You are on page 1of 13

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


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

environment. In several approaches a conversion phase is therefore design stage. For each of these approaches, it remains nonetheless to
required for converting the building model in IFC into a building model be seen to what extent such a rule language compares with existing
containing the information needed by the rule checking environment. approaches in terms of expressiveness.
Additionally, most rule checking environments seem forced to rely on a
procedural implementation approach, whereas a declarative imple- 1.3. Enhancing IFC for logic-based rule checking
mentation approach based on a rule language is indicated as the better
choice for rule checking environments. When considering a logic-based rule checking environment for the
construction industry, one has to consider its source of information
1.2. Rule checking approaches in the construction industry first. Because the IFC schema was not explicitly designed for import
into rule checking environments, its specification is not based on a
A good recent overview of such environments for building code logic theory. By enhancing IFC onto a logical level, one may enable the
checking was recently given in [5], combined with an overview of rule design and implementation of significantly improved rule checking
checking processes in general. We do not intend to give an equally systems. This will constitute the primary focus of this paper.
detailed overview of rule checking approaches in this paper. Instead, Additionally, the usage of a suitable different language may
we give a short overview of the conclusions and indicate how this overcome other existing barriers found in the usage of IFC. These
paper aims at contributing to the subject. barriers have several causes, not always directly caused by the nature
In [5], a rule checking process is separated into four phases, of IFC. Most of them nonetheless find their origin in using IFC. Over-
thereby considering a rule interpretation phase, a building model coming these barriers is not essential in the scope of rule checking for
preparation phase, a rule execution phase, and a rule check reporting the construction industry, but it might provide valuable additional
phase. Each of these phases is discussed, combined with their improvements to IFC in general. Barriers considered in this paper are a
respective effects on the overall rule checking process. For the rule limited expression range, difficulties in the partitioning of information
interpretation phase, diverse approaches are discussed on how rules and the possibility to describe the same information in numerous
in natural language may be best converted into computer under- ways.
standable code. The output of this phase is a certain amount of com-
puter processable code, of which the level of flexibility, modularity 1.4. Rule checking based on semantic web information
and functionality largely depends on the expressiveness of the rule
language chosen in the rule interpretation phase. This rule interpre- An appropriate description language based on a logic theory and
tation phase is thus of crucial importance for the remainder of the rule possibly able to enhance the additional challenges posed by the usage
checking process. This phase will therefore be the primary focus of of IFC, may very well be found in the semantic web domain [10]. In
this paper, whereas the effects on following phases will only be this domain, a semantic web is constructed to represent information
outlined briefly. on the world wide web (WWW) as a semantic network. This semantic
Although in many rule interpretation approaches, an intermediate, network describes concepts through a directed, labelled graph
often logic-based language is deployed to map natural language rules (Fig. 1). Each node in this graph represents a concept or object in
into a processable form, the actual implementation method is seldom the world and each arc in this graph represents the logical relation
based on such a logic theory. Implementation methods are distin- between two of these concepts or objects. In other terms, the graph
guished according to the usage of computer language encoded rules, represents a combination of logic-based declarative sentences, each
of parametric tables, or of a rule language to capture and implement sentence consisting of two nodes and a relational arc. The meaning or
the rules [5]. The first two implementation methods, which are most semantics of a concept is described through the graph associated with
often used currently, are seldom based on a rigorous logic theory, in this concept.
contrast to the latter implementation method based on a rule Next to the possibility to describe facts in a semantic network, the
language, which could be based completely on first order predicate semantic web domain also enables the description of rules using a rule
logic for instance. language similarly based on logic theory. As both the information
Several benefits of this implementation method based on a rule description language and the rule languages are thoroughly based on
language are outlined in [5]. This method would improve the por- logic theory, they can provide the possibility to implement a logic-based
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 ont:overallHeight “2180”
functionality, thereby making it possible to easily retarget the rule
inst:WindowX
checking process on native building model descriptions instead of on
ont:hasOpening rdf:type
the IFC exported building model. Furthermore, it would enable the
Element
description of an unlimited range of rules, making an almost infinitely ifc:IfcWindow
in-depth rule checking process possible.
rdfs:domain
During the following discussion of rule checking environments in inst:OpeningElementY
[5], it becomes clear that, although very sophisticated and complex xsd:double
rdfs:range
rule checking processes can and are already implemented following rdfs:subClassOf
ont:overallHeight
the first two approaches, an implementation method based on a rule rdf:type rdf:type
language for the rule interpretation phase would further enhance rdf:type
a rule checking environment, both in terms of flexibility and of owl:DataType
modularity. ifc:IfcOpening Property
Element
Such implementation methods have already been suggested in the
rdf:type
domain of conformance checking for the construction industry. In
[6,7], an implementation method was suggested based on semantic
owl:Class
web technology, more specifically deploying a semantic query
ifc:IfcBuilding rdf:type
language to infer whether or not a building model is compliant with Element
the applicable building codes. A similar approach based on logic has
been suggested in [8] for rule checking in the conceptual architectural 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 erability in the construction industry. New applications have been
limitation of IFC given above. Deploying a semantic rule language developed, capable of parsing IFC models, interpreting and reusing
should enable a declarative approach explicitly based on logic for the the available information. These software applications have mainly
implementation of a rule checking environment for building perfor- concentrated on deriving additional information concerning specialised
mance checking. At a minimum this adds the advantages of flexibility domains of interest. Exemplary are energy performance calculations, in
and modularity to the programming environment. Additionally, this which the energy performance level of the building is derived from the
approach may solve other limitations of IFC as the ones indicated above. model and compared to energy performance regulations [17], or
This paper investigates the possibility of using both an information eGovernment platforms, in which an information model can be
description language and a rule language stemming from the submitted through a web portal in order to obtain a building permit
semantic web field as a possible enhancement of IFC for building [18]. Other examples include automatic building cost calculation,
performance checking. We will first briefly compare the IFC standard simulation of a four-dimensional building schedule, escape route
with the information description languages deployed in the semantic analysis, fire and evacuation simulation, etc.
web initiative. We will show how semantic rule languages are related
to the information contained in a semantic web. A preliminary rule 2.1.2. Barriers in reaching the desired interoperability
checking environment is presented able to describe both facts and The above workflow has its limitations, some of which seem
rules in these languages, to store them in a combined knowledge base caused by the usage of the IFC schema. The following barriers or
and to draw conclusions based on logical inferences. A short limitations were found in the context of reusing IFC, partly based on
discussion of an acoustic performance checking test case completes research presented in [4,9,11].
the paper, thereby presenting our proposed methodology for per-
formance checking of a building design through a limited proof of • Limited expression range
concept. When designing a building, one is required to ‘restrain’ his or her
building design according to the IFC schema in order to gain the
2. The description of information and rules advantages IFC can offer. This causes important limitations for instance
within the domain of architectural design, in which information is
2.1. The Industry Foundation Classes often linked to information stemming from very other domains,
including for instance detailed geographic information, specialised
2.1.1. A desired future state: interoperability of information material characteristics, architecture-historical information, etc. Al-
Several languages were proposed within the field of product data though this is of lesser importance when confined to the domain of the
modelling to describe products and their data [11]. One of the most construction industry, this presents significant limitations when one
successful is EXPRESS, an information modelling language defined in wants to reference or reuse detailed construction-related information
ISO 10303-11:1994 [12]. This language “consists of language elements from within other knowledge domains, such as cultural heritage,
which allow an unambiguous data definition and specification of architectural theory, design thinking, etc.
constraints on the data defined and by which aspects of product data • Difficulties in partitioning the information
can be specified” [12]. EXPRESS was originally described as a part (Part As the IFC schema has a considerably large number of entities,
11) of the ISO 10303 standard, which is the international “Standard for defined types, enumerations and select types, it is important to
the Exchange of Product data” (STEP) [13]. The STEP standard uses provide users with the possibility to limit their scope to the
EXPRESS as its formal specification to define how product data should information they need, in order to maintain efficiency and quality in
be described and exchanged [14]. It contains several EXPRESS schemas the their work environment. A lot of research has focused on this
which can be used to describe products, thereby enabling the objective over the last years, including the in-depth research, design
exchange of this information using STEP compliant software tools. and implementation of the Model View Definitions (MVD) concept
Apart from STEP, other information models (e.g. EDIF) were proposed [9]. This research has to a certain extent addressed the initially
as well, using EXPRESS as a general information modelling language experienced barrier, but certain limitations seem to persist also in
[15]. these approaches. Alternatives and enhancements of the original
Information description in the construction industry was consid- approach should at least reflect on this limitation to indicate to what
erably influenced by the STEP standard. IFC was in this regard de- extent such additional enhancements are also necessary in these
veloped as a separate EXPRESS schema within STEP [2] by alternatives.
BuildingSMART, formerly known as the International Alliance for • Multiple descriptions of the same information
Interoperability [16]. EXPRESS and thus IFC allow information to be described in
The EXPRESS schema of IFC [2] enables a description of numerous ways. IFC also allows the description of additional generic
construction-related information through a network of entities, select objects with their proper sets of attributes, even if this information
types, enumerations, attributes, collections, relations, etc. Following is of a substantially lower level of interoperability as it is not
the IFC schema one can define a description of a building in which the included in the IFC standard. How information is eventually de-
defined objects have a well-defined and interrelated meaning and scribed in IFC, depends on how it is designed and implemented for
purpose. As a single window element can internally be described in the BIM environment at hand, and on how a user models this
very diverse ways by each BIM environment, the export and import information in a BIM environment. This range of possible descrip-
possibilities to and from IFC should guarantee that each BIM en- tions is more than desirable from a user perspective, but it requires
vironment is able to map its own descriptions to a generally an extra design and implementation effort by software engineers
understandable IFC format, thereby considerably improving interop- who want to reuse this information, as they may require the
erability of information. After several investigations and use cases information to be described in any of the other possible descrip-
over the past few years, it has become clear that these expectations tions. This may again be enhanced by the correct usage of MVD [9]
are only partly met. Although almost all current BIM modellers or by alternative approaches, but again, alternatives and enhance-
provide IFC exchange possibilities, the targeted exchange of building ments of the original approach should be checked to what extent
information with other IFC compliant software applications goes not they offer a solution to this initial limitation.
as smooth as it was initially suggested [4].
Nevertheless, IFC is currently considered one of the most ap- The first barrier, the limited expression range, seems a typical
propriate schemas for improving information exchange and interop- characteristic in the usage of any model for knowledge representation,
P. Pauwels et al. / Automation in Construction 20 (2011) 506–518 509

as no model can describe ‘all information’. No alternative model can Subject


Predicate
Object
encompass this limitation, but the appropriate combination of
technologies may enable a more intuitive extension of separate Fig. 2. The ‘triple’ form of an RDF statement: subject–predicate–object.
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 or predicate, is uniquely defined through this URI. When two identical
easy and intuitive handling of information, it needs qualitative URIs are found, their semantics are considered identical as well.
additional enhancements to make models described in this language The resulting RDF graph can be converted into a textual rep-
sufficiently manageable (easy partitioning of information, handling resentation that follows a specific syntax. Syntaxes used for RDF
parallel descriptions of the same information). When one thus graphs are RDF/XML, N-Triples [23], Turtle [24], SPARQL [25] and
considers an alternative language for knowledge representation, one Notation-3 (N3) [26]. We use the N3 syntax because it focuses on
should at least reflect on these initial barriers to indicate to what human readability and the possibility to express both data and logic in
extent such additional enhancements are still equally necessary. the same language [26]. The N3 syntax additionally provides one of
the highest levels of expressiveness within the semantic web domain
2.2. The semantic web [26], although certain information can still only be expressed in RDF/
XML and/or SPARQL (Fig. 3).
In the WWW, one may find an appropriate description language as Fig. 4 illustrates how a window may be described using N3. The
a valid alternative for EXPRESS. As the WWW contains information first two statements define two ‘prefixes’ (inst: and ont:) that
about almost any possible concept in the world, the language enable the abbreviation of the URIs used in the RDF statements below.
describing this information cannot follow one domain-specific Using the inst: prefix for instance, one can reconstruct the URI of the
schema. A limited expression range as observed in the IFC schema is resource inst:WindowX into bhttp://smartlab.elis.ugent.be/
thus not acceptable. Instead, a flexible and generic language is needed aimontologies/inst/SLwindow#WindowXN. The lower lines describe
that allows one to describe and easily link information from very two statements about the concept inst:WindowX, concatenated by a
different knowledge domains together. Because content needs to be ‘.’ as a representation of the logical AND operator. The predicates ont:
described for very diverse and large knowledge domains while hasOpeningElement and ont:overallHeight label the logical
maintaining its interrelations, sound partitioning possibilities should relations attached to the inst:WindowX concept.
be provided by this language, enabling users to describe concepts in
separate limited scopes and still be able to relate them back to 2.2.2. Web ontology language
concepts described earlier in different scopes. RDF graphs can be given an improved semantic structure using
The semantic web was conceived in [19] as a semantic network RDF vocabularies or ontologies. The most basic elements to describe
that describes the meaning of its concepts through a directed, labelled such ontologies are available in the RDF Schema (RDFS) vocabulary
graph (Fig. 1) based on description logic [20]. Each node in this graph [22]. RDFS for instance enables the specification of classes, subclasses,
represents a concept or object in the world and each arc in this graph comments, data types, etc. This specification is done through RDF
represents the logical relation between two of these concepts or statements that deploy concepts from the RDFS vocabulary. Examples
objects. In this way, the graph represents a set of logic-based can be found in Fig. 5, specifying for instance that the ifc:IfcWindow
declarative sentences. class is a subclass of the ifc:IfcBuildingElement class.
Similar to the way in which the construction industry relies on More expressive elements to describe ontologies are available
EXPRESS as a language to build schemas within the STEP standard within the Web Ontology Language (OWL) [20], which uses RDFS
(e.g. IFC schema), the semantic web uses the Resource Description concepts as a subset. The RDF graphs constructed with OWL concepts
Framework (RDF) as a language to represent its graph structure [21]. are called OWL ontologies, and they can be used as an available
This graph structure is generally referred to as an RDF graph. Within vocabulary when making other, more complex RDF statements. Such
the semantic web domain this was soon considered a standard an OWL ontology can be compared to the IFC schema in EXPRESS, only
language to describe any possible kind of information, not limited to using OWL/RDF as a language instead of EXPRESS. An OWL ontology
the WWW. Information thus implicitly became interoperable be- may include descriptions of classes, properties and their instances.
tween different environments, whether these environments be web RDF resources can then ‘belong to a specific class’ of an OWL ontology,
pages, complete software environments, or anything else [21]. as illustrated in Fig. 5. By extending RDF with this OWL functionality,
Today the development of the semantic web is mainly led by the virtually any kind of information can be described semantically.
World Wide Web Consortium (W3C) [10], significantly supported by When using OWL and RDFS concepts in the RDF graph, one can
actors stemming from various corners, including both scientific infer new information through a standard reasoning process. For
research institutes and industrial partners. According to the W3C, instance when a resource is part of a subclass, a reasoner can au-
the semantic web nowadays consists of a web of ‘linked data’ that is tomatically infer that the resource is also part of the superclass.
superseding the borders of individual applications and hence is Some of the concepts in the OWL language enable the specification of
interconnected through links between identical or related entities. more elaborate rules. The RDF graph in Fig. 6 for instance describes that
Since the full explanation of semantic web technologies exceeds the for a concept to be an instance of the ont:ResidentialBuilding
scope of this paper, we merely touch the basic concepts below and class, it always requires some values from the ont:Bedroom class for
refer to more elaborate information sources elsewhere [10,20–23]. 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.1. Resource description framework
An RDF graph is constructed by applying a logical AND operator to 2.2.3. Rule languages
a range of logical statements containing concepts or objects in the The available RDFS and OWL concepts enable only a basic,
world and their relations. These statements are often referred to as standard level of reasoning, limited to a certain level of complexity.
‘RDF triples’, consisting of a subject, a predicate and an object (Fig. 2), When a more complex logical reasoning is necessary, one may need to
consequently implying directionality in the RDF graph. In addition, build his or her rules in a more dedicated rule language. Using a
each concept and relation has a Unique Resource Identifier (URI) specific rule language one is able to define custom rules and
assigned to it, thereby making the RDF graph explicitly labelled. Every subsequently use them in a rule-based reasoning process. Several
concept described in an RDF graph, whether this is an object, subject 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 this working group has submitted a candidate recommendation
Web Rule Language (SWRL) [28], the Rule Interchange Format (RIF) regarding a RIF Framework for Logic Dialects [32,33], which was
[29] and the N3Logic language [30]. recently approved. At the core of the framework RIF is very similar to
SWRL was proposed as one of the first semantic rule languages in the SWRL effort in that it allows rules to be expressed both in XML as a
[28]. It is based on a combination of OWL and RuleML [31]. Both an normative concrete syntax and in a more human-readable abstract
abstract and an XML concrete syntax were proposed to describe rules. syntax. N3Logic is an alternative approach to SWRL and RIF, proposed
A similar approach was picked up by the RIF working group setup at in [30]. Unlike SWRL and RIF, this third rule language is based on N3 as
the W3C while constructing RIF [29]. After several draft specifications, 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
ont:overallHeight
“2180” sharable information on logic. They enable information with a far
greater expressive power (such as rules) to be sharable similar to the
inst:WindowX 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
ont:hasOpeningElement
environment.
We are currently using N3Logic to describe custom rules. A rule in
N3Logic contains hypothetical ‘formulae’. Every hypothetical formula
inst:OpeningElementY thereby uses curly brackets in its syntax to describe a subgraph, i.e. a
logical conjunction of the statements between the curly brackets [30]
@prefix inst: <http://smartlab.elis.ugent.be/aimontologies/inst#> .
@prefix ont: <http://smartlab.elis.ugent.be/aimontologies/ont#> .
(Fig. 7). Following the syntax of an RDF triple statement, a rule may
describe that IF one hypothetical formula is true, THEN the other
inst:WindowX ont:hasOpeningElement inst:OpeningElementY . hypothetical formula is also true. In addition, an N3Logic rule
inst:WindowX ont:overallHeight “2180.00”^^xsd:double references the concepts required in the rule using the URIs of these
concepts, optimally abbreviated with prefixes.
Fig. 4. Semantic web description of a window, both in a visual graph and an N3 An example of a rule in N3Logic is given in Fig. 7. This rule specifies
representation. 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 . 2.3. Towards a combined approach for the construction industry
ont:overallHeight rdf:type owl:DatatypeProperty .
ont:overallHeight rdfs:domain ifc:IfcWindow . 2.3.1. Possible enhancements generated by the combination
ont:overallHeight rdfs:range xsd:double
IFC — semantic web
Following the overview given above, one can outline how se-
Fig. 5. An OWL ontology describing an IfcWindow class. 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
property AND that property has an ont:hasR63Hz property, THEN
in logic theory. Also the N3Logic rule language is explicitly built on
that entity has an ont:hasAcousticProperty property with the
logic theory. The combination of the RDF and N3Logic languages
same URI as (i.e. identical to) the ont:hasR63Hz property.
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.
ont:ResidentialBuilding rdf:type
Secondly, the usage of URIs in RDF enables the description of
owl:equivalentClass information in very diverse and disparate groups while preserving its
owl:Class
original interrelations. This allows the unlimited connection of very
loosely related knowledge domains, such as BBC's multimedia
owl:someValuesFrom information, healthcare information, material information and build-
owl:onProperty rdf:type ing information into one web. The indirectly extended expression
range consequently allows building information to step out of its
rdf:type
specialised field of the construction industry and make possibly useful
ont:hasBedroom ont:Bedroom 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
rdf:type
languages and rule languages. With these techniques, it should be
owl:Restriction
fairly easy to do an appropriate partitioning of information, because it
allows an easy selection of the required information and an intuitive
owl:ObjectProperty
conversion into the required information structure. One is in this case
not obliged or restricted to the usage of MVDs for instance, but may
ont:ResidentialBuilding rdf:type owl:Class .
extract the model view definition instantaneously in any possible
ont:ResidentialBuilding owl:equivalentClass _:125 . format required at any specific time, thereby relying on standard
_:125 rdf:type owl:Restriction . functionality provided by a rule engine or a query processor.
_:125 owl:onProperty ont:hasBedroom . Finally, the RDF graph structure at the core of the semantic web
_:125 owl:someValuesFrom ont:Bedroom .
ont:Bedroom rdf:type owl:Class . easily enables one to define new concepts, classes, properties, etc. and
ont:hasBedroom rdf:type owl:ObjectProperty 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
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
information can be described. These descriptions can be interlinked in
only used in the serialisation into the N3 syntax. This identifier may not be used as a URI various places at the wishes of the person that specifies the information.
and consequently does not appear as a named label in the RDF graph [26]. 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 and function information, which is typically described in the semantic
for the conversion of geometric information in [34]. web field using rule languages instead of relying on the standard
An in-depth investigation of how semantic web technologies may reasoning capabilities of OWL. We argue that a full conversion of
address the three observed barriers in achieving the desired level of EXPRESS schemas may be reached when describing explicit logic-
interoperability, is not given in this paper because of its focus on rule based functionality with the appropriate rule language, for instance
checking functionality. The above overview nevertheless suggests N3Logic.
how these technologies may prove an enhancement or at least a valid The third approach for developing a rule checking system driven
alternative approach for the existing approaches. The absence of a by a rule language, has been suggested and presented in [8]. Although
mathematically rigorous logic theory may clearly be resolved through the presented ConDes system does not rely on semantic web
the adoption of semantic web technologies. It enables the usage of a technology, it proposes a visual knowledge specification that can be
declarative approach in the development of rule checking environ- considered equally expressive as any RDF graph specification. This
ments, making the application logic in these environments both more visual knowledge specification is used for the specification of
flexible and more modular. Note that such an approach conserves the conceptual architectural designs, using an add-on in the ArchiCAD
significant efforts put into the design and specification of IFC. The IFC 3D modelling environment of Graphisoft. This knowledge graph can
specification is merely enhanced to enable an improved rule checking be combined with design rules that are to be formalised by one or
process. more specialised knowledge engineers. Combining both the knowl-
edge graph and the design rules in ArchiCAD, similar to the
2.3.2. Comparison with previously suggested approaches based on a rule methodology suggested in [7], an architect is enabled to model
language information from the very first conceptual design stage and check
Rule checking approaches based on a rule language have already whether or not this design conforms to the applicable custom design
been suggested over the last few years. In [6] for instance, a rules. The ConDes system is a good example of what functionality a
methodology is suggested for conformance checking in the construc- rule checking system based on a logic-based language may provide to
tion industry. In this methodology an IFC building model is first a specialist in the construction industry. Relying on technology that is
converted into an RDF graph, building regulations are then digitised widely supported and acknowledged, such as semantic web technol-
into a set of ‘IF-THEN’ rules, after which the ontologies of both the ogy, might nonetheless provide a more solid basis for developing such
‘construction rules’ and the ‘construction project’ are aligned using a system.
specific alignment algorithms. In implementing this very sound
methodology, the authors have chosen to rely on an XSLT transfor- 3. A semantic rule checking environment for building models
mation between the ifcXML representation of an IFC model and the
RDF/XML representation of an RDF graph for the transformation Starting from the outlined possibilities of combining semantic web
procedure from IFC to RDF. Additionally, the set of IF-THEN rules is technology with IFC, we conceived a semantic rule checking
implemented using the SPARQL query language [7], which has the environment for the construction industry, thereby investigating
ability to express singular IF-THEN functionality through the how the rule checking process may be improved with a dedicated rule
CONSTRUCT formalism in SPARQL [25]. language and rule engine. This environment was conceived and
Notwithstanding the significant value of the methodology pro- developed as a part of the architectural information modelling (AIM)
posed in [6] and the significant improvements shown in the framework previously presented in [35]. We solely document the rule
conformance checking process, the implementation choices made in checking environment as the discussion of the AIM framework falls
[7] seem to limit functionality in the eventual rule checking outside the scope of this paper. The concluding test case will provide
environment. As Fig. 3 already indicated, the N3 syntax generates clear examples of the conceptual methodology outlined in this
higher expressiveness than the standard RDF/XML syntax. This section.
specifically applies to the expression of IF-THEN functionality and In our discussion we first document how a knowledge base can be
other rule handling functionalities, as can be concluded from the conceived, containing both explicit building information (facts) in
location of the IF-THEN symbol (=N) in Fig. 3. Although SPARQL RDF graphs and implicit building information (rules) in N3Logic. We
provides a very useful and intuitive CONSTRUCT formalism, it was still present how an inference engine is able to combine information in
originally intended as a query language for RDF graphs [25] and not as this knowledge base to retrieve the information desired. An interface
a rule language. Apart from being restricted to IF-THEN functionality, completes the rule checking environment for the construction
SPARQL is merely useful for a one-by-one querying or rule checking of industry (Fig. 8). We point out improvements over existing rule
a building model and does not allow an equally automated rule checking engines for the construction industry in our brief overview.
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 Knowledge Base
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- Explicit
building
quently be used to build a set of RDF instances describing a building or information
a building component in a semantic web format. Such a conversion
procedure allows constructing and handling RDF graphs in dedicated Inference Engine
semantic web software, which may then be outputted in various Implicit
syntaxes. Added to the fact that EXPRESS has a higher level of building
information
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 Interface
equivalent in OWL, such as WHERE rule constraints and procedural
FUNCTION calls. However, this mainly concerns more advanced rule Fig. 8. Conceptual overview of the rule checking environment proposed in this paper.
P. Pauwels et al. / Automation in Construction 20 (2011) 506–518 513

3.1. Explicit building information: RDF graphs graphs containing architectural history, geographical or design
information, thereby resulting in a far more rich information model
Several vocabularies are currently being constructed as OWL than the IFC schema can provide.
ontologies, thereby enabling the description of building information
in an RDF graph using structured vocabularies. We will only mention 3.2. Implicit building information: N3Logic rules
two of our OWL ontologies here, namely an IFC ontology and a
construction element ontology. Other ontologies focus on information Parallel to the explicit building information, a range of rule sets is
about architectural theory, design, actors, geographical locations, etc. developed in N3Logic and added to the knowledge base. They enable
The IFC ontology is largely similar to the ontology discussed in the description of information that is implicitly available in the
[11]. The EXPRESS schema was transformed into an OWL ontology. In building model. Every rule set contains rules that can be applied to
this transformation process, every EXPRESS element that has a direct RDF graphs in order to infer this implicit information. They are thus
equivalent in OWL is mapped onto this equivalent. For each ENTITY closely related to the ontologies deployed in describing these RDF
element in EXPRESS a corresponding OWL class is generated, EXPRESS graphs. We briefly discuss how these rules are described and how
attributes are converted into the appropriate OWL properties, etc. they are related to the explicit building information available in the
Having the eventual IFC ontology at our disposal, we are able to knowledge base, thereby making the comparison with existing
generate IFC/RDF instances as part of the explicit information in our approaches in the rule checking process as they were outlined in [5].
knowledge base. We are currently relying on existing BIM applica-
tions to generate an IFC model that can subsequently be converted 3.2.1. Rule description
into an equivalent IFC/RDF graph using our in-house IFC-to-RDF Rules are described in conformance with the N3Logic syntax [30].
converter [36]. A part of an IFC/RDF graph is displayed in Fig. 9. An example of such a rule was previously given in Fig. 7. These rules
The construction element ontology is constructed by applying a are combined into rule sets, for instance separating a rule set for
D2R server mapping [37] onto an existing construction element acoustic performance checking and a rule set for energy performance
database. This relational database collects test information about checking.
construction elements produced in Belgium. This test information One can outline several advantages caused by using a semantic
mainly concerns acoustic and thermal characteristics, such as sound rule language as N3Logic compared to traditional approaches. As
reduction indexes, thermal resistances, etc. On top of this database, outlined in [5], many software environments exist adopting a
RDF graphs describing construction elements (CONSTR/RDF procedural approach, whereas the declarative approach driven by a
instances) are generated real-time using the D2R mapping [38]. The rule language is named as the more appropriate long term
resulting CONSTR/RDF instances are in this way available as part of the implementation method for building rule checking. The two following
explicit information in the knowledge base. advantages of using a declarative approach were given in [5].
References between the different graphs of the knowledge base,
• Portability
under which are the IFC/RDF graph and the CONSTR/RDF graph, can be
It is possible to deploy, evaluate and edit the same set of rules in
created using explicit RDF statements. This allows creating a building
completely different software environments and applications, as
information graph containing both IFC/RDF information and CONSTR/
long as a commonly agreed upon rule language is deployed in
RDF information for instance. Fig. 9 displays how an instance in an IFC/
these environments.
RDF graph can be linked to an instance of the CONSTR/RDF graph. The
• Flexibility
instances in the building information graph can similarly be linked to
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.
inst:ifcOwnerHistory_33
Because of its foundation in logic theory, this approach lies within
inst:ifcProductDefinitionShape_461 reach when deploying a semantic rule language such as N3Logic.
Additionally, it enables the direct usage of existing logic-based
ifc:ownerHistory ifc:representation technologies during the rule checking process. The rules described
in N3Logic can for instance be directly deployed by existing logic-
inst:ifcLocalPlacement_381 based inference engines to check them in an explicit context or they
can be visualised in environments specialised in the visualisation of
ifc:objectPlacement logic rules, etc.

inst:ifcWallStandardCase_417 rdf:type 3.2.2. Relation with explicit building information


Similar to how they are described in natural language, rules tend to
constr:material deploy their own vocabulary, consisting of concepts that apply
ifc:IfcWallStandardCase
specifically to the rule set at hand and that are not available in the
constr:product_461 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
inst:ifcWallStandardCase_417 rdf:type ifc:IfcWallStandardCase . or thermal standard rule set. We therefore consider it useful to create a
inst:ifcWallStandardCase_417 constr:material constr:product_461 .
inst:ifcWallStandardCase_417 separate rule set vocabulary using OWL to describe the concepts
ifc:objectPlacement inst:ifcLocalPlacement_381 . deployed within each rule set. One can easily see how the rule displayed
inst:ifcWallStandardCase_417 in Fig. 10 for instance deploys only concepts stemming from its rule set
ifc:representation inst:ifcProductDefinitionShape_416 . vocabulary in OWL (i.e. ruleOnt:).
inst:ifcWallStandardCase_417 ifc:ownerHistory inst:ifcOwnerHistory_33
An explicit relation is needed between the different descriptions of
both the explicit building information and the implicit building
Fig. 9. Linking instances of an IFC/RDF graph to the appropriate construction element information. Otherwise, none of the rules described will be able to
information available in a CONSTR/RDF graph. 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 Location
math:greaterThan rdf:type
rdf:type
“3000”
Design ...
ruleOnt:aHighWall
ruleOnt:Wall

log:implies Theory IFC

{
?x rdf:type ruleOnt:Wall . Construction
?x ruleOnt:hasHeight ?y . Elements
?y math:greaterThan “3000”^^xsd:double ...
}
log:implies
{ Conversion
?x rdf:type ruleOnt:aHighWall Rule Set Conversion ...
} Rule Set

Fig. 10. Example of a rule described using its own rule ontology in OWL.
Rule
Rule ...
Ontology
Ontology

model. When deploying semantic web technology, however, this is Rule Set
fairly easily dealt with. A separate ‘conversion rule set’ can explicitly
Rule Set
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
Fig. 11. Rule sets linked to the core knowledge base deploy a separate ontology
acoustic performance rule set for instance, this conversion rule set definition and a conversion rule set.
explicitly describes how the running inference engine can interpret
the information described in the inputted RDF graph containing
building information. 3.3.1. The inference process
This approach guarantees that both the explicit information Main issues in the existing implementation approaches for rule
contained in the building information graph and the implicit checking environments currently concern syntactic pre-checking of
information contained in the rule set remain manageable and allow the model and the management of the rule execution process [5].
changes. When for instance the structure of the building information Because neither the IFC language nor the encoded rules are based on a
graph changes, it is only necessary to update the conversion rule sets mathematically rigorous theory this syntactic pre-checking and
without having to deal with the logic of the rule set itself. An overview management require an important amount of implementation work
of the resulting knowledge base that is to be addressed by the in order to let the rule checking environment function properly.
semantic rule checking environment, is shown in Fig. 11. As both the RDF graph and the rules defined in the semantic rule
As can be seen in Fig. 11, each rule set can thus be considered as a language are firmly rooted in logic theory, this amount of implemen-
separate addition of implicit information, each time for a very specific tation work is not an issue for semantic web technologies. Existing
domain of knowledge. Since they rely on the same central information technologies are based on these principles and are thus able to
base, these rule sets are nevertheless related and thus require a sound perform tasks like syntactic pre-checking and rule checking manage-
organisation or structure. One could for instance organize these rule sets ment automatically. A large amount of research in the semantic web
hierarchically (e.g. construction industry N structural–performance– field for instance focuses on improving semantic consistency checkers
architectural N ...), in distinct groups according to geographical para- for RDF graphs, ontology, data alignment, etc., independent of the
meters, or maybe completely intertwined at diverse levels. How this contents described but instead completely relying on logical princi-
relation is organized, requires further attention in future design and ples. Rule engines are part of these semantic web technologies.
implementation phases, as such a decision is hard to make in this early Several existing rule engines are able to infer information and return
stage of research. 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
3.3. The semantic rule checking environment significant advantage over existing rule checking environments.
Several semantic rule engines exist. The typical output of these
The knowledge base documented above contains the information engines is a conclusion, most often represented as a set of newly
required by a rule checking environment to perform specific rule inferred facts or as a proof that a statement holds or not. An elaborate
checks for the construction industry. Because of the semantic, logic- comparison of existing reasoning engines is out of scope for this
based nature of RDF and N3Logic, existing inference engines or rule paper. Instead, we give only a brief description for two of the most
engines can be deployed to make the logical inferences needed. An significant reasoning engines and refer to more elaborate information
interface on top of the knowledge base and the deployed rule engine elsewhere [39–43].
enables displaying both the available information and the resulting The Closed World Machine (CWM) reasoner was the first reasoner
inferences, thereby completing the semantic rule checking environ- built for processing N3Logic and RDF graphs. It is developed as a
ment for the construction industry. “general-purpose data processor for the semantic web” [39] and is
P. Pauwels et al. / Automation in Construction 20 (2011) 506–518 515

capable of loading resources, applying rules and outputting results in Nonetheless, we argue that a management system for construction
one of the several syntaxes available for RDF. CWM is a typical industry rule checking could use one or more of these automatic
forward-chaining reasoner, meaning that it starts from the available visualisation approaches to optimally display the results of the
facts and uses the available inference rules to infer new facts, after building performance checking process and give a construction
which these facts are added to the initial facts base and the reasoning industry specialist the feedback he or she needs in the format he or
process starts all over until there is nothing more to infer. The benefit she likes. Considering the experienced flexibility and the expressive-
of using a forward-chaining reasoner is that a lot of new information ness of N3Logic as a rule language, this information can easily be
becomes available, which could be useful for certain automation provided in the resulting RDF graph report.
purposes. On the other hand, in many cases far too much unnecessary
information is inferred, forcing even the smallest queries to go 4. Test case: the acoustic performance regulations
through an unnecessary long inferential discussion.
A backward-chaining reasoner on the other hand starts from a set 4.1. The setup of the test case
of hypotheses, which are most often passed to the engine through an
initial SPARQL query. It searches both among the supplied resources A test case was set up for the investigation of how the configuration
for the elements contained in the given hypotheses, as among the given above may improve existing rule checking processes in
supplied inference rules for those that have the input hypotheses in architectural design and construction. As a subject we chose the
their THEN clause. If the IF clause of a needed rule is not known to be newly emerging acoustic performance regulations both on a European
true, it is added to the hypotheses, and the search process continues. level as on a national level in Belgium, assuming that the methodology
Reasoning is consequently limited to a minimum and occurs on- deployed can be extended to other calculation and simulation
demand. The Euler Yap Engine (EYE) is one of the most notable processes as well. Note that we merely aim at documenting a proof
reasoners based on N3Logic and RDF graphs that implements a of concept, and not a fully implemented and widely usable application.
backward–forward–backward chaining inference process [40,41]. We merely show the basic concepts in order to make clear to what
Rule engines similar to CWM and EYE exist and are under extent this may form a valid alternative to existing approaches.
development for SWRL and RIF [42]. Differences concerning efficiency,
resource allocation, etc. between the two reasoning engines docu- 4.2. European and national standards
mented above, and between other engines as well, need to be
investigated and taken into account when planning the design and March 2000 was the publication date of the European standard
implementation of an effective and widely used reasoning environ- EN12354 [46] for the estimation of the acoustic performance of
ment. Because the research documented in this paper concentrates on buildings from the performance of elements. This standard consists of
the mere value of deploying such an engine for rule checking in the several parts, specifying the estimation process for instance for the
first place, we will not elaborate on such an investigation here. airborne sound insulation against outdoor sound, or for the
transmission of indoor sound to the outside. We solely addressed
3.3.2. Reporting of rule checking results the third part of the standard in this test case, namely ‘EN 12354-
The output of semantic web engines is in most cases returned in the 3:2000: Airborne sound insulation against outdoor sound’ [46].
form of new RDF statements. These results can directly be passed The EN 12354-3:2000 standard documents the way in which the
through to an existing visualisation software built for RDF graphs. The relevant quantities for expressing an acoustic building performance
most obvious choice would be to automatically export the resulting RDF can be both derived from quantities measured on-site or calculated
statements into an RDF triple store and make them accessible through a from a given calculation model and more basic rules of thumb. Fig. 12
SPARQL endpoint on the web [25]. Web pages and textual documen- for instance shows how to calculate the sound power ratio of radiated
tation reports can then be generated automatically on top of this sound power by a façade element i due to direct transmission of sound
endpoint if only the appropriate software applications are available to incident on this element, relative to incident sound power on the total
perform the visualisation effort for semantic web technology in general. façade [46].
Alternatively, when using a backward-chaining rule engine or proof- As the European standard only provides a means to derive the
engine, one can also obtain a proof as the output result of the checking required quantities for expressing an acoustic building performance,
process. Recording the backward-chaining process namely enables it leaves out the process of evaluating these quantities resulting in a
explicitly stating why something ‘passes’ or ‘fails’. ‘pass’, ‘fail’, ‘warning’ or ‘unknown’ message for building elements or
Several efforts in the semantic web field are currently focusing on for the building itself. This part of the evaluation process is to be
providing an optimised visualisation framework for RDF graphs. The addressed by the national standards organisations of the involved
online Disco Hyperdata Browser [44] for instance automatically countries in Europe [46].
generates and continuously updates an interactive web interface In response to the European standard, the National Bureau for
displaying the RDF information, thereby providing a more intuitive Normalisation (NBN) in Belgium published the national regulation
access to the data. Alternatively, one could also deploy N3Logic rules NBN S 01-400-1 in January 2008 [47]. This regulation specifies the
to generate custom graphical user interfaces (GUI) based on the acoustic performance requirements to be met in the construction of
outputted RDF graph. An initial investigation of this approach, applied new dwellings, regarding the insulation against airborne, contact and
to the healthcare industry, can be found in [45]. outdoor sound. The acoustic performance level against outdoor sound
In the design and implementation of such a reporting system, very hereby specifies explicit references to the acoustic quantities that can
diverse approaches for report visualisation may be chosen, thereby be obtained from the European EN 12354-3:2000 standard. An extract
incorporating varying interface strategies. An interface may for of NBN S 01-400-1:2008 given in Fig. 13 shows for instance the
instance focus on the sufficiency or insufficiency of certain building conditions that have to be met in order for a building to reach a
information required for the rule checking process, or it may focus on normal (Dutch: ‘normaal akoestisch comfort’) or an increased (Dutch:
the precise indication of problematic sections in the building, etc. ‘verhoogd akoestisch comfort’) acoustic performance level.
Other approaches and strategies exist, and will be generated in the
future, in response to specific needs and/or requirements. The 4.3. Explicit building information: RDF graphs
discussion of the most appropriate approach(es) or to what extent
the information required for rule check reporting may be generated A building information graph was constructed for this test case,
from a set of rules in N3Logic, was not part of this initial research. following the methodology given above. A simple building model was
516 P. Pauwels et al. / Automation in Construction 20 (2011) 506–518

{
?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
Fig. 12. The calculation procedure for several acoustic performance properties of standard, resulting in a rule ontology, a conversion rule set and the
buildings is given in [46]. actual rule set for the standard. Starting from the concepts derived
from both rule sets and their ontologies, one may thus eventually
created in a BIM application, namely Autodesk Revit Architecture derive an explicit statement about whether or not the building model
2010. This model was subsequently exported into an IFC represen- applies to a certain acoustic performance level, defined according to
tation, which was then converted into an IFC/RDF graph using our in- the Belgian NBN S 01-400-1 standard.
house IFC-to-RDF converter [36]. This graph was extended with
information from the CONSTR/RDF graph, resulting in an RDF graph of 4.4.2. Relation with explicit building information
which a part was previously presented in Fig. 9. The defined rules deploy concepts stemming from a rule ontology,
separately described in OWL. An inference engine needs to be able to
4.4. Implicit building information: N3Logic rules relate these concepts to the concepts described in the building
information graph. A dedicated conversion rule set is developed for
4.4.1. Rule description this purpose, containing concepts from the RDF graph in its IF clauses
The two above regulations had to be formalised into rules. We and concepts from the rule ontology in its THEN clauses. In this case,
chose to explicitly separate the specifications described in both the rule engine will consequently know how to translate or convert
standards and generate both an EN 12354-3:2000 and an NBN S 01- certain concepts with base URIs represented by the ifc: and
400-1:2008 rule set. This enables for instance the derivation of the constr: prefixes into concepts with the EN12354: prefix, which
relevant acoustic quantities defined by the European standard, represents the base URI of the rule ontology (Fig. 15).
keeping the possibility to subsequently combine them with other With this conversion rule set, the concepts required for the
relevant rule sets, for example the European equivalents to the acoustic calculations can be automatically inferred for any building
Belgian NBN S 01-400-1:2008 standard. information graph containing the required concepts. This can be
Both standards are manually interpreted and translated into a rule considered being implicit information available for the building
ontology in OWL, describing the concepts used within the standard, a information graph at hand. This implicit information describes for
rule set in N3Logic, describing the logic in the standard, and a instance an acoustic performance level acquired according to the
conversion rule set making the references required to the building EN12354-3:2000 and the NBN S 01-400-1:2008 standards.
information graph. The code fragment in Fig. 14 illustrates for instance
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.
Fig. 13. [47] describes what conditions need to be fulfilled in order to reach a certain As the rules describing the two acoustic standards enable the logical
acoustic performance level. 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 [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
checking examples. The outcome nevertheless indicates the validity of accessed on 12th. July 2010).
deploying semantic web technology to improve building performance [21] F. Manola, E. Miller, RDF Primer - W3C Recommendation, http://www.w3.org/TR/
checking in the construction industry. 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
Acknowledgements (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).
This research is a combined effort of the UGent SmartLab and [24] D. Beckett, T. Berners-Lee, Turtle - Terse RDF Triple Language - W3C Team
Multimedia Lab research groups, supported by the Interdisciplinary Submission, http://www.w3.org/TeamSubmission/turtle/ January 14 20088(last
accessed on 12th. July 2010).
Institute for Broadband Technology (IBBT) and both the Department [25] E. Prud'hommeaux, A. Seaborne, SPARQL Query Language for RDF - W3C
of Electronics and Information Systems and the Department of Recommendation, http://www.w3.org/TR/rdf-sparql-query/ January 15 20088
Architecture and Urban Planning of Ghent University. The project (last accessed on 12th. July 2010).
[26] T. Berners-Lee, D. Connoly, Notation 3 (N3): A readable RDF Syntax - W3C Team
team gratefully acknowledges the funding support from the Research Submission, http://www.w3.org/TeamSubmission/n3/January 14 20088(last
Foundation — Flanders (FWO). 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).
References [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
[1] C.M. Eastman, P. Teicholz, R. Sacks, K. Liston, BIM Handbook: A Guide to Building Submission, http://www.w3.org/Submission/SWRL/ May 21 2004, (last accessed
Information Modeling for Owners, Managers, Architects, Engineers, Contractors, on 12th. July 2010).
and Fabricators, John Wiley and Sons, Hoboken, 2008. [29] Rule Interchange Format (RIF) Working Group, http://www.w3.org/2005/rules/
[2] T. Liebich, Y. Adachi, J. Forester, J. Hyvarinen, K. Karstila, K. Reed, S. Richter, J. Wix, wiki/RIF_Working_Group, (last accessed on 12th. July 2010).
Industry Foundation Classes IFC2x Edition 3 Technical Corrigendum 1, http:// [30] T. Berners-Lee, D. Connolly, L. Kagal, Y. Scharf, J. Hendler, N3Logic: a logical
www.iai-tech.org/ifc/IFC2x3/TC1/html/index.htm, (last accessed on 12th. July framework for the world wide web, Theory and Practice of Logic Programming
2010). 8 (3) (2008) 249–269.
[3] M.P. Gallagher, A.C. O'Connor, J.L. Dettbar, L.T. Gilday, Cost analysis of inadequate [31] The Rule Markup Initiative, http://ruleml.org/, (last accessed on 12th. July 2010).
interoperability in the U.S. capital facilities industry, NIST Report GCR 04-867, [32] H. Boley, M. Kifer, RIF Framework for Logic Dialects - W3C Recommendation, http:
National Institute of Standards and Technology (NIST), 2004. //www.w3.org/TR/rif-fld/ June 22 2010, (last accessed on 12th. July 2010).
[4] Y.-S. Jeong, C.M. Eastman, R. Sacks, I. Kaner, Benchmark tests for BIM data [33] H. Boley, M. Kifer, RIF Basic Logic Dialect - W3C Recommendation, http://www.
exchanges of precast concrete, Automation in Construction 18 (2009) 469–484. w3.org/TR/rif-bld/ June 22 2010, (last accessed on 12th. July 2010).
[5] C.M. Eastman, J. Lee, Y. Jeong, J. Lee, Automatic rule-based checking of building [34] P. Pauwels, D. Van Deursen, J. De Roo, T. Van Ackere, R. De Meyer, R. Van de Walle,
designs, Automation in Construction 18 (2009) 1011–1033. J. Van Campenhout, 3D information exchange over the semantic web for the
[6] A. Yurchyshyna, C.F. Zucker, N. Le Thanh, C. Lima, A. Zarli, Towards an ontology- domain of architecture, engineering and construction, Artificial Intelligence for
based approach for conformance checking modeling in construction, Proceedings Engineering Design, Analysis and Manufacturing, Special Issue 25 (4) (2011)
of the 24th CIB W78 Conference, Maribor, 2007. (submitted).
[7] A. Yurchyshyna, A. Zarli, An ontology-based approach for formalisation and [35] P. Pauwels, R. Verstraeten, R. De Meyer, J. Van Campenhout, Semantics-based
semantic organisation of conformance requirements in construction, Automation design: can ontologies help in a preliminary design phase? Design Principles and
in Construction 18 (8) (2009) 1084–1098. Practices: An International Journal 3 (5) (2009) 263–276.
[8] B. Kraft, M. Nagl, Visual knowledge specification for conceptual design: definition [36] UGent MultiMediaLab, IFC-to-RDF Converter Service, http://ninsuna.elis.ugent.
and tool support, Advanced Engineering Informatics 21 (2007) 67–83. be/IfcRDFService/, (last accessed on 12th. July 2010).
[9] J. Hietanen, IFC Model View Definition Format, International Alliance for [37] C. Bizer, R. Cyganiak, D2R Server - Publishing Relational Databases on the Semantic
Interoperability (2006). Web, http://www4.wiwiss.fu-berlin.de/bizer/d2r-server/, (last accessed on 12th.
[10] W3C Semantic Web Activity, http://www.w3.org/2001/sw/, (last accessed on July 2010).
12th. July 2010). [38] UGent SmartLab, SPARQL endpoint for the TIATAB material database, http://
[11] J. Beetz, J. van Leeuwen, B. de Vries, IfcOWL: a case of transforming EXPRESS smartlab.elis.ugent.be/SPARQLEndpoint/, (last accessed on 12th. July 2010).
schemas into ontologies, Artificial Intelligence for Engineering Design Analysis [39] T. Berners-Lee, CWM, http://www.w3.org/2000/10/swap/doc/cwm, (last accessed
and Manufacturing (AI EDAM) 23 (1) (2009) 89–101. on 12th. July 2010).
[12] ISO 10303-11, Industrial automation systems and integration – product data [40] J. De Roo, Euler Proof Mechanism, http://www.agfa.com/w3c/euler/, (last accessed
representation and exchange – Part 11: description methods: the EXPRESS on 12th. July 2010).
language reference manual, http://www.iso.org/iso/iso_catalogue/catalogue_tc/ [41] J. De Roo, Eye, http://eulersharp.sourceforge.net/2003/03swap/eye-2009.txt, (last
catalogue_detail.htm?csnumber=183481994, (last accessed on 12th. July 2010). accessed on 12th. July 2010).
[13] STEP Overview - STEP (ISO 10303) Product Data Representation and Exchange, [42] RIF Working Group, Implementations, http://www.w3.org/2005/rules/wiki/
http://www.tc184-sc4.org/SC4_Open/SC4%20Legacy%20Products%20%282001- Implementations8(last accessed on 12th. July 2010).
08%29/STEP_%2810303%29/, (last accessed on 12th. July 2010). [43] T. Berners-Lee, D. Connolly, S. Hawke, Semantic Web Tutorial Using N3, http://
[14] D. Scheck, P. Wilson, Information Modeling: the EXPRESS Way, Oxford University www.w3.org/2000/10/swap/doc/tutorial.pdf 2003, (last accessed on 12th. July
Press, New York, 1994. 2010).
[15] R. Lau, H. Kahn, Information modelling of EDIF, Proceedings of the 30th ACM/IEEE [44] C. Bizer, T. Gauss, Disco - Hyperdata Browser: A simple browser for navigating the
Design Automation Conference, 1993, pp. 278–283. Semantic Web, http://www4.wiwiss.fu-berlin.de/bizer/ng4j/disco/, (last accessed
[16] International Alliance for Interoperability - IAI Tech International, http://www. on 12th. July 2010).
iai-tech.org/, (last accessed on 12th. July 2010). [45] L. Acke, Knowledge Based GUI Generators for Health-Care, Master thesis
[17] R. Verstraeten, P. Pauwels, R. De Meyer, W. Meeus, J. Van Campenhout, G. Lateur, submitted to the faculty of engineering at Ghent University8(in Dutch), http://
IFC-based calculation of the Flemish energy performance standard, in: A. Zarli, R. www.agfa.com/w3c/2006/scriptie_Lennert_Acke.pdf, (last accessed on 12th. July
Scherer (Eds.), Proceedings of the 7th European Conference on Product and 2010).
Process Modelling (ECPPM): eWork and eBusiness in Architecture, Engineering [46] European Committee for Standardization (CEN), European Standard EN 12354-3,
and Construction, Taylor & Francis Group, London, 2008, pp. 437–443. Building Acoustics — Estimation of Acoustic Performance of Buildings from the
[18] L. Khemlani, CORENET e-PlanCheck: Singapore's automated code checking system, Performance of Elements — Part 3: Airborne Sound Insulation Against Outdoor
AECBytes, http://www.aecbytes.com/buildingthefuture/2005/CORENETePlanCheck. Sound, 2000.
html 2005, (last accessed on 12th. July 2010). [47] Bureau voor normalisatie - Commissie: Geluidsleer - algemeen, Belgische norm
[19] T. Berners-Lee, J. Hendler, O. Lassila, The semantic web, Scientific American NBN S 01-400-1, Akoestische criteria voor woongebouwen - Critères acoustiques
284 (5) (2001) 35–43. pour les immeubles d'habitation (2008).