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

[Len Gallagher <LGallagher@nist.gov>]

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.

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".


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!


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.


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.


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.


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. 


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. 

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.


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