Re: Repository Information Model v0.1

[Len Gallagher <LGallagher@nist.gov>]

ebXML RegRep,

Here are some comments on v0.1 of the ebXML RegRep Information Model
specification distributed by Farrukh Najmi on Sept 18, 2000.  My colleague,
Lisa Carnahan, has not yet seen these, so they may or may not be considered
as NIST comments!  

Note:  I'm available for todays conference call, but someone will have to
let me know how to call in -- my telephone is 301-975-3251.

COMMENTS

1) It is good to separate out the Information Model as a separate document
from all of the requirements document(s), the Business Domain model, the
Registry Services specification, and the Program Interface specification.
It stands well on its own, with appropriate references to these other
specifications.

2) I like the overall organization of the document - it separates out
important concepts for presentation in separate sections.  In particular
each of the following sections deserve the special attention they are given:

   Managed Object  (will suggest a name change below)
   Associations of Managed Objects (comments below)
   Classification of Managed Objects (comments below)
   Managed Object Administration (appropriate to defer for now)
   Query of Managed Objects (comments below)

3) In my own mind I like to make a clear distinction between Queries and
other service Requests.  This is because a Query expects something to come
back, and a good portion of the query input is telling the system what
you'd like to get back and how it should be filtered, etc. A non-query
Request on the other hand, asks the Registry to do something.  The only
response expected is a success message or a list of error codes. I'd
suggest a separate section to talk about non-query Requests, i.e. Registry
Services.  This new section would be an overview of basic Registry
Services, focusing only on semantics, not syntax.  It would allow multiple
Registry Services specifications to povide different syntax styles to
communicate with the registry using the common semantics of this section,
e.g. PL API's, MOF, SQL, simple pre-defined XML DTD's, etc.

4) In Section 3, I'm having some difficulty with the treatment of nearly
everything as a Managed Object. Clearly, everything the information model
talks about is an object managed by the Registry/Repository, but not
everything has the attributes that are specified for Managed Objects.
Figure 4 says that things like Associations, Classifications,
ClassificationLevels, etc., are all subclasses of ManagedObject, but
clearly not every instance of one of these items has all of the atrtributes
specified for Managed Objects in Section 3.2.  I think we need to scrap the
notion of Managed Object as being too broad.  A better notion is Registered
Object.  Then we could say that every instance of a class in the UML model
is a managed object, but not every managed object is a registered object.

5) I'd prefer to make a further distinction between Registered Object and
an item in the Registry. Normally, every item in the registry would point
to a registered object - but there are exceptions!  A registered object may
be withdrawn, but there still is an item in the registry explaining what it
was.  Other applications may be pointing to a registry item and we want
that pointer to make sense, even if the registered object itself is
withdrawn.  The registry item would still have metadata, giving the status
of the registered object as "withdrawn" and the effective date of the
withdrawal. Even after an item is replaced, deprecated, or withdrawn, a
user could ask "does my registered DTD point to any registered objects that
have since been modified, enhanced, or withdrawn?".

6) I think the distinction between registered object and registry item can
be clarified by doing something analogous to what OASIS does.  I.e. a
registry item is an instance of the RegistryItem class defined in the UML
information model, and a registered object is an instance of some virtual
Repository class defined elsewhere. The only access to the Repository class
is through Registry Services. In my subsequent comments, I'll use the terms
"registered object" and "registry item" with this meaning. I'll also assume
that there's been a global replacement in the specification of "Registry
Item" for "Managed Object", of "registry item" for "managed object", and in
Section 2.3 of "registry item" for "object".  I believe all of this is
consistent with the basic definition in Section 2.3 of managed object as an
instance of metadata, not the content of a registered object.

7) In Figure 1, page 6, redo the diagram to emphasize the distinction
between the following terms: registered object, registry item in this
registry, registry item in some other registry, external object not in any
registry.

8) With the above clarifications, I'm OK with the content of Section 2.3.1.

9) With the above clarifications, I'm OK with the content of Section 2.3.2,
although I'd prefer a term for these objects as something other than
"External Object".  How about "Related Data".  Note that there's no
requirement that these things even have a persistent object identifier,
just a Name and a URL is sufficient.

10) One could clarify Section 2.4 based on the above distinctions.  A
registry item and a registered object could share the same name, only the
context will make clear whether that name is referencing a registry item or
a registered object.  Only registry items can enter into associations.

11) In Section 2.5, I think we'll get into less trouble in the future if we
say that an association is between registry items only. A possible
relationship among registry items and other managed objects is possible,
but we won't call them associations!  In particular, the relationship
between registry items and related data items, or between registry items
and classifications, will not be called associations in this model.

12) With the above clarifications, I'm OK with the content of Section 2.6.

13) In Figure 2, call the relationship from RegistryItem to Classification
something other than an Association.

14) In Figure 2, is it clear that an Association can have attributes?  I'd
prefer that an Association be represented as a UML Class, with two
different one-to-many UML Relationships from RegistryItem to Association.
I prefer this because I think it satisfies a MOF restriction to not define
many-to-many relationships.  Then the UML diagram could be queried by OMG
Meta Object Facility (MOF) methods.

15) I've got the following problems with Figure 4.
  - Association is not a subtype of RegistryItem.
  - ClassificationLevel is not a subtype of RegistryItem.
  - ClassificationItem is not a subtype of RegistryItem.
  - Classification is not a subtype of RegistryItem.
  - SubmittingOrganization, REgistrationAuthoprity, and
ResponsibleOrganization, are not subtypes of Organization.  Instead they
are roles played by an organization instance in some other relationship.

16) I'm OK with the attributes for RegistryItem in Section 3.2 as a
starting point, but think ebXML will want to add more registry-specific
attributes similar to what OASIS does. In particular, the following maps
the proposed ebXML attribute names to OASIS attribute names:

            id  -->  RAitemId
           uri  -->  ObjectLocation
          type  -->  DefnSource, PrimaryClass, SubClass
          name  -->  CommonName
    globalName  -->  AssignedURN
   description  -->  Description
      mimetype  -->  MimeType
  majorVersion  -->  partially to Version
  minorVersion  -->  partially to Version
registryStatus  -->  RegStatus

17) In Section 4, modify the second sentence (lines 237-238) to restrict
Association to a relationship among registry items.

18) I'm OK with Figure 5, since Party and TPA are subclasses of RegistryItem.

19) In the table of Section 4.1, modify the Description of "to" to allow
references to registry items in an external registry (this is why one needs
global visible names), but prohibit references to other objects.

20) The attributes of an ebXML Association differ from those of an OASIS
Association, but the differences are reconcilable.  In particular we get
the following mapping:

          from  -->  the related registry item, i.e. RAitemId of GivenItem.
            to  -->  AssocItemURN (and if local the local AssocItemId)
          type  -->  GivenItemRole
     fromLabel  -->  Derivable from GivenItemRole
       toLabel  -->  Derivable from GivenItemRole
 bidirectional  -->  every association is assumed to be bidirectional

21) I think Section 4.2 needs lots of discussion to agree on a standard
list of built-in association types, with very tight definitions to preckude
overlap and possible ambiguity. For example, if a registered ProfileDoc has
a ProfileDTD as its schema, is the association "instanceOf" or "uses".

22) Agree on a standard spelling of "supersedes" vs "supercedes". Both are
correct, but my Webster Collegiate prefers the first spelling!

23) In Section 5, I have some difficulty with Figure 6, because it implies
that there is a hard relationship between leaf nodes of the tree hierarchy
and RegistryItem.  This is not true in general. Instead, any such
relationship is only derivable as the result of a query that returns all
registry items that have a classification matching a branch of the hierarchy.

24) Figure 7 seems to stress the wrong relationships, and is missing some
others.  There should be an ISA relationship from ClassificationScheme to
RegistryItem since every ClassificationScheme hierarchy is a registered
object, the relationship from RegistryItem to Classification should not be
labeled Association, and there should be a one-to-many dependency
relationship from ClassificationScheme to ClasssificationItem.  The
relationship between ClassificationItem and ClassificationLevel is really
only secondary, since it can always be derived from the ClassificationItem
hierarchy (represented by the "parent" relationship on ClassificationItem).

25) I'm OK with Section 5.1, assuming "managed object" --> "registered object".

26) I'm lukewarm on Section 5.2 because it implies that a
ClassificationLevel drives a classification tree.  Rather, its the other
way around; a classification tree implies a number of levels, and
ClassificationLevel just gives the definer an opportunity to name and
describe the levels if they want to.  Otherwise the levels get derived or
default names.

27) I think Section 5.4 gets Classification wrong.  I think it suffices to
say that a "classification of a registry item" identifies a path through a
previously defined classification tree. However, it may take multiple
"classification" instances to determine a "classification of a registry
item".  I'm lukewarm about using Figure 6 as an example because of the
reservations expressed above.

28) I'm dubious about some of the classifications mentioned in the table of
Section 5.5, but that's a minor problem.  We'll get more complete built-in
classification schemes over time.

29) I'm OK with deferring on Section 5.6, but later it should contain
discussion of the services for defining a new classification scheme or
adding or deleting nodes from an existing classification scheme.

30) Section 7.1.2 implies that registered objects can be queried by their
content. This is true ONLY IF their content can be represented via Registry
structures, i.e. classifications and associations.  I don't expect that
we'll ever be able to query the content of registered objects in general,
unless they are pulled into the registry information model like
Classification Schemes and Packages are in OASIS.  For some, I suggest we
drop the terminology "and Content" from the title of this section and "as
well as content" from the 2nd sentence.

31) In Section 7.2 re Classification Based Query Support
  - I'm OK with item 1 provided that "managed objects" is replaced with
"registry items and/or registered objects". The query whould have to
distinguish what is wanted.
  - I don't understand the intent of item 2!  
  - I'm OK with item 3, but some people may prefer that it's sufficient to
just return the XML representation of the classification tree.  Also keep
in mind that the portion of the tree under a given node might be very
large, e.g. Library of Congress classification scheme nodes under History.

32) In Appendix B, add the mappings identified in points 16 and 20 above to
the table under the ThisSpec and OASIS columns.

Whew!

-- Len



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).
>
>Repository Information Model v0.1
**************************************************************
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
**************************************************************