Re: [ubl-comment] UBL comments on ebXML Core Components TechnicalSpecification v1.8

[Todd Boyle <tboyle@rosehill.net>]

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
>