[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [regrep] Pre-defined Association Types: Issues and Proposal
Len,
I'm not sure that you addressed Kathryn's specific question, which if I am
interpreting correctly is a question regarding the UI rather than the specs.
My follow-up to Kathryn is to ask, What will the user see? Suppose I am a
Registry user sitting at a PC, searching the ebXML Registry. I pull up a
record for an asset (Registry Object?). On this record I expect to find all
available information regarding this object, whether it's a DTD or a
Service. The way I understand your response is that the user may have to
enter a specific query (B.getSourceRegistryEntries(SupersededBy)) to find
out this information, ex post facto. I'm thinking the user may not know
that this search is even a possibility without text on the asset record
explaining such. This is process-heavy. What about a simple hyperlink on
the record display which says "Relationships," wherein upon clicking, the
user is shown a page of relationships that asset possesses. The data does
not have to be redundant; it can be referred/retrieved by the method you
suggest. I haven't heard much in this committee regarding UIs.
Graphical explanation attached; you may have to expand the image to 100% to
be able to read it.
Nicholas
-----Original Message-----
From: Len Gallagher [mailto:LGallagher@nist.gov]
Sent: Tuesday, October 23, 2001 2:50 PM
To: OASIS ebXML Registry
Subject: RE: [regrep] Pre-defined Association Types: Issues and Proposal
Kathryn,
I understand your requirement, but I think it is best satisfied by
something other than holding two Association instances for one piece of
information. Suppose (A SupersededBy B) is an association instance. This
instance is metadata for both A and B. We don't need a superflous (B
Supersedes A).
With new methods proposed for RegistryEntry in a recent proposal to this
list
cf http://lists.oasis-open.org/archives/regrep/200110/pdf00003.pdf
I can use A.getTargetRegistryEntries(SupersededBy) to get the collection of
B's that supersede A, and I can use
B.getSourceRegistryEntries(SupersededBy) to get the collection of A's that
are superseded by B. So, in your example, xyz can use either of these
methods to "immediately" answer whichever question is most relevant, i.e.
things that supersede "xyz" or things that "xyz" supersedes.
I think having two separate methods is what makes this functionality
obvious in the specs. If we need to emphasize this functionality even more,
then we can add an example to show how both types of questions can be
answered in a straight-forward way.
-- Len
At 03:24 PM 10/23/01, Breininger, Kathryn R wrote:
>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>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
**************************************************************
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC
