The idea is that we design a plant at Class level, see for example http://www.15926.info/functional-vs-mat ... object.htm. That is, for this containment example, shown in the upper part of the diagram, using the template ClassOfContainmentDefinition (see http://15926.org/templatespecs/CL-LOCTN-01.xml). Mind you, that has nothing to do with the RDL, it is information that sits in your application, and is mapped to that template format.
The "signature" (list of roles) of that template is:
Code: Select all
1 hasUrClassOfLocator dm:ClassOfIndividual
2 hasClassOfLocator dm:ClassOfIndividual
3 hasUrClassOfLocated dm:ClassOfIndividual
4 hasClassOfLocated dm:ClassOfIndividual
5 hasDefined dm:ClassOfContainmentOfIndividual
6 hasCardinalityOfLocator dm:Cardinality
7 hasCardinalityOfLocated dm:Cardinality
As the name of role 5 indicates, this template defines the characteristics of that instance of ClassOfContainmentOfIndividual. As said, that has nothing to do with the RDL, because you define that relation between ClassOf_P101 and ClassOf_S349, and these aren't in the RDL either.
Much later, when you need to describe the actual plant (or plants in case more that one copy is being built), you use templates for individuals. The lower part of the diagram shows such a template for individuals.
Now, in that template you classify the instance of the ContainmentOfIndividual relationship between P101 and S349 with the (role 5) ClassOfContainmentOfIndividual that you created during design. By doing so, your template gets access to that design information, and with the proper software in place it can be checked whether or not the template about the real world is in line with the design.
The signature of the ContainmentOfAnIndividual template is (see http://15926.org/templatespecs/WI-LOCTN-01.xml) :
Code: Select all
1 hasContainer dm:PossibleIndividual
2 hasContained dm:PossibleIndividual
3 hasContainerType dm:ClassOfContainmentOfIndividual