ArticlePDF Available

EXPRESS to OWL for construction industry: Towards a recommendable and usable ifcOWL ontology



An increasing number of information management and information exchange applications in construction industry is relying on semantic web technologies or tools from the Linked Open Data (LOD) domain to support data interoperability, flexible data exchange, distributed data management and the development of reusable tools. These goals tend to be overlapped with the purposes of the Industry Foundation Classes (IFC), which is a standard for the construction industry defined through an EXPRESS schema. A connecting point between semantic web technologies and the IFC standard would be represented by an agreed Web Ontology Language (OWL) ontology for IFC (termed ifcOWL) that allows to (1) keep on using the well-established IFC standard for representing construction data, (2) exploit the enablers of semantic web technologies in terms of data distribution, extensibility of the data model, querying, and reasoning, and (3) re-use general purpose software implementations for data storage, consistency checking and knowledge inference. Therefore, in this paper we will look into existing efforts in obtaining an ifcOWL ontology from the EXPRESS schemas of IFC and analyse which features would be required in a usable and recommendable ifcOWL ontology. In making this analysis, we present our implementations of an EXPRESS-to-OWL converter and the key features of the resulting ifcOWL ontology.
EXPRESS to OWL for construction industry:
towards a recommendable and usable ifcOWL ontology
Pieter Pauwels
, Walter Terkaj
Department of Architecture and Urban Planning, Ghent University,
J. Plateaustraat 22, B-9000 Ghent, Belgium
Istituto di Tecnologie Industriali e Automazione (ITIA), Consiglio Nazionale delle Ricerche (CNR),
Via Bassini, 15 - 20133 Milano, Italy
An increasing number of information management and information exchange applications in construction industry is
relying on semantic web technologies or tools from the Linked Open Data (LOD) domain to support data interoper-
ability, flexible data exchange, distributed data management and the development of reusable tools. These goals tend
to be overlapped with the purposes of the Industry Foundation Classes (IFC), which is a standard for the construction
industry defined through an EXPRESS schema. A connecting point between semantic web technologies and the IFC
standard would be represented by an agreed Web Ontology Language (OWL) ontology for IFC (termed ifcOWL)
that allows to (1) keep on using the well-established IFC standard for representing construction data, (2) exploit the
enablers of semantic web technologies in terms of data distribution, extensibility of the data model, querying, and
reasoning, (3) re-use general purpose software implementations for data storage, consistency checking and knowl-
edge inference. Therefore, in this paper we will look into existing eorts in obtaining an ifcOWL ontology from the
EXPRESS schemas of IFC and analyse which features would be required in a usable and recommendable ifcOWL
ontology. In making this analysis, we present our implementations of an EXPRESS-to-OWL converter and the key
features of the resulting ifcOWL ontology.
Keywords: Industry Foundation Classes (IFC), Web Ontology Language (OWL), building, construction, information
technology, Resource Description Framework (RDF), semantic web
1. Introduction1
Building information modelling (BIM) can be named2
as one of the most notable eorts in recent years re-3
garding information management in construction indus-4
try [1]. BIM environments allow to semantically de-5
scribe any kind of information about the building in6
one 3D model, so that it can be better represented and7
more easily exchanged than in the case of traditional8
computer-aided design (CAD) tools. The IFC stan-9
dard [2], developed by buildingSMART [3], aims at10
supporting these activities by providing a central “con-11
ceptual data schema and an exchange file format for12
BIM data” [2, scope]. In other words, using the IFC13
data model and file format, BIM data can be exchanged14
Corresponding author: Tel. 0032 9 264 3880 - Mob. 0032 486
Email addresses: (Pieter
Pauwels), (Walter Terkaj)
between software applications, which can in turn pro-15
vide extra functionality (e.g. 4D planning, 5D cost cal-16
culation, Computational Fluid Dynamics (CFD) simu-17
lation, structural analysis, and so forth).18
1.1. IFC and EXPRESS19
Each IFC data model is represented as a schema in20
the EXPRESS data specification language defined inthe21
10303-11:1994 standard of the International Organisa-22
tion for Standardisation (ISO). The EXPRESS language23
“consists of language elements which allow an unam-24
biguous data definition and specification of constraints25
on the data defined and by whichaspectsofproduct data26
can be specified” [4]. The EXPRESS language consists27
of the terms (e.g. types, entities, properties) and rules28
that must be used to build a specific EXPRESS schema29
(.exp). In the case of IFC, there are several avail-30
able IFC EXPRESS schemas, including the most well-31
known IFC2X3.exp, IFC2X3
TC1.exp, IFC4RC4.exp,32
Preprint submitted to Automation in Construction November 12, 2015
and IFC4 ADD1.exp (see [5] for an overview of the33
specifications). These schemas should be considered34
as chronologically ordered versions of one IFC schema,35
meaning that there is always one most recent schema36
Each of the EXPRESS schemas of IFC [5] enables38
a description of construction-related information where39
the represented objects have a well-defined and interre-40
lated meaning and purpose. As a single window ele-41
ment can internally be described in very diverse ways42
by each BIM environment, the export/import possibili-43
ties to/from IFC should guarantee that each BIM envi-44
ronment is able to map its own descriptions to a gen-45
erally understandable IFC format, thereby considerably46
improving (not solving) the interoperability of informa-47
We want to point out that IFC is not an isolated eort49
or standard. It should be used in combination with other50
standards, such as Model View Definitions (MVDs) and51
Information Delivery Manuals (IDMs), if an improved52
information exchange is targeted. Also Property Set53
Definition (PSD) releases [6] should be considered as54
important additions to the IFC schema. A PSD re-55
lease provides a schema that defines how custom prop-56
erties and property sets can be defined outside of the57
IFC specification. This schema is provided as an Ex-58
tensible Markup Language (XML) Schema Definition59
(XSD). PSD’s, as well as MVDs and IDMs are consid-60
ered out of the scope of this paper. Starting from a cen-61
trally agreed ifcOWL ontology, however, it is feasible to62
support PSD, MVD and IDM definitions in a semantic63
web representation.64
1.2. RDF and OWL65
1.2.1. The basics66
The semantic web initiative [7] shares some of the67
goals of formal specification of information that IFC68
is targeting for the construction industry domain. The69
semantic web was conceived and presented as the suc-70
cessor of the existing World Wide Web (WWW) by71
describing all information in a language that could be72
understood by computer applications, i.e. machine-73
readable. Because the WWW contains information74
about almost any possible concept in the world, the75
language describing this information cannot follow one76
domain-specific schema. Instead, a flexible and generic77
language is needed that allows to describe and easily78
combine information from very dierent knowledge do-79
mains. Therefore, the semantic web was conceived as80
a semantic network [8] in which diverse semantic do-81
mains can be represented and combined using directed82
labelled graphs. Each node in such a graph thus rep-83
resents a concept or object in the world and each la-84
belled arc represents the logical relation between two of85
these concepts or objects. A graph can be constructed86
using the Resource Description Framework (RDF) [9],87
which has a basis in description logic (DL) [10]. The88
graph is thus formed by a set of logic-based declarative89
sentences and, in total, it represents a specific semantic90
domain, as it is understood and explained by Hennessy91
[11]. By describing information in a single directed la-92
belled graph, a uniform representation of information is93
achieved, making information reusable by both humans94
and computer applications.95
An RDF graph is constructed by applying a logi-96
cal AND operator to a range of logical statements con-97
taining concepts or objects in the world and their rela-98
tions. These statements are often referred to as RDF99
triples, consisting of a subject, a predicate and an ob-100
ject (Figure 1) and thus implying directionality in the101
RDF graph. In addition, each concept has a Unique Re-102
source Identifier (URI), thereby making the RDF graph103
explicitly labelled. Every concept described in an RDF104
graph, whether this be an object, subject or predicate, is105
uniquely defined through this URI. When two identical106
URIs are found, their semantics are considered identical107
as well.108
Figure 1: The triple form of an RDF statement: subject - predicate -
The resulting RDF graph can be represented using109
various syntaxes. Syntaxes used for RDF graphs are110
RDF/XML (.RDF), N-Triples (.N
T), Turtle (.TTL -111
[12]), and Notation-3 (.N3) [13]. RDF graphs can be112
given an improved semantic structure using RDF vo-113
cabularies or ontologies. The most basic elements to de-114
scribe such ontologies are available in the RDF Schema115
(RDFS) vocabulary [14]. RDFS, for instance, enables116
the specification of classes, subclasses, comments, and117
data types. An RDFS interpreter is able to infer ex-118
tra RDF statements that are implicitly available via the119
RDFS constructs. More expressive elements to describe120
ontologies are available within OWL [15]. In short,121
OWL further enhances the RDFS concepts to allow122
making more complex RDF statements, such as cardi-123
nality restrictions, type restrictions, complex class ex-124
pressions. The RDF graphs constructed with OWL con-125
cepts are called OWL ontologies.126
1.2.2. OWL semantics and OWL profiles127
As the expressiveness of OWLis a key element in this128
article, we will briefly outline what options are avail-129
able in terms of building an OWL ontology. The seman-130
tic expressiveness of the OWL language is specified in131
multiple specification documents hosted by the World132
Wide Web Consortium (W3C). The first W3C Recom-133
mendation for OWL dates from 2004 [16]. This version134
is now superseded by the OWL2 language specification135
issued in 2012 [15]. Hence, any reference to OWL in136
this paper refers to the OWL2 specification. All relevant137
references to the exact semantics of OWL2 can be found138
in [17] (section about Semantics, including OWL2 Di-139
rect Semantics and OWL2 RDF-Based Semantics). Fig-140
ure 2 provides an overview picture that we will use to141
explain the basics of OWL profiles.142
OWL 2 (Full)
Figure 2: The OWL2 profiles EL, QL and RL each provide a cer-
tain kind of expressiveness, which determines to what level of detail
information can be semantically represented and which impacts per-
formance as a result (more information, less performing). Original
figure in [18].
As pointed out in [17], “the Direct Semantics as-143
signs meaning directly to ontology structures, result-144
ing in a semantics compatible with the model theo-145
retic semantics of the SROIQ description logic a146
fragment of first order logic with useful computational147
properties”. This leads to a semantic expressiveness148
for OWL2 that is properly grounded in a particular de-149
scription logic, namely SROIQ. This semantic expres-150
siveness is graphically displayed as the outer ellipse in151
Fig. 2 (OWL2 Full). However, “some conditions must152
be placed on ontology structures in order to ensure153
that they can be translated into a SROIQ knowledge154
base” [17]. For instance, transitive properties cannot be155
used in number restrictions. Whenever an OWL2 on-156
tology satisfies these conditions, the expressiveness of157
the ontology is in the second ellipse in Fig. 2, namely158
OWL2 DL. An OWL ontology should remain within159
this boundary if it is to be used by SROIQ-based tools,160
which are the tools typically supplied by the semantic161
web community.162
As in the case of OWL, also OWL2 has a number of163
so-called profiles, namely OWL2 EL, OWL2 QL and164
OWL2 RL [19]. Figure 2 displays the relationships be-165
tween these three key profiles. As outlined in Motik166
et al. [19], an OWL2 profile “is a trimmed down ver-167
sion of OWL2 that trades some expressive power for168
the eciency of reasoning”. In short, in each of the169
given OWL2 profiles, a number of statements that can170
be used in OWL2 DL is not allowed. By not allowing171
these statements, and thus sacrificing some expressive-172
ness, important improvements can be made in terms of173
performance. Namely, inference engines do not need to174
check a number of restrictions as they are not allowed175
(and thus not considered) in particular profiles. More176
information about the expressiveness of each of the pro-177
files can be found in [19]. The following summarised178
descriptions can be used as a reference:179
OWL2 EL180
This profile is to be used in applications that use181
ontologies with many properties and/or classes.182
Basic reasoning can be performed in time that is183
polynomial with respect to the size of the ontol-184
ogy (PTime). Important constructs that are not185
allowed in OWL2 EL are, among others, uni-186
versal restrictions (allValuesFrom), cardinality187
restrictions (maxCardinality, minCardinal-188
ity, exactCardinality), disjunction (union-189
Of), enumerations (oneOf), and several par-190
ticular property-related expressions (inverseOf,191
disjoint, functionalProperty, symmetric-192
OWL2 QL194
This profile is recommended for applications with195
a large volume of instance data, and where query196
performance is most important. If done properly,197
query answering can be performed in LOGSPACE198
with respect to the size of the data. The expres-199
sive power of this profile is quite limited as it ex-200
cludes constructs such as existential and universal201
restrictions (someValuesFrom, allValuesFrom),202
cardinality restrictions (maxCardinality, min-203
Cardinality, exactCardinality), disjunction204
(unionOf), property inclusions (subProperty-205
Of) and enumerations (oneOf). In comparison206
with OWL EL, some property-related expressions207
are allowed (inverseOf, disjoint, symmetric-208
OWL2 RL210
This profile is meant to be used for applications211
that require scalable reasoning without sacrificing212
too much expressive power. Whenever reasoning213
is involved, it is a good choice to adopt ontologies214
in this profile. “The ontology consistency, class215
expression satisfiability, class expression subsump-216
tion, instance checking, and conjunctive query an-217
swering problems can be solved in time that is218
polynomial with respect to the size of the ontol-219
ogy. [19]. The expressive power of OWL2 RL is220
quite close to OWL2 DL. A few syntactic restric-221
tions (see [19]) need to be taken into account in222
order for the ontology to be in the OWL2 RL pro-223
file. Moreover, all axioms of OWL2 are supported224
in OWL2 RL, except for disjoint unions of classes225
and reflexive object property axioms.226
1.2.3. Closed World Assumption (CWA) versus Open227
World Assumption (OWA)228
Two distinct approaches to knowledge representation229
are relevant when dealing with IFC and OWL: CWA230
and OWA [20]. According to CWA, any statement that231
is not known to be true, must be considered as false.232
When applied to an IFC model or a BIM model, one can233
conclude that whenever something is not specified, it is234
most definitely not there. On the other hand, according235
to OWA a statement that is not known to be true, is not236
necessarily false, nor true, but unknown. In other237
words, it might be true or false in the future, when238
more information is supplied, but no conclusion can be239
drawn until then.240
Many traditional software applications, including241
BIM tools, database systems and the IFC data model,242
adopt a CWA. Semantic web technologies, however,243
generally rely on an OWA because the technologies are244
supposed to be used on the Web, which is a system245
with incomplete information. One cannot conclude that246
something is not true simply because no one specified247
it on the web. Hence, an OWA needs to be adopted.248
At least, that is the original reason behind this decision.249
The dierence between CWA and OWA plays a key role250
when an ontology is used to represent an IFC model or a251
BIM model, because if something is not specified, then252
one cannot conclude much, except that it might still be253
true or false. A whole dierent kind of information254
usage and inference becomes available.255
Mapping information representations in CWA to in-256
formation representations in OWA is not that hard; the257
main dierence lies in the usage of the information that258
is presented in both. Furthermore, it is even possible259
to run a CWA-based validation of an OWL ontology260
(see [21, 22]). However, the OWA of semantic web261
technologies is still something dierent from the tradi-262
tional CWA features in current software applications.263
In many cases, both types of assumptions have their264
value (e.g. [23]). If adopted properly, the usage of se-265
mantic web technologies is a fruitful addition to (and266
not replacement of) existing technologies, such as BIM267
software environments and the IFC specification in EX-268
1.3. Current status of IFC and RDF270
1.3.1. The parallels between IFC and RDF271
There is a considerable parallel between the build-272
ingSMART eort towards the specification and stan-273
dardisation of IFC for construction industry, and the274
W3C eort towards the specification and standardisa-275
tion of RDF for web data. The purpose of the EX-276
PRESS language is similar to the purpose of the OWL277
language, and the semantic structure of an IFC file is278
to some extent comparable to the semantic structure of279
an RDF graph. However, Barbau et al. [24] empha-280
sised the lack of formal semantics in EXPRESS, argu-281
ing that a logic-based language, such as OWL, brings282
certain modelling advantages in knowledge representa-283
tion and semantic data sharing. Indeed, by adopting any284
of the given OWL profiles for specifying building infor-285
mation, one can rely on corresponding model theoretic286
semantics to interpret the information (see Sect. 1.2.2).287
A number of generally available tools beyond construc-288
tion industry can then be used, including generic for-289
mally grounded query engines, reasoning engines, and290
so forth. Such formally grounded generic tools are not291
generally available for EXPRESS. Additionally, Beetz292
et al. [25] stressed the limits of EXPRESS with respect293
to the reuse of existing ontologies and interoperability294
with semantic web tools. With this statement, Beetz295
et al. [25] most likelyrefertotheOWA basis of semantic296
web technologies (see Sect. 1.2.3), which makes it pos-297
sible to add new information without violating any of298
the conclusions that were inferred previously (cf. mono-299
tonic reasoning).300
The main dierences between the buildingSMART301
eort and the W3C eort thus lie in (1) the domain302
that is to be represented, and (2) the language/technol-303
ogy that is used to represent that domain. Currently,304
both IFC and RDF are mainly used within their re-305
spective domains. IFC is commonly used for exchange306
of construction-related information, notwithstanding its307
limitations, whereas RDF is used to represent web data.308
The combination of IFC and RDF led to, among other309
applications, an online LOD cloud [26, 27, 28, 29] that310
collects a considerable number of open RDF datasets311
that are linked together in one open data cloud (1014312
datasets in 2014). As there are so many parallels be-313
tween the approaches behind IFC and RDF, it should be314
possible to attempt publishing IFC data as part of this315
LOD cloud, or at least as RDF graphs.316
1.3.2. Why porting IFC data into the RDF data model?317
The formalisation of IFC data as an RDF graph318
requires to focus first on the conversion of the IFC319
schema, defined as an EXPRESS schema, into an OWL320
ontology. As soon as such an ontology is available, it is321
relatively straightforward to build RDF graphs that are322
compliant with that OWL ontology. Various research323
initiatives addressed the problem of converting an EX-324
PRESS schema to an OWL ontology and some of them325
focused in particular on the specific IFC case.326
Most of the initiatives to formalise IFC in an on-327
tology language have been motivated with the aim of328
providing a semantically rich and platform independent329
framework that can support the integration of software330
tools and exchange of data in a knowledge-based system331
that is both human readable and usable by machines.332
Some early example applications were provisionally333
suggested in Pauwels et al. [30], Abdul-Ghafour et al.334
[31], Yurchyshyna et al. [32], Yurchyshyna and Zarli335
[33] for the construction domain and in Kadar et al.336
[34], Terkaj et al. [35] for the manufacturing domain.337
The potentiality and the presence of technologies to de-338
velop a semantic linking of building information models339
were presented by T
a [36, 37]. In addition, Schevers340
and Drogemuller [38], as well as Zhang and Issa [39],341
arguedthat the conversion of IFC into OWL,besidesen-342
abling the exploitation of semantic web technologies for343
building information models, even facilitates the link-344
age between dierent IFC models and databases. Many345
more example applications have emerged by now, cov-346
ering a myriad of use case scenarios in architectural347
design, construction industry, smart cities applications,348
built heritage applications, the factory and manufactur-349
ing domain, building regulation management, and fa-350
cility management. From these use cases, it is clear351
that the focus of development does not really lie in the352
replacement of existing technologies, but rather in the353
combination of building information with relevant in-354
formation in other domains. This can be considered as355
a useful OWA addition to the set of currently available356
tools that provide crucial CWA functionality.357
Most of the semantic tools previously mentioned358
have relatively limited functionalities and applicability.359
In many cases, the reason for this limitation is the ab-360
sence of a real standard ifcOWL ontology, even though361
several proposals were presented. Therefore, the devel-362
oped applications are all based on slightly dierent on-363
tologies, making them work as isolated examples. As a364
result, it is not really possible to build applications with365
a realistic scope. A recommendable and usable ifcOWL366
ontology would allow to test applications of semantic367
web technologies in more realistic settings and to let368
them mature into usable, trustworthy and helpful tools.369
1.3.3. Previous proposals in the conversion of the EX-370
PRESS schema of IFC into an OWL ontology371
A number of EXPRESS to OWL conversion proce-372
dures has been proposed so far. Schevers and Dro-373
gemuller [38] proposed a first unidirectional conversion374
map from EXPRESS to OWL, taking IFC as a reference375
example and highlighting some of the key issues to be376
addressed. Agostinho et al. [40] proposed a mapping377
between EXPRESS and OWL within a broader Model378
Morphism initiative. Beetz et al. [25] proposed a semi-379
automatic method for converting EXPRESS schemas to380
OWL ontologies in order to enhance the applicability381
and re-usability of the IFC standard. Barbau and col-382
leagues specified a set of rules for the automated conver-383
sion from EXPRESS to OWL within the OntoSTEP ini-384
tiative [41, 24] and implemented the system as a plug-in385
for the Prot
e software tool [42]. Another conversion386
tool was presented by Pauwels and Van Deursen [43].387
Also Gao et al. [44] proposed to develop an OWL on-388
tology for the IFC schema. In this case, the focus was389
entirely on information retrieval (IR) use cases, and only390
those concepts and terms that were considered relevant391
for information retrieval were considered. Eventually,392
248 entities, 140 type enumerations, and 583 enumer-393
ation items were taken from the IFC4 schema as the394
basis for the IFC IR ontology [44]. Terkaj et al. [45]395
proposed an OWL version for a fragment of IFC aiming396
at facilitating the extension of IFC and the integration397
with other data models that are relevant in the scope of398
the industrial domain, in particular for the design and399
management of factories. Finally, Terkaj and Sojic [23]400
presented how some of the EXPRESS rules included in401
an IFC schema can be represented in OWL as well to402
enhance the previous ifcOWL ontologies.403
Many of these proposals have been documented only404
in relatively short scientific articles that are not de-405
tailed enough. For example, Schevers and Drogemuller406
[38], Beetz et al. [25] and Pauwels and Van Deursen407
[43] presented the key ideas of their approach, without408
publishing the generated ontology that would provide409
the actual details of the conversion procedure. There-410
fore, anyone willing to adopt any of these proposals411
would be required to implement the conversion pro-412
cedure, inevitably leading to slightly dierent versions413
(e.g. object property renaming undecided, presence/ab-414
sence of inverse properties, dierent handling of ENUM415
and SELECT data types). In addition, these three ear-416
lier proposals were developed when the OWL2 specifi-417
cation by Hitzler et al. [15] was not yet published. In-418
stead, there was the distinction between the OWL pro-419
files OWL Full, OWL DL and OWL Lite, which are420
dierent from the OWL2 profiles that exist nowadays.421
Nevertheless, most of the presented proposals were in422
OWL DL, which can be compared to OWL2 DL. Hence,423
the general outlines presented in these three early pro-424
posals are still of high value for this article and have425
informed many of the general decisions made here. As426
an example, class wrapping of EXPRESS simple data427
types has been proposed by Schevers and Drogemuller428
[38] and Beetz et al. [25] for good reasons, therefore this429
approach has been adopted here as well for the conver-430
sion of EXPRESS simple data types. Other than that,431
most of the details (cardinality restrictions, domain and432
range restrictions, class and property naming) had to be433
thoroughly reviewed.434
Of the later proposals, the most relevant resources435
are the conversion procedure presented and documented436
within the OntoSTEP initiative [41, 24], and the con-437
version procedure presented by Hoang [46], Hoang and438
a [47]. The OntoSTEP research initiative aims at439
providing a general purpose conversion mechanism for440
any EXPRESS schema to an OWL ontology, not only441
of the EXPRESS schema of IFC. In addition, the con-442
version procedure is well-documented and the result-443
ing ontology file can be generated and checked. Of444
all the available resources, only the conversion proce-445
dure by Hoang [46], Hoang and T
a [47] explicitly446
and appropriately takes into account the existence of447
the OWL2 profiles EL, QL and RL, thereby making a448
case for a conversion procedure that results in a layered449
ifcOWL ontology. Three layers are proposed: ifcOWL450
Simple, which only includes what can be specified in451
the intersection of OWL2 EL, QL and RL (see Fig. 2);452
ifcOWL Standard, which is an ontology in the OWL2453
RL profile; and ifcOWL Extended, which is an ontol-454
ogy in OWL2 DL.455
The proposal that we make in the following sections,456
only diers in the details compared to the proposals457
by Krima et al. [41], Barbau et al. [24] and by Hoang458
[46], Hoang and T
a [47]. Many of the decisions459
made by Krima et al. [41], Barbau et al. [24] are moti-460
vated by the aim of developing a general-purpose con-461
verter for EXPRESS. In other words, the conversion462
procedure is not tailored to the case of construction in-463
dustry or IFC, more specifically. As a result, quite ver-464
bose constructs are often used in order to take into ac-465
count the many possible declarations in EXPRESS. A466
less verbose and thus better usable conversion can be467
used for several concepts employed in IFC.468
The proposal by Hoang [46] and Hoang and T
[47] identified two main criteria for the conversion: (1)470
to be able to switch between dierent OWL2 profiles,471
and (2) to make it easy to generate RDFgraphs as linked472
data, not necessarily tied to an overly restricted ontol-473
ogy. As a result, considerable compromises are made in474
the three proposed ifcOWL ontologies (Simple, Stan-475
dard and Extended), in order to make them somewhat476
compatible. By choosing to not implement OWL class477
domain and range restrictions in the Simple and Stan-478
dard versions of the ontology, mainly because of cri-479
terion 2, these ifcOWL versions tend to become un-480
derspecified. In other words, these ifcOWL versions481
consider only a fraction of the semantic richness of the482
original EXPRESS schema. The ifcOWL Extended on-483
tology can be compared with what we propose in the484
following sections. However, by aiming to make this485
ontology compatible with ifcOWL Simple and ifcOWL486
Standard, it becomes hard to add all the restrictions that487
are originally defined in the EXPRESS schema.488
1.3.4. Targeted criteria489
As highlighted in the previous section, it is impor-490
tant to set appropriate criteria that underpin the pro-491
posed EXPRESS-to-OWL conversion procedure. Con-492
sidering the reasons for targeting one standardised (or493
at least recommended) version of the ifcOWL ontology494
(see Sect.1.3.2), we decided to stick to the following495
three criteria, in order of importance:496
1. The ifcOWL ontology must be in OWL2 DL.497
2. The ifcOWL ontology should match the original498
EXPRESS schema as closely as possible.499
3. The ifcOWL ontology primarily aims at supporting500
the conversion of IFC instance files into equivalent501
RDF files. Thus, herein it is of secondary impor-502
tance that an instance RDF file can be modelled503
from scratch using the ifcOWL ontology and an504
ontology editor.505
We decided to remain in OWL2 DL, and not in any506
of the three OWL2 profiles because an OWL2 DL on-507
tology provides full expressiveness. Note that it is pos-508
sible to develop an ifcOWL ontology in the EL, QL or509
RL profile from the OWL2 DL version, since these pro-510
files are subsets of the OWL2 DL version (Fig. 2). The511
disadvantage behind this decision is that the resulting512
ifcOWL ontology will imply sacrifices in terms of per-513
formance, in particular reasoning performance. The ad-514
vantage is that we have the complete freedom to build515
an ifcOWL ontology that is as close as possible to the516
original IFC EXPRESS schema (cf. our second crite-517
rion). If an ifcOWL ontology is used as a recommended518
version, then this ontology should be as close as possi-519
ble to the original IFC standard. These two first criteria520
are thus very important here, which is not the case in the521
recent proposal by Hoang [46], Hoang and T
a [47].522
The proposal by Krima et al. [41], Barbau et al. [24]523
takes our first two criteria in account as well, but addi-524
tionally aims at supporting the conversion of EXPRESS525
schemas other than IFC (more general purpose).526
The third criterion is considerably less important than527
the first two criteria. Essentially, wetargeted first at sup-528
porting the conversion of IFC instance files into equiv-529
alent RDF files, and not at the creation of RDF graphs530
from scratch, using only the ifcOWL ontology. In most531
cases, IFC models will likely be built still in BIM soft-532
ware environments, as they are available and spread in533
the industry. The common case will thus remain to be a534
one-directional conversion process from BIM environ-535
ment into an ifcOWL-compliant RDF graph. Consider-536
ing this common case, most instance RDF graphs will537
already be checked for consistency in the native BIM538
tools. As a result, we can opt to not convert all pro-539
cedural RULE and FUNCTION declarations in the native540
EXPRESS schema, which are in any case better han-541
dled in a native CWA BIM tool. If one would choose542
to set the third criterion the other way round (i.e. focus-543
ing on the creation of ifcOWL-compliant RDF graphs544
from scratch), then the ifcOWL ontology needs to in-545
clude as many as possible RULE and FUNCTION declara-546
tions. This is to some extent possible, considering the547
proposals made in Terkaj and Sojic [23].548
1.4. Paper outline549
Relying on previous conversion proposals, we have550
looked in close details at the various options of convert-551
ing EXPRESS schemas into OWL ontologies, so that552
we are able to propose and recommend the required ifc-553
OWL ontology. The following outline is used to docu-554
ment this research.555
Sect. 2 will first outline the key characteristics of556
an EXPRESS schema, providing all the details that557
are relevant to take the conversion decisions.558
Section 3 presents the proposed EXPRESS to559
OWL conversion procedure. This section is sim-560
ilarly detailed to point out also the exceptions to561
the general conversion procedure.562
In Sect. 4, we briefly present our implementa-563
tion(s) of the conversion procedure in executable564
software tools. The focus of this section (and of565
this article) is on the conversion of EXPRESS to566
OWL, i.e. only about the ifcOWL TBox. The sec-567
tion, however, also includes a brief indication of568
how this TBox can be exploited to generate ABox569
Section 5, finally, compares the proposed conver-571
sion procedure with the results of previous propos-572
als, which were only briefly touched in Sect.
2. The structure of EXPRESS574
In this section, we will first look into the key charac-575
teristics and content of an EXPRESS schema. We will576
use the IFC4
ADD1.exp schema [2] as a reference ex-577
ample for this purpose. This brief introduction to EX-578
PRESS will allow to better appreciate the diverse possi-579
ble conversion routines presented in Sect. 3.580
In EXPRESS, a number of declarations can be made.581
A distinction is hereby made between the declarations582
enumerated below.583
TYPE declarations [4, p.38]584
ENTITY declarations [4, p.40]585
SCHEMA declarations [4, p.62]586
CONSTANT declarations [4, p.63]587
ALGORITHM declarations [4, p.64] (cf. FUNCTION588
and PROCEDURE declarations)589
RULE declarations [4, p.72]590
An EXPRESS schema contains exactly one SCHEMA591
declaration that covers the entire file, thereby assign-592
ing the body of this file to the particular schema dec-593
laration. An EXPRESS schema may import definitions594
from other schemas using the REFERENCE FROM key-595
words. The IFC schema is self-contained and there is596
no import of other schemas (see Fragment 1).597
Fragment 1: Printout of the SCHEMA declaration present in
At the end of the IFC4 ADD1.exp schema, there are603
two RULE declarations and 45 FUNCTION declarations,604
which will be briefly covered further on in this section.605
All the other declarations make use of the TYPE and606
ENTITY keywords that represent and reference a num-607
ber of EXPRESS data types. A distinction is hereby608
made between the following data types:609
Simple data types [4, p.20], i.e. NUMBER, REAL,610
Aggregation data types [4, p.23], i.e. ARRAY, LIST,612
Named data types [4, p.28], i.e. entity data types614
and defined data types615
Constructed data types [4, p.29], i.e. enumeration616
data types and select data types617
Generalised data types [4, p.35]618
These data types will be briefly documented in the619
next subsections by following the order they appear in620
an IFC schema and skipping only the generalised data621
types since they are not regularly employed in an IFC622
schema (reference schema IFC4
2.1. Simple data type declarations624
Simple data types (i.e. NUMBER, REAL, INTEGER,625
used in an IFC schema. These data types are referenced627
by the other data type declarations as shown in the fol-628
lowing subsections.629
2.2. Defined (named) data type declarations630
Apart from the simple data type declarations, the de-631
fined (named) data type declarations are the most ba-632
sic elements that are used in an EXPRESS schema.633
These declarations are typically very short statements,634
eventually providing the building blocks used by more635
complex data types in the EXPRESS schema. Di-636
verse defined data types can be found in an IFC EX-637
PRESS schema and most declarations are similar to the638
one given in Fragment 2 (IfcAreaDensityMeasure),639
where a type name is given (e.g. IfcAreaDensity-640
Measure) together with a reference to a simple data641
type (e.g. REAL).642
TYPE IfcAreaDensityMeasure = REAL;644
Fragment 2: Printout of the defined data type declaration IfcArea-
Some defined data type declarations refer to other647
defined data types instead of a simple data type. For648
instance, the data type IfcBoxAlignment (see Frag-649
ment 3) refers to another defined type (i.e. IfcLabel).650
Fragment 3 provides also an example WHERE rule re-651
striction, namely WR1. This is a local rule that only ap-652
plies to the type in which it is declared. In the case of653
Fragment 3, the local rule specifies that the data type654
can be instantiated only using the values provided in the655
TYPE IfcBoxAlignment = IfcLabel;658
WR1 : SELF IN [‘top-left’, ‘top-middle’, ‘top-660
right’, ‘middle-left’, ‘center’, ‘middle-right661
’, ‘bottom-left’, ‘bottom-middle’, ‘bottom-662
TYPE IfcLabel = STRING(255);666
Fragment 3: Example of the defined data type declaration IfcBox-
Alignment, which refers to another defined data type (IfcLabel),
which in turn refers to a simple data type STRING of maximum 255
2.3. Aggregation data type declarations669
Some of the defined data type declarations refer to an670
aggregation data type. These aggregation data types are671
declared locally and can make use of one of the follow-672
ing containers: ARRAY, LIST, BAG, and SET.673
The LIST and ARRAY data types represent an or-674
dered collection of elements, whereas the BAG and SET675
data types represent unordered collections [4, p.23].676
Three examples are given in Fragment 4, namely Ifc-677
CompoundPlaneAngleMeasure, IfcLineIndex, and678
IfcComplexNumber. For each of these examples, car-679
dinality restrictions are declared between brackets. As680
an example, the data type IfcCompoundPlaneAngle-681
Measure is defined as a LIST with minimum 3 and682
maximum 4 INTEGER elements. In addition, it can be683
noticed that the values of these INTEGER elements are684
restricted using WHERE rules.685
TYPE IfcCompoundPlaneAngleMeasure = LIST [3:4] OF687
MinutesInRange : ABS(SELF[2]) < 60;690
SecondsInRange : ABS(SELF[3]) < 60;691
MicrosecondsInRange : (SIZEOF(SELF) = 3) OR (ABS692
(SELF[4]) < 1000000);693
ConsistentSign :694
((SELF[1] >= 0) AND (SELF[2] >= 0) AND (SELF695
[3] >= 0) AND ((SIZEOF(SELF) = 3) OR (SELF696
[4] >= 0)))697
((SELF[1] <= 0) AND (SELF[2] <= 0) AND (SELF699
[3] <= 0) AND ((SIZEOF(SELF) = 3) OR (SELF700
[4] <= 0)));701
TYPE IfcLineIndex = LIST [2:?] OF IfcPositiveInteger704
TYPE IfcComplexNumber = ARRAY [1:2] OF REAL;708
Fragment 4: Example of three data type declarations referring to
aggregation data types (LIST, ARRAY).
The IfcLineIndex in Fragment 4 refers to an or-711
dered LIST of at least 2 elements. No upper boundary712
is declared for the LIST size. The IfcComplexNumber713
type refers to a fixed-size, indexed list (ARRAY). In this714
case, the indices between brackets indicate the “lowest715
and highest index which are valid for an array value of716
this data type” [4, p.24]. Therefore, an instance of Ifc-717
ComplexNumber will be an array of exactly two REAL718
simple data type instances, indexed 1 and 2.719
An appropriate example of a SET aggregation data720
type declaration is available in Fragment 5. In this Frag-721
ment, an ENTITY IfcArbitraryProfileDefWith-722
Voids is declared with one of its attributes (namely723
InnerCurves) pointing towards a SET of IfcCurve724
data types. This SET is an unordered aggregation of dif-725
ferent IfcCurve instances [4, p.27].726
ENTITY IfcArbitraryProfileDefWithVoids728
InnerCurves : SET [1:?] OF IfcCurve;730
Fragment 5: Printout of the IfcArbitraryProfileDefWithVoids
entity data type declaration in EXPRESS including an attribute
declaration that refers to a SET aggregation data type declaration.
The IFC4
ADD1 schema does not include BAG ag-734
gregation data types, so we do not present any example735
here. The definition of a BAG aggregation data type is736
comparable to the definition of a SET aggregation data737
type. A BAG data type can, however, contain the same738
instances more than once, whereas SET data types can739
only contain dierent elements [4, p.26].740
2.4. Constructed data type declarations741
Two types of constructed data types can be de-742
clared in an EXPRESS schema, namely ENUMERATION743
(e.g. IfcDistributionSystemEnum) and SELECT744
(e.g. IfcActorSelect).745
2.4.1. Enumeration data type declarations746
An enumeration data type declaration is identified by747
the keyword ENUMERATION, as shown in Fragment 6.748
Any instantiation of such data type should refer to one749
of the values listed in the enumeration.750
TYPE IfcAddressTypeEnum = ENUMERATION OF752
Fragment 6: Printout of the ENUMERATION data type declaration Ifc-
AddressTypeEnum, whichreferstoalistoftheallowed values within
2.4.2. Select data type declarations760
A select data type declaration is identified by the key-761
word SELECT, as shown in Fragment 7. Any instantia-762
tion of such data type should refer to one instance of the763
listed types or entities. It mustbe noted that a select data764
type declaration might include various other EXPRESS765
data types, including defined (named) data types, other766
select data types, and entity (named) data types. The767
declaration of the IfcMetricValueSelect select data768
type represents an example of such a mixture, since it769
lists one defined (named) data type (i.e. IfcValue)770
and five entity (named) data types (i.e. IfcApplied-771
Value, IfcMeasureWithUnit, IfcReference, Ifc-772
Table, and IfcTimeSeries).773
TYPE IfcMetricValueSelect = SELECT775
Fragment 7: Printout of the SELECT data type declaration Ifc-
MetricValueSelect, which refers to a number of allowed data type
instantiations: IfcAppliedValue, IfcMeasureWithUnit, Ifc-
Reference, IfcTable, IfcTimeSeries, and IfcValue.
2.5. Entity (named) data type declarations784
Entity (named) data type declarations are identified785
by the keyword ENTITY and form most of the content786
of an EXPRESS schema in the case of IFC. An exam-787
ple declaration is given in Fragment 8, namely Ifc-788
BSplineCurve. After the name of the entity data type,789
a specification can be given of the hierarchical struc-790
ture through statements that make use of the keywords791
SUPERTYPE and SUBTYPE. In this case, IfcBSpline-792
Curve is an abstract supertype of IfcBSplineCurve-793
WithKnots, implying that only IfcBSplineCurve-794
WithKnots can be explicitly instantiated (i.e. no Ifc-795
BSplineCurve instances are allowed) while inherit-796
ing all the properties from IfcBSplineCurve. The797
IfcBSplineCurve entity is also a SUBTYPE of Ifc-798
BoundedCurve. An entity data type can have multiple799
supertypes and multiple subtypes [4].800
ENTITY IfcBSplineCurve802
SUBTYPE OF (IfcBoundedCurve);805
Degree : IfcInteger;806
ControlPointsList : LIST [2:?] OF807
CurveForm : IfcBSplineCurveForm;809
ClosedCurve : IfcLogical;810
SelfIntersect : IfcLogical;811
UpperIndexOnControlPoints : IfcInteger := (SIZEOF(813
ControlPointsList) - 1);814
ControlPoints : ARRAY [0:UpperIndexOnControlPoints815
] OF IfcCartesianPoint := IfcListToArray(816
SameDim : SIZEOF(QUERY(Temp <* ControlPointsList |819
Temp.Dim <> ControlPointsList[1].Dim)) = 0;820
Fragment 8: Printout of the entity (named) data type declaration Ifc-
The declaration of the entity attributes follows the823
declaration of the hierarchical structure. It is possible to824
declare explicit, derived, and inverse attributes [4, p.41].825
These attributes are defined exclusively within the scope826
of the entity data type under which they are declared,827
and they establish a relationship with other data types828
that are declared elsewhere in the EXPRESS schema829
(i.e. simple data types, named data types, aggregation830
data types, constructed data types, entity data types).831
It is also possible to refer to two-dimensional aggrega-832
tions, such as the LIST of LIST elements that can be833
found in IFC4
ADD1.exp (cf. the attribute Control-834
PointsList of entity IfcBSplineSurface).835
A specific kind of attribute that can be defined for836
an entity data type is a derived attribute, identified by837
the keyword DERIVE. These are typically attributes that838
can be derived from the other entity data type attributes839
through simple rules or more complex routines. In the840
case of the ControlPoints attribute in Fragment 8, for841
instance, a reference is made to the declared FUNCTION842
IfcListToArray() in order to calculate the value of843
the ControlPoints attribute.844
A second example of an entity data type declaration845
is given in Fragment 9 for IfcObject. This Fragment846
shows the usage of the OPTIONAL keyword, implying847
that all attributes without this annotation are required at-848
tributes in the definition of an instance of such an entity849
data type.850
ENTITY IfcObject852
SUBTYPE OF (IfcObjectDefinition);860
ObjectType : OPTIONAL IfcLabel;861
IsDeclaredBy : SET [0:1] OF IfcRelDefinesByObject863
FOR RelatedObjects;864
Declares : SET [0:?] OF IfcRelDefinesByObject FOR865
IsTypedBy : SET [0:1] OF IfcRelDefinesByType FOR867
IsDefinedBy : SET [0:?] OF869
IfcRelDefinesByProperties FOR RelatedObjects;870
UniquePropertySetNames : IfcUniqueDefinitionNames(872
Fragment 9: Printout of the entity (named) data type declaration Ifc-
Furthermore, Fragment 9 shows the usage of in-876
verse attributes with the keyword INVERSE. Any such877
INVERSE statement declares an attribute that is inverse878
to an attribute that has been declared elsewhere and in879
the opposite direction. In the case of the IsDeclaredBy880
attribute in Fragment 9, for example, the attribute going881
in the inverse direction can be found in Fragment 10,882
namely the RelatedObjects attribute of the IfcRel-883
DefinesByObject entity data type. Finally, the usage884
of local WHERE rule declarations within an entity data885
type declaration is also displayed in Fragment 9.886
ENTITY IfcRelDefinesByObject888
SUBTYPE OF (IfcRelDefines);889
RelatedObjects : SET [1:?] OF IfcObject;890
RelatingObject : IfcObject;891
Fragment 10: Printout of the entity (named) data type declaration
2.6. FUNCTION declarations894
The IFC4
ADD1.exp schema includes 45 FUNCTION895
declarations with a variable level of complexity. Frag-896
ment 11 shows a simple example FUNCTION declara-897
tion that is used in the declarations of the IfcElement-898
Quantity and IfcPhysicalComplexQuantity entity899
data types. The FUNCTION IfcUniqueQuantityNames900
defines (1) what input data it expects, namely a set of901
IfcPhysicalQuantity instances, and (2) what output902
it generates, namely one simple LOGICAL data type in-903
stance. The calculation from input data to output data is904
given in the body of the FUNCTION declaration. In the905
case of the IfcUniqueQuantityNames, the number of906
elements in the argument is counted and the result is re-907
FUNCTION IfcUniqueQuantityNames910
(Properties : SET [1:?] OF IfcPhysicalQuantity)911
Names : SET OF IfcLabel := [];915
REPEAT i:=1 TO HIINDEX(Properties);918
Names := Names + Properties[i].Name;919
RETURN (SIZEOF(Names) = SIZEOF(Properties));921
Fragment 11: Printout of the FUNCTION declaration IfcUnique-
2.7. RULE declarations924
The EXPRESS language allows the declaration of925
rules that “permit the definition of constraintsthat apply926
collectively to the entire domain of an entity data type,927
or to instances of more than one entity data type. [4].928
As an example, Fragment 12 shows one of the two RULE929
declarations made in the IFC4
ADD1.exp schema. The930
head of this RULE declaration indicates which entity data931
types are aected (i.e. IfcProject), whereas the body932
of the declaration indicates what restrictions apply to933
these entity data types (i.e. the number of IfcProject934
instances in a model may not be larger than one).935
RULE IfcSingleProjectInstance937
FOR (IfcProject);938
WR1 : SIZEOF(IfcProject) <= 1;941
Fragment 12: Printout of the RULE declaration IfcSingleProject-
3. The EXPRESS to OWL conversion pattern944
This section presents the proposed EXPRESS to945
OWL conversion pattern that can be used to generate an946
ifcOWL ontology. We will outline a reasonable number947
of conversion options whenever they are available and948
relevant in the overall conversion strategy. Section 5949
will summarise a comparison of the dierent conversion950
patterns available in the literature. The structure of the951
previous section will be followed by matching the EX-952
PRESS declaration examples (Fragments 1 to 12) with953
corresponding OWL declarations (Fragments 13 to 43)954
using the Turtle syntax [12].955
3.1. OWL header956
We propose to adopt a unique URI (namespace)957
for each ifcOWL ontology corresponding to a distinct958
EXPRESS schema of IFC. Currently, this results959
in four URIs for IFC2X3.exp, IFC2X3
IFC4RC4.exp, and IFC4
ADD1.exp, respectively.961
We propose to use the following URI design962
for these ontologies: http://www.building-963[schemaName], with964
[schemaName] being one of the four schema names.965
Fragment 13 shows what this results in OWL together966
with a few Dublin Core (dce) metadata annotations967
added to the ontology declaration, indicating details968
about the origins of the OWL ontology. The vann969
metadata annotations indicate preferred namespace URI970
and namespace prefix, and the cc:license property971
indicates which license is associated to the ontology.972
rdf:type owl:Ontology ;975
dce:creator "Pieter Pauwels (pipauwel.976" ;977
dce:creator "Walter Terkaj (walter.terkaj@itia.cnr978
.it)" ;979
dce:date "2015/07/30" ;980
dce:contributor "Aleksandra Sojic (aleksandra.981" ;982
dce:title "IFC4_ADD1" ;983
dce:description "OWL ontology for the IFC4_ADD1984
conceptual data schema and exchange file format985
for Building Information Model (BIM) data" ;986
dce:format "ttl" ;987
dce:identifier "IFC4_ADD1" ;988
dce:language "en" ;989
vann:preferredNamespacePrefix "ifc" ;990
vann:preferredNamespaceUri "http://www.991" ;992
cc:license <
/3.0/> .994
Fragment 13: Definition of the ifcOWL ontology.
Alternatively, one could decide to use one version-996
independent URI for the ifcOWL ontology. Such a URI997
would then correspond to an equivalent ifcOWL names-998
pace that is used as base URI for the definition of the key999
ontology entities (i.e. classes, object properties and data1000
properties). In this case, the ifcOWL namespace would1001
not change in time when the ifcOWL is updated after a1002
new release of the IFC standard, thus supporting back-1003
ward compatibility and re-use of data sets generated ac-1004
cording to previous IFC releases. In this case, the piece1005
of information about the specific IFC release that was1006
used to generate the ifcOWL ontology can be stored us-1007
ing an additional annotation owl:versionIRI.1008
In theory, the IFC schema in EXPRESS is back-1009
ward compatible, thus the version-independent alterna-1010
tive should be implementable. However, as the IFC1011
schema changes quite a lot from version to version,1012
this backward compatibility is hard to securely main-1013
tain using only OWL constructs in one singular ifcOWL1014
namespace. Therefore, we decided to opt for separate1015
namespaces for the ontology URI (one namespace for1016
each IFC schema). To ensure backward compatibility,1017
one could add relations between the (four) dierent ifc-1018
OWL ontologies afterwards. This will likely allow a1019
safer implementation of the backward compatibility.1020
At the outset of any OWLontology, a number of other1021
ontologies are referenced, thereby declaring the appro-1022
priate prefixes. In the proposed ifcOWL ontology, the1023
namespace prefixes listed in Fragment 14 are declared.1024
We recommend the usage of a separate namespace for1025
classes and properties that are specific to EXPRESS,1026
namely This1027
was also proposed by Hoang [46], Hoang and T
[47]. In this namespace, we can put ‘helper’ class and1029
property declarations that are not specific to IFC, but1030
rather to EXPRESS itself. We will see examples of how1031
this separate namespace is used in the following sub-1032
@base <
IFC4_ADD1> .1036
@prefix : <
IFC4_ADD1#> .1038
@prefix ifc: <
ifcOWL/IFC4_ADD1#> .1040
@prefix xsd: <> .1041
@prefix owl: <> .1042
@prefix rdfs: <
#> .1044
@prefix dce: <> .1045
@prefix rdf: <
syntax-ns#> .1047
@prefix vann: <> .1048
@prefix cc: <> .1049
@prefix express: <> .1050
Fragment 14: Printout of the ontologies that are used by the proposed
ifcOWL ontology.
3.2. Simple data type declarations1052
The notion of a data type in EXPRESS is consid-1053
erably dierent from a data type in OWL, since all1054
declarations made in EXPRESS are data type decla-1055
rations. In OWL, however, a distinction is made be-1056
tween owl:Class and rdfs:Datatype declarations.1057
In other words, the EXPRESS data type declarations1058
could map both to owl:Class and rdfs:Datatype1059
declarations in OWL, depending on which kind of EX-1060
PRESS data type isconsidered. For example, the simple1061
data type declaration STRING would map very well to1062
the xsd:string data type in OWL. On the other hand,1063
the entity data type declaration given in Fragment 91064
maps far more naturally to an owl:Class declaration1065
in OWL. This is a conversion decision that should be1066
well-considered, as it has many implications further on1067
in using the RDF instances according to the ifcOWL on-1068
In the case ofthe simple datatype declarations in EX-1070
PRESS (e.g. REAL, INTEGER, and so forth), these can be1071
converted to OWL data type or class declarations. Frag-1072
ments 15 and 16 give an example of both options for the1073
case of the simple data type REAL.1074
rdf:type rdfs:Datatype ;1077
owl:equivalentClass xsd:double .1078
Fragment 15: Printout of the RDF graph representation for one of
the simple data types (REAL) in the ifcOWL schema, illustrating the
option to convert it into an rdfs:Datatype.
rdf:type owl:Class ;1082
rdf:type owl:Restriction ;1085
owl:allValuesFrom xsd:double ;1086
owl:onProperty express:hasDouble1087
] .1088
Fragment 16: Printout of the RDF graph representation for one of
the simple data types (REAL) in the ifcOWL schema, illustrating the
option to convert it into an owl:Class.
If the rdfs:Datatype conversion option is adopted1090
(see Fragment 15), then an instance of an EXPRESS1091
simple data type (e.g. REAL) is converted to an RDF1092
typed literal (e.g. xsd:double). If the owl:Class con-1093
version option (see Fragment 16) is chosen, then an in-1094
stance of an EXPRESS simple data type is converted1095
to an individual of a class (e.g. express:REAL) and1096
this individual is in turn linked to an RDF typed lit-1097
eral via a functional owl:DatatypeProperty. The re-1098
quired owl:DatatypeProperty must be properly de-1099
clared by defining its domain, range and label (e.g.1100
see Fragment 17 for express:hasDouble). Note that1101
the rdfs:Datatype or owl:Class express:REAL1102
and the property hasDouble are declared within the1103
express namespace, as they are not concepts com-1104
ing from IFC, but from EXPRESS. Such concepts are1105
placed in a separate namespace, in order to be able to1106
distinguish them from the concepts specific to IFC, but1107
also to allow reuse of such concepts in OWL ontolo-1108
gies for EXPRESS schemas other than IFC. The domain1109
declaration is done in the form of an owl:unionOf con-1110
struct, because, in some cases, several EXPRESS sim-1111
ple data types (e.g. REAL and NUMBER) map to the same1112
xsd datatype (xsd:double). An overview of the pro-1113
posed mapping between the simple data types in EX-1114
PRESS and the XSD data types in OWL is given in Ta-1115
ble 1.1116
rdf:type owl:DatatypeProperty ;1119
rdf:type owl:FunctionalProperty ;1120
rdfs:label "hasDouble" ;1121
rdf:type owl:Class ;1124
owl:unionOf ( express:REAL express:NUMBER )1125
] ;1126
rdfs:range xsd:double .1127
Fragment 17: Printout of the RDF graph representation of the
express:hasDouble datatype property as it would be required in
combination with the owl:Class declaration given in Fragment 16.
NUMBER xsd:double
REAL xsd:double
INTEGER xsd:integer
LOGICAL xsd:boolean
BOOLEAN xsd:boolean
STRING xsd:string
BINARY xsd:hexBinary
Table 1: Overview of the simple data types defined in EXPRESS and
the corresponding XSD datatypes used in OWL.
If a conversion routine via an owl:Class decla-1129
ration and an accompanying owl:DatatypeProper-1130
ty is adopted, then an extra restriction with universal1131
quantifier (owl:allValuesFrom) can be added to the1132
owl:Class declaration for the corresponding datatype1133
property. An example of such a restriction can be seen1134
in Fragment 16 for the property express:hasDouble.1135
Table 1 includes one peculiar element, namely the1136
simple data type LOGICAL. This simple data type is1137
similar to the BOOLEAN simple data type, except that1138
it can have three values instead of two: TRUE, FALSE,1139
and UNKNOWN. There is no XSD data type that has these1140
three values. This is normal, because, setting this third1141
value would actually make little sense in the (semantic)1142
web domain. Namely, the OWA states exactly that any-1143
thing that is not set is by default UNKNOWN. Hence, it is1144
possible to consider this LOGICAL data type as equal to1145
BOOLEAN, as is also proposed in Table 1. Whenever an1146
IFC file happens to include this UNKNOWN value, it can1147
simply be discarded. We have opted for this option in1148
our proposal, as this stays true to the original EXPRESS1149
schema and makes good sense in the OWA of OWL21150
Alternatively, the LOGICAL simple data type1152
could be explicitly converted into a separate1153
OWL class that enumerates the three named in-1154
dividuals express:TRUE, express:FALSE, and1155
express:UNKNOWN (see Fragment 18). This can be1156
further constrained by adding an owl:oneOf constraint1157
to the express:LOGICAL class, which indicates that1158
the express:LOGICAL class contains exactly the three1159
given individuals express:TRUE, express:FALSE,1160
and express:UNKNOWN.1161
rdf:type owl:Class ;1164
rdf:type owl:Class ;1167
] .1174
rdf:type express:LOGICAL ;1177
rdf:type owl:NamedIndividual .1178
rdf:type express:LOGICAL ;1181
rdf:type owl:NamedIndividual .1182
rdf:type express:LOGICAL ;1185
rdf:type owl:NamedIndividual .1186
Fragment 18: Printout of the RDF graph representation of the
express:LOGICAL class and its three named individuals.
In summary, for EXPRESS simple data types, we can1188
distinguish the conversion options that are listed in Ta-1189
ble 2. Option 1 was documented in Fragment 15. In1190
this option, a LOGICAL will have to be converted into a1191
datatype that is equivalent to xsd:boolean. Option 21192
was documented in Fragment 16 and 17, with LOGICAL1193
eventually pointing again to the xsd:boolean. Op-1194
tion 3 was documented in Fragment 16 and 17, with1195
LOGICAL exceptionally converted as in Fragment 18.1196
Herein we propose to follow option 2.1197
option 1 rdfs:Datatype LOGICAL
same as BOOLEAN
option 2 owl:Class
(incl. unionOf)
same as BOOLEAN
option 3 owl:Class
(incl. unionOf)
Table 2: Overview of the key available conversion options for simple
data types, with the proposed option marked in grey background.
3.3. Defined (named) data type declarations1198
As shown in Fragment 2 and 3, a defined (named)1199
data type declaration in EXPRESS can refer either to1200
a simple data type or to another defined (named) data1201
type. The conversion of these defined (named) data type1202
declarations thus depends in part on the way in which1203
simple data types are converted, as rdfs:Datatype1204
declarations or as owl:Class declarations. Both con-1205
version options are given for the IfcAreaDensity-1206
Measure declaration in Fragments 19 and 20, respec-1207
tively. These conversion options can also be used for1208
the conversion of defined (named) data type declara-1209
tions that refer to other defined (named) data types, such1210
as IfcBoxAlignment (Fragment 3).1211
rdf:type rdfs:Datatype ;1214
owl:equivalentClass express:REAL .1215
Fragment 19: Printout of the RDF graph representation for the Ifc-
AreaDensityMeasure defined in Fragment 2, when converting an
EXPRESS simple data type to an rdfs:Datatype declaration.
rdf:type owl:Class ;1219
rdfs:subClassOf express:REAL .1220
Fragment 20: Printout of the RDF graph representation for the Ifc-
AreaDensityMeasure defined in Fragment 2, when converting an
EXPRESS simple data type to an owl:Class declaration.
Herein we decided to choose the owl:Class conver-1222
sion option (see Fragments 16 and 20) because, even1223
if it leads to an overhead in terms of triples in an RDF1224
graph, this is the only solution that guarantees a safe1225
conversion from EXPRESS to OWL, as it will be better1226
explained in Sect.
3.4. Aggregation data type declarations1228
In the following subsections we present the conver-1229
sion pattern for aggregation data types (i.e. BAG, LIST,1230
SET, ARRAY), while referring to the relevant EXPRESS1231
declaration examples given before (i.e. IfcCompound-1232
PlaneAngleMeasure, IfcLineIndex, IfcComplex-1233
Number, and the InnerCurves attribute of IfcArbi-1234
traryProfileDefWithVoids). The BAG data type1235
does not appear in the IFC4
ADD1 schema, so we de-1236
cided not to devote a separate section on the conversion1237
of this aggregation data type. If necessary, the general-1238
purpose conversion pattern for BAG proposed by Barbau1239
et al. [24] can be adopted.1240
3.4.1. LIST aggregation data types1241
Lists (or any kind of ordered sequence) cannot be eas-1242
ily represented in an RDF graph, because RDF relies on1243
a triple structure that inherently allows to link only two1244
concepts, not collections of multiple concepts (Fig. 1).1245
Lists are thus typically represented in RDF by linking1246
each concept to the next using rdf:List, rdf:first1247
and rdf:rest declarations (see [14] and [48]). When1248
using this construct in an OWL ontology, however, the1249
ontology goes beyond OWL2 DL expressiveness (see1250
Fig. 2), thus impeding the use of generally available se-1251
mantic web tools. This would violate the first criterion1252
that we have set in Sect. 1.3.4 (i.e. to keep ifcOWL in1253
OWL2 DL). Therefore, this conversion routine is not a1254
viable option.1255
There have been suggestions to represent ordered lists1256
in a fashion alternative to the rdf:List, rdf:first1257
and rdf:rest declarations [48]. Most of these alterna-1258
tive suggestions rely on additional statements that cor-1259
rectly define the relations between the elements of a1260
list to remain in OWL2 DL expressiveness, so that the1261
first conversion criterion can be met. Herein, our sug-1262
gested solution relies on the class express:List to1263
represent the list elements as proposed by Drummond1264
et al. [48]. Each element of the list is related to the1265
following element in the list by using the object prop-1266
erty express:hasNext, that is a sub-property of the1267
transitive property express:isFollowedBy. Finally,1268
each list element is linked with its actual content via the1269
object property express:hasContents. These defi-1270
nitions (see Fragment 21) are declared in the express1271
namespace so that they can be used in other ontologies1272
in dierent contexts, since they are not specific to IFC1273
but rather to EXPRESS.1274
rdf:type owl:Class ;1277
rdf:type owl:Restriction ;1280
owl:onProperty express:isFollowedBy ;1281
owl:allValuesFrom express:List1282
] ,1283
rdf:type owl:Restriction ;1285
owl:onProperty express:hasNext ;1286
owl:allValuesFrom express:List1287
] .1288
rdf:type owl:ObjectProperty ;1291
rdf:type owl:FunctionalProperty ;1292
rdfs:label "hasContents" ;1293
rdfs:domain express:List .1294
rdf:type owl:ObjectProperty ;1297
rdf:type owl:TransitiveProperty ;1298
rdfs:label "isFollowedBy" ;1299
rdfs:range express:List ;1300
rdfs:domain express:List .1301
rdf:type owl:ObjectProperty ;1304
rdf:type owl:FunctionalProperty ;1305
rdfs:label "hasNext" ;1306
rdfs:range express:List ;1307
rdfs:domain express:List ;1308
rdfs:subPropertyOf express:isFollowedBy .1309
Fragment 21: Printout of the additional OWL statements that allow to
represent ordered lists, including theexpress:List class declaration
and the three object property declarations express:hasContents,
express:hasNext, and express:isFollowedBy.
In order to be fully compliant with the list proposal1311
by Drummond et al. [48], one could also include an1312
express:EmptyList class declaration, as shown in1313
Fragment 22. Instances of this class, which is de-1314
clared as a subclass of express:List, can then be used1315
to mark the end of the list. We did not include this1316
express:EmptyList in our proposal, as it does not1317
seem to bring much added value.1318
rdf:type owl:Class ;1321
rdfs:subClassOf express:List ;1322
rdf:type owl:Restriction ;1325
owl:onProperty express:hasContents ;1326
owl:maxQualifiedCardinality "0"^^xsd:1327
nonNegativeInteger ;1328
] ,1329
rdf:type owl:Restriction ;1331
owl:onProperty express:hasNext ;1332
owl:maxQualifiedCardinality "0"^^xsd:1333
nonNegativeInteger ;1334
] .1335
Fragment 22: Printout of the express:EmptyList class declaration
that could be added to the statements in Fragment 21 in order to be
fully compliant with Drummond et al. [48].
Any specific ordered list can be defined as a sub-1337
class of express:List while specialising the rele-1338
vant restrictions. Fragment 23 shows how the class1339
List is used to define an item1340
in a list of INTEGER instances, while restrictions are1341
used on object properties express:hasContents and1342
express:hasNext to specify that the content of the list1343
item must be an INTEGER instance and the next item1344
in the list must be an INTEGER
List instance, respec-1345
tively. All these class declarations are declared within1346
the express namespace.1347
rdf:type owl:Class ;1350
rdfs:subClassOf express:List ;1351
rdf:type owl:Restriction ;1354
owl:onProperty express:hasContents ;1355
owl:allValuesFrom express:INTEGER1356
] ;1357
rdf:type owl:Restriction ;1360
owl:onProperty express:hasContents ;1361
owl:someValuesFrom express:INTEGER1362
] ;1363
rdf:type owl:Restriction ;1366
owl:onProperty express:isFollowedBy ;1367
owl:allValuesFrom express:INTEGER_List1368
] ;1369
rdf:type owl:Restriction ;1372
owl:onProperty express:hasNext ;1373
owl:allValuesFrom express:INTEGER_List1374
] .1375
Fragment 23: Printout of the RDF graph representation for class
List, which relies on the definitions presented earlier in
Fragment 21.
IfcCompoundPlaneAngleMeasure is defined as a1377
list of INTEGER instances (see Fragment 4) and, there-1378
fore, it is converted as a subclass of express:INTE-1379
List (see Fragment 24).1380
rdf:type owl:Class ;1383
rdfs:subClassOf express:INTEGER_List ;1384
Fragment 24: Printout of the RDF graph representation for the Ifc-
CompoundPlaneAngleMeasure defined data type, which refers to
a LIST aggregation data type declaration, as displayed earlier in
Fragment 4.
The size limits of aggregation data types can be1386
bounded or unbounded. For instance, IfcCompound-1387
PlaneAngleMeasure has a lower bound equal to three1388
and an upper bound equal to four, whereas IfcLine-1389
Index has a lower bound equal to two and an un-1390
bounded upper limit. The constraints on the size of1391
the list could be well defined via cardinality restric-1392
tions (owl:maxQualifiedCardinality, owl:min-1393
QualifiedCardinality, or owl:qualifiedCardi-1394
nality) on the transitive object property express:is-1395
FollowedBy, as shown in Fragment 25 for IfcCom-1396
poundPlaneAngleMeasure. Because the cardinality1397
restrictions are set on the transitive object property1398
express:isFollowedBy, one should only start count-1399
ing after the first instance of express:List. As a result,1400
if an EXPRESS LIST has at least three elements and1401
at most four elements, it means that that first instance1402
of express:List is followed by at least two instances of1403
express:List and at most three instances of express:List.1404
rdf:type owl:Class ;1407
rdfs:subClassOf express:INTEGER_List ;1408
rdf:type owl:Restriction ;1411
owl:maxQualifiedCardinality "3"^^xsd:1412
nonNegativeInteger ;1413
owl:onClass express:INTEGER_List ;1414
owl:onProperty express:isFollowedBy1415
] ;1416
rdf:type owl:Restriction ;1419
owl:minQualifiedCardinality "2"^^xsd:1420
nonNegativeInteger ;1421
owl:onClass express:INTEGER_List ;1422
owl:onProperty express:isFollowedBy1423
] .1424
Fragment 25: Printout of the RDF graph representation for the Ifc-
CompoundPlaneAngleMeasure defined data type, which refers to an
aggregation data type, as displayed earlier in Fragment 4.
However, the declaration of a cardinality restriction1426
on a transitive object property would cause ifcOWL to1427
be outside of OWL2 DL expressiveness [49, Sect.8.2],1428
again violating our first criterion. An alternative way1429
in which cardinality restrictions for EXPRESS LISTs1430
might by expressed, is given in Fragment 26. In this1431
proposal, cardinality restrictions are not set on the tran-1432
sitive property express:isFollowedBy, but instead,1433
universal (owl:allValuesFrom) and existential quan-1434
tifiers (owl:someValuesFrom) are used together with1435
the non-transitive property express:hasNext, which1436
is allowed in OWL2 DL and which allows to indirectly1437
set the maximum and minimum cardinality constraints1438
defined in EXPRESS schemas. The number of nested1439
restrictions that is added depends on the cardinality that1440
needs to be set. In the case of IfcCompoundPlane-1441
AngleMeasure, three universal quantifiers are added1442
(see Fragment 26) to specify that the fourth item in the1443
list (express:INTEGER
List) cannot be followed by1444
another item by using an owl:qualifiedCardinal-1445
ity of 0. Furthermore, two existential quantifiers are1446
used in Fragment 26 to define a restriction on prop-1447
erty express:hasNext specifying that the first list1448
item must be followed by an express:INTEGER
instance, which in turn must be followed by another1450
express:INTEGER List instance.1451
rdf:type owl:Class ;1454
rdfs:subClassOf express:INTEGER_List ,1455
rdf:type owl:Restriction ;1457
owl:onProperty express:hasNext ;1458
rdf:type owl:Restriction ;1461
owl:onProperty express:hasNext ;1462
rdf:type owl:Restriction ;1465
owl:onProperty express:hasNext ;1466
rdf:type owl:Restriction ;1469
owl:onProperty express:hasNext ;1470
owl:onClass express:INTEGER_List ;1471
owl:qualifiedCardinality "0"^^xsd:1472
] ,1477
rdf:type owl:Restriction ;1479
owl:onProperty express:hasNext ;1480
rdf:type owl:Restriction ;1483
owl:onProperty express:hasNext ;1484
owl:someValuesFrom express:INTEGER_List1485
] .1487
Fragment 26: Alternative definition of cardinality restrictions on
LIST classes, using a specific number of universal (owl:allValues-
From) and existential quantifiers (owl:someValuesFrom) on the
non-transitive property express:hasNext.
The proposal in Fragment 26 can be generalised to1489
constrain the list size for any data type (e.g. DTypeX)1490
defined as a LIST aggregation of another data type (e.g.1491
DTypeY). The pseudocode of Algorithm 1 (see function1492
ListMinSize) can be used to generate a restriction for1493
the minimum list size (MinSize) if it is greater than one,1494
whereas Algorithm 2 (see function ListMaxSize) gener-1495
ates a restriction for the maximum list size (MaxSize) if1496
it is greater than one and not unbounded. If the min-1497
imum and maximum size are equal (Size), then Algo-1498
rithm 3 (see function ListExactSize) can be employed1499
instead of Algorithms 1 and 2.1500
Algorithm 1 Generation of a restriction to constrain the
minimum size of a LIST aggregation data type.
1: function ListMinSize(DTypeX,DTypeY,MinSize)
2: print DTypeX, “ rdfs:subClassOf”
3: GenRestrMinSize(DTypeY,MinSize)
4: print “.
5: end function
6: function GenRestrMinSize(DTypeY,MinSize)
7: if (MinSize-2) >0 then
8: for i=1 to (MinSize-2) do
9: print “[ ”
10: print “rdf:type owl:Restriction ;”
11: print “owl:onProperty express:hasNext ;”
12: print “owl:someValuesFrom ”
13: end for
14: end if
15: print “[”
16: print “rdf:type owl:Restriction ;”
17: print “owl:onProperty express:hasNext ;”
18: print “owl:someValuesFrom ”, DTypeY, “
19: print “]”
20: if (MinSize-2) >0 then
21: for i=1 to (MinSize-2) do
22: print “]”
23: end for
24: end if
25: end function
Algorithm 2 Generation of a restriction to constrain the
maximum size of a LIST aggregation data type.
1: function ListMaxSize(DTypeX,DTypeY,MaxSize)
2: print DTypeX, “ rdfs:subClassOf”
3: GenRestrMaxSize(DTypeY,MaxSize)
4: print “.
5: end function
6: function GenRestrMaxSize(DTypeY,MaxS ize)
7: if (MaxS ize-1) >0 then
8: for i=1 to (MaxSize-1) do
9: print “[ ”
10: print “rdf:type owl:Restriction ;”
11: print “owl:onProperty express:hasNext ;”
12: print “owl:allValuesFrom ”
13: end for
14: end if
15: print “[”
16: print “rdf:type owl:Restriction ;”
17: print “owl:onProperty express:hasNext ;”
18: print “owl:onClass ”, DTypeY, “
List ;”
19: print
“owl:qualifiedCardinality “0”ˆˆxsd:nonNegativeInteger”
20: print “]”
21: if (MaxS ize-1) >0 then
22: for i=1 to (MaxSize-1) do
23: print “]”
24: end for
25: end if
26: end function
The presented conversion procedure for an EX-1501
PRESS LIST is not ideal or highly performing. As out-1502
lined in Pauwels et al. [50] and de Farias et al. [51],1503
more elegant options are available by replacing the ver-1504
Algorithm 3 Generation of a restriction to constrain the
exact size of a LIST aggregation data type.
1: function ListExactSize(DTypeX,DTypeY,Size)
2: print DTypeX, “ rdfs:subClassOf”
3: GenRestrExactSize(DTypeY,Size)
4: print “.
5: end function
6: function GenRestrExactSize(DTypeY,S ize)
7: if (Size-1) >0 then
8: for i=1 to (Size-1) do
9: print “[ ”
10: print “rdf:type owl:Restriction ;”
11: print “owl:onProperty express:hasNext ;”
12: print “owl:someValuesFrom ”
13: end for
14: end if
15: print “[”
16: print “rdf:type owl:Restriction ;”
17: print “owl:onProperty express:hasNext ;”
18: print “owl:onClass ”, DTypeY, “ List ;”
19: print
“owl:qualifiedCardinality “0”ˆˆxsd:nonNegativeInteger”
20: print “]”
21: if (Size-1) >0 then
22: for i=1 to (Size-1) do
23: print “]”
24: end for
25: end if
26: end function
bose and complex LIST constructs with (1) semantically1505
more meaningful and more direct object properties or1506
(2) using datatype properties pointing to Well-Known1507
Text (WKT) values. Examples of these two alternative1508
approaches can be found in Pauwels et al. [50]. Because1509
they cannot be generally applied and they diverge from1510
the original EXPRESS schema, however, these alterna-1511
tives are not appropriate options for the general purpose1512
ifcOWL ontology targeted in this article. In our pro-1513
posal, we therefore chose to adopt the definition given1514
in Fragment 26, which is as rich as the original EX-1515
PRESS representation and remains in OWL2 DL, and1516
thus fits best to our conversion criteria.1517
3.4.2. ARRAY aggregation data types1518
ARRAY data type declarations (see IfcComplexNum-1519
ber in Fragment 4) are not much dierent from LIST1520
data type declarations, the one dierence being that an1521
ARRAY is fixed in size whereas a LIST is not fixed in1522
size [4, p.24]. We propose to use the conversion routine1523
for LIST data type declarations also for ARRAY data type1524
declarations (see Fragment 27), adding also a restriction1525
to set the size of the array. Such restriction can be gen-1526
erated by exploiting the pseudocode in Algorithm 3.1527
rdf:type owl:Class ;1530
rdfs:subClassOf express:REAL_List ;1531
rdf:type owl:Restriction ;1534
owl:onProperty express:hasNext ;1535
rdf:type owl:Restriction ;1538
owl:onProperty express:hasNext ;1539
owl:onClass express:REAL_List ;1540
owl:qualifiedCardinality "0"^^xsd:1541
] .1544
Fragment 27: Printout of the RDF graph representation for the
IfcComplexNumber defined data type, which refers to an ARRAY
aggregation data type declaration, as displayed earlier in Fragment 4.
3.4.3. SET aggregation data types1546
The SET aggregation data types are unordered ag-1547
gregations of instances that are supposed to be dier-1548
ent from each other [4, p.27]. This is naturally repre-1549
sented in OWL through a common non-functional ob-1550
ject property that can be assigned an unlimited number1551
of times to the same instance. Cardinality restrictions1552
for this non-functional property allow to represent pos-1553
sible constraints on the size of the set, as defined in the1554
EXPRESS schema. An example of how this can be con-1555
verted is given in Fragment 28 for the IfcArbitrary-1556
ProfileDefWithVoids entity data type declaration1557
given earlier in Fragment 5.1558
rdf:type owl:Restriction ;1564
owl:minQualifiedCardinality "1"^^xsd:1565
nonNegativeInteger ;1566
owl:onClass ifc:IfcCurve ;1567
owl:onProperty ifc:InnerCurves1568
] ;1569
rdf:type owl:Restriction ;1572
owl:allValuesFrom ifc:IfcCurve ;1573
owl:onProperty ifc:InnerCurves1574
] .1575
Fragment 28: Partial printout of the owl:Class declaration for the
IfcArbitraryProfileDefWithVoids entity data type declaration
displayed in Fragment 5, including a cardinality restriction on the
minimum size of the set (cf. SET[1:?] of IfcCurve).
The SET aggregation data type declaration in Frag-1577
ment 5 can be represented as in Fragment 28 because1578
it is declared within an EXPRESS attribute declara-1579
tion. This attribute declaration maps well to an OWL1580
property declaration for which value and cardinality re-1581
strictions can be declared (see Sect. 3.6 for further de-1582
tails). However, in the IFC4
ADD1 schema, the SET1583
aggregation data type is also used in the declaration of1584
the defined data type IfcPropertySetDefinition-1585
Set. Unfortunately, in this case, no attribute is in-1586
volved and, therefore, it is not possible to convert the re-1587
lation between IfcPropertySetDefinitionSet and1588
IfcPropertySetDefinition by means of a restric-1589
tion on a non-functional OWL object property that1590
maps an attribute declaration (since no such property1591
is available). The best possibility to cope with this1592
one case is likely to modify the original IFC schema1593
in EXPRESS and replace the defined data type Ifc-1594
PropertySetDefinitionSet with an attribute decla-1595
ration that points to a SET of specific EXPRESS data1596
types. This would allow to use the conversion proce-1597
dure just explained, using non-functional OWL object1598
As such a modification of the EXPRESS schema1600
lies beyond our capacities, however, we propose to1601
convert this exception as displayed in Fragment 29,1602
namely by defining IfcPropertySetDefinition-1603
Set as an owl:Class with a universal restriction1604
(owl:allValuesFrom) on the predefined object prop-1605
erty express:hasSet. This object property is not di-1606
rectly converted from the EXPRESS schema and, there-1607
fore, it represents an overhead that is required to cope1608
with the misalignment between EXPRESS and OWL.1609
The constraint on the minimum size of the SET is con-1610
verted using an owl:minQualifiedCardinality re-1611
striction (see Fragment 29).1612
rdf:type owl:Class ;1615
rdf:type owl:Restriction ;1618
owl:allValuesFrom ifc:IfcPropertySetDefinition1619
owl:onProperty express:hasSet1621
] ;1622
rdf:type owl:Restriction ;1625
owl:minQualifiedCardinality "1"^^xsd:1626
nonNegativeInteger ;1627
owl:onProperty express:hasSet ;1628
owl:onClass ifc:IfcPropertySetDefinition1629
] .1630
Fragment 29: Printout of the RDF graph representation for the Ifc-
PropertySetDefinitionSet defined data type, which refers to a
SET aggregation data type in EXPRESS.
3.5. Constructed data type declarations1632
The ENUMERATION data type and SELECT data type1633
declarations are quite peculiar of the EXPRESS lan-1634
guage and have no immediate equivalent in OWL.1635
These data types could be converted into owl:Class1636
or rdfs:Datatype declarations. We propose to choose1637
the owl:Class option, as the followingsubsections will1638
3.5.1. Enumeration data type declarations1640
A first conversion option (option 1) consists in con-1641
verting any ENUMERATION data type into an owl:Class1642
that is equivalent to one of a limited set of named1643
individuals (owl:NamedIndividual), each individual1644
representing one enumeration item. Therefore, the1645
ENUMERATION data type declaration of IfcAddress-1646
TypeEnum given earlier in Fragment 6 is converted into1647
the representation reported in Fragment 30.1648
rdf:type owl:Class ;1651
rdf:type owl:Class ;1654
] ;1663
rdfs:subClassOf express:ENUMERATION .1664
Fragment 30: Printout of the RDF graph representation for the
IfcAddressTypeEnum enumeration data type declaration displayed
earlier in Fragment 6.
Since the enumeration items are defined within the1666
scope of the ENUMERATION, it may happen that the same1667
name is used for items belonging to dierent enumer-1668
ations. Because an owl:NamedIndividual does not1669
have such a local scope, ambiguity might occur and re-1670
sult in inconsistencies. Therefore, while converting the1671
enumeration to an owl:Class, we propose to uniquely1672
name its set of named individuals by adding a sux ac-1673
cording to the following naming convention: [NameOf-1674
of [EnumerationName]. This1675
naming convention is followed if and only if such an1676
ambiguity indeed occurs. For the example in Frag-1677
ment 30, ifc:HOME and ifc:DISTRIBUTIONPOINT are1678
not renamed, whereas the other owl:NamedIndividu-1679
al declarations are renamed to guarantee a unique URI.1680
As a slight variation (option 2), one could opt to fol-1681
low this naming convention for all enumeration items,1682
but this would result in notably more changes com-1683
pared to the original IFC schema, which would violate1684
the second and third criteria given in the introduction1685
(keep as closely as possible to the original IFC schema1686
and to the corresponding IFC instance file). Anyhow,1687
the original name of the enumeration item, as defined1688
in the EXPRESS schema, is preserved by the anno-1689
tation rdfs:label added to each owl:NamedIndi-1690
vidual (see Fragment 31). Finally, each enumeration1691
class is defined as a subclass of the predefined class1692
express:ENUMERATION (see Fragment 30).1693
rdf:type ifc:IfcAddressTypeEnum ;1696
rdf:type owl:NamedIndividual ;1697
rdfs:label "SITE" .1698
Fragment 31: Printout of the RDF graphrepresentation for theSITE -
IfcAddressTypeEnum named individual referenced by the Ifc-
AddressTypeEnum class declaration in Fragment 30.
Two alternative conversion options were suggested1700
by Krima et al. [41], Barbau et al. [24] (option 3) and1701
Hoang [46], Hoang andT
a [47] (option 4). Both op-1702
tions enforce no renaming, and the proposal by Krima1703
et al. [41], Barbau et al. [24] (option 3) additionally1704
avoids the use of the owl:oneOf restriction. Indeed,1705
named individuals (such as ifc:USERDEFINED) may1706
belong to multiple classes. This is feasible in OWL and1707
results in a less specific, but also less restricted ifcOWL1708
ontology, as one can see in Fragment 32. Note that we1709
only list 10 of the 161 classes in Fragment 32 of which1710
ifc:USERDEFINED would in this case be an instance.1711
rdf:type owl:Class ;1714
rdfs:subClassOf express:ENUMERATION .1715
rdf:type ifc:IfcAddressTypeEnum , ifc:1718
IfcCrewResourceTypeEnum ;1719
rdf:type owl:NamedIndividual ;1720
rdfs:label "OFFICE" .1721
rdf:type ifc:IfcAddressTypeEnum , ifc:1724
IfcCrewResourceTypeEnum , ifc:1725
IfcAssemblyPlaceEnum ;1726
rdf:type owl:NamedIndividual ;1727
rdfs:label "SITE" .1728
rdf:type ifc:IfcAddressTypeEnum ;1731
rdf:type owl:NamedIndividual ;1732
rdfs:label "HOME" .1733
rdf:type ifc:IfcAddressTypeEnum ;1736
rdf:type owl:NamedIndividual ;1737
rdfs:label "DISTRIBUTIONPOINT" .1738
rdf:type ifc:IfcElectricTimeControlTypeEnum ,1741
ifc:IfcTaskTypeEnum ,1742
ifc:IfcOpeningElementTypeEnum ,1743
ifc:IfcAirTerminalBoxTypeEnum ,1744
ifc:IfcProjectionElementTypeEnum ,1745
ifc:IfcElectricFlowStorageDeviceTypeEnum ,1746
... ,1747
ifc:IfcActionTypeEnum ,1748
ifc:IfcDuctSegmentTypeEnum ,1749
ifc:IfcRoofTypeEnum ,1750
ifc:IfcStructuralCurveActivityTypeEnum ;1751
rdf:type owl:NamedIndividual ;1752
rdfs:label "USERDEFINED" .1753
Fragment 32: Printout of the RDF graph representation for the
IfcAddressTypeEnum enumeration data type declaration displayed
earlier in Fragment 6, including the declaration of its individuals,
without renaming of named individuals and without the oneOf
restriction. Note that we only list 10 of the 161 classes of which
ifc:USERDEFINED is an instance.
The four conversion options documented above1755
are summarised in Table 3. Herein we suggest to1756
adopt the first conversion option, i.e. converting any1757
ENUMERATION data type into an owl:Class that is1758
equivalent to one of a limited set of named individuals1759
(owl:NamedIndividual), while minimising the num-1760
ber of renaming, as shown in Fragment 30.1761
renaming oneOf
option 1 partial yes
option 2 all yes
option 3 none no
option 4 none yes
Table 3: Overview of the key available conversion options for
ENUMERATION data types, with the proposed option marked in grey
3.5.2. Select data type declarations1762
We propose to convert any SELECT data type into an1763
owl:Class that is equivalent to a union of a limited set1764
of owl:Class statements (option 1). Thus, the SELECT1765
data type declaration given earlier in Fragment 7 is con-1766
verted into the representation given in Fragment 33.1767
rdf:type owl:Class ;1770
rdf:type owl:Class ;1773
] ;1783
rdfs:subClassOf express:SELECT .1784
Fragment 33: Printout of the RDF graph representation for the Ifc-
MetricValueSelect select data type declaration displayed earlier
in Fragment 7.
As an alternative (option 2), it is possible to replace1786
the owl:unionOf restriction with a simple hierarchi-1787
cal rdfs:subClassOf declaration, which would re-1788
sult in a less restricted, but also less specific ifcOWL1789
ontology (there would be no distinction between the1790
conversion of SUBCLASSOF declarations and SELECT1791
data type declarations in EXPRESS). This alternative1792
option is adopted by Krima et al. [41], Barbau et al.1793
[24] and Hoang [46], Hoang and T
a [47]. These1794
two main conversion options are summarised in Ta-1795
ble 4. Herein we suggest to adopt the first conversion1796
option, i.e. converting any SELECT data type into an1797
owl:Class that is equivalent to a union of a limited set1798
of OWL classes.1799
unionOf subClassOf
option 1 yes no
option 2 no yes
Table 4: Overview of the key available conversion options for SELECT
data types, with the proposed option marked in grey background.
In both options summarised in Table 4, the conver-1800
sion of SELECT data type declarations is rather straight-1801
forward, but it is in both cases of crucial importance1802
because it aects the whole EXPRESS to OWL conver-1803
sion strategy. As we anticipated in Sect. 2.4.2, a SELECT1804
data type declaration can refer to any other data type de-1805
clared in the EXPRESS schema (i.e. simple data types,1806
named data types, aggregation data types, and entity1807
data types), as shown in the following critical examples1808
of IFC4
IfcColourOrFactor includes the entity data type1810
IfcColourRgb and the defined data type IfcNor-1811
IfcTrimmingSelect includes the entity data type1813
IfcCartesianPoint and the defined data type1814
IfcPresentationStyleSelect includes the1816
enumeration data type IfcNullStyle and the1817
entity data types IfcTextStyle, IfcFillArea-1818
Style, IfcCurveStyle, and IfcSurfaceStyle.1819
However, the data types included in a SELECT data1820
type should all be converted in the same way to avoid1821
inconsistencies in the ifcOWL ontology, because an1822
owl:unionOf statement (see Fragment 33) cannot in-1823
clude references to both owl:Class and rdfs:Data-1824
type instances. As we saw in Sect. 3.2 and 3.3, a simple1825
data type and a defined data type declaration can be rep-1826
resented both as an owl:Class and rdfs:Datatype1827
declaration, whereas aggregation data type and entity1828
data type declarations (see next Sect. 3.6) must be con-1829
verted into owl:Class declarations. If the simple data1830
type and defined data type declarations were converted1831
into rdfs:Datatype declarations, it would result in1832
an owl:unionOf statement involving both owl:Class1833
and rdfs:Datatype.1834
Therefore, as anticipated in Sect. 3.3, we propose1835
to convert all simple data type and defined (named)1836
data type declarations as owl:Class declarations, thus1837
choosing for the options given in Fragments 16 and 20.1838
This decision is consistent with the literature as already1839
suggested by Schevers and Drogemuller [38] (referring1840
to the conversion as “objectifying the EXPRESS types1841
into OWL classes”) and Barbau et al. [24] (referring to1842
the conversion as “data wrapping”). Finally, each se-1843
lect class is defined as a subclass of the custom, prede-1844
fined class express:SELECT (see Fragment 33).1845
3.6. Entity (named) data type declarations1846
There is a common agreement among previous ap-1847
proaches in the literature to convert EXPRESS entity1848
(named) data type declarations into owl:Class decla-1849
rations. Indeed, most of the elements that are part of1850
an entity data type declaration in EXPRESS, if not all,1851
have direct parallels in owl:Class declarations.1852
3.6.1. Class hierarchy statements1853
The SUBTYPE OF declaration is converted into a dec-1854
laration using rdfs:subClassOf. If the EXPRESS1855
entity is an ABSTRACT SUPERTYPE OF, then the cor-1856
responding owl:Class is declared as a subclass of1857
the union (owl:unionOf) of its subclasses. More-1858
over, if the subclasses must be disjoint (see declaration1859
ONE OF in EXPRESS), then an OWL axiom involving1860
owl:disjointWith is added to the conversion. Frag-1861
ment 34 shows the conversion of these core owl:Class1862
statements, which correspond to the first four lines of1863
the IfcBSplineCurve entity (see Fragment 8).1864
rdf:type owl:Class ;1867
rdfs:subClassOf ifc:IfcBoundedCurve ;1868
rdf:type owl:Class ;1871
] ;1876
ifc:IfcTrimmedCurve .1881
Fragment 34: Partial printout of the RDF graph representation for the
IfcBSplineCurve entity (named) data type declaration displayed
earlier in Fragment 8 (class header).
In the other lines (besides the firstfour) listed in Frag-1883
ment 8, five regular attributes and two DERIVE attributes1884
are declared. Herein, for sake of conciseness we avoid1885
to list the conversion result for all the attributes that are1886
declared for the entity IfcBSplineCurve (see Frag-1887
ment 8), but we limit ourselves to two key reference ex-1888
amples, namely the Degree and ControlPointsList1889
3.6.2. Regular attributes1891
We suggest to convert any regular attribute declared1892
within an entity (named) data type declaration as an1893
object property declaration in OWL with the addition1894
of a proper set of restrictions to the declaration of the1895
owl:Class. Only object properties (and no data prop-1896
erties) are employed to convert the attributes because all1897
simple data type and defined (named) data type decla-1898
rations are converted into owl:Class declarations, as1899
explained in Sect.
The suggested conversion for the Degree and Con-1901
trolPointsList attributes are shown in Fragments 351902
and 36, respectively. Any regular attribute is con-1903
verted into an owl:ObjectProperty, while explic-1904
itly adding also the declaration of the domain and1905
range. In these two cases, the properties are declared1906
as owl:FunctionalProperty because the maximum1907
cardinality of the attribute is equal to one. Moreover, we1908
propose to guarantee that each object property is char-1909
acterised by one rdfs:domain and rdfs:range.1910
rdfs:label "Degree" ;1913
rdfs:domain ifc:IfcBSplineCurve ;1914
rdfs:range ifc:IfcInteger ;1915
rdf:type owl:FunctionalProperty, owl:1916
ObjectProperty .1917
Fragment 35: Printout of the RDF graph representation for the
object property ifc:Degree, which is used to convert the entity
(named) data type declaration IfcBSplineCurve displayed earlier
in Fragment 8.
rdfs:label "ControlPointsList" ;1921
rdfs:domain ifc:IfcBSplineCurve ;1922
rdfs:range ifc:IfcCartesianPoint_List ;1923
rdf:type owl:FunctionalProperty, owl:1924
ObjectProperty .1925
Fragment 36: Printout of the RDF graph representation for the object
property ifc:ControlPointsList
of IfcBSplineCurve, which
is used to convert the entity (named) data type declaration Ifc-
BSplineCurve displayed earlier in Fragment 8.
Because EXPRESS attributes are defined in the scope1927
of the entity (see Sect. 2.5), it can occur that multiple at-1928
tributes in dierent entity scopes have the same name,1929
thus being just homonyms. The uniqueness of the ob-1930
ject property name can be enforced by following a simi-1931
lar approach adopted to rename enumeration items with1932
identical names (cf. Sect. 3.5.1). In this case, the renam-1933
ing convention consists in adding a sux that recalls1934
the name of the entity where the attribute is defined,1935
i.e. [NameOfAttribute]
of [NameOfEntity]. This1936
convention is dierent compared to the work by Krima1937
et al. [41], where the renaming is enforced for all prop-1938
erties, even in case of no ambiguity, by adding a pre-1939
fix that recalls the name of the entity, i.e. [NameOf-1940
has [NameOfAttribute].1941
Anyhow, as a novelty with respect to the state of the1942
art, we propose to keep track of the original name of1943
the attribute by adding an annotation rdfs:label to1944
each object property. An example is represented by the1945
conversion of the attribute ControlPointsList into1946
the ifc:ControlPointsList
of IfcBSplineCurve1947
object property (Fragment 36), which has the original1948
name ControlPointsList as its rdfs:label prop-1949
erty. Note that the range of the corresponding object1950
property is not the class ifc:IfcCartesianPoint, but1951
the class ifc:IfcCartesianPoint
List, because the1952
EXPRESS attribute ControlPointsList refers to a1953
The range type and cardinality constraints of rele-1955
vance for each attribute in EXPRESS are added as re-1956
strictions to the OWL class that acts as the domain of1957
the property. Fragments 37 and 38 illustrate the dec-1958
laration of such restrictions for the object properties1959
ifc:Degree and ifc:ControlPointsList
of Ifc-1960
BSplineCurve of class ifc:IfcBSplineCurve. A1961
universal quantifier restriction (owl:allValuesFrom)1962
is added in all cases. For the examples in Frag-1963
ments 37 and 38, an additional owl:qualifiedCar-1964
dinality restriction is added, with its