RE: [regrep] Pre-defined Association Types: Issues and Proposal

["Breininger, Kathryn R" <kathryn.r.breininger@boeing.com>]

Len, 
One of the reasons for having reciprocal relationships (contains, contained
by) is so that the metadata for each object reflects the appropriate
relationship.  For example, if I create a relationship for item abc that
says "supersedes xyz", then a reciprocal relationship must be created
(preferably automatically) on xyz that says "superseded by abc".  If I as a
user than search and retrieve the record for xyz, I see the metadata for xyz
and I know immediately that it has been superseded by abc.  If you delete
the pairs, you miss the concept of creating the reciprocals for the
relationships.  I feel this needs to be obvious in the specs, so that it
doesn't get missed in implementations...

-----Original Message-----
From: Len Gallagher [mailto:LGallagher@nist.gov]
Sent: Tuesday, October 23, 2001 12:02 PM
To: OASIS ebXML Registry
Subject: [regrep] Pre-defined Association Types: Issues and Proposal



Registry TC,

Section 9.1.2.1, "Pre-defined Association Types", of ebRIM v1.1, lines 
950-958, defines 15 association labels that can be used by clients as the 
"associationType" attribute of an Association instance.

Many of these labels are "paired" as relationships, one that makes sense 
when going from "sourceObject" to "targetObject" and a second that makes 
sense when going from "targetObject" to "sourceObject".  Examples are:

   Contains
   ContainedBy

   Supersedes
   SupersededBy

   Uses
   UsedBy

   Replaces
   ReplacedBy

For some time many of us have agreed that we shouldn't necessarily define 
these relationships going both ways, because that would imply that there 
are two Association instances in the Registry for just one piece of 
information. Instead, we should define the semantics of these relationships 
from the point of view of the "owner" of the Association instance. For 
example, I think it's clear that the "owner" of the Replaces/ReplacedBy 
associations should be the owner of the object that gets replaced! It 
wouldn't be right for owner B to register a new object and say that it 
replaces an object owned by A; only A should have the right to say that his 
object is replaced by some other object.

Suppose we agree that the Association instance is "owned" by the owner of 
the "sourceObject" in the association. Then we can draw the following 
conclusions:

* The "Replaces" association type should be deleted in favor of a single 
"ReplacedBy" association type with semantics: "the object identified by the 
sourceObject attribute is replaced by the object identified by the 
targetObject attribute".

* The "UsedBy" association type should be deleted in favor of a single 
"Uses" association type with semantics: "the object identified by the 
sourceObject attribute uses the object identified by the targetObject 
attribute".

* The "Supersedes" association type should be deleted in favor of a single 
"SupersededBy" association type with semantics: "the object identified by 
the sourceObject attribute is superseded by the object identified by the 
targetObject attribute".

The intended semantics of the Contains/ContainedBy pair is not so clear. If 
I construct a new classification scheme that consists of a subset of the 
nodes of an existing classification scheme, it would make sense to say that 
the new scheme is contained by the old scheme, whereas if I construct a new 
classification scheme that is the union of nodes from existing 
classification schemes it would make sense to say the new scheme contains 
the old schemes. I think we need a more explicit definition of what we mean 
by contains! Then it will be easier to decide if one element of this pair 
should be deleted in favor of the other.

NOTE: We don't lose any functionality for querying the registry by deleting 
one of the elements of these pairs. For example, if we want to find out how 
popular my core component is I don't have to have a "UsedBy" association; 
instead, I could query the Registry to find all core components that are 
the sourceObject in a "Uses" association where my core component is the 
targetObject.


PROPOSAL

Modify the table of Section 9.1.2.1 of ebRIM v1.1, as follows:

1) Delete the row that corresponds to "Supersedes".

2) Delete the row that corresponds to "Replaces".

3) Delete the row that corresponds to "UsedBy".

4) Consider deleting both rows "Contains" and "ContainedBy", unless we can 
come up with a clearer definition of what they mean. Then just delete one 
item of the pair.

5) Review the semantics of each of the other definitions in this table to 
ensure that their intended semantics is clearly articulated. For example if 
I say that an XML document is an "InstanceOf" an XML DTD, does that mean 
the document "validates to" the DTD?

6) Consider deleting "ExternallyIdentifies" from this table because the 
ExternalIdentifier class already has a "registryObject" attribute that 
captures this association. We don't need to repeat this information as an 
Association instance.

7) Add text to Section 9.1, "Class Association", to make it clear that the 
"submitting organization" of an Association instance must be the same as 
the "submitting organization" of the object referenced by the sourceObject 
attribute, or have privileges granted by that owner.

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


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>