Re: Gallagher - Comments/Proposals #3,re: Figure 3: Object Class Hierarchy

[Farrukh Najmi <Farrukh.Najmi@east.sun.com>]

Len,

Thanks for the detailed feedback. I agree with several of your suggestions. See my
comments inline. Since there are several changes I am agreeing to, based on your
suggestions I ask that people speak up if they disagree with the changes.


Len Gallagher wrote:

> Gallagher - Comments/Proposals on Figure 3: Object Class Hierarchy
> See page 10 of the ebXML Registry & Repository specification,
> version 0.41, November 2000.
>
> 1) An Object, the root class in the hierarchy, is required to have
> attributes for GUID, URI, and Name. What is the purpose of requiring all of
> this information for an Address or a Submission? What is the URI and Name
> of the address "34 Elm St."? If I submit an object to be registered, what
> is the meaning of the Submission.Name as something distinct from
> ManagedObject.Name? What is the meaning of URI for an Organization - does
> it return metadata for that organization? Or is it the organization home
> page? Or does it just return the name and address of the Organization.
>
> Proposal:
>
> a) Only require URI and Name in places where they make sense, e.g. Managed
> Object. Let each Class have it's own set of required attributes.

Agreed. Will move URI and Name to ManagedObject. ExternalObject will need a URI and
description attribute added as well.

>

>
>
> b) Only require URI for ManagedObject -- that's the only class that
> requires a mandatory reference to the "managed object content". Then the
> attribute can have some meaning, such as the "location" of the "managed
> object content".

ManagedObject and ExternalObject will have URI.

>
>
> 2) An Association is a binary link from a ManagedObject to an Object. Why
> is it also a subtype of ManagedObject and thus required to have all of the
> attributes of a ManagedObject, including objectType, majorVersion,
> minorVersion, registryStatus, etc. If an object has a "Uses" association
> with 35 other objects, why does each association have to have versions and
> status?
>
> Proposal:
>
> Don't require that an Association be a subtype of ManagedObject. Instead,
> just let it be what it is - a named link between two other things, one of
> which is a ManagedObject instance. Thus an Association instance is
> dependent upon a ManagedObject instance and can be thought of as an
> attribute, or set of attributes, of that instance rather than a
> ManagedObject instance itself. It's not necessary to invent the 4 required
> attributes for ManagedObject as well as the 3 additional required
> attributes for Object!

Will change Association to be derived from Object instead of ManagedObject.

>
>
> 3) A package is a logical grouping of Managed objects (line 301). Why then
> is a Package a subtype of ManagedObject, which means that it is metadata
> about some "managed object content"? It IS a "managed object content" and
> thus should have a ManagedObject instance that points to it - not be a
> ManagedObject instance.

>
>
> Proposal:
>
> Don't require that Package be a subtype of ManagedObject - instead require
> that the Registry Services support packages by being able to create them,
> describe them via a ManagedObject instance, and retrieve them.

Will change Package to be derived from Object instead of ManagedObject.

>
>
> 4) A classification node is a specific node within a specific
> classification tree (lines409-410). Why then is a ClassificationNode a
> subtype of ManagedObject? It seems that a ClassificationNode instance is
> important in and of itself - it is an integral part of a specific
> classification tree -- not metadata for something else. Why is each node in
> a classification tree (there may be thousands - e.g.
> http://www.census.gov/epcd/naics/naicscod.txt ) required to have a URI,
> major and minor versions, and a registration status. Instead, it's the
> classification tree that should have these things -- not each node of the tree.

>

>
>
> Proposal:
>
> Don't require that each classification node be a managed object! Instead,
> re-introduce the notion of a classification tree as a "managed object
> content", with nodes as its content, and with each classification tree
> having a ManagedObject instance associated with it. Provide Registry
> Services to create a new classification tree, supply metadata for it, and
> define its constituent nodes.

Will change ClassificationNode to be derived from Object instead of ManagedObject.

>
>
> 5) A classification is a specialized association from a ManagedObject to a
> specific ClassificationNode in a classification tree (lines 419-421). Thus
> why is it necessary for a Classification instance to have 4 required
> Association attributes and 3 required Object attributes, when something
> like "NAICS 11114" to identify the NAICS classification tree and a node
> within that tree is sufficient.
>
> Proposal:
>
> Do not require that Classification be a subtype of ManagedObject. Instead,
> treat classification as an attribute of some ManagedObject instance. The
> attribute will identify a classification tree and a node within that tree.
> The user can then access the classification tree (presumably it is a
> registered "managed object content") to determine that 11114 means "Wheat
> Farming" as a subset of "Oilseed and Grain Farming" as a subset of "Crop
> Production" as a subset of "Agriculture, Forestry, Fishing and Hunting". We
> can visualize (NAICS 11114) as a classification attribute of FarmerJohn's
> Organization Profile; it could be represented as such in the Registry
> rather than as a ManagedObject instance.

This is already addressed when we change Association to be derived from Object
instead of ManagedObject.

>
>
> 6) PROPOSAL to Replace Figure 3
>
> Replace Figure 3 in the ebXML Registry & Repository, version 0.41, with
> Figure 1 "Registry and Repository Objects" (page 6) of the OASIS specification
>
>   ftp://xsun.sdct.itl.nist.gov/regrep/OasisRegrepSpec.pdf  (PDF 788KB)
>
> This action addresses comments 1,3, and 5 above, as well as parts of the
> other comments.

Changes will be made to figures to reflect the changes I have indicated as in this
message. Doing a lock-stock-and-barrel substitution is not improving our specs but
replacing them. This is something I cannot support.

>

>
>
> 7) PROPOSAL re: Classification, Association, and ExternalObject
>
> Let Classification, Association, and ExternalObject be treated as dependent
> classes of a ManagedObject class, as represented in Figure 3 "RegistryEntry
> with dependent classes" (page 11) of the OASIS specification. They are all
> part of the metadata for some "managed object content", not the complete
> metadata. Thus they should all be linked to a ManagedObject instance, not
> be ManagedObject instances themselves.

Already addressed. This is a repeat of your previous comments.

>
>
> This action addresses the remainder of the above comments except for how to
> deal with classification tree and Package. Those "special" registered
> objects can be handled as indicated in the following proposal.
>
> 8) PROPOSAL to Replace Figure 1 -- retain notion of Repository
>
> Re-introduce the notion of Repository being an optional component of a
> Registry/Repository implementation. Then ClassificationScheme and
> RegistryPackage can be treated as "managed object content", as they should
> be, each with its own metadata stored as a ManagedObject instance.  This
> can be captured by replacing Figure 1 in the ebXML Registry Information
> Model by Figure 2 "Registry/Repository Class Diagram" (page 7) of the OASIS
> specification.
>
> A "managed object content" stored in a Repository is still only accessible
> in one of two ways: 1) The URI given as an attribute of ManagedObject, or
> 2) a special Registry Service to return the "managed object content"
> instead of, or along with, a ManagedObject instance.

Changes will be made to figures to reflect the changes I have indicated as in this
message. Doing a lock-stock-and-barrel substitution is not improving our specs but
replacing them. This is something I cannot support.

>
>
> CONCLUSION
>
> The above actions would address all of my concerns about the direction of
> the ebXML Registry and Repository specification. We could then focus on the
> details of Registry Services.
>
> **************************************************************
> 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
> **************************************************************