Automation in Construction 92 (2018) 214–229

Contents lists available at ScienceDirect

Automation in Construction
journal homepage: www.elsevier.com/locate/autcon

A rule-based methodology to extract building model views T

a,b,c,* c c
Tarcisio Mendes de Farias , Ana Roxin , Christophe Nicolle
a
Department of Computational Biology, University of Lausanne, Lausanne, Switzerland
b
SIB Swiss Institute of Bioinformatics, Lausanne, Switzerland
c
Laboratory LE2I, CNRS, Arts et Métiers, Univ. Bourgogne Franche-Comté (UBFC), Dijon, France

A R T I C LE I N FO A B S T R A C T

Keywords: In this paper, we present a novel approach called IfcView that relies on Semantic Web technologies for creating
ifcOWL building views. To do so, we consider an ifcOWL ontology proposed by buildingSMART. The ifcOWL is an
Rule checking Industry Foundation Classes (IFC) based ontology. By combining the ifcOWL ontology with logical rules (ex-
Model view definition (MVD) pressed in Semantic Web Rule Language, SWRL), we demonstrate through several case studies that our approach
Reasoning
can perform a more intuitive and flexible extraction of building views when compared to the Model View
Semantic web
Definition (MVD) approach. This is because our rule-based approach dynamically creates sub-graphs (i.e. views)
by specifying the IFC elements to extract as Globally Unique Identifiers (GUID), relationships or entities. Another
benefit of our approach is the fact that it simplifies the maintenance and definition of building views. Once our
rule-based system extracts such a building view (i.e. sub-graph), this view can be exported by using STEP
(STandard for the Exchange of Product) or Turtle (a Resource Description Framework (RDF) syntax) formats.

1. Introduction
A building life-cycle mainly comprises the following stages: the in-
itial planning and design, the construction of the facility, the operation
and maintenance and the dismantling and recycling of buildings and
engineering structures. The data produced throughout the building’s
life-cycle is handled and updated by several different actors each in-
tervening in different associated processes. BIM (Building Information
Modeling) [1] is one of the latest approaches proposed in the AEC
(Architecture, Engineering and Construction) domain for bridging the
existing interoperability gap among systems in this field. A BIM system
is a tool that allows users to integrate and reuse building-related data
along with pertaining domain knowledge, throughout the considered
building’s life-cycle [2].
The first step in BIM standardization was conducted in 1999 by
buildingSMART International (bSI) organization (formerly
International Alliance for Interoperability, IAI) [3]. It resulted in the
development of a model for representing all components of a physical
building, namely the IFC model (Industry Foundation Classes). Unlike
previous formats such as DXF (Drawing eXchange Format) [4] or DWG
(DraWinG) [5], which were graph- and respectively vector-oriented
representation formats, the IFC standard (ISO 10303-21) relies on ob-
ject-oriented modeling (i.e. EXPRESS language based) [6].
In the context of BIM, a digital representation of the building comes
in the form of one or several IFC files, therefore ensuring
interoperability among the data produced with the various software
tools used by the different actors from the AEC domain. Still, manip-
ulating the data contained inside such IFC-based building representa-
tions remains a fastidious process, mainly performed manually (by se-
lecting IFC elements) and therefore source of numerous errors. Notably,
in order to facilitate the handling of such IFC files, there is an increasing
need to display only the information pertaining to a given business logic
or context (i.e. view). This need also arises when a given stakeholder
wishes to update or to modify the information contained in an IFC file,
and then forward the result to another stakeholder, or insert it into a
global BIM representation. Such workflow can be compared to loosely
coupled federated architectures as defined in Ref. [7]. Thus, in our
vision, BIM stands as a cooperative system of unified views of the same
building. Each stakeholder is allowed to locally keep a view of the
global building model. Such view is defined as the sum of necessary and
sufficient building information needed for the correct realization of
their related business processes (e.g. plumbing, building renovation,
window cleaning). In other words, to deliver such a view, one has to
correctly extract the minimal sub-graph of elements from the IFC file(s)
representing the whole building.
Given the fact that organizations (such as bSI, but also the
International Organization for Standardization, ISO) have been re-
cognized Semantic Web technologies as a potential mean to solve issues
related to the handling of IFC files, the approach we present here is
solely based on the OWL version of the IFC standard (i.e. ifcOWL

*
Corresponding author.
E-mail addresses: tarcisio.mendesdefarias@unil.ch (T.M.d. Farias), ana-maria.roxin@u-bourgogne.fr (A. Roxin), cnicolle@u-bourgogne.fr (C. Nicolle).

https://doi.org/10.1016/j.autcon.2018.03.035
Received 27 July 2017; Received in revised form 2 March 2018; Accepted 29 March 2018
Available online 25 April 2018
0926-5805/ © 2018 Elsevier B.V. All rights reserved.
T.M.d. Farias et al.
ontology, as pushed by bSI [8]). Our goal is to demonstrate that Se-
mantic Web technologies are suited for extracting pieces of data from
building models. We aim at proving that this approach allows a more
intuitive extraction of building views and mitigates the gap of semantic
heterogeneity for building software interoperability. Indeed, our ap-
proach is a rule-based system, where rules are expressed by means of
terms either extracted from the ifcOWL ontology or inferred (see
Section 4 and Appendix A). In other words, our main focus is to show
that Semantic Web technologies can be used to efficiently (semi)-au-
tomatically extract building views.
Section 2 begins with a brief overview of the most pertaining related
works in the context of the ifcOWL ontology and building model views.
Section 2 also includes a review of several recent rule-based systems as
implemented in a BIM context. Section 3 depicts Semantic Web con-
cepts that are needed to understand the rest of the work presented here.
Section 4 briefly describes how we create the knowledge graph based
on the ifcOWL ontology and how we define our logical rules to ease the
model view extraction. Section 5 explains the implementation of our
rule-based system prototype for extracting building views. Section 6
evaluates the implemented prototype in terms of query execution time
and number of expected results. Finally, we conclude this article by
discussing the benefits of such a rule-based system compared to tradi-
tional approaches. We end this article by enumerating several im-
provements that could be implemented in order to enhance the per-
formance of our prototype.
2. Related work
This section covers three research fields. The first one is dedicated to
the conversion of the IFC standard into an OWL ontology. The second
one concerns the most relevant approaches for defining building model
views. Finally, the third one presents two recent BIM systems that use
logical rules.
2.1. IFC-to-OWL converters
IFC-to-OWL converters studied in this section rely on automatic
methods for conceiving an OWL ontology from the EXPRESS schema
of the IFC standard. Developed in the context of the IntelliGrid EU
FP6 project [9], the approach described by Beetz et al. in [10] is the
first well-defined approach to translate the IFC standard into OWL
(i.e. ifcOWL). Over the last few years, various IFC-to-OWL converters
were proposed (see related approaches in Refs. [10-15] for further
details).
Dibley et al. in Ref. [16] present how to conceive an IFC ontology by
parsing STEP1 files that contain IFC entities. Unfortunately, this trans-
lation of the IFC standard into OWL only covers a limited set of IFC
classes, namely the classes considered relevant for the project at hand
(that is the implementation of an augmented environment for in-
telligent agents). Today, the reference (candidate standard) version of
an ifcOWL ontology is proposed by buildingSMART and available in
Ref. [8]. The IFC-to-OWL converter to generate the buildingSMART’s
ifcOWL version is fully described by Pauwels et al. in Ref. [11]. As a
reminder, an IFC-to-OWL converter is a method for generating an OWL
ontology starting from the IFC EXPRESS schema.
2.2. Defining model views
The approach defined in the context of the buildingSMART com-
munity for specifying sub-parts of IFC files is called Model View
Definition (MVD). An MVD “defines a subset of the IFC schema that is
needed to satisfy one or many Exchange Requirements of the AEC industry”
[17]. The specification of MVDs is currently enabled through the
1 4
https://www.iso.org/standard/63141.html.
215
Automation in Construction 92 (2018) 214–229
IfcDoc2 tool. At the moment, the MVD specification relies on modular
Concept Templates [18], namely bricks of IFC schema snippets. After
composing an MVD with the IfcDoc tool, the MVD can be exported as an
mvdXML file [17], both for future reuse and for inclusion in an IDM
(Information Delivery Manual). In addition, any IFC file can be vali-
dated according to an MVD loaded in the IfcDoc tool. In other words,
the IfcDoc tool allows validating a given IFC file with respect to a given
MVD. Thus the main issue with IFC files remains the information ex-
traction. This is why, in this paper, we investigate to what extent Se-
mantic Web technologies can be applied for extracting data from an IFC
file. Our present scope does not cover using Semantic Web technologies
for validating an IFC file. With this being mentioned, the MVD ap-
proach, as defined by bSI, has several main drawbacks listed below:
1. MVDs lack logical formalisms (e.g. description logic, horn-like rules
and shape expressions or constraints) which can take advantage of
reasoners and rule engines. For instance, such formalism eases the
implementation of validation rules [19].
2. The MVD solely considers the IFC schema. Our approach (described
in Section 4) goes beyond this, by addressing both IFC schema and
instances’ GUIDs (Globally Unique Identifier3), thus making
building views’ definition process more flexible.
3. An MVD-based constructor is based on static and previously defined
XML files (mvdXML). These mvdXML files have to be entirely parsed
before extracting a building view from an IFC project file.
4. In addition, in the MVD approach, a simple view modification
implies reconstructing the entire mvdXML file.
Our approach relies on logical rules to express the elements that are
part of a building view. These rules are dynamically applied during a
view extraction by a rule engine. Thus, as rules can be easily added or
removed from the knowledge base (see related definition in Section 3),
our approach has a higher level of flexibility. It can be seen as a way to
filter an IFC file according to a specific need or context. With our ap-
proach, all irrelevant data can be removed from the BIM before gen-
erating the ifcOWL file. The queries further addressed on this file are
solely handled by Semantic Web technologies, thus allowing the two
following advantages:
1. High maintainability: only one ifcOWL file derived from one master
IFC model along with the set of queries or rules (as adapted from the
considered mvdXML files) need to be maintained. All subset gen-
eration is based on ifcOWL graphs and will be done automatically on
query time.
2. High modularity: one is able to intuitively generate new MVDs by
combining queries and rules. Our approach thus matches the ori-
ginal MVD modularity; in our approach Concept Templates are re-
presented as formal logical rules or queries.
In Ref. [20], the authors describe a partial building view extraction
method (as RDF graphs and schemas), mostly based on a preliminary
version of the ifcOWL ontology [21]. However, this method has two
major limitations when compared with our approach. Firstly, this ap-
proach doesn’t allow for generating a view as an IFC-STEP file. Thus, in
other words, the output in Beetz et al.’s approach cannot be used as an
input to Computer-aided design (CAD) software tools handling IFC files.
Secondly, the authors in Ref. [20] do not propose a semi-automatic way
to define building model views. Actually, the building view is defined
by manually writing a unique SPARQL CONSTRUCT4 query.
2
http://www.buildingsmart-tech.org/specifications/specification-tools/ifcdoc-tool.
3
http://www.buildingsmart-tech.org/implementation/get-started/ifc-guid.
https://www.w3.org/TR/rdf-sparql-query/#construct.
T.M.d. Farias et al.
2.3. Other related works
In Ref. [22], the authors created a rule-based system to semantically
enrich an IFC building model. This system takes as an input a rule set
and uses a forward-chaining inference engine to process the rules over
the IFC data and infer new information. By doing so, implicit in-
formation becomes explicit based on the considered rules. Thus, this
system outputs an enriched IFC file with the inferred (now explicit)
information. In our work, we focus on extracting building model views
instead of enriching a given IFC file. Our system is also rule-based,
however we rely on semantic web standards or recommendations such
as OWL and Semantic Web Rule Language (SWRL) to conceive rules.
Therefore, by using such standards, we enhance interoperability with
other systems rather than defining a new specific rule language. An-
other main difference between the two approaches (ours and the one
from Ref. [22]) is the fact that we use a backward-chaining reasoner to
infer new information. Therefore, we avoid unnecessary data materi-
alization when extracting a building view (see Section 5 for further
details). Moreover, our approach is not restricted to the IFC CV 2.0
schema [23]. Our system is based on the IFC2x3 ontology nevertheless
can be easily extended to the IFC 4 ontology. Another recent work that
might seem similar to our approach is the work presented in Ref. [24].
Authors rely on different rule types, validation logic, and checking
scenarios, all of them specifically “identified, developed and organized”
for the IFC standard. In Ref. [24] , authors do not mention the logical
formalism on which they rely, neither how the considered rules were
developed (apparently manually and solely for the IFC standard in
combination with the IfcDoc tool). Our approach can be adapted in
order to generate rules based on another OWL version of the standard.
Still, the approach in Ref. [24] may be considered as complementary to
ours, with respect to the following constraints: a) rules (or logical ex-
pressions) used in Ref. [24] have to be adapted in some Semantic Web
rule language e.g. SWRL or RIF; b) these rules have to be mapped to
elements from the ifcOWL ontology; c) the so-generated set of rules has
to be further curated in order to verify that consistency rules inherent to
the Semantic Web language chosen are not duplicated or altered when
implementing logical constraints suggested by the authors in Ref. [24].
In Ref. [25], Ma et al. suggest formalizing specifications for con-
struction cost estimation by using ontologies and logical rules. By doing
so, the authors claim that the working efficiency and accuracy of esti-
mation is greatly improved. Ma et al.’s approach is based on OWL and
SWRL languages. SWRL is used to define the rule set corresponding to
the associated rule library for cost estimation.
The next section (i.e. Section 3) gives some formal definitions of
concepts employed in this article.
3. Background definitions
This section formally defines what an ontology is in the context of
the Semantic Web. Section 3.2 contains an overview of existing OWL-
based reasoners.
3.1. Definitions
Definition 1 . (Ontology) An ontology O is a tuple O = (S , A ) , S being
its signature (conceptual entities used for knowledge representation)
and A its associated set of axioms (expressed in a specific ontology
language or knowledge representation formalism) [26].
Definition 2 . (Signature of an ontology) The signature of an ontology
is defined as the union S = C ∪ I ∪ P of the ensemble of classes C ,
instances I and properties P [26].
The definitions for conceptual (abstract objects of the domain) and
concrete entities (concrete data values) can be found in [26]. All
statements defined regarding conceptual and concrete entities form a
knowledge box (KB). More specifically, the statements regarding
216
Automation in Construction 92 (2018) 214–229
conceptual entities form the so-called the terminological box (TBox)
and the statements involving concrete entities form the assertional box
(ABox) [27].
When adding logical rules to DL-based ontologies, we obtain rule
systems, which are seen today as a key knowledge representation and
reasoning technology. Indeed, logical rules allow for reasoning over
machine-readable descriptions of a domain of discourse (the KB itself).
Definition 3 . (Inference) The mechanism that allows deriving new
assertions based on existing axioms according to rules is called
inference [28].
Main ontology description languages, OWL [29] and OWL 2 [30],
are directly based on Description Logics (DL) [31]. Therefore, they both
include a logical framework comprising syntax and model-theoretic
semantics. Another “heritage” from DL is the concern for practical
reasoning and having effective reasoners (mainly extended from DL
reasoners such as Pellet [32] and HermiT [33]). Effective reasoning
means reaching conclusions: the axioms present in the considered KB
(and forming the so-called explicit knowledge) are processed compu-
tationally in order to deduce implicit knowledge. Such reasoning pro-
cess is mainly performed based on formal logic, because it allows for
specifying (through formal semantics) the consequences of a set of
axioms.
Definition 4 . (Rule or rule axiom) A rule is composed of a rule head
(also called consequent) and a body (called antecedent). If the body of a
rule is true, then its head is derived as a new assertion [34, 35].
Rule-based systems rely on rules for expressing knowledge through
logic programming paradigm IF-THEN, which is considered a special
form of axiomatization [26]. Several languages exist for integrating
such rules into ontologies. Among them we may cite RIF (Rule Inter-
change Format), RuleML (Rule Markup Language) or SWRL (Semantic
Web Rule Language) [36]. SWRL is a DL-safe rule language i.e. it pre-
serves decidability when combined with OWL-DL. Moreover, SWRL
extends the set of existing OWL axioms in order to include Horn clauses
[34].
Definition 5 . (Horn clause) A Horn clause is a disjunction of literals
(i.e atomic formulas) with at most one positive literal [34, 35]. A
definite clause is a type of Horn clause. The definite clause can be
interpreted as conjunctive positive literals that imply a positive literal.
Such reasoning process is mainly performed based on formal logic,
because it specifies the consequences of a set of axioms.
Definition 6 . (Consequence of an ontology) The consequences of an
ontology are represented by the set of assertions implicitly caused by an
ontology. These assertions directly impact answering to queries
addressed to the ontology [37].
3.2. Reasoning
For interpreting Horn-like rules at query execution, traditional logic
programming languages, such as Prolog, use a method called SLD
(Selective Linear Definite) resolution [38]. SLD stands for “SL resolu-
tion with Definite clauses” and consists in interpreting the top clause
(the query) as a negation of a conjunction of sub-goals (sub-queries). To
do so, it relies on a backward reasoning technique [39, 40].
When applied to OWL-based reasoners, four main approaches exist
for managing SWRL rules (Horn clauses):
1. SWRL rules can be translated into FOL (First Order Logic) — in this
case reasoning tasks are demonstrated by means of theorem provers.
This is the case for the Hoolet reasoner [41];
2. OWL-DL can be translated into rules which are then passed to a
forward-chaining or backward-chaining engine. This is used by the
Bossam [42], KAON2 [43, 44], DL2DB [45], SWRL-IQ [46],
SWRL2COOL [47] and O-Device [48] reasoners;
3. SWRL rules are translated into DL axioms based on a rolling-up
T.M.d. Farias et al. Automation in Construction 92 (2018) 214–229

technique [49]. These rules are then processed by an OWL-DL rea-

Query answering
soner based on the Tableaux calculus. This is the case for the Pellet
[32] and RacerPro [50] reasoners or for the Hypertableau calculus
[51] (e.g. the HermiT reasoner [33]);
support

4. Reasoning is performed by applying a query rewriting approach. In

Yes
Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes
No
this approach, SWRL rules are taken into account during query re-
writing process. This is the case for the reasoner implemented in the
Yes, with AllegroGraph
Large-scale triple store

Stardog triple store [52], a semantic graph database.

Some reasoners use a hybrid approach where both backward- and

triple store.

forward-chaining techniques are implemented to improve query ex-

ecution time. This is the case for DL2DB [45] and Jena [53], still the
latter does not support the SWRL syntax. Table 1 summarizes the main

Yes
No

No

No

No

No

No

No

No
reasoners which, to the best of our knowledge, support both OWL and
Language) for performing reasoning based on CLIPS. The CLIPS is

SWRL languages.
An inference engine based on XSB Prolog. Therefore, it reduces

Reduces KB to a datalog program. It is also based on rewriting

An inference engine based on the first-order theorem prover

Deriving implicit facts from SWRL rules at query execution can in-
Conversion of SWRL rules to COOL (CLIPS Object-Oriented

An inference engine based on the forward-chaining RETE
Based (mostly) on a query rewriting technique
Reduces KB to disjunctive datalog program.
deed significantly extend query processing time. Moreover, all rea-
soners which perform inferences at query execution time are OWL/
SWRL general purpose reasoners (see Table 1).
The next section describes our approach based on Semantic Web

technologies for extracting building views.

a RETE-based production rule engine.

techniques for answering queries.

Based on Hypertableau calculus.

4. Combining Horn-like rules with ifcOWL to leverage building

model view definitions
Based on Tableaux calculus.

Based on Tableaux calculus.

KB to a datalog program.

4.1. Creating the knowledge base(KB)

In order to be able to manipulate building data with Semantic Web

Methodology

algorithm.

technologies, we have to be able to represent such data in a Semantic

Vampire.

Web language (e.g. OWL). As described in Section 2, several approaches

have addressed the translation of the IFC standard into OWL. Our ap-
proach is based on the ifcOWL version as defined by buildingSMART5.
To create a knowledge base allowing us to manipulate building-
related information, we followed these steps:
SHIF(D) and it supports some
nominal and cardinality,

1. First, we considered the buildingSMART’s ifcOWL ontology based

on the IFC2x3 Technical Corrigendum 1 (TC) standard [6]. There-
constructors,(ON).

fore, this ontology forms the terminological box (TBox) of the KB.
DL-expressivity

The IFC EXPRESS schema converter used to generate this ontology is

SHOIN(D)

SROIQ(D)

SROIQ(D)

SROIQ(D)
SHIQ(D)

available in Ref. [54].

SHIQ

2. By considering the ifcOWL ontology, we use software tools (such as

SHI

SHI

SHI

Protégé6) which provide a simple interface for the ontology engineer

to define SWRL rules on top of the considered TBox. The rules are
Yes and supports incremental

manually created following the expressivity needed by domain ex-

during each consistency test.
Yes. Partial materialization

perts from AEC/FM (Architecture, Engineering and Construction/

Facility Management).
ABox materialization

3. The resulting terminological model is then uploaded into a triple

store. In our context, we have used the Stardog RDF database ac-
cording to the reasons mentioned in Section 5 (namely support of
reasoning.
Overview: SWRL-supporting semantic web reasoners.

SWRL rule reasoning and the DL expressiveness level of ifcOWL

ontology).
Yes

Yes

Yes
No

No

No

No

No

4. For populating the so-built TBox with information from IFC files,
we considered the parser available in Ref. [55] that extracts data
Reasoning at query

from an IFC STEP file and creates the respective concept instances in
execution time

the KB. During this process, we create a distinct database in the

triple store for each IFC STEP file.
Yes

Yes

Yes

Yes

Yes
No

No

No

No

No

Based on the above considerations, the following subsections illus-

trate the key benefits obtained by implementing DL-safe Horn-like rules
on top of this ontological model of the IFC standard. Notably we explain
SWRL2COOL & O-

the benefits achieved by defining and using DL-safe rules for the ex-
traction of IFC data.
Device
Pellet 2.0
Reasoner

RacerPro

SWRL-IQ

Stardog
KAON2

Bossam
Hermit

DL2DB
Table 1

Hoolet

5
http://www.buildingsmart-tech.org/ifcOWL/IFC2X3_TC1.
6
http://protege.stanford.edu/.

217
T.M.d. Farias et al. Automation in Construction 92 (2018) 214–229

Table 2
The prefixes used throughout this article.
Prefix Namespace IRI

ifcowl http://www.buildingsmart-tech.org/ifcOWL/IFC2X3_TC1#
express https://w3id.org/express#
ifcview http://purl.org/ifcview/
xsd http://www.w3.org/2001/XMLSchema#

4.2. Defining building views by using DL-safe Horn-like rules

4.2.1. Dynamic classification of eligible IFC components in a specific

industrial context Listing 2. A SPARQL query to retrieve all external walls of a building.
In many application contexts, the IFC standard fails to deliver a
proper solution tailored to the exact needs of the building actors. For Considering the definition of an external wall, this can be defined
example, the facility manager will not directly handle IFC entities, but through a DL-safe rule as follows:
will search for “façade” walls, determine spaces that cannot be ac-
cessed, or ask the system for the number of rooms in a building. This
information is implicitly described in the IFC model. However, it is not
easily exploitable when relying exclusively on the IFC standard, be-
cause this implies complex calculus that is based solely on the geometry
of the elements contained in the IFC file.
In order to address these limitations, our approach allows for de-
fining novel concepts as used by AEC/FM actors by means of SWRL
rules. A set of rules allows for specifying additional information re-
garding the concepts defined in the TBox. Notably, they specify means
for discovering and generating new knowledge from the exiting one. Listing 3. A Horn-like rule that classifies external walls (i.e. IfcWall instances)
of a building as a ExternalWall concept.
Therefore, the implicit information becomes explicit. By doing so, we
can conceive a more fine-grained ontology.
Table 2 describes the namespaces IRI (Internationalized Resource This rule (see Listing 3) populates the concept of ExternalWall which
Identifier) and the respective prefixes used throughout this article. does not exist in the IFC standard. By integrating the concept of Ex-
For example, considering the case of a facility manager that needs to ternalWall defined through the Horn-like rule, we greatly simplify the
plan the cleaning of all windows of a given building. The concept of a writing of the SPARQL query, making it more comprehensible and
windowed-space is not present in the IFC standard, so identifying such understandable. Listing 4 presents this simplified query.
spaces would represent a lot of manual work for the facility manager.
However, this information can be easily exploited, if we create the
concept ifcview:SpaceWithWindow instantiated by applying the Horn-
like rule in Listing 1 which identifies spaces that have one or more
windows.
Listing 4. Simplifying the query in Listing 2 when considering the DL-safe rule
in Listing 3.

5. IfcView approach to extract building views

Listing 1. A Horn-like rule that identifies spaces with windows.
We can easily extend this example to the case where logical rules are
used to specify precise business contexts (i.e. views) and processes.
4.2.2. Simplifying SPARQL queries’ writing
Defining DL-safe Horn-like rules using ifcOWL terms gives the ad-
vantage of simplifying the writing of SPARQL [56] queries because we
can use inferred terms from a more fine-grained ontology.
For example, let us consider the following SPARQL query (in Listing
2) that retrieves all external walls of a building:
Based on the ifcOWL ontology (see Section 4) and the benefits of using
Horn-like rules to classify instances that belongs to a given BIM context (or
view), we developed a prototype to automatically deliver a business view of
an IFC building project. This prototype was programmed in Java language.
Given the reasoners described in Table 1, we have chosen to apply our
approach (described in the next section) over a 5.0.3 Stardog triple store
[52], which uses a backward-chaining reasoner (based on query rewriting
techniques) to perform inferences. Besides reasoning techniques, we also use
the 5.0.3 Stardog for data persistence.
The DL-safe rule syntax used in the IfcView prototype is the SWRL
language. Our choice of SWRL is mainly motivated by the will to enhance
rule interoperability with other existing triple stores or systems. In this
section, we consider the ontology’s TBox and ABox as one single graph.
To better justify our choice of Stardog, it is mainly motivated by the

218
T.M.d. Farias et al.
Fig. 1. Implemented prototype for extracting building views.
three following reasons: Stardog supports OWL and SWRL rules, it en-
ables performing reasoning at query execution (backward-chaining)
and it is a large-scale triple store. Indeed, we want to avoid data ma-
terialization (as a reminder, in forward-chaining reasoning all entailed
facts are materialized). Furthermore, we need a reasoner associated to a
large-scale triple store for handling large KBs when considering (nu-
merous) building projects. We have also performed query execution
time benchmarks [57] and Stardog, in several cases, outperformed all
considered approaches, notably JENA+SPIN [58] and EYE [59].
Fig. 1 illustrates an architecture view of the implemented prototype.
Firstly, the IFC project data serialized by using the STEP Physical
File (SPF) [60] format is converted into Turtle (TTL) [61] format. Ad-
ditionally, the ifcOWL ontology is also serialized in TTL format. Both
IFC project data and schema (i.e. ifcOWL) are loaded into a new KB that
is created in the Stardog triple store. The related processes for con-
version and loading form the import phase of our system prototype.
Secondly, our prototype comprises an export phase. This phase allows
for exporting a subpart of a building project (or a view) either in STEP
or TTL formats. The export phase takes the following elements as in-
puts:
1. C is a set of concepts that can contain asserted concepts (e.g.
IfcDoor) or inferred concepts (e.g. BuildingEnvelope, ExternalDoor,
ExternalWall and so on) by applying Horn-like rules such as the
Duplex apartment case study discussed in Section 6.1.
2. R is a set of IFC relationship entities. These entities are asserted to
related IFC objects such as a door to a opening element and this
opening element to a wall.
3. G is a set of IFC GUIDs.
The Sub-Graph Constructor Module (SCM) (see Fig. 1) is responsible
for composing a sub-graph that contains all instances (according to the
C and G inputs) and their directly asserted properties (see Algorithms 1
and 2). In addition, this sub-graph is also composed of instances which
are related to each other through a given set of IFC relationships (see
219
Automation in Construction 92 (2018) 214–229
Algorithm 3). This module acquires instances recursively. In order to do
this, the SCM module retrieves all asserted properties of each visited
node (i.e. instance) in the graph. If the property value is an object (i.e.
another concept instance such as an instance of IfcDoor, see Fig. 2) then
SCM also retrieves this object and its asserted properties. This process
continues until the property value found is a data type (e.g. string,
double, integer, etc.), as it is the case for the express:hasString property
value illustrated in Fig. 2. The presented recursive process also con-
siders related instances which use relationships assigned in R .
For illustrating this, let us consider the IfcRelDefinesByProperties
relationship, an instance IR of this relationship and its two related in-
stances I and I ′. According to the IFC2x3 TC1 standard [6], the If-
cRelDefinesByProperties entity is “an objectified relationship that defines
the relationships between property set definitions and objects. Properties are
aggregated in property sets, property sets can be grouped to define an object
type”. Thus, the SCM retrieves I , I ′ and IR instances and their asserted
properties. To better illustrate this example, let us consider
R = {IfcRelDefinesByProperties} and the example in Fig. 2. This figure
shows a direct graph where I , I ′, IR and IR2 are instances of IfcDoor,
IfcPropertySetDefinition, IfcRelDefinesByProperties and IfcRelFillsElement,
respectively. In this example, SCM does not retrieve IR2 instance and its
associated instances and property values. This is because IfcRelFillsEle-
ment is not included in R and there is no edge in the graph pointing to
IR2 (an instance of IfcRelFillsElement).
Once the desired sub-graph (i.e. building view) is created, the TTL
Serializer Module (TSM) takes this sub-graph as an input and serializes
it using the TTL format. If a SPF serialization is required, this sub-graph
is represented as Java objects. Afterwards, these objects are used to
create an IFC STEP file by the SPF Serializer Module (SSM).
To output an IFC STEP file, the SSM module considers the STEP IDs
encoded in the names of ifcOWL class instances during the import
phase. In the export phase, the SSM module composes a list of all STEP
identifiers (IDs) which represent the IFC instances selected by the SCM
to construct a building view. This list of STEP IDs is used to select
corresponding lines from the original IFC file (the whole building
T.M.d. Farias et al. Automation in Construction 92 (2018) 214–229

Fig. 2. Sub-graph extraction example.

project). By doing so, the data of the extracted building model views Algorithm 2 . Function to create in-memory OWL individuals based on
correspond exactly to the data from the original IFC STEP file. Actually, a given instance URI stored in a knowledge base.
we select STEP lines from an IFC STEP file as related to the desired
building view.
Algorithm 1 presents the pseudo-code corresponding to the export
phase of a view extraction from an IFC STEP-based file (see Fig. 1). In
this pseudo-code, URI is an acronym for Uniform Resource Identifier.
Algorithm 1 . The pseudo-code of the export phase of our IfcView
approach.

Algorithm 3 . Function to create in-memory OWL individuals based on

a set of IFC relationships (e.g. IfcRelDefinesByProperties) and a given
instance URI stored in a knowledge base.

220
T.M.d. Farias et al.
6. Evaluating our IfcView prototype
The above-described prototype has been tested in the following
environment:
• Micro-processor i5 1.7 GHz, SSD 128 GB and 8 GB RAM memory.
• Stardog triple store and API version 5.
• Java version 1.8, Java(TM) SE Runtime Environment
(build1.8.0_31-b13).
• OPEN IFC JAVA TOOLBOX package is available online . 7
• Eclipse Standard/SDK Version: Kepler Service Release 1 Build id:
20130919-0819.
In the context of this environment, we test our prototype using
several case studies, notably over a publicly available building model
(see Section 6.1), and over four additional building models (see Section
6.2), all publicly available except one. The results obtained are dis-
cussed in Section 6.3.
6.1. Case study: the Duplex building project
The Duplex apartment building project was produced in Weimar
Germany for a design competition. This IFC building model is available
online8. Fig. 3 shows the original Duplex model using the Solibri Model
Viewer tool9.
In this section, we use this IFC model as a case study to validate our
proposed rule-based approach to extract building model views.
Moreover, in this case study, we define the “Building Envelope” concept
as the ensemble of external doors, windows and walls (i.e.
ifcview:ExternalDoor in Listing 5, ifcview:ExternalWindow in Listing 6 and
ifcview:ExternalWall in Listing 3, respectively). The “Building Envelope”
concept (i.e. ifcview:BuildingEnvelope) is formally defined using Horn-
like rules in Listing 7.
Appendix A describes Horn-like rules (similar to those in Listings 3,
5 and 6) that allow for defining external building elements in a modular
way. The rules in Appendix A were adapted from Ref. [57]. The inputs
of our system (for further details, see Section 5) for this case study are
described as follows:
• The IFC STEP file: Duplex_A_20110505.ifc
• C = {BuildingEnvelope}.
• G = { }. We consider the set of IFC GUIDs as an empty set (i.e. ϕ)
since it is irrelevant for test purposes.
• R ={IfcRelDecomposes, IfcRelContainedInSpatialStructure,
IfcRelVoidsElement, IfcRelFillsElement, IfcRelDefinesByProperties}.
A full description of IFC relationship entities is available in Ref. [6].
Fig. 4 based on the EXPRESS-G graphical notation [62] illustrates
various IFC relationships that belong to the R set. Moreover, the sub-
classes of the ifcOWL relationship classes in R are also considered by
our Algorithm 3.
With those inputs, instances of the considered external building
elements will be classified as instances of the ifcview:BuildingEnvelope
class by applying rules in Listings 3, 5, 6 and 7 at the KB level.
Therefore, the output of our rule-based system is the building envelope
illustrated in Fig. 5. To assess the performance of IfcView in terms of
execution time, this building view envelope was generated in ≈
49 seconds; it created 3676 in-memory JAVA objects and a STEP file
with 3685 lines out of which 3676 represent STEP instances. The im-
port phase (converting the IFC STEP file into RDF file and importing it
in the triple store) lasted ≈ 6 seconds. IfcView selected 4 Doors out of
7 10
http://www.openifctools.com.
8
http://openifcmodel.cs.auckland.ac.nz/Model/Details/274.
9 11
http://www.solibri.com/products/solibri-model-viewer/.
221
Automation in Construction 92 (2018) 214–229
the 14 available, 22 Windows (out of 24) and 23 Walls (out of 49) to
compose the building envelope. However, we also have to consider the
instances which are somehow connected to these 49 instances of doors,
windows and walls such as Cartesian points, IfcProperties and IfcRela-
tionship subclasses (i.e. R ). By including these elements, we obtain the
resulting set of 3676 STEP instances’ IDs, that was used to construct the
IFC building envelope view for the Duplex apartment project.
Fig. 5 also shows what seems to be an “internal” wall (highlighted in
green). However, this wall has the IsExternal property from the Pset_-
WallCommon10 asserted as “TRUE” in the original IFC model of the
“Duplex apartment” (see Fig. 3). According to the IFC standard, the
“IsExternal” property indicates whether the element is to be considered
external (“TRUE”) or not (“FALSE”). Hence, this explains why the
building envelope view illustrated in Fig. 5 also contains this wall.
Regarding building elements’ colors, these are not present in the IFC
model. They are defined by the Solibri Viewer tool. This is why one may
notice a change of colors between the original “Duplex” model and the
building envelope view generated with our approach.
6.2. Additional case studies
In order to evaluate the performance in terms of expected results
and execution time, we extracted, using our prototype, several building
views. Tables 3 and 4 describe three considered case studies, namely
the Institute Var project, the Medical Clinic project and the High-School
project (private IFC file).
For each case study, we addressed a different query, extracting each
time a different building view. Starting with the first case study
(Institute Var project), the complexity of the considered queries grows.
In the first case, we extract only all building doors, in the second case
we extract all building doors and windows, and finally, for the third
case study, we extract all doors and stairs. For each of the considered
case studies, we also retrieve all related instances by considering the
following relationship set: R= {IfcRelDecomposes,
IfcRelContainedInSpatialStructure, IfcRelVoidsElement, IfcRelFillsElement,
IfcRelDefinesByProperties}. The model views based on these queries are
automatically generated by considering G = {} and a set of concepts (i.e.
C ) that depends on the query. We also list the results obtained when
addressing the above-mentioned queries over the different projects
considered. The # symbol in Tables 3 and 5 represents the cardinality of
a given set (e.g. the number of STEP instances).
Table 4 gives additional details regarding the IfcView queries and
their descriptions.
Table 3 demonstrates that for each STEP instance in the extracted
building view, our approach creates an in-memory Java object. To il-
lustrate the impact of R in the IfcView query, let us consider the In-
stitute Var IFC project. It contains 77 doors. When querying a view
holding all these doors, we could naively expect that only 77 in-
memory objects (i.e. STEP instances) would be created. However, this is
not true, as 40,294 in-memory objects are created. Consequently, the
view holding all the doors of the Institute Var project contains 40,294
STEP instances. This is because of two main reasons:
1. Our approach considers all R relations of each door instance with
other IFC objects by also including their R relations.
2. For each IFC object or relationship, our approach retrieves their
attributes. An attribute value can be an instance of some IFC entity.
For example, the geometric data (e.g. a Cartesian point set) of a door
encapsulated in an IfcRepresentation11 instance.
Table 7 illustrates the different buildings as contained in the
http://www.buildingsmart-tech.org/ifc/IFC2x3/TC1/html/psd/
IfcSharedBldgElements/Pset_WallCommon.xml.
http://purl.org/ifcview/ifcrepresentation.
T.M.d. Farias et al. Automation in Construction 92 (2018) 214–229

Fig. 3. The “Duplex apartment” building project.

Listing 7. An ensemble of Horn-like rules that defines the external building

elements (i.e. the building envelope).

associated STEP files used to evaluate our prototype. Table 7 also dis-
Listing 5. A Horn-like rule that classifies external doors (i.e. IfcDoor instances)
plays the different building views obtained when using our prototype.
of a building as a BimExternalDoor concept.
All extracted building views include IFC objects associated somehow
with queried elements by using IfcRelationship subtypes (i.e. R set). For
example, for all mentioned building projects, resulted views contain
various walls from the original building, although we did not directly
query for these building objects. This is due to the fact that doors and
windows are obligatorily related to opening spaces in walls by using
IfcRelVoidsElement and IfcRelFillsElement relationships. Thus, the walls
related to windows and doors are also considered for the building view
construction.

Listing 6. A Horn-like rule that classifies external windows (i.e. IfcWindow

instances) of a building as a BimExternalWindow concept.

222
T.M.d. Farias et al. Automation in Construction 92 (2018) 214–229

Fig. 4. An example of IFC relationships that are present in R such as IfcRelContainedInSpatialStructure and IfcRelVoidsElement. The IfcRelAggregates relationship is a
subtype of IfcRelDecomposes relationship.

Fig. 5. The building envelope of the “Duplex apartment” building project.

223
T.M.d. Farias et al. Automation in Construction 92 (2018) 214–229

Table 3
The description of additional case studies and generated model views based on the queries described in Table 4 using our IfcView prototype. The “–” character means
not applicable and the "#" character means cardinality.
Institute Var project Institute Var extracted Medical clinic project Medical clinic extracted High-school project High-school extracted
original data IFC STEP view original data IFC STEP view original data IFC STEP view

IFC STEP file In Ref. [63] In Ref. [64] In Ref. [65] In Ref. [64] < Private model > In Ref. [64]
SPF file size 6.1 MB 2.2 MB 112.6 MB 1.7 MB 117.2 MB 22.6 MB
TTL file size 27.6 MB – 784.4 MB – 1.02 GB –
#STEP instances 104,226 40,294 1,904,600 23,484 2,057,114 417,341
#Triples 341,473 – 9,770,674 – 12,649,101 –
#In-memory – 40,294 – 23,484 – 417,341
objects
#Door instances 77 77 247 247 347 347
#Window instances 0 0 47 47 0 0
#Stair instances 0 0 0 0 48 48

Table 4
The IfcView queries and performance results in terms of execution time for the additional case studies described in Table 3 using our IfcView prototype.
IFC Project Query description IfcView query Execution time

Institute Var Retrieve all building doors and related instances such as property sets, opening C = {IfcDoor}, R and G = ϕ -Import phase: ≈17 s
elements and walls (based on R set). -Total(import+export):≈12.2 min
Medical clinic Retrieve all building doors, windows and related instances such as property sets, C = {IfcDoor, IfcWindow}, R and -Import phase: ≈169 s
opening elements and walls (based on R set). G =ϕ -Total(import+export):≈17.5 min
High-school Retrieve all building doors, stairs and related instances such as property sets, C = {IfcDoor, IfcStair}, R and -Import phase: ≈219 s
opening elements and walls (based on R set.) G =ϕ -Total (import+export): ≈19 h

Table 5 value is an instance i of a given IFC entity, additional queries are re-
The description of Vileda Dach case study and extracted IFC STEP based model cursively executed to retrieve instance i’s attribute values. By calling the
views by considering the Q1, Q2 and Q3 queries using our IfcView prototype. function in Algorithm 3, our IfcView approach also takes into account
Table 6 describes these queries. The “–" and “#” characters mean not applicable R set. Hence, more queries are executed to retrieve instances related to
and cardinality, respectively. the two wall instances initially selected (according to R set and their
Characteristics IFC original (Q1) (Q2) IFC (Q3) IFC attributes). Therefore, the number of queries addressed over a KB sig-
data IFC view view nificantly increases with the number of instances in C . Table 5 shows
view that the C sets generated by applying Q1, Q2 and Q3 queries contain
Vileda SPF file size 80.1 MB 55 KB 3.9 MB 20.1 MB
2989 and 2700 instances, respectively. Consequently, the number of in-
Dach TTL file size 903.9 MB – – – memory Java objects (i.e. I in Algorithm 1) and STEP instances in the
pro- #STEP instances 1,341,280 456 43,812 301,609 IFC view can only increase when comparing Q1 to Q3. Table 5 ex-
ject #Triples 11,037,833 – – – emplifies this fact. Q3 retrieves 2 walls, 987 columns and 1711 beams
#In-memory Java – 456 43,812 301,609
and other 298,909 connected instances by considering the R set and
objects
#Wall instances 2 2 2 2 instances’ attributes such as geometric data.
#Column 987 0 987 987 Although the main contribution of this paper is to demonstrate the
instances feasibility of applying semantic web technologies to automate the IFC
#Beam instances 1711 0 0 1711 STEP based model view extraction, in the next paragraphs, we focus on
(#Wall + 2700 2 989 2700
#Column +
explaining the performance issues in terms of execution time.
#Beam) instances Furthermore, we list several potential optimization for improving the
IFC STEP file Available in Model views for Q1, Q2 and Q3 overall approach presented here.
Ref. [66] queries are available in Ref. [64] As an improvement, one could envision parallelizing the “SELECT”
queries in Algorithm 1. Still, each query execution time comprises la-
tency time (i.e. disk access and memory load). As a reminder, we don’t
6.3. Results discussion
load any portions of the building model in memory. Because of this,
several accesses are made to the SSD disk used for implementation. For
When looking at the different benchmarks presented in Tables 3, 4,
creating these objects, our current IfcView prototype implementation
5 and 6, one may notice that, with our prototype, the time needed to
(based on Algorithm 1) demands to execute numerous queries over the
extract the different views drastically raises when compared to the
KB. Therefore, several disk accesses are necessary. By further analyzing
query complexity and its retrieved results. This is mainly justified by
Table 6, we notice that the time needed to populate the I set in
the fact that our prototype does not load the building model into
Algorithm 1, represents 73%, 50% and 69% for Q1, Q2 and respectively
memory (see Algorithm 1). Moreover, thousands of queries are exe-
Q3, of the total time needed for the export phase. These rates demon-
cuted sequentially. To illustrate this, let us consider the execution of the
strate that in average more than half of the execution time during the
Q1, Q2 and Q3 queries to extract model views from the Vileda Dach IFC
export phase is due to the various queries sequentially addressed over
project. These queries are described in Table 6. When considering Q1 as
the KB and implying numerous disk accesses. Algorithm 1 contains as a
an input of Algorithm 1, two wall instances are retrieved by querying
final instruction the writing of the extracted the view as an IFC STEP
the KB. Once these instances are retrieved, for each attribute of a wall
file. In our prototype, we naively implement an IFC STEP writer that
instance a query is executed. As a reminder, an IfcWall instance con-
reads the original file line by line. For each line, we verify if the line’s
tains eight attributes, thus eight queries are executed for each wall
STEP identifier is in the lines list (see Algorithm 1). If yes, then the line
instance for retrieving its attribute values. Moreover, if an attribute
is added to a string list. This list is used for the creation the IFC STEP-

224
T.M.d. Farias et al.
Table 6
The description of the Q1, Q2 and Q3 IfcView queries and performance results in terms of execution time to extract three different model views from the Vileda Dach
project using our IfcView prototype. Table 5 describes the original Vileda Dach IFC project and the resulted IFC STEP based views by applying Q1, Q2 and Q3 queries.
Query Query description
Q1 Retrieve all building walls and related instances such as property sets (based on R
set).
Q2 Retrieve all building walls, columns and related instances such as property sets
(based on R set).
Q3 Retrieve all building walls, columns, beams and related instances such as property
sets (based on R set).
based file representing the extracted view. The so-implemented IFC
writer is far from being optimized for large IFC files. This is why, with
our approach, ≈6 hours are needed to write the IFC view corre-
sponding to the execution of Q3 over the Vileda Dach project, out of the
22 hours needed for the total extraction time (see Tables 6 and 7).
Finally, for all these tests, we created one single KB containing all
building data. As our approach is based on STEP identifiers, we could
limit the portion of data to be loaded — we do not need to load all
building data, solely a portion of it is necessary. This can significantly
optimize the time needed for constructing the building view. The next
section gives additional optimization ideas for our prototype.
The partial IFC models generated by our prototype (after view ex-
traction, see Fig. 5 and Table 7) are available in Ref. [64] .
7. Conclusions and future works
In this article, we have depicted a methodology for extracting
building views based on logical rules applied on top of the standard
OWL/RDF serialization of the IFC standard [6]. This approach answers
the need of stakeholders (acting in the context of BIM) for having in-
teroperability among standards while being able to adapt those to their
specific needs (e.g. by conceiving model views). In our approach, we
have used semantic web technologies for defining new concepts by
means of logical rules, thus separating the BIM data structure model
(e.g. the IFC schema) from its semantics. Therefore, we can increase the
expressivity of the data model without compromising interoperability
when exchanging IFC files. The article at hand has illustrated the main
benefits of having developed such business-specific rules. These rules
allow for enriching the semantics of a building model. Such semantical
enrichment contributes to a flexible and easy implementation of a rule-
based approach to extract building model views. As a reminder, this
work focuses on extracting a portion of a given IFC file rather than
enriching the IFC file. In the context of this work, we enrich the
building model only at the ontological level in order to extract building
views. Our building view extraction approach is not able to auto-
matically update the set of rules based on changes in the IFC schema.
Several optimizations are possible and can be applied to our IfcView
prototype. They are enumerated below:
1. Compose more complex queries. For instance, currently, a query is
executed to retrieve each IFC object property value. This could be
adapted into one unique query for retrieving all the properties of an
IFC object.
2. Analyze the trade-off between composing simple queries and
225
Automation in Construction 92 (2018) 214–229
IfcView query Execution time
C = {IfcWall}, R and G = ϕ – Import phase: ≈181 s
– Export phase: ≈16.9 s
– In-memory objects: ≈12.3 s
– Total (import + export):
≈197.9 s
C = {IfcWall, IfcColumn}, R and G = ϕ – Import phase: ≈181 s
– Export phase: ≈64 min
– In-memory objects: ≈31.9 min
– Total (import + export):
≈67 min
C = {IfcWall, IfcColumn, IfcBeam}, R and – Import phase: ≈181 s
G=ϕ – Export phase: ≈22.35 h
– In-memory objects: ≈16.10 h
– Total (import + export): ≈22.4 h
complex queries.
3. Use query parallelization and in memory access. As a reminder,
each query in our prototype has a latency time that is composed of
the disk access time (a time-consuming task). Therefore, a result of
the current implementation is that the total query time increases
exponentially with the number of executed queries. Indeed, with the
current implementation, queries are processed sequentially. But, not
every query depends on results from previous ones. Thus, some of
them could be executed in parallel, therefore reducing the overall
view extraction time.
4. Optimize the writing of an IFC partial file. Our prototype for writing
and reading IFC files can be further improved (at the code level).
5. Reduce the size of data imported into the KB. Indeed, our prototype
considers STEP IDs for select lines from the original SPF file.
Therefore, the vast majority of data values present in an IFC file (e.g.
string and number values) are not necessary to construct building
views with our approach. As an optimization, we may solely con-
sider object values (e.g. instances of concepts, classes). By doing so,
we can significantly reduce the size of the KB, and improve query
execution time.
6. Use in memory load of a portion of (or all of) the so-created KB (that
does not contain data values). As mentioned before, disk access time
highly impacts query latency time. In other words, with the current
implementation, each query must access the disk to retrieve data
(nothing is previously stored in memory). This optimization would
allow for reducing the time needed for extracting a view.
Besides the above considerations, future work will address the
comparison of using SWRL syntax against other rule syntaxes (e.g. the
RIF syntax, as defined by the W3C) in order to address SWRL limitations
as identified in Ref. [36]. Last but not least, we will consider the need
for inconsistencies or ambiguities checking by introducing new rules
and for automatically updating the rule set based on changes in the IFC
standard, and consequently, in the ifcOWL ontology.
Acknowledgments
The authors would like to thank the Burgundy Regional Council for
its help and financing. The work presented in this paper is part of a
collaborative project with the French company Active3D who has fi-
nanced this research. The authors would also like to thank the Editors
and the anonymous reviewers for their constructive comments and
valuable suggestions to improve the quality of the article.
 Table 7
Original building models and building views extracted with our prototype.
Case Original 3D building model Extracted 3D building view
study
T.M.d. Farias et al.

Institute
Var

Medical
clinic

226
High-
scho-
ol

(continued on next page)

Automation in Construction 92 (2018) 214–229
T.M.d. Farias et al. Automation in Construction 92 (2018) 214–229

Appendix A

The rules defined in Listings 8–13 were adapted from Ref. [57] and the
rules are ordered from general (e.g. Listings 8–10) to more specific (e.g.
Listings 11–13). The rule in Listing 14 also demonstrates how we define
rules in a modular way (by considering the rules in Listings 8 and 9).

Listing 8. Rule S1 allows for inferring ifcview:hasPropertySet properties

that directly link objects and their property sets.

Listing 9. Rule S2 relies on rule S1 (Listing 8) and allows for inferring ifcvie-
w:hasProperty properties that directly link objects to individual properties.
Extracted 3D building view

Listing 10. Rule S3 relies on rule S2, which in turn relies on rule S1 (Listings 8 and
9), and allows for inferring the value for the property ifcview:isExternal,
which is typically associated to door, window, and wall elements.

Listing 11. Rule S4 relies on rule S3 (Listing 10), which furthermore relies on rule
S1 and S2 (Listings 8 and 9). Rule S4 allows for inferring whether a wall is of type
ifcview:ExternalWall or not.

Listing 12. Rule S5 relies on rule S3 (Listing 10), which furthermore relies on rule
S2 and S1 (Listings 8 and 9). Rule S5 allows for inferring whether a window is of
type ifcview:ExternalWindow or not.

Listing 13. Rule S5 relies on rule S3 (Listing 10), which furthermore relies on rule
S2 and S1 (Listings 8 and 9). Rule S5 allows for inferring whether a door is of type
ifcview:ExternalDoor or not.
Original 3D building model
Table 7 (continued)

Listing 14. Rule S7 relies on rule S2, which in turn relies on rule S1 (Listings 8 and
9), and allows for inferring the value of the property ifcview:occupancy-
Dach
(Q3)

Number, which is typically associated to an architectural program for a space (i.e.

Vileda
study
Case

IfcSpaceProgram) in the building being designed.

227
T.M.d. Farias et al.
References
[1] R. Volk, J. Stengel, F. Schultmann, Building Information Modeling (BIM) for
existing buildings — literature review and future needs, Autom. Constr. 38 (2014)
109–127 http://www.sciencedirect.com/science/article/pii/
S092658051300191Xhttp://dx.doi.org/10.1016/j.autcon.2013.10.023.
[2] G. Lee, R. Sacks, C.M. Eastman, Specifying parametric building object behavior
(BOB) for a building information modeling system, Autom. Constr. 15 (6) (2006)
758–776 http://www.sciencedirect.com/science/article/pii/S0926580505001445
http://dx.doi.org/10.1016/j.autcon.2005.09.009 (knowledge Enabled Information
System Applications in Construction).
[3] R. Vanlande, C. Nicolle, C. Cruz, IFC and building lifecycle management, Autom.
Constr. 18 (1) (2008) 70–78 http://www.sciencedirect.com/science/article/pii/
S0926580508000800http://dx.doi.org/10.1016/j.autcon.2008.05.001.
[4] Autodesk, Inc., AutoCAD 2012 - DXF Reference, (2011) available online at http://
images.autodesk.com/adsk/files/autocad_2012_pdf_dxf-reference_enu.pdf last ac-
cessed: 2018-02-20.
[5] Open Design Alliance Inc., Open Design Specification for .dwg files (version 5.4.1),
(2018) available online at http://opendesign.com/files/guestdownloads/
OpenDesign_Specification_for_.dwg_files.pdf last accessed: 2018-02-20.
[6] buildingSMART, IFC Overview summary, (2018) available online at http://www.
buildingsmart-tech.org/specifications/ifc-overview last accessed: 2018-02-20.
[7] A.P. Sheth, J.A. Larson, Federated database systems for managing distributed,
heterogeneous, and autonomous databases, ACM Comput. Surv. 22 (3) (1990)
183–236 http://doi.acm.org/10.1145/96602.96604http://dx.doi.org/10.1145/
96602.96604.
[8] buildingSMART, Linked Data — Overview Page for the Linked Data Working
Group, (2018) available online at http://www.buildingsmart-tech.org/future/
linked-data/linked-data last accessed: 2018-02-20.
[9] Žiga Turk (project coordinator), Interoperability of Virtual Organizations on a
Complex Semantic Grid. (2007) available online at http://inteligrid.eu-project.info
last accessed: 2018-02-20.
[10] J. Beetz, J. Van leeuwen, B. De vries, IfcOWL: a case of transforming EXPRESS
schemas into ontologies, Artif. Intell. Eng. Des. Anal. Manuf. 23 (1) (2009) 89–101,
http://dx.doi.org/10.1017/S0890060409000122.
[11] P. Pauwels, W. Terkaj, EXPRESS to OWL for construction industry: towards a
recommendable and usable ifcOWL ontology, Autom. Constr. 63 (2016) 100–133
http://www.sciencedirect.com/science/article/pii/S0926580515002435http://dx.
doi.org/10.1016/j.autcon.2015.12.003.
[12] R. Barbau, S. Krima, S. Rachuri, A. Narayanan, X. Fiorentini, S. Foufou, R.D.
Sriram, OntoSTEP: enriching product model data using ontologies, Comput. Aided
Des. 44 (6) (2012) 575–590 http://www.sciencedirect.com/science/article/pii/
S001044851200022Xhttp://dx.doi.org/10.1016/j.cad.2012.01.008.
[13] P. Pauwels, T. Krijnen, W. Terkaj, J. Beetz, Enhancing the ifcOWL ontology with
an alternative representation for geometric data, Autom. Constr. 80 (2017) 77–94
http://www.sciencedirect.com/science/article/pii/S0926580517301826http://dx.
doi.org/10.1016/j.autcon.2017.03.001.
[14] T.M. de Farias, A. Roxin, C. Nicolle, IfcWoD, Semantically Adapting IFC Model
Relations into OWL Properties, Proceedings of the 32nd CIB W78 Conference on
Information Technology in Construction, Eindhoven, The Netherlands, 27-29
October, 2015, pp. 175–185 http://itc.scix.net/cgi-bin/works/Show?w78-2015-
paper-018.
[15] T.M. Farias, A. Roxin, C. Nicolle, A Rule Based System for Semantical Enrichment of
Building Information Exchange, Proceedings of the RuleML 2014 Challenge and the
RuleML 2014 Doctoral Consortium hosted by the 8th International Web Rule
Symposium, Challenge+DC@RuleML 2014, Prague, Czech Republic, August 18-20,
2014, 2014 http://ceur-ws.org/Vol-1211/paper2.pdf.
[16] M.J. Dibley, An Intelligent System for Facility Management (Doctoral Dissertation),
(2011) available online at https://orca.cf.ac.uk/23277/1/2012DibleyMJPhD.pdf
last accessed: 2018-02-20.
[17] buildingSMART, MVD Overview Summary, (2018) available online at http://www.
buildingsmart-tech.org/specifications/mvd-overview/mvd-overview-summary last
accessed: 2018-02-20.
[18] M. Venugopal, C. Eastman, R. Sacks, J. Teizer, Semantics of model views for
information exchanges using the industry foundation class schema, Adv. Eng.
Inform. 1474-0346, 26 (2) (2012) 411–428 http://www.sciencedirect.com/
science/article/pii/S1474034612000067 http://dx.doi.org/10.1016/j.aei.2012.01.
005 Knowledge based engineering to support complex product design.
[19] P. Pauwels, D.V. Deursen, R. Verstraeten, J.D. Roo, R.D. Meyer, R.V. de Walle,
J.V. Campenhout, A semantic rule checking environment for building performance
checking, Autom. Constr. 20 (5) (2011) 506–518 http://www.sciencedirect.com/
science/article/pii/S0926580510001962http://dx.doi.org/10.1016/j.autcon.2010.
11.017.
[20] J. Beetz, B. De Vries, J. Van Leeuwen, RDF-based distributed functional part spe-
cifications for the facilitation of service-based architectures, Proceedings of the 24th
CIB-W78 Conference on Information Technology in Construction, Maribor,
Slovenia, June, 2007, pp. 183–188 http://itc.scix.net/cgi-bin/works/Show?w78_
2007_39.
[21] J. Beetz, J. van Leeuwen, B. de Vries, An ontology web language notation of the
industry foundation classes, Proceedings of the 22nd CIB W78 Conference on
Information Technology in Construction, 2005, pp. 193–198 http://itc.scix.net/cgi-
bin/works/Show?w78-2005-d1-4-beetz.
[22] M. Belsky, R. Sacks, I. Brilakis, Semantic enrichment for building information
modeling, Comput. Aided Civ. Infrastruct. Eng. 31 (4) (2016) 261–274, http://dx.
doi.org/10.1111/mice.12128.
228
Automation in Construction 92 (2018) 214–229
[23] buildingSMART, Coordination View Version 2.0 Summary, (2018) available online
at http://www.buildingsmart-tech.org/specifications/ifc-view-definition/
coordination-view-v2.0 last accessed: 2018-02-20.
[24] Y.-C. Lee, C.M. Eastman, W. Solihin, Logic for ensuring the data exchange in-
tegrity of building information models, Autom. Constr. 0926-5805, 85 (2018)
249–262 http://www.sciencedirect.com/science/article/pii/
S0926580517307276http://dx.doi.org/10.1016/j.autcon.2017.08.010.
[25] Z. Ma, Z. Liu, Z. Wei, Formalized representation of specifications for construction
cost estimation by using ontology, Comput. Aided Civ. Infrastruct. Eng. 31 (1)
(2016) 4–17, http://dx.doi.org/10.1111/mice.12175.
[26] S. Grimm, A. Abecker, J. Völker, R. Studer, Ontologies and the Semantic Web,
Springer Berlin Heidelberg, Berlin, Heidelberg, 978-3-540-92913-0, 2011, pp.
507–579, http://dx.doi.org/10.1007/978-3-540-92913-0_13.
[27] V. Haarslev, H.-I. Pai, N. Shiri, Uncertainty Reasoning for the Semantic Web I,
Springer-Verlag, Berlin, Heidelberg, 2008, pp. 385–402, http://dx.doi.org/10.
1007/978-3-540-89765-1_22 (Ch. Uncertainty Reasoning for Ontologies with
General TBoxes in Description Logic).
[28] World Wide Web Consortium (W3C), Semantic Web: Inference, (2015) available
online at http://www.w3.org/standards/semanticweb/inference last accessed:
2018-02-20.
[29] M. Dean, G. Schreiber, S. Bechhofer, F. Van Harmelen, J. Hendler, I. Horrocks,
D.L. McGuinness, P.F. Patel-Schneider, L.A. Stein, OWL Web Ontology Language
Reference. W3C Recommendation, (2004) available online at www.w3.org/TR/
2004/REC-owl-ref-20040210 last accessed: 2018-02-20.
[30] B. Motik, P.F. Patel-Schneider, B.C. Grau, OWL 2 Web Ontology Language Direct
Semantics (Second Edition). W3C Recommendation, (2012) available online at
https://www.w3.org/TR/owl2-direct-semantics/ last accessed: 2018-02-20.
[31] F. Baader, D. Calvanese, D.L. McGuinness, D. Nardi, P.F. Patel-Schneider (Eds.), The
description logic handbook: theory, implementation, and applications, Cambridge
University Press, 0-521-78176-0, 2003.
[32] E. Sirin, B. Parsia, B.C. Grau, A. Kalyanpur, Y. Katz, Pellet: a practical OWL-DL
reasoner, Web Semant. 5 (2) (2007) 51–53, http://dx.doi.org/10.1016/j.websem.
2007.03.004.
[33] B. Glimm, I. Horrocks, B. Motik, G. Stoilos, Z. Wang, HermiT: an OWL 2 reasoner,
J. Autom. Reason. 0168-7433, 53 (3) (2014) 245–269, http://dx.doi.org/10.1007/
s10817-014-9305-1.
[34] I. Horrocks, P.F. Patel-Schneider, H. Boley, S. Tabet, B. Grosof, M. Dean, SWRL: A
Semantic Web Rule Language Combining OWL and RuleML, (2004) This W3C
Member submission is available online at https://www.w3.org/Submission/SWRL/
last accessed: 2018-02-20.
[35] B. Motik, U. Sattler, R. Studer, Query answering for OWL-DL with rules, Web
Semant. Sci. Serv. Agents World Wide Web 1570-8268, 3 (1) (2005) 41–60 http://
www.sciencedirect.com/science/article/pii/S157082680500003X http://dx.doi.
org/10.1016/j.websem.2005.05.001 Rules Systems.
[36] buildingSMART, Report on Open Standards for Regulations, Requirements and
Recommendations Content, (2017) available online at https://buildingsmart-
1xbd3ajdayi.netdna-ssl.com/wp-content/uploads/2017/11/17-11-08-Open-
Standards-for-Regulation.pdf last accessed: 2018-02-20.
[37] J. Euzenat, Networks of Ontologies and Alignments, M2R SWXO Lecture Notes,
(2011) available online at https://pdfs.semanticscholar.org/c6c5/
6c90b1fc60d74a2fe3545cab50ccdae2dbec.pdf last accessed: 2018-02-20.
[38] K.R. Apt, From Logic Programming to Prolog, Prentice-Hall, Inc., Upper Saddle
River, NJ, USA, 0-13-230368-X, 1996.
[39] J.H. Gallier, Logic for Computer Science: Foundations of Automatic Theorem
Proving, Second Edition, Dover Publications, Inc., New York, NY, USA, 2015
ISBN:0486780821, ISBN:9780486780825.
[40] S. Russell, P. Norvig, The Artificial Intelligence, 3rd Edition, Prentice Hall Press,
Upper Saddle River, NJ, USA, 2010 ISBN:9780136022923.
[41] S. Bechhofer, Hoolet, (2004) available online at http://owl.man.ac.uk/hoolet/ last
accessed: 2018-02-20.
[42] M. Jang, J.-C. Sohn, Bossam: an extended rule engine for OWL inferencing, in:
G. Antoniou, H. Boley (Eds.), Rules and Rule Markup Languages for the Semantic
Web, Springer Berlin Heidelberg, Berlin, Heidelberg, 978-3-540-30504-0, 2004, pp.
128–138.
[43] B. Motik, Reasoning in Description Logics using Resolution and Deductive
Databases, (2006) available online at https://publikationen.bibliothek.kit.edu/
1000003797/1437 last accessed: 2018-02-20.
[44] B. Motik, U. Sattler, A Comparison of Reasoning Techniques for Querying Large
Description Logic ABoxes, Proceedings of the 13th International Conference on
Logic for Programming, Artificial Intelligence, and Reasoning, LPAR’06, Springer-
Verlag, Berlin, Heidelberg, 978-3-540-48282-6, 2006, pp. 227–241, , http://dx.doi.
org/10.1007/11916277_16.
[45] J. Mei, L. Ma, Y. Pan, Ontology Query Answering on Databases, Proceedings of the
5th International Conference on The Semantic Web, ISWC’06, Springer-Verlag,
Berlin, Heidelberg, 978-3-540-49029-6, 2006, pp. 445–458, , http://dx.doi.org/10.
1007/11926078_32.
[46] D. Elenius, SWRL-IQ: A Prolog-based Query Tool for OWL and SWRL, Proceedings
of OWL: Experiences and Directions (OWLED) Workshop, Heraklion, Crete, Greece,
May 27–28, 2012 http://ceur-ws.org/Vol-849/paper_17.pdf.
[47] E. Rigas, G. Meditskos, N. Bassiliades, SWRL2COOL: Object-oriented
Transformation of SWRL in the CLIPS Production Rule Engine, Proceedings of the
7th Hellenic Conference on Artificial Intelligence: Theories and Applications,
SETN’12, Springer-Verlag, Berlin, Heidelberg, 978-3-642-30447-7, 2012, pp.
49–56, , http://dx.doi.org/10.1007/978-3-642-30448-4_7.
[48] G. Meditskos, N. Bassiliades, A rule-based object-oriented OWL reasoner, IEEE
Trans. Knowl. Data Eng. 1041-4347, 20 (3) (2008) 397–410, http://dx.doi.org/10.
T.M.d. Farias et al.
1109/TKDE.2007.190699.
[49] B. Parsia, E. Sirinb, B.C. Graua, E. Ruckhausa, D. Hewlettb, Cautiously approaching
SWRL, University of Maryland, Tech. Rep, 2005 available online at http://citeseerx.
ist.psu.edu/viewdoc/download?doi=10.1.1.222.7885&rep=rep1&type=pdf last
accessed:2018-02-20.
[50] V. Haarslev, K. Hidde, R. Möller, M. Wessel, The Racerpro knowledge re-
presentation and reasoning system, Semant. Web 1570-0844, 3 (3) (2012) 267–277,
http://dx.doi.org/10.3233/SW-2011-0032.
[51] B. Motik, R. Shearer, I. Horrocks, Hypertableau Reasoning for Description Logics,
J. Artif. Int. Res. 1076-9757, 36 (1) (2009) 165–228 http://dl.acm.org/citation.
cfm?id=1734953.1734957.
[52] Stardog Union, Stardog 5: The Manual, (2018) available online at http://docs.
stardog.com/ last accessed: 2018-02-20.
[53] The Apache Software Foundation, Reasoners and Rule Engines: Jena Inference
Support, (2017) available online at https://jena.apache.org/documentation/
inference/ last accessed: 2018-02-20.
[54] P. Pauwels, EXPRESS to OWL tool, (2017) available online at https://github.com/
pipauwel/EXPRESStoOWL last accessed: 2018-02-20.
[55] P. Pauwels, IFC to RDF tool, (2017) available online at https://github.com/
pipauwel/IFCtoRDF last accessed: 2018-02-20.
[56] The W3C SPARQL Working Group, SPARQL 1.1 Overview W3C Recommendation
21 March 2013, (2013) available online at https://www.w3.org/TR/sparql11-
overview/ last accessed: 2018-02-20.
[57] P. Pauwels, T.M. de Farias, C. Zhang, A. Roxin, J. Beetz, J.D. Roo, C. Nicolle, A
performance benchmark over semantic rule checking approaches in construction
industry, Adv. Eng. Inform. 33 (2017) 68–88 http://www.sciencedirect.com/
science/article/pii/S1474034617301945http://dx.doi.org/10.1016/j.aei.2017.05.
001.
[58] The Apache Software Foundation, Apache Jena, (2015) available online at https://
jena.apache.org/ last accessed: 2018-02-20.
229
Automation in Construction 92 (2018) 214–229
[59] J. De Roo, Euler Yet Another Proof Engine — EYE, (2018) available online at
http://eulersharp.sourceforge.net/ last accessed: 2018-02-20.
[60] International Organization for Standardization (ISO), ISO 10303-21:2016 Industrial
Automation Systems and Integration — Product Data Representation and Exchange
— Part 21: Implementation Methods: Clear Text Encoding of the Exchange
Structure, (2016) available online at https://www.iso.org/standard/63141.html
last accessed: 2018-02-20.
[61] D. Beckett, T. Berners-Lee, E. Prud’hommeaux, G. Carothers, RDF 1.1 Turtle - Terse
RDF Triple Language - W3C Recommendation 25 February 2014, (2014) available
online at https://www.w3.org/TR/turtle/ last accessed: 2018-02-20.
[62] International Organization for Standardization (ISO), Industrial Automation
Systems and Integration - Product Data Representation and Exchange — Part 11:
Description Methods: The EXPRESS Language Reference Manual, (2004) available
online at https://www.iso.org/standard/38047.html last accessed: 2018-02-20.
[63] P. Pauwels, IFC Repository — The IFC STEP File of the Institute-Var Project, (2008)
available online at http://smartlab1.elis.ugent.be:8889/IFC-repo/http.
openifcmodel.cs.auckland.ac.nz/261110Allplan-2008-Institute-Var-2-IFC.ifc last
accessed: 2018-02-20.
[64] T.M. de Farias, A. Roxin, C. Nicolle, IfcView Approach — Building Model View
Extraction Examples, (2017) available online at https://github.com/tarcisiotmf/
ifcview/tree/master/ifcview%20results last accessed: 2018-02-20.
[65] P. Pauwels, IFC Repository — The IFC STEP File of the Medical Clinic Project,
(2010) available ontline at http://smartlab1.elis.ugent.be:8889/IFC-repo/http.
openifcmodel.cs.auckland.ac.nz/161210Med_Dent_Clinic_Combined.ifc last ac-
cessed: 2018-02-20.
[66] P. Pauwels, IFC Repository — The IFC STEP File of the Vileda Dach Project, (2014)
available online at http://smartlab1.elis.ugent.be:8889/IFC-repo/20151023_
TeklaBIMAwards2014/modell-vileda/08001_Vileda_Dach.ifc last accessed: 2018-
02-20.