Re: Proposal to resolve info model issues

[Len Gallagher <LGallagher@nist.gov>]

At 12:12 PM 12/5/00 , you wrote:
>
>
>"Nieman, Scott" wrote:
>
>> 1) I am somewhat troubled by Associations and Classification not inheriting
>> from ManagedObject.  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.  It is an IntrinsicObject
>> too, since associations are critical to the nature of a registry (if I am
>> intrepreting this correctly).
>
>I too would like to make the Association  be a sub-class of
>IntrisicObject (which is a ManagedObject). Len are you OK with making this
>change?

I think it would be substantial overkill to require that associations have
versioning information kept for them. Even to allow it, but not require it,
would add considerable complexity to the specification. In my mind that
additional complexity would violate the 80-20 rule paraphrased as "don't
increase the complexity by 80% just to gain 20% in functionality". I think
the added functionality would be down around 2%.


>> 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.
>
>Note since Versionable has been factored out as a separate interface, we can
>make anything
>versionable. Should these classes implement the Versionable interface?

No -for the same reason as above.

>> 2) I am happy with modeling the concepts of extrinsic and intrinsic, versus
>> debating whether we are modeling the repository. I believe there is no
>> benefit adding a class for the ACTUAL content in a repository, since the
>> metadata ABOUT the content is more than sufficient and should give me a
>> "handle" to the actual object when I need it (to download, to parse, etc).
>> I believe a classification is an extention of the metadata, further
>> describing the ManagedObject.
>
>I agree. I believe Len does too. Len chime in if I am accidently 
>misrepresenting
>your thoughts.

I agree that it is "possible" to specify a Registry Information Model
without having a separate class for "managed object content". I just don't
understand why we'd want to do that when it's so simple to represent the
class (call it "RegisteredObject" in the figure, and then say that
instances of that class are only available through registry services, or
through the URL provided in the metadata.


>I believe, Len and I have some residual difference in thinking on 
>Classification
>scheme support. Though I
>believe we are naturally close because the current Classification scheme 
>support
>is based on the work
>done by Len for OASIS Registry.

As a result of our discussions on Monday, I'm less concerned about treating
each ClassificationNode as a registered object than I was previously. Some
users may want to do that.  The Oasis model needs to be extended to allow
one classification scheme to be defined in terms of another -- then a
person could define each node as a classification scheme and build them up
into a tree. But I still object to requiring that it be done that way.

Note: Allowing definition of a new classification scheme that simply
references an existing classification scheme as its hierarchy would solve
the "context" issue that people were concerned about in Tokyo.  We could
have a geography classification scheme G, and reference it from two new
classification schemes L and M, where L is the geographic location of a
company profile and M is the geographic market area of a company profile.


>BTW What do folks think of renaming Object to Identifiable? The idea is to
>factor out behaviour such
>as Identifiable Versionable etc. as separate classes so that behaviour can be
>added at any level. The Identifiable
>class would still have the GUID attribute as its only attribute. This may
>partially mitigate Scott H's concern about Object.
>
>Team please note that I am really trying to incorporate the best ideas
from all
>of us but without adding delay and without
>compromising what IMHO is good design. We need to get through this IM stuff
>soon. Thansk for your help.


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