[regrep] ExternalIdentifier Type proposal

[Len Gallagher <LGallagher@nist.gov>]

Registry TC,

In ebRIM we have an ExternalIdentifier class that is intended to describe 
persistent instances of alternate identifiers for the "repository item" 
described by a RegistryEntry. At present, this class has only one attribute 
beyond those defined for every object instance; it is called the "value" 
attribute. These values would represent the alternate identifiers for the 
given "repository item".

In past Registry email exchanges some of us have argued that we need a 
standard way to classify ExternalIdentifier instances, e.g. URN, UUID, 
GUID, SSN, EID, etc. Discussions have shown that we cannot re-use existing 
attributes for this purpose without breaking the existing semantics of 
those attributes.

I propose that we add one new attribute to the ExternalIdentifier class, 
call it "extIdType" or some other appropriate attribute name. The 
underlying assumption is that some "responsible organization" (RO) will 
have enumerated a list of external identifier types that are appropriate as 
labels of identifiers for the "repository items" under consideration.

PROPOSAL

Make the following additions to ebRIM v1.1

1) In Section 6.8.1, Attribute Summary for ExternalIdentifier, add a new 
row to the table with the following values:
    Attribute: extIdType
    Data Type: ShortName (or better CodeText from another proposal)
    Required:  Yes
    Default Value: none
    Specified By: Client
    Mutable: Yes

2) Add a new Section 6.8.x, titled "Attribute extIdType", with the 
following text:

"The extIdType attribute provides a way for clients to classify the values 
they provide as identifiers for the object identified by the registryObject 
attribute. The intent is that clients will choose a type pre-defined by 
some responsible organization to make sense in the context of the 
referenced registry object."


FOLLOW ON DISCUSSION

A criticism of this proposal is that there is no existing way to determine 
a single list of extId types that will make sense in the context of the 
referenced registry object. To solve this problem, I'm looking forward to a 
future requirement that every organization approved as a responsible 
organization (RO) provide a list of acceptable values for each of the 
following enumeration lists in our model: objectType, stability, status, 
associationType, extIdType, extLinkType, etc. These lists could be defined 
as "unique" codes in a classification scheme registered by that 
organization before they are approved to be a responsible organization. 
Each potential RO will also be required to register an RO_profile and link 
the RegistryEntry for that profile via Association instances to the 
RegistryEntry instances for the corresponding registered classification 
schemes. The associationType would identify the specific enumeration. Then, 
if a submitting organization (SO) names a responsible organization (RO) 
when they submit a new RegistryEntry instance, that organization will be 
linked to a single enumeration for each of the enumeration attributes in 
our model.

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