Re: Repository Information Model v0.1

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

Len,

Thanks for the very detailed comments. Some responses below. Others in separate
message threads to follow for discussion. The separate threads will be:

1. Terminoligy alignement
2. Managed Object model
3. Association model
4. Classification model

On with the inline comments.

Len Gallagher wrote:

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

There is a brief description of RS on line 99. I will add a small section on RS in
overview.

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

This is the main issue you have raised here and in the meeting. It is an important
one to get agreement on. I will start a discussion topic (topic 2) on this so we
can address it as a team.

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

Related issue as above. Handled in discussion

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

Related issue as above. Handled in discussion

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

Related issue as above. Handled in discussion

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

terminology alignement will be a topic (topic 1) for separate discussion.

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

Associations will be a topic (topic 3) for separate discussion.

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

See above

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

See above

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

See above. BTW I used UML as the basis for associations represenations. All
diagrams in docs are UML diagrams.

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

Classification will be a separate discussion topic (topic 4). As I said I am using
OASIS classification verbatim (missing link not withstanding). However, I felt that
there was room for improvement but I though OASIS had a good start and we could
refine later once we had traction. You should be pleased (assume that is already
the case) with my use of your work in this area. It is good work.

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

Related to terminolgy issue (topic 1). However, I will say that my tactic was to
read all relevant specs I could find use as many ideas from whatever sources that
made sense as is, if an idea/terminology needed tweeking to make it more self
describing, I did so (e.g. RegStatus to registryStatus). I also used camel notation
as is the dominant UML and Java standard for naming classes and variable. Classes
start with upper case while variable and attributes start with lower case. This is
pretty standard stuff. So I do not  agree with changing description to Description
for example.

I explicitly did not intend to use either ISO 11179 or OASIS lock-stock and barrel.
If I did then what is the point. Why not just adopt those specs so we can all focus
on other things. That said I used several OASIS terminologies (e.g. globalName.
WHich you seem to imply should be AssignedURN. Hey, I dont even like the concept
but I used it verbatim from OASIS. What am I missing.

While I value your opinion and experience, I feel that there is some trend in your
feedback to encourage me to be doing things just like OASIS. I do not feel OK with
that for the reasons I indicated above.

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

Topic 3 for discussion


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

Topic 3 for discussion.
Added association with objects in other registries in issues list. This is an
important suggestion. Noted.

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

I will add to mapping table thanks.

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

Topic 3 for discussion

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

The list is a superset of OASIS. Nothing from OASIS was dropped AFAIK. Again you
should be pleased.

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

Let me know which one team prefers.

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

The relationship is indirect as I tried to explain. WIll do a better job when we do
the improvement over your excellent work. Sorry for any miscommunication.
(classification is Topic 4)

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

Topic 4

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

Send me a better representation even if it is a fax of a handrawn image. My fax is
in my sig. I will consider any example help from all the team. Whatever helps get
the concept across.

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

This is aligned and based on work done in BB/CC see reference 9. I was just the
messenger. FWIW I agree ith it as a core basis. If you have other suggestions send
them in and I will raise with BB/CC in my alignment meetings with them.

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

This belongs in RS spec not RIF spec. It is planned in RS post Tokyo.

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

This is an area where my past experience can help make our RR have strong
differntiators over other RR work. This is out of scope for Tokyo. However, I would
very excited to discuss a detailed proposal post Tokyo.

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

Done.

>
>
> Whew!

Double Phew!

Thanks again for the hard work you have put into these comments. We are lucky to
have you and your firect experience in this as an asset to the team.


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

--
Regards,
Farrukh

begin:vcard 
n:Najmi;Farrukh 
tel;fax:781-442-1610
tel;work:781-442-0703
x-mozilla-html:TRUE
url:www.sun.com
org:Sun Microsystems;Java Software
adr:;;1 Network Drive, MS BUR02-302;Burlington;MA;01803-0902;USA
version:2.1
email;internet:najmi@east.sun.com
fn:Farrukh S. Najmi
end:vcard