OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [ubl-ndrsc] Important eBTWG Code/CCT discussion

Title: Important eBTWG Code/CCT discussion

<<Re: [CCSD] Re: DISCUSSION CODE vs IDENTIFIER>> <<[CCSD] Re: DISCUSSION CODE vs IDENTIFIER>> <<Re: [CCSD] Re: DISCUSSION CODE vs IDENTIFIER>> <<Re: [CCSD] Re: DISCUSSION CODE vs IDENTIFIER>> <<Re: [CCSD] Re: DISCUSSION CODE vs IDENTIFIER>> <<Re: [CCSD] Re: DISCUSSION CODE vs IDENTIFIER>> <<Re: [CCSD] Re: DISCUSSION CODE vs IDENTIFIER>> <<Re: CCSD - DISCUSSION CODE vs IDENTIFIER>> <<CCSD - DISCUSSION CODE vs IDENTIFIER>>

Many of you are not subscribed to the eBTWG CC listserve.  The attached messages are from an ongoing discussion of the Core Components Supplementary Documents (CCSD) project team that is also doing a proof of concept for the core components.  I think we need to watch their conversations as we may be able to apply some of their thinking with our own as we write our inputs to the CC Technical Specification project team.

Mark
"

--- Begin Message ---
Title: Re: [CCSD] Re: DISCUSSION CODE vs IDENTIFIER

Hi Todd,

Identifiers seem to be a subclass of codes. The distinction is important in my opinion, which has to to with the maintenance issue (like I mentioned during the call). Like in Edifact, I think that codes need to be maintained and stored with the attribute they are coding: in the repository. Like with BIE's, private lists should (in the name of interoperability) be defined as subsets of the centrally harmonised list.

Identifiers are typically maintained by third parties. The set to identify is mostly (so not in all cases!!) much larger than a set of codes. Here your change request (that was approved) to send (or at least define) the URI of an identification scheme helps.

I think the basic set of types will (and should) not be very dynamic. Types are probably handled on a lower software level and should be fairly stable. There are some types though I am not very comfortable with. One is the DataTime type. First it may be used to define different concepts (point-in-time, period, recurrent period, duration) which is confusing, second because the type contains a "format code" as an attribute that has not been defined. Reference is made to ISO8601, which is a syntax on its own. For the EWG I am preparing a paper on this subject, and I probably will submit a change request to the spec.

Another issue is the "typing" or stereotyping of composites. This is a mechanism now not defined, but probably needed. The discussions in CCSD seem to lead to define ACC's on too low a level (e.g. "Address"), while the level ACC should be the highest non-context dependent. As this is another subject I'll not further elaborate it, but I value your opinion.

Fred

<<< Todd Boyle <tboyle@rosehill.net>  4/10  6:50p >>>
Is Code.Type a specialized case of Identifier.Type?
     or,
Are they both specialized cases of something more basic?
     or,
neither of the above?

If, upon close inspection, Code and Identifier really are
related classes, either siblings or class/subclass, then,
would there be costs or disruption in changing the CCTS?
In principle, if some change of this nature were found to be
necessary, would CCTS be modified at this time or would it be
wiser to publish an approved version 1.o and push any change
into version 2.x?

Another question one might ask, is whether these two types
(Code and Identifier) are really CCT's.   A CCT is supposed to
be an irreducible element, without business context, without
implied behaviors etc. etc.  I mean, all of the other CCT's are
almost compuer language datatypes.  Let us agree in any case
Code and Identifier types are necessary but, if we found out
that they don't fit the principle then, would pragmatism prevail
over principle?   If so then, why not just chuck the principle,
and create a process for the introduction and approval of more
and more CCT's?  The CCTS today says that the CCT types
in the CCTS are a closed set.  (My own preferences would be
to collapse some of the levels of the "stack" in the CCTS but
I cannot pretend to see the whole big picture.)

I'm just asking; I just think discussion and repetition of some
of these things can be helpful,

Todd


 


                       

--- End Message ---
--- Begin Message ---
Title: [CCSD] Re: DISCUSSION CODE vs IDENTIFIER

Hi Gait,

I fully agree with you. In the call I said that *mostly* codes are assigned centrally (and immediately noticed that that word is very dangerous in definitions).

You perfectly narrowed down the discussion to the difference between *things* (objects? classes?) and attributes (properties?). So: can an attribute or property be an object itself? Probably it can. Is a "payment terms code" the identification of an object? If "payment terms date" is an attribute, "payment terms" should be an object, or not?

Please advise us, like Melany said, how to make the definitions (more) unambiguous.

Fred

<<< Gait Boxman <gait.boxman@tie.nl>  4/ 9  8:50a >>>
Hi Melanie, Fred, others,

just my 0.02EUR on Codes and Identifiers:
I don't believe that it matters whether the owner of a code or identifier is
a standards org or just a party. It's perfectly viable to have party
specific codelists (or should we say partner-agreed specific codelists), and
it's also quite ok to have standards org assigned id's. An example of the
latter is the UN/LOCODE, or the EAN/UCC party number. In fashion retail,
parties quite often keep their own colour tables, and require translation
between them.
The major distinguishing property of identifiers and codes is that an
identifier tells you WHICH thing in a set of similar things you're talking
about (e.g. which party, which order, which article), while a code
identifies an attribute value that tells you WHAT KIND OF a thing it is
(e.g. the role of a party, the type of an order, or the colour of an
article).
This is already reflected in the existing definitions, which link the codes
to attribute values and identifiers to object identification.

Regards,
Gait Boxman.

----- Original Message -----
From: <melanie.mccarthy@gm.com>
To: <ebtwg-ccs@lists.ebtwg.org>
Sent: Monday, April 08, 2002 11:19 PM
Subject: CCSD - DISCUSSION CODE vs IDENTIFIER


During  08APR02 conference call we discussed the following open issue.
Following are extracts from the CCTS page 49, comments recorded from the
discussion and Monica's notes taken during our last discussion in Barcelona.
It
is apparent that the text could be clearer to avoid this type of confusion.
Please review it and make suggestions on how to 'enhance the text in the
CCTS'
so there is clear communication!

Looking forward to hearing from you,

Best Regards,

Melanie


   CODE (Definition from CCTS page 49) ? A character string (letters,
figures or
   symbols) that for brevity and/or language independence may be used to
   represent or replace a definitive value or text of an attribute.  Codes
   usually are maintained in code lists per attribute types (e.g colour).

    Fred?s comment :  Codes do things that are maintained by standardization
   committees


   IDENTIFIER (Definition from CCTS page 49)  -  A character string used to
   establish the identity of and distinguish uniquely, one instance of an
object
   within an identification scheme from all oth er objects within the same
   scheme.   [Note:  Type shall not be sued when a person or an object is
   identified by its name.  In this case the Representation Term ?Name?
shall be
   used.]

   Fred?s comment:  Identifiers are maintained internal organizations
(unique
   not looked up on a list)

   Monica?s comments:  The distinguishing guideline between identifier and
code
   is identifier
     is unique and is not looked up on a list while a code is checked
against a
     business process.

     There was some discussion about the clarity of Location.
Identification.
     Code, that exists in CCTS.  This should be an identifier not a code.
     Redefine Identifier. Type so it does not specify âcharacterâ for
string.
     This should be assessed against other CCT.





                       

--- End Message ---
--- Begin Message ---
Title: Re: [CCSD] Re: DISCUSSION CODE vs IDENTIFIER

Is Code.Type a specialized case of Identifier.Type?
     or,
Are they both specialized cases of something more basic?
     or,
neither of the above?

If, upon close inspection, Code and Identifier really are
related classes, either siblings or class/subclass, then,
would there be costs or disruption in changing the CCTS?
In principle, if some change of this nature were found to be
necessary, would CCTS be modified at this time or would it be
wiser to publish an approved version 1.o and push any change
into version 2.x?

Another question one might ask, is whether these two types
(Code and Identifier) are really CCT's.   A CCT is supposed to
be an irreducible element, without business context, without
implied behaviors etc. etc.  I mean, all of the other CCT's are
almost compuer language datatypes.  Let us agree in any case
Code and Identifier types are necessary but, if we found out
that they don't fit the principle then, would pragmatism prevail
over principle?   If so then, why not just chuck the principle,
and create a process for the introduction and approval of more
and more CCT's?  The CCTS today says that the CCT types
in the CCTS are a closed set.  (My own preferences would be
to collapse some of the levels of the "stack" in the CCTS but
I cannot pretend to see the whole big picture.)

I'm just asking; I just think discussion and repetition of some
of these things can be helpful,

Todd


 

--- End Message ---
--- Begin Message ---
Title: Re: [CCSD] Re: DISCUSSION CODE vs IDENTIFIER

Hi Gait,

I agree with the "SHOULD".
I think the note will be helpfull as one of the outcomes of the CCSD project is probably that we need class diagrams associated with requests for new BIE's and CC's. From the Class diagram it should be clear whether the element points to an object or an attribute.

Fred

>>> Gait Boxman <gait.boxman@tie.nl> 04/10/02 12:06pm >>>
Hi,

Adding the note does not resolve the problem itself, which is more of
conceptual level (is a payment term an object, or not). The note at least
hints to the alternative and should trigger some thought on it, but I would
expect some explanatory discussion on the choice between the terms outside
of the definitions. Since there are quite a few borderline cases like
payment terms, *shall* (in the note) appears to be too strong. I think
*should* is more appropriate.

Gait.
----- Original Message -----
From: "Fred Blommestein, van" <f.van.blommestein@berenschot.com>
To: <melanie.mccarthy@gm.com>; <ebtwg-ccs@lists.ebtwg.org>;
<gait.boxman@tie.nl>
Sent: Wednesday, April 10, 2002 11:40 AM
Subject: Re: [CCSD] Re: DISCUSSION CODE vs IDENTIFIER


Hi Gait,

Thanks so much for your quick and lengthy answer!
I fully trust your experience in this field and can recognise much of your
observations from my own experience.

So I also would advise not really to change the definitions of Code and
Identifier. What we could do to avoid ambiguity is to add a note to the Code
definition (like there is a note in the Identifier definition to distinguish
it from the Name type)

The note could be phrased as:

[Note: Type shall not be used if the character string identifies an instance
of an object, in which case the Representation Term *Identifier* shall be
used.]

So the procedure for allocating the types could be that first is examined
whether Identifier applies, and only if it does not, to assign the Code
type. What do you think?

The two definitions then would be:

Code:
A character string (letters, figures or symbols)
that for brevity and / or language independence
may be used to represent or replace a definitive
value or text of an attribute. Codes usually are
maintained in code lists per attribute type (e.g.
colour). Code. Type
[Note: Type shall not be used if the character string identifies an instance
of an object, in which case the Representation Term *Identifier* shall be
used.]

Identifier:
A character string used to establish the identity of,
and distinguish uniquely, one instance of an
object within an identification scheme from all
other objects within the same scheme.
[Note: Type shall not be used when a person or an
object is identified by its name. In this case the
Representation Term *Name* shall be used.]
Identifier. Type

Fred

>>> Gait Boxman <gait.boxman@tie.nl> 04/10/02 09:40am >>>
Hi Fred,

as always when trying to define business data, there is a gray area where
things are not always as crystal clear as we want them to be, and
interpretation of a few words can lead to long and sometimes heated
discussions, even in EWG/T1 (Technical Assessment for UN/EDIFACT).
Lesson 1 on these forums: don't blindly interpret an element name, but first
look at the description to what it is you think it is. CC has developed a
similar rule: descriptions first.

I'll try to answer your question using my EDIFACT knowledge, which is
atmittedly mostly technical, since I'm not a banking or financial expert.

As you probably know, the EDIFACT PYT segment is used to identify the
payment terms attribute(s) of an object. From the segment structure, we can
see it's an attribute, since it is qualified with a 'payment terms type code
qualifier' (DE 4279). However, this is actually immaterial to the question
whether or not it is an object. We already know objects can be attributes of
other objects, just like a steering wheel most of the time belongs to a car.

The segment structure allows two ways to describe the actual payment terms.
One is through a coded value (DE 4277), i.e. the 'payment terms description
identifier', which can be further qualified by a code list id and agency, or
through a simple text description. Effectively, this shows that at least for
some people, there is a need to identify one payment terms description from
a predefined list, hence one could at least say that payment terms
descriptions are identifyable objects. Along with the description, you
probably also need some date/time information, which can also be transmitted
in the PYT segment.

I suspect 'payment terms code' was the old name for either DE 4277 or DE
4279, as well as being the business term in banking (for the description
identifier). So in that sense, I'd say payment terms code is a misnomer, and
should read payment terms identifier.

The code list for DE 4279 shows some values that I would definitely not
expect there, since I'd say these were payterm descriptions. This hints to
interpretation problems of payterms, and the question of whether it is a
simple attribute, or an object is probably an old one.

Regarding the 'payment terms date', I question whether that is an attribute
on the payterm itself (as in, the date that the terms were defined or
initially agreed), or on the object to which the payterm applies. My guess
would be the latter, as in the payterm may read 'pay for the end of the
month', with a date as 'April, 2002'. In this case, the date is not a
payterm attribute, but an attribute to the application of the payterm to the
object (e.g. order).

As you can see, I sliced in a some context in the discussion, and the answer
to whether a payterm is an object or not, is context dependant.

The question of whether something is an object mainly boils down to whether
or not it can have attributes itself. E.g. I'd say colour is not an object,
even though one could use identifiers to specify a colour in a colour scheme
(e.g. pantone colours). Yet, paint is an object, but when referring to the
colour of  a car, we tend to not distinguish between paint and colour. We
actually use paint (an object) with a specific colour (an attribute of
paint) to get the colour of the car, and when describing the car, we only
list the colour as an attribute (except when painting the car itself, that's
where we also want paint types).
Something similar happens with payment terms. On it's own, a payment term is
an object, either agreed between parties, or enforced by a gorilla.com.
Typically, it has several attributes, such as an issue date, the location
where the paper copy of the terms is stored, the identification number etc.
Yet, when we want to apply these terms to an object, we don't care about all
those attributes. All we care about is this one important attribute of the
payterm, which is the actual terms of the payment, just like the colour of
the paint. Now, we can reissue those actual terms, or just list the
identification number of the payterm itself, thereby indirectly listing the
terms (you might call this a reference, but I'm not going to include
referencing in this discussion).

I don't think we can always make a clear distinction between codes and
identifiers. I do know we've had problems with this in UN/EDIFACT and data
modelling in general, and have to live with the consequences. I expect we're
going to have similar problems in the future, with Core Components, and
whatever else we'll build.

I hope this shed some light on the problems, although I realize it does not
give a better solution. In fact, I don't think we can get much better
definitions than we already have. People have been confused regarding codes,
numbers, identifiers and references ever since they started using these
concepts, and probably will be for a long time.

Regards, Gait.

----- Original Message -----
From: "Fred Blommestein, van" <f.van.blommestein@berenschot.com>
To: <melanie.mccarthy@gm.com>; <ebtwg-ccs@lists.ebtwg.org>;
<gait.boxman@tie.nl>
Sent: Wednesday, April 10, 2002 12:04 AM
Subject: [CCSD] Re: DISCUSSION CODE vs IDENTIFIER


Hi Gait,

I fully agree with you. In the call I said that *mostly* codes are assigned
centrally (and immediately noticed that that word is very dangerous in
definitions).

You perfectly narrowed down the discussion to the difference between
*things* (objects? classes?) and attributes (properties?). So: can an
attribute or property be an object itself? Probably it can. Is a "payment
terms code" the identification of an object? If "payment terms date" is an
attribute, "payment terms" should be an object, or not?

Please advise us, like Melany said, how to make the definitions (more)
unambiguous.

Fred

<<< Gait Boxman <gait.boxman@tie.nl>  4/ 9  8:50a >>>
Hi Melanie, Fred, others,

just my 0.02EUR on Codes and Identifiers:
I don't believe that it matters whether the owner of a code or identifier is
a standards org or just a party. It's perfectly viable to have party
specific codelists (or should we say partner-agreed specific codelists), and
it's also quite ok to have standards org assigned id's. An example of the
latter is the UN/LOCODE, or the EAN/UCC party number. In fashion retail,
parties quite often keep their own colour tables, and require translation
between them.
The major distinguishing property of identifiers and codes is that an
identifier tells you WHICH thing in a set of similar things you're talking
about (e.g. which party, which order, which article), while a code
identifies an attribute value that tells you WHAT KIND OF a thing it is
(e.g. the role of a party, the type of an order, or the colour of an
article).
This is already reflected in the existing definitions, which link the codes
to attribute values and identifiers to object identification.

Regards,
Gait Boxman.

----- Original Message -----
From: <melanie.mccarthy@gm.com>
To: <ebtwg-ccs@lists.ebtwg.org>
Sent: Monday, April 08, 2002 11:19 PM
Subject: CCSD - DISCUSSION CODE vs IDENTIFIER


During  08APR02 conference call we discussed the following open issue.
Following are extracts from the CCTS page 49, comments recorded from the
discussion and Monica's notes taken during our last discussion in Barcelona.
It
is apparent that the text could be clearer to avoid this type of confusion.
Please review it and make suggestions on how to 'enhance the text in the
CCTS'
so there is clear communication!

Looking forward to hearing from you,

Best Regards,

Melanie


   CODE (Definition from CCTS page 49) ? A character string (letters,
figures or
   symbols) that for brevity and/or language independence may be used to
   represent or replace a definitive value or text of an attribute.  Codes
   usually are maintained in code lists per attribute types (e.g colour).

    Fred?s comment :  Codes do things that are maintained by standardization
   committees


   IDENTIFIER (Definition from CCTS page 49)  -  A character string used to
   establish the identity of and distinguish uniquely, one instance of an
object
   within an identification scheme from all oth er objects within the same
   scheme.   [Note:  Type shall not be sued when a person or an object is
   identified by its name.  In this case the Representation Term ?Name?
shall be
   used.]

   Fred?s comment:  Identifiers are maintained internal organizations
(unique
   not looked up on a list)

   Monica?s comments:  The distinguishing guideline between identifier and
code
   is identifier
     is unique and is not looked up on a list while a code is checked
against a
     business process.

     There was some discussion about the clarity of Location.
Identification.
     Code, that exists in CCTS.  This should be an identifier not a code.
     Redefine Identifier. Type so it does not specify âcharacterâ for
string.
     This should be assessed against other CCT.






--- End Message ---
--- Begin Message ---
Title: Re: [CCSD] Re: DISCUSSION CODE vs IDENTIFIER

Hi Gait,

Thanks so much for your quick and lengthy answer!
I fully trust your experience in this field and can recognise much of your observations from my own experience.

So I also would advise not really to change the definitions of Code and Identifier. What we could do to avoid ambiguity is to add a note to the Code definition (like there is a note in the Identifier definition to distinguish it from the Name type)

The note could be phrased as:

[Note: Type shall not be used if the character string identifies an instance of an object, in which case the Representation Term *Identifier* shall be used.]

So the procedure for allocating the types could be that first is examined whether Identifier applies, and only if it does not, to assign the Code type. What do you think?

The two definitions then would be:

Code:
A character string (letters, figures or symbols)
that for brevity and / or language independence
may be used to represent or replace a definitive
value or text of an attribute. Codes usually are
maintained in code lists per attribute type (e.g.
colour). Code. Type
[Note: Type shall not be used if the character string identifies an instance of an object, in which case the Representation Term *Identifier* shall be used.]

Identifier:
A character string used to establish the identity of,
and distinguish uniquely, one instance of an
object within an identification scheme from all
other objects within the same scheme.
[Note: Type shall not be used when a person or an
object is identified by its name. In this case the
Representation Term *Name* shall be used.]
Identifier. Type

Fred

>>> Gait Boxman <gait.boxman@tie.nl> 04/10/02 09:40am >>>
Hi Fred,

as always when trying to define business data, there is a gray area where
things are not always as crystal clear as we want them to be, and
interpretation of a few words can lead to long and sometimes heated
discussions, even in EWG/T1 (Technical Assessment for UN/EDIFACT).
Lesson 1 on these forums: don't blindly interpret an element name, but first
look at the description to what it is you think it is. CC has developed a
similar rule: descriptions first.

I'll try to answer your question using my EDIFACT knowledge, which is
atmittedly mostly technical, since I'm not a banking or financial expert.

As you probably know, the EDIFACT PYT segment is used to identify the
payment terms attribute(s) of an object. From the segment structure, we can
see it's an attribute, since it is qualified with a 'payment terms type code
qualifier' (DE 4279). However, this is actually immaterial to the question
whether or not it is an object. We already know objects can be attributes of
other objects, just like a steering wheel most of the time belongs to a car.

The segment structure allows two ways to describe the actual payment terms.
One is through a coded value (DE 4277), i.e. the 'payment terms description
identifier', which can be further qualified by a code list id and agency, or
through a simple text description. Effectively, this shows that at least for
some people, there is a need to identify one payment terms description from
a predefined list, hence one could at least say that payment terms
descriptions are identifyable objects. Along with the description, you
probably also need some date/time information, which can also be transmitted
in the PYT segment.

I suspect 'payment terms code' was the old name for either DE 4277 or DE
4279, as well as being the business term in banking (for the description
identifier). So in that sense, I'd say payment terms code is a misnomer, and
should read payment terms identifier.

The code list for DE 4279 shows some values that I would definitely not
expect there, since I'd say these were payterm descriptions. This hints to
interpretation problems of payterms, and the question of whether it is a
simple attribute, or an object is probably an old one.

Regarding the 'payment terms date', I question whether that is an attribute
on the payterm itself (as in, the date that the terms were defined or
initially agreed), or on the object to which the payterm applies. My guess
would be the latter, as in the payterm may read 'pay for the end of the
month', with a date as 'April, 2002'. In this case, the date is not a
payterm attribute, but an attribute to the application of the payterm to the
object (e.g. order).

As you can see, I sliced in a some context in the discussion, and the answer
to whether a payterm is an object or not, is context dependant.

The question of whether something is an object mainly boils down to whether
or not it can have attributes itself. E.g. I'd say colour is not an object,
even though one could use identifiers to specify a colour in a colour scheme
(e.g. pantone colours). Yet, paint is an object, but when referring to the
colour of  a car, we tend to not distinguish between paint and colour. We
actually use paint (an object) with a specific colour (an attribute of
paint) to get the colour of the car, and when describing the car, we only
list the colour as an attribute (except when painting the car itself, that's
where we also want paint types).
Something similar happens with payment terms. On it's own, a payment term is
an object, either agreed between parties, or enforced by a gorilla.com.
Typically, it has several attributes, such as an issue date, the location
where the paper copy of the terms is stored, the identification number etc.
Yet, when we want to apply these terms to an object, we don't care about all
those attributes. All we care about is this one important attribute of the
payterm, which is the actual terms of the payment, just like the colour of
the paint. Now, we can reissue those actual terms, or just list the
identification number of the payterm itself, thereby indirectly listing the
terms (you might call this a reference, but I'm not going to include
referencing in this discussion).

I don't think we can always make a clear distinction between codes and
identifiers. I do know we've had problems with this in UN/EDIFACT and data
modelling in general, and have to live with the consequences. I expect we're
going to have similar problems in the future, with Core Components, and
whatever else we'll build.

I hope this shed some light on the problems, although I realize it does not
give a better solution. In fact, I don't think we can get much better
definitions than we already have. People have been confused regarding codes,
numbers, identifiers and references ever since they started using these
concepts, and probably will be for a long time.

Regards, Gait.

----- Original Message -----
From: "Fred Blommestein, van" <f.van.blommestein@berenschot.com>
To: <melanie.mccarthy@gm.com>; <ebtwg-ccs@lists.ebtwg.org>;
<gait.boxman@tie.nl>
Sent: Wednesday, April 10, 2002 12:04 AM
Subject: [CCSD] Re: DISCUSSION CODE vs IDENTIFIER


Hi Gait,

I fully agree with you. In the call I said that *mostly* codes are assigned
centrally (and immediately noticed that that word is very dangerous in
definitions).

You perfectly narrowed down the discussion to the difference between
*things* (objects? classes?) and attributes (properties?). So: can an
attribute or property be an object itself? Probably it can. Is a "payment
terms code" the identification of an object? If "payment terms date" is an
attribute, "payment terms" should be an object, or not?

Please advise us, like Melany said, how to make the definitions (more)
unambiguous.

Fred

<<< Gait Boxman <gait.boxman@tie.nl>  4/ 9  8:50a >>>
Hi Melanie, Fred, others,

just my 0.02EUR on Codes and Identifiers:
I don't believe that it matters whether the owner of a code or identifier is
a standards org or just a party. It's perfectly viable to have party
specific codelists (or should we say partner-agreed specific codelists), and
it's also quite ok to have standards org assigned id's. An example of the
latter is the UN/LOCODE, or the EAN/UCC party number. In fashion retail,
parties quite often keep their own colour tables, and require translation
between them.
The major distinguishing property of identifiers and codes is that an
identifier tells you WHICH thing in a set of similar things you're talking
about (e.g. which party, which order, which article), while a code
identifies an attribute value that tells you WHAT KIND OF a thing it is
(e.g. the role of a party, the type of an order, or the colour of an
article).
This is already reflected in the existing definitions, which link the codes
to attribute values and identifiers to object identification.

Regards,
Gait Boxman.

----- Original Message -----
From: <melanie.mccarthy@gm.com>
To: <ebtwg-ccs@lists.ebtwg.org>
Sent: Monday, April 08, 2002 11:19 PM
Subject: CCSD - DISCUSSION CODE vs IDENTIFIER


During  08APR02 conference call we discussed the following open issue.
Following are extracts from the CCTS page 49, comments recorded from the
discussion and Monica's notes taken during our last discussion in Barcelona.
It
is apparent that the text could be clearer to avoid this type of confusion.
Please review it and make suggestions on how to 'enhance the text in the
CCTS'
so there is clear communication!

Looking forward to hearing from you,

Best Regards,

Melanie


   CODE (Definition from CCTS page 49) ? A character string (letters,
figures or
   symbols) that for brevity and/or language independence may be used to
   represent or replace a definitive value or text of an attribute.  Codes
   usually are maintained in code lists per attribute types (e.g colour).

    Fred?s comment :  Codes do things that are maintained by standardization
   committees


   IDENTIFIER (Definition from CCTS page 49)  -  A character string used to
   establish the identity of and distinguish uniquely, one instance of an
object
   within an identification scheme from all oth er objects within the same
   scheme.   [Note:  Type shall not be sued when a person or an object is
   identified by its name.  In this case the Representation Term ?Name?
shall be
   used.]

   Fred?s comment:  Identifiers are maintained internal organizations
(unique
   not looked up on a list)

   Monica?s comments:  The distinguishing guideline between identifier and
code
   is identifier
     is unique and is not looked up on a list while a code is checked
against a
     business process.

     There was some discussion about the clarity of Location.
Identification.
     Code, that exists in CCTS.  This should be an identifier not a code.
     Redefine Identifier. Type so it does not specify âcharacterâ for
string.
     This should be assessed against other CCT.






--- End Message ---
--- Begin Message ---
Title: Re: [CCSD] Re: DISCUSSION CODE vs IDENTIFIER

Hi,

Adding the note does not resolve the problem itself, which is more of
conceptual level (is a payment term an object, or not). The note at least
hints to the alternative and should trigger some thought on it, but I would
expect some explanatory discussion on the choice between the terms outside
of the definitions. Since there are quite a few borderline cases like
payment terms, *shall* (in the note) appears to be too strong. I think
*should* is more appropriate.

Gait.
----- Original Message -----
From: "Fred Blommestein, van" <f.van.blommestein@berenschot.com>
To: <melanie.mccarthy@gm.com>; <ebtwg-ccs@lists.ebtwg.org>;
<gait.boxman@tie.nl>
Sent: Wednesday, April 10, 2002 11:40 AM
Subject: Re: [CCSD] Re: DISCUSSION CODE vs IDENTIFIER


Hi Gait,

Thanks so much for your quick and lengthy answer!
I fully trust your experience in this field and can recognise much of your
observations from my own experience.

So I also would advise not really to change the definitions of Code and
Identifier. What we could do to avoid ambiguity is to add a note to the Code
definition (like there is a note in the Identifier definition to distinguish
it from the Name type)

The note could be phrased as:

[Note: Type shall not be used if the character string identifies an instance
of an object, in which case the Representation Term *Identifier* shall be
used.]

So the procedure for allocating the types could be that first is examined
whether Identifier applies, and only if it does not, to assign the Code
type. What do you think?

The two definitions then would be:

Code:
A character string (letters, figures or symbols)
that for brevity and / or language independence
may be used to represent or replace a definitive
value or text of an attribute. Codes usually are
maintained in code lists per attribute type (e.g.
colour). Code. Type
[Note: Type shall not be used if the character string identifies an instance
of an object, in which case the Representation Term *Identifier* shall be
used.]

Identifier:
A character string used to establish the identity of,
and distinguish uniquely, one instance of an
object within an identification scheme from all
other objects within the same scheme.
[Note: Type shall not be used when a person or an
object is identified by its name. In this case the
Representation Term *Name* shall be used.]
Identifier. Type

Fred

>>> Gait Boxman <gait.boxman@tie.nl> 04/10/02 09:40am >>>
Hi Fred,

as always when trying to define business data, there is a gray area where
things are not always as crystal clear as we want them to be, and
interpretation of a few words can lead to long and sometimes heated
discussions, even in EWG/T1 (Technical Assessment for UN/EDIFACT).
Lesson 1 on these forums: don't blindly interpret an element name, but first
look at the description to what it is you think it is. CC has developed a
similar rule: descriptions first.

I'll try to answer your question using my EDIFACT knowledge, which is
atmittedly mostly technical, since I'm not a banking or financial expert.

As you probably know, the EDIFACT PYT segment is used to identify the
payment terms attribute(s) of an object. From the segment structure, we can
see it's an attribute, since it is qualified with a 'payment terms type code
qualifier' (DE 4279). However, this is actually immaterial to the question
whether or not it is an object. We already know objects can be attributes of
other objects, just like a steering wheel most of the time belongs to a car.

The segment structure allows two ways to describe the actual payment terms.
One is through a coded value (DE 4277), i.e. the 'payment terms description
identifier', which can be further qualified by a code list id and agency, or
through a simple text description. Effectively, this shows that at least for
some people, there is a need to identify one payment terms description from
a predefined list, hence one could at least say that payment terms
descriptions are identifyable objects. Along with the description, you
probably also need some date/time information, which can also be transmitted
in the PYT segment.

I suspect 'payment terms code' was the old name for either DE 4277 or DE
4279, as well as being the business term in banking (for the description
identifier). So in that sense, I'd say payment terms code is a misnomer, and
should read payment terms identifier.

The code list for DE 4279 shows some values that I would definitely not
expect there, since I'd say these were payterm descriptions. This hints to
interpretation problems of payterms, and the question of whether it is a
simple attribute, or an object is probably an old one.

Regarding the 'payment terms date', I question whether that is an attribute
on the payterm itself (as in, the date that the terms were defined or
initially agreed), or on the object to which the payterm applies. My guess
would be the latter, as in the payterm may read 'pay for the end of the
month', with a date as 'April, 2002'. In this case, the date is not a
payterm attribute, but an attribute to the application of the payterm to the
object (e.g. order).

As you can see, I sliced in a some context in the discussion, and the answer
to whether a payterm is an object or not, is context dependant.

The question of whether something is an object mainly boils down to whether
or not it can have attributes itself. E.g. I'd say colour is not an object,
even though one could use identifiers to specify a colour in a colour scheme
(e.g. pantone colours). Yet, paint is an object, but when referring to the
colour of  a car, we tend to not distinguish between paint and colour. We
actually use paint (an object) with a specific colour (an attribute of
paint) to get the colour of the car, and when describing the car, we only
list the colour as an attribute (except when painting the car itself, that's
where we also want paint types).
Something similar happens with payment terms. On it's own, a payment term is
an object, either agreed between parties, or enforced by a gorilla.com.
Typically, it has several attributes, such as an issue date, the location
where the paper copy of the terms is stored, the identification number etc.
Yet, when we want to apply these terms to an object, we don't care about all
those attributes. All we care about is this one important attribute of the
payterm, which is the actual terms of the payment, just like the colour of
the paint. Now, we can reissue those actual terms, or just list the
identification number of the payterm itself, thereby indirectly listing the
terms (you might call this a reference, but I'm not going to include
referencing in this discussion).

I don't think we can always make a clear distinction between codes and
identifiers. I do know we've had problems with this in UN/EDIFACT and data
modelling in general, and have to live with the consequences. I expect we're
going to have similar problems in the future, with Core Components, and
whatever else we'll build.

I hope this shed some light on the problems, although I realize it does not
give a better solution. In fact, I don't think we can get much better
definitions than we already have. People have been confused regarding codes,
numbers, identifiers and references ever since they started using these
concepts, and probably will be for a long time.

Regards, Gait.

----- Original Message -----
From: "Fred Blommestein, van" <f.van.blommestein@berenschot.com>
To: <melanie.mccarthy@gm.com>; <ebtwg-ccs@lists.ebtwg.org>;
<gait.boxman@tie.nl>
Sent: Wednesday, April 10, 2002 12:04 AM
Subject: [CCSD] Re: DISCUSSION CODE vs IDENTIFIER


Hi Gait,

I fully agree with you. In the call I said that *mostly* codes are assigned
centrally (and immediately noticed that that word is very dangerous in
definitions).

You perfectly narrowed down the discussion to the difference between
*things* (objects? classes?) and attributes (properties?). So: can an
attribute or property be an object itself? Probably it can. Is a "payment
terms code" the identification of an object? If "payment terms date" is an
attribute, "payment terms" should be an object, or not?

Please advise us, like Melany said, how to make the definitions (more)
unambiguous.

Fred

<<< Gait Boxman <gait.boxman@tie.nl>  4/ 9  8:50a >>>
Hi Melanie, Fred, others,

just my 0.02EUR on Codes and Identifiers:
I don't believe that it matters whether the owner of a code or identifier is
a standards org or just a party. It's perfectly viable to have party
specific codelists (or should we say partner-agreed specific codelists), and
it's also quite ok to have standards org assigned id's. An example of the
latter is the UN/LOCODE, or the EAN/UCC party number. In fashion retail,
parties quite often keep their own colour tables, and require translation
between them.
The major distinguishing property of identifiers and codes is that an
identifier tells you WHICH thing in a set of similar things you're talking
about (e.g. which party, which order, which article), while a code
identifies an attribute value that tells you WHAT KIND OF a thing it is
(e.g. the role of a party, the type of an order, or the colour of an
article).
This is already reflected in the existing definitions, which link the codes
to attribute values and identifiers to object identification.

Regards,
Gait Boxman.

----- Original Message -----
From: <melanie.mccarthy@gm.com>
To: <ebtwg-ccs@lists.ebtwg.org>
Sent: Monday, April 08, 2002 11:19 PM
Subject: CCSD - DISCUSSION CODE vs IDENTIFIER


During  08APR02 conference call we discussed the following open issue.
Following are extracts from the CCTS page 49, comments recorded from the
discussion and Monica's notes taken during our last discussion in Barcelona.
It
is apparent that the text could be clearer to avoid this type of confusion.
Please review it and make suggestions on how to 'enhance the text in the
CCTS'
so there is clear communication!

Looking forward to hearing from you,

Best Regards,

Melanie


   CODE (Definition from CCTS page 49) ? A character string (letters,
figures or
   symbols) that for brevity and/or language independence may be used to
   represent or replace a definitive value or text of an attribute.  Codes
   usually are maintained in code lists per attribute types (e.g colour).

    Fred?s comment :  Codes do things that are maintained by standardization
   committees


   IDENTIFIER (Definition from CCTS page 49)  -  A character string used to
   establish the identity of and distinguish uniquely, one instance of an
object
   within an identification scheme from all oth er objects within the same
   scheme.   [Note:  Type shall not be sued when a person or an object is
   identified by its name.  In this case the Representation Term ?Name?
shall be
   used.]

   Fred?s comment:  Identifiers are maintained internal organizations
(unique
   not looked up on a list)

   Monica?s comments:  The distinguishing guideline between identifier and
code
   is identifier
     is unique and is not looked up on a list while a code is checked
against a
     business process.

     There was some discussion about the clarity of Location.
Identification.
     Code, that exists in CCTS.  This should be an identifier not a code.
     Redefine Identifier. Type so it does not specify âcharacterâ for
string.
     This should be assessed against other CCT.






--- End Message ---
--- Begin Message ---
Title: Re: [CCSD] Re: DISCUSSION CODE vs IDENTIFIER

Hi Fred,

as always when trying to define business data, there is a gray area where
things are not always as crystal clear as we want them to be, and
interpretation of a few words can lead to long and sometimes heated
discussions, even in EWG/T1 (Technical Assessment for UN/EDIFACT).
Lesson 1 on these forums: don't blindly interpret an element name, but first
look at the description to what it is you think it is. CC has developed a
similar rule: descriptions first.

I'll try to answer your question using my EDIFACT knowledge, which is
atmittedly mostly technical, since I'm not a banking or financial expert.

As you probably know, the EDIFACT PYT segment is used to identify the
payment terms attribute(s) of an object. From the segment structure, we can
see it's an attribute, since it is qualified with a 'payment terms type code
qualifier' (DE 4279). However, this is actually immaterial to the question
whether or not it is an object. We already know objects can be attributes of
other objects, just like a steering wheel most of the time belongs to a car.

The segment structure allows two ways to describe the actual payment terms.
One is through a coded value (DE 4277), i.e. the 'payment terms description
identifier', which can be further qualified by a code list id and agency, or
through a simple text description. Effectively, this shows that at least for
some people, there is a need to identify one payment terms description from
a predefined list, hence one could at least say that payment terms
descriptions are identifyable objects. Along with the description, you
probably also need some date/time information, which can also be transmitted
in the PYT segment.

I suspect 'payment terms code' was the old name for either DE 4277 or DE
4279, as well as being the business term in banking (for the description
identifier). So in that sense, I'd say payment terms code is a misnomer, and
should read payment terms identifier.

The code list for DE 4279 shows some values that I would definitely not
expect there, since I'd say these were payterm descriptions. This hints to
interpretation problems of payterms, and the question of whether it is a
simple attribute, or an object is probably an old one.

Regarding the 'payment terms date', I question whether that is an attribute
on the payterm itself (as in, the date that the terms were defined or
initially agreed), or on the object to which the payterm applies. My guess
would be the latter, as in the payterm may read 'pay for the end of the
month', with a date as 'April, 2002'. In this case, the date is not a
payterm attribute, but an attribute to the application of the payterm to the
object (e.g. order).

As you can see, I sliced in a some context in the discussion, and the answer
to whether a payterm is an object or not, is context dependant.

The question of whether something is an object mainly boils down to whether
or not it can have attributes itself. E.g. I'd say colour is not an object,
even though one could use identifiers to specify a colour in a colour scheme
(e.g. pantone colours). Yet, paint is an object, but when referring to the
colour of  a car, we tend to not distinguish between paint and colour. We
actually use paint (an object) with a specific colour (an attribute of
paint) to get the colour of the car, and when describing the car, we only
list the colour as an attribute (except when painting the car itself, that's
where we also want paint types).
Something similar happens with payment terms. On it's own, a payment term is
an object, either agreed between parties, or enforced by a gorilla.com.
Typically, it has several attributes, such as an issue date, the location
where the paper copy of the terms is stored, the identification number etc.
Yet, when we want to apply these terms to an object, we don't care about all
those attributes. All we care about is this one important attribute of the
payterm, which is the actual terms of the payment, just like the colour of
the paint. Now, we can reissue those actual terms, or just list the
identification number of the payterm itself, thereby indirectly listing the
terms (you might call this a reference, but I'm not going to include
referencing in this discussion).

I don't think we can always make a clear distinction between codes and
identifiers. I do know we've had problems with this in UN/EDIFACT and data
modelling in general, and have to live with the consequences. I expect we're
going to have similar problems in the future, with Core Components, and
whatever else we'll build.

I hope this shed some light on the problems, although I realize it does not
give a better solution. In fact, I don't think we can get much better
definitions than we already have. People have been confused regarding codes,
numbers, identifiers and references ever since they started using these
concepts, and probably will be for a long time.

Regards, Gait.

----- Original Message -----
From: "Fred Blommestein, van" <f.van.blommestein@berenschot.com>
To: <melanie.mccarthy@gm.com>; <ebtwg-ccs@lists.ebtwg.org>;
<gait.boxman@tie.nl>
Sent: Wednesday, April 10, 2002 12:04 AM
Subject: [CCSD] Re: DISCUSSION CODE vs IDENTIFIER


Hi Gait,

I fully agree with you. In the call I said that *mostly* codes are assigned
centrally (and immediately noticed that that word is very dangerous in
definitions).

You perfectly narrowed down the discussion to the difference between
*things* (objects? classes?) and attributes (properties?). So: can an
attribute or property be an object itself? Probably it can. Is a "payment
terms code" the identification of an object? If "payment terms date" is an
attribute, "payment terms" should be an object, or not?

Please advise us, like Melany said, how to make the definitions (more)
unambiguous.

Fred

<<< Gait Boxman <gait.boxman@tie.nl>  4/ 9  8:50a >>>
Hi Melanie, Fred, others,

just my 0.02EUR on Codes and Identifiers:
I don't believe that it matters whether the owner of a code or identifier is
a standards org or just a party. It's perfectly viable to have party
specific codelists (or should we say partner-agreed specific codelists), and
it's also quite ok to have standards org assigned id's. An example of the
latter is the UN/LOCODE, or the EAN/UCC party number. In fashion retail,
parties quite often keep their own colour tables, and require translation
between them.
The major distinguishing property of identifiers and codes is that an
identifier tells you WHICH thing in a set of similar things you're talking
about (e.g. which party, which order, which article), while a code
identifies an attribute value that tells you WHAT KIND OF a thing it is
(e.g. the role of a party, the type of an order, or the colour of an
article).
This is already reflected in the existing definitions, which link the codes
to attribute values and identifiers to object identification.

Regards,
Gait Boxman.

----- Original Message -----
From: <melanie.mccarthy@gm.com>
To: <ebtwg-ccs@lists.ebtwg.org>
Sent: Monday, April 08, 2002 11:19 PM
Subject: CCSD - DISCUSSION CODE vs IDENTIFIER


During  08APR02 conference call we discussed the following open issue.
Following are extracts from the CCTS page 49, comments recorded from the
discussion and Monica's notes taken during our last discussion in Barcelona.
It
is apparent that the text could be clearer to avoid this type of confusion.
Please review it and make suggestions on how to 'enhance the text in the
CCTS'
so there is clear communication!

Looking forward to hearing from you,

Best Regards,

Melanie


   CODE (Definition from CCTS page 49) ? A character string (letters,
figures or
   symbols) that for brevity and/or language independence may be used to
   represent or replace a definitive value or text of an attribute.  Codes
   usually are maintained in code lists per attribute types (e.g colour).

    Fred?s comment :  Codes do things that are maintained by standardization
   committees


   IDENTIFIER (Definition from CCTS page 49)  -  A character string used to
   establish the identity of and distinguish uniquely, one instance of an
object
   within an identification scheme from all oth er objects within the same
   scheme.   [Note:  Type shall not be sued when a person or an object is
   identified by its name.  In this case the Representation Term ?Name?
shall be
   used.]

   Fred?s comment:  Identifiers are maintained internal organizations
(unique
   not looked up on a list)

   Monica?s comments:  The distinguishing guideline between identifier and
code
   is identifier
     is unique and is not looked up on a list while a code is checked
against a
     business process.

     There was some discussion about the clarity of Location.
Identification.
     Code, that exists in CCTS.  This should be an identifier not a code.
     Redefine Identifier. Type so it does not specify âcharacterâ for
string.
     This should be assessed against other CCT.






--- End Message ---
--- Begin Message ---
Title: Re: CCSD - DISCUSSION CODE vs IDENTIFIER

Hi Melanie, Fred, others,

just my 0.02EUR on Codes and Identifiers:
I don't believe that it matters whether the owner of a code or identifier is
a standards org or just a party. It's perfectly viable to have party
specific codelists (or should we say partner-agreed specific codelists), and
it's also quite ok to have standards org assigned id's. An example of the
latter is the UN/LOCODE, or the EAN/UCC party number. In fashion retail,
parties quite often keep their own colour tables, and require translation
between them.
The major distinguishing property of identifiers and codes is that an
identifier tells you WHICH thing in a set of similar things you're talking
about (e.g. which party, which order, which article), while a code
identifies an attribute value that tells you WHAT KIND OF a thing it is
(e.g. the role of a party, the type of an order, or the colour of an
article).
This is already reflected in the existing definitions, which link the codes
to attribute values and identifiers to object identification.

Regards,
Gait Boxman.

----- Original Message -----
From: <melanie.mccarthy@gm.com>
To: <ebtwg-ccs@lists.ebtwg.org>
Sent: Monday, April 08, 2002 11:19 PM
Subject: CCSD - DISCUSSION CODE vs IDENTIFIER


During  08APR02 conference call we discussed the following open issue.
Following are extracts from the CCTS page 49, comments recorded from the
discussion and Monica's notes taken during our last discussion in Barcelona.
It
is apparent that the text could be clearer to avoid this type of confusion.
Please review it and make suggestions on how to 'enhance the text in the
CCTS'
so there is clear communication!

Looking forward to hearing from you,

Best Regards,

Melanie


   CODE (Definition from CCTS page 49) ? A character string (letters,
figures or
   symbols) that for brevity and/or language independence may be used to
   represent or replace a definitive value or text of an attribute.  Codes
   usually are maintained in code lists per attribute types (e.g colour).

    Fred?s comment :  Codes do things that are maintained by standardization
   committees


   IDENTIFIER (Definition from CCTS page 49)  -  A character string used to
   establish the identity of and distinguish uniquely, one instance of an
object
   within an identification scheme from all oth er objects within the same
   scheme.   [Note:  Type shall not be sued when a person or an object is
   identified by its name.  In this case the Representation Term ?Name?
shall be
   used.]

   Fred?s comment:  Identifiers are maintained internal organizations
(unique
   not looked up on a list)

   Monica?s comments:  The distinguishing guideline between identifier and
code
   is identifier
     is unique and is not looked up on a list while a code is checked
against a
     business process.

     There was some discussion about the clarity of Location.
Identification.
     Code, that exists in CCTS.  This should be an identifier not a code.
     Redefine Identifier. Type so it does not specify âcharacterâ for
string.
     This should be assessed against other CCT.



--- End Message ---
--- Begin Message ---
Title: CCSD - DISCUSSION CODE vs IDENTIFIER

During  08APR02 conference call we discussed the following open issue.
Following are extracts from the CCTS page 49, comments recorded from the
discussion and Monica's notes taken during our last discussion in Barcelona.  It
is apparent that the text could be clearer to avoid this type of confusion.
Please review it and make suggestions on how to 'enhance the text in the CCTS'
so there is clear communication!

Looking forward to hearing from you,

Best Regards,

Melanie


   CODE (Definition from CCTS page 49) ? A character string (letters, figures or
   symbols) that for brevity and/or language independence may be used to
   represent or replace a definitive value or text of an attribute.  Codes
   usually are maintained in code lists per attribute types (e.g colour).

    Fred?s comment :  Codes do things that are maintained by standardization
   committees


   IDENTIFIER (Definition from CCTS page 49)  -  A character string used to
   establish the identity of and distinguish uniquely, one instance of an object
   within an identification scheme from all oth er objects within the same
   scheme.   [Note:  Type shall not be sued when a person or an object is
   identified by its name.  In this case the Representation Term ?Name? shall be
   used.]

   Fred?s comment:  Identifiers are maintained internal organizations  (unique
   not looked up on a list)

   Monica?s comments:  The distinguishing guideline between identifier and code
   is identifier
     is unique and is not looked up on a list while a code is checked against a
     business process.

     There was some discussion about the clarity of Location. Identification.
     Code, that exists in CCTS.  This should be an identifier not a code.
     Redefine Identifier. Type so it does not specify âcharacterâ for string.
     This should be assessed against other CCT.



--- End Message ---

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC