Life Cycle of a Class

[OnnoPaap]

The proposed Revision of Class model can be viewed here:
http://www.15926.org/publications/gener ... /index.htm

Summary:

This model is used to solve the problem of class revision.

The former solution for this was the template SuccessionOfInvolvementInActivity in ISO 15926-7 (the old and the new class are involved in a revision activity). This solution was seen as cumbersome as it was not clear what the "current" classes are that classify a possible individual without querying out all the successions. So we are looking for a more straightforward method.

How this method works:

The whole-life individual and its ur-class remain unchanged. The classification relationships that give the whole-life individual its aspects, through transitive inheritance of its temporal parts, are gathered in a set of EnumeratedSetOfClass. This EnumeratedSetOfClass is also related to the ur-class (semantically correct) so it can be found in one query. The EnumeratedSetOfClass is marked with the create date property (of Thing) giving the set a date. Old sets can be queried the same way, providing for history.

From the given example:

The "mySphere T-101" is made of 316 SS (the light-grey part). If the material of construction changes in the design (314 SS):

• The temporal part of the ArrangedIndividual will be terminated (given an end date).
• A new ClassOfArrangedIndividual instace is created, modeled as "314 SS" being a subClass of the ur-class of T-101.
• A new EnumeratedSetOfClass is created, given a date, which collects the other class instances of the temporal parts of "mySphere T-101" and the new temporal part.

[HansTeijgeler]

Hi,

I have added the possibility to deprecate any subclasses of the UrClass that are no longer applicable.
See http://www.15926.org/publications/gener ... /index.htm

Regards,
Hans

[vvagr]

One question about generic class model example (2nd picture).

There is a greyed out sample template SpecializationByCompoundType in the lower right corner. Its hasUrClass role goes to the 'handle' OIM class. It is a mistake? Shouldn't it go to the proper UR-Class of T-101?

The 'handle' OIM class is not obviously necessary for me. Do you intend its ontological meaning to be the intersection of all EnumeratedSetOfClass members? But in this case you have to add some kind of universal restriction, current meaning is that each member of the 'handle' class is classified by at least one member of the EnumeratedSetOfClass class. But it is simpler to state intersection directly.

But its technical role is doubtful anyway. All possible queries can use EnumeratedSetOfClass class.

[HansTeijgeler]

Hi Victor,

You are right! Oh my...
I have corrected the graph.
Thanks!

Regards,
Hans

[vvagr]

For a template DefiningAClassVariant role name hasOIMPosessor is not a good one. This class is not a "posessor" of OIM, rather an opposite is true. I'll propose the simple name hasSubclass.

Also a template SpecializationFromUrClass is required, with two roles hasUrClass and hasSubclass.

It'll be nice to have a ClassOfSpecialization "SPECIALIZATION FROM UR-CLASS" also, to be able to lift templates without losing important information about the kind of relationship between ur-class and its subclasses. Although some popular OWL realisation will force people to omit this classification anyway.

[HansTeijgeler]

Hi Victor,

Since the OIM is about an Object, I think 'hasObject' is somewhat more informative. OK?

I take it that the reason behind those two new templates is to allow for retroactive addition of them to existing class templates. Is that a correct assumption?

Regards,
Hans

[vvagr]

Hans,

hasObject is better, but not perfect. Ur-class is an object of all OIMs. Subclasses we discuss are included in OIMs (EnumeratedSets) in various combinations, it is possible to imagine OIM1 consisting of Class1, Class2, Class3, and OIM2 consisting of Class1, Class3 and Class4. Are you ready to call any of them OIM's objects?

I've suggested one new template and one new class.

The reason for addition of SpecializationFromUrClass template is simple: when I'm changing the property for an ur-class, I'm not always ready to declare a specific OIM - thus I don't have enough data to use DefiningAClassVariant. An OIM can be built later and automatically, based on time meta-data of templates created.

Or am I misunderstanding the DefiningAClassVariant diagram? I've just noticed that 5 is a ClassOfClassification. But I thought it'd be Classification, as 3 in CompositionOfOIM?

The class of specialization "SPECIALIZATION FROM UR-CLASS" is required to lift all templates with ur-class and its subclass in a signature. It should be used to classify specializations: for example, Specialization 4 in DefiningAClassVariant.

[HansTeijgeler]

Hi Victor,

Consider an OIM as a view, at a given date-time, on information about the UrClass. That view can be all-in, or all-in minus deprecated template instances, or just "process data", or "data sheet data", etc.

The subclass that is pointed at with the "hasObject" property is the handle to such an OIM.

The reason for addition of SpecializationFromUrClass template is simple: when I'm changing the property for an ur-class, I'm not always ready to declare a specific OIM - thus I don't have enough data to use DefiningAClassVariant. An OIM can be built later and automatically, based on time meta-data of templates created.

[HT] You can change any information about an UrClass at any time, and you don't have to create a new (all-in-minus-deprecated) OIM at that time. So you don't have to create a new instance of the DefiningAClassVariant template. The template for the new information has the specialization of the UrClass already included.

Or am I misunderstanding the DefiningAClassVariant diagram? I've just noticed that 5 is a ClassOfClassification. But I thought it'd be Classification, as 3 in CompositionOfOIM?

[HT] The EnumeratedSetOfClass is a subtype of ClassofClassOfIndividual, hence ClassOfClassification.

The class of specialization "SPECIALIZATION FROM UR-CLASS" is required to lift all templates with ur-class and its subclass in a signature. It should be used to classify specializations: for example, Specialization 4 in DefiningAClassVariant.

[HT] You lost me. Are you looking at the same template? See http://www.15926.org/templatespecs/CL-DEFN-05.xml
The only use for a template with that name would be to enable folks who have an installed base of class templates without the UrClass concept to add that retroactively.

Regards,
Hans

[vvagr]

The template for the new information has the specialization of the UrClass already included.

Yes - if we add hasUrClass role to all templates. If not - we can use this new template together with old-style templates. "The only use for a template with that name would be to enable folks who have an installed base of class templates without the UrClass concept to add that retroactively." -- exactly.

[HT] The EnumeratedSetOfClass is a subtype of ClassofClassOfIndividual, hence ClassOfClassification.

Isn't the handle class a member of OIM EnumeratedSetOfClass ?

About the class_of_relationship specialization "SPECIALIZATION FROM UR-CLASS" - yes, it is required to classify relationship 4 in the template http://www.15926.org/templatespecs/CL-DEFN-05.xml

[HansTeijgeler]

Isn't the handle class a member of OIM EnumeratedSetOfClass ?

[HT] No.

About the class_of_relationship specialization "SPECIALIZATION FROM UR-CLASS" - yes, it is required to classify relationship 4 in the template http://www.15926.org/templatespecs/CL-DEFN-05.xml

[HT] Classify with what?