Re: Proposal to resolve info model issues

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

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


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

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

Nothing has changed in the new picture Vis a Vis Classification scheme support.
A scheme is
defined by a structured tree of ClassificationNodes where the root
ClassificationNode represents the scheme.
A Classification instance is the specialized form of Association between a
ManagedObject and a ClassificationNode.

So if you liked the Information Model (IM) 0.41 classification scheme support
then nothing has changed.

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.

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.

>
>
> Regards,
>
> Scott
>
>
> -----Original Message-----
> From: Farrukh Najmi - JavaSoft East [mailto:Farrukh.Najmi@East.Sun.COM]
> Sent: Monday, December 04, 2000 12:10 PM
> To: ebxml-regrep@lists.ebxml.org
> Subject: Proposal to resolve info model issues
>
> 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:
>
> 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.
> -major and mindor version are now in Versionable
> -ManagedObject has registryStatus, description and submission
> -ExtrinsicObject have url, name, type and mimeType
> -IntrinsicObject has no attributes identified so far
>
> 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

--
Regards,
Farrukh