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

[Farrukh Najmi <Farrukh.Najmi@Sun.COM>]

Len's observation is correct that we all mentally seem to be comfortable with the
notion of a URN associated with an object.

However, my mental model for a URN solution has been to relax the definition of id
attribute to say it is a URN that could either be a urn:uuid or any other unique
URN. This allows for keeping existing use of UUID as well as allowing use of other
more human friendly URNs such as the ones in the classification scheme examples.

The benifit of the above solution is that one existing attribute serves both
purposes. If the submitter wants a human friendly name they specify a URN that is
human friendly. Else they or the registry can provie a machine friendly id of the
form urn:uuid:....

The only restrictions is that the id attribute must be unique. UUID based URNs are
guarenteed to be unique based on the DCE 128 bit algorithm.

So to summarize, I like the idea of formally supporting URNs but I propose we not
introduce a new attribute and instead use the existing id attribute.

I am copying Nikola on this issue to solicit his opinion, as he is one of the most
knowledgeable person I know on this subject.

--
Regards,
Farrukh


Len Gallagher wrote:

> 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>



begin:vcard 
n:Najmi;Farrukh
tel;work:781-442-0703
x-mozilla-html:FALSE
url:www.sun.com
org:Sun Microsystems;Java Software
adr:;;1 Network Dr. MS BUR02-302;Burlington;MA;01803-0902;USA
version:2.1
email;internet:najmi@east.sun.com
fn:Farrukh Najmi
end:vcard