[ubl-lcsc] 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 ---

From: "Fred Blommestein, van" <>

To: , , ,

Date: Thu, 11 Apr 2002 00:41:08 -0400

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 <>  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 ---

From: "Fred Blommestein, van" <>

To: , , 

Date: Tue, 09 Apr 2002 18:04:41 -0400

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 <>  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: <>

To: <>

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 ---

From: Todd Boyle <>

To: Gait Boxman <>,"Fred Blommestein, van" <>,, 

Date: Wed, 10 Apr 2002 12:55:29 -0400

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 ---

From: "Fred Blommestein, van" <>

To: , , 

Date: Wed, 10 Apr 2002 06:31:26 -0400

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 <> 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" <>

To: <>; <>;

<>

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 <> 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" <>

To: <>; <>;

<>

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 <>  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: <>

To: <>

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 ---

From: "Fred Blommestein, van" <>

To: , , 

Date: Wed, 10 Apr 2002 05:40:46 -0400

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 <> 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" <>

To: <>; <>;

<>

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 <>  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: <>

To: <>

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 ---

From: Gait Boxman <>

To: "Fred Blommestein, van" <>,, 

Date: Wed, 10 Apr 2002 06:06:17 -0400

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" <>

To: <>; <>;

<>

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 <> 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" <>

To: <>; <>;

<>

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 <>  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: <>

To: <>

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 ---

From: Gait Boxman <>

To: "Fred Blommestein, van" <>,, 

Date: Wed, 10 Apr 2002 03:40:03 -0400

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" <>

To: <>; <>;

<>

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 <>  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: <>

To: <>

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 ---

From: Gait Boxman <>

To: , 

Date: Tue, 09 Apr 2002 02:47:15 -0400

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: <>

To: <>

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 ---

From: 

To: 

Date: Mon, 08 Apr 2002 17:19:03 -0400

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 ---