Now we discuss Individuals, both in Design & Engineering as well as in the real world around us. These aren't ontologies but recordings of the state of an Individual at a given point in time.
This is where all the work on the previous ontologies and classes comes together. This can be illustrated by repeating the ISO-on-a page diagram with marked-up relationships:
The red lines are all rdf:type relations, and are all pointing at an object in a particular ontology, as discussed before.
Both 'anchor' Individuals are pointing to the Upper Ontology for Classes, to the applicable subtype of PossibleIndividual (here: InanimatePhysicalObject), along with the typings in blue telling that they are an instance of WholeLifeIndividual (= top of the temporal part meronomy), and an instance of either of NonActualIndividual (= inhabitant of an Imaginary World) or
ActualIndividual (= inhabitant of the Real World).
NonActualIndividual
The 'anchor' Tag P-101 is being declared as an instance of what we call its 'EssentialType' (something that will never change for that Tag), here PUMP, and subsequently a temporal part of it is typed with a class from the Reference Ontology (here CENTRIFUGAL PUMP, for example derived from its symbol on the P&ID).
Later, during Detailed Engineering, another temporal part is made an instance of an Asset Requirements Class (here CO-P-101-rev1) (later we will discuss the revisions of classes).
ActualIndividual
The 'anchor' Asset #12345 is being declared as an instance of what is its Essential Type, here CENTRIFUGAL PUMP (essential enough when it has been manufactured as such), and a temporal part as an instance of a manufacturer's class (actually of the class that has been defined in his quotation).
Implementation
The Tag is being implemented by the Asset, which is represented with an Implementation relationship (actually between temporal parts of both sides but that would clutter the diagram too much). That Implementation relationship is only valid once the Asset has actually been installed in the Functional Location of the Tag and is in an operational state.
IFF, and only if, the Asset fully complies with the applicable Asset Requirements Class, then that temporal part can be typed/classified with the latter.
The actual world of a process plant is represented on the righthand site of the Plant Life-cycle Model Graph. The actual physical objects have a string of temporal parts:
Possible Worlds
The fact that we make a distinction between a Tag and an Asset is because of the adoption of the Possible Worlds philosphy of David K. Lewis, as set forth in his treatise "On
the Plurality of Worlds". I suggest that you have a peek into the topic 'Possible
Worlds'.
It is important to remember that an Imaginary World and the Real World can't share anything, they are different universes but, by convention, with the same physical laws. They can be interrelated only by a relationship that Lewis called ''Counterpart'.
In most cases an Imaginary World is the Design World, but other imaginary worlds are there, for example the imaginary world of a planning. The objects in a Planning World have completion dates that are only valid in that world. Each updated planning creates a new Planning World, that reports completion dates as if that world was created at the dateTime of the last 'completion' in that planning.
An object in a Planning World has counterparts in the Design World and/or the Actual World.
Here is a simplified sketch. Note that planning is about Activities:
Wrapping it up
Here is another way to look at it, basically using the same logic.
and this one that shows the path from dm:Thing all the way down to an installed pump:
Templates
In the next lesson I will address the concept of Templates and Mapping.