May I note that there is a difference between a proposed draft and
your characterization that the "UBL TC has recommended"? This topic
is still under discussion.
At Monday, 29 April 2002, Todd Boyle <> wrote:
>UBL TC has recommended that the Core Component Type and
>Representation Term (CCT and RT) "Identifier" be eliminated from
>the CCTS.
>
> If a code is used as a way of representing the value of something,
an
> identifier provides unambiguous identification of an object.
The two are
> not alternatives, they are complementary to each other.
>
> They can be confused because we often use codes to identify things.
> Country codes uniquely identify countries. But we can also use
strings
> of text (e.g. names such as URLs) and unbounded sets of values
(e..g.
> unique numbers such as phone numbers, SSID, tax file numbers,
etc..) as
> identifiers. The value of an identifier tells you which thing
in a set
> of similar things you're talking about.
>
> In addition, codes are not always identifiers. It depends on
the context
> of their use. For example, within the object class Country,
the value
> ‘AU’ is the unique identification of Australia. But, when used
in other
> contexts, such as Shipping Location, ‘AU’ will not be unique
– it is
> still a code, but it is not an identifier of the Shipping Location.
>
> We have this mix of relationships because a code is a representation,
> whereas ‘identification’ is actually a property, a function
of the use
> an object.
>
> Proposal 9
>
> The use of Identifier as a Representation Term (and Core Component
Type
> if they still exist –[Proposal 3]) should be discontinued.
>
> The property of ‘Identifier’ may exist as a Property Term. The
> representation of this may be as a Code, Text, Number, or any other
> Representation Term.
>
>Regardless of what can be said, about the matter, there *are*
>identification schemes in the universe both global (DUNS, EAN/UCC
etc..)
>and within internal systems (customer and vendor lists, product
>lists, accounts etc.) These are utterly ubiquitous. How do you
>propose to reference them? With a mere character string, apparently.
>This would imply that every community somehow establish and
>maintain common frames of reference out-of-band, or, that only
>markets already having frames of reference can use ebXML?
>
>I think it would be very helpful if the UBL TC explain more precisely
>why the Identifier is not an RT or CCT. If "Code" is a semantic
>primitive, referencing a string or number in a scheme someplace,
>then why isn't "Identifier" a semantic primitive, referencing a
>collection of elements such as a party or product record?
>
>(Certainly, I hope UBL TC is not just making the suggestion
>because XML parsers or some other tool, can't easily resolve
>Identifiers... because, tools should follow ontology not the
>reverse.)
>
>You have made the assertion that " ‘identification’ is actually a
>property, a function of the use an object." I don't get it. IMO,
>an identifier seldom is a property (attribute of something else).
>
>An Identifier refers to a discrete, real *thing* in every scenario
>that really matters. SMEs need a way to point to product records,
>party records and a plethora of other Identification Schemes
>without the approval of registration authorities, vendors or
>their supply chain masters. The whole reason I'm here working
>in UN/CEFACT is to avoid being trapped in all those other
>registries and identification schemes, already waitin for us
>in Redmond, or at DUNs, Verisign and fifty other expensive,
>controlled lists who all charge excessive rents.
>
>I think I can guess what you guys in UBL will start using for
>product, party and other identifiers. You will start creating
>elements like "PartyDUNSnumber". Please tell me I'm
>wrong! :-)
>
>Private monopolies like DUNS and EAN/UCC etc. would
>generally charge as much rent as the market would bear,
>and governments and corporations would increasingly
>snoop, regulate, tax, etc. these global monolithic things.
>You'll never find any tunes or warez or IP telephone
>schemes in there. And SMEs would not be able to
>sell a whole lot of other cheap things either.
>
>If Identifiers with URIs disappear from the CCTS, then,
>perhaps CODE should also disappears because it is exactly
>the same kind of animal, having such extensive behavior and
>context built into it.
>
>Alternatively, CODE might perhaps, be expanded to include
>a data resolver URI and schema URI, so that users can use it
>as we planned to use Identifier Type (pointing to identification
>schemes.)
>
>Finally, Identifier Type should NOT be discontinued, without
>at same time, providing some alternative method for referencing
>both global and internal identification schemes.
>
>Perhaps the Core Components team should seek help from
>the RM and RegRep teams, for this whole Code/Identifier
>thing. It is an automation artifact as much as business
>semantic artifact,
>
>Respectfully
>TOdd Boyle
>
>At 11:11 PM 4/28/02, Tim McGrath wrote:
>>In response to the UN/CEFACT's Electronic Business Transition ad-hoc
>>Working Group's (eBTWG) call for comments on their ebXML Core Components
>>Technical Specification (see http://www.ebtwg.org/news/040402.html),
we
>>are attempting to prepare a consolidated response from UBL members
based
>>on our recent experiences with implmenting some of the concepts
and rules
>>indentified.
>>
>>Please find attached the current working draft of this response.
If you
>>would like to contribute or comment on our comments, then please
do so
>>within the next 48 hours using this list. We plan to discuss these
>>responses at this week's NDR and LC subcommittee meetings. The
date for
>>submission to the eBTWG is Saturday May 4th.
>>
>>--
>>regards
>>tim mcgrath
>>fremantle western australia 6160
>>phone: +618 93352228 fax: +618 93352142
>>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>
---------------------------
Michael C. Rawlins
Rawlins EC Consulting
www.rawlinsecconsulting.com
