[regrep] ExternalLink Type proposal

[Len Gallagher <LGallagher@nist.gov>]

Registry TC,

In ebRIM we have an ExternalLink class that is intended to describe 
persistent instances of links from a registered object to non-registered 
objects. If the link targets were registered objects we could use the 
Association class to identify these links. But by assuming that some link 
targets will not be registered, we have to have some mechanism to capture 
them. The ExternalLink class is this mechanism.

At present, this class has only one attribute beyond those defined for 
every object instance; it is called the "externalURI" attribute. The intent 
is that the URI is really a URL that will "locate" the target object. The 
inherited "name" attribute can be used as a label for the underlying URL.

In past Registry email exchanges some of us have argued that we need a 
standard way to classify ExternalLink instances, e.g. 
GraphicRepresentation, Example, WhitePaper, SupportingDocumentation, 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 ExternalLink class, call it 
"extLinkType" or some other appropriate attribute name. The underlying 
assumption is that some "responsible organization" (RO) will have 
enumerated a list of external link types that are appropriate as 
classifications of target objects consisting of non-registered supporting 
data related to the "repository items" under consideration.

PROPOSAL

Make the following additions to ebRIM v1.1

1) In Section 6.9.1, Attribute Summary for ExternalLink, add a new row to 
the table with the following values:
    Attribute: extLinkType
    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.9.x, titled "Attribute extLinkType", with the 
following text:

"The extLinkType attribute provides a way for clients to classify the 
target objects of the URL's they provide for the externalURI 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 extLink 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
**************************************************************