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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-comment message

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


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


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 <tboyle@rosehill.net> 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









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


Powered by eList eXpress LLC