Information Model Hierarchy: Take 3

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

Below is an inheritance diagram with my current thinking on the Information
Model. I relaize it is too big to print decently. It is a minor evolution
of what I posted previously on behalf on Len and I in previous weeks. The
remainder of this note decsribes the rationale behind my thought process
and is folowed by open issues. An important aspect is that this note defines
the rules I have used to lay out the classes and attributes in the model.

I humbly request that this straw dog proposal to be discussed in a phone conference that Scott may setup for this week.

Assumtions

• Information model is a meta model. It is only modeling meta-data and not actual content

What Is An Object

This section decsribes the criterea defined for determining whether some
data is an Object or not.
Instances of Object provide a meta-model for registry content:

• that has a unique identity
• that is likely to be stored independently in stable store rather than as part of some other meta data

Initially Object was modeled to only have the GUID attribute. Later I added
the description attribute after observing that all its sub-classes had
needs for something akin to a description (e.g. comment in Submission).
It seemed reasonable that all Objects have the option to be self describing.

What Is Not An Object

Note that Address and Contact are classes that are not Objects. An Address
or a Contact does not have its own independent existence (and consequently
no identity). They are simply wrapper classes whose purpose is to group
a set of attributes into a new reusable type. The new type may be used
in multiple classes in the model as needed.  They are always part
of some other Object (e.g. instances of Organization).

What Is a ManagedObject

This section decsribes the criterea defined for determining whether some
data is a ManagedObject or not. The confusion in this area arises from
the folowing distinctions being blurred:

1. Distinction between meta data about a submitted content (e.g. version ifno) and the submitted content itself. To resolve this confusion we simply state that ithe info model has no classes to model a submitted content (referred to in spec as managed object content). So we are always dealing with meta data about managed object content in teh model
2. Distinction between the typical submitted content (e.g. Party profiles, business process descriptions, schemas, etc) and other submitted content such as (Association, Classification, ClassificationNode, ExternalObject. To resolve this confusion we have added the classes ExtrinsicObject and IntrinsicObject as sub-classes of ManagedObject as will be described later.
3. The special nature of the Submission and Organization classes. These will be discussed later after the normal cases have been worked through so they dont muddle the issues prematurely.

What Is an ExtrinsicObject

An ExtrinsicObject Content provides a meta-model for content whose type
is not intrinsically known to the Registry. Since the Registry can contain
arbitrary content without intrinsic knowledge about that content, ExtrinsicObjects
require special meta data attributes to provide some knowledge about the
object (e.g. mime type). Examples include Party profiles, business process
descriptions, schemas, etc.

What Is an IntrinsicObject

An IntrinsicObject  provides a meta-model for content whose type is
known to the Registry. These types are well known and in fact defined by
the registry specifictions. Examples include Association, Classification,
ClassificationNode, ExternalObject, Organization and Package..

Characteristrics of ManagedObject

Some characteristrics of ManagedObject follow. Instances of ManagedObject:

• are used to represent both types of  registry content (intrinsic and extrinsic)
• are submitted to the registry by a Submitting Organization (SO)
• are always associated with an SO
• have their lifecycle managed by the Registry (approve, deprecate, remove etc.)
• are traceable to a specific Submission
• are able to be assigned user friendly names

What Is Versionable

Any class or interface in the model that is required to support teh ability
to create and maintain multiple versions is Versionable. The Versionable
interface has been factored out of ManagedObject to give us some freedom
to decide what classes are Versionable or not. Currently only ExtrinsicObjects
are Versionable. It is an open issue whether IntrinsicObjects also need
to be Versionable. I feel they should have the option. I believe Len disgarees.
Not that any class or interface in teh model that implements the Versionable
interface in addition to other inheritance links is not suffering from
evils of multiple inheritence. Versionable is an interface not a class.
Inheriting from an interface simply enforces behaviour (method) conformance.

Deciding What Goes Under Which Class

Now that we have defined the rules for what is an Object etc., we can apply
these rulese as consistently as possible to determine which info model
classes get sub-classed from which base classes. There are some exceptions
that will be treated as exceptional cases.

• We place almost all Registry defined types under IntrinsicObject. These include Association, Classification, ClassificationNode, ExternalObject, Organization and Package
• We determine that Submission is an exceptional case because it is not submitted content but a log of an act of submission. Each Submission instance has a unique identity and independent lifecycle. As such it is derived from Object.

Issues

1. Should Versionable be implemented by ManagedObject instead of ExtrinsicObject. Alternatively should it be implemented by both ExtrinsicObject and IntrinsicObjects. My vote is to have it be implemented by ManagedObject. Gives the most flexibility.
2. Should ExternalObject be derived from Object. I feel better leaving it derived from IntrinsicObject. This follows the rules and is not an exception. It also gives most flexibility.

--
Respectfully,
Farrukh