This topic deals with activity modeling. Activity models are used to describe processes and also human activities in and around a plant, such as maintenance.
The Ur-model is the old IDEF0 model:
This useful model is, however, too limited in expressivity. The activity model of ISO 15926 has enough expressivity for lifecycle information integration. In its basic form it looks like this:
Basic ISO 15926 Activity Model
The four relationships are:
In general the following applies:
ALGORITHM - A self-contained step-by-step set of operations to be performed.
BEHAVIO(U)R - A specific response of a certain organism to a specific stimulus or group of stimuli.
COMBINATORIAL LOGIC FUNCTION - A concept in which two or more input states define one or more output states, where the resulting state or states are related by defined rules that are independent of previous states. Each of the inputs and output(s) can attain either of two states: logic 0 (low) or logic 1 (high).
MATHEMATICAL FORMULA - A rule or principle, expressed in an equation or a set of instructions that solves a certain type of problems in a prescribed manner. In a formula, the same set of inputs always produces the same output(s).
METHOD - An established, habitual, logical, or prescribed practice or systematic process of achieving certain ends with accuracy and efficiency, usually in an ordered sequence of fixed steps.
PROCEDURE - An orderly, logical, or systematic set of instructions to be followed in solving a problem or accomplishing a task.
RULE - A statement that establishes a principle or standard, and serves as a norm for guiding or mandating action. Rules are commonly published as recommended practices that allow some discretion with their interpretation and use.
STRATEGY - A plan of action designed to achieve a long-term or overall aim.
First a bit of filosophy: The reason why Participation is a subtype of CompositionOfIndividual is that an Activity can be seen as the result of an interaction between the behaviours of the participating individuals. That is why Activity is in the role of 'whole' and each participating individual, with its relevant behaviour, in the role of 'part'.
The participation model at class level, in the form of the applicable template, is shown below:
An instance of ClassOfParticipation is defined in this template and made explicit by means of the signature role 'hasDefined'. This is a case where the relationship at class level has to be made explicit in order to define the relationship at individual level. The reason is that in above template the role in which is being participated is defined. Therefore the template at individual level is as follows:
In this case the Particpation relationship is classified with the ClassOfParticipation instance at class level. That tells that Stream N-83 participates in the Role of 'PUMPED' (that explicit role name can be fetched with a SPARQL query).
It is also possible to further specialize the template at class level in order to define your design. Then PUMPING is specialized to PUMPING STREAM CLASS CO_N-83 and the STREAM CLASS is specialized to STREAM CLASS CO_N-83. This is the normal procedure of defining your design. The Participation relationship at individual level is then classified with the instance of ClassOfParticipation in that design template.
Things can be involved in an Activity without participating in its, i.e. without their behaviour playing a role. A good example for that is the involvement by reference of rules and regulations, progress reports, supervision, etc.
The involvement-by-reference model at class level, in the form of the applicable template, is shown below:
An instance of ClassOfInvolvementByReference is defined in this template and made explicit by means of the signature role 'hasDefined'. This is a case where the relationship at class level has to be made explicit in order to define the relationship at individual level. The reason is that in above template the role in which is being involved-by-reference is defined. There are two templates at individual level (of the Activity), one for the involvement of an individual, and one for the involvement of a class:
In these cases the InvolvementByReference relationships are classified with the ClassOfInvolvementByReference instance at class level. That tells that, in the lower example, Welding Instruction 12345 is involved-by-reference in the Role of 'Instruction' in the welding of line RZ17801 (that explicit role name can be fetched with a SPARQL query).
An Activity can cause some Event, and that Event can be the beginning or the end of some Individual (bumping in a brick wall can cause the end of the driver). In short: cause and effect.
The models for ClassOfCauseOf(Event) and CauseOfEvent are not, like other releationship, similar.
The cause-of-event model at class level, in the form of the applicable templates, are shown below:
whereas for individuals these templates are:
Some things shall be noted here:
1) The relationship CauseOfEvent is uninformative, unless it is classified by either an instance of ClassOfCauseOfBeginningOf ClassOfIndividual or ClassOfCauseOfEndingOfClassOfIndividual;
2) These templates can only apply to instances of WholeLifeIndividual, since temporal parts thereof are not made explicit in the various template signatures, so we can't address them.
There are more templates with variations on the theme.
Recognition is somewhat problematic. That already starts with the definition of the word in the various dictionaries. We use here the following definition: "Recognition is the result of deductive observation of some information". That information is represented by a template instance. So we get the following template:
and for an individual:
Note that the relationship Recognition is uninformative, unless it is classified by either an instance of ClassOfRecognition, that is defined above.