Defining and using Classification and-or Libraries

The COINS standard has built in capabilities for setting up a classification and/or library of object types.

Historically this feature was added to facilitate a kind of project catalogue which should contain standard components/products/objects allocated for that specific project, like for example foundation pile, lamp post, etc. This original purpose is reflected by the class name CataloguePart. The catalogue principles that were captured in this class turned out to be much more general, which quite spontaneously resulted in the development of general purpose stand-alone classifications/libraries of object types.

Inhoud

01 Background and basic mechanism

The leading principle that underlie the class CataloguePart is derived from set theory. The instances of the class CataloguePart represent sets or types. The objects that refer to a particular instance of class CataloguePart are the elements of the set. Automatically those objects are assigned the set definition, i.e. property types, assigned property values and template relations. If instance B of class CataloguePart refers to instance A of class CataloguePart as its supertype (with property supertype) then B represents the subset of A and the elements of B per definition are also elements of A.

Set-theory
Set-theory

02 Defining CatalogueParts

The class CataloguePart has a property called supertype. This property is of the type CataloguePart and has a restriction of occurring zero or once (max 1). The meaning of the property supertype is that an instance of CataloguePart is a differentiation of the instance of CataloguePart the property supertype points to.

UML CataloguePart
UML CataloguePart

Example:
CataloguePart "Pile"
CataloguePart "Point Bearing Pile" with supertype CataloguePart "Pile"
CataloguePart "Cohesion Pile" with supertype CataloguePart "Pile"

UML CataloguePart supertype example
UML CataloguePart supertype example

03 CatalogueParts: from object types to items

This section explains the difference between a object type Point Bearing Pile and an item Point Bearing Pile 532832.

Object type Point Bearing Pile is the definition of the classification Point Bearing Pile and what properties a Point Bearing Pile can have. Item Point Bearing Pile 532832 is the instance of the classification Point Bearing Pile and has properties like a length of 10 meter, and material Wood. This item Point Bearing Pile 532832 can be ordered/bought from the catalog of a supplier. Point Bearing Pile 532832 is a specific kind of Point Bearing Pile. It has an item number, but it is not a tangible/touchable thing. The tangible/touchable things are FunctionFullfillers (see next paragraph).

The confusion part can be that in the COINS data model object type Point Bearing Pile and item Point Bearing Pile 532832 are both instances of CataloguePart. The property supertype of CataloguePart defines this behavior of differentiation.

Example:

PointBearingPile PointBearingPile532832 example
PointBearingPile PointBearingPile532832 example

04 Using CatalogueParts for FunctionFulfillers

This section will answer the question "How to link a CataloguePart to a FunctionFulfiller?".

The class FunctionFulfiller has a property contains. This property is of the class Amount and has no restriction of occurrence. The class Amount has a property cataloguePart. This property is of the class CataloguePart and has restriction of occurrence (exactly 1).

FunctionFulfiller Amount CataloguePart
FunctionFulfiller Amount CataloguePart

The class FunctionFulfiller has two subclasses: PhysicalObject and Space, so by the rules of inheritance the classes PhysicalObject and Space have the property contains, and can be linked via Amount to a CataloguePart.

Example: PhysicalObject "Piles of foundation of viaduct V435" is connected to CataloguePart "Point Bearing Pile" via Amount "A378-3232-323". This amount has a value of 100, which means that the PhysicalObject has 100 CatalogueParts.

framePhysicalObject Amount CataloguePart example

05 Adding simple properties to CatalogueParts

To the instance of class CataloguePart properties can be added. In the datamodel class CataloguePart has a property propertyValue, which points to class PropertyValue. Class PropertyValue has a property propertyType which points to class PropertyType.

UML CataloguePart PropertyValue PropertyType
UML CataloguePart PropertyValue PropertyType

Class PropertyValue has properties "name" and "value". The "name" represents the name of the property, and "value" represents the value of the property.

Class PropertyType has property valueDomain, which points to a ValueDomain (XsdFloat, XsdInt, XsdBoolean or XsdString). The value of property valueDomain represents how the property "value" of PropertyValue should be interpreted (as a float, integer, boolean or string). Class PropertyType has property unit, which is a string. The value of property unit represents what the unit is of the property "value" of PropertyValue.

Example: A property "height relative to ground" is added to instance "Point Bearing Pile" CataloguePart by creating instance "PV82110" of PropertyValue with name "height relative to ground". And creating "PT3892893" of PropertyType and linking "Point Bearing Pile" to "PV82110", and linking "PV82110" to "PT3892893".

CataloguePart PropertyValue PropertyType example
CataloguePart PropertyValue PropertyType example

06 Adding complex properties to CatalogueParts

To the instance of class CataloguePart properties can be added which don't contain a value but point to an instance of a class. For this functionality also class PropertyValue, PropertyType and ValueDomain are used, but for PropertyValue property "value" is NOT used, but property "complexValue" is used. Also for ValueDomain CbimCataloguePart, CbimParameter or CbimDocument must be used.

Property "complexValue" of PropertyValue is part of Reference Framework "Functional Specifying". ValueDomain CbimCataloguePart is part of Reference Framework "Functional Specifying". ValueDomain CbimParameter and CbimDocument are part of Reference Framework "Object Type Library".

UML PropertyValue complexValue Parameter
UML PropertyValue complexValue Parameter

Example: A property "material" is added to instance "Point Bearing Pile" CataloguePart by creating instance "PV82111" of PropertyValue with name "material". And creating "PT3892894" of PropertyType and linking "Point Bearing Pile" to "PV82111", and linking "PV82111" to "PT3892894". "PV82111" is linked to instance "P4444555" of Parameter with name "Wood".

UML PropertyValue complexValue Parameter example
UML PropertyValue complexValue Parameter example

07 Inheriting simple and complex properties via supertype

Some relationships in the COINS Standard are implicit, i.e. they can be derived from other relationships. The supertype relationship is such a relationship that implies other derivable relationships.

The underlying semantics of property supertype is the behaviour of inheritance, in this case inheritance of properties. If a CataloguePart "A” links to another CataloguePart “B” with property supertype, every PropertyValue of “B” is considered also a PropertyValue of “A”. This principle works recursively: if “B” itself has a property supertype with yet another CataloguePart "C” then every PropertyValue of “C” is considered PropertyValues of “B” but also of “A”.

Inherited PropertyValue example
Inherited PropertyValue example

The inherited PropertyValue has a value, i.e. it cannot be modified. This restriction follows directly from the underlying set theory: elements from the subset are also elements from the superset. This excludes different PropertyValues for the superset.

However, if the inherited PropertyValue has no value in the supertype CataloguePart then the subtype is allowed to assign a value to it. In the data this situation is expressed with an additional PropertyValue that has the exact same name as the inherited PropertyValue, and that links to the same PropertyType.

Inherited and overwritten PropertyValue example
Inherited and overwritten PropertyValue example

08 Constraining simple and complex properties

This section will not explain how to use PropertyValueInterval to constrain the possible values of simple and complex properties, because it is not part of the core of the COINS datamodel, but part of Reference Model Functional Specifying.

Personal tools