re Scott #1 and #3: Proposal to resolve info model issues

[Len Gallagher <LGallagher@nist.gov>]

Some in-line comments below.

-- Len


At 11:32 AM 12/5/00 , Scott wrote:
>1) I am somewhat troubled by Associations and Classification not inheriting
>from ManagedObject.  

We could fix this by changing the name of "Object" to "ManagedObject", to
signify that a managed object is anything of interest to the Registry. Then
we could use a new name for the existing ManagedObject!  How about
RegistryEntry?

>for example, I use associations to create a package of
>ManagedObjects, and by removing an association (deprecate, or delete), a
>ManagedObject can be removed from a package, but is NOT removed from the
>Registry.  Therefore I am managing associations.  

Yes - every instance in the Registry Information Model is managed by the
Registry. We haven't yet discussed how Packages get created and managed.
But I'd prefer that packages get created by a separate registry service
rather than just by creating a new relationship that says X contains Y as a
member. This would be meaningless unless X were already a registered
package instance.

>It is an IntrinsicObject
>too, since associations are critical to the nature of a registry (if I am
>intrepreting this correctly).

I agree that associations are intrinsic to the Registry Information Model.
That's why there's a class in the model named Association.

>I have had concerns about the Contact, Organization, and Address classes not
>inheriting from ManagedObject too, since there are subject to versioning ,
>but I am less concerned about those classes as I am about associations.  the
>begging question is when I update address information, do I replace it or
>version it?  ditto with contacts etc.

Of course the model could go either way on this. My preference would be
that we preserve versioning information about some things, but not about
other things. For me, Contact, Organization, and Address do not need
versioning information kept for them. And I'd argue that associations don't
either! In Scott's example involving package above, the package instance
would have versioning information kept for it, but each association that
says "x Contains y" need not be versioned. 

>3) I perceive there is still a conceptual difference between Classification
>Scheme and Classification.  To me, a classification scheme is special
>ManagedObject that consists of classification nodes, and Classification is a
>special link between a ManagedObject and a classification scheme (e.g.,
>linked to a specific node within the scheme).  

I agree with this statement entirely. That's why I've been arguing that
ClassificationScheme and ClassificationNode both need to be modeled in the
Registry Information Model. Then it's much easier to say that a
Classification is an extension of some metadata instance that links that
metadata instance to a specific node of the classification scheme, and
indirectly classifies the "managed object content" pointed to by the URL
attribute of the metadata instance.

>If we are trying to equate
>the two concepts, we need to explicitly state how classification
>accomplishes the representation of a scheme.  I strongly believe as you try
>to clarify that, that you will see my point in issue #1.

I agree that Figure 5 in version 0.41 of the Registry Information Model
specification "appears" to be trying to do that. I've been confused by that
figure since the very beginning and would love to see it changed. But I
don't see what this has to do with issue #1 above.


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