NISTIR 7436

An Ontology for Assembly 

Representation

Xenia Fiorentini

Iacopo Gambino

Vei-Chung Liang

Sudarsan Rachuri

Mahesh Mani

Conrad Bock

 
NISTIR 7436

An Ontology for Assembly 

Representation

Xenia Fiorentini 

Iacopo Gambino 

Vei-Chung Liang 

Sudarsan Rachuri 

Mahesh Mani 

Conrad Bock 

Manufacturing Systems Integration Division 

Manufacturing Engineering Laboratory 

July 2007

U.S. Department of Commerce 

Carlos M. Gutierrez, Secretary 

National Institute of Standards and Technology 

 James M. Turner, Acting Director 

 
Abstract 

Mechanical assemblies are systems composed of modules that are either 

subassemblies or parts. Traditionally an assembly information model contains 

information regarding parts, their relationships, and its form. But it is important that 

the model also represent the function and behavior. This report describes the 

development of an Ontological Assembly Model in the broader context of Product 

Lifecycle Management (PLM). 

The ontological assembly model can help in achieving various levels of 

interoperability as required to enable the full potential of PLM. In this report we first 

present an Ontology Web Language (OWL) version of the Core Product Model 

(CPM) and subsequently an Open Assembly Model (OAM) based on their previous 

Unified Modeling Language (UML) versions developed at the National Institute of 

Standards and Technology (NIST) [7] [8] [9]. Besides developing a semantic 

assembly information model, we further extend this model to incorporate reasoning 

capabilities. We explore and discuss various tools and methodologies for ontological 

assembly modeling with reasoning capabilities. The ontological assembly model can 

be considered an extension to the NIST OAM with semantic interoperability. This 

extended Assembly Ontology in OWL could serve to test the advantages of a 

semantic approach to represent a product structure evolution i.e., from the design 

phases and throughout the life of the product. An example case study is additionally 

discussed to explain the Ontological Assembly Model including rules and reasoning 

capabilities. 
i

Table of Contents 

1 Introduction .........................................................................................1

2 Previous Works at NIST......................................................................1

2.1 Core Product Model 1 

2.2 Open Assembly Model 6 

3 Language concepts and tools...............................................................7

3.1 Patterns for Translation 8 

3.1.1 Property Translating Pattern................................................................... 8

3.1.2 Association Pattern................................................................................ 10

3.2 Modeling and Reasoning Tools 14 

4 OWL Model of the Assembly ...........................................................15

4.1 Translation of the CPM to OWL 15 

4.2 Translation of OAM to OWL 17 

4.2.1 Relationships between artifacts ............................................................. 17

4.2.2 Relationships between features.............................................................. 21

4.2.3 Pairs and Relations................................................................................ 21

4.2.4 Tolerances.............................................................................................. 22

4.2.5 Usage Patterns....................................................................................... 23

5 Reasoning with OWL Assembly Model ...........................................26

5.1 Description Logic Reasoning 26 

5.2 Rule-based Reasoning 26 

5.2.1 Property rules........................................................................................ 27

5.2.2 Association rules.................................................................................... 27

5.2.3 PartOf rules ........................................................................................... 27

5.2.4 Restrict rules.......................................................................................... 28

5.3 Rule Analysis and Discussion 29 

6 Case study: Planetary Gear System...................................................34

6.1 Use Case Description 34 
ii

6.1.1 Components in Planetary Gear System ................................................. 35

6.1.2 Assembly Hierarchy............................................................................... 35

6.2 Use Case Implementation 41 

6.2.1 Asserted Instances and Properties......................................................... 42

6.2.2 Inferred Instances and Properties ......................................................... 51

6.2.3 Kinematic Information Representation.................................................. 57

6.2.4 Tolerance Representation in the Planetary Gear System...................... 58

7 Results and Discussion......................................................................59

7.1 Model Advantages 60 

7.2 Limitations and future research directions 61 

8 Acknowledgements ...........................................................................62

9 Disclaimer..........................................................................................63

10 References......................................................................................63

11 Appendix........................................................................................66
iii

List of Figures 

Figure 1 Class diagram of the Core Product Model ..................................................... 3 

Figure 2 Overview of the OAM-UML ......................................................................... 7 

Figure 3 Protégé composition..................................................................................... 12 

Figure 4 UML Property Class..................................................................................... 13 

Figure 5 A Property Class connecting two different Object Classes.......................... 13 

Figure 6 Property pattern for two Object Classes....................................................... 13 

Figure 7 First part of the translation of Property Classes........................................... 14 

Figure 8 Second part of the translation of Property Classes....................................... 14 

Figure 9 A is composed by B, C and D ...................................................................... 17 

Figure 10 B is an assembly too................................................................................... 18 

Figure 11 B and D are not directly connected ............................................................ 18 

Figure 12 Example of an assembly composition ........................................................ 19 

Figure 13 The assembly representation in OWL ........................................................ 20 

Figure 14 Usage pattern.............................................................................................. 24 

Figure 15 Example of the usage pattern ..................................................................... 25 

Figure 16 Property rules ............................................................................................. 27 

Figure 17 PartOf rule .................................................................................................. 28 

Figure 18 Example of a not allowed assembly ........................................................... 28 

Figure 19 Planetary Gear System ............................................................................... 35 

Figure 20 Exploded view of the Planetary Gear System............................................ 35 

Figure 21 Planetary Gear structure ............................................................................. 37 

Figure 22 Planetary Gear hierarchy............................................................................ 38 

Figure 23 Connections between parts......................................................................... 39 

Figure 24 Output Housing Assembly ......................................................................... 39 

Figure 25 Ring Gear Assembly .................................................................................. 40 

Figure 26 Planet Gear-carrier Assembly .................................................................... 40 

Figure 27 Planet Carrier Assembly and Sungear........................................................ 41 

Figure 28 Output Housing Assembly ......................................................................... 41 

Figure 29 Kinematic Diagram of Planetary Gear System .......................................... 57 

Figure 30 Sungear tolerances...................................................................................... 59 

Figure 31 Dynamic Range Example........................................................................... 61 

Figure 32 Open World Assumption............................................................................ 62 
iv

List of Tables 

Table 1 Artifact Association rules .............................................................................. 30

Table 2 Assembly Feature Association rules.............................................................. 31

Table 3 Assembly Feature Association Representation rules..................................... 32

Table 4 Kinematic Path rules...................................................................................... 32

Table 5 SameAs rule................................................................................................... 33

Table 6 PartOf rules.................................................................................................... 33

Table 7 Rules for not Allowed Artifacts..................................................................... 34

Table 8 Rule for not allowed Pair Frame.................................................................... 34

Table 9 Components of the Planetary Gear System ................................................... 36

Table 10 Artifact: asserted instances and properties .................................................. 43

Table 11 Part: asserted instances and properties ........................................................ 45

Table 12 OAM Features: asserted instances............................................................... 47

Table 13 ArtifactAssociation: asserted instances and properties................................ 48

Table 14 AssemblyFeatureAssociation: asserted instances and properties................ 50

Table 15 AssemblyFeatureAssociationRepresentation: asserted instances and 

properties .................................................................................................................... 51

Table 16 Assembly inferred properties....................................................................... 53

Table 17 Meaning_Less_Artifact inferred instances .................................................. 53

Table 18 Part: inferred properties ............................................................................... 54

Table 19 ArtifactAssociation: inferred properties ...................................................... 55

Table 20 AssemblyFeatureAssociation: inferred property ......................................... 56

Table 21 AssemblyFeatureAssociationRepresentation: inferred properties............... 57

Table 22 Kinematic Pairs and Associated Parts of Planet Gear System .................... 58
v

List of Acronyms 

NIST- National Institute of Standards and Technology 

PLM – Product Lifecycle Management 

CAD – Computer Aided Design 

UML – Unified Modeling Language 

OWL – Ontology Web Language 

ERP – Enterprise Resource Planning 

DSS – Decision Support System 

SWRL -Semantic Web Rule Language 

CAE- Computer Aided Engineering 

URI- Universal Resource Identifier 

OAM- Open Assembly Model 

CPM- Core Product Model 

MOKA- Methodology and tools Oriented to Knowledge-Based Engineering Applications 

OWL-DL Ontology Web Language Description Logic 

RDF- Resource Description Framework 

AFA- Assembly Feature Association 

AFAR- Assembly Feature Association Representation
1

1 Introduction 

The development of an ontological assembly representation was initiated from several 

considerations concerning assembly representation for PLM. The complete distribution 

and control of information between different stake holders is the underlying goal for the 

PLM approach. To achieve an interoperability level that could enable efficient 

implementation of PLM, it is necessary to identify a common data structure to allow data 

exchange between different stake holder’s platforms [1] [2]. A first step towards 

achieving this goal is to develop information models with standard data structures to 

support interoperability. An ontology based approach with additional reasoning 

capabilities could create a new perspective for PLM [3] [4] [5]. 

In an industrial scenario, many products are assemblies composed of either individual 

parts or subassemblies produced from different suppliers. An important reason to model 

assemblies using an ontology is to test the advantages of a semantic approach where the 

meaning of the modeled concepts is formally defined. The semantic model is especially 

useful to capture the evolution of the assembly from the design phases and throughout the 

life of the product. An assembly model is required to represent relationships between 

artifacts (for example parts, assemblies. We will formally define artifacts in the following 

sections) that characterize an assembly representation of a product model. 

The ontological assembly model can help in achieving various levels of interoperability 

as required to enable the full potential of PLM. Besides developing a semantic assembly 

information model, we further extend this model to incorporate reasoning capabilities. 

This report is organized as follows: Section 2 presents the previous and related work at 

NIST, here we briefly discuss the UML [6] versions of NIST’s CPM [7] [8] and OAM 

models [9]. Section 3 presents useful methodologies and relevant tools used for the 

creation of the ontology. Section 4 presents the OWL [10] model of the assembly 

representation. Section 5 presents the reasoning capabilities of the ontology 

representation. Section 6 presents an implemented case study to explain the Ontological 

Assembly Model including the applied rules and reasoning capabilities. Finally Section 7 

summarizes the report with results and discussion. 

2 Previous Works at NIST 

NIST’s CPM and OAM [9] are a starting point towards developing an ontological 

assembly model. CPM is a product representation model while OAM is the CPM 

extension for an assembly representation. Both CPM and OAM were originally UML 

models [11] [12]. In this section a brief overview of the UML versions of CPM and OAM 

are presented for better understanding. 

2.1 Core Product Model 

The CPM [7] [8] was intended to form a base for future systems that could respond to the 

demands of the next generation CAD systems besides providing improved 
2

interoperability among future software. CPM is an abstract model with generic or 

meaningful semantics about a particular domain to be embedded within an 

implementation model and the policy of use of that model. The key concept that makes 

CPM a candidate for supporting the full range of PLM activities is that a product is 

described by a triad: 

 Function: what the artifact is supposed to do; the term function is often used 

synonymously with the term intended behavior. 

 Form: the proposed design solution for the design problem specified by the 

function; in CPM, the artifact’s physical characteristics are modeled in terms of its 

geometry (the “traditional” domain of CAD models) and material properties. 

 Behavior: how the artifact implements its function in terms of the engineering 

principles incorporated into a behavioral or causal model; application of the 

behavioral model to the artifact describes or simulates the artifact’s observed 

behavior based on its form [13]. 

Figure 1 shows a UML diagram [14] [6] of the CPM composed of four categories of 

classes: classes that provide supporting information for the objects (abstract classes), 

physical or conceptual objects classes, classes that describe associations (relationships) 

among the objects and classes that are commonly used by other classes. For more 

information please refer to Fenves et al, 2001. 

In the rest of this report, the following naming conventions are used: names of CPM 

classes are written in boldface and capitalized (e.g., CoreProductModel, 

EntityAssociation, Artifact). Names of attributes are in boldface and lower case (e.g., 

information) while names of instances are in italics (e.g., cylindricalForm). 

The common information is stored in five supporting classes: exploring the model 

starting from the highest level of generalization, the first class CoreProductModel 

represents the highest level of generalization. For this class we define the common 

attributes type, name and information and they are inherited by all the classes of 

the model. 

CommonCoreObject is the base class for all the object classes. 

CommonCoreRelationship and its specializations may be applied to instances of classes 

derived from this class. 

CommonCoreRelationship is the base class from which all association classes are 

specialized. 
3

Figure 1 Class diagram of the Core Product Model 

CoreEntity is the base class from which the classes Artifact and Feature are 

specialized. EntityAssociation relationships may be applied to entities in this class. 

CoreProperty is an abstract class from which the classes Function, Flow, Form, 

Geometry and Material are specialized. Constraint relationships may be applied to 

instances of this class. 

The following constitute the object classes: 

Artifact is the key object class in the model. It represents a distinct entity in a product, 

whether a component, part, subassembly or assembly. All the latter entities can be 

represented and interrelated through the subArtifacts/subArtifactOf

containment hierarchy. 
4

Feature is a portion of the artifact’s form that has some specific function assigned to it. 

Thus, an artifact may have design features, analysis features, manufacturing features, etc. 

Feature has its own containment hierarchy, so that compound features can be created out 

of other features. A Feature has attributes of Function and Form, but does not have a 

different Behavior since its Behavior is defined in the Artifact containing the Feature. 

Port is a specific kind of feature, sometimes referred to an interface feature. 

Specification is the collection of information relevant to an Artifact deriving from 

customer needs and/or engineering requirements; it is a container for the specific 

Requirements that the artifact must satisfy. 

Requirement is a specific element of the Specification of an artifact that governs some 

aspect of its function, form, geometry or material. Requirements cannot be applied to 

Behavior, which is strictly determined by a behavioral model. This is because 

requirements represent what the artifact is supposed to do while Behavior is the observed 

performance of the Artifact. 

Function represents what the artifact or feature is supposed to do. The artifact satisfies 

customer needs and/or engineering requirements largely through its function. 

TransferFunction is a specialized form of Function involving the transfer of an input 

flow into an output flow. 

Flow is the medium that serves as the output of one or more transfer function(s) and the 

input of one or more other transfer function(s). 

Behavior describes how the artifact implements its function; it is governed by physical, 

chemical or other engineering principles that are incorporated into a behavioral or causal 

model. 

Form of the artifact or feature is the design solution for the problem specified by the 

function. In the CPM, the artifact’s or feature’s physical characteristics are represented by 

two distinct classes, namely: 

Geometry is the spatial description of an artifact or feature. 

Material is the material composition of an artifact or feature. 

The following constitutes the association (relationship) classes derived from the 

CommonCoreRelationship class: 

Constraint is a specific shared property of a set of entities that must hold in all cases. At 

the level of the CPM, only the entity instances that constitute the constrained set are 

identified. 

EntityAssociation is a simple set membership relationship among artifacts and features. 
5

Usage is a mapping from CommonCoreObject to CommonCoreObject, useful when 

constraints apply to multiple “target” entities but not to the generic “source” entity. 

Trace is structurally identical to Usage, useful when the “target” entity in the current 

product description depends on a “source” entity in another product description. 

The following three utility classes (not shown on Figure 1) provide additional detail: 

Information, an attribute of CoreProductModel and all its specializations, is a container 

consisting of three attributes: a textual description, a textual documentation and 

properties that represent a set of attribute-value pairs representing all domain or 

object-specific attributes. process_information, an attribute of Artifact, contains 

product development process parameters that may be used in a PLM environment. 

Rationale, an attribute of CoreProperty, documents decision in the product 

development process. 

The classes described above are linked by three kinds of associations. 

First, all object classes have their own separate, independent decomposition hierarchies

by attributes such as subArtifacts/subArtifactOf for the Artifact class. 

Second, there are associations between: 

• a Specification and the Artifact that results from it 

• a Flow and its source, destination Artifacts and its input/ output Functions 

• a Artifact and its Features 

Third, and most importantly, four aggregations are fundamental to the CPM: 

• Function, Form and Behavior aggregate into Artifact 

• Function and Form aggregate into Feature 

• Geometry and Material aggregate into Form 

• Requirement aggregates into Specification. 

The conceptual model of CPM may be used in actual applications. Specific instances of 

entities must be located by means of their type and their attributes stored in and 

retrieved from the properties slot of the associated Information instance. These 

same two constructs, type and properties, may be used by a model compiler to create 

subclasses of Artifact from the specifications in the type slot, and define attributes on 

the subclasses from the properties list. 
6

2.2 Open Assembly Model 

The reason to create an Open Assembly Model (OAM) [9] was to provide a standard 

representation and exchange protocol for assembly and system level tolerance 

information. The OAM structure was created to be extensible, and in the current UML 

version (see Figure 2), it is possible to store data for tolerance representation and 

propagation, representation of kinematics, and engineering analysis at the system level. 

The assembly information model focuses on the information requirements for part, 

features and assembly relationships. The data structure used is part of ISO 10303, 

informally known as the STandard for the Exchange of Product model data (STEP) [15] 

[16] [17] [18]. Information about assembly relationships and component compositions 

are incorporated in the schema. The convention utilized is the same as the CPM 

overview. 

The class AssemblyAssociation represents the component assembly relationship of an 

assembly. It is the aggregation of one or more Artifact Associations. 

The assembly relationships between one or more artifacts are represented by the class 

ArtifactAssociation. In most of the cases, two or more artifacts are involved in this 

relationship. However, the possibility of one artifact association in the OAM is also 

allowed to represent special cases. Such a case may occur when an artifact is to be fixed 

in space for anchoring the entire assembly with respect to the ground. It can also occur 

when kinematics information between an artifact and the ground is to be captured. Such 

cases can be regarded as relationships between the ground and an artifact. For these 

reasons the artifact association with one artifact associated is allowed. Please see [9] for 

the detailed description of the model. 
7

Figure 2 Overview of the OAM-UML 

Based on the CPM/ OAM models discussed above, the motivation was to further explore 

and extend the current OAM with reasoning capabilities exploiting the ontological 

representation. We also intend to experiment with various tools for modeling an 

ontological assembly representation. Besides defining concepts, the benefits of such an 

ontology include [19] [20]: 

• Creating abstract models 

• Explicating concepts, properties, relations, functions, axioms and constrains 

• Creating computer interpretable formulizations so as to infer classes, instances, or 

in general, reasoning through queries. 

3 Language concepts and tools 

In this section we first present the general concepts needed to explain the creation of the 

OAM ontology. The first step of the ontology development is the translation of the UML 

structure in OWL [21]. The idea of incremental modeling allows us to take advantage of 

the experience and knowledge gained from the earlier deliverable versions of the model. 

The key was to start with a simple implementation of a subset of the model and then 

progressively evolve towards a full model. 
8

3.1 Patterns for Translation 

UML was originally used in software engineering and more specifically to support the 

software development. For this reason, the modeling elements offered by UML are 

substantially aligned with the needs of object-oriented programming and to some extent 

relational databases, which are also software. The current extensive use of UML is due to 

its intuitive graphic representation. 

OWL was developed to support the semantic web [10] [21] [22] [23], as an extension of 

RDF [24] [25], and its core mission is to enable interoperability through semantic data 

representation. There are several underlying constraints to achieve harmonization 

between these two languages [26]. However particular attention is needed while 

translating the classes, where no widely accepted rules for creating or evaluating 

collections of classes currently exists [27] [28] [29]. 

In this work we adopt general repeatable solutions (termed patterns) to problems often 

occurring while mapping a model from UML to OWL. We specifically define a set of 

mapping solutions [30] [31] for the following: 

1) problems concerning general UML properties 

2) problems regarding various property constructs used to describe association 

relationships 

3.1.1 Property Translating Pattern 

There are two main considerations while translating UML properties into OWL elements 

(for example, object properties, data type properties, etc). First is the naming strategy for 

UML properties and the second is the UML property type mapping to OWL elements. 

First, UML properties are local to their owning classes and thus two classes may have 

properties with the same name. In this case, the properties have to be renamed when they 

are translated into OWL properties or OWL classes to avoid naming conflicts. Secondly, 

UML properties may be of primitive data types (data type provided by UML as building 

blocks) or of class types (constructs built ad hoc for a specific model). Here, if a property 

is intended to be of primitive data type, corresponding OWL properties and classes have 

to be created for the translation. 

• UML properties into OWL properties or OWL Classes 

An important consideration is to decide if UML properties should be translated into OWL 

properties or OWL classes. If a UML property represents a decomposable concept, it 

should be treated as an OWL class [32] instead of OWL property in the OWL model. 

Properties and attributes concepts are modeled as resources and can be further identified 

by their Universal Resource Identifiers (URI). If a new concept, such as an attribute type, 

is later introduced to denote the attribute value in an attribute, it can be attached to the 

attribute resource. 
9

• Naming strategy and General Rules 

The Class-name-Property-name convention can be used to rename UML properties for 

most of the cases. The class name is the name of the class that owns the property. This 

class will be set as domain of the OWL property while the type of the UML property will 

be set as range of the OWL property. The following rules can determine which kind of 

OWL properties are used to translate UML properties: 

1. If the property is of type class, use owl:ObjectProperty (property for which 

the value is an individual). 

2. If the property type is a primitive data type, use owl:DatatypeProperty

(property for which the value is a data literal, such as a string or a number): in this 

case the values of the property are treated as atomic types and cannot be 

decomposed further in conceptual modeling. 

3. If the property has a multiplicity of 1, use owl:FunctionalProperty (a 

property that has a unique value y for each instance x) or specify cardinality equal 

to 1. 

The drawback of this method is that all local properties must have unique names in an 

OWL document, which may result in generating a large number of properties. However, 

since there are only a handful of properties specified in CPM and OAM, this approach is 

adequate in most cases. 

• Using Inheritance 

Sometimes, making all local UML properties to be global properties in OWL may cause 

redundancy and naming conflicts. Inheritance of properties in OWL can be used to 

eliminate such problems. First, a unique generic property without specifying any classes 

as its domain (the class owning the property) and range (the class of the values of the 

property) type will have to be created. The following rules may apply: 

1. Restriction on domain and range will be further specified only when the property is 

refined in a specific class description. 

2. The generic property can be used in many different class descriptions. A unique 

name needs to be assigned to this property and restrictions will be applied to each 

single class. 

The use of the inheritance property allows us to overcome the limitation of the absence of 

qualified cardinality restrictions, not supported in the OWL version 1.0. Consider the 

example in which there is a ClassA connected with a property to ClassB, superclass of 

ClassC. To specifiy that an individual of ClassA has to be connected at least with two 

individuals of ClassC, we have to create a subproperty specifically connected with 

ClassC and then add the restriction on that subproperty. Moreover, to prevent the use of 
10

the superproperty connected to an individual of ClassC we can specify that the range of 

that superproperty is constituted by all the elements in ClassB that are not in ClassC. 

Another use of inheritance property is when, for example, there is a ClassA connected 

with ClassB and ClassC through two different properties (each class is range of each 

property). To specify that an individual of ClassA is connected with only one of these 

two properties, we have to assert that both the two properties are subproperties of a 

generic property, having as domain ClassA and having range not specified, and then add 

the cardinality restriction on this generic property. 

3.1.2 Association Pattern 

There are many different types of associations that can be described in UML, such as 

directed associations, binary associations, association classes, and so on. OWL also 

provides various property constructs to describe relationships. There are similarities and 

differences between these constructs. Both UML and OWL allow users to apply 

cardinality constraints, refinement, and sub-setting to associations and properties. 

However, UML supports n-ary relations (relations linking an individual to more than one 

individual or value), while OWL supports only binary relations. Besides, UML supports 

aggregation and composition relations between classes, while OWL supports transitive, 

symmetric, and functional property definitions. Association patterns are used to translate 

these UML association properties into OWL properties. 

• Simple directed association 

A simple directed association can be translated as an owl:ObjectProperty. The 

participating classes will be the domain and range of the associated property. 

• Classified binary association 

Associations in UML have various combinations of characteristics. For example, an 

association can be unnamed, shared, binary, and navigable. In mathematics, a binary 

relation (or a dyadic relation) is an arbitrary association of elements of one set with 

elements of another set. 

A formal definition of a binary relation could be the following: A binary relation R is 

usually defined as an ordered triple (X, Y, G) where X and Y are arbitrary sets (or classes), and 

G is a subset of the Cartesian product X × Y. The sets X and Y are called the domain and range, 

respectively, of the relation, and G is called its graph. 

Analyzing this definition from the OWL point of view, it is easy to understand that X and 

Y are simply two classes of the ontology (e.g., Assembly and ArtifactAssociation) and 

that G is a property between them (e.g., Assembly2ArtifactAssociation). These properties 

are not shared between classes, unlike the ones previously presented. 

In order to translate these binary associations into OWL, a taxonomy of binary 

associations is first created. The root of this taxonomy will be binaryAssocation. 
11

The subproperties of binaryAssocation include 

binaryUnnamedAssociation, binaryNamedAssociation, and 

associationClass. Since OWL properties are directional, for a given UML binary 

association a pair of mutually inverse properties is created. For example, two mutually 

inversed properties are created as subproperties of binaryUnnamedAssociation

property. BUA_1 and BUA_1_INV are created as a pair of mutually inverse OWL 

ObjectProperties for further extension. The hasOutputFlow and 

isDestinationOf properties can thus be organized as subproperties of BUA_1 and 

BUA_1_INV respectively. This pair of properties can be used to describe the association 

between Artifact and Flow (see section 2). Some ontology editors, such as ProtégéOWL, can take advantage of this arrangement and automatically generate the 

corresponding inverse subproperties. 

• Shared aggregation association 

The significance of the shared aggregation1

 associations in UML is that the parts can be 

shared by many containers. Such semantics cannot directly be captured by OWL 

constructs. Similar to the classified binary association pattern, the root of the aggregation 

properties taxonomy will be first created after which a pair of directional subproperties of 

this root will capture the aggregation. 

• Self-referenced weak composition association 

The self-referenced weak composition association pattern is used in CPM to capture: 

decomposition hierarchies, part-of relationship, and containment hierarchies. A part-of 

relation can be defined as a transitive, irreflexive, and asymmetric relation. OWL 

currently only supports the transitive property. Without irreflexive construct, it is not 

possible for one to state that a part cannot be part of itself. Without asymmetric construct, 

two parts may contain each other. These unsupported properties (at the time of this 

report) will be available in OWL 1.1. As already mentioned in the UML version of the 

model, core classes are characterized by reflexive relationships but in OWL there are no 

primitives to represent such relationships. Hence the structure has to be reproduced in the 

ontology using a composite set of properties grouped under the super property 

composition (Figure 3 Protégé composition ). 

 

1

 In some old UML documents, a shared aggregation is also called weak composition as opposed to the black diamond (strong) 

composition in which the containing component is responsible for the storage and creation of the contained components. Components 

in weak composition can be stored by more than one container. 
12

Figure 3 Protégé composition

As can be seen from the Figure 3 the class composition has two subproperties: hasPart

and partOf, each inverse of the other. Considering hasPart it can be noticed that it 

further has subproperties like hasPart_direct. 

Note that the second properties have subproperties too. The subproperties of this class 

differ from the “not” direct properties because they are not transitive. For further 

explanation of the hierarchy let’s consider a description of a bicycle and its 

decomposition into elements: 

Bicycles have parts Wheel, DriveTrain 

Wheels have parts Rim, Tire 

DriveTrains have parts Gear, Chain 

For expressing the part-whole relations [33] between individuals, we use hasValue

with partOf_direct and the relations between classes using the restrictions 

someValuesFrom with partOf_direct. Following are some useful conclusions 

drawn from the above example: first of all the semantics necessary for the correct 

representation for bicycle parts are not completely represented by existential restrictions 

for e.g. owl:someValuesFrom. Considering the Chain class, we can deduce that a 

chain is part of at least a drive train, but we cannot deduce that a particular chain cannot 

be owned by more then one drive train. Adding a cardinality restriction (e.g., 

maxCardinality 1) on the property partOf to the definition of chain will not solve the 

problem either. A chain is also a part of the bicycle where the drive train is a part. For 
13

this reason OWL-DL does not allow transitive properties to have any cardinality 

restrictions. The creation of the property partOf_directly is useful for the 

introduction of restrictions in the definitions of these classes. A single chain cannot be a 

direct part of more then one drive train and a drive train cannot be part of more then a 

bicycle, so in these cases a cardinality restriction specified on the property 

partOf_directly is needed. Specifying cardinality constraints helps to create a 

precise representation but there is a trade off between model accuracy and computational 

time needed by the Reasoner. 

• Association class pattern 

There are several approaches for translating association classes into OWL classes. Let’s 

consider for example the following UML structure (Figure 4). 

Figure 4 UML Property Class

In OWL it is not possible to represent this structure directly because there is no built-in 

pattern with this meaning. However, it is possible to decompose the UML structure into 

simple elements and later translate it in OWL to recreate the original meaning (Figure 5). 

Figure 5 A Property Class connecting two different Object Classes 

For the translation of UML association classes, in OWL there are two feasible solutions: 

the first requires the creation of a set of four different properties between classes with 

specific cardinality restrictions (Figure 6). 

Figure 6 Property pattern for two Object Classes 

This solution includes two different object classes, while in CPM and OAM this case 

never occurs. So we create an alternate second solution (Figure 7). 

Class A

Class B 

Class B 

Class A

Class C

INVERSE INVERSE

=1

Class B Class A Class C 

max 1
14

Figure 7 First part of the translation of Property Classes 

The second solution is used with the specification of certain constraints. First of all (as 

seen from the Figure 7) a cardinality constraint has to be set and it is mandatory to 

preserve the binary relation between the two classes. This means that two instances of 

class B can be linked only with one instance of class A. In OWL, it is not possible to 

explicitly express this constraint but alternatively we declare that if the same two 

instances of class B are linked with two different instances of class A (A1 and A2) they 

have to be equal (Figure 8). 

Figure 8 Second part of the translation of Property Classes 

• Cardinality Pattern 

All the above discussed patterns have to deal with the cardinality. By default, the 

cardinality restrictions for all properties in a model are set to be zero to many. 

Sometimes, it is hard to determine the cardinality of a relationship at an early stage of the 

design. Unlike UML, OWL allows redefining properties independently from the classes 

so we can specify cardinalities after the classes are defined. This provides more freedom 

to the model creators. However, caution has to be taken with the description-logic based 

approach since the changed cardinality may destroy the parent-child relations between 

the classes. Further examples will be presented later, when we discuss the strategies for 

using the CPM OWL model for various design phases. 

3.2 Modeling and Reasoning Tools 

The Assembly ontology is created starting from the core classes using the DL 

(Description Logic) sublanguage of OWL and Protégé-OWL to edit it. The preliminary 

modifications introduced in the model were tracked for later changes due to modeling 

necessities. A partial demo was created instantiating the model after every change or 

modification. We verified each branch of the ontology using Protégé-OWL, as it is able 

to run the reasoning simulation of the model. The Protégé-OWL editor [34] [35] is an 

extension of Protégé that supports OWL. Snapshots of Protégé Subclass explorer 

min 2 

Class A Class B 

A1 

B1 

B2 

A2

B1

B2

A1=A2 
15

(Snapshot A1), Property browser (Snapshot A2) and Class browser (Snapshot A3) are 

presented in the Appendix. 

The Protégé-OWL editor enables users to: 

• Load and save OWL and RDF ontologies. 

• Edit and visualize classes, properties and SWRL (Semantic Web Rule 

Language) rules. 

• Define logical class characteristics as OWL expressions. 

• Execute reasoners such as description logic classifiers [36] [37]. 

• Edit OWL individuals. 

Although time consuming, this incremental approach (discussed earlier) of model 

development has allowed time for testing, and, subsequently improved the model. 

Description logic reasoning are done using RACER [38], a DL reasoner. This tool allows 

consistency checking and to infer class/instances. 

Rule-based reasoning is possible using SWRL [39] [40] rules. An appropriate plug-in 

was available in Protégé-OWL (SWRL Tab). A Jess Bridge [41] is used to translate both 

the rules and the ontology into the Jess Engine. Once executed, the results can be 

imported again into the ontology in OWL through the Jess Bridge. 

4 OWL Model of the Assembly 

One of the main benefits using an ontology is the possibility to share and reuse 

knowledge [42] [43] [44]. When importing one ontology from another, all the classes, 

properties and individual definitions that are part of the imported ontology become 

available for use and furthermore, we can add components or restrictions without 

affecting the imported ontology. In this research, since OAM is an extension of the CPM, 

we can first build the CPM ontology and then import it into the OAM ontology. With 

OAM, all the considerations about the CPM are still valid. Coherent with our aim to 

create a model that is extensible by itself, we choose to create a vertical hierarchy so that 

all the classes of the extensions will be subclasses of the main model classes. Section 4.1 

presents the translation of the CPM to OWL and Section 4.2 subsequently presents the 

OAM translation. The reasoning in the developed OAM-OWL Assembly Model is 

presented in Section 4.3. 

4.1 Translation of the CPM to OWL 

The structure of the ontology begins from the class: CommonCoreEntity. This class 

represents real objects and relationships or associations between them. 
16

The common attributes type, name, and information for all CPM classes are 

defined for the CommonCoreEntity class. The first two are Datatypeproperties

while the last is an ObjectProperty. The attribute type, set 0 or 1, is useful to 

overcome the OWL drawback of not being able to set a class as abstract. 

An abstract class is a class for which all instances are instances of a subclass. Such 

classes normally are used as base classes in inheritance hierarchies. In our case, abstract 

classes constitute the top few levels of the hierarchy. To determine whether a class is 

abstract or concrete we control the usage of type by manually setting the cardinality to 

zero for CommonCoreEntity’s abstract classes and maximum cardinality back to one 

for concrete subclasses. 

The name attribute can be completely ignored in the OWL document because rdfs:label 

and the URI for each resource can be used to achieve the same identification purpose. 

However, to preserve the semantics of CPM, the corresponding property 

commonCoreEntityName is created. 

The information class is set like a class and not a DatatypeProperty (attributes) 

to allow users to define them with flexibility, for example to connect every object to any 

number of information. It has description, documentation, and properties 

attributes. The description and documentation can be represented by OWL 

DatatypeProperties for their values are the URI pointing to the referenced 

documents. 

The properties attribute is a set of attribute-value pairs stored as strings representing 

all domain or object-specific attributes. It should be noted that the attribute-value pair 

may be extended to be attribute-type-value pair at the detail design phase. Unlike the 

other two attributes which are defined as DatatypeProperties, the set concept 

defined in CPM report has to be preserved for all these string values. To achieve this, 

properties and its attributes are treated as OWL classes. 

The two subclasses of CommonCoreEntity are CommonCoreObject and 

CommonCoreRelationship. They are represented respectively in UML as two main 

groups of object classes and association classes. For this reason they have type set to 0 

(because they are on a high level of the hierarchy) and they are connected with each other 

with the ObjectProperty property2class and its inverse, following the binary 

pattern of the association classes. 

CommonCoreObject is the parent of five subclasses of which three are concrete classes 

(with type 1) and two are abstract. The former are Behavior, Requirement and 

Specification. They have the same type of connections as in UML, for example the 

Requirement and Specification will be joined by a relationship, and Behavior will have 

a self-reference relationship with the composition pattern. In this way the super-property 

Composition is divided into the subproperties partOf and hasPart, composed of 

specific properties that connect Behavior with itself (both of them are transitive). 
17

Similarly, as subclasses of partOf_direct and hasPart_direct we have 

partOfBehavior_direct and behaviorHasPart_direct. 

Two other subclasses of CommonCoreObjet are CoreEntity and CoreProperty. These 

are important classes because they are particularly involved in the construction of the 

OAM ontology and because they are connected with subclasses of 

CommonCoreRelationship (see Figure 1). CoreEntity has a binary relationship with 

EntityAssociation (coreEntity2entityAssociation) while CoreProperty has 

one with Constraint (coreProperty2Constraint). 

Rationale is an attribute of CoreProperty with specializations (Flow, Form, Function, 

Geometry, and Material) and connected to the Requirement through a binary 

ObjectProperty. 

The rest of the model is developed following the patterns previously described, paying 

attention to the meaning of the UML relationships and their cardinalities. However, it is 

necessary to underline the role of the classes Artifact and Feature as they are the main 

classes of the OAM OWL. 

Further, we decided to preserve the UML interpretation of the relationship partOf

between Artifact and itself, so as to describe the composition of an assembly at the CPM 

level. This information can be useful for the core description of an artifact because some 

characteristics of an assembly can be influenced by the characteristics of its constituent 

parts (for example the function of a part partakes in the function of the assembly). 

4.2 Translation of OAM to OWL 

Starting from the CPM-OWL model (discussed earlier) a relative OAM ontology is built. 

In OAM all the classes and properties presented in section 4.1 are valid. In the following 

section we further discuss the translation of the OAM from UML to OWL. 

4.2.1 Relationships between artifacts 

First and foremost, for the translation it is important to represent the relationships 

between artifacts. Consider the following: artifact A is composed by artifact B, artifact C 

and artifact D as in Figure 9. 

Figure 9 A is composed by B, C and D 
18

There are different levels of decomposition for this product. Now consider artifact B 

composed by artifact E and artifact F (Figure 10). 

Figure 10 B is an assembly too 

Here, we can have different relationships between products, for example artifact A can be 

composed by integrating artifacts B, C and D or it can be created by the relationship of 

artifact C with B and artifact C with D (Figure 11) considering B and D not connected. 

Figure 11 B and D are not directly connected 

In the above example, we have to distinguish between artifacts composed by other 

artifacts (A and B) and artifacts that represent the leaf nodes of the composition (C, D, E 

and F). We classify them into Assembly and Part respectively (as subclasses of 

Artifact). For the Part class we associate the necessary and sufficient conditions such 

that a leaf node has cardinality 0 with the property artifactHasPart_direct that 

is inherited but not required. In this way, we define a part like an artifact without 

subassemblies, so with neither the direct nor the indirect properties 

artifactHasPart. 

Contrarily, considering the necessary conditions of Assembly, there is a constraint to 

have at least two artifacts connected through the property 

artifactHasPart_direct (inherited from Artifact and hence not repeated for 

Assembly). By defining Assembly and Part like partitions of the class Artifact, an 

Artifact composed by other artifacts will be inferred to be an assembly. Unfortunately it 

is impossible to infer the opposite, which means that we have no way to assert that an 

artifact without direct artifacts is a part. This is one of the biggest limitations of 

ontologies in general. The logic is as follows: not relating an artifact with other 

subartifacts does not mean that this artifact is without subartifacts, it just means that at the 

moment we do not know if it will be composed by other parts. Although, it does have the 

relationship artifactHasPart_direct, but we do not know to which subartifacts 

it is connected. 
19

While populating the ontology the user will choose a level by level connection of the 

artifacts. This implies that he/she will decide on the link between them to instantiate the 

direct properties (artifactHasPart_direct or partOfArtifact_direct). 

Here, there could be three choices while implementing the logic of the ontology, in 

particular choosing the connection with indirect properties. Let us take the example in 

which assembly A is composed by assembly B and assembly C, and assembly B is made 

by part 1 and part 2 and assembly C by assembly D and part 3, assembly D by part 4 and 

part 5 (this is the composition of the direct properties shown in Figure 12). 

Figure 12 Example of an assembly composition

The three different choices of inferred connection to the assembly A through the indirect 

property artifactHasPart are: 

 part 1, part 2, part 3, part 4, part 5, assembly B, assembly C and assembly D: all 

the levels 

 part 1, part 2, part 3, part 4 and part 5: only parts at all levels 

 part 1, part 2, part 3 and assembly D: the second level of the decomposition 

We choose the second solution because it is less confusing than the first and more 

detailed than the third. So, if we want to see the detailed composition of the assembly it is 

sufficient to check the direct property of each subassembly and if we want to know the 

parts that compose the assembly we can check the indirect properties. Moreover, since 

the user has to choose only the direct property, we have to decide to allow or not, the 

possibility to create an assembly with two subassemblies without specifying their 

constituent parts. Here, the question arises as to if there is any meaning to define an 

assembly without describing the parts by which it is composed? Or does an assembly 

exist without parts? 

Although from the definition the lowest level of the tree has to be represented by parts, 

we choose to define an assembly even without specifying the constituent parts. The 

reason is as follows: during the concept phase of the product life cycle we have to allow 

the representation of an assembly without specifying its composition. For example we 

assembly A

assembly B assembly C 

part 1 part 2 assembly D part 3

part 4 part 5 
20

may represent a car simply made from an engine and 4 wheels, without specifying from 

which parts the engine and the wheels are composed. 

So, in this ontology, there are two approaches: the bottom up, useful when we want to 

structure some data with complete information, and the top down, necessary in cases 

when we do not know the exact composition of the assembly but we have just an idea of 

its organization. 

After choosing the rules to represent relationships between an assembly and its 

constituents, the second step is the representation of relationships between these 

constituents. In the UML model, we have two classes for representing the structure of the 

assembly: ArtifactAssociation, which represents the relationship between subassemblies 

and AssemblyAssociation, which is the collection of the elements of 

ArtifactAssociation. 

Figure 13 The assembly representation in OWL

In the ontology the class ArtifactAssociation is created with two different 

ObjectProperties connected to it: the first one 

(artifactAssociation2Part) relates the constituents of the assembly and is a 

specification of the binary association entityAssociation2CoreEntity while 

the second one (artifactAssociation2Assembly) is the property that connects 

ArtifactAssociation to the Assembly. 

In this way the UML class AssemblyAssociation is replaced by the property that directly 

connects the elements of ArtifactAssociation with the assembly. For example, if 

assembly A is composed by part 1 and part 2, there will be an instance of 

ArtifactAssociation that connects part 1 and part 2 through the property 

artifactAssociation2Part (ArtifactAssociation has to be connected with at 

least two instances of Parts or Assembly). The same instance of ArtifactAssociation

will be connected with the assembly A through the property 

artifactAssociation2Assembly (assembly A has to be connected with at least 

one instance of ArtifactAssociation). 

Part 1 

Assembly 1 

Assembly 2 Assembly 3 

ArtifactAssociation α ArtifactAssociation α

AssemblyAssociation: α, β
21

4.2.2 Relationships between features 

Although the information regarding the assembly composition is useful to give an 

overview of an artifact, we need to detail the representation to understand in which way 

parts are connected together and the positions and profiles interested in the assembly. 

In the CPM we have already represented the relationship between an artifact and its 

features through the ObjectProperty artifactHasFeature. Our aim in OAM 

is to represent that a feature, although still remaining characteristic of a part, will meet 

another feature belonging to another part to form the assembly. We term this particular 

feature OAMFeature, subclass of Feature. We include in the OAM the possibility to 

connect these OAM features together, and so as to connect the parts that have these 

features and finally to create the assembly in the ontology. 

The class that represents the link between two or more features is termed 

AssemblyFeatureAssociation (AFA) (subclass of EntityAssociation). It is connected to 

the features through the property AFA2Feature following the property class pattern. 

Once this property is defined, we give a formal definition (necessary and sufficient 

condition) to the OAMFeature as a feature with at least one connection with the class 

AssemblyFeatureAssociation. 

Like in the UML model, it is useful to have a direct connection between the class that 

represents the association between features (AFA) and the one that represents the link 

between the artifacts that own these features (ArtifactAssociation). For this, we use an 

ObjectProperty that is a binary property but not a subproperty of 

property2class, since it connects what in UML were two property classes. This 

property is called artifactAssociation2AssemblyFeatureAssociation

(its inverse is called 

assemblyFeatureAssociation2ArtifactAssociation). Logically, an 

element of AssemblyFeatureAssociation can participate only in one 

ArtifactAssociation while an instance of ArtifactAssociation can be represented by one 

or more associations of features. 

4.2.3 Pairs and Relations 

So far, we can describe an assembly through the parts and the features that are involved 

in it. Here we need to detail the description of an assembly with a section relative to pairs 

existing between features. Besides we also need to know if they are movable or fixed, the 

kind of constraints between them and so on. 

In the ontology we choose, like in the UML version, to leave a single class that reunites 

this information: AssemblyFeatureAssociationRepresentation (or AFAR). This is still 

an EntityAssociation because it represents the relationship between two or more 

features. It will have the same restrictions developed for the property class pattern and 

will be connected with the AFA to which it refers: the AFAR will link together the same 

features that are involved in the AFA. Moreover, the AFA has to have just one AFAR
22

linked with it, since AFAR is by itself the class that clusters all the information about the 

connection. This information will be represented through the same classes as in the UML 

model: ParametricAssemblyConstraint, KinematicPair and KinematicPath. They are 

all again subclasses of EntityAssociation, they have the same children classes as in the 

UML version and additionally they refer to the same features involved in the pair. 

The properties connecting AFAR to these three classes are aggregations and they are 

collected under a unique property called AFAR_details. In the ontology an 

association between features can have utmost one path and one pair while the number of 

constraints is flexible. 

Consider the class KinematicPair which represents the kinematic constraints between 

two adjacent features at a joint: to be defined it needs to be connected with the classes 

PairRange, PairValue and PairFrame. PairRange specifies the allowable 

configuration range of the two features in the form of upper and lower bounds. 

PairValue specifies the current configuration (value) of the two links between the two 

bounds. PairFrame represents a coordinate system attached to a feature. A kinematic 

pair needs two coordinate systems to describe its kinematic behaviour as to where they 

will be attached to the two relevant features. For the pairs, the properties involved are 

grouped into one property that connects the pair with its range, value and frames, and 

another property is used to connect these frames to the reference features. 

The class KinematicPath provides the description of kinematic motion. It is the 

aggregation of path elements along which the motion is to take place. A PathElement

can specify different types of paths. Since the KinematicPath is composed of a set of 

PathElements, it can describe a composite path as well as a simple path. To connect the 

PathElements a composite class PathElementConnection is used to order the elements 

by defining the precedence. For this reason there exist the properties 

isNextElementOf and isPreviousElementOf. 

PathElement is a path segment with two PathNodes, which represent the "from" node 

and "to" node, respectively. Two different properties are established going from the 

PathElement to the PathNodes, both with cardinality 1. PathNode is used to define the 

start and end locations of a path. At each PathNode, the position and rotation of a frame 

along the path need to be defined. 

4.2.4 Tolerances 

Like in the UML OAM, we introduce tolerances in the model. We want to allow for 

design tolerances from the early stages of the product lifecycle, to combine the tolerances 

definition with the assembly structure [45]. A proactive approach could be useful for an 

early tolerance synthesis and analysis when the design is incomplete. 

The class Tolerance has the same subclass structure of the UML version, i.e., geometric 

and dimensional tolerance. Tolerance is connected with OAMFeature to represent 

tolerances important in the pairs of parts/subassemblies. The choice of tolerances is 
23

particularly difficult when different parts have to be combined together to obtain a 

specific functionality. 

DimensionalTolerance is linked to the class Size because it controls the variability of 

linear dimensions. Size is a subclass of Attribute, so it is connected with all the 

CommonCoreEntities, including features. The GeometricTolerance defines the 

allowable variation for the form, size of individual features, allowable variation in 

orientation and location between features. For this reason, this class is connected to 

Geometry (a subclass of the CPM class CoreProperty connected with the form of an 

artifact or of a feature). Of the geometric tolerances we can underline important ones: 

LocationTolerance, OrientationTolerance and RunoutTolerance. Unlike other 

tolerances they are also linked with the class Datum. This class represents the geometries 

that are chosen like a reference for the tolerance. So here, Datum is a subclass of 

Geometry and it is connected with DatumFeature that is a subclass of OAMFeature. 

The individuality of the datum is that it can be described like a particular geometry, for 

example like a point, a curve or a plane. Now that we already have these elements in the 

ontology, we exploit the potentiality of OWL to build a class that is a subclass of 

different classes (multiple inheritance). For example, the class CurveDatum will not 

only be a subclass of Datum but also a subclass of Curve. In this way it inherits the 

properties and the characteristics of both Curve and Datum. The practical way to realize 

this is to define the two conditions in the specification of the class. 

4.2.5 Usage Patterns 

The next task is to improve the model since it requires redundant specification of the 

subassemblies, parts, and artifact associations used more than once. For example, if a 

wheel subassembly in a car is comprised of a tire and a hub, this subassembly must be 

repeated at least two times in the current model, so that each wheel subassembly could be 

attached to the correct axle. Otherwise, there is no way to distinguish the back wheels 

from the front ones. 

This leads to a number of problems: 

• Consistency maintenance is difficult when a reused subassembly is changed, and 

requires propagation to all its usages. For example, there is no central class to make a 

change to the parts of wheels, and then propagate this change to all assemblies using 

wheels. 

• Finding all the usages of a part or subassembly is unreliable. For example, the only 

information available about location of wheels usage is in the names “FrontWheel” 

and “BackWheel,” which may change over time. 

Hence it is important to find a central class that represents the elements to be used more 

than once and then to create some classes to realize the usages of these elements. This 

problem concerns not only the elements of the assembly but also the relationships in this 

assembly. 
24

The general pattern is that for any element of an assembly, we define a corresponding 

usage element that refers to the original element and the context of its use. 

The elements that can be repeated (used more than once) are Artifact, OAMfeature, 

ArtifactAssociation and AssemblyFeatureAssociation: these are the Reusable elements 

(Figure 14). For each one of them we define a corresponding class Usage, so in the model 

we have the following classes: ArtifactUsage, AssemblyFeatureUsage, 

ArtifactAssociationUsage and AssemblyFeatureAssociationUsage. Every concept that 

is to be repeated will also have a particular Context. This means that Artifact and 

ArtifactAssociation will be repeated within an Assembly (the context of these classes) 

while in the context of ArtifactUsage we can find several OAMfeatures and 

AssemblyFeatureAssociations. 

ReusableElement Usage Context 

Artifact ArtifactUsage Assembly 

AssemblyFeature AssemblyFeatureUsage ArtifactUsage

ArtifactAssociation ArtifactAssociationUsage Assembly 

AssemblyFeatureAssociation AssemblyFeatureAssociationUsage ArtifactUsage

 Figure 14 Usage pattern 

The property uses will connect every Usage to its corresponding ReusableElement. 

The cardinality will be equal to 1 because each repeated element can belong to only one 

element. The inverse of this property is isUsedBy and has free cardinality because 

every element can either follow the usage pattern or not and can have more than one 

repetition. Usage is connected with the context through the property used_in. The 

cardinality 1 on this property constrains the Usage to have not only its referring element 

but also its context. The property hasUsage is used to link contexts with usages and it 

is declared as the inverse of used_in. 

Let us take into consideration a composition of an assembly formed by repeated parts or 

subassemblies. This assembly will be connected through the hasUsage property with 

the ArtifactUsage that represent the repetitions and with the ArtifactAssociationUsage

that represents the repeated association between these repetitions. Every ArtifactUsage 

will be referred to its corresponding element through the property uses that explains 

which element is repeated. The same holds for the ArtifactAssociationUsage. 

uses used_in 

1 0..* 0..* 1 

ReusableElement Usage Context 
25

In the example (see Figure 15) of the car we will have a representation similar to the 

above discussion. 

Figure 15 Example of the usage pattern

The most important element in representing this usage pattern is its implementation and 

its advantages in using an ontology instead of a UML model. In fact in OWL we can 

create a class that is a subclass of more than one class so that it inherits the properties and 

the characteristic of every parent class. In the same way, one instance can instantiate 

more than one class, taking all the properties of these classes. The coherence control will 

enable us to verify the correctness of such assertions. These OWL characteristics are 

exploited in the usage pattern because the model setting will be the same for both cases 

when we do or do not use the usage pattern. The instantiation of the model will follow the 

steps for which we define the Artifacts: 

 we can either directly connect the Artifacts through the hasPart_direct, 

isPartOf_direct when we don't need to use the usage pattern, or 

 we can connect them with their repetition elements (ArtifactUsage) if we want to 

use the usage pattern. 

This is allowed because an Artifact will have the possibility to have subassemblies or to 

be a subassembly and at the same time to belong to the ReusableElement class having 

property isUsedBy. If we want to choose to follow the usage pattern, we have to 
26

employ some SWRL rules. Without them, for example, the ArtifactAssociation will not 

be connected to any Artifact but only with the ArtifactAssociationUsage. This will be 

presented as an inconsistency since there is a restriction that an ArtifactAssociation has 

to link at least two Artifacts. For this reason we have built some rules (explained in the 

following section) to automatically compile the field 

artifactAssociation2Artifact property. The same kind of reasoning will be 

followed for each usage concept. 

5 Reasoning with OWL Assembly Model 

Classes, properties and restrictions are the elements that OWL offers for the creation of 

an ontology but these elements are not sufficient to capitalize the real potentials of an 

ontology, i.e., the reasoning capabilities. In this ontology we can execute two different 

kinds of reasoning, the description logic reasoning using RACER and rule-based 

reasoning using SWRL and Jess. 

5.1 Description Logic Reasoning 

Description logic reasoning is done using RACER, a software that works like a reasoner. 

RACER practically exploits all the restrictions and the definitions of the classes to infer 

classes and instances. If for example, we define a Class A and we specify a necessary and 

sufficient restriction on its properties (i.e., a pizza is defined like a food that has a base 

and some toppings) and we separately define a Class C that has its properties specified 

(Margerita pizza is a food that has a base and has, as toppings, cheese and tomatoes) the 

reasoner can infer that Class C is a subclass of Class A (i.e., Margerita is a pizza with 

additional characteristics). In the same way the reasoner can infer instances. By always 

using the necessary and sufficient conditions RACER can associate an instance to a 

different class if it satisfies these conditions. Taking the previous example, it means that 

if we define Margerita as a pizza that has only cheese and tomatoes as toppings and we 

create an instance of Pizza that has only these two ingredients, the reasoner will infer that 

this instance belongs to the class Margerita. The role of the reasoner is also to check the 

consistency of the ontology by verifying the necessary conditions and the tree of the 

classes. 

5.2 Rule-based Reasoning 

Since the description logic reasoning cannot be applied to properties, we chose to apply 

some SWRL rules (interpreting the ontology through a Jess Bridge) to improve the 

reasoning capability of the ontology. Once the Jess Engine is run, it returns the new 

inferred information to the ontology. In the subsequent paragraphs we will first explain 

the rules in general, and then discuss every specific rule. There are 4 kinds of rules that 

are useful both to associate instances to new classes and to create properties between 

instances. 
27

5.2.1 Property rules 

Property rules are the most common in the ontology, they are used to create new links 

between instances once some properties are satisfied (Figure 16). They are logic rules and 

they incorporate the meaning into the ontology. They are useful because, when defining 

the ontology, we do not need to specify every property: doing so we can avoid mistakes 

and thus input a lighter ontology. For example, once we have the structure of an 

Assembly and the ArtifactAssociations between its subassembly, the Jess Engine can 

link these ArtifactAssociations to the Assembly. In the example of Figure 16 the 

Assembly 1 is composed by Part 1 and Part 2 (property partOfArtifact_direct), 

these last are connected through the ArtifactAssociation α (property 

artifactAssociation2Part): the Jess Engine infers the connection between 

Assembly 1 and ArtifactAssociation α (property 

artifactAssociation2Assembly). 

Figure 16 Property rules

5.2.2 Association rules 

As mentioned earlier in this report (section 3.1.2), we have decided to uniquely translate 

the property classes and the relationships they specify between two elements of the same 

object class. The property class will become a normal class in the ontology and it will be 

connected to the object class with a binary property. To be binary, first of all we apply a 

minimum cardinality 2, and then we specify that if two different elements of the property 

class are connected to the same elements of the object class, then these two elements are 

the same. In SWRL it is translated with the embedded language structure: sameAs. 

5.2.3 PartOf rules 

These rules (see Figure 17) are needed to infer the indirect properties (discussed earlier in 

the structure of Assembly). The user only specifies the properties 

partOfArtifact_direct while the partOfArtifact will be built through 

SWRL rules. 

Assembly 1 

Part 1 ArtifactAssociation α Part 2 
28

Figure 17 PartOf rule 

5.2.4 Restrict rules 

They are useful to populate the classes of the kind not-allowed. We have to create these 

classes because in OWL, and in particular in Protègè, there is no way to infer that some 

impossible properties or instances created by the user have to be cancelled from the 

ontology. The only way to realize this is to insert the user’s input without meaning into 

new classes. Take for example the case in which an assembly is composed by itself (i.e., 

assembly 2 is composed by assembly 1 that is in turn composed by assembly 2) as can be 

seen from Figure 18. 

Figure 18 Example of a not allowed assembly

Assembly 2 

Assembly 1 Part 3 

Part 1 Part 2 

Assembly 2 

Part 1 Part 2 Part 3 

partOfArtifact_direct

partOfArtifact

Assembly 2 

Assembly 1 

Assembly 2 
29

Some traditional SWRL rules or some OWL definitions are useless because they can only 

specify some characteristics of the classes but not of the instances. In the example, both 

the assembly 2 and 1 are instances of the same class, so no definitions can be applied to 

the relationships between them. To solve such problems we create the not-allowed 

classes and we put such structures in them through SWRL rules. 

5.3 Rule Analysis and Discussion 

In this section we examine the rules in the Ontology. Note that we sometimes may need 

to present some of them together, because they are useful only if they are run together. 

The rules will be presented in tables with the antecedent in one column and the 

consequent in the other (similar to the structure if-then in other languages). The first 

group of rules we analyze is useful to create the relationship between an assembly and the 

ArtifactAssociations it is composed of. 

Table 1 presents the ArtifactAssociation rules. We need four different rules because an 

ArtifactAssociation can connect both parts and assemblies. As already mentioned, we 

allow this because usually in the first stage of the product lifecycle we need to describe 

an assembly in general, without considering the individual parts by which it is composed. 

However in the manufacturing phase, we specifically need to describe the assembly. We 

want to allow both of these situations, but the drawback is the lack of information as to 

whether or not there will be a complete description of the subassemblies. 

Rule Antecedent Consequent

1 

artifactHasPart_direct(?x, ?y) 

Part(?y) 

artifactHasPart(?x, ?z) 

Part(?z) 

differentFrom(?y, ?z) 

part2ArtifactAssociation(?y, ?a)

part2ArtifactAssociation(?z, ?a)

Assembly2ArtifactAssociation(?x, ?a) 

2 

artifactHasPart_direct(?x, ?y) 

Assembly(?y) 

artifactHasPart_direct(?x, ?z) 

Assembly(?z) 

differentFrom(?y, ?z) 

artifactHasPart(?y, ?q) 

Part(?q) 

artifactHasPart(?z, ?r) 

Part(?r) 

differentFrom(?q, ?r) 

part2ArtifactAssociation(?q, ?a)

part2ArtifactAssociation(?r, ?a) 

Assembly2ArtifactAssociation(?x, ?a) 

3 

artifactHasPart_direct(?x, ?y) 

Assembly(?y) 

artifactHasPart_direct(?x, ?z) 

Assembly(?x) 

part2ArtifactAssociation(?y, ?a) 

part2ArtifactAssociation(?z, ?a) 

Assembly2ArtifactAssociation(?x, ?a) 

4 artifactHasPart_direct(?x, ?y) Assembly2ArtifactAssociation(?x, ?a) 
30

Assembly(?y) 

artifactHasPart_direct(?x, ?z) 

Part(?z) 

part2ArtifactAssociation(?y, ?a) 

part2ArtifactAssociation(?z, ?a) 

Table 1 Artifact Association rules 

The first rule is applied when the description of the assembly is complete (the 

AssemblyAssociation connects two or more Parts) and the assembly has at least one 

subassembly that is a part. The antecedent of the rule indicates that one Part is directly 

part of the Assembly while the other one is indirectly connected to the Assembly. 

Rule 2 is applied when the description is detailed but the ArtifactAssociation is between 

Parts that are not directly subassemblies of the Assembly. This means that the Assembly

will be composed by other subassemblies that will have Parts that are connected 

together. We ignore the levels here, because in the antecedent we explore the indirect 

property to search these parts in the subassemblies. 

Rule 3 is applied when the description is not detailed so the Assembly is composed by 

two or more subassemblies connected together. Rule 4 is similar to the third but is useful 

in the situations when we want to describe an assembly made by a part and a 

subassembly. 

The highlight of this ontology is that, given the components of the Assembly, we are able 

to connect the AssemblyAssociation to the Assembly. The drawback now is that we are 

unable to do the opposite, i.e., to reconstruct the structure of the Assembly having the 

associations by which it is composed. One solution here is to first input in the rule the 

property between Assembly and ArtifactAssociations and second the subassemblies that 

are connected through these associations. Further we do not know at which level of the 

assembly structure are the subassemblies. Let us take the example of an Assembly A 

composed by subassemblies B and C that are made by Part 1, 2, 3 and 4 respectively; the 

ArtifactAssociation exists between Part 2 and Part 3. In this case a rule like “if a part is 

part of an assembly and another part is partof another assembly, then connect these 

assemblies together to form the superassembly” will hold good, but the problem occurs 

when the superassembly is composed by three levels. If Assembly A is composed by 

subassemblies B and C that are made respectively by subassemblies D, E, F and G each 

having two Parts (from 1 to 8) the rule would infer that the Assembly A is defined by 

Assemblies D and F , without considering the upper level. We then need a rule to 

recognize the highest level in the hierarchy and then connect the Assemblies in this level 

with the superassembly through artifactPartOf_direct. With the inability to 

build complex constructs (like OR, NOT or XOR) with SWRL rules, these kind of 

recognitions are currently impossible. The alternate step is to automatically create the 

association at the features level. 

Table 2 presents the AssemblyFeatureAssociation rules. The first rule is applied when 

we have a complete description of an artifact, i.e., when the ArtifactAssociation

describes the relationship between two Parts. If these Parts have two Features that are 
31

connected with an AssemblyFeatureAssociation, then this association will be linked to 

the ArtifactAssociation between the Parts. 

Rule Antecedent Consequent

1 

artifactHasFeature(?x,?f) 

artifactHasFeature(?y, ?g) 

AFA2Feature(?w, ?f) 

AFA2Feature(?w, ?g) 

artifactAssociation2Part(?z, ?y) 

artifactAssociation2Part(?z, ?x) 

differentFrom(?x, ?y) 

differentFrom(?f, ?g) 

AssemblyFeatureAssociation2 

ArtifactAssociation(?w, ?z) 

2 

artifactHasFeature(?x, ?f) 

artifactHasFeature(?y, ?g) 

AFA2Feature(?w, ?f) 

AFA2Feature(?w, ?g) 

artifactAssociation2Part(?z, ?e) 

artifactAssociation2Part(?z, ?d) 

artifactHasPart(?d, ?x) 

Part(?x) 

Assembly(?d) 

artifactHasPart(?e, ?y) 

Part(?y) 

Assembly(?e) 

differentFrom(?e, ?d) 

differentFrom(?x, ?y) 

differentFrom(?f, ?g) 

AssemblyFeatureAssociation2 

ArtifactAssociation(?w,?z) 

3 

Feature(?f) 

Feature(?g) 

artifactHasFeature(?x, ?f) 

artifactHasFeature(?y, ?g) 

ArtifactAssociation(?z) 

AssemblyFeatureAssociation(?w) 

AFA2Feature(?w, ?f) 

AFA2Feature(?w, ?g) 

AssemblyFeatureAssociation2 

ArtifactAssociation(?w, ?z) 

differentFrom(?x, ?y) 

differentFrom(?f, ?g) 

artifactAssociation2Part(?z, ?x) 

artifactAssociation2Part(?z, ?y) 

Table 2 Assembly Feature Association rules 

The second rule is a little bit more complex because it represents the case in which the 

ArtifactAssociation is between two subassemblies and the Features are relative to the 

Parts that compose these subassemblies. The logic is the same but in this rule we have to 

specify the relationship between the features of the Parts of the subassemblies. 

The third rule is very similar to the first but the antecedent and the consequent have 

switched one part. In this case it's possible to say that if two Artifacts have two Features 

connected together through the AssemblyFeatureAssociation which by itself is linked to 

an ArtifactAssociation, this last association will link together the Artifacts owning the 

Features. 
32

Table 3 presents the AssemblyFeatureAssociationRepresentation rules. The last three 

rules are consequences of the first. Once a connection is created between two Features

with an element of the class AssemblyFeatureAssociation, and association connected 

with its representation, the first rule will link the representation to the Features. This will 

be the input for the other rules that will associate the Features with the specification of 

the representation (KinematicPair, KinematicPath, ParametricAssemblyConstraints). 

Rule Antecedent Consequent

1 

Feature(?f) 

AssemblyFeatureAssociationRepresentation(?z) 

AssemblyFeatureAssociation(?w) 

AFA2Feature(?w, ?f) 

AFA_2_AFAR(?w, ?z) 

AFAR_2_Feature(?z, ?f) 

2 

Feature(?f) 

AssemblyFeatureAssociationRepresentation(?z) 

AFAR_2_Feature(?z, ?f) 

AFAR_2_KinematicPair(?z, ?w) 

KinematicPair_2_Feature(?w, ?f) 

3 

Feature(?f) 

AssemblyFeatureAssociationRepresentation(?z) 

AFAR_2_Feature(?z, ?f) 

AFAR_2_KinematicPath(?z, ?w) 

KinematicPath_2_Feature(?w, ?f)

4 

Feature(?f) 

AssemblyFeatureAssociationRepresentation(?z) 

AFAR_2_Feature(?z, ?f) 

AFAR_2_ParamAssConstr(?z, ?w) 

ParamAssConstr_2_Feature(?w, 

?f) 

Table 3 Assembly Feature Association Representation rules 

Table 4 presents the KinematicPath rules. These rules are useful when we want to 

represent a composite path. In the first two rules a PathElement, connected with a 

Feature, has either another preceding or succeeding element; as a consequence the two 

KinematicPaths will be connected to the same Feature. The last two rules are similar to 

the previous ones but they analyze the structure on a higher level. They connect all the 

elements in the path to the same AssemblyFeatureAssociationRepresentation. 

Rule Antecedent Consequent

1 

PathHasConnection(?x, ?y) 

KinematicPath_2_Feature(?x, ?a)

NextPathElement(?y, ?z) 

KinematicPath_2_Feature(?z, ?a) 

2 

PathHasConnection(?x, ?y) 

KinematicPath_2_Feature(?x, ?a)

PreviousPathElement(?y, ?z) 

KinematicPath_2_Feature(?z, ?a) 

3 

PathHasConnection(?x, ?y) 

KinematicPath_2_AFAR(?x, ?a) 

NextPathElement(?y, ?z) 

KinematicPath_2_AFAR(?z, ?a) 

4 

PathHasConnection(?x, ?y) 

KinematicPath_2_AFAR(?x, ?a) 

PreviousPathElement(?y, ?z) 

KinematicPath_2_AFAR(?z, ?a) 

Table 4 Kinematic Path rules 
33

Table 5 presents the main association rule. This rule infers that if two EntityAssociations

x and w connect the same CoreEntities y and x, then the EntityAssociations are the 

same. This is necessary because we want to translate a binary property that unequivocally 

connects two entities. 

Antecedent Consequent 

entityAssociation2CoreEntity(?x, ?y) 

entityAssociation2CoreEntity(?x, ?z) 

differentFrom(?y, ?z) 

entityAssociation2CoreEntity(?w, ?y) 

entityAssociation2CoreEntity(?w, ?z) 

sameAs(?x, ?w) 

Table 5 SameAs rule 

We need just one rule because the property classes in the ontology are all children of the 

EntityAssociation class, so they will adhere to the rule. 

There are two partOf rules as shown in Table 6. Both are needed to link the Assembly

with all its Parts through the indirect property artifactHasPart. The advantage of 

these rules is that they do not run one after another but with a special algorithm that 

decomposes the structure of the Assembly. If we have several levels of the Assembly, 

the algorithm will apply the rules starting from the first subassembly composed by parts. 

Rule Consequent Antecedent 

1 artifactHasPart_direct(?x, ?y)

Part(?y) artifactHasPart(?x, ?y) 

2 

artifactHasPart_direct(?x, ?y)

Assembly(?y) 

artifactHasPart(?y, ?z) 

Part(?z) 

artifactHasPart(?x, ?z) 

Table 6 PartOf rules 

The last group of rules in Table 7 are needed to specify if the user explicitly wants to 

build something without a meaning. The first two rules provide a case in which an 

Artifact is a subassembly of itself, direct or not. The rules in Table 8 concerns the 

PairFrames. For a case in which we have a KinematicPair between two Features, the 

frames of this pair have to be associated with the same Features. Here, we can not use 

dynamic ranges or restrictions for the properties and hence we cannot constrain the user 

to specifically choose only between the Features that are connected with a 

KinematicPair. For this reason the rule will consider a PairFrame as meaningless when 

the user does something logically incorrect or when he uses a Feature to describe the 

frame even if the Feature is not included in the KinematicPair. 
34

Rule Antecedent Consequent 

1 artifactHasPart_direct(?x, ?x) meaning_less_artifact(?x) 

2 artifactHasPart(?x, ?x) meaning_less_artifact(?x) 

Table 7 Rules for not Allowed Artifacts 

Antecedent Consequent 

KinematicPair_2_Feature(?k, ?f) 

KinematicPair_2_Feature(?k, ?g) 

differentFrom(?f, ?g) 

pair_frame(?k, ?x) 

PairFrameAttribute2Feature(?x, ?h) 

differentFrom(?f, ?h) 

differentFrom(?g, ?h) 

PairFrame_meaning_less(?x) 

Table 8 Rule for not allowed Pair Frame 

After defining the model, the restrictions and the SWRL rules, the next step is to verify if 

it is well composed and if it can represent every condition/assembly. For this reason we 

choose a use case to underline advantages and disadvantages of the OWL version of the 

Open Assembly Model. 

6 Case study: Planetary Gear System 

This section illustrates the implementation of an industrial example used to test the OAM 

ontology. The assembly model of a planetary gear system is modeled using a Computer 

Aided Design (CAD) system. Section 6.1 is dedicated to explain the reasons that have led 

to the selection of this particular assembly and related description. Section 6.2 presents 

the implementation and instantiation of the model, together with the reasoning 

capabilities performed by RACER and Jess. 

6.1 Use Case Description 

The Planetary Gear System is an electromechanical component normally used to change 

the rotation speed or the torque of a shaft. In this example our aim is to represent a 

scenario of an assembly representation to outline assembly complexity but at the same 

time not to complicate the example itself. Moreover, the same example had been 

previously used during the instantiation of the OAM-UML model. 

The System consists of 4 subassemblies with almost 30 different parts. As with any 

electromechanical component, tolerances are specifically defined for all parts. In the 

chosen planetary gear system, the connection and pairs between different artifacts are of 

different types. 
35

6.1.1 Components in Planetary Gear System 

The solid model of the planetary gear system is shown in Figure 19. 

Figure 19 Planetary Gear System 

The planetary gear system consists of many components. Figure 20 shows the exploded 

view of the above solid model. The list of all the components of the planetary gear 

system is given in Table 9. 

Figure 20 Exploded view of the Planetary Gear System

6.1.2 Assembly Hierarchy 

We first need to define an assembly hierarchy for the planetary gear system. The 

planetary gear system is composed of two parts and three sub-assemblies as shown in 

Figure 20. The parts include the input-housing and the sungear. The three subassemblies 

include: (1) the output end assembly comprising two bearings, a washer, and the output 

housing; (2) the ring gear assembly comprising a ring gear and two ring-gear pins; and 

(3) the planet gear holder assembly comprising three planet gears and a planet carrier 

assembly, which further decomposes into the output shaft and three planet-gear pins. 
36

Table 9 Components of the Planetary Gear System 
37

Figure 21 Planetary Gear structure 

The hierarchical relationships between the components of the planetary gear system can 

be represented as an instance diagram as shown in Figure 22. The names take the form of 

"instance name:class name". The root node is the entire assembly, the interior nodes are 

sub- assemblies, and the leaf nodes are component parts. 
38

Figure 22 Planetary Gear hierarchy

The connections between parts are presented in the Figure 23. The naming conventions 

are related to the types of possible connections (fc: fixed connection, mc: movable 

connection, po: position orientation). These connections between parts are represented in 

the model through instances of the class ArtifactAssociation. 
39

Figure 23 Connections between parts

6.1.2.1 Output Housing Assembly 

Figure 24 shows the subassembly and the output housing (the output end of the planetary 

gear system). It consists of four parts: bearing 1, bearing 2, washer, and output housing. 

The washer goes to the inner groove of the output housing. Both bearings (ball bearings) 

go into the output housing on either side of the washer with a tight fit. Bearing 1 stays 

outside, and Bearing 2 stays inside of the planetary gear system. 

Figure 24 Output Housing Assembly 
40

6.1.2.2 Ring Gear Assembly 

The second subassembly is the ring gear assembly, shown in Figure 25. It consists of 

three parts: ring gear, and ring-gear pins 1 and 2. The two ring-gear pins go into the 

pinholes of the ring gear with a tight fit. 

Figure 25 Ring Gear Assembly 

6.1.2.3 Planet Gear-carrier Assembly 

The planet gear-carrier assembly shown in Figure 26 is comprised of four parts: three 

planet gears and one planet carrier assembly. The three planet gears are assembled by a 

loose fit with the planet-gear pins of the planet carrier assembly. 

Figure 26 Planet Gear-carrier Assembly 

6.1.2.4 Planet Carrier Assembly and Sungear 

The planet carrier assembly in Figure 27 is comprised of four parts: three planet-gear pins 

and an output shaft. The three planet-gear pins are assembled with output shaft by a tight 

fit. The sungear is assembled with the three planet gears of the planet gear-carrier 

assembly by gear meshing. 
41

Figure 27 Planet Carrier Assembly and Sungear

6.1.2.5 Output Housing Assembly 

Consider the output housing assembly and planet gear-carrier assembly shown in Figure 

28. 

Figure 28 Output Housing Assembly

The output shaft of the planet gear-assembly is inserted into the bearings of the output 

housing assembly. 

6.2 Use Case Implementation 

In this section, the use case implementation is presented. For explanation of the Planetary 

Gear System example, the structure of the ontology will be followed and every class will 

be presented twice with its instances and properties. Accordingly, this section is divided 

into two main parts: Input Instances and Output Instances. Note that the whole model is 

composed by 145 classes, 200 properties, 70 restrictions on properties used for the class 

definitions and 25 different SWRL rules. The classes that are omitted in this explanation 

of the OAM ontology are either simply used to store information or are simple 
42

specifications of the presented classes or properties. The total number of instances needed 

for the use case description is approximately 250. 

6.2.1 Asserted Instances and Properties 

In this section, each class is presented with the instances and the input properties needed 

for the basic population of the model. The elements inserted in the models are necessary 

for the subsequent reasoning on the ontology. In most cases, the properties in the model 

have an inverse: the user has to only instantiate the property on one direction because the 

other is automatically constituted by the editor. In the following tables all the properties 

for every class are shown.

6.2.1.1 Asserted Artifact Instances and Properties 

The class Artifact has four subclasses: Assembly, Meaningless_Artifact, Connecter

and Part. The reasoning capabilities of the model allow us to create all the instances of 

Assembly directly as Artifacts and then infer them as instances of Assembly. This is 

possible defining an Assembly as an Artifact composed by at least two subassemblies 

(through restriction on the property artifactHasPart_direct. 

The input instances of the class Artifact are presented in Table 10. In the first column of 

the table are the instances of artifact. In the other columns, are the instances of the related 

classes linked through the property that names these columns. From the table, notice that 

the Output_Housing_Assembly is incorrectly defined i.e., composed by itself (*). This 

error is purposely introduced for testing the reasoning capabilities of the ontology in 

sections 5.2.1.3 (Meaning_Less_Artifact Input) and 5.2.2.3 

(Meaning_Less_Artifact Output). 

 Asserted Properties 

Artifact Instances artifactHasPart_direct 

(D:Artifact R:Artifact) 

cpm2:partOfArtifact_direct 

(D:Artifact R:Artifact) 

Output_Housing_Assembly 

Bearing_1 

Bearing_2 

Output_Housing 

Washer 

Output_Housing_Assembly*

Planetary_Gear 

System_Assembly 

Planet_Carrier_Assembly 

Output_Shaft 

Planet_Gear_Pin_1 

Planet_Gear_Pin_2 

Planet_Gear_Pin_3 

Planetary_Gear 

Carrier_Assembly 

Planet_Gear 

Carrier_Assembly 

Planet_Gear_1 

Planet_Gear_2 

Planet_Gear_3 

Planet_Carrier_Assembly 

Planetary_Gear 

System_Assembly 

Ring_Gear_Assembly 

Ring_Gear 

Ring_Gear_Pin_1 

Ring_Gear_Pin_2 

Planetary_Gear 

System_Assembly 

Planetary_Gear 

System_Assembly 

Output_Housing_Assembly 

Planet_Carrier_Assembly 

Planet_Gear_Carrier_Assembly 

-- 
43

Ring_Gear_Assembly 

Sungear 

Input_Housing 

Screw_1 

Screw_2 

Screw_3 

Screw_4 

Screw_5 

Screw_6 

Screw_7 

Screw_8 

Table 10 Artifact: asserted instances and properties

6.2.1.2 Asserted Assembly Instances and Properties 

It is possible to assert all instances of the class Assembly as instances of the class 

Artifact and let the reasoner (in this case RACER) reclassify the instances. At this point 

the class Assembly is empty. 

6.2.1.3 Asserted Meaning_Less_Artifact Instances and Properties 

This class is created for managing the impossibility of blocking the creation of a selfreference in the current version of Protégé-OWL. In the current model it is possible to 

define an instance of Assembly composed by itself. Presently, there is no direct solution 

and hence the class “Meaning_Less_Artifact” is created. For demonstration purposes 

the wrong definition of the Output_Housing_Assembly is introduced for testing the 

capability of the ontology to identify this kind of error (see 5.2.1.1 for details). Thanks to 

the SWRL rules (see section 4.2 for details) created with an aim to reclassify the wrongly 

defined instances (see section 5.2.2.3 for details). At the instantiation step this class is 

empty. 

6.2.1.4 Asserted Part Instances and Properties 

Although the class Part is a subclass of the class Artifact, it is not possible to assert the 

instances of the different parts as instances of Artifact and later infer them as instances 

of Part as with the case of the instances of Assembly. This is due to the limitation with 

OWL: it is impossible to define a class as a class without a property. An instance of Part 

is an Artifact that is not composed by any other Parts but for a reasoner an Artifact 

without a property (in this case artifactHasPart_direct) is not an instance of 

Part but only an instance of Artifact not yet completely defined. For this reason all the 

parts are created directly in the class Part. 

The asserted instances and properties for the class Part are shown in Table 11. 
44

 Asserted Properties 

Part Instances partOfArtifact_direct 

(D:Artifact R:Artifact) 

artifactHasFeature 

(D:Artifact 

R:Feature) 

part2ArtifactAssociation 

(D:Part 

R:ArtifactAssociation) 

Bearing_1 Output_Housing_Assembly Inner_Race_1 

Outer_Race_1 

fc_2 

mc_4 

Bearing_2 Output_Housing_Assembly Inner_Race_2 

Outer_Race_2 

fc_3 

mc_4 

Input_Housing Planetary_Gear_System_Assembly 

Stepped_Side 

Thru_Hole_5 

Thru_Hole_6 

Thru_Hole_7 

Thru_Hole_8 

fc_12 

fc_13 

Output_Housing Output_Housing_Assembly 

Bearing_Seat_1 

Bearing_Seat_2 

Groove 

pin_Hole_9 

pin_Hole_10 

Thru_Hole_1 

Thru_Hole_2 

Thru_Hole_3 

Thru_Hole_4 

fc_1 

fc_2 

fc_3 

fc_4 

fc_10 

fc_11 

Output_Shaft Planet_Carrier_Assembly 

Bearing_Seat_3 

Output_Shaft_Feature 

pin_Hole_3 

pin_Hole_4 

pin_Hole_5 

fc_7 

fc_8 

fc_9 

mc_4 

po_1 

Planet_Gear_1 Planet_Gear_Carrier_Assembly 

pin_Cylinder_3 

teeth_7 

teeth_8 

mc_1 

mc_5 

mc_9 

Planet_Gear_2 Planet_Gear_Carrier_Assembly pin_Hole_7, teeth_9, 

 teeth_10 mc_2, mc_6, mc_10 

Planet_Gear_3 Planet_Gear_Carrier_Assembly pin_Hole_8, teeth_11, 

teeth_12 mc_3, mc_7, mc_11 

Planet_Gear_Pin_1 Planet_Carrier_Assembly pin_Cylinder_3, 

pin_Cylinder_6 mc_1, fc_5, fc_7 

Planet_Gear_Pin_2 Planet_Carrier_Assembly pin_Cylinder_4, 

pin_Cylinder_7 mc_2, fc_8 

Planet_Gear_Pin_3 Planet_Carrier_Assembly pin_Cylinder_5, 

pin_Cylinder_8 mc_3, fc_9 

Ring_Gear Ring_Gear_Assembly 

pin_Hole_1, 

pin_Hole_2 

Ring_Gear_Side 

teeth_4, teeth_5, 

teeth_6 

threaded_Hole_1 

hreaded_Hole_2 

threaded_Hole_3 

threaded_Hole_4 

mc_9, mc_10 

mc_11, fc_5 

fc_6, fc_11 

fc_12, fc_13 

Ring_Gear_Pin_1 Ring_Gear_Assembly 

pin_Cylinder_1, 

 pin_Cylinder_5 

pin_Cylinder_9 

fc_5 

fc_10 

Ring_Gear_Pin_2 Ring_Gear_Assembly 

pin_Cylinder_2, 

pin_Cylinder_7 

pin_Cylinder_10 

fc_6 

fc_10 

Screw_1 Planetary_Gear_System_Assembly thread_1 fc_11 

Screw_2 Planetary_Gear_System_Assembly thread_2 fc_11 
45

Screw_3 Planetary_Gear_System_Assembly thread_3 fc_11 

Screw_4 Planetary_Gear_System_Assembly thread_4 fc_11 

Screw_5 Planetary_Gear_System_Assembly thread_5 fc_11 

Screw_6 Planetary_Gear_System_Assembly thread_6 fc_11 

Screw_7 Planetary_Gear_System_Assembly thread_7 fc_11 

Screw_8 Planetary_Gear_System_Assembly thread_8 fc_11 

Washer Output_Housing_Assembly Outer_Rim fc_1 

Sungear Planetary_Gear_System_Assembly 

DatumFeature_Axis1 

Sun_Gear_Feature, 

 teeth_1, 

teeth_2, teeth_3, 

Input_Shaft 

mc_5, mc_6, mc_7 

mc_8, po_1 

Table 11 Part: asserted instances and properties

6.2.1.5 Asserted Features Instances and Properties 

The class Feature has the same level of the class Artifact (both of them are children of 

CoreEntity)and stores the instances that represent the features of the single parts. This 

class has two direct subclasses Port and OAMFeature. Class OAMFeature further has 

two subclasses used to represent the reference features as DatumFeatures. Table 12 

presents the instances of the class OAMFeatures that participate in the creation of the 

assemblies through the different types of connections. 

 Asserted Properties 

OAMFeatures 

Instances 

FeatureOfArtifact 

(D:Feature R:Artifact) 

feature2AFA 

(D:Feature R:AFA) 

feature2AFAR 

(D:Feature R:AFAR) 

Bearing_Seat_1 Output_Housing AFA_fc2 AFAR_fc2 

Bearing_Seat_2 Output_Housing AFA_fc3 AFAR_fc3 

Bearing_Seat_3 Output_Shaft AFA_mc4 AFAR_mc4 

Groove Output_Housing AFA_fc1 AFAR_fc1 

Inner_Race_1 Bearing_1 AFA_mc4 AFAR_mc4 

Inner_Race_2 Bearing_2 AFA_mc4 AFAR_mc4 

Outer_Race_1 Bearing_1 AFA_fc2 AFAR_fc2 

Outer_Race_2 Bearing_2 AFA_fc3 AFAR_fc3 

Outer_Rim Washer AFA_fc1 AFAR_fc1 

Output_Shaft_Feature Output_Shaft AFA_po1 AFAR_po1 

pin_Cylinder_1 Ring_Gear_Pin_1 AFA_fc5 AFAR_fc5 

pin_Cylinder_2 Ring_Gear_Pin_2 AFA_fc6 AFAR_fc6 

pin_Cylinder_3 Planet_Gear_1 AFA_fc7 AFAR_fc7 

pin_Cylinder_4 Planet_Gear_Pin_2 AFA_fc8 AFAR_fc8 

pin_Cylinder_5 Planet_Gear_Pin_3 AFA_fc9 AFAR_fc9 
46

pin_Cylinder_6 Ring_Gear_Pin_1 AFA_mc1 AFAR_mc1 

pin_Cylinder_7 Planet_Gear_Pin_2 AFA_mc2 AFAR_mc2 

pin_Cylinder_8 Planet_Gear_Pin_3 AFA_mc3 AFAR_mc3 

pin_Cylinder_9 Ring_Gear_Pin_1 AFA_fc10 AFAR_fc10 

pin_Cylinder_10 Ring_Gear_Pin_2 AFA_fc10 AFAR_fc10 

pin_Hole_1 Ring_Gear AFA_fc5 AFAR_fc5 

pin_Hole_2 Ring_Gear AFA_fc6 AFAR_fc6 

pin_Hole_3 Output_Shaft AFA_fc7 AFAR_fc7 

pin_Hole_4 Output_Shaft AFA_fc8 AFAR_fc8 

pin_Hole_5 Output_Shaft AFA_fc9 AFAR_fc9 

Pin_Hole_6 Ring_Gear_Pin_2 AFA_mc1 AFAR_mc1 

pin_Hole_7 Planet_Gear_2 AFA_mc2 AFAR_mc2 

pin_Hole_8 Planet_Gear_3 AFA_mc3 AFAR_mc3 

pin_Hole_9 Output_Housing AFA_fc10 AFAR_fc10 

pin_Hole_10 Output_Housing AFA_fc10 AFAR_fc10 

Ring_Gear_Side Ring_Gear AFA_fc12 AFAR_fc12 

Stepped_Side Input_Housing AFA_fc12 AFAR_fc12 

Sun_Gear_Feature Sungear AFA_po1 AFAR_po1 

teeth_1 Sungear AFA_mc5 AFAR_mc5 

teeth_2 Sungear AFA_mc6 AFAR_mc6 

teeth_3 Sungear AFA_mc7 AFAR_mc7 

teeth_4 Ring_Gear AFA_mc9 AFAR_mc9 

teeth_5 Ring_Gear AFA_mc10 AFAR_mc10 

teeth_6 Ring_Gear AFA_mc11 AFAR_mc11 

teeth_7 Planet_Gear_1 AFA_mc5 AFAR_mc5 

teeth_8 Planet_Gear_1 AFA_mc9 AFAR_mc9 

teeth_9 Planet_Gear_2 AFA_mc6 AFAR_mc6 

teeth_10 Planet_Gear_2 AFA_mc10 AFAR_mc10 

teeth_11 Planet_Gear_3 AFA_mc7 AFAR_mc7 

teeth_12 Planet_Gear_3 AFA_mc11 AFAR_mc11 

thread_1 Screw_1 AFA_fc11 AFAR_fc11 

thread_2 Screw_2 AFA_fc11 AFAR_fc11 

thread_3 Screw_3 AFA_fc11 AFAR_fc11 

thread_4 Screw_4 AFA_fc11 AFAR_fc11 

thread_5 Screw_5 AFA_fc13 AFAR_fc13 

thread_6 Screw_6 AFA_fc13 AFAR_fc13 

thread_7 Screw_7 AFA_fc13 AFAR_fc13 

thread_8 Screw_8 AFA_fc13 AFAR_fc13 

AFA_fc11 AFAR_fc11 

threaded_Hole_1 Ring_Gear AFA_fc13 AFAR_fc13 
47

AFA_fc11 AFAR_fc11 

threaded_Hole_2 Ring_Gear AFA_fc13 AFAR_fc13 

AFA_fc11 AFAR_fc11 

threaded_Hole_3 Ring_Gear AFA_fc13 AFAR_fc13 

AFA_fc11 AFAR_fc11 

threaded_Hole_4 Ring_Gear AFA_fc13 AFAR_fc13 

Thru_Hole_1 Output_Housing AFA_fc11 AFAR_fc11 

Thru_Hole_2 Output_Housing AFA_fc11 AFAR_fc11 

Thru_Hole_3 Output_Housing AFA_fc11 AFAR_fc11 

Thru_Hole_4 Output_Housing AFA_fc11 AFAR_fc11 

Thru_Hole_5 Input_Housing AFA_fc13 AFAR_fc13 

Thru_Hole_6 Input_Housing AFA_fc13 AFAR_fc13 

Thru_Hole_7 Input_Housing AFA_fc13 AFAR_fc13 

Thru_Hole_8 Input_Housing AFA_fc13 AFAR_fc13 

Table 12 OAM Features: asserted instances

6.2.1.6 Asserted ArtifactAssociation Instances and Properties 

An Assembly can be composed by several Parts and the simple enumeration of them is 

represented through the properties artifactHasPart and 

artifactHasPart_direct. The class ArtifactAssociation and its subclasses 

(Connection, PositionOrientation and RelativeMotion) are used to represent the 

relationship between the Parts that are connected for creating an Assembly . The class 

Connection further has three subclasses FixedConnections, IntermittentConnections

and MovableConnections. 

For example, as an instance of Assembly, Ring_Gear_Assembly is composed by the parts 

Ring_Gear, Ring_Gear_Pin_1and Ring_Gear_Pin_2. This information does not provide 

any information on the relation between these parts. However, the two instances of the 

class FixedConnection (sub-class of ArtifactAssociation) fc_5 and fc_6 represents the 

real assembly configuration. The instance fc_5 links the Ring_Gear and the 

Ring_Gear_Pin_1 and fc_6 links the Ring_Gear and the Ring_Gear_Pin_2. In this way it 

is possible to fully represent the Ring_Gear_Assembly structure. 

In the FixedConnection class, only the relations between its instances and the parts 

linked to it have to be asserted. The other properties will be inferred by the reasoner 

through the SWRL rules. 

The asserted instances and properties are listed in Table 13. For every instance the 

subclass of pertinence is specified through the name (fc:FixedConnection

mc:MovableConnection po:PositionOrientation). 
48

Asserted Properties Asserted Properties 

ArtifactAssociation 

 Instances 

artifactAssociation2Part 

 (D:AA R:Part) 

ArtifactAssociation

 Instances 

artifactAssociation2Part 

(D:AA R:Part) 

fc1 Washer fc13 Screw_7 

fc2 Output_Housing fc13 Screw_8 

fc2 Bearing_1 fc13 Ring_Gear 

fc3 Output_Housing fc13 Ring_Gear 

fc3 Bearing_2 fc13 Ring_Gear 

fc5 Ring_Gear_Pin_1 fc13 Ring_Gear 

fc5 Ring_Gear fc13 Input_Housing 

fc6 Ring_Gear_Pin_2 fc13 Input_Housing 

fc6 Ring_Gear fc13 Input_Housing 

fc7 Planet_Gear_1 fc13 Input_Housing 

fc7 Output_Shaft mc1 Ring_Gear_Pin_1 

fc8 Planet_Gear_Pin_2 mc1 Ring_Gear_Pin_2 

fc8 Output_Shaft mc2 Planet_Gear_Pin_2 

fc9 Planet_Gear_Pin_3 mc2 Planet_Gear_2 

fc9 Output_Shaft mc3 Planet_Gear_Pin_3 

fc10 Ring_Gear_Pin_1 mc3 Planet_Gear_3 

fc10 Ring_Gear_Pin_2 mc4 Output_Shaft 

fc10 Output_Housing mc4 Bearing_1 

fc10 Output_Housing mc4 Bearing_2 

fc11 Screw_1 mc5 Sungear 

fc11 Screw_2 mc5 Planet_Gear_1 

fc11 Screw_3 mc6 Sungear 

fc11 Screw_4 mc6 Planet_Gear_2 

fc11 Ring_Gear mc7 Sungear 

fc11 Ring_Gear mc7 Planet_Gear_3 

fc11 Ring_Gear mc9 Ring_Gear 

fc11 Ring_Gear mc9 Planet_Gear_1 

fc11 Output_Housing mc10 Ring_Gear 

fc11 Output_Housing mc10 Planet_Gear_2 

fc11 Output_Housing mc11 Ring_Gear 

fc11 Output_Housing mc11 Planet_Gear_3 

fc12 Ring_Gear 

fc12 Input_Housing Po1 Output_Shaft 

Fc13 Screw_5 po1 Sungear 

Table 13 ArtifactAssociation: asserted instances and properties

6.2.1.7 Asserted AssemblyFeatureAssociation Instances and Properties 

The AssemblyFeatureAssociation class has the same aim of ArtifactAssociation but at 

the feature level. If two parts are connected through an instance of ArtifactAssociation 

(e.g. fc_1) then two Features of these parts have to be connected through an instance of 

AssemblyFeatureAssociation (e.g., AFA_fc1). This class has two properties 

AFA2Feature and AFA_2_AFAR. The property AFA2Feature has the similar 

function as ArtifactAssociation2Part and links at least two Features realizing 

an assembly constituted of two parts. The property AFA_2_AFAR links the instances of 

AssemblyFeatureAssociation with AssemblyFeatureAssociationRepresentation. 
49

The AssemblyFeatureAssociationRepresentation class is used to connect the Features

with several classes used in tolerances and geometric representations. The asserted 

instances and properties are shown in Table 14.

Asserted Properties 

AFA Instances

AFA_2_AFAR 

(D:AFA R:AFAR)

AFA2Feature 

(D:AFA R:Feature) 

Groove 

AFA_fc1 AFAR_fc1 

Outer_Rim 

Bearing_Seat_1 AFA_fc2 AFAR_fc2 

Outer_Race_1 

Bearing_Seat_2 AFA_fc3 AFAR_fc3 

Outer_Race_2 

pin_Cylinder_1 

pin_Hole_1 

pin_Cylinder_2 

AFA_fc5 AFAR_fc5 

pin_Hole_2 

pin_Cylinder_3 AFA_fc7 AFAR_fc7 

pin_Hole_3 

pin_Cylinder_4 AFA_fc8 AFAR_fc8 

pin_Hole_4 

pin_Cylinder_5 AFA_fc9 AFAR_fc9 

pin_Hole_5 

pin_Cylinder_9 

pin_Cylinder_10 

pin_Hole_9 

AFA_fc10 AFAR_fc10 

pin_Hole_10 

thread_1 

thread_2 

thread_3 

thread_4 

threaded_Hole_1 

threaded_Hole_2 

threaded_Hole_3 

threaded_Hole_4 

Thru_Hole_1 

Thru_Hole_2 

Thru_Hole_3 

AFA_fc11 AFAR_fc11 

Thru_Hole_4 

AFA_fc12 AFAR_fc12 Ring_Gear_Side 
50

Stepped_Side 

thread_5 

thread_6 

thread_7 

thread_8 

threaded_Hole_1 

threaded_Hole_2 

threaded_Hole_3 

threaded_Hole_4 

Thru_Hole_5 

Thru_Hole_6 

Thru_Hole_7 

AFA_fc13 AFAR_fc13 

Thru_Hole_8 

pin_Cylinder_6 AFA_mc1 AFAR_mc1 

Pin_Hole_6 

pin_Cylinder_7 AFA_mc2 AFAR_mc2 

pin_Hole_7 

pin_Cylinder_8 AFA_mc3 AFAR_mc3 

pin_Hole_8 

Bearing_Seat_3 

AFA_mc4 AFAR_mc4 Inner_Race_1 

Inner_Race_2 

teeth_1 

AFA_mc5 AFAR_mc5 

teeth_7 

teeth_2 

AFA_mc6 AFAR_mc6 teeth_9 

teeth_3 

AFA_mc7 AFAR_mc7 teeth_11 

teeth_4 

AFA_mc9 AFAR_mc9 teeth_8 

teeth_5 

AFA_mc10 AFAR_mc10 teeth_10 

teeth_6 

AFA_mc11 AFAR_mc11 

teeth_12 

Output_Shaft_Feature AFA_po1 AFAR_po1 Sun_Gear_Feature 

Table 14 AssemblyFeatureAssociation: asserted instances and properties
51

6.2.1.8 Asserted AssemblyFeatureAssociationRepresentation Instances 

and Properties 

This class is used to link the Features with the geometric representation and tolerance 

specifications. For the correct connection between the Features and the detailed 

information cited before, two properties are specified for this class: AFAR_2_AFA and 

AFAR_2_Feature. The first has to be asserted. The second will be inferred. (see Table 

15). 

 Asserted Properties Asserted Properties 

AFAR Instances

AFAR_2_AFA 

(D:AFAR R:AFA)

AFAR Instances

AFAR_2_AFA 

(D:AFAR R:AFA)

AFAR_fc1 AFA_fc1 AFAR_mc1 AFA_mc1 

AFAR_fc2 AFA_fc2 AFAR_mc2 AFA_mc2 

AFAR_fc3 AFA_fc3 AFAR_mc3 AFA_mc3 

AFAR_fc5 AFA_fc5 AFAR_mc4 AFA_mc4 

AFAR_fc7 AFA_fc7 AFAR_mc5 AFA_mc5 

AFAR_fc8 AFA_fc8 AFAR_mc6 AFA_mc6 

AFAR_fc9 AFA_fc9 AFAR_mc7 AFA_mc7 

AFAR_fc10 AFA_fc10 AFAR_mc9 AFA_mc9 

AFAR_fc11 AFA_fc11 AFAR_mc10 AFA_mc10 

AFAR_fc12 AFA_fc12 AFAR_mc11 AFA_mc11 

AFAR_fc13 AFA_fc13 AFAR_po1 AFA_po1 

Table 15 AssemblyFeatureAssociationRepresentation: asserted instances and 

properties

6.2.2 Inferred Instances and Properties 

In this section the output instances of each class will be presented. The term output 

instances refer to the instances that are inferred with the reasoning software (RACER or 

Jess) and the SWRL rules. 

6.2.2.1 Inferred Artifact Properties 

After the reasoning with RACER and Jess the input instances of Artifact are inferred 

(thanks to RACER) as instances of the class Assembly. For details see the following 

section. 

6.2.2.2 Inferred Assembly Properties 

After reasoning, the class Assembly is not empty anymore (see Table 16). The reasoning 

performed by RACER on the restriction defined for this class on the property 
52

artifactHasPart_direct min 2 has inferred the instances asserted in the class 

Artifact as elements of the class Assembly. 

The Jess reasoning based on the SWRL (see section 5.2 for more details) rules has 

inferred not only the parts that constitute every instance of Assembly but also its related 

instances of ArtifactAssociation (see 6.2.1.1 for details on the reflexive definition of 

Output_Housing_Assembly). 

 Inferred Properties 

Assembly Instances 

artifactHasPart 

(D:Artifact R:Artifact) 

assembly2ArtifactAssociation 

(D:Assembly 

R:ArtifactAssociation) 

Output_Housing_Assembly 

Bearing_1 

Bearing_2 

Output_Housing 

Washer 

Output_Housing_Assembly*

fc_1 

fc_2 

fc_3 

mc_4 

Planet_Carrier_Assembly 

Output_Shaft 

Planet_Gear_Pin_1 

Planet_Gear_Pin_2 

Planet_Gear_Pin_3 

fc_7 

fc_8 

fc_9 

Planet_Gear_Carrier_Assembly 

Planet_Gear_1 

Planet_Gear_2 

Planet_Gear_3 

Planet_Carrier_Assembly 

mc_1 

mc_2 

mc_3 

Ring_Gear_Assembly 

Ring_Gear 

Ring_Gear_Pin_1 

Ring_Gear_Pin_2 

fc_6 

fc_10 

Planetary_Gear_System_Assembly 

Bearing_1 

Bearing_2 

Output_Housing 

Washer 

Output_Shaft 

Planet_Gear_Pin_1 

Planet_Gear_Pin_2 

Planet_Gear_Pin_3 

Planet_Gear_1 

Planet_Gear_2 

Planet_Gear_3 

Ring_Gear 

Ring_Gear_Pin_1 

Ring_Gear_Pin_2 

Sungear 

Input_Housing 

Screw_1 

Screw_2 

Screw_3 

Screw_4 

Screw_5 

Screw_6 

Screw_7 

mc_1 

mc_2 

mc_3 

mc_4 

mc_5 

mc_6 

mc_7 

mc_9 

mc_10 

mc_11 

po_1 

fc_5 

fc_7 

fc_8 

fc_9 

fc_10 

fc_11 

fc_12 

fc_13 
53

Screw_8 

Table 16 Assembly inferred properties 

6.2.2.3 Inferred Meaning_Less_Artifact Instances 

After the Jess reasoning, the Meaning_Less_Artifact class (see Section 5.2.1.3) is no 

longer empty. Two instances of the class Artifact are reclassified as not well defined. In 

Table 17 the reclassified instances are presented. 

Meaning_Less_Artifact Instances 

Output_Housing_Assembly 

Planetary_Gear_System_Assembly 

Table 17 Meaning_Less_Artifact inferred instances

As expected, the instance (Output_Housing_Assembly) with a self reference 

(inadmissible in assembly representation) is reclassified as element of this class. Also 

notice that the Planetary_Gear_System_Assembly is reclassified to this class since the 

inadmissible Output_Housing_Assembly is a sub-assembly of the 

Planetary_Gear_System_Assembly. 

6.2.2.4 Inferred Part Properties 

After the Jess engine reasoning, the indirect property partOfArtifact, inverse of 

the property artifactHasPart, is inferred for each instance. For example, the 

instance Bearing_1 is directly a part of the Output_Housing_Assembly, which in turn is a 

part of the Planetary_Gear_System_Assembly. The Bearing_1 is inferred both as part of 

the Output_Housing_Assembly and Planetary_Gear_System_Assembly. The inferred 

properties are presented in Table 18.

 Inferred Instances 

Part Instances partOfArtifact 

(D:Artifact R:Artifact) 

Bearing_1- 2 Output_Housing_Assembly 

Planetary_Gear_System_Assembly 

Input Housing Planetary_Gear_System_Assembly 

Output_Housing Output_Housing_Assembly 

Planetary_Gear_System_Assembly 

Output_Shaft 

Planet_Carrier_Assembly 

Planet_Gear_Carrier_Assembly 

Planetary_Gear_System_Assembly 

Planet_Gear_1 - 3 Planet_Gear_Carrier_Assembly 

Planetary_Gear_System_Assembly 

Planet_Gear_Pin_1 -3 

Planet_Carrier_Assembly 

Planet_Gear_Carrier_Assembly 

Planetary_Gear_System_Assembly 
54

Ring_Gear Ring_Gear_Assembly 

Planetary_Gear_System_Assembly 

Ring_Gear_Pin_1- 2 Ring_Gear_Assembly 

Planetary_Gear_System_Assembly 

Screw_1 – Screw 8 Planetary_Gear_System_Assembly 

Sungear Planetary_Gear_System_Assembly 

Washer Output_Housing_Assembly 

Planetary_Gear_System_Assembly 

Table 18 Part: inferred properties 

6.2.2.5 Inferred Feature Instances and Properties 

The class Feature has to be completely defined from the beginning. As this is the lowest 

level of the representation, it is not possible to infer anything about the Features from the 

structure of the Assemblies. 

6.2.2.6 Inferred ArtifactAssociation Properties 

With the SWRL rules the Jess reasoning engine is able to infer the properties: 

artifactAssociation2Assembly and 

artifactAssociation2AssemblyFeatureAssociation. The first is the 

inverse of the property assembly2ArtifactAssociation inferred for the class 

Assembly. The second is the property that links the instances of this class with the ones 

of the class AssemblyFeatureAssociation that has the same rules of the class 

ArtifactAssociation but on the features level (Table 19). 

Inferred Properties 

ArtifactAssociation 

Instancies

artifactAssociation2Assembly 

(D:Artifact R:Assembly) 

artifactAssociation2AFA 

(D:ArtifactAssociation 

R:AssemblyFeatureAssociation) 

fc_1 Output_Housing_Assembly AFA_fc1 

fc_2 Output_Housing_Assembly AFA_fc2 

fc_3 Output_Housing_Assembly AFA_fc3 

fc_3 Output_Housing_Assembly AFA_fc3 

fc_5 Planetary_Gear_System_Assembly AFA_fc5 

fc_6 Ring_Gear_Assembly AFA_fc6 

fc_7 Planet_Carrier_Assembly AFA_fc7 

fc_8 Planet_Carrier_Assembly AFA_fc8 

fc_9 Planet_Carrier_Assembly AFA_fc9 

AFA_fc10 fc_10 Ring_Gear_Assembly 

AFA_mc1 

fc_11 Planetary_Gear_System_Assembly AFA_fc11 

AFA_fc12 fc_12 Planetary_Gear_System_Assembly

AFA_fc13 
55

AFA_fc12 fc_13 Planetary_Gear_System_Assembly

AFA_fc13 

mc_1 Planet_Gear_Carrier_Assembly AFA_mc1 

mc_2 Planet_Carrier_Assembly AFA_mc2 

mc_3 Planet_Gear_Carrier_Assembly AFA_mc3 

mc_4 Output_Housing_Assembly AFA_mc4 

mc_5 Planetary_Gear_System_Assembly AFA_mc5 

mc_6 Planetary_Gear_System_Assembly AFA_mc6 

mc_7 Planetary_Gear_System_Assembly AFA_mc7 

mc_9 Ring_Gear_Assembly AFA_mc9 

mc_10 Planet_Gear_Carrier_Assembly AFA_mc10 

mc_10 Planet_Gear_Carrier_Assembly AFA_mc10 

mc_11 Planet_Gear_Carrier_Assembly AFA_mc11 

po_1 Planetary_Gear_System_Assembly AFA_po1 

po_1 Planet_Carrier_Assembly AFA_po1 

Table 19 ArtifactAssociation: inferred properties

6.2.2.7 Inferred AssemblyFeatureAssociation Properties 

After the reasoning, the property between the two classes AssemblyFeatureAssociation

and ArtifactAssociation is inferred 

(AssemblyFeatureAssociation2ArtifactAssociation). This is possible 

with the Jess engine and SWRL rules (see section 5.2 for details). Rules form the 

relationships between parts and features, between parts and artifacts associations and 

between features. The class AssemblyFeatureAssociation permits the deduction of the 

property (see Table 20). 

Inferred Properties 

AFA Instances AssemblyFeatureAssociation2ArtifactAssociation 

(D:AFA R:ArtifactAssociation)

AFA_fc1 fc_1 

AFA_fc2 fc_2 

AFA_fc3 fc_3 

AFA_fc5 fc_5 

AFA_fc7 fc_7 

AFA_fc8 fc_8 

AFA_fc9 fc_9 

AFA_fc10 fc_10 

AFA_fc11 fc_11 

AFA_fc12 fc_12 
56

AFA_fc13 fc_13 

AFA_mc1 mc_1 

AFA_mc2 mc_2 

AFA_mc3 mc_3 

AFA_mc4 mc_4 

AFA_mc5 mc_5 

AFA_mc6 mc_6 

AFA_mc7 mc_7 

AFA_mc9 mc_9 

AFA_mc10 mc_10 

AFA_mc11 mc_11 

AFA_po1 po_1 

Table 20 AssemblyFeatureAssociation: inferred property 

6.2.2.8 Inferred AssemblyFeatureAssociationRepresentation Properties 

The inferred property is AFAR_2_Feature. From the asserted properties that links the 

class AssemblyFeatureAssociationRepresentation to AssemblyFeatureAssociation

and AssemblyFeatureAssociation to Feature, the reasoner is able to infer the property 

AFAR_2_Feature. The detailed inferred instances are presented in Table 21. 

 Inferred Properties Inferred Properties 

AFAR 

Instances 

AFAR_2_Feature 

(D:AFAR R:Feature)

AFAR 

Instances

AFAR_2_Feature 

(D:AFAR R:Feature) 

Groove thread_5 AFAR_fc1 

Outer_Rim thread_6 

Bearing_Seat_1 thread_7 AFAR_fc2 

Outer_Race_1 thread_8 

Bearing_Seat_2 threaded_Hole_1 AFAR_fc3 

Outer_Race_2 threaded_Hole_2 

pin_Cylinder_1 threaded_Hole_3 

pin_Hole_1 threaded_Hole_4 

pin_Cylinder_2 Thru_Hole_5 

AFAR_fc5 

pin_Hole_2 Thru_Hole_6 

pin_Cylinder_3 Thru_Hole_7 AFAR_fc7 

pin_Hole_3 

AFAR_fc13 

Thru_Hole_8 

pin_Cylinder_4 pin_Cylinder_6 AFAR_fc8 

pin_Hole_4 

AFAR_mc1 

Pin_Hole_6 

pin_Cylinder_5 pin_Cylinder_7 AFAR_fc9 

pin_Hole_5 

AFAR_mc2 

pin_Hole_7 
57

pin_Cylinder_9 pin_Cylinder_8 

pin_Cylinder_10 AFAR_mc3 pin_Hole_8 

pin_Hole_9 Bearing_Seat_3 AFAR_fc10 

pin_Hole_10 Inner_Race_1 

thread_1 

AFAR_mc4 

Inner_Race_2 

thread_2 teeth_1 

thread_3 

AFAR_mc5 

teeth_7 

thread_4 teeth_2 

threaded_Hole_1 

AFAR_mc6 

teeth_9 

threaded_Hole_2 teeth_3 

threaded_Hole_3 

AFAR_mc7 

teeth_11 

threaded_Hole_4 teeth_4 

Thru_Hole_1 

AFAR_mc9 

teeth_8 

Thru_Hole_2 teeth_5 

Thru_Hole_3 

AFAR_mc10

teeth_10 

AFAR_fc11 

Thru_Hole_4 teeth_6 

Ring_Gear_Side 

AFAR_mc11

teeth_12 AFAR_fc12 

Stepped_Side Output_Shaft_Feature 

 

AFAR_po1 Sun_Gear_Feature 

Table 21 AssemblyFeatureAssociationRepresentation: inferred properties 

6.2.3 Kinematic Information Representation 

The Planetary Gear System is used for transmitting motion and for this reason the model 

has to be able to represent the relative motion of the single parts. 

Figure 29 Kinematic Diagram of Planetary Gear System
58

Figure 29 illustrates the Kinematic Diagram of Planetary Gear System. Table 22 presents 

the kinematic pairs and the associated parts that are identified from the planetary gear 

system. For convenience, numbers are used to distinguish the three planet gears and the 

kinematic pairs of the same type. As shown in Table 22, two types of kinematic pairs 

(GearPair and RevolutePair) are used in the planetary gear system. 

Kinematic Pairs Associated Parts 

Revolute Pair 1 Unknown Support – Sungear (Input Shaft) 

Gear Pair 1 Sungear – Planet Gear 1 

Gear Pair 2 Sungear – Planet Gear 2 

Gear Pair 3 Sungear – Planet Gear 3 

Gear Pair 4 Planet Gear 1 – Ring Gear 

Gear Pair 5 Planet Gear 2 – Ring Gear 

Gear Pair 6 Planet Gear 3 – Ring Gear 

Revolute Pair 2 Planet Gear 1 – Planet Carrier 

Revolute Pair 3 Planet Gear 2 – Planet Carrier 

Revolute Pair 4 Planet Gear 3 – Planet Carrier 

Revolute Pair 5 Planet Carrier – Bearing 

Table 22 Kinematic Pairs and Associated Parts of Planet Gear System

Assigning frames to each link (part) of the gear system is essential to describe the 

movements of each part. In general, two coordinate systems or frames are needed to 

describe the kinematic behavior of any KinematicPair, each attached to a link of the 

pair. Considering that a binary link is associated with two KinematicPairs (one with the 

preceding link and the other with the following link), there are two frames associated 

with the link. The KinematicPairs (instances of classes GearPair and RevolutePair) 

contain their specific kinematic information (constraints of the pair) to describe their own 

behavior and they are connected with the class AFAR through the property 

AFAR_2_KinematicPair and with the class Feature through the property 

feature_2_KinematicPair. It is also possible to represent the path of each 

movement with specific geometric characteristics through subclasses of the classes 

KinematicPair and KinematicPath. With this representation every movement could be 

represented in the OAM-OWL and thereby possible to perform reasoning between the 

classes KinematicPair, KinematicPath, AFAR and Feature. 

6.2.4 Tolerance Representation in the Planetary Gear System 

The tolerance schema is adopted from the OAM-UML, which is based on the standard 

ASME Y14.5 M [45]. For every type of tolerance defined in the standard, a class is 

defined to represent the tolerance value and other needed information. For example, 

consider the Sungear and its tolerances as in Figure 30. 
59

Figure 30 Sungear tolerances

Consider the highlighted Sun_Gear_Feature on the top of the Sungear. Notice that there 

are two different tolerances defined: a cylindricity tolerance and dimensional tolerance. 

This means that in the class Tolerance of the model two instances have to be created and 

linked through the property OAMFeature_toleranced_by (domain: feature 

range:Tolerance) to the Sun_Gear_Feature instance. To define a cylindricity tolerance, a 

reference axis is needed and with this aim a new feature has to be added to the Sungear: 

the DatumFeature_Axis_1. This particular instance is created in the class DatumFeature

that is a subclass of OAMFeature. After setting DatumFeature_Axis_1 as reference for 

the cylindricity tolerance it is possible to define its attributes. The dimension of the 

tolerance is implemented as an instance with a numeric value of a dedicated class called 

Size. This choice is done to allow for reusing the same tolerance data when possible. For 

the dimensional tolerance the steps are the same but the creation of a datum reference is 

not needed. 

7 Results and Discussion 

Even if the interoperability between different systems is growing, the current PLM 

solutions are inefficient while screening data (usually in terabytes) clustered in 

companies. This necessitates a need for a data analysis system. This scenario is due to the 

inherent drawback with the commonly used approaches, to give any sort of meaning to 

the stored data to help systems to understand/react immediately to the kind of information 

saved in a particular cluster. This problem is present in any entity that collects great 

quantity of data (an entity could be anything from a whole organization, a single division 

or office). Generally every entity has good knowledge of the kind of data it manages 

(nevertheless may still need the assistance of a dedicated data analysis tool). However, 

this knowledge can become complex if we refer to different subjects of a supply chain or 

to a set of divisions or facilities trying to share data in a PLM context. The aim of this 
60

work, i.e., the development of an OWL version of the Open Assembly Model fits the 

above mentioned scenario. The underlying reasons for the creation of the OWL version 

of the assembly model are: 

• A standard data structure developed directly in a Web-oriented language such as 

OWL: this assures the highest level of compatibility and diffusion. 

• New reasoning capabilities offered by the ontological approach: OWL is developed 

with the intent of supporting the growth of the Semantic Web and offers the 

possibility to give to the data structure not only a format but a meaning intelligible 

by a computer. This allows the machines to reason this ontology to deduct 

knowledge and more information from the stored data. 

The proposed OAM-OWL aims to address a data representation model for 

interoperability between software platforms with a capability of sharing meaningful 

stored data. In the subsequent Section 7.1 the novelty of the OAM model will be 

discussed along with a brief analysis of its capability. Section 7.2 presents a discussion on 

certain limitations scopes for future research. 

7.1 Model Advantages 

The first advantage of an ontological approach is the possibility to use the rich 

Vocabulary defined for this language. In the OWL model, it is possible to use classes and 

properties to define any kind of relation between different elements of representation. 

The property-based nature of OWL allows us to create all operations possible using sets. 

Concepts such as intersection and union can be used to tailor modeling activities based on 

the specific needs of the developer and recur to the definition of cardinality constraints if 

needed. The conceptual difference between UML and OWL offers the advantage to 

define on the same properties different constraints for different classes. 

The structure and the semantic nature of the OWL model can be understood and reasoned 

by suitable reasoning software. In this application we deployed RACER to check the 

consistency of the developed ontology, to reclassify classes and to infer the related 

instances. 

The consistency check capability of the reasoner is helpful for testing the correctness of 

the developed model and to find class definition or restrictions that could be contrasting. 

This is much more than a simple error check. The consistency check is aimed to test if the 

semantic (meaning) included in the model makes sense and not just the syntax. 

The class reclassification is another interesting feature offered by RACER. Let’s consider 

the previous example of the two-seat and four-seat cars with an added class car. The class 

car is defined as the class that contains all the elements with four wheels and with no 

precise number of passengers. If we add the condition (to be a car it has to have four 

wheels) to the two previous classes then the reasoner will reclassify the two- and fourseats cars as subclasses of the class car. 
61

RACER has the capability to infer instances of classes as elements of a different class 

that are of immediate relevance. Following the restrictions and the cardinality constraints 

defined in the model the reasoner is able to understand (infer) the particular kind of 

instance to be analyzed. This means that after the reclassification of the classes of the car 

in the earlier example, if an instance of car is created and is defined as a car with two 

seats, the reasoner will infer that in the ontology there is a two-seat car inserted. 

The reasoning performed with RACER is useful for testing the consistency of the 

ontology and for relocating instances following the class definition. These are already 

good improvements to the previous versions of the models, but with the Jess engine it is 

possible to extract much more knowledge from the stored data. Jess is a rule engine that 

is able to process rules written with SWRL. With the combination of these two elements 

it is possible to define any rule on the representation and with the reasoning function Jess 

is able to add knowledge to the stored information. The level of complexity is higher than 

in the RACER reasoning. As with RACER, the inferred properties are directly related to 

the intrinsic structure of the ontology and hence limited to the comparison between the 

characteristics of any single instance and classes definitions. With Jess, the operation is 

performed on the ontology by the Jess engine through the SWRL rules and is more like a 

deduction then a simple comparison. Consider for example one of the reasonings 

performed in the implemented model to clarify this concept. 

In the Planetary Gear Example, to create an assembly the connection between two parts is 

needed and it is represented by a relationship between two features of those parts. Only 

by specifying the relation between the two features of the two parts, the model is able to 

infer that the two parts have to be connected. 

7.2 Limitations and future research directions 

The OWL-OAM model has some criticisms, most of them inherent to the version of the 

language OWL 1.1 used and its integration with the tool Protégé-OWL. This can be 

attributed to the fact that both of them are still new and evolving. The final specification 

of OWL (1.1) was released in 2004 and Protégé is still available only in beta version. The 

first limitation of the current version of OWL 1.1 is the impossibility to define dynamic 

ranges for properties. Considering the example in Figure 31, it is impossible to specify 

that the range of the property A2C has to be represented by the elements of C connected 

with elements of B. 

Figure 31 Dynamic Range Example 
62

This kind of structure could be useful to immediately identify (in large instantiated 

models) the instances of a class related with a particular instance. 

Another limitation is related to the Open World Assumption present in the current 

version of OWL. The Open World Assumption makes it impossible to define an element 

as “is not an...”. It is possible to define set operations for defining classes but, due to the 

Open World Assumption, it is not possible to define in a given set a subset and it’s 

complement. In Figure 32 there exists a set with two subsets defined as partitions of the 

biggest set, but there still exists another element that is not a part of the two subsets. 

Figure 32 Open World Assumption 

Considering the OAM-OWL class Artifact and its subclasses Assembly and Part, it is 

not possible to define as parts all the artifacts that are not assemblies. These instances will 

be considered as simple artifacts. 

The previous problem could not be solved even with the SWRL rules. In fact, in the 

actual version of SWRL, logic operators like OR, NOT and XOR are not present. 

Although it is possible to infer that an Artifact created by many parts is an Assembly, it is 

impossible to infer that an Artifact not composed by parts is a Part. 

Another problem is associated with the current version of Protégé-OWL. In fact it is not 

possible to accept inferred instances. Even if the tool recognizes that an Artifact created 

by many parts is an Assembly, it is not possible to specify some properties concerning 

only Assembly. This issue is expected to be solved with the next release of the tool. 

All the open issues discussed above will be solved with the new release of OWL 2.0. 

Besides the issues, we can still appreciate the potentialities of the new ontology for the 

representation of the Open Assembly Model. This work can be considered an initial step 

in the standardization process within the PLM applications. 

8 Acknowledgements 

The authors wish to acknowledge the valuable comments, suggestions and improvements 

from Dr.Steven Fenves, Dr.Eswaran Subrahmanian and from all the researchers of the 
63

Design Process Group. Their comments have substantially improved and shaped the 

report. 

9 Disclaimer 

No approval or endorsement of any commercial product by NIST is intended or implied. 

Certain commercial equipment, instruments or materials are identified in this report to 

facilitate better understanding. Such identification does not imply recommendations or 

endorsement by NIST nor does it imply the materials or equipment identified are 

necessarily the best available for the purpose. 

10References 

 1. ISO. ISO 13584-1:2001, Industrial automation systems and integration -- Parts 

library -- Part 1: Overview and fundamental principles. 2001. ISO. 

 2. ISO. IEC 62264-2:2004, Enterprise-control system integration. 2004. ISO. 

 3. ISO 10303-1:1994, Industrial automation systems and integration -- Product data 

representation and exchange -- Part 1: Overview and fundamental principles. 

 4. Porter, M. How competitive forces shape strategy. 1979. Harvard business Review, 

Harvard business Review. 

 5. Product Life Cycle Support (PLCS), Frequently Asked Questions. 

http://xml.coverpages.org/PLCSInc-FAQv2-20030804.pdf . 8-4-2003. 

 6. OMG. UML 2.0: Infrastucture. 5-7-2005. 

 7. Fenves, S. J. A Core Product Model For Representing Design Information. NISTIR 

6736. 2001. Gaithersburg, MD 20899, USA, National Institute of Standards and 

Technology. 

 8. Fenves, S, Foufou, S, Bock, C, Bouillon, N, and Sriram, R. D. CPM2: A Revised 

Core Product Model for Representing Design Information . NISTIR 7185. 2004. 

Gaithersburg, MD 20899, USA, National Institute of Standards and Technology. 

 9. Baysal, M. M, Roy, U, Sudarsan, R, Sriram, R. D, and Lyons, K. W. The Open 

Assembly Model for the Exchange of assembly and tolerance information: overview 

and example. 2004. Salt Lake City, Utah. 

 10. Web Ontology Language (OWL). http://www.w3.org/2004/OWL/ . 2005. 
64

 11. Grady Booch, Jim Rumbaugh, and Ivar Jacobson. UML User Guide. 1999. 

Addison-Wesley. 

 12. J.Rumbaugh. The UML Reference Manual. 1999. Addison-Wesley. 

 13. G Mocko. A Knowledge Repository for Behavioral Models in Engineering Design. 

2004. 24th ASME Computers and Information in Engineering. 

 14. M.Flower. UML distilled. 2004. Addison-Wesley. 

 15. Schenck D, Wilson PR. Information modeling: the EXPRESS way. New York: 

Oxford University Press, 1994. 

 16. ISO. www.step-nc.org. 

 17. STEP ISO 10303. http://www.steptools.com/library/standard/ . 2006. STEP Tools, 

Inc. 

 18. Feeney AB. The STEP Modular Architecture. Journal for Computing and 

Information Science in Engineering 2002;2:132-5. 

 19. Gruber, T. R. Towards principles for the design of ontologies used for knowledge 

sharing. 1993. Padova, Italy. International workshop on Formal Ontology. 

 20. Gruber, T. What is an Ontology? http://www-ksl.stanford.edu/kst/what-is-anontology.html . 1993. 

 21. G.Schreiber. OWL Web Ontology Language Reference. 2004. W3C. 

 22. Harmelen. Reviewing the design of DAML+ OIL: An ontology language for the 

semantic web. 2001. Proc. of the 18th Nat. Conf. on Artificial Intelligence. 

 23. Patel-Schneider. Semantic web: ontology construction. 2006. International World 

Wide Web Conference. 

 24. RDF- Resource Description Framework. www.w3.org/RDF/ . 2006. 

 25. D.Brickley, R. V. Guha. Resource Description Framework (RDF) Model and 

Syntax Specification. 1999. W3C Recommendation submitted. 

 26. K Falkovych, M Sabou H Stuckenschmidt. UML for the Semantic Web: 

Transformation-Based Approaches. 2003. 

 27. T.Bittner, M. Donnelly B. Smith. Individuals, Unicersals, Collections: On the 

Foundational Relations of Ontology. 2005. Saarland University, Germany; 

University of Buffalo, NY. 

 28. E.Rosch. Principles of Categoization. 1978. Hillsdale. 
65

 29. F.Giunchiglia, M. Marchese I. Zaihrayeu. Encoding Classifications into 

Lightweight Ontologies. 2005. Italy, Department of Information and 

Communication Technology, University of Trento. 

 30. Ontology Definition Metamodel Specification. Object Management Group. 

 31. D.Berardi, D.Calvanese G.De Giacomo. Reasoning on UML class diagrams.

 32. J.Parsons, Yari Wand. Choosing Classes in Conceptual Modeling. Commuication 

of ACM 40(No. 6). 1997. 

 33. Evan Wallace and Natasha Noy. Simple part-whole relations in OWL Ontologies. 

2005. W3C. 

 34. protégé Official Web Page. protege.stanford.edu . 2006. 

 35. H Knublauch, RW Fergerson NF Noy MA Musen. The Protégé OWL Plugin: An 

Open Development Environment for Semantic Web Applications. 2004. Third 

International Semantic Web Conference (ISWC 2004), 2004. 

 36. D.L.McGuinnes, J. Wright. Conceptual modelling for configuration: A description 

logic-based approach. Cambridge Journals . 1998. 

 37. D.L.McGuinnes. Description Logics Emerge from Ivory Towers. 2000. Stanford 

University. 

 38. RACER Reasoner. www.sts.tu-harburg.de/-r.f.moeller/racer . 2006. 

 39. SWRL plug-in for Protégé-OWL. protege.stanford.edu/plugins/owl/swrl . 2006. 

 40. SWRL: A Semantic Web Rule Language. www.w3.org/Submission/SWRL . 2006. 

 41. Jess Rule Engine. herzberg.ca.sandia.gov/jess . 2006. 

 42. P.Onions, G. Orange. A Model for Knowledge that supports Ontology and 

Epistemology. 2002. Leeds Metropolitan University, School of Information 

Management. 

 43. B.Smith. The Basic Tools of Formal Ontology. In: IOS Press. Formal Onthology in 

Information Systems. 1998:19-28. 

 44. B.Smith. Blackwell Guide to the Philosophy of Computing and Information: 

Chapter Ontology. 155-166. 2003. Oxford, Blackwell. 

 45. ASME. Dimensioning and Tolerancing Y14.5M. ASME, 1994. 

 
66

11Appendix 

A few snapshots of the Model in Protégé OWL: 

Snapshot A1 Subclass Explorer 
67

Snapshot A2 Property Browser 
68

Snapshot A3 Class Browser