Automation in Construction 20 (2011) 506–518

Contents lists available at ScienceDirect

Automation in Construction
j o u r n a l h o m e p a g e : w w w. e l s ev i e r. c o m / l o c a t e / a u t c o n

A semantic rule checking environment for building performance checking

P. Pauwels a,b,⁎, D. Van Deursen c, R. Verstraeten a,b, J. De Roo c, R. De Meyer a,
R. Van de Walle c, J. Van Campenhout b
a
Department of Architecture and Urban Planning, Ghent University, J. Plateaustraat 22, B-9000 Ghent, Belgium
b
Department of Electronics and Information Systems, Ghent University, Sint-Pietersnieuwstraat 41, B-9000 Ghent, Belgium
c
Department of Electronics and Information Systems, Multimedia Lab, Ghent University-IBBT, Gaston Crommenlaan 8 bus 201, B-9050 Ledeberg-Ghent, Belgium

a r t i c l e i n f o a b s t r a c t

Article history: Today's construction industry relies heavily on high-performing building information modelling (BIM)
Accepted 4 November 2010 systems. By deploying the Industry Foundation Classes (IFC) as a description language, these systems offer
Available online 13 December 2010 building information in a widely interoperable format, so that several applications are able to infer extra
information. For a certain functionality, IFC shows limitations however. Existing semantic web technology
Keywords:
may be able to overcome these limitations, thereby enabling a range of significant improvements and
Semantic web
Construction industry
possibilities for automation in building design and construction. This paper gives a short overview of the
Rule checking functionality of IFC as a language, compared to the functionality of languages deployed in the semantic web
Reasoning domain. The improvements generated by deploying semantic web languages are briefly discussed, after
which a concrete implementation approach is presented for a semantic rule checking environment for
building design and construction. An implemented test case for acoustic performance checking illustrates the
improvements of such an environment compared to traditionally deployed approaches in rule checking.
© 2010 Elsevier B.V. All rights reserved.

1. Introduction initiatives have emerged concentrating on the management and

Current architectural design and construction processes become
more complex every day because of the introduction of new building
technologies, research outcomes and increasingly stringent building
codes. As a result, an architect is not only responsible for the design
and construction of a building, he also needs to comply with acoustic
standards, fire safety regulations, energy performance requirements,
etc. He is also more and more subject to increasing expectations on
several knowledge domains, striving towards building designs with
better performance and quality. These challenges require an intense
communication among project participants, and a profound evalua-
tion of the building design starting from the earliest stages in the
design process.
1.1. Information management in construction industry
Several software tools are available to help a designer manage a
building design project and the associated requirements. Numerous
⁎ Corresponding author. Tel.: + 32 9 264 8917, + 32 486 791488; fax: + 32 9 264
4185.
E-mail addresses: pipauwel.pauwels@ugent.be (P. Pauwels),
davy.vandeursen@ugent.be (D. Van Deursen), ruben.verstraeten@ugent.be
(R. Verstraeten), jos.deroo@agfa.be (J. De Roo), ronald.demeyer@ugent.be
(R. De Meyer), rik.vandewalle@ugent.be (R. Van de Walle),
jan.vancampenhout@ugent.be (J. Van Campenhout).
visualisation of this information, typically building on the concept of
product data management (PDM) and information modelling (IM).
Building information modelling (BIM) can be named as one of the
most notable efforts in recent years regarding information manage-
ment in the construction industry [1]. BIM modellers typically provide
different ‘specialised’ model views (e.g. structural and architectural)
of a single building model within one and the same software suite.
Additionally, they aim at making the model accessible for applications
outside the BIM modelling environment through the Industry
Foundation Classes (IFC) [2]. The IFC language thus aims at providing
easy communication of construction-related information back and
forth between BIM modelling environments and other IFC-compatible
software environments, thereby targeting a more integrated design
and construction process and thus a considerably improved construc-
tion process quality and efficiency [3].
Significant improvements were expected in the domain of rule
checking, with the emergence of rule checking environments capable of
assessing the features and characteristics of a building design (e.g.
energy performance level) based on the information available in an IFC
model. These software environments typically apply a set of procedures
to the information model, thereby deriving new information and
eventually resulting in a ‘pass’, ‘fail’, ‘warning’ or ‘unknown’ message for
the assessed features. These improvements in terms of interoperability
are, however, not met as expected in practice [4]. The data structure of
IFC and the information contained within the IFC model often collide
with the information model deployed within the rule checking

0926-5805/$ – see front matter © 2010 Elsevier B.V. All rights reserved.
doi:10.1016/j.autcon.2010.11.017
 P. Pauwels et al. / Automation in Construction 20 (2011) 506–518
environment. In several approaches a conversion phase is therefore
required for converting the building model in IFC into a building model
containing the information needed by the rule checking environment.
Additionally, most rule checking environments seem forced to rely on a
procedural implementation approach, whereas a declarative imple-
mentation approach based on a rule language is indicated as the better
choice for rule checking environments.
1.2. Rule checking approaches in the construction industry
A good recent overview of such environments for building code
checking was recently given in [5], combined with an overview of rule
checking processes in general. We do not intend to give an equally
detailed overview of rule checking approaches in this paper. Instead,
we give a short overview of the conclusions and indicate how this
paper aims at contributing to the subject.
In [5], a rule checking process is separated into four phases,
thereby considering a rule interpretation phase, a building model
preparation phase, a rule execution phase, and a rule check reporting
phase. Each of these phases is discussed, combined with their
respective effects on the overall rule checking process. For the rule
interpretation phase, diverse approaches are discussed on how rules
in natural language may be best converted into computer under-
standable code. The output of this phase is a certain amount of com-
puter processable code, of which the level of flexibility, modularity
and functionality largely depends on the expressiveness of the rule
language chosen in the rule interpretation phase. This rule interpre-
tation phase is thus of crucial importance for the remainder of the rule
checking process. This phase will therefore be the primary focus of
this paper, whereas the effects on following phases will only be
outlined briefly.
Although in many rule interpretation approaches, an intermediate,
often logic-based language is deployed to map natural language rules
into a processable form, the actual implementation method is seldom
based on such a logic theory. Implementation methods are distin-
guished according to the usage of computer language encoded rules,
of parametric tables, or of a rule language to capture and implement
the rules [5]. The first two implementation methods, which are most
often used currently, are seldom based on a rigorous logic theory, in
contrast to the latter implementation method based on a rule
language, which could be based completely on first order predicate
logic for instance.
Several benefits of this implementation method based on a rule
language are outlined in [5]. This method would improve the por-
tability of the rules, making them usable not only on dedicated rule
checking servers, but also in design environments, simulation
environments, etc. Additionally, it would improve flexibility of
functionality, thereby making it possible to easily retarget the rule
checking process on native building model descriptions instead of on
the IFC exported building model. Furthermore, it would enable the
description of an unlimited range of rules, making an almost infinitely
in-depth rule checking process possible.
During the following discussion of rule checking environments in
[5], it becomes clear that, although very sophisticated and complex
rule checking processes can and are already implemented following
the first two approaches, an implementation method based on a rule
language for the rule interpretation phase would further enhance
a rule checking environment, both in terms of flexibility and of
modularity.
Such implementation methods have already been suggested in the
domain of conformance checking for the construction industry. In
[6,7], an implementation method was suggested based on semantic
web technology, more specifically deploying a semantic query
language to infer whether or not a building model is compliant with
the applicable building codes. A similar approach based on logic has
been suggested in [8] for rule checking in the conceptual architectural
507
design stage. For each of these approaches, it remains nonetheless to
be seen to what extent such a rule language compares with existing
approaches in terms of expressiveness.
1.3. Enhancing IFC for logic-based rule checking
When considering a logic-based rule checking environment for the
construction industry, one has to consider its source of information
first. Because the IFC schema was not explicitly designed for import
into rule checking environments, its specification is not based on a
logic theory. By enhancing IFC onto a logical level, one may enable the
design and implementation of significantly improved rule checking
systems. This will constitute the primary focus of this paper.
Additionally, the usage of a suitable different language may
overcome other existing barriers found in the usage of IFC. These
barriers have several causes, not always directly caused by the nature
of IFC. Most of them nonetheless find their origin in using IFC. Over-
coming these barriers is not essential in the scope of rule checking for
the construction industry, but it might provide valuable additional
improvements to IFC in general. Barriers considered in this paper are a
limited expression range, difficulties in the partitioning of information
and the possibility to describe the same information in numerous
ways.
1.4. Rule checking based on semantic web information
An appropriate description language based on a logic theory and
possibly able to enhance the additional challenges posed by the usage
of IFC, may very well be found in the semantic web domain [10]. In
this domain, a semantic web is constructed to represent information
on the world wide web (WWW) as a semantic network. This semantic
network describes concepts through a directed, labelled graph
(Fig. 1). Each node in this graph represents a concept or object in
the world and each arc in this graph represents the logical relation
between two of these concepts or objects. In other terms, the graph
represents a combination of logic-based declarative sentences, each
sentence consisting of two nodes and a relational arc. The meaning or
semantics of a concept is described through the graph associated with
this concept.
Next to the possibility to describe facts in a semantic network, the
semantic web domain also enables the description of rules using a rule
language similarly based on logic theory. As both the information
description language and the rule languages are thoroughly based on
logic theory, they can provide the possibility to implement a logic-based
ont:overallHeight “2180”
inst:WindowX
ont:hasOpening rdf:type
Element
ifc:IfcWindow
rdfs:domain
inst:OpeningElementY
xsd:double
rdfs:range
rdfs:subClassOf
ont:overallHeight
rdf:type rdf:type
rdf:type
owl:DataType
ifc:IfcOpening Property
Element
rdf:type
owl:Class
ifc:IfcBuilding rdf:type
Element
Fig. 1. A directed, labelled graph describing a window in an opening element.
508 P. Pauwels et al. / Automation in Construction 20 (2011) 506–518
rule checking system declaratively. This possibility applies to the main
limitation of IFC given above. Deploying a semantic rule language
should enable a declarative approach explicitly based on logic for the
implementation of a rule checking environment for building perfor-
mance checking. At a minimum this adds the advantages of flexibility
and modularity to the programming environment. Additionally, this
approach may solve other limitations of IFC as the ones indicated above.
This paper investigates the possibility of using both an information
description language and a rule language stemming from the
semantic web field as a possible enhancement of IFC for building
performance checking. We will first briefly compare the IFC standard
with the information description languages deployed in the semantic
web initiative. We will show how semantic rule languages are related
to the information contained in a semantic web. A preliminary rule
checking environment is presented able to describe both facts and
rules in these languages, to store them in a combined knowledge base
and to draw conclusions based on logical inferences. A short
discussion of an acoustic performance checking test case completes
the paper, thereby presenting our proposed methodology for per-
formance checking of a building design through a limited proof of
concept.
2. The description of information and rules
2.1. The Industry Foundation Classes
2.1.1. A desired future state: interoperability of information
Several languages were proposed within the field of product data
modelling to describe products and their data [11]. One of the most
successful is EXPRESS, an information modelling language defined in
ISO 10303-11:1994 [12]. This language “consists of language elements
which allow an unambiguous data definition and specification of
constraints on the data defined and by which aspects of product data
can be specified” [12]. EXPRESS was originally described as a part (Part
11) of the ISO 10303 standard, which is the international “Standard for
the Exchange of Product data” (STEP) [13]. The STEP standard uses
EXPRESS as its formal specification to define how product data should
be described and exchanged [14]. It contains several EXPRESS schemas
which can be used to describe products, thereby enabling the
exchange of this information using STEP compliant software tools.
Apart from STEP, other information models (e.g. EDIF) were proposed
as well, using EXPRESS as a general information modelling language
[15].
Information description in the construction industry was consid-
erably influenced by the STEP standard. IFC was in this regard de-
veloped as a separate EXPRESS schema within STEP [2] by
BuildingSMART, formerly known as the International Alliance for
Interoperability [16].
The EXPRESS schema of IFC [2] enables a description of
construction-related information through a network of entities, select
types, enumerations, attributes, collections, relations, etc. Following
the IFC schema one can define a description of a building in which the
defined objects have a well-defined and interrelated meaning and
purpose. As a single window element can internally be described in
very diverse ways by each BIM environment, the export and import
possibilities to and from IFC should guarantee that each BIM en-
vironment is able to map its own descriptions to a generally
understandable IFC format, thereby considerably improving interop-
erability of information. After several investigations and use cases
over the past few years, it has become clear that these expectations
are only partly met. Although almost all current BIM modellers
provide IFC exchange possibilities, the targeted exchange of building
information with other IFC compliant software applications goes not
as smooth as it was initially suggested [4].
Nevertheless, IFC is currently considered one of the most ap-
propriate schemas for improving information exchange and interop-
erability in the construction industry. New applications have been
developed, capable of parsing IFC models, interpreting and reusing
the available information. These software applications have mainly
concentrated on deriving additional information concerning specialised
domains of interest. Exemplary are energy performance calculations, in
which the energy performance level of the building is derived from the
model and compared to energy performance regulations [17], or
eGovernment platforms, in which an information model can be
submitted through a web portal in order to obtain a building permit
[18]. Other examples include automatic building cost calculation,
simulation of a four-dimensional building schedule, escape route
analysis, fire and evacuation simulation, etc.
2.1.2. Barriers in reaching the desired interoperability
The above workflow has its limitations, some of which seem
caused by the usage of the IFC schema. The following barriers or
limitations were found in the context of reusing IFC, partly based on
research presented in [4,9,11].
• Limited expression range
When designing a building, one is required to ‘restrain’ his or her
building design according to the IFC schema in order to gain the
advantages IFC can offer. This causes important limitations for instance
within the domain of architectural design, in which information is
often linked to information stemming from very other domains,
including for instance detailed geographic information, specialised
material characteristics, architecture-historical information, etc. Al-
though this is of lesser importance when confined to the domain of the
construction industry, this presents significant limitations when one
wants to reference or reuse detailed construction-related information
from within other knowledge domains, such as cultural heritage,
architectural theory, design thinking, etc.
• Difficulties in partitioning the information
As the IFC schema has a considerably large number of entities,
defined types, enumerations and select types, it is important to
provide users with the possibility to limit their scope to the
information they need, in order to maintain efficiency and quality in
the their work environment. A lot of research has focused on this
objective over the last years, including the in-depth research, design
and implementation of the Model View Definitions (MVD) concept
[9]. This research has to a certain extent addressed the initially
experienced barrier, but certain limitations seem to persist also in
these approaches. Alternatives and enhancements of the original
approach should at least reflect on this limitation to indicate to what
extent such additional enhancements are also necessary in these
alternatives.
• Multiple descriptions of the same information
EXPRESS and thus IFC allow information to be described in
numerous ways. IFC also allows the description of additional generic
objects with their proper sets of attributes, even if this information
is of a substantially lower level of interoperability as it is not
included in the IFC standard. How information is eventually de-
scribed in IFC, depends on how it is designed and implemented for
the BIM environment at hand, and on how a user models this
information in a BIM environment. This range of possible descrip-
tions is more than desirable from a user perspective, but it requires
an extra design and implementation effort by software engineers
who want to reuse this information, as they may require the
information to be described in any of the other possible descrip-
tions. This may again be enhanced by the correct usage of MVD [9]
or by alternative approaches, but again, alternatives and enhance-
ments of the original approach should be checked to what extent
they offer a solution to this initial limitation.
The first barrier, the limited expression range, seems a typical
characteristic in the usage of any model for knowledge representation,
 P. Pauwels et al. / Automation in Construction 20 (2011) 506–518
as no model can describe ‘all information’. No alternative model can
encompass this limitation, but the appropriate combination of
technologies may enable a more intuitive extension of separate
models with information from within other knowledge domains. The
other two barriers seem mainly caused by the nature of the EXPRESS
language underneath the IFC schema. As EXPRESS does not allow an
easy and intuitive handling of information, it needs qualitative
additional enhancements to make models described in this language
sufficiently manageable (easy partitioning of information, handling
parallel descriptions of the same information). When one thus
considers an alternative language for knowledge representation, one
should at least reflect on these initial barriers to indicate to what
extent such additional enhancements are still equally necessary.
2.2. The semantic web
In the WWW, one may find an appropriate description language as
a valid alternative for EXPRESS. As the WWW contains information
about almost any possible concept in the world, the language
describing this information cannot follow one domain-specific
schema. A limited expression range as observed in the IFC schema is
thus not acceptable. Instead, a flexible and generic language is needed
that allows one to describe and easily link information from very
different knowledge domains together. Because content needs to be
described for very diverse and large knowledge domains while
maintaining its interrelations, sound partitioning possibilities should
be provided by this language, enabling users to describe concepts in
separate limited scopes and still be able to relate them back to
concepts described earlier in different scopes.
The semantic web was conceived in [19] as a semantic network
that describes the meaning of its concepts through a directed, labelled
graph (Fig. 1) based on description logic [20]. Each node in this graph
represents a concept or object in the world and each arc in this graph
represents the logical relation between two of these concepts or
objects. In this way, the graph represents a set of logic-based
declarative sentences.
Similar to the way in which the construction industry relies on
EXPRESS as a language to build schemas within the STEP standard
(e.g. IFC schema), the semantic web uses the Resource Description
Framework (RDF) as a language to represent its graph structure [21].
This graph structure is generally referred to as an RDF graph. Within
the semantic web domain this was soon considered a standard
language to describe any possible kind of information, not limited to
the WWW. Information thus implicitly became interoperable be-
tween different environments, whether these environments be web
pages, complete software environments, or anything else [21].
Today the development of the semantic web is mainly led by the
World Wide Web Consortium (W3C) [10], significantly supported by
actors stemming from various corners, including both scientific
research institutes and industrial partners. According to the W3C,
the semantic web nowadays consists of a web of ‘linked data’ that is
superseding the borders of individual applications and hence is
interconnected through links between identical or related entities.
Since the full explanation of semantic web technologies exceeds the
scope of this paper, we merely touch the basic concepts below and
refer to more elaborate information sources elsewhere [10,20–23].
2.2.1. Resource description framework
An RDF graph is constructed by applying a logical AND operator to
a range of logical statements containing concepts or objects in the
world and their relations. These statements are often referred to as
‘RDF triples’, consisting of a subject, a predicate and an object (Fig. 2),
consequently implying directionality in the RDF graph. In addition,
each concept and relation has a Unique Resource Identifier (URI)
assigned to it, thereby making the RDF graph explicitly labelled. Every
concept described in an RDF graph, whether this is an object, subject
509
Subject
Predicate
Object
Fig. 2. The ‘triple’ form of an RDF statement: subject–predicate–object.
or predicate, is uniquely defined through this URI. When two identical
URIs are found, their semantics are considered identical as well.
The resulting RDF graph can be converted into a textual rep-
resentation that follows a specific syntax. Syntaxes used for RDF
graphs are RDF/XML, N-Triples [23], Turtle [24], SPARQL [25] and
Notation-3 (N3) [26]. We use the N3 syntax because it focuses on
human readability and the possibility to express both data and logic in
the same language [26]. The N3 syntax additionally provides one of
the highest levels of expressiveness within the semantic web domain
[26], although certain information can still only be expressed in RDF/
XML and/or SPARQL (Fig. 3).
Fig. 4 illustrates how a window may be described using N3. The
first two statements define two ‘prefixes’ (inst: and ont:) that
enable the abbreviation of the URIs used in the RDF statements below.
Using the inst: prefix for instance, one can reconstruct the URI of the
resource inst:WindowX into bhttp://smartlab.elis.ugent.be/
aimontologies/inst/SLwindow#WindowXN. The lower lines describe
two statements about the concept inst:WindowX, concatenated by a
‘.’ as a representation of the logical AND operator. The predicates ont:
hasOpeningElement and ont:overallHeight label the logical
relations attached to the inst:WindowX concept.
2.2.2. Web ontology language
RDF graphs can be given an improved semantic structure using
RDF vocabularies or ontologies. The most basic elements to describe
such ontologies are available in the RDF Schema (RDFS) vocabulary
[22]. RDFS for instance enables the specification of classes, subclasses,
comments, data types, etc. This specification is done through RDF
statements that deploy concepts from the RDFS vocabulary. Examples
can be found in Fig. 5, specifying for instance that the ifc:IfcWindow
class is a subclass of the ifc:IfcBuildingElement class.
More expressive elements to describe ontologies are available
within the Web Ontology Language (OWL) [20], which uses RDFS
concepts as a subset. The RDF graphs constructed with OWL concepts
are called OWL ontologies, and they can be used as an available
vocabulary when making other, more complex RDF statements. Such
an OWL ontology can be compared to the IFC schema in EXPRESS, only
using OWL/RDF as a language instead of EXPRESS. An OWL ontology
may include descriptions of classes, properties and their instances.
RDF resources can then ‘belong to a specific class’ of an OWL ontology,
as illustrated in Fig. 5. By extending RDF with this OWL functionality,
virtually any kind of information can be described semantically.
When using OWL and RDFS concepts in the RDF graph, one can
infer new information through a standard reasoning process. For
instance when a resource is part of a subclass, a reasoner can au-
tomatically infer that the resource is also part of the superclass.
Some of the concepts in the OWL language enable the specification of
more elaborate rules. The RDF graph in Fig. 6 for instance describes that
for a concept to be an instance of the ont:ResidentialBuilding
class, it always requires some values from the ont:Bedroom class for
the property ont:hasBedroom. This RDF graph thus describes the rule
‘IF something has at least one bedroom, THEN it is a residential building’.
2.2.3. Rule languages
The available RDFS and OWL concepts enable only a basic,
standard level of reasoning, limited to a certain level of complexity.
When a more complex logical reasoning is necessary, one may need to
build his or her rules in a more dedicated rule language. Using a
specific rule language one is able to define custom rules and
subsequently use them in a rule-based reasoning process. Several
rule languages have been developed to express such logic. Three of the
510 P. Pauwels et al. / Automation in Construction 20 (2011) 506–518

Full N3

{ graph literals }

=>
=
SPARQL where
@forAll
x!y^z paths
@forSome
?var
Turtle

[ ];,
ns:localId
literals as
@prefix subjects
( ) lists
N Triples @base

<uri>

_:bnode

“literal”
.
free
format

reification
(obsolete)

‘single $var
quoted’

expressable in
RDF/XML

Fig. 3. Venn diagram summarising the expressiveness for the different syntaxes for RDF graphs (original image in [27]).

most notable initiatives in the semantic web domain are the Semantic
Web Rule Language (SWRL) [28], the Rule Interchange Format (RIF)
[29] and the N3Logic language [30].
SWRL was proposed as one of the first semantic rule languages in
[28]. It is based on a combination of OWL and RuleML [31]. Both an
abstract and an XML concrete syntax were proposed to describe rules.
A similar approach was picked up by the RIF working group setup at
the W3C while constructing RIF [29]. After several draft specifications,
ont:overallHeight
“2180”
inst:WindowX
ont:hasOpeningElement
inst:OpeningElementY
@prefix inst: <http://smartlab.elis.ugent.be/aimontologies/inst#> .
@prefix ont: <http://smartlab.elis.ugent.be/aimontologies/ont#> .
inst:WindowX ont:hasOpeningElement inst:OpeningElementY .
inst:WindowX ont:overallHeight “2180.00”^^xsd:double
Fig. 4. Semantic web description of a window, both in a visual graph and an N3
representation.
this working group has submitted a candidate recommendation
regarding a RIF Framework for Logic Dialects [32,33], which was
recently approved. At the core of the framework RIF is very similar to
the SWRL effort in that it allows rules to be expressed both in XML as a
normative concrete syntax and in a more human-readable abstract
syntax. N3Logic is an alternative approach to SWRL and RIF, proposed
in [30]. Unlike SWRL and RIF, this third rule language is based on N3 as
its normative syntax, which was presented as a readable alternative
for RDF/XML in [26].
These rule languages aim to do for logical information what RDF
does for data: to provide a common data model to express globally
sharable information on logic. They enable information with a far
greater expressive power (such as rules) to be sharable similar to the
way in which RDF is sharable. Having one rule described in such a rule
language, any other agent should be able to understand this rule
and possibly apply it within a completely different situation and
environment.
We are currently using N3Logic to describe custom rules. A rule in
N3Logic contains hypothetical ‘formulae’. Every hypothetical formula
thereby uses curly brackets in its syntax to describe a subgraph, i.e. a
logical conjunction of the statements between the curly brackets [30]
(Fig. 7). Following the syntax of an RDF triple statement, a rule may
describe that IF one hypothetical formula is true, THEN the other
hypothetical formula is also true. In addition, an N3Logic rule
references the concepts required in the rule using the URIs of these
concepts, optimally abbreviated with prefixes.
An example of a rule in N3Logic is given in Fig. 7. This rule specifies
that IF an entity can be found that has an ont:hasMaterial
 P. Pauwels et al. / Automation in Construction 20 (2011) 506–518 511

inst:WindowX
ont:hasMaterial ?x
?x
rdf:type
?y
ont:hasAcoustic
ifc:IfcWindow ont:hasR63Hz Property
rdfs:domain
?z
xsd:double
rdfs:subClassOf ?z
rdfs:range
ont:overallHeight

rdf:type
log:implies
owl:DataType
Property {
rdf:type ?x ont:hasMaterial ?y .
?y ont:hasR63Hz ?z
}
log:implies
owl:Class {
?x ont:hasAcousticProperty ?z
ifc:IfcBuilding rdf:type }
Element

Fig. 7. N3Logic rule in its normative N3 notation.

inst:WindowX rdf:type ifc:IfcWindow .
ifc:IfcWindow rdf:type owl:Class .
ifc:IfcWindow rdfs:subClassOf ifc:IfcBuildingElement .
ifc:IfcBuildingElement rdf:type owl:Class .
ont:overallHeight rdf:type owl:DatatypeProperty .
ont:overallHeight rdfs:domain ifc:IfcWindow .
ont:overallHeight rdfs:range xsd:double
Fig. 5. An OWL ontology describing an IfcWindow class.
property AND that property has an ont:hasR63Hz property, THEN
that entity has an ont:hasAcousticProperty property with the
same URI as (i.e. identical to) the ont:hasR63Hz property.
ont:ResidentialBuilding rdf:type
owl:equivalentClass
owl:Class
owl:someValuesFrom
owl:onProperty
rdf:type
ont:hasBedroom ont:Bedroom
rdf:type
owl:Restriction
owl:ObjectProperty
ont:ResidentialBuilding rdf:type owl:Class .
ont:ResidentialBuilding owl:equivalentClass _:125 .
_:125 rdf:type owl:Restriction .
_:125 owl:onProperty ont:hasBedroom .
_:125 owl:someValuesFrom ont:Bedroom .
ont:Bedroom rdf:type owl:Class .
ont:hasBedroom rdf:type owl:ObjectProperty
Fig. 6. A set of RDF sentences describing a simple rule using OWL concepts. The graph
contains one ‘blank node’, identified by the node identifier _:125. This node identifier is
only used in the serialisation into the N3 syntax. This identifier may not be used as a URI
and consequently does not appear as a named label in the RDF graph [26].
2.3. Towards a combined approach for the construction industry
2.3.1. Possible enhancements generated by the combination
IFC — semantic web
Following the overview given above, one can outline how se-
mantic web technology can overcome the limitations observed when
relying on IFC and which possibilities consequently arise when
deploying semantic web technology.
Being a semantic network, the RDF graph structure is firmly rooted
in logic theory. Also the N3Logic rule language is explicitly built on
logic theory. The combination of the RDF and N3Logic languages
allows one to set up a considerably strong knowledge base accessible
for agents and engines similarly based on the same logic theory. These
agents and engines may provide rule checking functionality for the
construction industry, adopting a declarative, logic-based approach.
Secondly, the usage of URIs in RDF enables the description of
information in very diverse and disparate groups while preserving its
original interrelations. This allows the unlimited connection of very
loosely related knowledge domains, such as BBC's multimedia
information, healthcare information, material information and build-
rdf:type ing information into one web. The indirectly extended expression
range consequently allows building information to step out of its
specialised field of the construction industry and make possibly useful
connections to all kinds of other relevant knowledge domains.
The information in a semantic web can easily be processed using
techniques driven by logic, including the appropriate standard query
languages and rule languages. With these techniques, it should be
fairly easy to do an appropriate partitioning of information, because it
allows an easy selection of the required information and an intuitive
conversion into the required information structure. One is in this case
not obliged or restricted to the usage of MVDs for instance, but may
extract the model view definition instantaneously in any possible
format required at any specific time, thereby relying on standard
functionality provided by a rule engine or a query processor.
Finally, the RDF graph structure at the core of the semantic web
easily enables one to define new concepts, classes, properties, etc. and
relate these to existing concepts in the semantic web to define its
semantics. One merely needs to specify a set of RDF statements using a
proper vocabulary. Following this approach, virtually any kind of
information can be described. These descriptions can be interlinked in
various places at the wishes of the person that specifies the information.
In the case of parallel descriptions of the same information, one may rely
512 P. Pauwels et al. / Automation in Construction 20 (2011) 506–518
on rule languages to switch between these descriptions as we suggested
for the conversion of geometric information in [34].
An in-depth investigation of how semantic web technologies may
address the three observed barriers in achieving the desired level of
interoperability, is not given in this paper because of its focus on rule
checking functionality. The above overview nevertheless suggests
how these technologies may prove an enhancement or at least a valid
alternative approach for the existing approaches. The absence of a
mathematically rigorous logic theory may clearly be resolved through
the adoption of semantic web technologies. It enables the usage of a
declarative approach in the development of rule checking environ-
ments, making the application logic in these environments both more
flexible and more modular. Note that such an approach conserves the
significant efforts put into the design and specification of IFC. The IFC
specification is merely enhanced to enable an improved rule checking
process.
2.3.2. Comparison with previously suggested approaches based on a rule
language
Rule checking approaches based on a rule language have already
been suggested over the last few years. In [6] for instance, a
methodology is suggested for conformance checking in the construc-
tion industry. In this methodology an IFC building model is first
converted into an RDF graph, building regulations are then digitised
into a set of ‘IF-THEN’ rules, after which the ontologies of both the
‘construction rules’ and the ‘construction project’ are aligned using
specific alignment algorithms. In implementing this very sound
methodology, the authors have chosen to rely on an XSLT transfor-
mation between the ifcXML representation of an IFC model and the
RDF/XML representation of an RDF graph for the transformation
procedure from IFC to RDF. Additionally, the set of IF-THEN rules is
implemented using the SPARQL query language [7], which has the
ability to express singular IF-THEN functionality through the
CONSTRUCT formalism in SPARQL [25].
Notwithstanding the significant value of the methodology pro-
posed in [6] and the significant improvements shown in the
conformance checking process, the implementation choices made in
[7] seem to limit functionality in the eventual rule checking
environment. As Fig. 3 already indicated, the N3 syntax generates
higher expressiveness than the standard RDF/XML syntax. This
specifically applies to the expression of IF-THEN functionality and
other rule handling functionalities, as can be concluded from the
location of the IF-THEN symbol (=N) in Fig. 3. Although SPARQL
provides a very useful and intuitive CONSTRUCT formalism, it was still
originally intended as a query language for RDF graphs [25] and not as
a rule language. Apart from being restricted to IF-THEN functionality,
SPARQL is merely useful for a one-by-one querying or rule checking of
a building model and does not allow an equally automated rule
checking process as a combination of a dedicated rule language and
rule engine can provide.
In [11], a remarkable approach is suggested for converting IFC
information into a semantic web format. In this approach an EXPRESS
schema is directly converted into an OWL ontology, based on the
EXPRESS schema definition itself. This OWL ontology can subse-
quently be used to build a set of RDF instances describing a building or
a building component in a semantic web format. Such a conversion
procedure allows constructing and handling RDF graphs in dedicated
semantic web software, which may then be outputted in various
syntaxes. Added to the fact that EXPRESS has a higher level of
semantics than XML, this seems a better approach than the XSLT
transformation between ifcXML and RDF/XML suggested in [6].
It is concluded in [11] that a fully automatic conversion of EXPRESS
schemas into an OWL ontology will probably never be reached, due to
certain types of semantic information that do not have a direct
equivalent in OWL, such as WHERE rule constraints and procedural
FUNCTION calls. However, this mainly concerns more advanced rule
and function information, which is typically described in the semantic
web field using rule languages instead of relying on the standard
reasoning capabilities of OWL. We argue that a full conversion of
EXPRESS schemas may be reached when describing explicit logic-
based functionality with the appropriate rule language, for instance
N3Logic.
The third approach for developing a rule checking system driven
by a rule language, has been suggested and presented in [8]. Although
the presented ConDes system does not rely on semantic web
technology, it proposes a visual knowledge specification that can be
considered equally expressive as any RDF graph specification. This
visual knowledge specification is used for the specification of
conceptual architectural designs, using an add-on in the ArchiCAD
3D modelling environment of Graphisoft. This knowledge graph can
be combined with design rules that are to be formalised by one or
more specialised knowledge engineers. Combining both the knowl-
edge graph and the design rules in ArchiCAD, similar to the
methodology suggested in [7], an architect is enabled to model
information from the very first conceptual design stage and check
whether or not this design conforms to the applicable custom design
rules. The ConDes system is a good example of what functionality a
rule checking system based on a logic-based language may provide to
a specialist in the construction industry. Relying on technology that is
widely supported and acknowledged, such as semantic web technol-
ogy, might nonetheless provide a more solid basis for developing such
a system.
3. A semantic rule checking environment for building models
Starting from the outlined possibilities of combining semantic web
technology with IFC, we conceived a semantic rule checking
environment for the construction industry, thereby investigating
how the rule checking process may be improved with a dedicated rule
language and rule engine. This environment was conceived and
developed as a part of the architectural information modelling (AIM)
framework previously presented in [35]. We solely document the rule
checking environment as the discussion of the AIM framework falls
outside the scope of this paper. The concluding test case will provide
clear examples of the conceptual methodology outlined in this
section.
In our discussion we first document how a knowledge base can be
conceived, containing both explicit building information (facts) in
RDF graphs and implicit building information (rules) in N3Logic. We
present how an inference engine is able to combine information in
this knowledge base to retrieve the information desired. An interface
completes the rule checking environment for the construction
industry (Fig. 8). We point out improvements over existing rule
checking engines for the construction industry in our brief overview.
Knowledge Base
Explicit
building
information
Inference Engine
Implicit
building
information
Interface
Fig. 8. Conceptual overview of the rule checking environment proposed in this paper.
 P. Pauwels et al. / Automation in Construction 20 (2011) 506–518
3.1. Explicit building information: RDF graphs
Several vocabularies are currently being constructed as OWL
ontologies, thereby enabling the description of building information
in an RDF graph using structured vocabularies. We will only mention
two of our OWL ontologies here, namely an IFC ontology and a
construction element ontology. Other ontologies focus on information
about architectural theory, design, actors, geographical locations, etc.
The IFC ontology is largely similar to the ontology discussed in
[11]. The EXPRESS schema was transformed into an OWL ontology. In
this transformation process, every EXPRESS element that has a direct
equivalent in OWL is mapped onto this equivalent. For each ENTITY
element in EXPRESS a corresponding OWL class is generated, EXPRESS
attributes are converted into the appropriate OWL properties, etc.
Having the eventual IFC ontology at our disposal, we are able to
generate IFC/RDF instances as part of the explicit information in our
knowledge base. We are currently relying on existing BIM applica-
tions to generate an IFC model that can subsequently be converted
into an equivalent IFC/RDF graph using our in-house IFC-to-RDF
converter [36]. A part of an IFC/RDF graph is displayed in Fig. 9.
The construction element ontology is constructed by applying a
D2R server mapping [37] onto an existing construction element
database. This relational database collects test information about
construction elements produced in Belgium. This test information
mainly concerns acoustic and thermal characteristics, such as sound
reduction indexes, thermal resistances, etc. On top of this database,
RDF graphs describing construction elements (CONSTR/RDF
instances) are generated real-time using the D2R mapping [38]. The
resulting CONSTR/RDF instances are in this way available as part of the
explicit information in the knowledge base.
References between the different graphs of the knowledge base,
under which are the IFC/RDF graph and the CONSTR/RDF graph, can be
created using explicit RDF statements. This allows creating a building
information graph containing both IFC/RDF information and CONSTR/
RDF information for instance. Fig. 9 displays how an instance in an IFC/
RDF graph can be linked to an instance of the CONSTR/RDF graph. The
instances in the building information graph can similarly be linked to
inst:ifcOwnerHistory_33
inst:ifcProductDefinitionShape_461
ifc:ownerHistory ifc:representation
inst:ifcLocalPlacement_381
ifc:objectPlacement
inst:ifcWallStandardCase_417 rdf:type
constr:material
ifc:IfcWallStandardCase
constr:product_461
inst:ifcWallStandardCase_417 rdf:type ifc:IfcWallStandardCase .
inst:ifcWallStandardCase_417 constr:material constr:product_461 .
inst:ifcWallStandardCase_417
ifc:objectPlacement inst:ifcLocalPlacement_381 .
inst:ifcWallStandardCase_417
ifc:representation inst:ifcProductDefinitionShape_416 .
inst:ifcWallStandardCase_417 ifc:ownerHistory inst:ifcOwnerHistory_33
Fig. 9. Linking instances of an IFC/RDF graph to the appropriate construction element
information available in a CONSTR/RDF graph.
513
graphs containing architectural history, geographical or design
information, thereby resulting in a far more rich information model
than the IFC schema can provide.
3.2. Implicit building information: N3Logic rules
Parallel to the explicit building information, a range of rule sets is
developed in N3Logic and added to the knowledge base. They enable
the description of information that is implicitly available in the
building model. Every rule set contains rules that can be applied to
RDF graphs in order to infer this implicit information. They are thus
closely related to the ontologies deployed in describing these RDF
graphs. We briefly discuss how these rules are described and how
they are related to the explicit building information available in the
knowledge base, thereby making the comparison with existing
approaches in the rule checking process as they were outlined in [5].
3.2.1. Rule description
Rules are described in conformance with the N3Logic syntax [30].
An example of such a rule was previously given in Fig. 7. These rules
are combined into rule sets, for instance separating a rule set for
acoustic performance checking and a rule set for energy performance
checking.
One can outline several advantages caused by using a semantic
rule language as N3Logic compared to traditional approaches. As
outlined in [5], many software environments exist adopting a
procedural approach, whereas the declarative approach driven by a
rule language is named as the more appropriate long term
implementation method for building rule checking. The two following
advantages of using a declarative approach were given in [5].
• Portability
It is possible to deploy, evaluate and edit the same set of rules in
completely different software environments and applications, as
long as a commonly agreed upon rule language is deployed in
these environments.
• Flexibility
Virtually any set of rules can be specified using this rule language.
This results in a highly flexible rule checking environment once an
application developer or a user is familiar with the rule language
deployed.
Because of its foundation in logic theory, this approach lies within
reach when deploying a semantic rule language such as N3Logic.
Additionally, it enables the direct usage of existing logic-based
technologies during the rule checking process. The rules described
in N3Logic can for instance be directly deployed by existing logic-
based inference engines to check them in an explicit context or they
can be visualised in environments specialised in the visualisation of
logic rules, etc.
3.2.2. Relation with explicit building information
Similar to how they are described in natural language, rules tend to
deploy their own vocabulary, consisting of concepts that apply
specifically to the rule set at hand and that are not available in the
vocabularies used to describe other information, such as the information
in a building information graph. Geometric and material-based concepts
for instance do not map directly on the concepts deployed in an acoustic
or thermal standard rule set. We therefore consider it useful to create a
separate rule set vocabulary using OWL to describe the concepts
deployed within each rule set. One can easily see how the rule displayed
in Fig. 10 for instance deploys only concepts stemming from its rule set
vocabulary in OWL (i.e. ruleOnt:).
An explicit relation is needed between the different descriptions of
both the explicit building information and the implicit building
information. Otherwise, none of the rules described will be able to
infer any information from the explicit RDF graph of the building
514 P. Pauwels et al. / Automation in Construction 20 (2011) 506–518
ruleOnt:hasHeight ?x
?x
?y
math:greaterThan rdf:type
rdf:type
“3000”
ruleOnt:aHighWall
ruleOnt:Wall
log:implies
{
?x rdf:type ruleOnt:Wall .
?x ruleOnt:hasHeight ?y .
?y math:greaterThan “3000”^^xsd:double
}
log:implies
{ Conversion
?x rdf:type ruleOnt:aHighWall
} Rule Set
Fig. 10. Example of a rule described using its own rule ontology in OWL.
model. When deploying semantic web technology, however, this is
fairly easily dealt with. A separate ‘conversion rule set’ can explicitly
link the ontology structure used in the RDF graph to the ontology
structure of a rule set. When one tries to infer information with an
acoustic performance rule set for instance, this conversion rule set
explicitly describes how the running inference engine can interpret
the information described in the inputted RDF graph containing
building information.
This approach guarantees that both the explicit information
contained in the building information graph and the implicit
information contained in the rule set remain manageable and allow
changes. When for instance the structure of the building information
graph changes, it is only necessary to update the conversion rule sets
without having to deal with the logic of the rule set itself. An overview
of the resulting knowledge base that is to be addressed by the
semantic rule checking environment, is shown in Fig. 11.
As can be seen in Fig. 11, each rule set can thus be considered as a
separate addition of implicit information, each time for a very specific
domain of knowledge. Since they rely on the same central information
base, these rule sets are nevertheless related and thus require a sound
organisation or structure. One could for instance organize these rule sets
hierarchically (e.g. construction industry N structural–performance–
architectural N ...), in distinct groups according to geographical para-
meters, or maybe completely intertwined at diverse levels. How this
relation is organized, requires further attention in future design and
implementation phases, as such a decision is hard to make in this early
stage of research.
3.3. The semantic rule checking environment
The knowledge base documented above contains the information
required by a rule checking environment to perform specific rule
checks for the construction industry. Because of the semantic, logic-
based nature of RDF and N3Logic, existing inference engines or rule
engines can be deployed to make the logical inferences needed. An
interface on top of the knowledge base and the deployed rule engine
enables displaying both the available information and the resulting
inferences, thereby completing the semantic rule checking environ-
ment for the construction industry.
Location
Design ...
Theory IFC
Construction
Elements
...
Rule Set Conversion ...
Rule
Rule ...
Ontology
Ontology
Rule Set
Rule Set
Fig. 11. Rule sets linked to the core knowledge base deploy a separate ontology
definition and a conversion rule set.
3.3.1. The inference process
Main issues in the existing implementation approaches for rule
checking environments currently concern syntactic pre-checking of
the model and the management of the rule execution process [5].
Because neither the IFC language nor the encoded rules are based on a
mathematically rigorous theory this syntactic pre-checking and
management require an important amount of implementation work
in order to let the rule checking environment function properly.
As both the RDF graph and the rules defined in the semantic rule
language are firmly rooted in logic theory, this amount of implemen-
tation work is not an issue for semantic web technologies. Existing
technologies are based on these principles and are thus able to
perform tasks like syntactic pre-checking and rule checking manage-
ment automatically. A large amount of research in the semantic web
field for instance focuses on improving semantic consistency checkers
for RDF graphs, ontology, data alignment, etc., independent of the
contents described but instead completely relying on logical princi-
ples. Rule engines are part of these semantic web technologies.
Several existing rule engines are able to infer information and return
conclusions, based on mathematical theories and principles and
automatically accounting for the syntactic pre-checking and the rule
checking management during its inference process. This constitutes a
significant advantage over existing rule checking environments.
Several semantic rule engines exist. The typical output of these
engines is a conclusion, most often represented as a set of newly
inferred facts or as a proof that a statement holds or not. An elaborate
comparison of existing reasoning engines is out of scope for this
paper. Instead, we give only a brief description for two of the most
significant reasoning engines and refer to more elaborate information
elsewhere [39–43].
The Closed World Machine (CWM) reasoner was the first reasoner
built for processing N3Logic and RDF graphs. It is developed as a
“general-purpose data processor for the semantic web” [39] and is
 P. Pauwels et al. / Automation in Construction 20 (2011) 506–518
capable of loading resources, applying rules and outputting results in
one of the several syntaxes available for RDF. CWM is a typical
forward-chaining reasoner, meaning that it starts from the available
facts and uses the available inference rules to infer new facts, after
which these facts are added to the initial facts base and the reasoning
process starts all over until there is nothing more to infer. The benefit
of using a forward-chaining reasoner is that a lot of new information
becomes available, which could be useful for certain automation
purposes. On the other hand, in many cases far too much unnecessary
information is inferred, forcing even the smallest queries to go
through an unnecessary long inferential discussion.
A backward-chaining reasoner on the other hand starts from a set
of hypotheses, which are most often passed to the engine through an
initial SPARQL query. It searches both among the supplied resources
for the elements contained in the given hypotheses, as among the
supplied inference rules for those that have the input hypotheses in
their THEN clause. If the IF clause of a needed rule is not known to be
true, it is added to the hypotheses, and the search process continues.
Reasoning is consequently limited to a minimum and occurs on-
demand. The Euler Yap Engine (EYE) is one of the most notable
reasoners based on N3Logic and RDF graphs that implements a
backward–forward–backward chaining inference process [40,41].
Rule engines similar to CWM and EYE exist and are under
development for SWRL and RIF [42]. Differences concerning efficiency,
resource allocation, etc. between the two reasoning engines docu-
mented above, and between other engines as well, need to be
investigated and taken into account when planning the design and
implementation of an effective and widely used reasoning environ-
ment. Because the research documented in this paper concentrates on
the mere value of deploying such an engine for rule checking in the
first place, we will not elaborate on such an investigation here.
3.3.2. Reporting of rule checking results
The output of semantic web engines is in most cases returned in the
form of new RDF statements. These results can directly be passed
through to an existing visualisation software built for RDF graphs. The
most obvious choice would be to automatically export the resulting RDF
statements into an RDF triple store and make them accessible through a
SPARQL endpoint on the web [25]. Web pages and textual documen-
tation reports can then be generated automatically on top of this
endpoint if only the appropriate software applications are available to
perform the visualisation effort for semantic web technology in general.
Alternatively, when using a backward-chaining rule engine or proof-
engine, one can also obtain a proof as the output result of the checking
process. Recording the backward-chaining process namely enables
explicitly stating why something ‘passes’ or ‘fails’.
Several efforts in the semantic web field are currently focusing on
providing an optimised visualisation framework for RDF graphs. The
online Disco Hyperdata Browser [44] for instance automatically
generates and continuously updates an interactive web interface
displaying the RDF information, thereby providing a more intuitive
access to the data. Alternatively, one could also deploy N3Logic rules
to generate custom graphical user interfaces (GUI) based on the
outputted RDF graph. An initial investigation of this approach, applied
to the healthcare industry, can be found in [45].
In the design and implementation of such a reporting system, very
diverse approaches for report visualisation may be chosen, thereby
incorporating varying interface strategies. An interface may for
instance focus on the sufficiency or insufficiency of certain building
information required for the rule checking process, or it may focus on
the precise indication of problematic sections in the building, etc.
Other approaches and strategies exist, and will be generated in the
future, in response to specific needs and/or requirements. The
discussion of the most appropriate approach(es) or to what extent
the information required for rule check reporting may be generated
from a set of rules in N3Logic, was not part of this initial research.
515
Nonetheless, we argue that a management system for construction
industry rule checking could use one or more of these automatic
visualisation approaches to optimally display the results of the
building performance checking process and give a construction
industry specialist the feedback he or she needs in the format he or
she likes. Considering the experienced flexibility and the expressive-
ness of N3Logic as a rule language, this information can easily be
provided in the resulting RDF graph report.
4. Test case: the acoustic performance regulations
4.1. The setup of the test case
A test case was set up for the investigation of how the configuration
given above may improve existing rule checking processes in
architectural design and construction. As a subject we chose the
newly emerging acoustic performance regulations both on a European
level as on a national level in Belgium, assuming that the methodology
deployed can be extended to other calculation and simulation
processes as well. Note that we merely aim at documenting a proof
of concept, and not a fully implemented and widely usable application.
We merely show the basic concepts in order to make clear to what
extent this may form a valid alternative to existing approaches.
4.2. European and national standards
March 2000 was the publication date of the European standard
EN12354 [46] for the estimation of the acoustic performance of
buildings from the performance of elements. This standard consists of
several parts, specifying the estimation process for instance for the
airborne sound insulation against outdoor sound, or for the
transmission of indoor sound to the outside. We solely addressed
the third part of the standard in this test case, namely ‘EN 12354-
3:2000: Airborne sound insulation against outdoor sound’ [46].
The EN 12354-3:2000 standard documents the way in which the
relevant quantities for expressing an acoustic building performance
can be both derived from quantities measured on-site or calculated
from a given calculation model and more basic rules of thumb. Fig. 12
for instance shows how to calculate the sound power ratio of radiated
sound power by a façade element i due to direct transmission of sound
incident on this element, relative to incident sound power on the total
façade [46].
As the European standard only provides a means to derive the
required quantities for expressing an acoustic building performance,
it leaves out the process of evaluating these quantities resulting in a
‘pass’, ‘fail’, ‘warning’ or ‘unknown’ message for building elements or
for the building itself. This part of the evaluation process is to be
addressed by the national standards organisations of the involved
countries in Europe [46].
In response to the European standard, the National Bureau for
Normalisation (NBN) in Belgium published the national regulation
NBN S 01-400-1 in January 2008 [47]. This regulation specifies the
acoustic performance requirements to be met in the construction of
new dwellings, regarding the insulation against airborne, contact and
outdoor sound. The acoustic performance level against outdoor sound
hereby specifies explicit references to the acoustic quantities that can
be obtained from the European EN 12354-3:2000 standard. An extract
of NBN S 01-400-1:2008 given in Fig. 13 shows for instance the
conditions that have to be met in order for a building to reach a
normal (Dutch: ‘normaal akoestisch comfort’) or an increased (Dutch:
‘verhoogd akoestisch comfort’) acoustic performance level.
4.3. Explicit building information: RDF graphs
A building information graph was constructed for this test case,
following the methodology given above. A simple building model was
516 P. Pauwels et al. / Automation in Construction 20 (2011) 506–518
Fig. 12. The calculation procedure for several acoustic performance properties of
buildings is given in [46].
created in a BIM application, namely Autodesk Revit Architecture
2010. This model was subsequently exported into an IFC represen-
tation, which was then converted into an IFC/RDF graph using our in-
house IFC-to-RDF converter [36]. This graph was extended with
information from the CONSTR/RDF graph, resulting in an RDF graph of
which a part was previously presented in Fig. 9.
4.4. Implicit building information: N3Logic rules
4.4.1. Rule description
The two above regulations had to be formalised into rules. We
chose to explicitly separate the specifications described in both
standards and generate both an EN 12354-3:2000 and an NBN S 01-
400-1:2008 rule set. This enables for instance the derivation of the
relevant acoustic quantities defined by the European standard,
keeping the possibility to subsequently combine them with other
relevant rule sets, for example the European equivalents to the
Belgian NBN S 01-400-1:2008 standard.
Both standards are manually interpreted and translated into a rule
ontology in OWL, describing the concepts used within the standard, a
rule set in N3Logic, describing the logic in the standard, and a
conversion rule set making the references required to the building
information graph. The code fragment in Fig. 14 illustrates for instance
Fig. 13. [47] describes what conditions need to be fulfilled in order to reach a certain
acoustic performance level.
{
?BE rdf:type EN12354:BoundaryElement .
?BE EN12354:elementSurfaceArea ?a .
?BE EN12354:partOfRoomBoundary ?RB .
?RB rdf:type EN12354:RoomBoundary .
?RB EN12354:facadeSurfaceArea ?atot .
?BE EN12354:soundReductionIndex_4000Hz ?R_4000 .
?a math:notLessThan 1.
(?a ?atot) math:quotient ?value_i .
(?R_4000 -10) math:quotient ?value_j .
(10 ?value_j) math:exponentiation ?value_k .
(?value_i ?value_k) math:product ?value_l
}
log:implies
{
?BE EN12354:directSoundPowerRatio_4000Hz ?value_l
}
Fig. 14. Rule from the EN12354-3:2000 rule set, specifying how the EN12354:
directSoundPowerRatio_4000Hz property can be derived from a building model. The
EN12354 prefix refers to the base URI of the rule ontology for this standard.
how the second part of the textual resource (‘Other elements’) given
in Fig. 12 is translated into one of the rules in the EN 12354-3:2000
rule set.
Similar to making translations between natural languages, slight
discrepancies between the original text and its translation were found
to be inevitable. However, having described the standards in an
interoperable computer- and human-readable syntax enables an
improved understanding of the contents of the standards, thereby
helping involved parties to more easily make improvements to the
contents of the standards.
An identical approach was followed for the NBN S 01-400-1:2008
standard, resulting in a rule ontology, a conversion rule set and the
actual rule set for the standard. Starting from the concepts derived
from both rule sets and their ontologies, one may thus eventually
derive an explicit statement about whether or not the building model
applies to a certain acoustic performance level, defined according to
the Belgian NBN S 01-400-1 standard.
4.4.2. Relation with explicit building information
The defined rules deploy concepts stemming from a rule ontology,
separately described in OWL. An inference engine needs to be able to
relate these concepts to the concepts described in the building
information graph. A dedicated conversion rule set is developed for
this purpose, containing concepts from the RDF graph in its IF clauses
and concepts from the rule ontology in its THEN clauses. In this case,
the rule engine will consequently know how to translate or convert
certain concepts with base URIs represented by the ifc: and
constr: prefixes into concepts with the EN12354: prefix, which
represents the base URI of the rule ontology (Fig. 15).
With this conversion rule set, the concepts required for the
acoustic calculations can be automatically inferred for any building
information graph containing the required concepts. This can be
considered being implicit information available for the building
information graph at hand. This implicit information describes for
instance an acoustic performance level acquired according to the
EN12354-3:2000 and the NBN S 01-400-1:2008 standards.
4.5. The rule checking environment
4.5.1. The inference process
The information described by the rules in the knowledge base can
be considered implicit information concerning the designed building.
As the rules describing the two acoustic standards enable the logical
inference of an acoustic performance level, this information can be
 P. Pauwels et al. / Automation in Construction 20 (2011) 506–518 517

{
improvements have originated for the automation of processes in the
?SS ifc:spaceBoundary _:675 . construction industry. Next to the interoperability caused between
_:675 ifc:relatedBuildingElement ?BE . the diverse BIM applications, several new applications have been
?BE rdf:type ifc:IfcWallStandardCase . developed, capable of parsing IFC models and interpreting and reusing
?BE constr:material ?mat .
this information.
?mat rdf:type constr:product .
Notwithstanding these improvements, several limitations are found
?mat constr:SRI63Hz ?63Hz in IFC as well. When considering rule checking environments
} specifically, the sole usage of IFC restrains an application developer of
log:implies
using a declarative approach, which shows considerable improvements
{
?SS EN12354:soundReductionIndex_63Hz ?63Hz towards modularity and flexibility of the rule checking environment.
} This is for a large part caused by the lack of a mathematically rigorous
logic theory in the language deployed to specify the IFC schema. A
limited expression range, difficulties in partitioning the information and
Fig. 15. Building model preparation starting from the ifc: and the constr:
the possibility to describe the same information in many different ways
namespaces used in the testcase.
were indicated in this paper as other significant hindrances or obstacles
often met in the usage of IFC. The limited expression range of the IFC
considered as implicitly available building information. The inference schema causes limitations when one wants to describe a building using
process thus solely makes this implicit information explicit. As both certain concepts not found in the IFC schema. Difficulties in partitioning
the RDF graph and the N3Logic rule sets are based on logic theory, this the IFC information prevent the user from intuitively defining smaller,
is a standard task for a logical inference engine such as the EYE. After dedicated and easy to handle model views that can increase efficiency
providing the engine with the RDF graph and the rule set at hand the and quality in his or her tasks. Finally, the possibility of describing the
required inferences can be made. same information in many different ways using IFC often results in
Several commands can be given to the EYE reasoner, each time software engineers rather implementing the easiest description instead
resulting in a different backward-chaining process with its own of the most appropriate description, thereby making it difficult for
specific output. It is possible to reason through all information given application developers to reuse this information.
and reproduce all inferences found in the output result. Using specific This paper has briefly shown how these limitations may be
queries, however, one is able to only infer and retrieve the in- overcome when deploying semantic web languages as an enhance-
formation needed. As we are primarily interested in the acoustic ment to IFC. When focusing more specifically on rule checking
performance level of the building model, we constructed a specific functionality, the logic-based graph structure of the semantic web
query that specifically returns this information. The eventually enables the design and implementation of significantly improved rule
resulting output is given in the code fragment in Fig. 16. checking environments. The information available in the graph
namely becomes available for reuse in logic-based processes, such
as rule checking environments, thereby allowing the direct deploy-
4.5.2. Reporting of rule checking results
ment of a declarative implementation approach for these processes,
As can be seen in Fig. 16, the results of the rule checking process
and thus adding the advantages of modularity and flexibility in the
are returned by the inference engine in the form of new RDF
implementation.
statements. By making these statements available in an RDF graph, for
As the semantic web is based on logic theory, a lot of existing
instance within an online triple store, they can easily be reused in any
technologies lay within reach for improving the automation of rule
other information environment for further processing. Generating
checking processes in architectural design and construction industry.
such an RDF graph of the results is of course only a beginning. A
Additional to the building information graph, several rule languages
substantial amount of additional research, design and implementa-
are available in the semantic web domain to express logic into explicit
tion efforts is needed to enable a sufficiently functional visualisation
rules. These rule languages for instance enable the definition of
of rule checking reports, as was indicated earlier.
building regulations and standards without the need to write an
explicit, procedural programming code that is only to a certain extent
5. Conclusion accessible for user edits.
The combination of the graph structure in the semantic web and
Today's BIM applications are targeting interoperability of building these rule languages was tested in the development of a rule checking
information using IFC as a common language for exchange. Several environment for the construction industry. Both explicit (facts) and
implicit building information (rules) were described and stored into a
knowledge base. The rules stored in the knowledge base can be
#Processed by $Id: euler.yap 3098 2009-10-24 20:31:17Z josd $ considered implicit building information because this information can
@prefix : [...] be inferred using only logical theories and principles. On top of this
knowledge base, existing semantic rule engines are able to make such
inst:RoomBoundary_1 NBNS014001:ComfortLevel “normaal”^^xsd:string . inferences and thus making this implicit information explicit. The
inst:RoomBoundary_2 NBNS014001:ComfortLevel “verhoogd”^^xsd:string . implementation of an interface on top of this inference engine should
inst:RoomBoundary_3 NBNS014001:ComfortLevel “normaal”^^xsd:string .
inst:RoomBoundary_4 NBNS014001:ComfortLevel “normaal”^^xsd:string . only be a matter of graphical design and user interaction design.
A test case has been documented in this paper, illustrating how an
acoustic rule checking environment may be implemented using
#ENDS 16 msec semantic web technologies. We merely targeted an initial proof of
#Trunk : 94/326 = 28.8343558282209 %
#Branch: 1/93 = 1.0752688172043 % concept with this test case. It can thus not provide a basis solid enough
for a detailed and sound comparison on expressiveness with existing
and suggested rule checking environments not relying on a rule
Fig. 16. The output of the query on a given building information graph and a set of rules language. Such a comparison is however indispensable for a correct
indicates how four inst:RoomBoundary concepts (equivalent to four wall elements)
each reach a certain NBNS014001:ComfortLevel, distinguishing between ‘normaal’
evaluation of the suggested approach, when a more elaborate
(Dutch for ‘normal’) and ‘verhoogd’ (Dutch for ‘increased’). More details on the semantic rule checking environment is available. Further, in-depth
calculation can be generated as well, but are left out here for reasons of brevity. testing in this direction is thus needed to indicate the practical
518 P. Pauwels et al. / Automation in Construction 20 (2011) 506–518
feasibility and significance of this approach for more complex rule
checking examples. The outcome nevertheless indicates the validity of
deploying semantic web technology to improve building performance
checking in the construction industry.
Acknowledgements
This research is a combined effort of the UGent SmartLab and
Multimedia Lab research groups, supported by the Interdisciplinary
Institute for Broadband Technology (IBBT) and both the Department
of Electronics and Information Systems and the Department of
Architecture and Urban Planning of Ghent University. The project
team gratefully acknowledges the funding support from the Research
Foundation — Flanders (FWO).
References
[1] C.M. Eastman, P. Teicholz, R. Sacks, K. Liston, BIM Handbook: A Guide to Building
Information Modeling for Owners, Managers, Architects, Engineers, Contractors,
and Fabricators, John Wiley and Sons, Hoboken, 2008.
[2] T. Liebich, Y. Adachi, J. Forester, J. Hyvarinen, K. Karstila, K. Reed, S. Richter, J. Wix,
Industry Foundation Classes IFC2x Edition 3 Technical Corrigendum 1, http://
www.iai-tech.org/ifc/IFC2x3/TC1/html/index.htm, (last accessed on 12th. July
2010).
[3] M.P. Gallagher, A.C. O'Connor, J.L. Dettbar, L.T. Gilday, Cost analysis of inadequate
interoperability in the U.S. capital facilities industry, NIST Report GCR 04-867,
National Institute of Standards and Technology (NIST), 2004.
[4] Y.-S. Jeong, C.M. Eastman, R. Sacks, I. Kaner, Benchmark tests for BIM data
exchanges of precast concrete, Automation in Construction 18 (2009) 469–484.
[5] C.M. Eastman, J. Lee, Y. Jeong, J. Lee, Automatic rule-based checking of building
designs, Automation in Construction 18 (2009) 1011–1033.
[6] A. Yurchyshyna, C.F. Zucker, N. Le Thanh, C. Lima, A. Zarli, Towards an ontology-
based approach for conformance checking modeling in construction, Proceedings
of the 24th CIB W78 Conference, Maribor, 2007.
[7] A. Yurchyshyna, A. Zarli, An ontology-based approach for formalisation and
semantic organisation of conformance requirements in construction, Automation
in Construction 18 (8) (2009) 1084–1098.
[8] B. Kraft, M. Nagl, Visual knowledge specification for conceptual design: definition
and tool support, Advanced Engineering Informatics 21 (2007) 67–83.
[9] J. Hietanen, IFC Model View Definition Format, International Alliance for
Interoperability (2006).
[10] W3C Semantic Web Activity, http://www.w3.org/2001/sw/, (last accessed on
12th. July 2010).
[11] J. Beetz, J. van Leeuwen, B. de Vries, IfcOWL: a case of transforming EXPRESS
schemas into ontologies, Artificial Intelligence for Engineering Design Analysis
and Manufacturing (AI EDAM) 23 (1) (2009) 89–101.
[12] ISO 10303-11, Industrial automation systems and integration – product data
representation and exchange – Part 11: description methods: the EXPRESS
language reference manual, http://www.iso.org/iso/iso_catalogue/catalogue_tc/
catalogue_detail.htm?csnumber=183481994, (last accessed on 12th. July 2010).
[13] STEP Overview - STEP (ISO 10303) Product Data Representation and Exchange,
http://www.tc184-sc4.org/SC4_Open/SC4%20Legacy%20Products%20%282001-
08%29/STEP_%2810303%29/, (last accessed on 12th. July 2010).
[14] D. Scheck, P. Wilson, Information Modeling: the EXPRESS Way, Oxford University
Press, New York, 1994.
[15] R. Lau, H. Kahn, Information modelling of EDIF, Proceedings of the 30th ACM/IEEE
Design Automation Conference, 1993, pp. 278–283.
[16] International Alliance for Interoperability - IAI Tech International, http://www.
iai-tech.org/, (last accessed on 12th. July 2010).
[17] R. Verstraeten, P. Pauwels, R. De Meyer, W. Meeus, J. Van Campenhout, G. Lateur,
IFC-based calculation of the Flemish energy performance standard, in: A. Zarli, R.
Scherer (Eds.), Proceedings of the 7th European Conference on Product and
Process Modelling (ECPPM): eWork and eBusiness in Architecture, Engineering
and Construction, Taylor & Francis Group, London, 2008, pp. 437–443.
[18] L. Khemlani, CORENET e-PlanCheck: Singapore's automated code checking system,
AECBytes, http://www.aecbytes.com/buildingthefuture/2005/CORENETePlanCheck.
html 2005, (last accessed on 12th. July 2010).
[19] T. Berners-Lee, J. Hendler, O. Lassila, The semantic web, Scientific American
284 (5) (2001) 35–43.
[20] D.L. McGuinness, F. van Harmelen, OWL Web Ontology Language Overview - W3C
Recommendation, http://www.w3.org/TR/owl-features/ February 10 2004, (last
accessed on 12th. July 2010).
[21] F. Manola, E. Miller, RDF Primer - W3C Recommendation, http://www.w3.org/TR/
rdf-primer/ February 10 2004, (last accessed on 12th. July 2010).
[22] D. Brickley, R.V. Guha, RDF Vocabulary Description Language 1.0: RDF Schema -
W3C Recommendation, http://www.w3.org/TR/rdf-schema/February 10 20048
(last accessed on 12th. July 2010).
[23] J. Grant, D. Beckett, RDF Test Cases - W3C Recommendation, http://www.w3.org/
TR/rdf-testcases/ February 10 2004, (last accessed on 12th. July 2010).
[24] D. Beckett, T. Berners-Lee, Turtle - Terse RDF Triple Language - W3C Team
Submission, http://www.w3.org/TeamSubmission/turtle/ January 14 20088(last
accessed on 12th. July 2010).
[25] E. Prud'hommeaux, A. Seaborne, SPARQL Query Language for RDF - W3C
Recommendation, http://www.w3.org/TR/rdf-sparql-query/ January 15 20088
(last accessed on 12th. July 2010).
[26] T. Berners-Lee, D. Connoly, Notation 3 (N3): A readable RDF Syntax - W3C Team
Submission, http://www.w3.org/TeamSubmission/n3/January 14 20088(last
accessed on 12th. July 2010).
[27] T. Berners-Lee, Notation 3 (N3): A readable language for data on the web, http://
www.w3.org/DesignIssues/Notation3.html, (last accessed on 12th. July 2010).
[28] I. Horrocks, P.F. Patel-Schneider, H. Boley, S. Tabet, B. Grosof, M. Dean, SWRL: A
Semantic Web Rule Language Combining OWL and RuleML - W3C Member
Submission, http://www.w3.org/Submission/SWRL/ May 21 2004, (last accessed
on 12th. July 2010).
[29] Rule Interchange Format (RIF) Working Group, http://www.w3.org/2005/rules/
wiki/RIF_Working_Group, (last accessed on 12th. July 2010).
[30] T. Berners-Lee, D. Connolly, L. Kagal, Y. Scharf, J. Hendler, N3Logic: a logical
framework for the world wide web, Theory and Practice of Logic Programming
8 (3) (2008) 249–269.
[31] The Rule Markup Initiative, http://ruleml.org/, (last accessed on 12th. July 2010).
[32] H. Boley, M. Kifer, RIF Framework for Logic Dialects - W3C Recommendation, http:
//www.w3.org/TR/rif-fld/ June 22 2010, (last accessed on 12th. July 2010).
[33] H. Boley, M. Kifer, RIF Basic Logic Dialect - W3C Recommendation, http://www.
w3.org/TR/rif-bld/ June 22 2010, (last accessed on 12th. July 2010).
[34] P. Pauwels, D. Van Deursen, J. De Roo, T. Van Ackere, R. De Meyer, R. Van de Walle,
J. Van Campenhout, 3D information exchange over the semantic web for the
domain of architecture, engineering and construction, Artificial Intelligence for
Engineering Design, Analysis and Manufacturing, Special Issue 25 (4) (2011)
(submitted).
[35] P. Pauwels, R. Verstraeten, R. De Meyer, J. Van Campenhout, Semantics-based
design: can ontologies help in a preliminary design phase? Design Principles and
Practices: An International Journal 3 (5) (2009) 263–276.
[36] UGent MultiMediaLab, IFC-to-RDF Converter Service, http://ninsuna.elis.ugent.
be/IfcRDFService/, (last accessed on 12th. July 2010).
[37] C. Bizer, R. Cyganiak, D2R Server - Publishing Relational Databases on the Semantic
Web, http://www4.wiwiss.fu-berlin.de/bizer/d2r-server/, (last accessed on 12th.
July 2010).
[38] UGent SmartLab, SPARQL endpoint for the TIATAB material database, http://
smartlab.elis.ugent.be/SPARQLEndpoint/, (last accessed on 12th. July 2010).
[39] T. Berners-Lee, CWM, http://www.w3.org/2000/10/swap/doc/cwm, (last accessed
on 12th. July 2010).
[40] J. De Roo, Euler Proof Mechanism, http://www.agfa.com/w3c/euler/, (last accessed
on 12th. July 2010).
[41] J. De Roo, Eye, http://eulersharp.sourceforge.net/2003/03swap/eye-2009.txt, (last
accessed on 12th. July 2010).
[42] RIF Working Group, Implementations, http://www.w3.org/2005/rules/wiki/
Implementations8(last accessed on 12th. July 2010).
[43] T. Berners-Lee, D. Connolly, S. Hawke, Semantic Web Tutorial Using N3, http://
www.w3.org/2000/10/swap/doc/tutorial.pdf 2003, (last accessed on 12th. July
2010).
[44] C. Bizer, T. Gauss, Disco - Hyperdata Browser: A simple browser for navigating the
Semantic Web, http://www4.wiwiss.fu-berlin.de/bizer/ng4j/disco/, (last accessed
on 12th. July 2010).
[45] L. Acke, Knowledge Based GUI Generators for Health-Care, Master thesis
submitted to the faculty of engineering at Ghent University8(in Dutch), http://
www.agfa.com/w3c/2006/scriptie_Lennert_Acke.pdf, (last accessed on 12th. July
2010).
[46] European Committee for Standardization (CEN), European Standard EN 12354-3,
Building Acoustics — Estimation of Acoustic Performance of Buildings from the
Performance of Elements — Part 3: Airborne Sound Insulation Against Outdoor
Sound, 2000.
[47] Bureau voor normalisatie - Commissie: Geluidsleer - algemeen, Belgische norm
NBN S 01-400-1, Akoestische criteria voor woongebouwen - Critères acoustiques
pour les immeubles d'habitation (2008).