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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

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


Subject: Re: [ubl-dev] Code vs. Identifier representation types?


On Thu, 14 Apr 2005 kenneth.sall@gsa.gov wrote:

>>.....

The UBL definitions do capture the essence of the difference,
though it may seem to be shrouded in similarities due to the
need to be more precise and all-encompassing.

Perhaps I can share how I look at them.   I tend to see Code
as a description of some sort of attribute of things, and
Identifier as a means to refer to things.  

Codes are identifiers for groups of things of dissimilar nature
usually described in the form of shortened abbreviations or plain 
acronyms for an equivalent English description of the groups of things.
Each Code Value describes one such group of things (amongst the
dissimilar groups of things) in which all the things in this group
share some kind of similarity under a given definition.

Allow me to use a simple generic example.  If a person A wants to buy
apples, and not oranges nor bananas nor any other types of fruits,
A might want to specify the Code Value "APPLE" for type of 
fruit to purchase in his P.O.  A doesn't want to identify
any specific apple, but just wish to convey the message "apple"
as a category.  The dissimilar groups of things are the fruit
categories.  The group of similar things identified by the
Code Value "APPLE" is the apple.

But if A now takes delivery of a box of apples and found that
one of them is rotten, and he wishes to reference that apple
to the seller to replace, he might wish to send a message referencing
the small unique string printed on the rotten apple.  That
unique string differentiates that rotten apple from the entire
box of seemingly identical apples, and allows A to unambiguously
pin-point in his message to the seller which apple that he wants
replaced.

So an Identifier then allows instances within a given Coded class
of similar, or dissimilar, instances to be unambiguously referenced.
Depending on how the valid values of a given Identifier type are
defined, these ID values may refer to instances within the same,
or different, Coded classes.


>>On a U.S. General Services Administration (GSA) project, we are applying
>>this to numerous data elements. For example,
>>
>>(a) A code identifying party receiving transmission; codes agreed to by
>>trading partners. Originally called Application Rcvrs Code (TXN06). We have
>>given this the BIE of Receiving_ Party. Identification. Identifier because
>>it uniquely distinguishes one party from all others.

Yes, Identifier.  The inherent Code class assumed will be the class
of all trading parties.  The Identifier then differentiates these 
trading parties as different instances.



>>(b) When considering the type of Indefinite Delivery Vehicle (IDV)
>>contract, there is a finite set of possible "brief" symbolic values that
>>can readily be enumerated. Therefore, the assigned BIE is Contract.
>>Indefinite Delivery Contract_ Type. Code.

Yes, Code.  You mentioned "type" of objects and "finite set of
possible ... values", all pointing to use of Code than Identifier.



>>(c) The FIPS Pub. 95 code for the agency of the contracting office that
>>executed or is otherwise responsible for the transaction was assigned the
>>BIE of Contracting_ Organization. Agency_ Identification. Identifier
>>because it uniquely distinguishes one agency from all others.

Yes, Identifier.  The inherent Code class assumed will be the class
of all agencies defined by your description above.  Instances will
be the agencies.



>>(d) Similarly, the US govt uses lots of "codes" such as NAICS codes (North
>>American Industry Classification System codes designate major sectors of
>>the economies of Mexico, Canada, and the United States) and PSC codes
>>(Product and Service Code). Since they "distinguish uniquely, one instance
>>of an object in an identification scheme from all other objects in the same
>>scheme", they should be Identifiers, right?

No, not immediately clear that it should be Identifier.  The NAICS 
sounds more right in saying "Classification".  The code values describe
types of objects (major sectors of economies), and have a finite set of
possible values (please see (b) above).

The reason I say it's not immediately clear is that it very much depends
on how you define "economies".  If one country is "defined" to have
one economy, then each "Identifier" would describe one instance of
the economies.  In my simple generic apple example above, it is like
delivering a box containing one apple labeled with an identifier.
So although one could use the only apple's identifier to reference
the apple, one could also use the code value "APPLE" because it
also unambiguously references the only apple present.

Entertaining the (likely) possibility of "instances" such as
companies, trading parties, etc from or belonging to or originating 
from or even exporting to those economies, the NAICS values would 
probably be more like a Code class than Identifiers.

For PSC, given a product or service category, one could have different
types of "instances" like manufacturers, service providers, importers,
exporters, etc.  Another set of "instances" might be origins of the
product (e.g. locally produced, imported, etc).  Again, allowing
such possibilities as valid instances of PSC, it would probably
be more appropriate to call PSC as Code (as its name suggests).



>>(e) Note that  calling (c) and (d) Identifiers goes against the commonly
>>used terms (FIPS codes, NAICS codes, PSC codes).

Hope (d) above nullifies this concern on (d).  
But I agree with you on (c).




>>Basically, UBL reserves
>>the term "code" strictly for symbolic shorthand elements, right?

I didn't think UBL defines "code" going by the mechanics of 
English shorthand, but more by the nature of the classes of things
and their relationships with their instances.



>>(f) DUNS and SSN (social security numbers) should be Identifiers.

Yes, Identifiers.  The inherent Code class assumed for SSN would 
be American citizens (plus naturalized immigrants, PRs).  Instances
would be American citizens (plus naturalized immigrants, PRs).


>>(g) Country codes and state codes should be Codes.

Yes, Codes.  It's a one-apple-per-box case also, and would be
better as Code than as Identifier.



>>Does anyone disagree with any of the above representation types? Thanks in
>>advance.

I think I agree mostly with your deductions.




>>Kenneth Sall
>>SiloSmashers
>>XML Specialist
>>GSA IAE Program Management Office
>>U.S. General Services Administration
>>1 Crystal Park, Mail Stop IAA
>>2011 Crystal Drive, Suite 911
>>Arlington, VA 22202
>>Phone: 703.872.8589
>>Cell: 301-672-3269
>>Fax: 703.872.8598
>>
>>
>>The President's Management Agenda:
>>"Implementation of E-Government is important in making Government more
>>responsive and cost-effective."
>>http://www.whitehouse.gov/omb/egov/
>>(Embedded image moved to file: pic20899.jpg)




Best Regards,
Chin Chee-Kai
SoftML
Tel: +65-6820-2979
Fax: +65-6743-7875
Email: cheekai@SoftML.Net
http://SoftML.Net/



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