Life cycle of a Class

Introduction

A Class has eternal validity. The concept of "Smartphone" existed since the Big Bang, it only has been discovered recently. Yet, a Class is not always relevant in a particular context.

In order to find a way to describe the "life cycle" of a (Part 2) Class that Class has to be modeled in a particular way using the following rationale:

• We start with the declaration of a Class, as described in Declaring an object ;
• For each information element about that Class we use a template ;
• In that template the information actually is attributed to a class-of-temporal-part of the declared Class;
• This means that the information applies to a temporal part of members of that declared Class;
• In case that information is no longer applicable, the template (which is also a Class) is deprecated.  

As an example the following template graph:

Although Class (1) is pointed at as the possessor type, in fact its class-of-temporal-part Class (6) is the possessor type. But since hardly any software has temporal parts it was practical to use (1) as a kind of proxy. Only in case such a lowered template would be mapped to its lifted counterpart the Class (6) will be made the possessor type. Now it is implied. Semantically an instance of this template means that any member of ClassOfIndividual (6) has that Property with that value on that Scale, from EffectiveDate until DeprecationDate.

Here is a diagram that explains the relation between ClassOfTemporalWholePart and TemporalWholePart as defined in ISO 15926-2:

The design of PhysicalObject X is defined in a specialized ClassOfPhysicalObject CO_X (CO=ClassOf). From Jan. 6th 2018 till May 14th 2018 X is required to have a size of 2 inches, and from May 14th 2018 onwards a size of 3 inches. Since those class-of-temporal-part Classes are hidden inside the templates their valEffectiveDate and valDeprecationDate are depending on those dates of the templates. Note that ClassOfPhysicalObject has many specializations as can be seen here.

Timeline

If these many different Classes are declared to be classOf(temporal)Part of one "Ur"-Class (see http://en.wiktionary.org/wiki/ur-), with an absolute minimum of criteria for membership, that Ur-Class can be used as a collector ('handle' or 'anchor') of all information that has been added, replaced and deleted since that Ur-Class became effective. (that UrClass is a kind of "ClassOfWholeLifeIndividual", which doesn't exist in Part 2).

Each class template has an annotation property:   meta:valEffectiveDate "2011-03-27T13:18:00Z"^^xsd:dateTime .

To the signature of each template about a Class its Ur-Class is added, conceptually similar to the addition of the temporal whole to templates for individuals. An exception to this rule is a case where a class-of- temporal-part Class has been declared. This is then the anchor of all its information.

Starting with the thesis that the memberschip of a Part 2 Class is the sum of itself (Part 2: "A class may be a member of another class or itself.") and of all its "classOfPart" Classes, we can visualize this in the following diagram, where we show a timeline, and where:

• the first heavy-lined block represents the UrClass with its typing and label;
• each other colored block represents a template instance;
• the red blocks represent deprecated templates .