Harmonization of Oasis and ebXML RegRep

[Len Gallagher <LGallagher@nist.gov>]

To: Oasis and ebXML RegRep groups

On Septemeber 18 this year Farrukh Najmi submitted a proposal to ebXML
RegRep for an information model to define the logical structures of an
ebXML registry/repository. He borrowed a number of concepts from the Oasis
registry information model with an intent to extend it to capture the fact
that ebXML was also planning to be the repository for some (or all) of the
ebXML registered objects.

At 01:32 PM 9/18/00 , Farrukh Najmi wrote:
>After doing due diligence and studying the ISO 11179 and OASIS
>information models as well as the UDDI specs, here is a first stab at
>the ebXML Repository Information Model (attached).

I'm a big fan of the purpose and structure of the proposed ebXML document,
but had some comments on the representation of Oasis concepts. So -
attached is a 1-page PDF diagram that uses UML constructs to try to
harmonize the Oasis and ebXML concepts. I feel relatively good about it and
hope that exposure to both groups will flesh out any deficiencies. My goal
is that it would eventually replace Figure 4 in the proposed ebXML base
document.

I have no strong feelings about the UML Class and Atribute names, or in the
role names of any associations among classes, but using the names presented
in the attached UML diagram, I have the following explanations:

1) The terms Registry Item, Related Data, Alternate Name, Association,
Classification, LevelValuePair, Alternate Description, Package,
Classification Scheme, Classification Level, Classification Item, and
Registered Object all come from the Oasis specification and are defined in
that specification. That specification has not yet undergone a public
review, so the names and terminology are not cast in concrete.

2) The terms Party Profile, Business Process, Trading Partner (TP)
Agreement, and Core Component come from other ebXML specifications. Those
specifications are also under intense development, so these names and the
structures and relationships they represent, are also not cast in concrete.

3) The RR_ManagedObject class is just a placeholder for scoping object
identifiers. I make an important assumption that the RR_ManagedObject class
holds only local object identifiers. I assume that a remote implementation
of the ebXML specification would own and manage its own objects, thereby
giving local autonomy to each implementation.  I assume that both local and
remote registry/repositiories conform to the ebXML specifications and that
the only interaction among them is via Registry Services, defined in a
separate document.  In particular, I'm assuming that an object identifier
in one conforming registry/repository is meaningless to any other
registry/repository.  Thus I'm assuming that a registry may have to keep
track of the Uniform Resource Names (URNs) used by other registries to
identify their registered objects or registry items. That's one of the
purposes of the Alternate Name class! This class could also be used to map
remote object identifiers to local object identifiers if that should prove
desirable.

4) I'll use lower case names to refer to an instance of a Class with the
capitalized name. For example, a registered object is an instance of the
Registered Object class, and a business process is an instance of the
Business Process class.

5) Each registered object maps to exactly one registry item. The registry
item contains the metadata for that registered object.

6) A registry item may or may not map to a local registered object.
Instead, it may map to a registered object or registry item in some remote
registry/repository, or it may map to a registered object that has since
been withdrawn.  Thus the Content association from Registry Item to
Registered Object is 0..1 instead of 1..1.

7) This high-level UML diagram does not attempt to capture the rules for
how a registry item maps to a remote registered object.  It could be via a
URL that locates the object itself, or it could be by using a URN that
identifies a remote registry item that then maps to the remote registered
object, or both.

8) The Related Data class is the same concept as the External Object class
defined in the current ebXML proposal. It gives a name and a URL for
something related to a registry item, but not owned or managed by any
registry/repository. 

9) The Registry Package class makes explicit the Oasis notion of a package.
Logically, a registry package is a set of pointers to registry items.
Also, logically, a registry package is a registered object and thus has its
own metadata as something separate from the registry package itself. A
package may represent a hierarchical structure since it is OK for a package
to have another package as one of its elements.

10) A classification scheme is a complete definition of a classification
hierarchy, including names and descriptions for each item in the hierarchy
and possible names and description of the purpose for each level in the
hierarchy.  The Oasis definition of classification scheme does not yet
allow the construction of new classification schemes from existing ones.
That's an opportunity that can be pursued by the classification scheme
group. The important thing is that classification schemes are registered
objects, and thus have their own metadata.

11) A classification is the identification of a single branch down a
classification scheme hierarchy. Each classification consists of one or
more level-value pairs to identify the path down that branch. 

12) A registry item may be classified by an arbitrary number of
classification schemes. The only requirement is that each classification
must reference a classification scheme that is a registered object in some
conforming registry/repository.  The SchemeURN association maps a
classification to a registry item in the local registry/repository, and
that registry item points to a classification scheme that is a registered
object in some conforming registry repository - not necessarily the local
one! This means that classification schemes can be owned and maintained by
one registry and then referenced by many registries.

13) The Alternate Description class supports internationalization by
allowing the Description of a registry item to be done in an arbitrary
number of languages. It is intended that each instance be a direct
translation into some human readable language of the primary description of
a registry item, which is an attribute in the Registry Item class.

14) It is likely that Core Components will be the building blocks for party
profiles, business processes, and trading partner agreements.  If the core
components are registered, then the "uses" assocations from, say Business
Process to Core Component can be captured by instances of the Association
class in the diagram.  The advantage is that the Association class can
represent many different kinds of associations between registered objects,
yet the registry interface remains static. Similarly, if a trading partner
agreement references a set of business processes, it would be sufficient
for that trading partner agreement to reference a registry package that
identifies each of those business processes.  I think that much of the
effort of ebXML RegRep will be on how to populate the static registry
structures when someone submits a registered object that is one of the many
different supported types. For example, the XML of a trading partner
agreement may have to be parsed to identify the referenced business
processes so that the appropriate association instances can be created.

15) Note that in the diagram, each association instance of the Association
class is hard wired to a single registry item as the GivenItem, and is only
loosely coupled to another potential registry item called the
AssociatedItem.  This is because the associated item may not be in the
local registry. It is OK for an association to reference a remote
registered object or registry item by using a globally unique URN for that
external object. Maybe ebXML can improve on the Oasis definition to allow
references to remote object identifiers, if known.  Another approach might
be to require that the associated item reference a local registry item and
then allow that local registry item to reference a remote object, as it
already can.  There are pros and cons of each approach. This can all be
worked out in discussions.

16) Note that a registry is also responsible for keeping track of the life
cycle of registry items, including any additions or modifications to its
metadata.  The ebXML information model has not yet considered this
responsibility, but the attached UML diagram is consistent with the Oasis
approach for meeting this requirement,
cf ftp://xsun.sdct.itl.nist.gov/regrep/OasisModel.pdf and
   ftp://xsun.sdct.itl.nist.gov/regrep/OasisNewXML.pdf

Regards,
Len Gallagher

ebxmlUML.pdf

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