[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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 **************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC