RE: Old Issue again: What is an "id"

["Munter, Joel D" <joel.d.munter@intel.com>]

In addition to Len's statement: 
"And -- there is no guarantee that different Registries won't use different
UUID's to identify ClassificationScheme metadata in those Registries that
may reference the same known classification scheme (e.g. UNSPSC, NAICS,
etc.)."

As each Registry or publisher is responsible for generating their own UUIDs,
is there any guarantee that the same UUID will not be used for two different
entities across ebXML Registries.  My real question is: Can UUID truly be
considered unique across all ebXML Registries? 

Joel

-----Original Message-----
From: Len Gallagher [mailto:LGallagher@nist.gov]
Sent: Tuesday, September 25, 2001 12:14 PM
To: regrep-query@lists.oasis-open.org
Subject: Old Issue again: What is an "id"



Query team,

I notice that all of the people, myself included, who are submitting 
examples for discussion are assuming that an "id" is in the form of a 
human-friendly URN. And we also all seem to be assuming that any such "id" 
is the same for each ClassificationScheme instance no matter what Registry 
it happens to reside in.

However, both of these assumptions are false!

Sections 6.2 and 6.3 of ebRIM, v1.1, require that an "id" be a 128-bit 
Universally Unique ID (UUID) generated in a specific format.

And -- there is no guarantee that different Registries won't use different 
UUID's to identify ClassificationScheme metadata in those Registries that 
may reference the same known classification scheme (e.g. UNSPSC, NAICS,
etc.).

I think we could address the problems and mis-communication we've been 
having if we agree that there's a crying need for human-friendly 
identifiers for common repository items, and there's a strong desire that 
all Registries use the same human-friendly identifier whenever possible.

I think we can address both concerns at the same time if we "require" a new 
attribute in some classes (especially Organization and RegistryEntry) to 
play this role. Call it the "URN" attribute to distinguish it from the "id" 
attribute. The "id" attribute could continue to be treated as the primary 
mechanism for representing associations among registry objects. However, on 
submission of new information to the Registry, or on queries to find 
things, we could "allow" the "URN" attribute to be used as a surrogate for 
the instances of whatever classes have it as a required attribute.

Consider two different Registries, each having a ClassificationScheme 
instance that references the 2001 version of the UN Standard Product and 
Services Classification (UNSPSC) system. Suppose these Registries were set 
up independently, so there is no guarantee that the "id's" of their 
ClassificationScheme instances are identical. We can't ask these Registries 
to change their fundamental "id's" for these ClassificationScheme 
instances, because that would cause too much havoc on their entire 
implementation.  But we could require that each Registry try to keep the 
"URN" attribute for those instances the same. They could do this with much 
less impact on their implementations, either by modifying that attribute 
with no side effects on maintained associations that use "id", or by 
superseding or replacing those entries with updated ones.

PROPOSAL:

1) Add "URN" as a new attribute to the Organization and RegistryEntry
classes.

2) Require that this attribute have a non-null value that satisfies the 
format of a Uniform Resource Name (URN) specified by IETF RFC 1241.

3) Require that the "URN" attribute is an "alternate key" (in addition to 
the "id" key) to uniquely identify an object in the local Registry.

4) Encourage Registries to make this URN value human-friendly!! Whenever 
appropriate, allow submitters to suggest the "URN" for a submitted object.

5) Encourage Registries to use the same URN value for known organizations 
and repository items. If Registries enter into formal agreements to share 
information, then "require" that all members of the federation migrate to 
the same "URN" for shared information.

5) Allow submissions of new Registry content to use "URN" as a surrogate 
"id" for a RegistryEntry or Organization instance. E.g., submission of a 
new Classification instance could reference the ClassificationScheme used 
for the classification by "URN" or by "id", whichever was most convenient, 
or both if they don't contradict one another.

6) Allow Registry Queries to query "URN" as they would any other attribute. 
But do NOT automatically assume that "id" attributes are the same as the 
URN attributes; instead, to access the "URN" attribute, the query must 
explicitly (or implicitly) link along an appropriate branch to reach the 
class having it as a required attribute.

I think implementation of this proposal would eliminate much of the 
mis-communication we've been having about the meaning of "id" and "name" 
attributes. I'd love to see some discussion.

-- Len



**************************************************************
Len Gallagher                             LGallagher@nist.gov
NIST                                      Work: 301-975-3251
Bldg 820  Room 562                        Home: 301-424-1928
Gaithersburg, MD 20899-8970 USA           Fax: 301-948-6213
**************************************************************


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>