ArticlePDF Available

Abstract and Figures

Semantic Web technologies are becoming more and more appealing to the community of the Industry Foundation Classes (IFC) users. The recent actions towards the development of an OWL version of the IFC schema (named ifcOWL) evidence the effort of facing the community request to specify IFC in an ontology language. This paper presents an enrichment of the EXPRESS to OWL conversion patterns with OWL class expressions that specifically capture certain constraints of the IFC standard. The presented class expressions can be used to improve the robustness of ifcOWL and support data integrity, consistency, and applicability across various scenarios of industrial application. In particular, the rules defining the relationships between non-abstract subtypes of IfcObject and corresponding subtypes of IfcTypeObject are analyzed and converted into novel class expressions. The proposed additions to the conversion pattern have been implemented into a software tool and the resulting ontology was tested against a use case to show the benefits of the new solution with respect to a basic ifcOWL. The novel conversion pattern enhances usability of the ifcOWL ontology by enabling its direct instantiation, without necessarily going through the intermediate generation of a STEP physical format that is then converted into an ontology.
Content may be subject to copyright.
Ontology-based Representation of IFC EXPRESS rules: an enhancement
of the ifcOWL ontology
Walter Terkaj, Aleksandra Sojic
Institute of Industrial Technologies and Automation (ITIA-CNR), Milan, Italy
Abstract
Semantic Web technologies are becoming more and more appealing to the community of the Industry
Foundation Classes (IFC) users. The recent actions towards the development of an OWL version of the
IFC schema (named ifcOWL) evidence the effort of facing the community request to specify IFC in an
ontology language. This paper presents an enrichment of the EXPRESS to OWL conversion patterns with
OWL class expressions that specifically capture certain constraints of the IFC standard. The presented class
expressions can be used to improve the robustness of ifcOWL and support data integrity, consistency, and
applicability across various scenarios of industrial application. In particular, the rules defining the relation-
ships between non-abstract subtypes of IfcObject and corresponding subtypes of IfcTypeObject are
analysed and converted into novel class expressions. The proposed additions to the conversion pattern have
been implemented into a software tool and the resulting ontology was tested against a use case to show
the benefits of the new solution with respect to a basic ifcOWL. The novel conversion pattern enhances
usability of the ifcOWL ontology by enabling its direct instantiation, without necessarily going through the
intermediate generation of a STEP physical format that is then converted into an ontology.
Keywords: IFC-OWL conversion, EXPRESS rules, OWL Class Expression, ifcOWL instantiation
1. Introduction
Industry Foundation Classes (IFC) [1] is the accepted standard for Building Information Modelling
(BIM). It provides schemas for data management in building and construction, but its applicability extends
across numerous other domains that are dealing with industrial data modelling, including factory design,
construction, simulation and evaluation of manufacturing processes. The Semantic Web (SW) technologies5
provide a modelling environment that can deal with heterogeneous data, supporting interoperability across
diverse knowledge domains, integration of distributed data and employment of reasoning engines to infer
new knowledge automatically [2]. The appealing features of SW motivated work on conversion of the IFC
Email address: walter.terkaj@itia.cnr.it (Walter Terkaj, Aleksandra Sojic)
Preprint submitted to Automation in Construction April 15, 2015
EXPRESS schema [3] into an OWL [4] ontology. In this paper, we take into consideration the existing
efforts in the direction of the IFC to OWL conversion. While taking an OWL version of IFC (named10
ifcOWL [5]) as a reference, we propose an enhancement of the conversion pattern in order to optimise
its applicability. In particular, the pattern deals with some of the rules defined in the IFC schema. The
conversion of these rules have been neglected so far, since the main application scenario addressed in the
literature consists in the conversion of IFC files (in the form of STEP physical file [6]) that were generated
by IFC-compliant software tools [7]. The conversion of the rules into the OWL version of IFC may enable15
the direct instantiation of the ontology without going through the generation of STEP files and afterwords
checking the consistency of IFC projects, whatever is their origin. Moreover, the enrichment of the ifcOWL
ontology allows both to safely use general purpose SW tools and to develop new ifcOWL-based software
tools while minimising inconsistencies and erroneous applications of the standard.
In this paper, we address the conversion of the EXPRESS schema [3] representing the IFC standard into20
an OWL ontology to exploit the features of SW technologies [2]. In particular, an OWL version of IFC
(named ifcOWL) can be better integrated with other ontologies to support interoperability, while making
use of data distribution capabilities; moreover, general purpose reasoning engines can be directly employed
to infer new knowledge.
This paper is organized as follows. We first outline the state of the art about the IFC to OWL conversion25
(Sect.2) and then we briefly present the adopted conversion pattern (Sect.3). Section 4 describes the pro-
posed enhancements to the conversion pattern, whereas its implementation is discussed in Sect.5. Section 6
presents an ontology-based software tool that is able to exploit the results of conversion pattern suggested
in the previous section, thus providing additional control for the assurance of the data quality. Finally, we
provide an example to demonstrate how the proposed pattern impacts on the results of both closed world30
assumption (CWA) integrity check and open world assumption (OWA) reasoning (Sect.7).
2. State of the Art
The Industry Foundation classes (IFC) standard by buildingSMART [1] is an object oriented data model
provided as an open specification for Building Information Modelling (BIM). IFC aims at supporting data
exchange and sharing among the various participants in a building construction or facility management35
projects. It consists of the data schema, represented as an EXPRESS schema specification [3], and ref-
erence data, represented as XML definitions of property and quantity definitions [1]. The IFC model is
structured into four layers: Resource layer (i.e. general purpose or low level concepts/objects), Core Layer
(where the most abstract concepts of the model are defined), Interoperability Layer defining concepts or
objects common to two or more domains, and the Domains/Application Layer [1]. Even if the standard40
2
was mainly conceived for the Architecture, Engineering and Construction (AEC) industry domains (e.g.
Building Controls, Structural elements, Structural Analysis, etc.), its data structures can be specialised for
other industrial domains, such as the manufacturing domain [8].
The emergence of SW technologies led to several initiatives aimed at converting the IFC schema into an
ontology language that can provide a semantically rich and platform independent framework to support the45
integration and interoperability of software tools and exchange of data in a knowledge based system that
are human readable and processable by machines. In particular, Beetz and colleagues [9], as well as Krima
et al. [10, 11], emphasised the EXPRESS’s lack of formal semantics, arguing that a logic-based language
such as OWL brings modelling advantages in knowledge representation, semantic data sharing, and reuse
of existing ontologies and interoperability with the SW tools.50
The first conversion map from EXPRESS to OWL was presented by Schevers and Drogemuller [12],
while taking IFC as a reference example and highlighting some of the key issues to be addressed. Beetz
et al. [9] proposed a semi-automatic method for converting EXPRESS schemas to OWL files to enhance
the applicability and re-usability of the IFC standard. Barbau and colleagues specified the rules for the
automated conversion from EXPRESS to OWL within the OntoSTEP initiative [11] and implemented the55
system as an OWL plug-in for Prot´
eg´
e [13].
Several recent works dealing with the BIM domain have shown how useful SW technologies can be
to support the related business processes [14]. Zhang et al. [15] argued that the conversion of IFC into
OWL, beside enabling the exploitation of SW technologies for building information models, facilitates the
retrieval of information from IFC models. Pauwels et al. [16] showed how Semantic Web Rule Language60
(SWRL) [17] rules can be exploited to enrich an OWL version of IFC and create a semantic rule checking
environment. The use of rules was exemplified by the case of acoustic performance regulations. Similarly,
Beach et al. [18] developed a methodology to automatically check the compliance with regulations in the
building industry. The authors suggest the development of specific regulation ontologies consisting of
SWRL rules that can be linked with a core ontology representing the addressed industrial domain.65
Lee et al. [19] proposed to model the work conditions and work items needed during a tiling process
by means of ontologies. They made use of the XML version of IFC and reasoning was exploited to infer
which are the proper work items according to the work condition.
Terkaj et al. [20] proposed a modular OWL ontology for factory modelling and data sharing between
heterogeneous software tools. The ontology, named Virtual Factory Data Model (VFDM), was based on the70
integration of an OWL version of IFC with other ontologies derived from technical standards (e.g. STEP-
NC [21]), or defining basic concepts not included in IFC (e.g. probability distributions), or specializing IFC
for the manufacturing domain. The VFDM was exploited to enable interoperability between various soft-
ware tools, including both commercial (e.g. Plant Simulation by Siemens PLM [22]) and non-commercial
3
(e.g. GIOVE Virtual Factory [23]) applications.75
Zhang et al. [24] proposed a construction safety ontology to formalize the safety management knowl-
edge, while considering both construction elements and construction processes. SWRL rules were used to
express safety regulations and support the automatic generation of job hazard analysis (JHA) reports.
All the previous cases demonstrate that a recommended and complete ontology version of IFC would
be beneficial to ease the integration of data models, support the flow of data and enable the use of ontology-80
based tools. Indeed, recently Pauwels [5] proposed a conversion pattern that re-elaborates the previous
contributions (mainly [9] and [11]) and adds new features, aiming also at producing an officially recom-
mended OWL version of IFC ontology, named ifcOWL. The main conversion criteria were:
(A) keeping the ifcOWL ontology in the OWL DL profile [4] in order to enable reasoning;
(B) enriching the ifcOWL with axioms to match the original EXPRESS schema as closely as possible;85
(C) primarily supporting the conversion of IFC STEP physical files into equivalent RDF graphs, without
necessarily guaranteeing that an RDF graph can be modelled from scratch by directly instantiating
the ifcOWL ontology.
3. IFC to OWL conversion pattern
The previous section mentioned some of the key approaches to the conversion of IFC from EXPRESS to90
OWL that are well documented in the literature (cfr. [12, 9, 11]). This section instead focuses the attention
on the most recent development in this research field that was proposed by Pauwels [5]. The key features
of the conversion pattern are outlined together with a few examples that are relevant for the analysis carried
out in the following sections, especially for the core contribution of Sect. 4. The reference IFC EXPRESS
schema is IFC4 ADD1.exp [1].95
Table 1 reports the summary of the conversion pattern by Pauwels [5] in terms of EXPRESS state-
ments paired with the corresponding OWL axioms. EXPRESS ENTITY is converted into owl:Class, i.e.,
the OWL construct that specifies classes in general, including classes of particulars. The EXPRESS tax-
onomical relationship SUPERTYPE OF/SUBTYPE OF, holding between concepts classified by ENTITY, has
its OWL equivalent in rdfs:subClassOf, which holds between owl:Class concepts.100
The ABSTRACT characterization in EXPRESS rules out direct instantiation of certain entities. This con-
straint does not have a direct counterpart in OWL. The corresponding structural pattern is obtained by
declaring that the subclasses form a partition, where the OWL subclasses of the given class cover the ex-
tension of the concept. Analogously, the ONEOF construct is obtained by declaring that the OWL subclasses
of that class are disjoint.105
4
EXPRESS OWL
Schema Ontology
Simple data type OWL class with a restriction on an owl:DatatypeProperty
Defined data type OWL class
Constructed SELECT data type OWL class with equivalence to a unionOf collection of OWL classes
Constructed ENUMERATION
data type
OWL class with equivalence to a oneOf collection of owl:NamedIndividual items
Entity data type OWL class
Attribute of entity data type Functional object property with specified domain and range; owl:AllValuesFrom re-
striction; owl:qualifiedCardinality or owl:maxQualifiedCardinality restriction
Attribute of entity data type as a
SET
Non-functional object property with specified domain and range; owl:AllValuesFrom
restriction; owl:minQualifiedCardinality and/or owl:maxQualifiedCardinality restric-
tion or owl:qualifiedCardinality restriction
INVERSE attribute object property with a specified owl:inverseOf
DERIVE attribute N/A
WHERE rule N/A
FUNCTION N/A
RULE N/A
Table 1: Summary of the adopted conversion pattern [5], where owl: stands for the namespace ’http://www.w3.org/2002/07/owl#’.
In EXPRESS the properties of the entities are modelled via attributes. By default, an attribute listed
in the class definition is mandatory for each element of that class. When this is not so, the attribute is
labelled OPTIONAL: if a class C1has optional attribute A1, then it is a matter of choice whether A1should be
instantiated by a particular value. EXPRESS attributes are converted into OWL class restrictions by means
of object properties, using a universal quantification (owl:AllValuesFrom) and, if necessary, cardinality110
constraints.
One of the novelties introduced in the proposal by Pauwels consists in the automatic conversion of
INVERSE attributes that were neglected or not thoroughly addressed in previous literature contributions.
However, it can be noted that some EXPRESS statements, in particular WHERE rules, have not been con-
verted (see Table 1) since they are considered irrelevant according to the conversion criteria mentioned115
before.
The case of entity IfcObject (defined in Fragment 1 using EXPRESS language) can be used as an
example to show how the conversion pattern can be applied. An IfcObject is “the generalization of any
semantically treated thing or process. Objects are things as they appear - i.e. occurrences. Examples of
IfcObject include physically tangible items such as wall, beam or covering, physically existing items such120
as spaces, or conceptual items such as grids or virtual boundaries” [1].
5
EN TI TY I fc Ob je ct
AB S TR A CT SU PE R TY P E OF ( O NE O F ( If cA c to r , I f cC o nt ro l , I fc G ro up , If c Pr oc e ss , If c Pr od u ct , If c Re s o ur c e ))
SUBTYPE OF (IfcObjectDefinition);
Ob j ec t Ty p e : OP T IO NA L I f cL a be l ;
INVERSE
Is D ec l ar e dB y : SE T [ 0: 1] O F I fc R el D ef i ne s By O bj e ct FOR Re la t ed O bj e ct s ;
De c la r es : S ET [ 0: ? ] OF I f cR e lD e fi n es B yO b je c t FO R R el a ti n gO b je ct ;
Is T yp e dB y : SE T [0 : 1] O F I fc R el D ef i ne s By T yp e F OR R e la t ed Ob j ec t s ;
Is D ef i ne d By : S ET [ 0: ? ] OF I f cR e lD e fi n es B yP r op e rt i es FOR Re la t ed O bj e ct s ;
WH ER E
UniquePropertySetNames : IfcUniqueDefinitionNames(IsDefinedBy);
EN D _E N TI T Y ;
Fragment 1: Definition of entity IfcObject
The conversion of IfcObject into OWL is given by the conjunction of the statements from (1) to (11),
whereas statements from (12) to (22) define the object properties that are used in the restrictions. These
ontology fragments are defined according to the Manchester Syntax [25] that is mapped to the traditional125
DL Syntax in Table 2.
In addition, for each subclass of IfcObject there will be an axiom specifying that such class is disjoint
with the other subclasses. The OWL statements capture the EXPRESS abstract construct because every
instance of IfcObject must be an instance of one and only one of its subclasses, since statement (2)
declares IfcObject as a subclass of the union of its disjoint subclasses. For example, it cannot be the130
case that a particular object (e.g. ObjectX) instantiates both a subclass of IfcGroup and a subclass of
IfcProcess.
Some of the object properties are named differently from the corresponding EXPRESS attribute (e.g.
ObjectType) to guarantee their uniqueness in ifcOWL.
Class: IfcObject (1)135
SubClassOf:
IfcActor or IfcControl or IfcGroup or IfcProcess or IfcProduct or IfcResource, (2)
IfcObjectDefinition, (3)
ObjectType of IfcObject only IfcLabel, (4)
ObjectType of IfcObject max 1 IfcLabel, (5)140
IsDeclaredBy only IfcRelDefinesByObject, (6)
IsDeclaredBy max 1 IfcRelDefinesByObject, (7)
Declares of IfcObject only IfcRelDefinesByObject, (8)
IsTypedBy only IfcRelDefinesByType, (9)
IsTypedBy max 1 IfcRelDefinesByType, (10)145
DisjointWith: IfcTypeObject, IfcContext (11)
6
OWL Constructor DL Syntax Manchester OWL Syntax
intersectionOf C D C and D
unionOf C D C or D
complementOf ¬Cnot C
oneOf {a}{b}... {a b ...}
someValuesFrom R C R some C
allValuesFrom R C R only C
minCardinality N R R min N
maxCardinality N R R max N
cardinality =N R R exactly N
hasValue R{a}Rvalue a
Table 2: Mapping between the DL Syntax and Manchester OWL Syntax [25]
ObjectProperty: ObjectType of IfcObject (12)
Characteristics: Functional (13)
ObjectProperty: IsDeclaredBy (14)
Characteristics: Functional (15)150
InverseOf: RelatingObject of IfcRelDefinesByObject (16)
ObjectProperty: Declares of IfcObject (17)
Characteristics: Functional (18)
InverseOf: RelatingObject of IfcRelDefinesByObject (19)
ObjectProperty: IsTypedBy (20)155
Characteristics: Functional (21)
InverseOf: RelatedObjects of IfcRelDefinesByType (22)
The OWL statements (9) and (10) involve the class
IfcRelDefinesByType
standing for the IFC objecti-
fied relationship entity that is meant to “define the relationship between an object type (see
IfcTypeObject
)
and object occurrences (see
IfcObject
). The
IfcRelDefinesByType
is a 1-to-N relationship as it al-160
lows for the assignment of one type information to a single or to many objects. Those objects then share
the same object type, and the property sets and properties assigned to the object type” [1]. The entity
IfcTypeObject
in turn “defines the specific information about a type, being common to all occurrences
of this type. It refers to the specific level of the well recognized generic - specific - occurrance modeling
paradigm. The
IfcTypeObject
gets assigned to the individual object instances (the occurrences) via the165
IfcRelDefinesByType
relationship. The object type is represented by a set of property set definitions” [1].
Practically, objectified relationships are used in IFC to separate the properties specific to relationships from
the object attributes. This allows the development of a separate subtype tree for the relationship seman-
7
tics [1].
According to the adopted conversion pattern, the core definition of classes IfcTypeObject and170
IfcRelDefinesByType
is reported in statements (23)-(28) and statements (29)-(34), respectively. Finally,
statements (35)-(44) define the object properties that are needed to formulate the restrictions. The complete
definitions of classes and properties can be found in [5].
Class: IfcTypeObject (23)175
SubClassOf:
IfcObjectDefinition (24)
HasPropertySets only IfcPropertySetDefinition, (25)
Types only IfcRelDefinesByType, (26)
Types max 1 IfcRelDefinesByType (27)180
DisjointWith: IfcObject, IfcContext (28)
Class:IfcRelDefinesByType (29)
SubClassOf:
IfcRelDefines, (30)185
RelatingType only IfcTypeObject, (31)
RelatingType exactly 1 IfcTypeObject, (32)
RelatedObjects of IfcRelDefinesByType only IfcObject, (33)
RelatedObjects of IfcRelDefinesByType min 1 IfcObject (34)
190
ObjectProperty: HasPropertySets (35)
InverseOf: DefinesType (36)
ObjectProperty: Types (37)
Characteristics: Functional (38)
InverseOf: RelatingType (39)195
ObjectProperty: RelatingType (40)
Characteristics: Functional (41)
InverseOf: Types (42)
ObjectProperty: RelatedObjects of IfcRelDefinesByType (43)
InverseOf: IsTypedBy (44)200
The class IfcPropertySetDefinition used in statement (25) plays a key role in IFC together with
IfcObject and IfcTypeObject. Indeed it is “a generalization of all individual property sets that can
be assigned to an object or type object. The property set definition can be specified either as dynamically
8
extendable property sets or as statically defined property sets. Property set definitions define information205
that is shared among multiple instances of objects, either object types (via a direct relationship) or object
occurrences (via the objectified relationship IfcRelDefinesByProperties)” [1].
Again according to the adopted conversion pattern, the core definition of classes
IfcPropertySetDefinition
and
IfcRelDefinesByProperties
is reported in statements (45)-(49) and
statements (50)-(55), respectively, whereas statements (56)-(63) define the object properties that are needed210
to formulate their restrictions.
Class: IfcPropertySetDefinition (45)
SubClassOf:
IfcPreDefinedPropertySet or IfcPropertySet or IfcQuantitySet, (46)215
IfcPropertyDefinition, (47)
DefinesType only IfcTypeObject, (48)
DefinesOccurrence only IfcRelDefinesByProperties, (49)
Class:IfcRelDefinesByProperties (50)220
SubClassOf:
IfcRelDefines, (51)
RelatingPropertyDefinition only IfcPropertySetDefinitionSelect, (52)
RelatingPropertyDefinition exactly 1 IfcPropertySetDefinitionSelect, (53)
RelatedObjects of IfcRelDefinesByProperties only IfcObjectDefinition, (54)225
RelatedObjects of IfcRelDefinesByProperties min 1 IfcObjectDefinition (55)
ObjectProperty: DefinesType (56)
InverseOf: HasPropertySets (57)
ObjectProperty: DefinesOccurrence (58)230
InverseOf: RelatingPropertyDefinition (59)
ObjectProperty: RelatingPropertyDefinition (60)
Characteristics: Functional (61)
InverseOf: DefinesOccurrence (62)
ObjectProperty: RelatedObjects of IfcRelDefinesByProperties (63)235
Finally, Fig.1 shows the OWL universal quantification restrictions linking IfcObjectDefinition,
IfcObject,IfcTypeObject,
IfcPropertySetDefinition
,
IfcRelDefinesByType
and
IfcRelDefinesByProperties
, which are depicted by dashed lines.
IfcPropertySetDefinitionSelect
,
used in statements (52) and (53), is defined as equivalent to the union of
IfcPropertySetDefinition
and240
9
IfcPropertySetDefinitionSet
; for the sake of simplicity,
IfcPropertySetDefinitionSelect
is not
included in Fig.1 and is instead replaced by
IfcPropertySetDefinition
.
IfcTypeObject IfcObject
IsTypedBy only
IfcRelDefinesByType
RelatingType only RelatedObjects_of_IfcRelDefinesByType
only
Types only
IfcPropertySetDefinition
IfcRelDefinesByProperties
DefinesType only
RelatingPropertyDefinition
only
IfcObjectDefinition
DefinesOccurrence
only
RelatedObjects_of_IfcRelDefinesByProperties
only
HasPropertySets
only
SubClassOf SubClassOf
Figure 1: OWL universal quantification restrictions linking IfcObjectDefinition,IfcObject,IfcTypeObject,
IfcPropertySetDefinition,IfcRelDefinesByType and IfcRelDefinesByProperties.
4. Conversion of IFC rules into OWL Class Expressions
The conversion pattern presented in the previous section is incomplete because there are still relevant
EXPRESS definitions that are not taken in due consideration, as reported in Table 1. In particular, the245
WHERE keyword can be used in the EXPRESS schema to specify rules and complex constraints; Zhao and
Liu [26, 27] proposed a mapping between WHERE rules and SWRL language, as was already suggested by
Beetz et al. [28].
In this section we propose an enhancement of the ifcOWL ontology by partially revising the conversion
criteria defined by Pauwels [5]. The criteria Aand B(i.e. keeping ifcOWL in OWL DL profile and enriching250
the ifcOWL with axioms to match the original EXPRESS schema as closely as possible) are preserved, but
criterion C(i.e. primarily supporting the conversion of IFC STEP physical files into equivalent RDF files)
is excluded and replaced by the following one:
(D) Analysis of rules in the IFC schema and ensuing conversion into the ifcOWL to support the direct
instantiation of the ontology and guarantee its consistency, thus recalling the motivations presented255
in Sect. 1.
10
If key rules are not properly defined in the ifcOWL ontology, then it is necessary to introduce rule-like
constraints at a later time, e.g. during the development of an ontology-based software application. However,
this choice leads to at least two important drawbacks:
The risk of introducing errors and misinterpretations by the software developers.260
The development of rigid (hard-coded) applications that are not able to properly deal with changes in
domain ontologies, thus affecting the flexibility of the system and, in turn, the interoperability.
Herein, it is proposed to overcome these problems by enriching the ifcOWL ontology with OWL class
expressions1representing rules of the IFC schema. Even if the use of class expressions is a standard practice
in ontology design, we are going to discuss their significance in the context of IFC conversion pattern, in265
particular with reference to typing relationships (Sect. 4.1) and pre-defined property sets (Sect. 4.2). We
propose the use of OWL class expressions and not SWRL in order to assure compliance with conversion
criterion A. Indeed, SWRL is not part of OWL and this language has not yet been approved after the
submission to the World Wide Web Consortium (W3C).
4.1. Typing relationships270
The objectified relationship entity IfcRelDefinesByType plays a key role in the IFC schema because
it allows to reduce unnecessary data redundancy inside a model, as explained in the definition quoted in
Sect.3. The correct use of this typing relationship is guaranteed by WHERE rules in the IFC schema that
constrain which instances can be linked via IfcRelDefinesByType. For example, taking in consideration
IfcWindow and IfcWindowType that are specializations of IfcObject and IfcTypeObject, respectively,275
the IFC definition of IfcWindow in Fragment 2 shows the WHERE rule named CorrectStyleAssigned;
such rule states that the instances of IfcWindow can be related only with an instance of IfcWindowType.
1Note that Manchester syntax supports the nesting of class constructors and complex class expressions that can be disambiguated
by bracketing, see e.g.[25]
11
EN TI TY I fc Wi nd ow
SU P ER T YP E O F ( ON EO F ( I f cW i nd o w St a nd a r dC a se ) )
SU B TY PE OF ( If c Bu i ld i ng El e me n t );
Ov e ra l lH e ig ht : O P TI ON A L I fc P os i ti v eL e ng t hM e as ur e ;
Ov e ra l lW id t h : OP T IO NA L I f cP o si t iv e Le n gt h Me as u re ;
Pr e de f in e dT y pe : O PT I ON A L If c Wi n do w Ty p eE n um ;
Pa r ti t io n in g Ty pe : O P TI ON A L I fc W in d ow T yp eP a rt i ti o ni n gE n um ;
Us e r De f in e dP a rt i t io n in g Ty p e : OP T IO N AL If cL a be l ;
WH ER E
Co r r ec t St y le A s si g ne d : ( SI Z EO F ( I sT y pe d By ) = 0) O R
(’ I F C4 . I F CW I ND O WT Y PE IN T Y PE O F ( SE LF \ I f c Ob j ec t . I s Ty p ed B y [ 1] . R e la t in g T yp e ) );
EN D _E N TI T Y ;
Fragment 2: Definition of entity IfcWindow
Based only on statements (9), (10), (26), (27), and (31)-(34), the ifcOWL ontology allows to cre-
ate links between an instance of a non-abstract IfcObject subclass and an instance of any non-abstract280
IfcTypeObject subclass. Thus the conversion criterion Dis not met. Without restricting relations, it is
possible to (erroneously) relate, for example, an instance of IfcDoor with an instance of IfcWindowType,
implying that a door is modelled after a type of window. Therefore, it is relevant to convert the WHERE rules
defining the correct typing relationship into the OWL version of IFC, otherwise this lack would jeopardize
the consistency in the output of an ontology-based software application. As anticipated, it is possible to285
meet this goal by means of OWL class expressions.
Statement (65) shows how the WHERE rule CorrectStyleAssigned of IfcWindow (see Fragment 2)
can be converted into a class expression that consists in a more articulated restriction compared to the
restrictions used to convert the entity attributes according to the basic conversion pattern by Pauwels [5].
Class: IfcWindow (64)290
SubClassOf: IsTypedBy only (RelatingType only IfcWindowType) (65)
Moreover, we suggest to further constrain the link between non-abstract subclasses of
IfcTypeObject and corresponding subclasses of IfcObject by further characterizing also the
IfcTypeObject subclass, even if this type of rule is not defined in the IFC schema. Indeed, with ref-295
erence to the IfcWindowType example, Fragment 3 shows that no WHERE rule states that it can type only
instances of IfcWindow.
12
EN TI TY I fc Wi nd ow Ty pe
SU B TY PE O F ( If c Bu i ld i ng E le m en t Ty p e );
Pr ed ef in ed Ty pe : I fc WindowT yp eE nu m;
Pa r ti t io n in g Ty pe : I f cW i nd o wT y pe P ar t it i on i ng E nu m ;
Pa r a me t er T ak e sP r ec e de n ce : O P TI O NA L I fc B oo l ea n ;
Us e r De f in e dP a rt i t io n in g Ty p e : OP T IO N AL If cL a be l ;
WH ER E
Co r re c t Pr e de f in e dT y pe : ( P re d ef i ne d Ty p e <> I f cW i nd o wT y pe E nu m . U SE R DE F IN E D ) O R (( P r ed e fi n ed T yp e =
If c Wi n do w Ty p eE n um . U S ER DE F IN E D ) A N D EX IS T S (S E LF \ I fc E le m en t Ty pe . E l em e nt T yp e )) ;
EN D _E N TI T Y ;
Fragment 3: Definition of entity IfcWindowType
Statement (67) can be added to guarantee that an instance of IfcWindowType can be related only with
an instance of IfcWindow via a chain of properties including Types and300
RelatedObjects of IfcRelDefinesByType
. Without this additional restriction it would be possible to
relate an instance of IfcWindowType with an instance of any non-abstract subclass of IfcObject that is
not characterized by a restriction similar to (65); this is the case of class IfcBuilding that is not paired
with a corresponding subclass of IfcTypeObject.
Class: IfcWindowType (66)305
SubClassOf: Types only (RelatedObjects of IfcRelDefinesByType only IfcWindow) (67)
Furthermore, it would be beneficial to extend also the EXPRESS specification of IFC, that could be
reviewed by adding a specific WHERE rule to all non-abstract sub-entities of IfcTypeObject. Statement
(68) shows an example of this new WHERE rule named CorrectOccurrenceAssigned for the case of
IfcWindowType.310
(SIZEOF(Types) = 0) OR (’IFC4.IFCWINDOW’ IN TYPEOF(SELF \IfcObject.Types[1].RelatedObjects))
(68)
It must be stressed that the definition of class expressions like (65) and (67) was possible thanks to the
conversion of INVERSE attributes like Types and IsTypedBy in the ifcOWL by Pauwels [5].
Figure 2 shows a specialization of Fig.1 and provides a graphical representation of the restrictions (65)
and (67) in bold dashed lines. An ontology-based application can also exploit these restrictions to correctly315
instantiate the class IfcWindowType and the class IfcWindow as well as to relate them via an instance of
the class IfcRelDefinesByType.
Overall, the OWL capability to capture class expressions, as sketched in the examples above, represents
an advantage over the IFC schema, since it is not needed to split the definitions into separate attributes and
rules. More importantly, by rephrasing the system in a logical language, one can make explicit the pattern320
of reasoning over classes that impacts the inferences about particulars. The following section examines
13
IfcProduct
IfcTypeProduct
IfcElement
IfcBuildingElement
IfcElementType
IfcBuildingElementType
IfcWindow
IfcWindowType
IfcTypeObject IfcObject
IsTypedBy only
IfcRelDefinesByType
RelatingType only RelatedObjects_of_IfcRelDefinesByType
only
Types only
Types only (RelatedObjects_of_IfcRelDefinesByType only IfcWindow)
IsTypedBy only (RelatingType only IfcWindowType)
SubClassOf
SubClassOf
SubClassOf
SubClassOf
SubClassOf
SubClassOf
SubClassOf
SubClassOf
Figure 2: OWL restrictions linking IfcWindowType and IfcWindow.
the impact of class expressions to the representation and reasoning that involves instances, as Sect.7 will
discuss.
4.2. Pre-defined property sets
As already mentioned in Sect.3, the IFC schema allows to attach property sets defined as instances of325
IfcPropertySetDefinition
to instances of
IfcTypeObject
and
IfcObject
.
IfcPreDefinedPropertySet
and IfcPropertySet are subclasses of IfcPropertySetDefinition that can be used to represent stat-
ically defined property sets (i.e. pre-defined property sets) and dynamically extendible property sets, respec-
tively. The IFC schema includes only a few subclasses of IfcPreDefinedPropertySet (e.g.
IfcWindowPanelProperties can be used to characterize a window), whereas most of the property sets330
included in the IFC specification are not defined in the IFC EXPRESS schema, but are attached as XML files
(e.g. Pset WindowCommon.xml for common properties of a window) that can be used to lead the instanti-
ation of IfcPropertySet. Herein only IfcPreDefinedPropertySet and its subclasses are considered
because the attention is focused on the conversion from EXPRESS to OWL, but future developments could
address also the conversion of the XML property sets to OWL.335
The IFC schema defines the correct use of a pre-defined property set by means of WHERE rules that
constrain which specialization of IfcObject and IfcTypeObject can be linked to the property set. For
example, the IFC schema definition of IfcWindowPanelProperties in Fragment 4 shows the WHERE rule
14
named ApplicableToType. This rule states that an instance of IfcWindowPanelProperties must be
related with at least one instance of IfcWindowType or IfcWindowStyle via the attribute DefinesType.340
The rule can be converted into the OWL class expressions shown in statements (70) and (71).
ENTITY IfcWindowPanelProperties
SUBTYPE OF (IfcPreDefinedPropertySet);
Op e ra t io n Ty pe : I f cW i nd o wP a ne l Op e ra t io n En u m ;
Pa n el P os i ti on : I f cW i nd o wP a ne l Po s it i on E nu m ;
Fr a me D ep th : O P TI ON A L I fc P os it i ve L en g th M ea s ur e ;
Fr a me T hi c kn es s : O PT I ON AL If c Po si t iv e Le n gt h Me a su r e ;
Sh a pe A sp e ct S ty l e : OP T IO NA L I f cS h ap e As pe c t ;
WH ER E
Ap p l ic a b le T oT y p e : ( E X IS T S ( SE L F \ If c P ro p e rt y S et D e fi n i ti o n . D ef i ne s T yp e [ 1 ]) ) A ND
( ( ’ I FC 4 . I FC W IN D OW T YP E I N T YP E OF ( S EL F \ I f cP r o pe r t yS e t De f in i t io n . D e f in e sT y pe [ 1 ]) )
OR ( ’ IF C 4 . IF C WI N DO W ST Y LE IN T Y PE O F ( SE L F \ If c P ro p e rt y Se t D ef i n it i o n . D ef i ne s Ty p e [ 1 ]) ) );
EN D _E N TI T Y ;
Fragment 4: Definition of entity IfcWindowPanelProperties
Class: IfcWindowPanelProperties (69)345
SubClassOf:
DefinesType only (IfcWindowStyle or IfcWindowType), (70)
DefinesType min 1 (IfcWindowStyle or IfcWindowType), (71)
Moreover, even if not defined in the IFC schema, also the class expression (72) could be added to guar-
antee that an instance of IfcWindowPanelProperties can be related only with an instance of IfcWindow350
(and no other subclass of IfcObject) via a chain of properties including DefinesOccurrence and
RelatedObjects of IfcRelDefinesByProperties
.
SubClassOf: DefinesOccurrence only (RelatedObjects of IfcRelDefinesByProperties only IfcWindow)
(72)
Further specifications of class expressions do not include superclasses of
IfcWindowType and IfcWindow because of maintainability concerns. Indeed, other class expressions355
would need to be updated whenever a new property set for IfcWindowType and/or IfcWindow is created
in a domain ontology that extends ifcOWL, thus creating a conflict between the desired extendibility and
stability of a recommended ifcOWL.
360
15
5. Implementation of the conversion patterns
The conversion patterns presented in the previous section have been implemented into a C++ pro-
gram that makes use of programming libraries built on the Redland RDF libraries [29]. This program
implements a set of general purpose routines for the automatic generation of OWL class expressions that
are similar in structure to statements (65), (67), (70)-(72) defined for IfcWindow,IfcWindowType and365
IfcWindowPanelProperties.
The input data needed to run the C++ program consists in a list of paired classes being non-abstract
subclasses of IfcObject,IfcTypeObject, or IfcPreDefinedPropertySet. Having adopted a notation
where OccX,TypeY, and PsetZ stand for a generic non-abstract subclass of IfcObject,IfcTypeObject,
and IfcPreDefinedPropertySet, respectively, the input list can be obtained by parsing the WHERE rules370
in the IFC EXPRESS schema and applying the following rules:
a pair OccX -TypeY is added to the list if a WHERE rule containing the expression (73) is found in the
definition of OccX;
a pair PsetZ -TypeY is added to the list if a WHERE rule containing the expression (74) is found in
the definition of PsetZ;375
a pair PsetZ -OccX is added to the list if a WHERE rule containing the expression (75) is found in the
definition of PsetZ.
(TypeY IN TYPEOF(SELF\IfcObject.IsTypedBy[1].RelatingType)) (73)
(TypeY IN TYPEOF(SELF\IfcPropertySetDefinition.DefinesType[1])) (74)
(OccX IN TYPEOF(SELF\IfcPropertySetDefinition.DefinesOccurrence[1].RelatedObjects)) (75)380
Alternatively, the user can directly provide an input list, if the class expressions will be used to enrich a
domain ontology that extends ifcOWL. The routines of the program provide the following functionalities:
for each pair OccX -TypeY, the statements (76) and (77) are added to the definition of class OccX and
TypeY, respectively.
for each pair PsetZ -TypeY, the statement (78) is added to the definition of class TypeY.385
for each pair PsetZ -OccX, the statement (79) is added to the definition of class OccX.
SubClassOf: IsTypedBy only (RelatingType only TypeY) (76)
SubClassOf: Types only (RelatedObjects of IfcRelDefinesByType only OccX) (77)
SubClassOf: DefinesType only TypeY (78)
SubClassOf:
DefinesOccurrence only (RelatedObjects of IfcRelDefinesByProperties only OccX)
(79)390
16
The program allows to generate and store the additional class expressions in an ontology module that
is separated from the ontology containing the basic definitions of the classes. This is particularly useful if
the program has to enrich the ifcOWL ontology, because in this case the additional class expressions can
be stored in a new ontology module. This module, named ifcOWL rules, imports ifcOWL and exploits the395
advantages of data distribution and linked-data paradigm enabled by the SW approach. When an Abox
ontology must be created, the user decides to directly import ifcOWL rules or ifcOWL ontology according
to his/her needs.
6. Ontology-based Software Tool exploiting additional OWL class expressions
This section presents OntoGUI, an ontology-based software tool that can be employed in the manage-400
ment and instantiation of Abox ontology modules. This tool mainly aims at supporting:
The fast evaluation of ontology Tbox by concurrently instantiating a corresponding Abox, following
a Test-driven development approach.
The generation of RDF data sets to be used as input for other ontology-based applications, without
needing to develop complex customized graphical user interfaces or data converters.405
OntoGUI was developed in the C++ language making use of wxWidgets Cross-Platform GUI Library
and another programming library named VfConnectorLib, based on the Redland RDF libraries [29]. The
VfConnectorLib library includes the following key features:
A mapping between class definitions in the ifcOWL ontology and C++ classes and methods.
Support for different solutions of data repository that can be implemented as file-based systems,410
relational databases or native triple stores [30].
The user interface of OntoGUI consists of a control panel for the creation and loading of ontologies from
a file-based repository or other more performing RDF stores. The control panel provides also access to a
set of functional modules, including Individuals Manager that is a general purpose tool for the exploration,
generation and characterization of OWL individuals. The user interface of Individuals Manager (Fig.3)415
is dynamically reconfigured every time a different OWL class is selected since the tool is able to extract
information related to the following axioms defined in the Tbox ontology:
Equivalent classes, both defined as single classes or union of classes.
Subclasses, both defined as single classes or union of classes.
Restrictions of any degree if they involve universal quantifier (i.e. owl:allValuesFrom), existential420
quantifier (i.e. owl:someValuesFrom), or cardinality constraints (i.e.
owl:qualifiedCardinality
,
owl:maxQualifiedCardinality
,
owl:minQualifiedCardinality
).
17
Figure 3: A view of Individuals Manager tool in OntoGUI
The characterisation of the classes with their restrictions is exploited by the Individuals Manager tool
both for exploring and generating relations between individuals and also for checking the consistency of
the individuals. After loading an ontology, Individuals Manager allows to select any OWL class defined in425
the corresponding Tbox and with respect to this class the following operations can be performed:
Generation of a new individual belonging to the selected class.
Listing of the individuals belonging to the selected class (and its subclasses if this option is flagged)
and selection of one of them.
Navigation through all the possible relations involving the selected individual according to the re-430
strictions defined in the Tbox for the class(es) it belongs to. For each restriction it is possible to
visualise the target individuals or literals that can be found at the end of the property chain defined
by the restriction itself. The target individuals can be in turn explored by double clinking.
Creation of new relations between the selected individual and already existing individuals or individ-
uals/literals generated on demand.435
Integrity check of the selected individual by analysing one by one all the restrictions associated with
18
the classes the individual belongs to and checking if the restrictions are violated when interpreted as
Integrity Constraints according to the Closed World Assumption (see Sect. 7.3).
In particular, after querying which are the target individuals or literals at the end of the property chain
specified by the analysed restriction, the integrity check is able to identify the following violations:440
At least one target does not belong to the class/datatype specified by a restriction using a universal
quantifier.
There is no target belonging to the class/datatype specified by a restriction using an existential quan-
tifier.
The number of targets belonging to the class/datatype specified by a restriction using a qualified445
cardinality does not respect the cardinality constraint.
A functional property is used to link a specific individual with more than one individual/literal.
The basic functionalities of Individuals Manager can be provided for any ontology Tbox without re-
quiring specific adaptations. However, Individuals Manager can also be enhanced by introducing cus-
tomizations depending on a specific Tbox. In particular, taking into consideration the ifcOWL ontology,450
the following functionalities have been added:
Customized window for the quick definition of an object placement.
Automatic replication of the aggregation structure defined for an individual of type object class if
this individual is used to generate an instance of the corresponding occurrence object class that is
identified thanks to a class expression like (77).455
Specific interface for the management of pre-defined property sets. If a non-abstract subclass of
IfcObject (e.g. OccX) or IfcTypeObject (e.g. TypeY) is selected, then the non-abstract subclasses
of
IfcPreDefinedPropertySet
are explored searching for class expressions like (78) and (79). If a
match is found in a subclass of
IfcPreDefinedPropertySet
(e.g. PsetZ), then this class is added to
the list of selectable pre-defined property sets.460
Visualization of inherited property sets. If an instance of a non-abstract subclass of IfcObject is
typed by an instance of the corresponding type object class according to a class expression like (76),
then the property sets of the typing instance are inherited. The inheritance is disabled if the property
set is overridden by the object occurrence instance making use of IfcRelDefinesByProperties
(see Fig.1).465
Visualization of the proper unit of measurement when numeric values are explored according to
definitions in the IFC project or library.
19
7. Benefits of additional OWL class expressions under CWA and OWA
7.1. Test case
The test case consists of an excerpt taken from an IFC model available on an open access reposi-470
tory [31] and it involves the instantiation of IFC entities IfcWindowType,IfcWindowPanelProperties,
IfcWindowLiningProperties, and IfcWindow, thus recalling the examples presented in Sect.4. Table 3
reports the characteristics of the IfcWindowType instance named W1 Casement; two property sets are at-
tached to the definition of the window type, namely instances of
IfcWindowPanelProperties
and
IfcWindowLiningProperties
.475
IFC Entity Attribute Value
IfcWindowType
Name W1 Casement
Construction Type NOTDEFINED
Operation Type SINGLE PANEL
Parameter Takes Precedence 0
IfcWindowLiningProperties
Lining Depth 50
Lining Thickness 50
Transom Thickness 0
Mullion Thickness 0
First Transom Offset 0
Second Transom Offset 0
First Mullion Offset 0
Second Mullion Offset 0
IfcWindowPanelProperties
Operation Type NOTDEFINED
Panel Position MIDDLE
Frame Depth 50
Frame Thickness 50
Table 3: Definition of W1 Casement as an instance of IfcWindowType [31]
The original IFC model required a limited re-factoring since it was based on a previous version of
IFC, namely IFC2x3. For example, IfcWindowType is used in place of IfcWindowStyle because it is
deprecated in IFC4 ADD1.
The excerpt of the IFC model was converted into an ontology module, named WindowTest, that in-
stantiates a fragment of the ifcOWL ontology. The instantiation can be carried out using any OWL editor480
(e.g. Prot´
eg´
e [13], OntoGUI, etc.) or an automatic converter of IFC files into RDF graphs (e.g. [32]).
Furthermore, individuals W01 and D01 were generated by instantiating classes IfcWindow and IfcDoor,
respectively. Finally, a typing relationship with individual W1 Casement of class IfcWindowType was
added to both W01 and D01. The typing relation of D01 is a modelling error that was introduced on purpose
20
to check the relevance of the additional class expressions in the following subsections. The graphical repre-485
sentation of the key individuals defined in the ontology module WindowTest is shown in Fig.4, where the
individuals are represented by boxes with grey background.
IfcDoor
IfcWindowType
DefinesType
IfcRelDefinesByType
RelatedObjects_of_IfcRelDefinesByType
Types
IfcWindow
rdf:type
W1_Casement W01
D01
rdf:type
rdf:type
id61
rdf:type
RelatedObjects_of_IfcRelDefinesByType
IfcWindowPanelPropertiesIfcWindowLiningProperties
w1c_lining_prop w1c_panel_prop
rdf:type
rdf:type
DefinesType
Figure 4: Graphical representation of the key individuals within the ontology module WindowTest, where rdf: stands for the namespace
’http://www.w3.org/1999/02/22-rdf-syntax-ns#’.
It is possible to design two configurations of the test case (WinTest1 and WinTest2), even using the
same ontology module WindowTest, as shown also in Fig.5:
WinTest1. The ontology WindowTest imports only ifcOWL.490
WinTest2. The ontology WindowTest imports ifcOWL and also ifcOWL rules that contains the definition
of additional class expressions like (76)-(79).
The test case configurations2will be analysed in two possible scenarios; the former is defined by the
Open World Assumption (OWA, see Sect.7.2), whereas the latter considers the context of the Closed World
Assumption (CWA, see Sect.7.3). CWA and OWA are two distinct approaches to knowledge representa-495
tion [33].
2WinTest1 and WinTest2 are available at https://ontohub.org/repositories/test-ifc, under tab ‘File Browser’
21
ifcOWL_rules
ifcOWL
imports
WindowTest
imports
WindowTest
ifcOWL
imports
WinTest1 WinTest2
Figure 5: Graphical representation of the ontology modules in test case configurations WinTest1 and WinTest2.
7.2. Reasoning under OWA
The Open World Assumption includes the concept of incomplete information. For instance, if a fact
(or an atomic sentence) is not present in the database it is not false by default, but rather it is considered
under the assumption that it is unknown if the sentence is true or false. An advantage of using OWA is that500
it allows expansion of knowledge in the ABox through the reasoning and inference over the existing facts
in the ABox and the axioms defined in the TBox. SW and OWL support the implementation of OWA, that
can drive to the discovery of new facts that have not been explicitly declared.
Test case configurations WinTest1 and WinTest2 can be considered in the context of OWA, which
leaves open the possibility that some facts are unknown. In this case WinTest1 passes the parsing test per-505
formed via reasoners that are available in Prot´
eg´
e (FaCT++, Pellet, HermiT), without capturing any incon-
sistency. Unlike WinTest1, the class expressions available in WinTest2 function as the closure axioms, ex-
plicitly restricting the intended meaning of the typing relationship between the class-pairs IfcWindowType
and IfcWindow, and IfcDoorType and IfcDoor. Thus, an inappropriate assignment of the typing rela-
tionship leads to inconsistency of WinTest2.510
One of the possible explanations of the inconsistency is given by considering together statements (67),
(80), (81), (82), (83), and (84).
D01 Type IfcDoor (80)
W1 Casement Types id61 (81)515
id61 RelatedObjects of IfcRelDefinesByType D01 (82)
W1 Casement Type IfcWindowType (83)
IfcDoor DisjointWith IfcWindow (84)
22
The individual D01 of class IfcDoor (80) is involved in a typing relationship (81-82) with individ-520
ual W1 Casement of class IfcWindowType (83). According to statement (67), an individual of class
IfcWindowType can be in a typing relationship only with individuals of class IfcWindow, therefore it can
be inferred that individual D01 belongs to class IfcWindow as well. However, IfcWindow and IfcDoor are
disjoint classes (84) and their intersection is an empty set, thus leading to inconsistency because individual
D01 cannot be a member of both classes.525
The presence of additional class expressions in WinTest2 provides a relevant advantage over WinTest1
because it enables the detection of inconsistencies caused by modelling errors. This is particularly useful
during reasoning, because it reduces the risk of generating and using the fact inferred from a poorly built
ontology. For examples, the works by Pauwels et al. [16], Beach et al. [18], and Lee et al. [19] mentioned
in Sect.2 could benefit from the inclusion of the proposed class expressions that can increase the quality530
and confidence of inferences obtained via reasoning.
7.3. Integrity Constraint Validation under CWA
The Closed World Assumption states that unless an atomic sentence is known to be true, it can be
assumed to be false (see [33], p. 210). This assumption is frequently used in the database practice as it
allows to act as if a Knowledge Base (KB) represents complete knowledge. In addition, the CWA provides535
a useful approach that simplifies the representational scope by capturing only a small fraction of the large
number of sentences that can be declared in a KB, i.e. the fraction of the atomic sentences that are true by
default. It also assumes that any unmentioned atomic sentence is false. Moreover, the typical KB that we
consider employs the CWA with domain closure, including the additional assumption that no object exists
apart from the named constants (see [33], p. 214).540
The test case configurations WinTest1 and WinTest2 can be re-evaluated in the context of CWA under
the domain closure where everything that exists must be explicitly declared and only the declared sentences
are considered to be true. The fact that instance W1 Casement is a member of the class IfcWindowType,
and the fact that D01 is a member of the class IfcDoor are stated to be true. If an integrity check based
on CWA3is run over WinTest1, then no violation is detected and its interpretation under CWA is satisfi-545
able. On the other hand, certain statements about the typing relationships are recognised as impermissible,
i.e. false, within WinTest2 (see Fig.6). The typing relation between W1 Casement and D01 is false in
WinTest2 because an individual of class IfcWindowType is allowed to have a typing relationship only
3The integrity check under CWA can be run with different tools, e.g. Pellet Integrity Constraint Validator (http://clarkparsia.
com/pellet/icv/) and OntoGUI (see Sect. 6).
23
with individuals of class IfcWindow, whereas D01 belongs to class IfcDoor, thus leading to a violation of
integrity check under CWA.550
Figure 6: Explanation of integrity constraint violation for WinTest2 under CWA as generated by OntoGUI tool (see Sect. 6).
Also in the case of CWA the presence of additional class expressions in WinTest2 is beneficial because
it provides tighter constraints to be used to detect unintended statements and to lead the generation of new
instances and relationships.
8. Concluding Remarks
Motivated by the relevance of the IFC standard and the growing interest towards SW technologies, we555
provided an enhancement of the state-of-the-art IFC to OWL conversion patterns by adding class expres-
sions that explicate the links between IFC object occurrence, object type and pre-defined property sets.
The analysis of a test case under CWA and OWA scenarios has demonstrated that the additional class
expressions allow the detection of impermissible relationships between individuals, thus showing how dif-
ferent conversion strategies can lead to more accurate (and even more reliable) ontological representations560
of the IFC standard. These strategies rely on the structural constructs of the ontological language and are
thus suitable to verify the logical consistency and coherence of the captured information.
The relevance of the new class expressions has been discussed also in the scope of software development
by addressing the case of the ontology-based software tool OntoGUI. The class expressions allow this tool
to correctly create relations between object types, object occurrences, and pre-defined property sets while565
avoiding hard-coded implementations and enhancing the consistency and integrity of data on the level of
application. The generation of class expressions like (76)-(79) can be applied to the core ifcOWL ontology,
but also to domain ontologies that extend ifcOWL. Therefore, any ontology-based application that is able
to handle such class expressions will enhance its flexibility and re-usability.
24
It remains to be determined to what extent OWL class expressions can be employed to convert further570
explicit and implicit rules in the IFC schema. Further developments are foreseen to address the following
open issues:
IFC property and quantity sets have not yet been considered in the literature about EXPRESS to
OWL conversion because they are not included in the EXPRESS schema, but attached to the IFC
specification as XML files. However, the XML definition can be converted to OWL by creating575
new pre-defined property sets. In this case, class expressions like (78) and (79) would complete the
characterization of the property sets.
WHERE rules that constrain the feasible values of EXPRESS defined data types (e.g.
IfcPositiveInteger and IfcTextAlignment) can be converted to class expressions consisting in
restrictions on OWL datatype properties (owl:DatatypeProperty). This conversion pattern would580
be general purpose and not limited to the IFC schema.
Further WHERE rules declarations in the IFC schema may be successfully converted into customized
class expressions. Attention will be paid to declarations involving objectified relationship classes (i.e.
subclasses of IfcRelationship).
Implicit rules in the IFC standard could be made explicit in its OWL version. For example, class585
expressions can be exploited to enforce that a process (see IfcProcess) can be nested only by
another process.
Ontology can help to shed light into other aspects of the IFC standard as well. On the one hand, it helps
to understand classes and relationships, raising the awareness of the modeller toward a coherent use of these
elements [34]. On the other hand, it provides guidelines to choose the appropriate representation schema590
depending on the information to be modelled. It remains to verify whether this further analysis may lead
to improve the conversion results here discussed as suggested by previous experiences in applied ontology,
e.g. [35, 36, 37].
9. Acknowledgments
This research has been partially funded by the European Union 7th FP (FP7/20072013) under the grant595
agreement No: 314156, Engineering Apps for advanced Manufacturing Engineering (Apps4aME) and by
MIUR under the Italian flagship project Fabbrica del Futuro, Subproject 2, research project Product and
Process Co-Evolution Management via Modular Pallet configuration (PRO2EVO) and Smart Manufactur-
ing 2020 of the Cluster Tecnologico Nazionale Fabbrica Intelligente.
25
References600
[1] T. Liebich, Y. Adachi, J. Forester, J. Hyvarinen, S. Richter, T. Chipman, M. Weise, J. Wix, Industry Foundation
Classes official release - Introduction, online.
URL http://www.buildingsmart-tech.org/ifc/IFC4/final/html/introduction.htm
[2] T. Berners-Lee, J. Hendler, O. Lassila, et al., The semantic web, Scientific American 284 (5) (2001) 28–37.
[3] International Organization for Standardization, ISO 10303-11:2004, Industrial Automation Systems and Integra-605
tion – Product Data Representation and Exchange – Part 11: Description Methods: The EXPRESS Language
Reference Manual, online.
URL http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=
38047
[4] P. Hitzler, M. Krtzsch, B. Parsia, P. F. Patel-Schneider, S. Rudolph, OWL 2 Web Ontology Language Primer610
(Second Edition), online.
URL http://www.w3.org/TR/owl2-primer/
[5] P. Pauwels, ifcOWL: the EXPRESS to OWL conversion pattern, online (2015).
URL http://www.w3.org/community/lbd/ifcowl/
[6] International Organization for Standardization, ISO 10303-21:2002, Industrial Automation Systems and Integra-615
tion – Product Data Representation and Exchange – Part 21: Implementation Methods: Clear Text Encoding of
the Exchange Structure, online.
URL http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=
38047
[7] buildingSMART, Certified Software, online.620
URL http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=
38047
[8] W. Terkaj, M. Urgo, Ontology-based Modeling of Production Systems for Design and Performance Evaluation,
in: 12th IEEE International Conference on Industrial Informatics, Porto Alegre, 2014, 2014.
[9] J. Beetz, J. Van Leeuwen, B. De Vries, IfcOWL: A case of transforming EXPRESS schemas into ontologies,625
Artificial Intelligence for Engineering Design, Analysis and Manufacturing 23 (01) (2009) 89–101.
[10] S. Krima, R. Barbau, X. Fiorentini, R. Sudarsan, R. Sriram, OntoSTEP: OWL-DL ontology for STEP, National
Institue of Standards and Technology, NISTIR 7561.
[11] R. Barbau, S. Krima, S. Rachuri, A. Narayanan, X. Fiorentini, S. Foufou, R. D. Sriram, OntoSTEP: Enriching
product model data using ontologies, Computer-Aided Design 44 (6) (2012) 575–590.630
[12] H. Schevers, R. Drogemuller, Converting the Industry Foundation Classes to the Web Ontology Language, in:
Semantics, Knowledge and Grid, 2005. SKG’05. First International Conference on, IEEE, 2005, pp. 73–73.
[13] H. Knublauch, R. W. Fergerson, N. F. Noy, M. A. Musen, The Prot´
eg´
e OWL plugin: An Open Development
Environment for Semantic Web Applications, in: The Semantic Web–ISWC 2004, Springer, 2004, pp. 229–243.
[14] P. Pauwels, R. De Meyer, J. Van Campenhout, Interoperability for the Design and Construction Industry through635
26
Semantic Web Technology, in: T. Declerck, M. Granitzer, M. Grzegorzek, M. Romanelli, S. Rger, M. Sintek
(Eds.), Semantic Multimedia, Vol. 6725 of Lecture Notes in Computer Science, Springer Berlin Heidelberg,
2011, pp. 143–158.
[15] L. Zhang, R. R. Issa, Development of IFC-based construction industry ontology for information retrieval from
IFC models, in: Proceedings of the 2011 EG-ICE Workshop, University of Twente, The Netherlands, July, 2011,640
pp. 6–8.
[16] P. Pauwels, D. Van Deursen, R. Verstraeten, J. De Roo, R. De Meyer, R. Van de Walle, J. Van Campenhout,
A semantic rule checking environment for building performance checking, Automation in Construction 20 (5)
(2011) 506–518.
[17] I. Horrocks, P. F. Patel-Schneider, H. Boley, S. Tabet, B. Grosof, M. Dean, et al., SWRL: A Semantic Web Rule645
Language Combining OWL and RuleML, W3C Member submission 21 (2004) 79.
[18] T. Beach, Y. Rezgui, H. Li, T. Kasim, A rule-based semantic approach for automated regulatory compliance in
the construction sector, Expert Systems with Applications 42 (12) (2015) 5219 – 5231.
[19] S.-K. Lee, K.-R. Kim, J.-H. Yu, BIM and ontology-based approach for building cost estimation, Automation in
Construction 41 (2014) 96 – 105.650
[20] W. Terkaj, G. Pedrielli, M. Sacco, Virtual Factory Data Model, in: Proceedings of the Workshop on Ontology and
Semantic Web for Manufacturing, CEUR Workshop Proceedings, Vol. 886, 2012, pp. 29–43.
[21] International Organization for Standardization, ISO 14649-1:2003, Industrial automation systems and integration
– Physical device control – Data model for computerized numerical controllers – Part 1: Overview and funda-
mental principles, online.655
URL http://www.iso.org/iso/catalogue_detail.htm?csnumber=34743
[22] B. K ´
ad´
ar, W. Terkaj, M. Sacco, Semantic virtual factory supporting interoperable modelling and evaluation of
production systems, CIRP Annals-Manufacturing Technology 62 (1) (2013) 443–446.
[23] M. Colledani, G. Pedrielli, W. Terkaj, M. Urgo, Integrated Virtual Platform for Manufacturing Systems Design,
Procedia CIRP 7 (2013) 425 – 430.660
[24] S. Zhang, F. Boukamp, J. Teizer, Ontology-based semantic modeling of construction safety knowledge: Towards
automated safety planning for job hazard analysis (JHA), Automation in Construction 52 (2015) 29 – 41.
[25] M. Horridge, N. Drummond, J. Goodwin, A. L. Rector, R. Stevens, H. Wang, The Manchester OWL Syntax, in:
OWLed, Vol. 216, 2006.
[26] W. Zhao, J. Liu, OWL/SWRL representation methodology for EXPRESS-driven product information model: Part665
I. Implementation methodology, Computers in Industry 59 (6) (2008) 580 – 589.
[27] W. Zhao, J. Liu, OWL/SWRL representation methodology for EXPRESS-driven product information model: Part
II: Practice, Computers in Industry 59 (6) (2008) 590 – 600.
[28] J. Beetz, J. van Leeuwen, B. de Vries, An ontology web language notation of the industry foundation classes, in:
Proceedings of the 22nd CIB W78 Conference on Information Technology in Construction, Vol. 2006, 2005.670
[29] D. Beckett, Redland RDF Libraries, Online.
URL http://librdf.org/
27
[30] G. Modoni, M. Sacco, W. Terkaj, A survey of RDF store solutions, in: International ICE Conference on Engi-
neering, Technology and Innovation (ICE), 2014, pp. 1–7.
[31] Open IFC Model Repository, Iai: 6-01window brep ac 1, online.675
URL http://openifcmodel.cs.auckland.ac.nz/Model/Details/199
[32] P. Pauwels, D. Van Deursen, IFC-to-RDF: adaptation, aggregation and enrichment, in: First International Work-
shop on Linked Data in Architecture and Construction, Abstracts, 2012, pp. 1–3.
[33] R. Brachman, H. Levesque, Knowledge representation and reasoning, Elsevier, 2004.
[34] S. Borgo, E. M. Sanfilippo, A. Sojic, W. Terkaj, Ontological Analysis and Engineering Standards: an initial680
study of IFC, in: V. Ebrahimipour, S. Yacout (Eds.), Ontology Modeling in Physical Asset Integrity Management,
Springer, 2015.
[35] N. Guarino, C. A. Welty, An overview of OntoClean, in: Handbook on ontologies, Springer, 2009, pp. 201–220.
[36] M. Gr ¨
uninger, Using the PSL ontology, in: Handbook on Ontologies, Springer, 2009, pp. 423–443.
[37] M. West, Developing high quality data models, Elsevier, 2011.685
28
... (Belsky et al. 2016) Semantic enrichment to supplement an IFC exchange file with semantically useful concepts inferred from the information contained in the building model (Costa and Madrazo 2015) Integration between product component catalogues and BIM through the Linked Data approach. (Hamledari et al. 2017) Incorporation of progress data into 4D BIM by updating the IFC file (Terkaj and Šojić 2015) An enhancement of the existing IFC to OWL conversion patterns. (Sacks et al. 2018b) Compiling information for bridge inspection and system management, using point cloud data processing and IFC (Abanda et al. 2013 We can conclude that there are two major research directions regarding enrichment of BIM models, more specifically the representation of building data as the starting point of the process. ...
... The connection between semantic web technologies and the IFC standard (namely, the agreed Web Ontology Language for IFC -ifcOWL) was further investigated in (Pauwels and Oraskari 2016;Terkaj and Šojić 2015). All efforts aim to increase machine readability and eventually provide a semantically rich platform to support the integration of software tools and data exchange (Pauwels and Terkaj 2016). ...
Article
Semantic enrichment of BIM models is a process designed to add meaningful semantics to the information represented in a building model. Although semantic enrichment provides a valuable opportunity for BIM technology to reach its full potential, it is considered an emergent field of research. As such, the body of knowledge on the subject is incomplete and lacks formal definition of the process, possible applications, contributions, and computational approaches. In this work, an extensive literature review is performed to begin forming the body of knowledge in this field. A bibliometric analysis of relevant publications is implemented to identify previously explored approaches and methods for enrichment. Papers describing previous work in the field demonstrate the application of semantic enrichment to building information stored in accordance to the Industry Foundation Classes (IFC) schema as well as based on a web ontology. A detailed content analysis illustrates the benefits of semantic enrichment for various tasks in the BIM domain, including improvement of data exchange routines, design analysis and processing data obtained by remote sensing techniques. A formal definition for "semantic enrichment of BIM" is suggested based on the common features identified during the literature review. This work discusses the significance of semantic enrichment to a BIM workflow, pinpoints its current research gaps and describes direction for future research.
... He identified four different categories: (i) "validation checking" of the building information model's content with the rules set (regulation, standards, contract, etc.), (ii) "model content checking" of the completeness of the building information model's content with regards to a particular use-case, (iii) "smart object checking" of the model's objects with behavioural rules, and (iv) "design option checking" to support and guide the design process with respect to best practices. (Krijnen, 2016) gave an overview of technical solutions to automate data requirements checking and proposed a classification based on these technologies, namely: schema semantics and IFC ( (Eastman et al., 2009), (Terkaj & Šojić, 2015)); Model View Definitions (MVD) ( , , ); concept libraries ( (Palos et al., 2014), (Miller, 1995), (Navigli & Ponzetto, 2012)); query languages (Pauwels & Terkaj, 2016), and reasoners (Krijnen & Tamke, 2015). ...
Article
Full-text available
Building Information Modelling (BIM) is changing how built assets are delivered and operated. A built asset is represented as a set of objects, each with an identity, attributes, and relations. This object-oriented nature enables new approaches for ensuring compliance with a range of requirements: e.g. industry guidelines; project and client-specific requirements; and building codes and standards. Furthermore, bottom-up design approaches are known to be more suitable for quality control and design errors detection. Based on an adapted version of simulated annealing concept, this paper proposes an automated compliance checking classification and identifies a set of desired characteristics these methods should fulfil. It then demonstrates a bottom-up object-centred approach for automated model checking and the corresponding plugin prototype. The approach and the prototype enable four key processes and satisfy all desired characteristics of compliance checking methods including content validation, model completeness, smart object, and design option checking. To demonstrate the feasibility and accuracy of the approach, two case studies are processed using existing BIM objects libraries one of which is created by a major French manufacturer. All four steps were successfully completed, and the results show savings of around 125 minutes per object between the automated approach and traditional manual methods of working.
... There is a growing appetite for Semantic Web data within the building information modelling (BIM) communities, evidenced by the existence of working groups like the W3C Linked Building Data Community Group (https://www.w3.org/community/lbd/, accessed on 30 October 2021), and the existence of projects such as BRICK [43], IFC/Ontology mappings [44] and the "Building Topology Ontology" (https://w3id.org/bot, accessed on 30 October 2021). ...
Article
Full-text available
In 2012 the Open Geospatial Consortium published GeoSPARQL defining ``an RDF/OWL ontology for [spatial] information'', ``SPARQL extension functions'' for performing spatial operations on RDF data and ``RIF rules'' defining entailments to be drawn from graph pattern matching. In the 8+ years since its publication, GeoSPARQL has become the most important spatial Semantic Web standard, as judged by references to it in other Semantic Web standards and its wide use for Semantic Web data. An update to GeoSPARQL was proposed in 2019 to deliver a version 1.1 with a charter to: handle outstanding change requests and source new ones from the user community and to "better present" the standard, that is to better link all the standard's parts and better document \& exemplify elements. Expected updates included new geometry representations, alignments to other ontologies, handling of new spatial referencing systems, and new artifact presentation. This paper describes motivating change requests and actual resultant updates in the candidate version 1.1 of the standard alongside reference implementations and usage examples. We also describe the theory behind particular updates, initial implementations of many parts of the standard, and our expectations for GeoSPARQL 1.1's use.
... There still exists room for improvement in regards to maintaining the original intent of EXPRESS schemas by considering WHERE, DERIVE, UNIQUE clauses and the redefinition of attributes in entities, and CONSTANTs, RULEs, and FUNCTIONs in schemas [24]. For the individual filter, importing an EXPRESS schema instead of a commaseparated values (CSV) file might be helpful for potential Table 6. ...
Article
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.
... From then on, the following researches have focused on the ontology-based representation of IFC EXPRESS schema. Recently, Terkaj [27] and Pauwels [28] have proposed an EXPRESS-to-OWL converter of IFC data model and the ifcOWL (an OWL representation of the IFC schema) has become a standard in buildingSMART International. Based on the ifcOWL and a designed regulatory ontology, automated code compliance checking could be implemented for acoustic performance checking [29] and building environment checking [15]. ...
Article
Code compliance checking plays a critical role that identifies substandard designs according to regulatory documents and promises the accuracy of the designs before construction. However, the traditional code compliance checking process relies heavily on human work. To help the users better understand the checking process, this study proposes a gray-box checking technique and a BIM-based (Building Information Modeling) automated code compliance checking methodology that leverages ontology. The proposed approach contains a code ontology, a designed model ontology, a merged ontology, a code compliance checking ontology, a set of mapping rules, and a set of checking rules. During the checking process, the ontologies provide knowledge bases, and the rules provide necessary logic. A five-step roadmap is proposed for code ontology development for domain experts. For the time being, pre-processing is applied to create the designed model ontology to achieve time saving. Next, an ontology mapping procedure between the code and the designed model ontology is executed to obtain the merged ontology. In the ontology mapping procedure, the mapping rules aim to mitigate the semantic ambiguity between design information and regulatory information and enrich building information's semantics. Subsequently, rule-based reasoning is applied based on the checking rules and the merged ontology for checking reports generation. Finally, according to Chinese building codes, an automated code compliance checking platform is implemented for real construction projects to validate the proposed methodology.
... Timing and SWG participant effort did not allow for roles to be added in GeoSPARQL 700 1.1 and their addition may be sensible for a GeoSPARQL 1.2. as BRICK [42], IFC/Ontology mappings [43] and the "Building Topology Ontology" 36 . While it is currently possible to use spatial reference system definitions in literal 718 descriptions, spatial reference system definitions have not been completely formalized 719 using an ontology model as of today. ...
Preprint
Full-text available
In 2012 the Open Geospatial Consortium published GeoSPARQL defining “an RDF/OWL ontology for [spatial] information”, “SPARQL extension functions” for performing spatial operations on RDF data and “RIF rules” defining entailments to be drawn from graph pattern matching. In the 8+ years since its publication, GeoSPARQL has become the most important spatial Semantic Web standard, as judged by references to it in other Semantic Web standards and its wide use for Semantic Web data. An update to GeoSPARQL was proposed in 2019 to deliver a version 1.1 with a charter to: handle outstanding change requests and source new ones from the user community and to “better present” the standard, that is to better link all the standard’s parts and better document & exemplify elements. Expected updates included new geometry representations, alignments to other ontologies, handling of new spatial referencing systems, and new artifact presentation. In this paper, we describe motivating change requests and actual resultant updates in the candidate version 1.1 of the standard alongside reference implementations and usage examples. We also describe the theory behind particular updates, initial implementations of many parts of the standard, and our expectations for GeoSPARQL 1.1’s use.
Article
Contemporary engineering in the construction field has put forward higher requirements on the value utilization of building information models, and as the prefabricated building is the core of construction industrialization, using BIM (Building Information Model) technology to realize the forward design of prefabricated buildings and maximize the value of BIM is in urgent demand in the current construction industry. However, in the application process of forward design, there is a lack of standardized implementation guidance and mature technical support, leading to many problems such as a redundancy of model information, heterogeneity of data information, and low efficiency of transmission. Based on this, this paper proposes a model view delivery method of forward design for prefabricated buildings. Firstly, a simplified assembly model and an assembly knowledge model are designed and extended with IFC (Industry Foundation Classes), then we realize the knowledge visualization expression by combining with an ontology semantic system. For the model view of a prefabricated building domain, this paper realizes the reusable concept module by ontology IDM (Information Delivery Manual) and properties selection of knowledge graphs, and then completes the model view delivery through data mapping and IfcDoc (Ifc Documentation Generator) tool output. Finally, the implementation model of information delivery management for forward design is built with model view delivery as the central link.
Chapter
Fundamental changes of business processes in railway transport are the outcomes of implementing large-scale research and technical projects known today as “digital railways”. The adoption of digital technologies has enabled more effective management of the industry intangible assets which are defined in the article as industry-specific knowledge. In particular, there is increasing pragmatic interest in ontologies as a form of industry-specific knowledge representation and Semantic Web standards relevant to the challenges facing digital railways in a global scale. This is a powerful argument in favour of an ontology-based model of interaction between the railway industry and engineering education (railway universities). Such an ontology-based model is the core of knowledge factory didactic concept proposed by the authors. Addressing the ontologies provides developing a model of highly structured, open conceptual space organized through Semantic Web standards for industry-specific knowledge interoperability and their machine processing. The study used a bottom-up approach to constructing Russian-English ontologies as the basis of e-learning training courses intended for future railway engineers. The Onto.plus software with an embedded multi-user ontology editor supporting the Semantic Web standards and the way of knowledge representation in Controlled Natural Languages (in particular, the author's version of Controlled Russian Language) was applied for that purpose. The constructed ontologies are considered as a key element of didactic tools to introduce theoretical foundations of knowledge factory concept in the learning and teaching process. The integration of an ontology-based model into the competence-based paradigm of engineering education is ensured through a method for developing students’ cognitive skills focusing on the step-by-step formation of concepts.
Article
Full-text available
Information extraction (IE), which aims to retrieve meaningful information from plain text, has been widely studied in general and professional domains to support downstream applications. However, due to the lack of labeled data and the complexity of professional mechanical, electrical and plumbing (MEP) information, it is challenging to apply current common deep learning IE methods to the MEP domain. To solve this problem, this paper proposes a rule-based approach for MEP IE task, including a “snowball” strategy to collect large-scale MEP corpora, a suffix-based matching algorithm on text segments for named entity recognition (NER), and a dependency-path-based matching algorithm on dependency tree for relationship extraction (RE). 2 ideas called “meta linking” and “path filtering” for RE are proposed as well, to discover the out-of-pattern entities/relationships as many as possible. To verify the feasibility of the proposed approach, 65 MB MEP corpora have been collected as input of the proposed approach and an MEP semantic web which consists of 15,978 entities and 65,110 relationship triples established, with an accuracy of 81% to entities and 75% to relationship triples, respectively. A comparison experiment between classical deep learning models and the proposed rule-based approach was carried out, illustrating that the performance of our method is 37% and 49% better than the selected deep learning NER and RE models, respectively, in the aspect of extraction precision.
Book
Full-text available
Developing High Quality Data Models provides an introduction to the key principles of data modeling. It explains the purpose of data models in both developing an Enterprise Architecture and in supporting Information Quality; common problems in data model development; and how to develop high quality data models, in particular conceptual, integration, and enterprise data models. The book is organized into four parts. Part 1 provides an overview of data models and data modeling including the basics of data model notation; types and uses of data models; and the place of data models in enterprise architecture. Part 2 introduces some general principles for data models, including principles for developing ontologically based data models; and applications of the principles for attributes, relationship types, and entity types. Part 3 presents an ontological framework for developing consistent data models. Part 4 provides the full data model that has been in development throughout the book. The model was created using Jotne EPM Technologys EDMVisualExpress data modeling tool. This book was designed for all types of modelers: from those who understand data modeling basics but are just starting to learn about data modeling in practice, through to experienced data modelers seeking to expand their knowledge and skills and solve some of the more challenging problems of data modeling.
Chapter
Full-text available
There is an increasing interest in developing ontological versions of engineering standards. In general, this amounts to restating a given standard in some ontological language like OWL. We observe that without an ontological analysis of the standard, the conversion neither improves the clarity of the standard nor facilitates its coherent application. In this chapter we begin to study the Industry Foundation Classes (IFC), a standard providing an open vendor-independent file format and data model for data interoperability and exchange for Architecture/Engineer-ing/Construction and Facility Management. We first look at IFC and at an existing OWL version of IFC; then we highlight the implicit assumptions and we apply ontological analysis to discuss how to best grasp the type/occurrence distinction in IFC. The goal is to show what has been done in IFC and the contribution of ontological analysis to help increasing the correct understanding of a standard. With this approach, we reach a deeper understanding, which can guide the translation from the original language to OWL with increased conceptual clarity while ensuring both logical coherence and ontological soundness.
Conference Paper
Full-text available
This paper presents the extension to an ontology-based data model supporting the design and performance evaluation of production systems. This extension aims to link the modeling of the spatial representation of physical objects with the characterization of their states and behavior. Furthermore, the formalization of the performance history of a production system and its components is addressed to capture both the spatial and state evolution of the objects. Such history can be provided by simulation runs or gathered from a monitoring system. A test case is described and then used to show how different software tools can be integrated to support the integrated design and evaluation of a production system.
Article
Full-text available
The Industry Foundation Classes (IFC) is the preferred format for addressing the interoperability issues in using Building Information Modeling (BIM) in the information-intensive construction industry. IFC specifies virtual representation of building objects as well as their attributes and relationships. Although IFC is an open standard, its complex nature makes information retrieval from an IFC model difficult. This paper proposes an ontology built with Web Ontology Language (OWL) based on IFC specifications to help the information retrieval process from an IFC model. With simple reasoning build into the ontology, an information retrieval system could query the IFC model in XML format directly. The development of the ontology is reviewed and test cases are designed to validate the ontology. Limitations and future studies are also discussed at the end.
Conference Paper
Full-text available
The usage of semantic web technologies might enable addressing existing interoperability issues in the domain of architecture, engineering and construction, because they allow linking diverse information models. We indicate here how IFC models can be made available as RDF graphs in the semantic web and how they can be linked to other information. As such, their capabilities in addressing interoperability issues can be assessed.
Conference Paper
Full-text available
This paper analyzes the potential of Semantic Web technologies to support innovation in industrial scenarios. The study focuses in particular on RDF stores, the software components dedicated to the storage, representation and retrieval of semantic information. Starting from a literature review, a qualitative analysis is carried out considering a set of these systems. RDF stores are evaluated to find the implementations that are best suited to play the role of backbone in a software architecture sharing information between the software tools adopted by the various stakeholders. This can be achieved if the architecture overcomes the problems deriving from the lack of integration between the involved software applications, providing in this way an integrated view on relevant engineering knowledge.
Article
A key concern for professionals in any industry is ensuring regulatory compliance. Regulations are often complex and require in depth technical knowledge of the domain in which they operate. The level of technical detail and complexity in regulations is a barrier to their automation due to extensive software development time and costs that are involved. In this paper we present a rule-based semantic approach formulated as a methodology to overcome these issues by allowing domain experts to specify their own regulatory compliance systems without the need for extensive software development. Our methodology is based on the key idea that three semantic contexts are needed to fully understand the regulations being automated: the semantics of the target domain, the specific semantics of regulations being considered, and the semantics of the data format that is to be checked for compliance. This approach allows domain experts to create and maintain their own regulatory compliance systems, within a semantic domain that is familiar to them. At the same time, our approach allows for the often diverse nature of semantics within a particular domain by decoupling the specific semantics of regulations from the semantics of the domain itself. This paper demonstrates how our methodology has been validated using a series of regulations automated by professionals within the construction domain. The regulations that have been developed are then in turn validated on real building data stored in an industry specific format (the IFCs). The adoption of this methodology has greatly advanced the process of automating these complex sets of construction regulations, allowing the full automation of the regulation scheme within 18 months. We believe that these positive results show that, by adopting our methodology, the barriers to the building of regulatory compliance systems will be greatly lowered and the adoption of three semantic domains proposed by our methodology provides tangible benefits.
Article
Construction safety related knowledge and project specific information are scattered and fragmented. Despite technological advancements of information and knowledge management in the building and construction industry, a link between safety management and information models is still missing. The objective of this study is to investigate a new approach to organize, store and re-use construction safety knowledge. A construction safety ontology is proposed to formalize the safety management knowledge. It consists of three main domain ontology models, including Construction Product Model, Construction Process Model, and Construction Safety Model. One-on-one expert interviews were conducted for ontology evaluation. The interaction between safety ontology and Building Information Modeling (BIM) is also explored. A prototype application of ontology-based job hazard analysis (JHA) and visualization is implemented to further illustrate the applicability and effectiveness of the developed ontology. The developed construction safety ontology enables more effective inquiry of safety knowledge, which is the first step towards automated safety planning for JHA using BIM.
Article
This research proposes an ontological inference process to automate the process of searching for the most appropriate work items, which is limited to tiling in this case study. The proposed ontological approach can help engineers to find work items with greater ease and consistency. Suggestions are also made for further research on ways of improving the accuracy of BIM-based quantity take-off, and developing a methodology to match between work items which are expressed as different terms; however, the proposed approach emphasizes the automation of searches using BIM data to find items suitable for building elements and materials. To enable automated inference, this study establishes (1) a work condition ontology that consists of the determinants required to select work items, (2) a work item ontology, which consists of the factors defining the tiling method, and (3) semantic reasoning rules. By conducting a case study to demonstrate the proposed ontological inference process in a real-world situation, we confirm that the proposed process can provide consistent results; however, since work items differ depending on construction type and technological advancement, the work item ontology should be continually revised and updated. The ontological inference process removes the need for the intervention of a cost estimator's subjectivity in searching for an appropriate work item. Also, if ontology is elaborately defined by the knowledge of experienced engineers, then accurate and consistent results can be obtained. In addition, the proposed process will assist cost estimators to use BIM data more easily, and it will help the expansion of BIM-based construction management.