Classifying an individual

7 Dec. 2010, revised 9 Dec. 2010

Introduction

Individuals are, in their lifetime, being classified in increasing detail. Let us assume that we have an instance of FunctionalPhysicalObject.

When declaring the individual as an instance of FunctionalPhysicalObject, including its proper typing as an instance of WholeLifeIndividual and in most cases as an instance of ArrangedIndividual, we must classify it with a class that will apply during its entire life. When you come to think of that, you will find that there are not many aspects of an individual that fall in that category. Nowadays it is even not safe to classify a male person as such, because gender change is possible.

So, when the individual is a pump, stick to that class for the whole life individual, and do not classify it as a centrifugal pump, or as a stainless steel pump. That comes later, and will be attributed to temporal parts of that pump.

In case you would have classified the whole life individual as a centrifugal pump, and a design change makes it necessary to change that to a positive displacement pump, you will have to end the whole life individual and all its relationships, and declare a new one, and define its relationships again.

But if you have declared the individual as a pump, and declared a temporal part of that as a centrifugal pump, you end the existence of that temporal part and declare a new temporal part that is a positive displacement pump. Since all other aspects (relationships) are attributed to other temporal parts, nothing else has to be ended, except aspects that are affected by that classification change.

During the plant design we then learn that the centrifugal pump shall be of stainless steel. So we create a new temporal part of the individual and classify that with an instance of ClassOfCompound 'stainless steel'. And if, at a later date, we find that it shall be made of monel, we end the temporal part that is classified as stainless steel and create a new temporal part that is classified as being made of monel.

When we go out for quotations to vendors, we classify a temporal part of our individual with the class that is defined by the contents of the applicable specification. This is where the bucket stops for the functional physical object, except when the specification changes. Again, we end the temporal part that is classified with the class defined by previous version of the specification, and create a new temporal part that is classified with the class that is defined by the latest version.

The functional physical object is detailed over time, with temporal parts as placeholders

The above diagram gives cause for some observations:

  1. The fact that there is not one-only common ground for the ClassOfFunctionalObject and the ClassOfInanimatePhyscialObject is because Part 2 misses a ClassOfPrinciple, in this case CentrifugalHydrokineticPrinciple, defined as: "Principle whereby the fluid is accelerated through (an) impeller(s) and the increase in speed is converted into delivery head" (or something similar). In that case the diagram could look like shown below.
  2. Here the ultimate definition of both classes is done with a document. Defining the classes in a fully modeled way is a horrendous task, because stating that the pump is of stainless steel is not correct, only the wetted parts (need to define the assembly! ) are made of stainles steel. Unless the object is NOT and arranged individual, this fully modeled definition is a no-go if one wants to stick to the principles of ISO 15926. Each equipment or instrument item will prove to be as complex as a process unit.
  3. As a consequence the classification with stainless steel, as shown above, does not make much sense.
  4. In order to make the data of the specification computer-interpretable the document could be expressed in RDF/XML, based on an OWL schema.

The subclasses are created by specializing them by aspect