[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Limits on ebRIM Generalizations
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 **************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC