Re: Proposal to resolve info model issues

[Len Gallagher <LGallagher@nist.gov>]

All,

Farrukh and I talked for a long time Monday on the telephone, and I truly
believe there was more agreement than disagreement.  However, even
accepting names that I'm very uncomfortable with (e.g. ManagedObject as
metadata for some object) I'm still not able to see my way through all
parts of the figure that Farrukh distributed.

See in-line comments below.

-- Len


At 01:10 PM 12/4/00 , you wrote:
>
>Hi Team,
>
>Len and I have been working to get our ideas to fit together. Here is the our
>current thinking on the chanhes needed on the info model. Please see attached
>GIF file for reference:
>
>Based on Friday's discussion we had identified the need to model two types of
>Registry Content (as meta data). Note names were given today:

The main point here is that registry packages (called Package in the
figure) and classification schemes (called ClassificationNode in the
figure) are "special" kinds of registry objects. They are treated in a
special way because some registry services depend on their structure and
content. They have metadata just like any other "managed object content",
but in addition, they have "managed object content" that can be managed by
registry services.

>1. IntrinsicObject: Sub-class of ManagedObject that provides metadata on 
>content that is known to the Registry
>
>2. ExtrinsicObject: Sub-class of ManagedObject that provides metadata on 
>content that is not knownn intrinsicaly  to the Registry
>
>For dictionary definition of intrinsic and extrinsic see:
>
>	http://www.webster.com/cgi-bin/dictionary
>
>Note that not all Registry content known to Registry is derived from 
>IntrinsicObject
>since some have minimal metadata requirements and are derived from Object.
>
>Note that:
>
>-Object only has GUID attribute now.

OK -- everything in the Registry can be viewed as an object.

>-major and mindor version are now in Versionable

Only sort of OK -- I'd really prefer that Versionable be treated as an
attribute or property of something rather than a superclass of
ManagedObject. Given that it's treated as superclass, should it also be a
subclass of Object?

>-ManagedObject has registryStatus, description and submission

I'm assuming that "submission" is a typo here since it doesn't make any
sense to me that it be an attribute of ManagedObject.  I'd prefer that
"registryStatus" be "registrationStatus" because it's the "managed object
content" that's being registered, not the metadata for a "managed object
content".  We discussed 7 different levels of status: (submitted,
under-review, registered, superceded, replaced, deprecated, and withdrawn).
Each of these terms refers to the "managed object content" pointed to by
the URL, not the ManagedObject metadata.

>-ExtrinsicObject have url, name, type and mimeType

OK -- but why don't IntrinsicObject instances have these attributes too?

>-IntrinsicObject has no attributes identified so far

But "Package" and "ClassificationNode" are subtypes of IntrinsicObject.
Don't they have name, type, mimeType, and URL attributes too?

I'd be OK with this part of the figure if we allow "multiple inheritance"
and define "Package" and "ClassificationNode" to also be sub-classes of
"ExtrinsicType". 

But I'd prefer NOT to introduce multiple inheritance into what otherwise is
a very simple model. That's the main reason I'd prefer to treat
"ManagedObject" and "managed object content" as two different sub-classes
of Object, with every instance of "managed object content" associated with
one "or more" instances of ManagedObject. The "or more" case is relatively
rare, but arises when a "managed object content" gets replaced by a new
"managed object content"; then both the old ManagedObject and the new
ManagedObject would have URL attributes that point to the new "managed
object content", and the registryStatus attribute of the old ManagedObject
would indicate that the old "managed object content" has been "replaced".

>Please note that this is a joint proposal by Len and I and naturally we are
>in agreement on this. There may be some details to iron out but there is a
>strong desire and ability for us to work as a team and get through these
issues
>in teh next few week. 
>
>Lets all work hard to make the Jan 12 drop dead deadline for all our Release 1
>spec work to be submitted to QR so we can all be proud of what we have
>accomplished.
>
>--
>
>Regards,
>Len and Farrukh


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