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

[Matthew MacKenzie <matt@xmlglobal.com>]

Len,

I agree with your proposal.  UUIDs are clumsy for a human to work with.


Matthew MacKenzie
XML Global Technologies, Inc.


-----Original Message-----
From: Len Gallagher [mailto:LGallagher@nist.gov] 
Sent: 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>