Technical ReportPDF Available

OntoSTEP: OWL-DL ontology for STEP

  • Engisis LLC
  • Engisis LLC

Abstract and Figures

The Standard for the Exchange of Product model data (STEP) (1) contains product information mainly related to geometry. The modeling language used to develop this standard, EXPRESS, does not have logical formalism that will enable rigorous semantics. In this paper we present an OWL-DL (Web Ontology Language - Description Logic) (2) version of STEP (OntoSTEP) that will allow logic reasoning and inference mechanisms and thus enhancing semantic interoperability. The development of OntoSTEP requires the conversion of EXPRESS schema to OWL-DL, and the classification of EXPRESS instances to OWL individuals. Currently we have considered AP203 (3) - the most widely used Application Protocol (AP) for the exchange of Computer-Aided Design (CAD) files - and STEP Part 21 (4) CAD files - CAD files conformant to the data exchange format defined in Part 21 - for schema level conversion and instance level classification respectively. We have implemented a web application to demonstrate OntoSTEP. We are currently extending OntoSTEP to include information such as function, behavior, and assembly requirements.
Content may be subject to copyright.
Computer-Aided Design 44 (2012) 575–590
Contents lists available at SciVerse ScienceDirect
Computer-Aided Design
journal homepage:
OntoSTEP: Enriching product model data using ontologies
Raphael Barbau
, Sylvere Krima
, Sudarsan Rachuri
, Anantha Narayanan
, Xenia Fiorentini
Sebti Foufou
, Ram D. Sriram
Le2i, Université de Bourgogne, BP 47870, 21078 Dijon, France
System Integration Division, Engineering Laboratory, National Institute of Standards and Technology, Gaithersburg, MD 20899, USA
Engisis s.r.l., Rome, Italy
Software and Systems Division, Information Technology Laboratory, National Institute of Standards and Technology, Gaithersburg, MD 20899, USA
CSE Department, CENG, Qatar University, Doha, Qatar
a r t i c l e i n f o
Article history:
Received 3 December 2010
Accepted 26 January 2012
Product modeling
Automated model transcription
Product lifecycle information
a b s t r a c t
The representation and management of product lifecycle information is critical to any manufacturing
organization. Different modeling languages are used at different lifecycle stages, for example STEP’s
EXPRESS may be used at a detailed design stage, while UML may be used for initial design stages. It is
necessary to consolidate product information created using these different languages to build a coherent
knowledge base. In this paper, we present an approach to enable the translation of STEP schema and its
instances to Ontology Web Language (OWL). This gives a model which we call OntoSTEP that can
easily be integrated with any OWL ontologies to create a semantically rich model. As an example, we
combine geometry information represented in STEP with non-geometry information, such as function
and behavior, represented using the NIST’s Core Product Model (CPM). A plug-in for Protégé is developed
to automate the different steps of the translation. As additional benefits, reasoning, inference procedures,
and queries can be performed on enriched legacy CAD models. We describe the rules for the translation
from EXPRESS to OWL, and illustrate the benefits of OWL translation with an example. We will also
describe how these mapping rules can be implemented through meta-model based transformations,
which can be used to map other languages to OWL.
Published by Elsevier Ltd
1. Introduction
The Product Lifecycle Management (PLM) approach enables or-
ganizations to manage their product portfolio from conception to
disposal, in an integrated fashion [1]. Manufacturing organizations
spend a considerable amount of resources to understand and ap-
ply the PLM approach. PLM is gaining acceptance primarily because
of the emergence of the networked firm and the networked econ-
omy, in contrast to the market- or hierarchy-based organizations
that typically use a transactions cost model as the cornerstone for
the choice of organizational structure [2]. PLM support entails the
modeling, capturing, manipulating, exchanging, and using of infor-
mation in all product lifecycle decision-making processes, across
Corresponding author at: System Integration Division, Engineering Laboratory,
National Institute of Standards and Technology, Gaithersburg, MD 20899, USA. Tel.:
+1 301 975 3508.
E-mail addresses:,, (R. Barbau), (S. Krima), (S. Rachuri),
(A. Narayanan), (X. Fiorentini),, (S. Foufou),
(R.D. Sriram).
all application domains. Proper representation and management
of product information is the key for a successful implementation
of PLM.
To enable the exchange of product data throughout a product’s
lifecycle, the International Organization for Standardization (ISO)
has developed the STandard for Exchange of Product model data
(STEP), referenced as ISO 10303 [3], which is still evolving to meet
the needs of modern Computer-Aided Design (CAD), Computer-
Aided Engineering (CAE), and Product Data Management (PDM)
systems. Application Protocols (APs) represent the implementable
data specification of STEP. Examples of the most widely used
APs are AP203 (Configuration controlled 3D design of mechanical
parts and assemblies) [4], AP214 (Core data for automotive
mechanical design processes) [5] and AP239 (Product lifecycle
support) [6]. These APs mainly focus on product data management
and geometry information. Unfortunately, the representation of
non-geometry information such as the function and behavior of the
product is usually not contained in these APs.
The STEP APs are modeled using the EXPRESS (ISO 10303-11)
language [7]. EXPRESS was developed for representing product
models and providing support to describe the information required
for designing, building, and maintaining products [8]. Data models
(or schemas) are represented in EXPRESS as a network of concepts
0010-4485/$ see front matter. Published by Elsevier Ltd
576 R. Barbau et al. / Computer-Aided Design 44 (2012) 575–590
Fig. 1. Building semantic product model.
(entities), and concepts can have properties (attributes). Entities
and attributes are therefore the basic constructs of EXPRESS. STEP
Part 21 defines the syntax for representing instance data according
to a specific EXPRESS schema [9]. The use of EXPRESS and Part 21 is
not particularly suited for the integration of STEP data with other
STEP or non-STEP product data.
Many tools have been developed to check the syntax of
EXPRESS information models and the validity of the instances
against the information models. Unfortunately, these tools are
specifically developed for implementers and consumers of STEP,
so their usage is restricted to the field of product modeling in
EXPRESS. Semantics aims at providing a common meaning to
the terms in a particular domain. Lack of explicit semantics and
contexts in the content to be shared across PLM applications is
a major problem. Making data semantics explicit and context
aware and sharable among product lifecycle applications is a major
challenge. For an evolving organization to function, an information
infrastructure that supports well-defined information exchange
among the participants is critical. One language that provides
such capabilities is OWL (Ontology Web Language) [10]. The OWL
representations are generic and OWL is evolving to become the
language of the Semantic Web.
The development of a high-level interoperable model poses
many challenges, such as (i) the complex nature of interactions in
product modeling and (ii) representation of the information con-
tent and abstraction principles used. The model for representing
mechanical assemblies (products) is inherently complex due to:
the variety of information elements to be represented: function,
behavior, structure, geometry and material, assembly features,
tolerances, and various levels of interaction between these
the abstraction principles needed to represent the informa-
tion model: generalization, grouping, classification, and aggre-
One of our earlier papers [11] outlines a method for evaluating
the appropriate level of expressiveness to capture both the
information content and the abstraction principles, discussed with
the aim of developing a consistent formal model for product
assemblies. The paper [11] also evaluates the application of OWL
for the development of ontologies for manufactured products, in
terms of expressivity and the use of SWRL (Semantic Web Rule
Language) [12] for representing domain-specific rules.
Semantically enriched product models allow us to use special-
ized concepts defined in shared ontologies. These models help to
capture knowledge in a better way. Product data integration is an-
other benefit that is made possible by the use of semantically en-
riched product models. In Ref. [11], we provided a rationale for
OWL-DL as a good choice for representing the semantics of prod-
uct information. This paper describes how to represent STEP prod-
uct models in OWL 2, which is an extension of OWL-DL, by the
automatic translation of EXPRESS schemas and instances, and how
these product models can be semantically enriched. This trans-
lation allows the application of logic mechanisms to check the
validity of the models and data, to check the consistency of the
instances, and to infer new knowledge. These logic mechanisms
are performed by software tools called reasoners [11]. We refer to
the translated STEP as OntoSTEP in the rest of the paper. Thus, On-
toSTEP [13] can be used to express and semantically enrich product
information available in STEP files.
OntoSTEP is a step toward developing semantically enriched
product models. Semantic models support both the representation
of product geometry concepts and non-geometry concepts, such
as function, behavior, design rationale, etc. Fig. 1 shows the
R. Barbau et al. / Computer-Aided Design 44 (2012) 575–590 577
different steps involved in building a semantic product model. We
outline three important steps: (1) a STEP AP written in EXPRESS
is translated into an OWL schema (TBox—terminological box),
(2) data instances are extracted from a Part 21 file and translated
into OWL individuals (ABox—assertional box), (3) this ontology is
then combined with another product model to incorporate non-
geometry information, resulting in a new semantically enriched
product model. These steps are demonstrated in a use case,
which consists of: (1) translating the AP203 (data model for
geometry) into OWL, (2) translating a Part 21 generated by a
CAD system into OWL, (3) combining the resulting ontology with
CPM product model (outlined in Section 5.1) that contains non-
geometry information. The semantic product model also allows
us to perform reasoning, inferences, and queries, as shown in the
figure (this will be described in Section 2.3).
In our earlier work [14], we created a semantic model for
including non-geometry concepts (such as function, behavior,
requirements and sustainability factors) from the NIST Core
Product Model (CPM) [15] and the NIST Open Assembly Model
(OAM) [16] developed at NIST (National Institute of Standards and
Technology). This model was implemented in OWL-DL 1.0 [10] and
used SWRL rules [12]. A third party reasoner allowed reclassifying
the input instances, and the SWRL rules allowed refinement and
improvement of the model.
In this paper, we combine OntoSTEP with the semantic models
of CPM and OAM. We developed a plug-in for Protégé [17] that
enables STEP product models to be imported and translated into
OWL Non-geometry information of the designed product can then
be integrated. The traditional geometry information and non-
geometry information would then be represented in a unified,
consistent OWL model.
The paper is organized as follows. We introduce the OntoSTEP
concepts and benefits in Section 2. We review related literature
in Section 3. We present the details of our implementation (plug-
in for Protégé) and the tools used to realize it in Section 4. In
Section 5, we present two examples of product model enrichment:
the integration of non-geometry information with geometry
information defined in STEP, and the reference to concepts
defined in external ontologies. In Section 5.26 we introduce a
high-level model transformation specification for the OntoSTEP
translation using a meta-modeling approach. Finally, we present
our conclusions and future work in Section 7.
2. OntoSTEP: translating STEP data model into OWL
This section describes how a STEP data model (schema) is
translated into OWL. The term STEP data refers to the models
written in EXPRESS and instances of these models. For example, the
data model would be an AP203 schema, while an instance would
be a Part 21 CAD file containing the 3D representation of a product.
We use Courier New font to denote EXPRESS code and we use
to denote OWL code.
2.1. Mapping EXPRESS schemas (TBox)
We illustrate our translation of the main concepts in EXPRESS
through the following example from AP203.
ENTITY product_category;
name : label;
description : OPTIONAL text;
END_ENTITY; -- product_category
ENTITY product_related_product_category
SUBTYPE OF (product_category);
products : SET [1:?] OF product;
END_ENTITY; -- product_related_product_category
ENTITY product;
id : identifier;
name : label;
description : text;
END_ENTITY; -- product.
In this example three entities are described: product, product
_category, and product_related_product_category. A
product has an identifier, a name and a description. A
product_category contains a name and may have a description.
A product_related_product_category is a product_category
that identifies the products that satisfy the type identified by the
category. In order to simplify this example, some parts of the actual
AP203 entity definitions have been removed.
The concept of entity in EXPRESS is similar to the concept
of a class in object-oriented modeling: entities can be seen as
abstractions of real-world objects (instances) and can be organized
in hierarchies. These hierarchies conform to the following
inheritance principle: sub-entities (product_related_product_
category in our example) inherit the attributes of their super-
entities (product_category in our example) and the instances
of the former are also instances of the latter. Attributes specify
relationships between entities or between entities and data
types. An attribute consists of a name and a type: in our
example, the first attribute of the entity product is called id,
and its type is identifier. An attribute may be optional, as
in the case of description in product_category, and its type
can be a collection of data, as in the case of products in
In our translation, EXPRESS entities and instances map respec-
tively to OWL classes and individuals. Attributes correspond to
OWL properties—ObjectProperties link classes together, while Dat-
aProperties link classes to data types. The domain of a property
defines which classes can have this property. Without restric-
tions, properties in OWL are aggregations, so an individual can
be linked to several individuals by using the same property. To
define the usage of a property, it is possible to restrict its cardi-
nality through the ‘‘ObjectExactCardinality’’ construct and its val-
ues through the ‘‘ObjectAllValuesFrom’’ construct. In the case of
an optional attribute, the ‘‘ObjectAllValuesFrom’’ construct is used
to link the entity to the union of the attribute type and the class
owl:Nothing. This solution is adopted to explicitly express the se-
mantics of the OPTIONAL keyword: a value is not required for this
An ontology may contain statements related to both classes
(TBox—terminological box) and individuals (ABox—assertional
box). In our approach, an EXPRESS schema is translated into an on-
tology that contains mainly classes and property definitions [11].
Table 1 summarizes the proposed OWL mapping of the basic con-
cepts of EXPRESS.
We also need to redefine the naming conventions for the
properties. Consider, as an example, the entities product and
product_category, both having the name attribute. In EXPRESS
attributes are defined to be within the scope of the entity. In OWL
properties have a global scope, so the property name would be
the same for the product and the product_category. We choose
to prefix the attribute names with the entity names in order
to differentiate attributes. As a result, the entities product and
product_category will contain, respectively, the attributes prod-
uct_has_name and product_category_has_name. The following
OWL statements, expressed in functional syntax, are the transla-
tion of the previous entity definitions:
578 R. Barbau et al. / Computer-Aided Design 44 (2012) 575–590
Table 1
Mapping of the basic concepts from EXPRESS to OWL.
Schema Ontology
Entity Class
Subtype of Subclass of
Attribute with an entity
ObjectProperty. The domain of the property is the class that corresponds to the entity that contains the attribute.
This class is restricted to have ObjectExactCardinality equal to 1 and ObjectAllValuesFrom equal to the entity type for that property.
Attribute with a simple
data type
DataProperty. The domain of the property is the class that corresponds to the entity that contains the attribute.
This class is restricted to have ObjectExactCardinality equal to 1 and ObjectAllValuesFrom equal to the data type for that property.
Optional attribute The range of the property is restricted to have ObjectAllValuesFrom equal to the union of the attribute type and the class .
Some EXPRESS constructs, such as functions, cannot be
translated without some additional efforts: these constructs
usually define entity constraints and attributes computation,
and may rely on complex algorithms. OWL, as it is based
on Description Logic, does not contain any procedural aspects.
The next paragraphs focus on the EXPRESS language constructs
(e.g. data types, bags, select, enumerations, abstract entities and
inheritance) that can be automatically translated into OWL. This
section focuses on the EXPRESS language aspects that can be
automatically translated to OWL concepts. We will now explain
how the EXPRESS concepts such as data types, bags, select,
enumerations, abstract entities and inheritance are represented in
Data types
EXPRESS includes all the data types (such as integer, boolean,
string) required to capture product information. OWL inherits the
data types defined in the XML Schema Definition (XSD) language.
Some EXPRESS types, e.g., Boolean and String, have an exact
equivalent in OWL, while other types, e.g., Number and Real, are
represented in a slightly different way in OWL. For example, we
translated the EXPRESS Real type as double in OWL, even though
the precision of those two data types is different.
EXPRESS allows the derivation of data types from simple types.
In order to deal with these derived types in OWL, we build a type
hierarchy and apply the concept of data wrapping.
In the example in Fig. 2, we define a class String that has a
DataProperty relation to the string data type. It is then sufficient to
subclass the class String to translate all the user-defined data types
(Label in this case) derived from string. Because of the possible use
of functions, we cannot guarantee an automatic translation of data
type restrictions. Using a manual case-by-case translation, most of
the types defined in AP203 can be translated.
Fig. 2. Representation of EXPRESS attributes in OWL.
EXPRESS provides four different kinds of aggregations: set,
bag, list, and array. Each of these aggregations has order and
duplication policies. When an actual aggregation is used in a
schema, the type of its content and the number of elements it
shall have are defined. The detailed mapping of aggregations is
explained in [13]. Here, as an example, we provide the detailed
mapping of bag.
Bags are unsorted collections of elements. The only difference
between sets and bags is the duplication policy: the same element
can be repeated several times in a bag. As object properties in
OWL do not allow duplications, we create the structure shown in
Fig. 3 to correctly map EXPRESS bags to OWL. Consider a bag called
Container, which contain items of type Content. To correctly map
this bag to OWL, we create two classes, (Container and Bag), and
two properties (hasBag and hasContent).
The class Bag is used to represent an occurrence of Content
using the property hasContent. The property hasContent is
declared as Functional, which means that there can be only one
instance of Content linked to an instance of Bag by the property
hasContent. Fig. 4 represents the instantiation of the schema
presented in Fig. 3, illustrating how an EXPRESS bag containing a
duplicated element is converted to OWL. An instance of Container
(cont) is linked to two different instances of the Bag class (b1 and
b2). Each of these two instances is then linked to the same instance
of the Content class (elem1). Since b1 and b2 are different, the
ontology contains the fact that the elem1 element is present twice
in the aggregation.
SELECT is a keyword used in EXPRESS to choose from a set of
different types. A new OWL class is created to represent the SELECT
construct. This class is asserted as the equivalent of the union of all
the types included in the SELECT. As a result, no other classes can
be added to this type in the future.
Enumerations are defined in EXPRESS as a finite set of values. In
OWL, a new class representing the enumeration is created, and the
values are represented by individuals. The OWL OneOf construct is
used to give the individuals of the enumeration.
R. Barbau et al. / Computer-Aided Design 44 (2012) 575–590 579
Fig. 3. Representation of a Bag in OWL (TBox).
Fig. 4. Representation of a Bag in OWL (ABox).
Abstract Entity and Class
An entity in EXPRESS may be declared as abstract. The meaning
is the same as in object-oriented programming: an abstract entity
cannot be directly instantiated, but it may be subclassed. Consider,
as an example, the following two entities extracted from AP203:
ENTITY document_reference
assigned_document : document;
source : label;
END_ENTITY; -- document_reference
ENTITY cc_design_specification_reference
SUBTYPE OF (document_reference);
items : SET [1:?] OF specified_item;
END_ENTITY; -- cc_design_specification_reference
The entity document_reference is defined as abstract, and
the entity cc_design_specification_reference is defined as
its subtype. This means that the entity document_reference
cannot be directly instantiated, but cc_design_specification
_reference can be instantiated.
OWL does not provide any feature to translate the ABSTRACT
keyword, i.e. an OWL class cannot be declared as abstract. Using
an OWL class to represent an abstract entity causes a problem:
because of the Open World Assumption, we cannot assume that
the OWL class will never be instantiated. To overcome this
problem, we can declare the subtype classes as partitions of the
supertype. A partition forces the instances of the supertype to
belong to at least one subtype. This is achieved by declaring
that the set of instances of the supertype is equivalent to the
set of instances of all its subtypes. In that case, if an individual
is declared as an instance of document_reference and not an
instance of cc_design_specification_reference, the reasoner
would detect an inconsistency. However, this solution works only
when the supertype and all the subtypes are declared within the
same schema. Because of these reasons, we choose to ignore the
ABSTRACT keyword. Consequently instantiating an entity defined
as abstract in the EXPRESS schema will not raise an error.
In order to specify the allowed combination of subtypes for an
entity, EXPRESS provides three keywords: ONEOF, ANDOR, and AND.
Along with the ABSTRACT keyword, they restrict the usage of the
instantiation mechanism.
ONEOF: The ONEOF keyword takes a list of entities as its
parameter, and it specifies that only one of these entities can
be instantiated. An equivalent behavior in OWL is obtained by
defining the subclasses as disjoint: an inconsistency is detected
when an individual is an instance of two of these subclasses.
We mark the set of classes contained in a ONEOF list as disjoint.
Another solution could be to use the logical definition of XOR.
We could also use the OWL intersection, union and complement
operations, to translate AND, OR, and NOT. However, this increases
the complexity of the ontology, as the length of the formula
increases dramatically with the number of elements involved. For
this reason, we choose the first solution.
ANDOR: When no specific constraints are defined, the default
keyword for the instantiation is ANDOR. This means that the
instance can belong to more than one subclass. A set of entities
joined by an ANDOR is translated to the union of the corresponding
classes in OWL. We first represent the union of the subclasses by
using the ObjectUnionOf construct and then declare this union to
be equivalent to the parent class.
AND: The AND operator imposes that the object is an instance of
all the subclasses. In order to represent this constraint in OWL, we
use the ObjectIntersectionOf construct to link the subclasses.
More details regarding the translation of other EXPRESS
concepts, such as UNIQUE, LIST, ARRAY, and SET can be found
in our earlier report [13].
2.2. Mapping instances (ABox)
An EXPRESS schema is instantiated by creating a file as defined
in ‘‘Clear Text Encoding of the Exchange Structure—10303-21’’, or
Part 21. CAD packages can export data in STEP format that complies
with the AP203 schema and the constraints of STEP Part 21. In this
paper, we refer to these files as ‘‘Part 21 files’’.
The translation to OWL is performed by performing a syntactic
analysis (a process called parsing) in order to recognize all the
instances declared within the Part 21 file, and then creating
individuals and property assertions. In STEP, the schema and the
instances are declared in different files: the related schema is
specified in the Part 21 file in the FILE_SCHEMA section. In a
similar fashion, we generate two different ontologies during the
translation: a schema ontology for the EXPRESS schema and an
instance ontology for the Part 21 file. OWL provides a mechanism
to import statements declared in an external OWL ontology. We
use this feature in the instance ontology to import the schema
ontology, so that we keep the schema ontology separated from the
instance ontology while accessing both simultaneously. By having
the final ontology containing both the TBox and the ABox, we are
able to check the consistency of the instances against the schema.
All the EXPRESS instances contained in a Part 21 file are distinct,
which means that any two EXPRESS instances represent two
different real world objects. Conversely, OWL individuals are not
inherently distinct. Unless explicitly declared as distinct, two OWL
individuals may represent the same real world object. To translate
the EXPRESS instances correctly, it is then necessary to declare
explicitly all the OWL individuals contained in the same file to be
distinct using the DifferentIndividuals OWL construct.
The processing of an unknown fact is another major difference
between EXPRESS and OWL. In EXPRESS, any unknown fact is
580 R. Barbau et al. / Computer-Aided Design 44 (2012) 575–590
supposed to be false. For example, let us consider two EXPRESS
entities called product and product_category. If an instance of
product is not declared as an instance of product_category, then
the system assumes it is not. This behavior is called the Closed
World Assumption (CWA), because it supposes that the world is
limited to what is stated. OWL uses the Open World Assumption
(OWA): unless a reasoner proves a fact is false, that fact is
unknown. Hence, the translation sometimes requires additional
information to capture the semantics of EXPRESS in OWL. The
difference between CWA and OWA causes a translation problem
when an instance is constrained to have one attribute. The attribute
id of the entity product is not declared as optional, so it must be
instantiated for all the instances of product. In EXPRESS, the lack of
data will raise an error. In OWL, even if the id is not specified for an
instance of product, the reasoner will not detect an inconsistency:
the instance is still considered to have an unknown id. To allow
the reasoner to detect an inconsistency in case of a missing id,
it would be required to declare explicitly that that instance of
product has no id. However, research is being conducted to work
with CWA in OWL [18]. In the context of optional attributes, the
use of CWA in OWL would allow correct representations of the
constraints defined in the EXPRESS schema. An error would occur
if a mandatory attribute was missing.
The translation of some additional concepts, such as derived
data types, is also required before completing the translations of
2.3. Benefits of OWL ontology for STEP
OWL [19] is based on Description Logics (DL), a family of
knowledge representation languages. These languages can be
used to define domain concepts according to a predefined and
well-understood formalism. Concepts are used to represent the
domain’s objects, while roles are used to represent relationships
between these concepts. The OWL representation provides ben-
efits subject to the level of OWL expressivity. The expressivity of
OWL is denoted using different characters, such as ( ). The explana-
tion of this expressivity is given in [20]. In [11] the authors provide
examples of DL semantic axioms in product modeling and high-
light that DL semantics can be implemented in a reasoner engine
Check the consistency of the ontology.
Perform inference on the class hierarchy.
Perform inference on the membership of the individuals to the
Query and search the model.
The performance of the reasoner engine depends on the
expressivity of the ontological representation. In the following
subsections, we explain the tradeoffs between performance and
expressivity for ontology reasoning. Then, we introduce three
benefits given by the reasoning: consistency checking, inference
procedures, and queries. Lastly, we discuss the scalability of the
STEP data translation and the ontology reasoning.
2.3.1. Performance of the reasoning and expressivity of ontological
The choice of OWL may lead to performance issues when
dealing with large ontologies. Because the use of certain OWL
constructs have severe repercussions on the computational time
and memory space, it is possible to improve the performance by
altering parts of the mapping. The second version of OWL (OWL
2) defines sublanguages that trade some expressive power for the
efficiency of reasoning. An option for improving the performance
is to use only the constructs defined in the sublanguage called OWL
2 RL (Rule Language). The use of OWL 2 RL guarantees in the worst
case a polynomial complexity instead of an exponential complexity
for OWL 2. Some restrictions defined in the EXPRESS schemas will
not be correctly expressed into OWL RL, but the performance will
be drastically better. The consequence of limiting the expressivity
to OWL RL is that the following restrictions defined in EXPRESS
schemas will not be expressed: the minimum cardinalities on
aggregations do not appear and the ENUMERATION type and SELECT
type are considered extensible. The benefit of this approach is that
the reasoning time is improved, especially for large ontologies.
Section 2.3.5 contains a performance comparison between using
OWL 2 and using OWL 2 RL. It is important to note that the choice
of using OWL 2 RL to represent the ontology does not affect the
translation of the data. Only some restrictions declared in the
schema are not translated, which means only the validation of the
data is affected.
2.3.2. Consistency checking of the ontology
The consistency checking procedure can be applied at the
schema level and the instance level. At the schema level, it
determines whether an instantiation of a concept would create an
inconsistency in the model. At the instance level, it checks whether
an instance of a class satisfies the definition of this class.
Currently, software libraries are available to check the consis-
tency of EXPRESS schemas and Part 21 files. With OntoSTEP, a DL
reasoner performs consistency checking at the schema as well as
at the instance levels. Checking the logical consistency of the OWL
classes and individuals resulting from a translation is a necessary
condition to use an inference procedure. As we will see later in
Section 5, the integration of non-geometry information allows us
to perform advanced consistency checking that is not available in
2.3.3. Knowledge inference from the ontology
An inference procedure uses the data evidences in a context and
draws conclusions using certain problem solving strategies [21]. To
perform inference procedures, reasoners use a knowledge base as
a source of data, such as concepts, roles, and axioms, to reach a
conclusion. The expressivity of the axioms and concept definitions
is dependent on the used logical language.
Once the reasoner has applied all the inference procedures on
our ontology, new knowledge and data can be made available
both at the schema and at the instance level. These dynamic
modifications cannot be done in EXPRESS. One can then use a
querying mechanism to query the new data, which represents an
enriched version of the original ontology.
2.3.4. Querying the ontology
Queries are performed to retrieve specific data from a large
amount of information. This mechanism does not readily exist
as part of STEP, although some mechanisms have been devel-
oped [22]. In our case, we perform queries to retrieve some spe-
cific product information from an OntoSTEP file. The information
contained in a CAD file is first translated into OWL representation,
then checked for consistency, inferred upon, and finally queried.
There are two approaches in practice today to perform queries
on OWL ontologies. The first approach uses a language called
SPARQL Query Language (recursive acronym that stands for
SPARQL Protocol and RDF Query Language) [23], and the second
approach uses the Semantic Query-Enhanced Web Rule Language
(SQWRL) [24]. OntoSTEP gives users the freedom to choose any
query language.
SPARQL was specifically developed for Resource Description
Framework (RDF) models, so we would need to translate our OWL
ontology to RDF before performing SPARQL queries. SPARQL has
two major drawbacks. First, the translation from OWL to RDF
increases the computational time. Second, the OWL 2 reasoner
R. Barbau et al. / Computer-Aided Design 44 (2012) 575–590 581
Table 2
Characteristics of the STEP files.
File # File name File size (bytes) No. instances No. parts
1 gbsa-100a_any_asm.stp 97,064 2,259 4
2 gta02-mpb02_asm.stp 678,505 15,650 5
3 clock_assembly_asm.stp 6,183,396 114,861 27
4 sim-microsd-acon_asm.stp 6,093,409 120,927 2
5 gta02-mme01_asm.stp 43,064,477 708,016 105
Table 3
Translation and reasoning on the entire product models.
File number Translation using OWL 2 (s) Reasoning using OWL 2 (s) Translation using OWL 2 RL (s) Reasoning using OWL 2 RL (s)
1 2 91 1 1
2 8 4915 6 9
3 62 51 223
4 60 55 195
5 ∗∗ ∗∗ ∗∗ ∗∗
* The reasoning did not terminate in a reasonable time.
** There was not enough computer memory to complete the translation.
Table 4
Translation and reasoning on a subset of the product models.
File number Translation using OWL 2 (s) Reasoning using OWL 2 (s) Translation using OWL 2 RL (s) Reasoning using OWL 2 RL (s)
1 1 1 1 1
2 1 1 2 1
3 2 3 6 2
4 3 3 3 2
5 24 12 50 13
we used, Pellet [25], does not support several SPARQL built-in
functions, such as DESCRIBE, OPTIONAL, or FILTER. While SPARQL
was developed for RDF, SQWRL was specifically developed for
OWL. It is based on SWRL [12] and does not need any RDF bridge.
In addition to the large number of its built-in functions, SQWRL
also provides some classical aggregation functions like maximum,
minimum, sum, or average [26], which are missing in SPARQL.
While being more appropriate to OWL, we found two issues with
SQWRL. First, it is based on the proprietary engine Jess (a rule
engine and scripting environment) [27], which is the only option
currently available to process SQWRL queries. Second, because it
is based on SWRL, SQWRL does not allow combining functions
together, e.g., it is not possible to query the maximum of averages.
2.3.5. Scalability of the translation and reasoning
The use of OWL for representing product models may pose scal-
ability issues. Three factors can influence the time taken for trans-
lating the ontology, checking the consistency, and inferencing:
the size of the ABox, which depends on the size of the Part 21
the size of the TBox, which depends on the EXPRESS schema
the complexity of the ontology, which, in this case, depends on
the axioms chosen to represent the EXPRESS schema.
Decisions regarding what knowledge to represent may impact
the performance of the translation and reasoning. For example, it
might be decided to:
not translate the entire Part 21 file, but only a subset. Someone
might not be interested in the geometric representation of the
product, but more in the bill of material. They might translate
only specific instances that will be connected to external
knowledge (shared ontologies or other product models).
not translate the entire EXPRESS schema, but only a subset.
not translate the constructs of the EXPRESS schema that would
lead to dramatically increased computational time. As noted
previously, not translating some EXPRESS constructs results
in having a polynomial complexity instead of an exponential
Table 2 shows the characteristics of 5 different AP203 files
(example parts), used for a performance tests. 4 files are taken from
the OpenMoko project [28] and represent four phone components
of different size (files #1, #2, #4 and #5). The file #3 is the CAD
file representing the clock showcased in Section 5. The size range
of these files (from 97 KB to 43 MB) shows how the different
operations are affected by more or less detailed and complex
product models.
The tests were realized on an Intel Xeon X5365 3 GHz, 10 GB of
Table 3 sums up the translation time and reasoning time for
each file. All of the instances of the Part 21 were translated. The
first two columns correspond to a translation using all the available
constructs of OWL 2, as defined in [13] (exponential time). The
last two columns correspond to a translation limited to the OWL
2 RL constructs (polynomial time). In the latter translation, the
minimum cardinalities on aggregations do not appear and the
ENUMERATION type and SELECT type are considered extensible.
This loss of expressivity means that, for example, no error will be
detected when an instance of an entity that is not part of a SELECT
is used as a member of this SELECT.
Even though the limitation of the expressivity provides a less
strict validation, the gain in performance allows files #3 and #4
to be translated, whereas it was not possible with the OWL 2
construct. Therefore inferences and queries can be used on these
product models. Note that the file #5 could not be translated
because of computer memory issues. Reducing the expressivity of
the ontology allows dealing with larger ontologies.
Table 4 shows the translation time and reasoning time,
but in this case, only specific portions of the Part 21
were translated: instances of product, product_definition,
product_definition_formation and product_definition_
relationship. These entities are used to represent the product
structure. The first two columns correspond to translation with
maximum expressivity (OWL 2), and the two last columns corre-
spond to translation with limited expressivity (OWL 2 RL).
By limiting the types of instances that are translated, the
translation and reasoning over the product model become possible
582 R. Barbau et al. / Computer-Aided Design 44 (2012) 575–590
even for large product models. The file #5 could be translated and
the reasoning could occur in a reasonable time. When considering
the entire Part 21 file, file #5 could not be translated. As a result,
consistency checking and inference cannot be performed on the
entire product model, but only on the subset that was translated.
However it allows us to integrate and perform queries using this
These results show that the reasoning time varies considerably
depending on the schema complexity and the amount of data
that is translated. When using OntoSTEP with large ontologies, the
product modeler can decide to reduce the expressivity to allow
better performance or also to restrict the translation to a subset
of the product model (product structure in this case).
3. Related work
This section discusses two related efforts that aim to develop a
translation from EXPRESS to OWL. We provide a brief presentation
of these approaches and their main contributions. Intelligent Self-
describing Technical and Environmental Networks (S-TEN) [29] is
a project funded by the European Community. One of its objectives
is to ‘‘exploit the Semantic Web for scientific and engineering
applications’’. This project describes a bi-directional translation
between EXPRESS and OWL.
To understand the approach adopted in the S-TEN project,
we briefly trace the development of STEP Application Protocols
(APs). APs are data models adopted to support data exchange
in a particular business application. Different APs may require
common parts. When the first APs were created, these parts were
copied and adapted according to the goal of the AP. Currently
APs are being migrated from their old versions to modular ones.
The modularity ensures that the information available from an AP
can be shared among the other APs. S-TEN focuses on translating
modules, so the translated parts are used within several APs.
Hence in the S-TEN project no AP is covered in full. The STEP
modules are also modified, either to take advantage of the use
of OWL, or as an improvement. For instance, some entities used
to express relationships are directly translated to relationships.
Moreover new capabilities are added, such as a better management
of the product identifiers. A manual check is performed after the
translation of the EXPRESS schemas to ensure that the meaning
of the data models is the same in EXPRESS and in OWL. The final
ontology is stored in a database.
The deliverables of the S-TEN project include a description
of the bi-directional translation from EXPRESS to OWL and a
list of the EXPRESS features that have not been translated yet
(e.g., optional/mandatory attributes, aggregate bounds, lists, and
arrays). As parts of the S-TEN project, tools have been developed
to manage and access web-based databases, to convert EXPRESS
schemas and instances to OWL, and to convert OWL data to
The S-TEN approach translates selected modules, which only
covers a subset of STEP APs. This restricts the range of instance
files that can be automatically translated to OWL. Further, the OWL
schemas are manually modified after translation. On the other
hand, our approach is defined at the EXPRESS language level. Using
the OntoSTEP plugin, a user can automatically translate both the
EXPRESS schema (as long as the schema is available as an EXPRESS
file) and the instance file.
Zhao and Liu, from the Zhongshan University in China,
proposed a methodology to represent EXPRESS models in OWL and
SWRL [31], a rule-based language for OWL. Their report describes
the approach in two parts. In the first part, the mapping between
EXPRESS schemas and OWL and SWRL is discussed. SWRL adds
more capabilities to OWL by permitting rule-based inference over
the ontology. In the second part, the combination of the OWL
ontology and the SWRL rules is integrated into Jess, a Rule Engine
for Java. As OWL, SWRL and the Jess rules can be described
in EXtensible Markup Language (XML), an EXtensible Stylesheet
Language Transformation (XSLT) is performed to achieve this
integration. The different steps involved in the process are
described. The authors also present a set of tools that can be used
to query and reason over the ontology.
Zhao and Liu also translated procedural code contained in the
EXPRESS schemas. The procedural code specifies algorithms that
can be used to compute derived attributes or to check the validity
of data. Since OWL is not a procedural language, the authors chose
to use Jess rules to represent EXPRESS procedures and functions.
However it is not clear whether this mapping between procedures
and Jess rules could work for all the procedures. Moreover, some
aspects of the EXPRESS language are not properly dealt with.
For instance, the translation of ordered lists in EXPRESS was
not proposed. Automated tools doing the entire translation are
planned, but we are not aware of any software released.
Zhao and Liu have proposed mapping rules between EXPRESS
and OWL. OntoSTEP does not have exactly the same mapping rules.
For example we have chosen a different approach for dealing with
aggregations and naming conventions. Also they did not mention
the translation of existing instance files. Moreover we could not
find the tools related to this work for an automatic translation.
In addition to the previous research works, some research has
been done under ISO with the recent AP239. AP239 provides
a mechanism for enriching product data by using external
classification. External classification enables users to define
controlled vocabularies that are used to specialize instances of
generic entities of the AP239 EXPRESS schema. The use of OWL is
recommended, to define controlled vocabularies. This mechanism
is known as Reference Data Library (RDL). Using RDL differs from
OntoSTEP since only the enriching elements are defined in OWL,
and the original product model data in EXPRESS.
4. Implementation of OntoSTEP
The Section 2 discussed the transformation rules and mappings
necessary to generate an ontology from EXPRESS schemas and
instance files. In this section we present and discuss aspects related
to the implementation of these rules and mappings. The main goal
here is to create tools to generate ontologies from STEP data. These
tools translate both schema files and instances files (Part 21).
We use the Protégé [17] editor to implement OntoSTEP as a
plug-in to Protégé. Protégé is a free, open source ontology editor
and knowledge base framework. It is one of the most widely
used tools to edit and manage knowledge bases. The Protégé
architecture allows third party developers to write their own
extensions in Java.
The implementation involves the following steps: generation of
the OWL Schema from the EXPRESS Schema (schema translation
for creating TBox), generation of the OWL individuals from the Part
21 file (schema instantiation for creating ABox), and development
of a plug-in to integrate the TBox and ABox within the Protégé
environment. We will also combine OntoSTEP with CPM–OAM
(Step 3 in Fig. 5) to create an ontology representing non-geometry
4.1. Translating EXPRESS schemas
The translation of an EXPRESS schema is carried out in two
stages. First, we retrieve the syntax tree, i.e. structured representa-
tion, of the schema. This is done by using a tool to generate a parser
from the EXPRESS grammar. This parser is then able to create a syn-
tax tree from a file that conforms to the grammar. Second, we scan
the syntax tree and apply the rules described in Section 3. During
R. Barbau et al. / Computer-Aided Design 44 (2012) 575–590 583
Fig. 5. Implementation of OntoSTEP.
this scan, specific actions are taken depending on the encountered
element. For instance, in our implementation, the detection of the
keyword ENTITY leads to the creation of a class in OWL.
In order to obtain the syntax tree of the EXPRESS schema, we use
a modified version of the open source EXPRESS Parser [32], which
contains the EXPRESS grammar. This parser is implemented using
ANTLR (ANother Tool for Language Recognition) [33] to generate
the EXPRESS parser from the EXPRESS grammar.
We used the open source OWL Application Programming
Interface (OWL API) [34] for OWL2 to create the ontology. This API
is used by Protégé 4 [17].
4.2. Translating instances
The translation process for Part 21 files is similar to the
translation process for the EXPRESS schema. First, we retrieve the
syntax tree of a Part 21 file using the Part 21 grammar and a parser
generator. Second, we scan the syntax tree and create the OWL
constructs using an API. For each instance encountered in the Part
21 file, an individual is created, and its attributes are obtained and
The result is a file containing all the individuals and the
assertions on these individuals (ABox). The TBox translation of the
EXPRESS schema is also imported as it contains the definition of
the OWL classes.
The same technologies as for the TBox are used: ANTLR is used
to generate a Part 21 parser, and OWLAPI is used to generate the
OWL constructs.
4.3. Protégé plug-in of OntoSTEP
The third and last step of this implementation is to integrate
the schema and the Part 21 translations within the Protégé editor.
This integration is done via the plug-in platform provided by the
editor. This platform allows developers to extend the capabilities
of Protégé by developing their own plug-ins. The OntoSTEP plug-
in we developed provides two new menu options in Protégé. One
option allows schema translation, and the other option allows
schema instantiation. The resulting ontology is displayed through
Protégé and users are then free to manipulate the ontology. This
implementation of OntoSTEP is summarized in the Fig. 5. The
plugin also includes options to select whether the EXPRESS schema
translation will result in an OWL RL ontology, as defined in 2.3.1
(less expressivity but better performances), and whether the entire
Part 21 file or only the bill of material should be translated.
5. Application of OntoSTEP to enrich product models
OntoSTEP can be extended, as OWL schema and individuals can
be enriched by the inclusion of external knowledge, such as other
product models represented in OWL or public ontologies.
5.1. Example 1: combining STEP and CPM/OAM information
This section provides an example of data integration by the
combination of geometry information defined in STEP, with non-
geometry information defined using CPM and OAM. CPM and
OAM have been chosen for 2 reasons: (1) Both models represent
concepts which are not defined in AP203 whose focus is on
geometry representation, (2) Both models have been originally
designed in a different modeling language than AP203, which
makes them good candidates to demonstrate how ontologies can
ease data integration of heterogeneous models, UML and EXPRESS
in this paper.
In [14] the authors explain the translation of CPM from UML to
OWL. Extensions written in other languages such as UML can be
584 R. Barbau et al. / Computer-Aided Design 44 (2012) 575–590
Table 5
Functional decomposition of the clock.
Subassembly Function
Speed-reduction Change the angular speed
Escapement Transmit motion
Weight Provide energy
Pendulum Create motion
Face Show the reading
Frame Support
translated in OWL, but it is out of the scope of this paper. We use
Arial Narrow font to denote CPM terms.
5.1.1. Motivation for including non-geometry information
NIST developed a Core Product Model (CPM) [35] that provides
an open, generic, and expandable product model. CPM aims to
capture all product information shared throughout the product
lifecycle. The key concepts of CPM are Artifact and Feature. Artifact
represents a product. A sub-artifact relationship allows product
decomposition. Feature is defined as a portion of an artifact’s form
that has specific functions. Different characteristics of the Artifact
are also described in CPM. Function describes what the artifact is
supposed to do. Form describes a design solution for the problem
specified by a Function. A Form in CPM is composed of Geometry
and Material. Behavior describes how an Artifact implements a
Function. CPM also defines different kinds of relationships, such as
Constraint or Usage, to link all the previous concepts.
Because CPM is a generic product model, an extension called
the Open Assembly Model (OAM) [36] was created in order to
include assembly representation. Some generic concepts defined
in CPM are specialized into assembly-specific concepts in OAM.
For instance, Artifact is specialized into Assembly and Part.
Particular focus is given to the connections between artifacts
(MoveableConnection, FixedConnection, IntermittentConnection,
etc.). These connections can also describe parametric assembly
constraints, and can include tolerance information.
We use both CPM/OAM and STEP AP203 to capture product
design information (non-geometry and geometry information).
CPM and AP203 share several notions, for example the class Artifact
and the entity Product refer to the same concept. Moreover, both
models can specify relationships between Artifacts. The goal of the
integration is to make sure that information representing the same
knowledge is actually recognized as such.
In order to make the integration possible, the data has
to be expressed in the same language. To get an integrated
representation in OWL, we used the translation tools from EXPRESS
to OWL previously introduced, and the OWL version of CPM/OAM
explained in [14].
5.1.2. A clock design example
In this section, we show how to combine AP203 and CPM
through a clock design. AP203 is used to create a 3D CAD model of a
product, while CPM and OAM are used to represent the functional
decomposition of this product and the relationships between the
Functional decomposition
The first step is to perform a functional decomposition of the
clock assembly. The different parts of the assembly are identified,
and their functions are provided. The result of this design phase
is an assembly composed of six subassemblies. In CPM, one
Artifact is created for the assembly and for each subassembly,
and the relationship subArtifacts is used to relate them. Then
for each Artifact, a function is created and linked to each Artifact
through the relationship functionOfArtifact. Table 5 presents these
subassemblies and their corresponding functions.
Fig. 6. 3D representation of the Speed-reduction subassembly.
Geometric definition of the clock
The next step is the design of the product using a CAD system.
The assemblies were created using Pro/ENGINEER [37], and then
saved in Part 21 files conform to AP203. The parts are set to
have the same name in the CAD file and in the CPM model, so
that they can be easily mapped. Fig. 6 shows the Speed-reduction
Integration of geometry and non-geometry information
The previous steps allowed the designer to create two different
assemblies using two different data models: the AP203 and the
OAM models. The benefit of using semantic technologies is the
capability to bring in external knowledge to create a richer model.
For instance, in this case we can assert that the clock that
has a geometric representation in AP203 model is the same as
the clock that has a function in CPM. Then, all the knowledge
about the product in each of the two models will be shared.
This capability of aggregating multiple sources of knowledge is
crucial for product lifecycle management due to the collaborative
nature of product development. The use of ontologies as a way of
enabling data integration in heterogeneous environments has been
demonstrated in many domains [38], such as finance, healthcare
and manufacturing. Ontologies benefit from new, diverse and
powerful mapping mechanisms which ease the reconnaissance of
common concepts and have been improving over the past years as
explained in [39].
In order to integrate the geometric data, we follow the
steps defined in the previous section. First, use the OntoSTEP
Protégé plug-in to generate an OWL representation of an AP203
EXPRESS schema used to represent the clock. The resulting OWL
representation is saved, so that it can be reused by all the relevant
Part 21 translations. Second, use the OntoSTEP plug-in to convert
our CAD file into OWL. This translation requires the schema to be
already translated, so the ontology previously created is selected
and imported by the plug-in. Once the translation is completed, all
the information described in the CAD file is available in Protégé.
Next, it is necessary to identify equivalent concepts in CPM
and in AP203. The main equivalence is between the class Artifact
in CPM and the entity Product in the AP203. Our goal will be
to match the instances of these two concepts in order to get a
single view of the product. We consider three levels of complexity
regarding the way the integration should be performed. The easiest
is an algorithm that is able to ‘‘guess’’ which parts are equivalent
in the two models from the information available. It could, for
instance, compare the assembly tree in the two models. The
hardest approach is to perform the integration manually because
there would be no way to ‘‘guess’’. This would make the designer
assert the equivalence in CPM each time a part is created in
CAD. A simple tradeoff is to have equivalent parts have the same
name in both models, in which case a simple rule that makes
R. Barbau et al. / Computer-Aided Design 44 (2012) 575–590 585
Fig. 7. 16-teeth gear in Protégé.
this equivalence based on the name is enough. This approach
relies on the assumption that designers have respected a naming
convention, so that such an automated process can be applied. We
used SWRL to implement this rule:
cpm:Artifact(?art) ˆ cpm:hasName(?art, ?artName) ˆ ap203:
product(?prod) ˆ ap203:product_has_name(?prod, ?prod
Name) ˆ ap203:toString(?prodName, ?prodNameVal) ˆ swrlb:
equal(?prodNameVal, ?artName) => sameAs(?art, ?prod).
OWL benefits
The benefits described in the Section 2.3 are especially relevant
in this example. The consistency checking ensures that each class,
whether it is the translation of an entity or the translation of a type,
is actually instantiable (they can be used). In addition, the Part 21
translation is checked in order to determine if the instances are
used as intended.
Once the ontology is verified, the inference mechanisms use
logic to determine the types of each translated individual. SWRL
rules are also executed by the reasoner. A single integrated
view of the product is then generated, as the ontology combines
geometry and non-geometry information. Fig. 7 shows the result
in Protégé for the 16-teeth gear (named ‘‘Art_23’’), which is part
of the Speed-reduction subassembly. The figure was annotated
to indicate the different sources for the individuals (Part 21 and
CPM instance) and for their classes (AP203 and CPM). The window
in this figure is vertically split into three panels. The left panel
contains the list of all the OWL individuals in the ontology. Here
the 16-teeth gear is selected, so the individual named ‘‘Art_23’’ is
highlighted. The middle panel shows all the classes the selected
individual is an instance of. The statements written as bold text
have been explicitly asserted while the statements written as
normal text have been inferred. In this example, the individual
Art_23 has been explicitly declared as an Artifact. As Art_23 is
also the same individual as product i53363, the type product is
inferred for Art_23. The right panel contains all the object property
assertions and all the data property assertions for the selected
individual. As an example of object property assertion, the gear is
linked to the function Fn_07 (Transmit_motion) by the CPM object
property artifactHasAspect. The gear is also linked to an identifier
i53363_id by the AP203 object property product_has_id. In
regards to data property assertions, the gear has a property
hasName that contains the value ‘‘Art_23’’.
It is now possible to take advantage of this integrated data to
query the ontology. We present two queries that use both CPM and
STEP information to answer simple questions a designer may ask.
The first query is about retrieving the function of a part defined
in a CAD system. The input of this query is the identifier of the
part defined in the CAD system. The expected output is a string
representing the function of that particular part. Here is the SQWRL
query that retrieves the function of the product i53363:
cpm:Artifact(i53363) ˆ cpm:Function(?func) ˆ cpm:artifactHas
Aspect(i53363, ?func) ˆ cpm:hasName(?func, ?name) =>
Because of the integration previously performed, the product
i53363 is recognized as being the Artifact Art_23. Hence i53363
gets the properties of Art_23, including the functions Fn_07
(Transmit_motion) and Fn_12 (Change_angular_speed) (see Fig. 7).
Thus, we are able to infer that the 16-teeth gear performs the
functions of transmitting motion and changing angular speed. This
new knowledge would not have been possible with the CAD model
The second query is about retrieving the parts that are
connected to a particular part via a fixed connection. The CPM class
FixedConnection is a kind of ArtifactAssociation that is used to state
that two parts are physically connected and have a fixed joint. The
relationship artifactAssociation2Artifact links the connection with
the two involved parts. As in the previous query, the input will be
a particular part defined in a CAD system: the 16-teeth gear. Here
is the SQWRL query that gives the intended result:
cpm:Artifact(i53363) ˆ cpm:FixedConnection(?fc) ˆ cpm:artifact
Association2Artifact(?fc, i53363) ˆ cpm:artifactAssociation2
Artifact(?fc, ?art) => sqwrl:select(?art).
586 R. Barbau et al. / Computer-Aided Design 44 (2012) 575–590
This query returns the individuals representing a shaft in CPM
and in the CAD system. Since the class FixedConnection is defined
only in CPM, this knowledge cannot be represented in CAD alone.
5.2. Example 2: using controlled vocabularies for enriching product
Product model schemas are built for generic purpose, so they do
not always capture business specific concepts. However product
modelers sometimes need to refer to more specific concepts
in order to fully capture fine details. Shared ontologies offer a
controlled vocabulary and can be easily used by various product
modelers to precisely define specific concept. People referring
to the same concept use the same definition of this concept.
Shared ontologies do not always provide sufficient specialization
to precisely express the modeler’s idea, so these ontologies can
often be extended to capture more specific concepts. An example
of shared ontology in the product modeling domain is ISO 13584:
PLib [40]. PLib aims at offering a model and exchange format for
digital libraries of technical components.
In order to use a shared ontology, it is necessary to establish the
connection between a product model and the external concepts it
refers to. This connection will likely be explicitly stated within the
product model, or defined elsewhere if the product model schema
does not allow such extension.
As an example of shared ontology usage, if a modeler creates a
product model that represents a piping system, all the parts will
be indicated as ‘‘part’’. The modeler may want to assert these parts
are actually pipes, elbows or valves, but the original schema does
not contain these concepts. The modeler can then connect the part
to a concept that is defined in PLib.
The use of ontologies enables semantic searches to be
performed instead of text searches. For instance, let us suppose a
part is declared as a ‘‘gate valve’’. If someone is looking for a ‘‘valve’’,
a simple text search will be able to retrieve this part. However, if
someone is looking for ‘‘piping equipment’’, a text search will fail.
In a semantic context, ‘‘gate_valve’’ is not just a text, but a concept
that is connected to other concepts. So assuming the ‘‘gate valve’’ is
well defined as piping equipment, the semantic query will succeed.
Presentation of the STEP approach to refer to external concepts
STEP provides a mechanism that enables customization of
product models with domain-specific concepts. Modelers can
classify STEP instances with concepts defined in an external
controlled vocabulary. This is called external classification, as this
controlled vocabularies formally define the semantic of domain-
specific concepts that specialize generic terms from the EXPRESS
In the following example (Fig. 8), we show an OWL ontology
that defines a product taxonomy. This taxonomy can be used to
specialize the generic concept of product defined in APs such as
AP203, AP214 or AP239. The use of such taxonomy helps capturing
more accurately the intent of the product modeler.
The most recent STEP APs, such as AP239 or AP203 second
edition, support the external classification. Instances are classified
by providing an external library identifier and a class name.
Unfortunately no specific guidance or limitations are given in the
standard regarding how the classification mechanism should be
implemented. Additional and ad hoc tools are needed to check
the correctness and to merge the external knowledge with the
product model. Implementation guidance can be defined as part of
an agreement. For example, for the AP239, the OASIS recommends
that OWL be used for representing controlled vocabularies that
specialize the AP239. In a particular data exchange agreement
using PLCS, an identifier is given to the external library. This
identifier is then used in the STEP instance file. As a result,
Fig. 8. OWL ontology used for classification.
knowledge of the agreement is necessary to implement the
classification mechanism.
Presentation and benefits of the OntoSTEP approach to refer to external
OntoSTEP provides a mechanism for translating product models
from STEP to OWL. One of the goal of OWL is to provide a way for
different data source to commit to the same ontology for shared
meaning [41]. As part of the Semantic Web, OWL ontologies can
be easily published on the Internet. One of the benefits of having a
representation of STEP product models into OWL is the possibility
to directly classify individuals defined in the product model as
concepts defined in external ontologies. The knowledge associated
with these concepts is automatically imported and merged with
the product model knowledge. Because this mechanism is part of
the OWL language, no additional tool is necessary to achieve the
goal of classifying STEP instances.
The Fig. 9 shows a query over a product model translated into
OWL in Protégé. The individuals #55403, #55456 and #55483 were
respectively classified as gate valve, check valve and globe valve
according to the taxonomy showed in Fig. 8. This query asks for
the piping equipment in the product model, and thanks to the
knowledge imported from the taxonomy, all three products were
identified as piping equipment.
6. Meta-model based model transformations
A model transformation is a sequence of well-defined rules
that takes an input model (such as an EXPRESS model) and pro-
duces an output model (such as an OWL model). While these
transformations are usually conceived as high-level mappings as
described here, they are often implemented using an imperative
programming language such as Java. However, recent develop-
ments in model transformation allow us to specify these mappings
using more formal, high level, visual representations. Using these
technologies, the transformations themselves can be specified as
models, which allows better understanding, analyzing, and archiv-
ing the transformation. This is particularly significant when con-
sidering long term retention of these specifications.
A meta-model in systems engineering is a model that captures
the salient concepts and relations of a domain, along with the
rules that define the domain. Meta-model based transformations
provide a high-level specification of a mapping between two
domains (called source and target domains), such as from EXPRESS
R. Barbau et al. / Computer-Aided Design 44 (2012) 575–590 587
Fig. 9. Individuals classified as piping_equipment.
to OWL, that is easier to understand and analyze. The high-level
specifications are also easier to evolve when changes are made to
the source and target domains.
Section 2 described the mapping rules we used to translate
STEP models into OWL. In this section, we create a model
transformation from these mapping rules. As an example, we
created meta-models for EXPRESS and OWL (derived from a
subset of the previously published Meta-Object Facility (MOF)
meta-models for these languages in [42,43]). We specified model
transformation rules based on our previous mapping descriptions,
and used an automatic model transformation tool to execute the
transformation. This example is described next.
6.1. Example using GME/GReAT
As a prototype study, we have used the Generic Modeling
Environment (GME) [44], a tool for domain modeling developed
at Vanderbilt University, to create meta-models for subsets
of EXPRESS and OWL. The meta-models are defined using
stereotyped Unified Modeling Language (UML) class diagrams,
as shown in Figs. 10 and 11. The notation used in these meta-
models is in the native meta-language of the GME tool, which
is derived from UML class diagrams. More details on the meta-
language can be found in [45]. The meta-models for EXPRESS
and OWL used in this example were created by extracting a
small subset of the MOF meta-models that were defined in
[42,43]. We use the Arial Unicode MS font to denote concepts
defined in GME. For example, Fig. 10 shows a subset of the
EXPRESS meta-model, which defines concepts called EntityType
and Attribute. Attribute has a relation called attribute type, which
connects it to ParameterType (ParameterType is shown in italics
to denote that it is an abstract type). Connections are modeled
as UML association classes, and the rolenames (‘srcattributetype’
and ‘dstattributetype’) on the connections are used by the GME
toolset to keep track of the source and destination objects in the
instance models. The ParameterType has three subtypes namely
SimpleType, DefinedType, and EntityType. Fig. 11 shows a subset
of the OWL meta-model. It defines concepts such as OWLClass
and Property. OWLRestriction is a subtype of OWLClass. OWLClass
and Property have a relation called DomainForProperty. The
rolenames ‘srcDomainForProperty’ and ‘dstDomainForProperty’
for this connection are used by GME to keep track of the source
and target objects of this connection.
Next, we specified the mapping rules described in this paper
as high-level model transformation rules. We used the Graph
Rewriting And Transformation (GReAT) tool suite [46] to specify
and execute the model transformation. GReAT allows us to specify
the transformation rules as graph transformations, by treating the
concepts and relations in the input and output models as nodes
and edges of a graph. The rules specify portions of the input that
must be matched, and portions of the output that must be newly
created. Fig. 12 shows the transformation specified in GReAT, with
two of the rules expanded for detail. The first rule, CreateOWLClass,
specifies the creation of an OWL class corresponding to an entity
in the EXPRESS schema. This rule denotes that instances of
EntityType must be matched in the input EXPRESS schema, and
for every matched entity, an OWLClass must be created in the
output OWL schema. The rule AssignDomains assigns the domain
for a previously created OWL property in the output model,
corresponding to the attribute type in the input model.
The GReAT tool suite allows us to organize the transformation
rules both sequentially and in parallel, and encapsulate them
hierarchically, making it convenient to analyze and maintain
them. Each of the elements in the transformation rule must
come from one of the two meta-models. The patterns specified
in the transformation rules cannot violate the meta-models. This
ensures that the output model is conformant with the OWL meta-
model, reducing the possibility of producing an erroneous output
model. Other verification methods and technologies are available
to perform further analysis, to ensure that the transformation
produced the correct result.
7. Conclusions and future work
In this paper, we presented an approach to enable the
translation of STEP schema and Part 21 files defined in EXPRESS
to OWL. We described the mapping rules for the translation from
EXPRESS to OWL, and outlined the benefits of OWL translation
with an example. Translating an information structure based on a
modeling paradigm and language representation will always have
issues in terms of concepts mismatch and loss in translation, but
even with this problem, translating entities defined in EXPRESS to
concepts in OWL provides a mechanism for exploiting the rigor
of OWL. The OntoSTEP explained in this paper is a step toward
semantically enriching product information. OntoSTEP can easily
be integrated with other OWL ontologies, such as other product
models or public ontologies.
Manufacturing systems today must deal with product lifecycle
information that goes beyond basic 3D geometry. As an example of
enriched product model, we described an approach to include in-
formation such as product function, behavior, requirements that
were described using other product models. As a first step we
translated STEP AP schema to OWL representation and then in-
corporated beyond geometry information using our earlier model
CPM. In this paper, we explained the additional benefits, reason-
ing, inference procedures, and queries that can be performed on
the enriched model. A plug-in for Protégé was developed to trans-
late the STEP AP and the CAD output file (Part 21 file) to create
the TBox and ABox respectively. The Protégé plug-in can be down-
loaded from
We would like to point out some of the assumptions and
limitations of our approach. Our goal was to find a representation
of STEP data in OWL that would capture as much information
588 R. Barbau et al. / Computer-Aided Design 44 (2012) 575–590
Fig. 10. Representative subset of express meta-model.
Fig. 11. Representative subset of OWL meta-model.
as possible, without sacrificing reasoning and inference. As a
result, we did not (because of an increased complexity) or could
not (because OWL did not support the feature) translate some
features of the EXPRESS language. This results in the ontology
not containing as much validation restrictions as in the EXPRESS
schema. However the most critical EXPRESS information (entities,
relationships and instances) is translated into OWL. OntoSTEP
should not be seen as a replacement of EXPRESS and Part 21,
but more as an alternative representation for EXPRESS data. In a
similar way that ISO 10303-28 provides an XML representation
for EXPRESS data, OntoSTEP provides an OWL representation for
EXPRESS data, which allows the creation of semantically enriched
product models. To be fully compliant, an instance file, whether it
is represented with Part 21, XML or OWL, needs a validation against
the EXPRESS schema.
Even with these tradeoffs, there will still be scalability issues
that will make reasoning and inference problematic for complex
product representations. These could be addressed by using the
approach presented in Section 6. For example, various mapping
rules could be implemented through meta-model based model
transformations. This will address several issues described earlier,
such as size, translation loss, and implementation issues.
The OWL ontologies generated by this approach have several
applications beyond the examples described in this paper. One
such application is for long term preservation of engineering
data. The objective of the Long Term Knowledge Retention (LTKR)
project at NIST is to define guidelines and information models to
enable effective archival and retrieval of digital product model data
and other engineering-related documents. The current strategy
for preserving product model data is to use STEP instead of
proprietary formats [47]. The main motivation is that standard
formats are less likely to change than proprietary formats. We
believe OntoSTEP provides a good alternative or complementary
solution for representing product model data in the context
of LTKR. The data integration given by OWL can facilitate the
discovery of product data within the archive. Since the OWL
language is being used in several other domains, we believe that
more advanced tools to interpret the product model data in OWL
will be available in the future.
No approval or endorsement of any commercial product by NIST
is intended or implied. Certain commercial software are identified
in this report to facilitate better understanding. Such identification
does not imply recommendations or endorsement by NIST nor does
R. Barbau et al. / Computer-Aided Design 44 (2012) 575–590 589
Fig. 12. Model transformation from EXPRESS to OWL.
it imply the software identified are necessarily the best available
for the purpose.
[1] Subrahmanian E, Rachuri S, Fenves S, Foufou S, Sriram RD. Product
lifecycle management support: a challenge in supporting product design and
manufacturing in a networked economy. International Journal of Product
Lifecycle Management 2005;1(1):4–25.
[2] Sudarsan R, Subrahmanian E, Bouras A, Fenves S, Foufou S, Sriram RD.
Information sharing and exchange in the context of product lifecycle
management: role of standards. Computer-Aided Design 2008;789–800.
[3] International Organization for Standardization. ISO 10303-11: 1994. Industrial
automation systems and integration product data representation and
exchange part 1: overview and fundamental principles. 1994.
[4] International Organization for Standardization. ISO 10303-203: 1994. Indus-
trial automation systems and integration product data representation and
exchange part 203: application protocol: configuration controlled 3D design
of mechanical parts and assemblies. 1994.
[5] International Organization for Standardization. ISO 10303-214: 2003 Indus-
trial automation systems and integration product data representation and
exchange part 214: application protocol: core data for automotive mechan-
ical design processes. 2003.
[6] International Organization for Standardization. ISO 10303-239: 2005. Indus-
trial automation systems and integration product data representation and
exchange part 239: application protocol: product life cycle support. 2005.
[7] International Organization for Standardization. ISO 10303-11: 1994. Indus-
trial automation systems and integration product data representation an-
dexchange part 11: description methods: The EXPRESS language reference
manual. 1994.
[8] Schenck D, Wilson PR. Information modeling: the EXPRESS way. New York:
Oxford University Press; 1994.
[9] International Organization for Standardization. ISO 10303-21: 2002 Industrial
automation systems and integration product data representation and
exchange part 21: implementation methods: clear text encoding of the
exchange structure. 2002.
[10] OWL Web Ontology Language Overview.
features/. 2004.
[11] Fiorentini X, Rachuri S, Mahesh M, Fenves S, Sriram RD. Description logic
for product information models. In: Proceedings of the ASME international
design engineering technical conferences & computers and information in
engineering conference. 2008.
[12] SWRL, W3C Member Submission.
[13] Krima S, Barbau R, Fiorentini X, Rachuri S, Sriram RD. OntoSTEP: OWL-DL
ontology for STEP. National Institue of Standards and Technology, NISTIR 7561.
Gaithersburg. MD 20899. USA; 2009.
[14] Fiorentini X, Gambino I, Liang V, Rachuri S, Mahesh M, Bock C. An ontology
for assembly representation. National Institute of Standards and Technology,
NISTIR 7436. Gaithersburg. MD 20899. USA; 2007.
[15] Fenves S, Foufou S, Bock C, Sriram RD. CPM2: a core model for product
data. Journal of Computing and Information Science in Engineering 2008;8(1):
[16] Baysal MM, Roy U, Sudarsan R, Sriram RD, Lyons KW. The open assembly model
for the exchange of assembly and tolerance information: overview and exam-
ple. In: Proceedings of the ASME international design engineering technical
conferences & computers and information in engineering conference. 2004.
[17] Protégé. 2008.
[18] Tao J, Sirin E, Bao J, McGuinness DL. Integrity constraints in OWL, In:
Proceedings of the twenty-fourth AAAI conference on artificial intelligence.
[19] OWL 2 Web Ontology Language Profiles.
profiles/. 10-27-2009.
[20] Hitzler P, Krotzch M, Rudolph S. Foundations of semantic web technologies.
CRC Press; 2009.
[21] Sriram RD. Intelligent systems for engineering: a knowledge-based approach.
Springer; 1997.
[22] Koonce D, Huang L, Judd R. EQL an EXPRESS query language. Computers &
Industrial Engineering 1998;35(1–2):271–4.
590 R. Barbau et al. / Computer-Aided Design 44 (2012) 575–590
[23] SPARQL Query Language for RDF.
[24] SQWRL. 2009.
[25] LLC. Pellet. 2008.
[26] SQWRL—Aggregation functions.
SQWRL#nidA20. 2009.
[27] Sandia National Laboratories. Jess engine.
[28] Openmoko project. 2011.
[29] Klein L, Liutkus G, Nargelas V, Sileikis P, Baltramaitis T, Schowe-von der Brelie
B, Alfter A, Wesbuer C. Ontologies derived from STEP data models. S-TEN.
Deliverable D3.3. 2008.
[30] S-Ten SemanticSTEP. 2009.
[31] Zhao W, Liu JK. OWL/SWRL representation methodology for EXPRESS-driven
product information model. Computers in Industry 2008;59:580–600.
[32] Lubell J, Lardet S. Open source EXPRESS Parser.
projects/osexpress/. 2001.
[33] ANTLR Parser generator. 2008.
[34] University of Manchester. OWL API.
[35] Fenves S, Foufou S, Bock C, Bouillon N, Sriram RD. CPM2: a revised core product
model for representing design information. National Institute of Standards and
Technology, NISTIR 7185. Gaithersburg. MD 20899. USA; 2004.
[36] Sudarsan R, Young-Hyun H, Foufou S, Feng SC, Roy U, Fujun W, Sriram RD,
Lyons KW. A model for capturing product assembly information. Journal of
Computing and Information Science in Engineering 2006;6(1):11–21.
[37] PTC. Pro/ENGINEER. 2010.
[38] Kaza S, Chen H. Evaluating ontology mapping techniques: an experiment
in public safety information sharing. Decision Support Systems 2008;45(4):
[39] Kalfoglou Y, Schorlemmer M. Ontology mapping: the state of the art. The
Knowledge Engineering Review 2003;18(1):1–31.
[40] Pierra G, Sardet E, Potier JC, Battier G, Derouet JC, Willmann N, Mahir A.
Exchange of component data: the PLib (ISO 13584) model, standard and tools.
Proceedings of the CALS EUROPE’98 Conference 1998;160–76.
[41] W3C. Shared ontologies.
ontologies. 2-10-2004.
[42] Object Management Group. Ontology definition metamodel. 2008.
[43] Object Management Group. Reference metamodel for the EXPRESS informa-
tion modeling language RFC. 2008.
[44] Ledeczi A, Bakay A, Maroti M, Volgyesi P, Nordstrom G, Sprinkle J, Karsai G.
Composing domain-specific design environments. Computer 2001;34(11):
[45] The GME User’s Manual. 2010.
[46] Balasubramanian D, Narayanan A, VanBuskirk C, Karsai G. The graph rewriting
and transformation language: GReAT. Electronic Communications of the
EASST 2006;1.
[47] LOTAR—LOng Term Archiving and Retrieval of digital technical product docu-
mentation such as 3D, CAD and PDM data.
Raphael Barbau received his M.SC degree in Computer
Science at the University of Burgundy. He is currently a
Guest Researcher at the National Institute of Standards and
Technology, Gaithersburg, MD.
Sudarsan Rachuri is a Computer Scientist in the Systems
Integration Division, Engineering Laboratory at National
Institute of Standards and Technology, USA. His primary
objectives at NIST are to develop and transfer knowledge
to industry about standards and information models for
sustainable manufacturing, green products, assembly rep-
resentation, system level analysis, and tolerance represen-
tation. He is a member of ASME Y14.5.1. He is the re-
gional editor (North America) for the International Journal
of Product Development, and associate editor for Interna-
tional Journal of Product Lifecycle Management. Sudarsan
Rachuri received the M.S. and Ph.D. degrees from the Indian Institute of Science,
Bangalore, India.
Anantha Narayanan is a Research Scientist at the Institute
for Software Integrated Systems (ISIS), at Vanderbilt Uni-
versity, in Nashville, TN, USA. He is currently working as
a guest researcher at the National Institute of Standards
and Technology (NIST). His research interests are in do-
main specific modeling, model transformations, systems
engineering, product life cycle modeling, and sustainable
manufacturing. Anantha has a B.Tech. in Mechanical Engi-
neering from IIT, Madras, India, and an M.S. and Ph.D. in
Computer Science from Vanderbilt University.
Xenia Fiorentini is one of the founders of Engisis, a com-
pany that supports the adoption of international standards
for product data exchange and business collaboration. She
serves as consultant in the areas of integrated logistic sup-
port, systems interoperability, and standards application.
Before founding Engisis, Xenia Fiorentini worked for four
years as a guest researcher at the National Institute of Stan-
dards and Technology (NIST). She earned a Master of Sci-
ence in industrial engineering in the systems engineering
college at the Politecnico di Milano, Italy. She also earned
a diploma from the Alta Scuola Politecnica, a school for the
management of complex innovation projects.
Sebti Foufou obtained a Ph.D. in computer science in
1997 from the University of Claude Bernard Lyon I, France,
for a dissertation on parametric surfaces intersections.
He worked with the computer science department at the
University of Burgundy, France since 1998 as associate
professor and then as a full professor. His research
interests concern computer graphics, geometric modelling
and CAD-CAM topics and include: surfaces blending
using Dupin cyclides, subdivision surfaces, geometric
constraints solving, ontologies and semantic web tools for
product information representation. He also worked in
2005 and 2006, as a guest researcher, at the National Institute of Standards and
Technology, Gaithersburg, MD, USA, where he contributed in product engineering
related researches: smart machining systems, tolerances, assembly modelling and
PLM. He is with the computer science department at Qatar University since Sept.
2009. Prof. Sebti Foufou has been involved in various projects related to computer
graphics, imaging and semantic web. He is serving on the technical committees of
several international conferences and member of the review board of a number of
international journals.
Ram D. Sriram is currently the chief of theSoftware
and Systems Division, Information Technology Laboratory,
at the National Institute of Standards and Technology.
Before joining the Software and Systems Division, Sriram
was theleader of the Design and Process group in the Man-
ufacturing Systems Integration Division, Manufacturing
Engineering Laboratory, where he conducted research on
standards for interoperability of computer-aided design
systems. He was also the manager of the Sustainable Man-
ufacturing Program. Prior to joining NIST, he was on the
engineering faculty (1986–1994) at the Massachusetts In-
stitute of Technology (MIT) and was instrumental in setting up the Intelligent En-
gineering Systems Laboratory. Sriram has co-authored or authored nearly 250 pub-
lications, including several books. Sriram was a founding co-editor of the Interna-
tional Journal for AI in Engineering. In 1989, he was awarded a Presidential Young
Investigator Award from the National Science Foundation, USA. He is also the recip-
ient of the 2011 ASME Design Automation Award. Sriram is a Fellow of ASME and
AAAS, a life member of ACM, a Senior Member of the IEEE, and a member of AAAI.
Sriram has a B.Tech. from IIT, Madras, India, and an M.S. and a Ph.D. from Carnegie
Mellon University, Pittsburgh, USA.
... OntoSTEP is an application-based technique that translates STandard for the Exchange of Product Model Data (STEP), or International Organization for Standardization (ISO) 10303, schemas represented in the EXPRESS language [1] and instances represented as STEP Part 21 (P21) files [2], into an ontology and a Knowledge Graph (KG) represented in the Web Ontology Language (OWL) [3,4]. On-toSTEP formally represents entities and attributes in STEP data models using ontologies. ...
... Zhao and Liu [10] proposed a method to represent EX-PRESS schemas in OWL and Semantic Web Rule Language (SWRL) and used Java Expert System Shell (Jess) rules to represent EXPRESS procedures and functions. Krima et al. [3] and Barbau et al. [4] proposed OntoSTEP that enables EXPRESS and P21-to-OWL translation. They demonstrated how to link the model geometry of a product with Core Product Model (CPM) [14] and Open Assembly Model (OAM) [15]. ...
... There are also issues related to the specification of the OntoSTEP translation. Firstly, the plugin does not strictly follow its original specification as described by Krima et al. [3]. For example, disjoint relationships are not supported in the plugin but still detailed in the specification. ...
OntoSTEP is a method to translate the STandard for the Exchange of Product model data (STEP) schema and its instances to an ontology and knowledge graphs represented in the Web Ontology Language (OWL). OntoSTEP models can be integrated with any OWL models to enrich their semantics. However, the current implementation has several limitations , mainly in (1) supporting the latest ISO 10303 schemas and (2) generating various representation types depending on the purpose of use. We present an improved implementation of OntoSTEP to overcome these limitations. In this paper , we demonstrate that the new implementation can successfully translate STEP schemas and instances in a faster and more flexible way, thus furthering the adoption of the full capabilities of ISO 10303. By encoding STEP entities in OWL, we facilitate integration with other standards through knowledge graphs.
... [130], [265]. Viele Konzeptualisierungen beinhalten jedoch auch Konstrukte, die sich auch in logikbasierten Sprachen abbilden ließen, ohne dass diese aber als semantisch betitelt werden 47 [155] hat sich bereits mit dem OWL Vorgänger DAML+OIL abgezeichnet [205] und macht Ansätze mit geringerem Formalisierungsgrad der Semantik, wie beispielsweise [207], bereits im Vorfeld obsolet. OntoSTEP berücksichtigt jedoch nur den Teil von STEP, der formal in EXPRESS beschrieben ist. ...
Full-text available
he concept provides a means to characterise the solution spaces of fully defined geometrical constraint solving problems defining the relative position of points, lines and planes implicitly by nonlinear geometrical constraints such as angle and distance. In general, multiple solutions exist for each of those problems. The geometrical interpretation of each solution is referred to as variational geometry. While all variational geometries are equivalent from the perspective of the problem formulation not all variational geometries are equivalent in other interpretation contexts. The characterisation of variational geometries aims at their differentiation in order to allow for their selection, also known as solution selection. In order to disambiguate two sets of the solution space the chirality relation of two geometric elements is used as minimal information. For computer-aided design the concept is applicable to variational geometries in two-dimensional sketches and three-dimensional assembly models. Other possible application areas include the interpretation of sensor-based measurements. Constraints within variational geometries do not include direction information that is necessary to identify which geometric element defines which other geometric element. A deficit of existing approaches for solution selection consists in taking the direction information of constraints for granted. Other deficits are their limitation to points and the lacking proof of their completeness and correctness. To overcome this deficit, a solution selection is required that enables the selection of geometrically unique solutions. In order to guarantee geometrical uniqueness such a solution selection needs to be founded on a concept which enables the characterisation of all variational geometries, given a specific geometrical problem. The proposed concepts for solution selection and characterisation fulfil these conditions. Especially, the concept is designed to enable characterisations under uncertainty with respect to the constraint directions as well as position and orientation of the geometrical elements. The uncertainty information is explicitly modelled in a decidable description logic. Hence, the description logic representation of the geometrical problem may be exploited with deductive reasoning methods in order to assess whether the variational geometry is defined geometrically unique and if the calculated variational geometry corresponds to the modelling intent of the designer. The main contributions of the dissertation consist in the development of a conceptual, declarative and procedural part. The conditions for a geometrically unique solution selection are formalised in the description logic definition of geometrical uniqueness, building up on the specification of 27 constraint problems, so called basic configurations. The geometrical uniqueness of a given geometrical problem is tested for a corresponding subset of these basic configurations. Additional contributions include the declarative prototype implementation of 32 constraints. A new method for the conversion of ISO 10303 standards into description logics has been developed and applied. For the considered set of geometrical problems upper and lower boundaries are estimated for the number of solutions and the number of solution selectors necessary to attain geometrical uniqueness. The concept has been implemented, verified and validated. The verification result indicates that a sequential assessment of solution selectors results in linear calculation time with respect to the number of variational geometries. The validation has been performed on a geometry that has been generated with a newly developed algorithm which offers an efficient way to generate variational geometries with specific topological properties. The validation result demonstrates the completeness and correctness of the characterisation. The transferability of the research results is facilitated by the use of existing standards like ISO 10303-108 and OWL 2. Finally, opportunities for the further reduction of solution selection information necessary to obtain geometrical unique variational geometries have been identified for future.
... OntoSTEP is the representation of STEP product models in Web Ontology Language. It was introduced in 2009 and is continuously being expanded [46,47]. ...
Full-text available
Mass customization aims to meet individual requirements and, therefore, is one way to attract and retain customers—a key challenge in the design industry. The increase in design automation has offered new opportunities to design customized products at high speed in a way that is cost equivalent to mass production. Design automation is built upon the reuse of product and process knowledge. Ontologies have proven to be a feasible, highly aggregated knowledge representation in engineering design. While product and process knowledge from other lifecycle phases are represented in multiple approaches, the design process of the product as well as the adaption process of product variants is missing, causing breakpoints or additional iterations in design automation. Therefore, suitable knowledge representation tailored to design automation is still missing. Accordingly, this contribution proposes a novel knowledge representation approach to enable design automation for mass customization. Methodically, this novel approach uses semantic enrichment of CAD environments to automatically deduce information about a design task, design rationale, and design process represented by a formal ontology. The integration of the design process significantly differentiates the approach from previous ones. The feasibility of the approach is demonstrated by a bike crank customization process.
... The users of our system are the different experts responsible for the task of developing machine learning methods. Indeed, none of the ontologies for manufacturing (e.g., [53][54][55][56][57][58]) fully serve as the communication model for our use cases and sufficiently cover our domains. The mapping-based data integration solutions like Ontop [59] are not particularly targeted towards our aim of minimising the involvement of ontologists into the model maintenance processes. ...
Full-text available
Monitoring of the state, performance, quality of operations and other parameters of equipment and productiosn processes, which is typically referred to as condition monitoring, is an important common practice in many industries including manufacturing, oil and gas, chemical and process industry. In the age of Industry 4.0, where the aim is a deep degree of production automation, unprecedented amounts of data are generated by equipment and processes, and this enables adoption of Machine Learning (ML) approaches for condition monitoring. Development of such ML models is challenging. On the one hand, it requires collaborative work of experts from different areas, including data scientists, engineers, process experts, and managers with asymmetric backgrounds. On the other hand, there is high variety and diversity of data relevant for condition monitoring. Both factors hampers ML modeling for condition monitoring. In this work, we address these challenges by empowering ML-based condition monitoring with semantic technologies. To this end we propose a software system SemML that allows to reuse and generalise ML pipelines for conditions monitoring by relying on semantics. In particular, SemML has several novel components and relies on ontologies and ontology templates for ML task negotiation and for data and ML feature annotation. SemML also allows to instantiate parametrised ML pipelines by semantic annotation of industrial data. With SemML, users do not need to dive into data and ML scripts when new datasets of a studied application scenario arrive. They only need to annotate data and then ML models will be constructed through the combination of semantic reasoning and ML modules. We demonstrate the benefits of SemML on a Bosch use-case of electric resistance welding with very promising results.
... This type of ontology has limited concept constraints such that their semantics are insufficient to support interoperability, i.e., to integrate different domain models [34]. To address this, particularly for the STEP format, the ONTOSTEP ontology was developed, which addressed the lack of logical formalism of EXPRESS so that reasoning and semantic operability could be realized [35]. Thus, heavyweight ontologies describe concepts, relationships and logic constraints for automatic prediction and logical inference. ...
Full-text available
The literature on the modeling and management of data generated through the lifecycle of a manufacturing system is split into two main paradigms: product lifecycle management (PLM) and product, process, resource (PPR) modeling. These paradigms are complementary, and the latter could be considered a more neutral version of the former. There are two main technologies associated with these paradigms: ontologies and databases. Database technology is widespread in industry and is well established. Ontologies remain largely a plaything of the academic community which, despite numerous projects and publications, have seen limited implementations in industrial manufacturing applications. The main objective of this paper is to provide a comparison between ontologies and databases, offering both qualitative and quantitative analyses in the context of PLM and PPR. To achieve this, the article presents (1) a literature review within the context of manufacturing systems that use databases and ontologies, identifying their respective strengths and weaknesses, and (2) an implementation in a real industrial scenario that demonstrates how different modeling approaches can be used for the same purpose. This experiment is used to enable discussion and comparative analysis of both modeling strategies.
Building Information Modeling (BIM) has revolutionized the construction industry as a platform for core integrated design, modeling, asset planning, and collaboration. Although BIM simplifies the retrieval and use of information in construction projects, BIM tools use native formats that pose challenges for data reuse and exchange. This article proposes a method for mapping BIM data into sets of concepts of a specific domains, and the use of Semantic Web tools for the exchange of data and information. Domain ontologies are a widely used tool for the formal definition of a field of knowledge, which facilitates the exchange of information in heterogeneous systems through technologies such as the Semantic Web. The proposed mapping can be used to enrich information and improve data integration in systems based on semantic tools that manage services or maintain facilities and building infrastructures. The article also presents a case study based on the management of airport facilities to illustrate the practical application of the method.
Manufacturing activities in cloud-based environments strongly rely on the online integration and description of the capability of machining resources. In the authors’ previous work, STEP-NC was applied to construct an ontology model to support the integration and reasoning of industrial information. For the maintenance and update of the model, a self-learning method is proposed to explore correlations from STEP-NC process planning documents to obtain machining knowledge to improve the comprehensiveness of the model. In this method, a Map/Reduce-based Apriori algorithm is developed via integration with the ontology model. First, a dataset is extracted from the document according to the importance analysis results of the model. Then, a mining procedure that combines the Apriori algorithm and Map/Reduce framework is developed. Finally, two representation modes are adopted to embed the mined results into the model. According to the outcomes of a preliminary experiment with standard STEP-NC documents, this method effectively enables the ontology learning mechanism from the aspects of time consumption and mined associations, which improves the suitability of the enriched ontology model to handle information integration and industrial applications.
The high complexity of assemblies and components in Computer-Aided Design (CAD) leads to a high effort in the maintenance of the models and increases the time required for adjustments. Metrics indicating the complexity of a CAD Model can help to reduce it by showing the results of changes. This paper describes a concept to calculate metrics aiming to describe the extent of complexity of components in CAD systems based on an ontology-based representation in a first step. The representation is initially generated from CAD models using an automated process. This includes both a boundary representation and the history of the feature-based design. Thus, the design strategy also contributes to measuring the complexity of the component so that the same shape can lead to different complexity metrics. Semantic rules are applied to find patterns of the design and to identify and evaluate various strategies. Different metrics are proposed to indicate the particular influence factors of complexity and a single measure for the overall complexity. Furthermore, the influencing factors can also be used to allow the designer to see how to reduce the complexity of the component or assembly.
This paper addresses the challenge of developing an ontology for manufacturing process capability. This is an important task needed to achieve the semantical integration of various manufacturing planning and execution software and hardware (equipment) systems. The research presented has been performed within a framework of the Industrial Ontology Foundry (IOF) in which the authors are active participants. Manufacturing process capability is seen as a composition or combination of capabilities and functions of resources participating in the process. Theoretical foundation for the capability composition is presented. Individual participant resource functions are established using axiomatic design principles. The function and capability of the whole manufacturing processes is derived from individual resources using axiomatic design composition of functions. The overall approach is applied on example prismatic parts, their features, and simple machining processes. For each machining process, the machine tool brings one set of functions, while the cutting tool (mill or drill) brings its own functions. When combined for the manufacturing process those functions become capabilities in the whole process. The approach is illustrated on several feature geometries (holes, slots and pockets).
Conference Paper
Full-text available
The languages and logical formalisms developed by information scientists and logicians concentrate on the theory of languages and logical theorem proving. These languages, when used by domain experts to represent their domain of discourse, most often have issues related to the level of expressiveness of the languages and need specific extensions. In this paper we analyze the levels of logical formalisms and expressivity requirements for the development of ontologies for manufacturing products. We first discuss why the representation of a product model is inherently complex and prone to inconsistencies. We then explore how these issues can be overcome through a structured knowledge representation model. We report our evaluation of OWL-DL in terms of expressivity and of the use of SWRL for representing domainspecific rules. We present a case study of product assembly to document this evaluation and further show how the OWL-DL reasoner together with the rule engine can enable reasoning of the product ontology.
Full-text available
The support of PLM throughout the product life, from the product's conceptualization to its disposal, requires reliable, complete and efficient data models. The Core Product Model (CPM), initially developed at NIST for a number of in-house research projects, has been extended so as to support the full range of PLM information. CPM gives equal status to three aspects of a product or artifact: its function, form and behavior. Thus, CPM can support purely functional reasoning about a product in the conceptual stages of design as well as the recording and modeling of its behavior in the post-design stage. CPM is a generic, abstract model with generic semantics. It is defined as a UML class diagram.. Three levels of CPM models, denoted as the conceptual, intermediate, and implementation models, are described. Extensions of CPM are briefly presented and a short illustrative example is given.
Full-text available
In this paper, we provide an overview of the changing design and manufacturing landscape in the 21 st century that has come about because of IT and the changing global conditions. Based on this overview and a review of the current state of IT for PLM support in the design and manufacturing sector, we identify the areas of need for standards. A review of areas covered by standards leads us to the development of an initial typology of standards and a potential path for bringing convergence of these standards in support of PLM. We make a case throughout the paper that given the nature of the task we need to aspire to create open standards with wide participation. We conclude by arguing that there is an important role to be played in this context by institutions such as NIST as a neutral party in the standards debates and implementations.
In this paper, we describe the language and features of our graph transformation tool, GReAT.We begin with a brief introduction and motivation, followed by an overview of the actual language, the modeling framework, and the tools that were written to support transformations. Finally, we compare GReAT to other similar tools, discuss additional functionality we are currently implementing, and describe some of our experiences with the tool thus far.
Ontology mapping is seen as a solution provider in today's landscape of ontology research. As the number of ontologies that are made publicly available and accessible on the Web increases steadily, so does the need for applications to use them. A single ontology is no longer enough to support the tasks envisaged by a distributed environment like the Semantic Web. Multiple ontologies need to be accessed from several applications. Mapping could provide a common layer from which several ontologies could be accessed and hence could exchange information in semantically sound manners. Developing such mapping has beeb the focus of a variety of works originating from diverse communities over a number of years. In this article we comprehensively review and present these works. We also provide insights on the pragmatics of ontology mapping and elaborate on a theoretical approach for defining ontology mapping.
The newly available PLib Standard (officially the ISO 13584 Standard series "Parts Library") has defined a model and an exchange format for digital libraries of technical components. The major benefits of this approach include : productivity increase (the components are not modeled several times), quality increase (the data models are guaranteed by the supplier of the library) and product data storage / exchange efficiency (in product data a component is only represented by a reference). Developed in the same ISO committee as STEP, PLib is fully inter-operable with STEP. In PLib libraries, component representations may be defined as STEP data. In STEP product data, PLib components may be represented by simple references. This presentation gives an overview of the PLib information model and outlines the document structure of ISO 13584. It discusses the use of PLib for the design and the use of on-line electronic catalogues. Then, some of the tools developed in several ESPRIT projects to generate, on the supplier site (catalogue generators), and to use , on the customer site (Library Management System-LMS), PLib conforming libraries are presented.
With more substantial funding from research organizations and industry, numerous large-scale applications, and recently developed technologies, the Semantic Web is quickly emerging as a well-recognized and important area of computer science. While Semantic Web technologies are still rapidly evolving, Foundations of Semantic Web Technologies focuses on the established foundations in this area that have become relatively stable over time. It thoroughly covers basic introductions and intuitions, technical details, and formal foundations. The book concentrates on Semantic Web technologies standardized by the World Wide Web Consortium: RDF and SPARQL enable data exchange and querying, RDFS and OWL provide expressive ontology modeling, and RIF supports rule-based modeling. The text also describes methods for specifying, querying, and reasoning with ontological information. In addition, it explores topics that are clearly beyond foundations, such as tools, applications, and engineering aspects. Written by highly respected researchers with a deep understanding of the material, this text centers on the formal specifications of the subject and supplies many pointers that are useful for employing Semantic Web technologies in practice. The book has an accompanying website with supplemental information.