Dear MMT member,
I seek your comments/approval for the following:
In order to find a way to describe the "life cycle" of a (Part 2) Class we have to model that Class in a particular way. My rationale for that is:
- Any change to the information related to a Class may constitute a change in the "criteria for membership", so in fact a change to another Class.
- Classes are eternal and unlimited in number, so the best we can do is put on record when a particular template instance about a Class was created.
- When we have a design class, e.g. for P-101, we may see more than one hundred templates related to that Class, and all were made at different date-times, each with their own UUID. But what we mean is still that P-101 class.
- In case of changes there will be templates that are contradicting each other, but cannot be deleted (because classes are eternal).
My proposal is:
- If we declare these many different Classes to be subclasses of one "Ur"-Class (see http://en.wiktionary.org/wiki/ur-) with an absolute minimum of criteria for membership, we can use that Ur-Class as a collector of all information that has been added, replaced and deleted since we started the record of that Ur-Class.
- Each template has an annotation property that is the same as the record_created attribute of Thing.
- To the signature of each template about a Class we add its Ur-Class, conceptually similar to the addition of the hasTemporalWhole to templates for temporal parts. For example:
- At times, dictated by the business needs, we can "take stock" and determine what information (= which templates) is considered to be valid at that point in time.
- The composition of an OIM (Object Information Model) is a matter of choice, using SPARQL, in that one could be interested in all information or in a selection, such as only the "process data".
- But in any case conflicting information shall be avoided, as will be defined in Part 10. For example two different values for the design pressure.