The last part at Class level in the row is discussed here, the
Product Model
The manufacturer has class models for his products. Similar to the Requirements Class the Product Model is a specialization of the Reference Ontology, be it with other information content.
Customers or industry groups, like IOGP, define their information requirements related to the equipment they purchase. For example, CFIHOS is defining Equipment Class Properties, which will tell the manufacturer what the kind of information shall be that the owner/operator receives (often via an EPC contractor) about the products they purchase from that manufacturer.
A difference with the Engineering Ontology is that the Product Model has to accomodate various types, options, extras, sizes, materials, etc of the products. That is a bit more complex from a modeling point of view. I'll take a part of the Plant Life-cycle Model to illustrate that:
I'll walk you through this:
- The 'Ur' (or 'anchor') Class of a Product is an instance of the ClassOfInanimatePhysicalObject [61]; it has, by definition, no class-of-temporal-whole;
- It has, at any point in time, an instance of ClassOfFunctionalObject [60] as a superclass, that defines the functional aspects of the product;
- It also has, at any point in time, an instance of ClassOfInanimatePhysicalObject [62] as a class-of-temporal-part, that inherites the functional data of [60] and adds the physical product information;
- That [62] is the placeholder of all information that is standard for the product;
- In this diagram three additional options, [63], [64], and [65], are shown as subclasses of the Product Class [62], so, for example, [63] has next to its own data (defining the option 1) also the standard data, as inherited from [62];
- Now comes the selection: each option that has been selected is made a member of EnumeratedSetOfClass [66];
- Now we make use of a rather exotic Relationship, called UnionOfSetOfClass, that, in this example, creates the union of the information contents of the members of [66], i.e. [63] and [65], thus filtering out the double contents of [612].
Is this an ontology? Probably so, in its own peculiar way.
As already referred, the 15926.blog website contains a topic Catalog Options that shows in
practice how such a Product Options Selector, often referred to as Configurator, works.
The full code of the BMW Configurator example is included there.
It would be nice when the manufacturers that serve the process industries would come with their Configurators. It would greatly help the engineers.