Limits on ebRIM Generalizations

[Len Gallagher <LGallagher@nist.gov>]

On August 8, 2001, Lisa distributed to this list two GIF graphic files that 
showed the basis of a proposal to re-structure the design of RIM.

   http://lists.oasis-open.org/archives/regrep/200108/msg00002.html

On August 9, Farrukh distributed a textual summary of the proposed changes.

   http://lists.oasis-open.org/archives/regrep/200108/msg00006.html

Also on August 9, I distributed two separate emails giving my "spin" on the 
proposal in order for it to have my full support

   http://lists.oasis-open.org/archives/regrep/200108/msg00007.html
   http://lists.oasis-open.org/archives/regrep/200108/msg00009.html

The purpose of today's email is to propose some restrictions on the 
"generality" of RIM implied by the diagrams of the model. I'm comfortable 
with having a very general model that "allows" certain generalizations to 
be made in the future. I'm not comfortable with having all of those 
potential generalizations "required" of all conforming implementations.

The problem with having a model that is too general is that some very 
important concepts, i.e. those that deserve special attention, get buried 
in the generality. An example of an important concept that gets buried too 
deep in the current proposal is the notion that every registry entry should 
be submitted by a "submitting organization" (SO) and that the submitting 
organization becomes the "owner" both of the repository item submitted with 
the registry entry and of the metadata submitted with the registry entry. 
Thus there is a required single-valued association from RegistryEntry to 
Organization to identify the SO of that object. Another important concept 
accepted at the Vancouver ebXML meeting is the ISO 11179 notion of 
"responsible organization" (RO). Some registration authorities (RA) may 
want to require that every object submitted to the Registry have an 
identified RO (possibly different from the SO). The RO declaration could be 
represented by an optional single-valued association from RegistryEntry to 
Organization. Right now these two important concepts are buried under the 
general notion of a many-to-many mapping from RegistryEntry to 
Organizations labeled simply as "organizations". I believe that the graphic 
referenced above is too abstract in that the two separate associations from 
RegistryEntry to Organization are not sufficiently visible. In order to 
capture what we've previously agreed upon, it would be necessary to write 
rules saying:

   - For every RegistryEntry instance x, there is a required Association 
instance y,
     such that y.sourceObject=x and 
y.associationType='SubmittingOrganization'. Then
     we'd have to add "SubmittingOrganization" to the list of valid 
associationTypes.

   - If an SO wishes to identify an RO for a submitted registry item, then
     they must submit an Association instance y such that y.sourceObject=x and
     y.associationType='ResponsibleOrganization'. Also, we'd have to add
     "ResponsibleOrganization" to the list of valid associationTypes.

I would prefer that the model visualize the special single-valued 
associations from RegistryEntry to Organization as two separate 
single-valued arrows, one labeled "SubmittingOrganization" and one labeled 
"ResponsibleOrganization". Then we wouldn't have to write special rules 
like those above and we wouldn't have to add new values to the list of 
valid associationTypes. Additionally, we'd know that the associations are 
single-valued and we wouldn't have to write routines to potentially 
accept/prohibit multiple submitting organizations. Can you imagine the 
difficulty of writing security access rules if submitted objects could have 
multiple owners? Finally, the FilterQuery mechanism that we've adopted for 
RegistryServices (cf ebRS Section 8.2.2) already makes use of the 
visibility of SO's and RO's, already factors in their single-valuedness, 
and will not have to be modified to fit the more general model.

Discussion of Classification and Association

In my opinion, the Classification and Association classes in our model are 
more general than they need to be for a second version of our 
specification. I've already discussed above how the enforced generalization 
of Association to represent SO and RO information, instead of explicitly 
represented single-valued associations, is a burden to understanding of 
those concepts. I also think that the enforced generality of 
Classifications and Associations is a heavy burden on implementations. 
Enforcement of their complete generality would require support for concepts 
that are of marginal utility, e.g. adhoc associations from ExternalLinks to 
Contact.

I would like to propose a course of action that recognizes the value of 
having general structures to provide a framework for potential future 
expansion, while at the same time only requiring explicit support for the 
most useful subsets of those generalizations.

In my mind, the following restrictions on the generality of Classification 
and Association would make both understanding and implementation much easier:

  1) Treat Classification as a supertype with subtypes for each type of object
     that can be dynamically classified. Let Classification_RE be the subtype
     that allows for dynamic classification of RegistryEntry. Make 
Classification_RE
     more visible and require explicit support for it in Registry Services. 
Do not
     require support for dynamic classifications on other Registry objects, 
but
     design Registry Services so that subsequent extensions could be 
supported in an
     upward compatible way.

  2) Treat Association as a supertype with subtypes for each distinct pair 
of source
     and target object types supported by the model.
     - Let Association_RERE be the subtype that allows dynamic many-to-many
       associations from RegistryEntry to RegistryEntry.
     - Let HasExternalLinks be the subtype that allows dynamic one-to-many
       associations from RegistryEntry to ExternalLink.
     - Let HasExternalIdentifiers be the subtype that allows dynamic 
one-to-many
       associations from RegistryEntry to ExternalIdentifier.
     - Let HasContacts be the subtype that allows dynamic one-to-many 
associations
       from RegistryEntry to Contact.
     Make the most important subtypes highly visible in the model and 
require explicit
     support for them in Registry Services. Do not require support for other
     adhoc associations, but design Registry Services so that subsequent 
extensions
     could be supported in an upward compatible way.

Item #1 above requires support for dynamic classification of repository 
items submitted to the Registry, but it does not require support for 
dynamic classifications of supporting metadata submitted to help describe 
that repository item. NOTE: we do support static classifications of 
metadata, e.g. the associationType attribute for the Association class, 
where the static classifications are pre-specified. We could expand the 
static classifications that are supported by the model by adding additional 
attributes to some of the Registry objects, e.g. extLinkType could be added 
as an attribute of ExternalLink.

I believe that the above restrictions on the generality of Classification 
and Association would be of great benefit for presenting our model to other 
groups and for more clearly understanding and explaining our own Registry 
Services. Whenever we speak in terms of Classifications, we'd also make 
sure we know what type of Registry object is being classified. Whenever we 
speak in terms of Associations, we'd also make sure we know what type of 
Registry objects serve as the sourceObject and targetObject of the association.

This proposed reliance on specialized subtypes of Classification and 
Association was a driving force behind specification of the FilterQuery 
mechanism in Registry Services (cf ebRS Section 8.2). Each different kind 
of Association subtype was treated separately. For example, in the ebRIM 
binding for RegistryEntryQuery (ebRS SEction 8.2.2), the query treats 
associations from RegistryEntry to other Registry objects separately, i.e. 
SourceAssociation, TargetAssociation, ExternalLink, ExternalIdentifier, 
AuditableEvent, etc. I believe this makes for easier writing of the 
queries! It also makes for easier implementation of the queries in systems 
that leverage one-to-many mappings, e.g. nested XML representation of 
information. No explicit joins or join conditions are required. Instead, 
implicit joins among Registry objects follow naturally from the separately 
identified one-to-many associations.

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