See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/346923177

Multiple inheritance for a modular BIM

Article · May 2020

CITATIONS

0READS

6

6 authors, including:

Some of the authors of this publication are also working on these related projects:

Formal methods for NLP View project

Web of Things for smart building View project

Pierre Bourreau

Nobatek/INEF4

17 PUBLICATIONS   36 CITATIONS   

SEE PROFILE

All content following this page was uploaded by Pierre Bourreau on 10 December 2020.

The user has requested enhancement of the downloaded file.

Multiple inheritance for a modular BIM

Pierre Bourreau1, Nathalie Charbel1, Jeroen Werbrouck2, Madhumitha Senthilvel3,

Pieter Pauwels4 and Jakob Beetz3

1 Nobatek/INEF4, 64600 Anglet,

{pbourreau,ncharbel}@nobatek.inef4.com 2 Ghent University,

Jeroen.Werbrouck@UGent.be

3 RWTH Aachen

{senthilvel, j.beetz}@caad.arch.rwth-aachen.de 4 Eindhoven University of Technology, p.pauwels@tue.nl

Résumé : L’IFC a été créé comme format ouvert standard pour l’interopérabilité des logiciels BIM. Son adoption est pourtant

rendue délicate par sa structuration monolithique, non-modulaire et néanmoins en constante croissance. Un des enjeux est donc de

permettre une meilleure maintenance de ce modèle tout en veillant à son évolution future, et à son adaptabilité à différents types

de projets, sur différents types d’ouvrages. Nous proposons une nouvelle approche pour la structuration de modèles IFC basée

essentiellement sur l’héritage multiple. Nous montrons comment cette architecture permet une modularisation complète d’un

modèle BIM ouvert selon trois couches principales : (i) le découpage du bâtiment en différentes vues ; (ii) la catégorisation des

éléments du bâtiment ; (iii) et la définition de propriétés pour ceux-ci. Nous comparons cette approche à différents travaux, et nous

illustrons notre propos au cas d’un IFC pour la rénovation.

Mots-clés : IFC, modularité, extensibilité, héritage multiple, patron de conception.

Abstract: The Industry Foundation Classes (IFC) was created as an open standard format to ensure interoperability between BIM

software. Yet, its monolithic, non-modular structure makes it difficult to implement, extend and use. The need for an architecture

that is easy to maintain, to extend, and to adapt to different types of projects and different types of buildings is becoming a challenge.

We propose a new architecture for IFC, mainly based on a simple principle: multiple inheritance. We show how this approach can

be used for a modular BIM, through the creation of modules in three different layers: (i) the view layer to identify elements in the

building; (ii) the product layer to categorize those elements; (iii) and the domain layer to attach properties to elements. We compare

our approach to existing and similar approaches , and we show how it can be used to build an IFC model for retrofitting.

Key-words: IFC, modularity, extensibility, multiple inheritance, design pattern.

1 Introduction

Building Information Modelling (BIM) is associated to the concept of a virtual model of a

building, that can be used during the overall building life cycle (i.e. programming, conception,

implementation, commissioning, exploitation and even demolition). A subsequent ambition of this

digital model is to contain enough information so that each actor can work on it, something

challenging considering the fragmentation of the Architecture, Engineering and Construction

(AEC) industry. Nowadays, many BIM software tools are being used in a competitive market. In

this context, interoperability issues were raised, back in the 1990s, which led to the definition of

an open exchange format by the sector: IFC (Industry Foundation Classes).

Since the initial works, IFC has evolved over different versions, making it a continuously

growing schema with properly released versions. Current discussions within buildingSMART, the

organization in charge of the IFC standard, consider extensions to describe not only buildings, but

also infrastructure, such as roads, railways or bridges. The growth of the model is not foreseen as

reaching an end. In contrast, the current latest IFC version (IFC4.2) is presented as a single schema

containing all the information: while different modules are conceptually present in the schema,

separating those seems far from trivial, with respect to the amount of inter-module dependencies

(Terkaj and Pauwels, 2017). In addition to its continuous growth, the need for modularity is also

relevant for the building equipment industry, in order to describe products in an IFC-compliant

way. For those, there is a need for classifying their products under the right IFC category, and also

to associate to their products the desired properties. In IFC, the properties associated to an element

are declared through property and quantity sets, as well as intermediary concepts enabling many-

to-many relations everywhere (IfcRelationship and subclasses), but this results in long-distance

access between a concept and its attributes. Finally, while IFC is the result of an international

standardization process, regulations, properties and nomenclatures can vary from one region to

another, and constraints from one project to another.

In this paper, a design pattern is proposed to build a modular and extensible IFC. Our proposal

is based on different principles, the main one being multiple inheritance/instantiation. Indeed, by

allowing a particular object to be an instance of different classes, we want to reflect its different

functionalities and roles in a building. In order to illustrate our proposal, we consider the use of

BIM for buildings’ retrofitting. In such contexts, some of the requirements are to model (i) the

state of the building (damage and deterioration) and (2) uncertainty: when characterizing the

existing building, tools and knowledge may be inaccurate (Volk et al, 2014). Such information

cannot be straightforwardly modelled in IFC and we show how our proposal can provide answers

to these issues. Additionally, we also discuss the compactness of the final model, as well as the

complexity for querying it.

The rest of the paper is structured as follows: in section 2, we propose a diagnosis on IFC;

section 3 contains a state of the art of initiatives that have been taken to simplify IFC; in section 4,

we detail the key concepts for our proposal of a modular IFC, and a draft model; in section 5, we

compare our proposal with the existing ones; finally, section 6 gives some conclusion and

perspective for this work.

2 IFC – a detailed monolithic format

IFC is the result of a long-standing work between BIM software vendors and practitioners, to

define a common ground, understandable across different countries, and that entails minimal sets

of concepts that are relevant to different domain experts in the construction sector (architectural,

structural, thermal, environmental,...). But agreeing on a minimal set of information seems

complex, resulting in a constantly-growing schema, as summarized in Table 1.

TABLE 1 - Evaluation of the historical growth of the IFC schema.

IFC Version Date of publication File Size (EXP) #Types #Entities

IFC 2x 2000-10 180 kB 228 370

IFC2x-ADD1 2001-10 188 kB 228 370

IFC2x2-Final 2003-05 238 kB 312 623

IFC2x2-ADD1 2004-07 188 kB 327 370

IFC2x3 2005-12 261 kB 397 653

IFC2x3-TC1 2007-07 261 kB 327 653

IFC4 2013-02 379 kB 391 766

IFC4-ADD1 2015-06 361 kB 398 768

IFC4-ADD2 2016-07 364 kB 397 776

IFC4-ADD2-TC1 2017-10 364 kB 397 776

IFC4x1 2018-06 371 kB 400 801

IFC4x2 2019-04 378 kB 407 816

The IFC schema is structured in four different layers1, each containing a number ofmodules: (i)

the resource layer contains basic elements that can be reused at each other level (e.g. currency,

occupant types, units...); (ii) the core layer is made of the most basic elements that are used to

describe a building, a product, a process or a constraint; (iii) the interoperability layer describes

generic entities (e.g. a wall, a window, an energy conversion device); and (iv) the domain layer

contains specializations of the elements in the interoperability layer for specific domains

(electrical, plumbing, HVAC, ...). While the intention of modularizing the schema was originally

there, the IFC schema has evolved into a unique EXPRESS schema, with multiple dependencies

between concepts and modules in opposite directions (cyclic graph). Working with the schema

and identifying relevant parts is therefore a complex task. Additionally, standardizing new growing

versions of the schema is also a complex task, as the organization body needs to ensure new

concepts are not already modelled.

While IFC results from a great effort to unify concepts in a fragmented industry such as the

AEC one, it still suffers from various lacks. One of them is the need to specialize some concepts

or properties for a particular project need; in particular, the properties of importance attached to

building elements can vary depending on the geographical region. In the same way, product

vendors may need or want to extend their own products with additional specific properties. While

IFC offers extension mechanisms through the definition of additional property sets for particular

objects, it offers too much freedom leading to the generation of IFC STEP files that are not aligned

with the standard, and existing properties in the original schema can thus be duplicated under new

property sets. The extension mechanism native to the EXPRESS language (IMPORT SCHEMA)

is not supported or used. Another complexity resides in providing different IFCs (or better said

different views of a building model) to the different building experts; indeed, a thermal engineer

does not need the same information as a plumber for instance. While a categorization of concepts

and properties is proposed in the domain layer, it does not deal with inter-domain information (i.e.

shared by different domain experts).

From a more technical point of view, the IFC schema, as already mentioned, is a single

EXPRESS file, and considering its growing behaviour, and its existing structure, it seems more

intuitive to have separated files for each module. Additionally, the use of Property Sets is

debatable, as it inserts intermediate steps (the property set, the property itself, and the many-to-

many relationship steps in between) between a concept and a property value. In comparison, in the

object-programming paradigm, classes tend to provide direct access to their attributes. In the IFC

schema, however, concepts also have attributes attached, and property sets seems to be used as

both an extension mechanism, and a way of sharing properties across different concepts. Finally,

the IFC schema structure is a single inheritance tree: a concept can have only a single parent

concept. Any IFC instance data also has a single IFC classification. And many relations have

redundant inverse relations pointing up and down the tree. Considering the size of the schema, the

need to share information between different concepts, as well as the need to offer different views

to different actors of the sector, these technical points, and particularly the single inheritance and

classification, can also be seen as a weaknesses, which is at the core of this article.

Modularizing IFC is key for the future and broader usability of the standard, and

buildingSMART is considering this task, as described by van Berlo (2019), for whom key design

patterns and efforts for new IFC versions should be (i) to clean up the resource layer, so as to only

insert the most widely used concepts in the layer; (ii) in a similar way, to re-structure the core layer

of IFC so that it is only made of the most common concepts; (iii) to better integrate product

definition and the efforts from the bSDD (buildingSMART Data Dictionary), through the

possibility to specialize properties of building elements in a hierarchical way, from international

to regional agreements, to project specific needs (Fig. 1). The main guideline is therefore to focus

on standardizing the minimum of information that is shared in the AEC industry and to implement

1 https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD2_TC1/HTML/link/introduction.htm

extension layers to handle specificities. This would also force software vendors to implement this

minimal set of information in a correct way, to ease the interoperability between software, which

is the initial goal of IFC, a goal not yet reached.

FIGure 1 – Proposal draft architecture of a modular IFC3 by buildingSMART International.

3 Intents for a simplified IFC

Different works to offering BIM some modularity, additional extension mechanisms, and

simplification exist. In this section, the main initiatives to this direction are explained.

3.1 IfcOWL

The ifcOWL (LDWG, 2007 and Beetz et al, 2009) is the representation of the IFC standard

(buildingSMART, 2000) in the Web Ontology Language (OWL), leading to an OWL ontology

directly converted from the EXPRESS schema. The main goal is to migrate into Semantic Web

technologies to support data interoperability, flexibility and extensibility within information

system applications in the construction industry. In this direction, there have been several

approaches for the EXPRESS-to-OWL conversion, such as (Agostinho et al., 2007), (Barbau et

al., 2012), (Schevers & Drogemuller, 2005) (Terkaj et al., 2012). Among all approaches, (Pauwels

& Terkaj, 2016) propose a recommendable and usable ifcOWL ontology. It is semantically closer

to the original IFC Schema standard in comparison to alternative approaches. However, since the

ontology encapsulates being a direct mapping of the IFC schema, it does not solve the main

problems. IfcOWL, just like its EXPRESS and XSD equivalents, is monolithic, non-modular, and

supporting mainly a single inheritance and classification tree by the presence of the many

constraints, and the interconnecting relations and inverses.

3.2 SimpleBIM

In order to overcome the complexity of building models represented in ifcOWL graphs,

Pauwels & Roxin (2016) propose an approach towards simplification of such graphs using

semantic web technologies including query and rule languages (e.g., SPARQL and SWRL). The

3 Source : https://blog.buildingsmart.org/blog/the-curious-case-of-the-mvd

proposed simplification process was called SimpleBIM4 and consists of 4 main parts: (i) removing

geometric and representation data as the RDF graph data model is unfit for storing such data (the

required linked list design pattern does not fit efficiently), (ii) unwrapping all data types, so that

class instances are directly related to data properties, (iii) rewriting properties and removing a

considerable number of intermediate steps between class instances and their property values (e.g.:

xsd:string instead of ifc:IfcLabel ifc:hasValue xsd:string), and (iv) replacing relational instances

(i.e., instances of ‘IfcRelationship’) with direct object properties between class instances (many-

to-many relations are natively supported in the RDF data model, without requiring intermediate

concepts). The last two rules are inspired by the ifcWoD simplification approach (Mendes et al.,

2015). This initiative does not work as a refactoring of the schema, but as a refactoring of the

instances (i.e. a specific building model) and the main goal seems to prove how such rewritings

can lead to more efficient data handling and querying, without looking at the modularity of the

schema or instances.

3.3 Linked Building Data (LBD)

The work on SimpleBIM was one of the inspirations behind the set up of the Linked Building

Data (LBD) initiative in the World Wide Web Consortium (W3C)5. Where the SimpleBIM and

IfcWoD approaches lacked ontologies, a main target was to create OWL ontologies that allow a

modular and simplified (RDF native) representation of building data. This has led to the following

ontologies based on community work.

3.3.1 BOT

The development of distributed ontologies has several advantages over a one-size fits all, such

as interoperability and simple reuse. In this direction, the Building Topology Ontology (BOT)

(Rasmussen et al., 2017) is introduced as a modular ontology covering core concepts of the

building and three methods for extending it with domain-specific ontologies (such as ontologies

modelling information related to geographical location, sensor data, domotics, and construction

data). This reduces redundancies caused by overlapping data found in these ontologies, which is

currently violating the W3C best practice rules. Linking BOT to other ontologies can be done in

several ways: (i) extending the core classes with subclasses of more specialized ontologies, (ii)

defining equivalent classes, and (iii) establishing typed links between instances (Schneider et al,

2018). Based on these linking methods, efforts have been done to align BOT with BRICK (Balaji

et al., 2016), ifcOWL (Pauwels & Terkaj, 2016), DERIRoom (Cyganiak, 2012) and DogOnt

(Bonino & Corno, 2008) ontologies. Along the same lines, we intend to reuse BOT ontology and

link it to other modular ontologies describing elements and domains involved in a renovation

scenario such as building elements, HVAC elements, plumbing elements, etc. Based on

requirements mentioned in section 1, we believe that is better done using the third linking method

(i.e., on the instances level).

3.5 PRODUCT

3.3.2 BPO

The Building Product Ontology (BPO) (Wagner & Rüppel, 2019) is used to describe

individually manufactured building products as the assembly of their constituents, without setting

a maximum breakdown level. In this way, individual components from different manufacturers

can be assembled into one building product which can be useful to describe complex systems such

as solar panel integrated in a façade. The ontology consists of (i) classes (‘Component’, ‘Product’,

4 NOT related to the simpleBIM application (http://www.datacubist.com/)! 5 http://w3.org/community/lbd/

‘Element’, and ‘Assembly’) and relations (‘Consists of’ and ‘Is part of’) modelling assembly

structures, (ii) relations between components (‘Has outgoing connection’, ‘Connects input of’ and

‘Is connected with’), and (iii) classes and relations describing attributes attached to the product

description. BPO is aligned to well-known upper-level ontologies, such as schema.org6

and SEAS7, and brings product decomposition functionalities in a modular fashion in combination

with the BOT ontology.

3.3.3 OPM

The Ontology for Property Management (OPM) (Rasmussen et al., 2018) is an ontology for

describing properties that are subject to changes as the building design evolves over time, or to

associate metadata to them (provenance, reliability…). The relevance of the latter in renovation

scenarios was already discussed. Three levels of data modelling extensions are presented and

discussed, for different scenarios. OPM allows keeping track of deleted properties so they can be

restored if needed, and is also being considered at the CEN TC442 (BIM standardization in

Europe) as a possible future standard to handle additional properties in BIM through Linked Data.

3.4 Building Element and Distribution Element ontologies

Pauwels proposes two ontologies as extraction of the “BuildingElement” and

“DistributionElement” sub-trees in the IFC schema: the Building Element8 and Distribution

Element9 ontologies respectively, both regarded as taxonomies: attributes and relations are kept

out of these ontologies as user requirements may differ from one domain to another. The intention

is to simply allow the categorization of specific products in an IFC compliant way. The. concepts

of the 2 ontologies are linked to classes in ifcOWL and the buildingSMART Data Dictionary

(bSDD) (seeAlso links) for documentation purposes. However, changes are made w.r.t. the IFC

schema, such as “Enumeration Types” in the IFC specifications (or predefined type instances in

the ifcOWL) are directly included as subclasses (e.g., CO2Sensor). Moreover, “Undefined Type”

or “User-defined Type” mentions in the IFC specifications are excluded. OWL can be used by

users to define their own types if needed, and anything that is not defined in OWL, is unknown by

default in the Open World Assumption of OWL, so there is no need for ‘User-defined’ and

‘Undefined’ references, The use of such ontologies reflects a maximum degree of modularity and

flexibility while keeping a close relation with the standardization effort resulting in the IFC

standard. Many of the Object Type Libraries (OTLs) used in construction practice could easily

take the same approach.

3.5 DOT

The Damage Ontology Topology (DOT) (Hamdan et al, 2019) allows the definition of damage

representations and their relations with other damages and affected construction components. It

applies to any construction type including buildings and bridges. It comprises 3 main entities:

dot:DamageArea which can be made of the aggregation of several elementary damage elements,

i.e., dot:DamageElement and can be regrouped in damage patterns defined as dot:DamagePattern.

A cause can be given to certain damage by using the dot:hasCausation relation. The range of this

relation is intentionally left open for interpretation. Current extensions are being developed in

context of the German WiSiB project, among which are the Uncertain Damage Ontology (UDO)

(Hamdan, 2019) and the Concrete Damage Ontology (CDO) (Hamdan & Bonduel, 2019).

6 https://schema.org/ 7 https://ci.mines-stetienne.fr/seas/ 8 https://pi.pauwel.be/voc/buildingelement/ 9 https://pi.pauwel.be/voc/distributionelement/

3.6 Recap

Table 2 summarizes the schema of ontologies discussed above in terms of metrics (i.e., number

of classes, relations or object properties, attributes or data properties, and individuals) when

available, their scope and examples of alignment that have been done so far to link them together.

The lack of modularity and complexity of the IFC schema appears clearly through the number of

attributes and relations. Even though the BuildingElement and DistributionElement ontologies

have a considerable number of classes, they lack any relation, thus removing any kind of

complexity besides the classification tree structure (taxonomy). In the context of the BIM4Ren

project and more generally in order to provide a modular IFC version, it seems that smaller

modules, dedicated to modelling specific building domains should be designed or reused from the

existing ones. The next key step would then be on linking the different modules all together to

deliver a complete building model to end-users. Finally, one would remark that geometry is not

addressed in the modules below (apart from ifcOWL). That is mainly due to the same reason,

namely that the RDF data model is an inefficient storage mechanisms for linked lists, and therefore

also for 3D geometry. Modelling, handling and storing geometry information is a topic in itself,

that requires dedicated efforts (e.g. Wagner et al, 2019; Bonduel et al, 2019).

TABLE 2 - Recap on BIM-based ontologies and related modular ontologies.

Ontology Metrics Scope Alignment ifcOWL (Pauwels &

Terkaj, 2016) 1230 classes

1578 relations 5 attributes

1627 Individuals

IFC Schema BOT Building Element

Distribution Element

SimpleBIM (Pauwels

& Roxin, 2016) Not available Simplified IFC Schema

(without geometry) Not available

BOT (Rasmussen et al.,

2017)

7 classes 14 relations 1 attribute

0 Individual

Building topology BRICK DERIRoom

DogOnt ifcOWL

OPM (Rasmussen et al.,

2018)

7 classes 5 relations 2 attributes 0 individual

Properties and their states BOT SEAS

BPO (Wagner et al., 2019)

14 classes 19 relations 5 attributes 0 individual

Manufactured building

products or instances of those

product

Schema.org SEAS

Building Element

(Pauwels, 2018) 182 classes 0 relation 0 attribute

0 individual

Subtree of IfcBuildingElement

in the IFC Schema PRODUCT

bSDD ifcOWL

Distribution Element

(Pauwels, 2018) 480 classes 0 relation 0 attribute

0 individual

Subtree of

IfcDistributionElement in the

IFC Schema

PRODUCT bSDD

ifcOWL

DOT (Hamdan & Bonduel,

2019b)

12 classes 13 relations 2 attributes 0 individual

Damages related to a

construction type (Buildings,

bridges)

Concrete Damage Ontology Uncertain Damage Ontology

4 Modular IFC - a design pattern proposal

Our proposal for a modular and extensible IFC is based on a four layer structure (Fig. 2): (i) the

resource layer, as for IFC, is still the place to share information that can be used as properties or

quantities in the model, but all properties need to be encapsulated in a concept containing ‘Value’

and ‘Unit’ attributes at least; (ii) the view layer plays the role of the core layer; it is made of

different models, used for different views on the building, and relation between building

components: the most fundamental and mandatory module is a model to locate elements in the

building (similar to BOT); other models can be part of this layer to describe elements in a MEP

system for instance; (iii) the product layer, similar to the layer in the architecture proposed by van

Berlo (2019), and basically a minimal set of informed hierarchies of products classified by

categories; (iv) a set of models made of abstract concepts according to different domains, such as

‘Electricity’, ‘Carbon Impact’, ‘Thermal’. Our approach is then based on full independence

between all these models: no hard-coded dependence should exist between them; instead linking

the different modules is performed when instantiating objects, through multiple binding (similar

to multiple inheritance and classification in the object-oriented paradigm), to reflect the multiple

properties and roles of elements of a building.

FIGURE 2 – Schema for a modular architecture IFC based on multiple inheritance.

4.1 Description of the architecture

First of all, the resource layer is a refactoring of the identically named layer in the IFC schema;

indeed, for the sake of extensibility, we consider that a value needs to be described under an

encapsulated data type, made of at least two attributes: ‘Value’ and ‘Unit’. This approach is really

similar to level 2 modelling of properties in OPM; and different from the SimpleBIM approach.

This could be extended for the need of any project. For instance, in the case of using BIM in a

renovation project, one of the key issues is to deal with data uncertainty, which can be related to

non-available materials (for instance, the layer composition of a wall, dimensions of these layers

and type of materials used) or even about the tools used for scanning the geometry of the building,

or the approximation made when modelling it. A recommendation with the proposed design

pattern is to constantly use the same data type encapsulation for all the data in the project for

coherence purpose, and in order to avoid to deal with too many specific cases when, for instance,

parsing the model. In the case of a renovation project, we would recommend using the

‘UncertainDatatype’ in Figure 3 as the base type for all subsequent data used; this could involve

specifying a default value of 1 to the uncertainty indicator. Additionally, we recommend the use

of the QUDT nomenclature, by (i) removing all the concepts unnecessary to the building context

and (ii) extend it to include missing concepts required. This is currently being worked in the BIM

standardization group within the European Committee for Standardization (CEN).

FIGURE 3 – Example of multiple inheritance: extending datatypes.

In the view layer, we propose to use or develop different ontologies that are used to

contextualize elements according to different needs or usages. A first model called the

‘Localization View’, similar to the spatial-related elements in the ‘IfcProductExtension’ of the

Core Layer of the IFC Schema, is used to describe the spatial structure of the buildings, and to

enable the localization of additional elements. This model can be extracted from the IFC Schema

or the BOT ontology, both of them respecting the hierarchical structure of ‘Sites’, ‘Buildings’,

‘Storeys’ and ‘Spaces’. Other models should be developed according to the different usages. For

instance, a MEP (Mechanical, Electrical and Plumbing) view should be developed to identify

products’ roles in the distribution of gas, electricity or water in a building. Such a model can be

built based on the generic concepts already present in the ‘IfcSharedBuildingElements’ module of

the IFC schema. Regarding the design pattern to apply, and in order to preserve independence

between the different modules, we propose to have an abstract class in each view model, that can

be instantiated by external objects; this is the pattern applied in the BOT ontology through the

‘bot:Element’ class, to attach a localization to an external product.

The Product layer is made of categories of generic products, with a minimal set of attributes

attached to them. The goal of this layer, just as in Figure 1, is to have a common standard list of

products that must be re-used and further specialized by product manufacturers. Again, the

standardization efforts can be re-used to define the content of this layer, in the fashion of the

taxonomies in section 3.7, or by extending those taxonomies with the attributes associated to the

different concepts of IFC. As an example, Figure 4 illustrates how an ‘IfcWindow’ would be

translated from the IFC Schema into a UML class, by mapping attributes in the schema to attributes

in a class. Nevertheless, and similarly to what is done in SimpleBIM, we simplify the usage of

Enum Types, so that values in ‘IfcWindowTypeEnum’ should be mapped to sub-classes of

‘IfcWindow’, similarly to the simpleBIM approach. Similarly,

‘IfcWindowTypePartitioningEnum’ should be mapped to the ‘IfcWindowPartitioning’ class with

specific sub-classes or instances (and the ‘UserDefinedPartitioningType’ would be implemented

by defining a new instance or sub-class of the WindowPartitioning class).

FIGURE 4 – Mapping of an IFC concept and its attributes into a UML class diagram, through the

example of an IfcWindow.

The final top layer is made of concepts related to the domain in which the building products

reside (Thermal, Electric, Acoustic, Environmental). This particularly relates to the PSets in IFC.

Let us consider the definition of an IfcBoiler in the IFC Schema as an example; different PSets are

attached to it: (i) PSet_BoilerTypeCommon, including properties such as the storage capacity,

nominal energy consumption; (ii) PSet_SoundGeneration, including a table of frequencies

generated; (iii) PSet_ElectricalDeviceCommon, including properties related to the electrical

consumption of the device; and (iv) PSet_EnvironmentalImpactIndicators and

PSet_EnvironmentalImpactValues, associated to the waste generated, renewable energy

consumption, or other factors considered in life cycle analysis10. Those PSets can be reformulated

as aspects of the boiler, which can either be seen as a thermal system (i) an acoustic generator (ii),

an electrical device (iii), or a product having an environmental impact (iv). Such reformulation

leads to defining different domains (thermal, acoustic, electric and environmental) and a particular

boiler becomes an instance of a specific class in each of these categories (see Figure 5).

10 Some other PSets are used, not considered for the sake of concision.

FIGURE 5 – Multiple instantiation to model an electric boiler.

4.2 A combined data model

The proposed approach is based on a full independence between the different modules: there

is no hard link (i.e. links between the different classes in a module - in a UML or Object-Oriented

paradigm; links between concepts in the TBox in the web semantic paradigm) between modules

of different layers, or modules of the same layer, apart from the resource layer that should be used

for any data type associated to an attribute. Instead, linking the different classes is achieved when

instantiating a specific object: as an example, we saw how a specific boiler can instantiate different

classes to describe different aspects; this boiler is also an instance of the ‘Boiler’ class in the

Product layer; and an instance of ‘BuildingElement’ in the Localization View, and of ‘System

Element’ in the MEP View.

It is crucially important to stress that this approach could a priori allow incoherent instantiation

of objects (for instance a window as a gas consumer), and the semantic coherence of the model is

the entire responsibility of the specific building or product designers and engineers (human in the

loop). In order to solve this issue, one could use formal ontologies that describe specific inter-

modules linking, so that the coherence of the model remains easily maintainable; for instance, a

‘BoilerAspects’ ontology would define the restrictions between the Boiler class in the Product

layer, and the classes of the domain layer. One would note that a similar freedom exists in IFC as

any kind of PSet can be attached to a class.

While the design pattern we suggest is focused on modularity, it is also extensible in various

ways. First of all, new modules can be added if required for a specific project; this can be the case

for specific domain properties. Such new modules can be independent from the existing ones, or

can extend the latter. For instance, in the BIM4Ren project, we consider the BOT ontology as the

basis for the localization view, but we extend it so as to integrate concepts from Omniclass about

the typology of the different spaces in a residence, or of different kinds of residential buildings

(see Figure 6). A similar approach may be relevant to deal with refinements of properties as

described in van Berlo (2019), from international standards to project specific: the set of standard

properties attached to a product A may be encapsulated under n concepts 𝐴1, ..., 𝐴𝑛 in the domain

layer; those might be extended into concepts 𝐴1′ , ..., 𝐴𝑛

′ to integrate local or project specific

properties. Such an approach would again purely rely on the inheritance mechanism, and can then

be replicated to different formalisms. An additional question related to the extension of the model

is related to composed product definition. For instance, an integrated solar panel in a façade is

made of different products. The use and integration of BPO or a similar approach should be further

studied but it intuitively seems that it can be integrated into the proposed design pattern: a given

product in the product layer can be instantiated as either an assembly (i.e. a composed product) or

an element (i.e. a part of the composed product).

FIGURE 6 – Graph representation for the BOT extension to model buildings topologies and functional

spatial structures.

This modular approach can then be further explored for the proposal of a new standard IFC

architecture, but the question of the minimal set of concepts and properties that could be used as a

standard remains. The current IFC version should obviously be a starting point, although many of

its concepts are arguably suited to be included in the standard. For instance, a monitoring project

could be run with information restricted to the localization view, product layer, and with additional

information on sensors, meters and actuators (i.e. the IFC4 Control Domain) (see for instance

Chbeir et al. 2018). Through such a modular approach, it should be possible to define different

standard IFCs for different uses at different steps of the building life cycle, with a shared core

structure.

5 Comparison

In this section, we compare our approach with some of the other initiatives presented in Section

3, and try to compare our approach with current IFC models.

5.1 Modularity and extensibility

First of all, and as already commented in previous sections of the current article, our approach

relies on and can integrate different works provided by the community: BOT can be taken as the

core localization view; the building element and distribution element taxonomies (fully extracted

from the IFC model) can form the kernel of concepts for the product layer; and the use of the

Building Product ontology was discussed to describe complex products. Our approach is therefore

not directly comparable with those, as they address specific parts of a building model, but is rather

a proposal for integrating those, and building new ones.

The simpleBIM initiative is closer to what we propose, although no straightforward comparison

is possible, because simpleBIM results from a fully automatic refactoring (without ontology) of

ifcOWL models, while our approach is not. Moreover, the goal of simpleBIM seems to be a

simplification of ifcOWL instantiations for a better response time on queries, while our approach

focuses on the modularization of the IFC model. Nevertheless, we can already identify some

similarities and differences between our approach and the simpleBIM approach. First of all, data

types are unwrapped in simpleBIM while we propose an opposite approach, through data

encapsulation. The simpleBIM approach will shorten the verbosity of the model, and shorten the

path between a concept and its numerical attributes; our approach is focused on enabling model

extension, even at the data type level. We don’t go as far as IFC, however, and do not redefine

basic data types such as strings into IfcText, IfcLabel, and similar (also for other data types).

Secondly, PSets are removed in both approaches: in simpleBIM, properties in PSets are directly

rewritten as attributes while we propose to have PSets refactored as specific classes. At the instance

level, both approaches seem to offer similar results: an instance I of a concept C would have a

direct relation to its properties, shortening the path to data access and therefore simplifying and

speeding up querying time response on a specific building model; in our proposal, we show how

this can be enabled through multiple inheritance and modularization mechanisms at the model

level, while simpleBIM proposes a refactoring at the instance level. Other simplifications are

proposed in simpleBIM: ‘IfcRelationship’ classes are replaced with attributes/relations. This is not

tackled in the current proposition as it needs to be addressed within each module. Another key

simplification is the removal of the geometric information which results in a dramatic reduction

of the size of the model. The question of the modelling of the geometry remains as it cannot be

simply removed, yet we refer to the approach suggested in the W3C LBD CG as the most viable

alternative. A ‘geometric’ module could be designed in our approach, associating attributes to

accurately define the shape of the building and its components, and the integration of a

‘GeometricElement’ that would be instantiated by each element geometrically described (Wagner,

2019; Bonduel, 2019).

TABLE 3 - Description of the BIM4Ren data model

Layer Module Description Comment Resource Layer property.ttl 243 classes

65 relations

42 attributes

1024 individuals

Extension of the QUDT ontology, to model

numerical quantities and units. Additional use of

‘Uncertainty’.

actor.ttl 7 classes

2 relations

1 attribute

6 individuals

Description of the different individuals that can be

associated to a renovation project (Building

manager, owner, occupant...)

View Layer buildings.ttl 32 classes

19 relations

19 attributes

6 individuals

Extension of the BOT ontology to integrate

Omniclass specific concepts such as room usage

(‘Kitchen’, ‘Sleeping Room’...), buildings

categories (‘Dormitory’, ‘Single Family house’...)

to describe residential buildings systems.ttl 11 classes

4 relations

0 attributes

12 individuals

Generic description of systems as networks, made

of control, storage, terminal and transport elements.

To be used to describe HVAC or Plumbing

structures for instance. dot.ttl 13 classes

13 relations

3 attributes

1 individual

The damage topology ontology.

intervention.ttl 6 classes

4 relations

2 attributes

0 individuals

Attach historical intervention listing to elements

Product Layer

buildingElement.ttl 182 classes 0 relation 0 attribute

0 individual

Subtree of IfcBuildingElement in the IFC Schema -

extracted from (Pauwels, 2018)

distributionElement.ttl 480 classes 0 relation 0 attribute

0 individual

Subtree of IfcDistributionElement in the IFC

Schema - extracted from (Pauwels, 2018)

Domain Layer

thermal.ttl 2 classes

8 relations

0 attributes

0 individuals

Categorization of elements as ‘HeatProducer’ or

‘HeatTransferElements’, and related thermal

properties

electrical.ttl 2 classes

2 relations

0 attributes

0 individuals

Categorization of elements as ‘ElectricalProducer’

or ‘ElectricalConsumer’, and power produced in

entry or output.

Within the BIM4Ren project, we implemented a first draft of the above proposed data model,

based on the principles exposed along this article. The data model is presented under a semantic

web compliant format, made of the modules described in Table 3. First of all, one can remark that,

apart from the property.ttl ontology, all the modules in the model are concise and simple, restricted

to a limited number of classes and relations , which makes them individually more maintainable;

indeed, this information is to be compared with the complexity of the IFC schema (see Table 1).

• The case of the property.ttl differs from this analysis as it is built upon the QUDT ontology

(Hodgson, 2014), which is a generic data model that contains information that can be used

for a variety of domains, not restricted to the AEC domain. In the future, this module should

be replaced by a set of modules, so as to categorize the units and data kinds according to

different domains (such as ‘Spatial’ for distance, surface and volume, ‘Currency’,

‘Thermodynamics’....).

• Similarly, the buildingElement.ttl and distributionElement.ttl modules could be split into

more concise taxonomies; for instance, the distributionElement.ttl has

‘DistributionElement’ as a root, and all its children classes in the IFC schema, including

sensors, actuators, or solar panels and boiler. For the sake of modularity, one can split this

taxonomy into two different modules: one for ‘ControlElement’ (containing sensors,

actuators...) and one for ‘FlowElement’ (containing boilers, solar panels...).

• The buildings.ttl module is also slightly bigger than the other ones, as it is an extension of

the BOT ontology.

• Finally, the modules used in the domain layer are in a rough simplified version, and should

be extended in the future, to ensure they can cover all the needs for the description of

thermal systems within the BIM4Ren project. Indeed, the thermal.ttl module ambition is

not to become an internationally agreed model for thermal building elements, but rather to

ensure interoperability between the different tools to be developed and connected in the

BIM4Ren project. Additional modules will be developed and added to the presented

structure, which is only considered as an example for implementing the concepts described

in the present work.

5.2 Embedded content compared to IFC

The set of concepts covered by the proposed data model and the IFC schema are not

comparable: IFC does not cover damages or uncertainty, as already mentioned, while the

BIM4Ren model does not contain information on acoustic or structural information, for instance.

In order to compare the current IFC schema structure with the design pattern we propose, a

methodical translation of IFC into the presented approach should be achieved; while transforming

an IFC (or ifcOwl) instance into a simpleBIM one can be done automatically, our approach would

require a semi-automatic translation, and subjective choices that would further need to be

confirmed by standardization bodies regarding module categories, or content. For instance,

properties in the property set ‘PSet_BoilerTypeCommon’11 need to be dispatched in different

modules of the domain layer. But such work would also lead to properly identify the inter-modules

links and to ensure they can still be modelled according to our principles.

5.3 Query efficiency

11 https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD2_TC1/HTML/link/ifcboiler.htm

Finally, the architecture we propose also ensures some additional efficiency for some data

queries, in particular, for those specific to certain domains. As an example, let us consider IFC and

the BIM4Ren data model, and a query to retrieve the U-values associated to all windows of a

building. We consider both data models expressed in a semantic web-compliant format, so as to

formalize the query in a comparable way, in the SPARQL syntax. The two queries are presented

in Figure 6. It appears clearly that the query in the modular approach is less verbose, and requires

less sub-queries and graph traversals than in the IFC schema. This should result in a more efficient

time response, and an easier implementation of data access implementation for software vendors.

SELECT ?window ?u_value WHERE { ?window a ifc:IfcWindow. ?rel_def_prop

ifc:relatedObjects ?window; a ifc:IfcRelDefinesByProperties;

ifc:relatingPropertyDefinition

?prop_set. ?prop_set rdf:type

ifc:IfcPropertySet; ifc:hasProperties ?prop;

a ifc:IfcPropertySingleValue; ifc:name "Thermal Transmittance"; ifc:nominalValue ?u_value.

?u_value a

ifc:IfcThermalTransmittanceMeasure. }

SELECT ?window ?u_value WHERE { ?window a ifc:IfcWindow;

a thermal:HeatTransferElement;

thermal:thermalTransmittance

?u_qudt.

?u_qudt qudt:value ?u_value. }

FIGURE 6 – Query comparisons in ifcOWL and the BIM4Ren data model – SPARQL queries to obtain

all windows and their U-values

6 Conclusion and future works

IFC is the result of a collaborative effort from major representatives of the building value chain,

from software vendors to architects, engineers, housing companies and much more. The current

definition and open status of the IFC schema is of high value for the sector, but its constant growth,

and the difficulty to produce a world-wide adopted standard in a domain in which regulations and

conditions may dramatically vary, are appealing for more modularity. In this paper, we propose a

methodology to build up a modular IFC, based on a simple pattern: the use of multiple inheritance

(or multiple instantiations). We show that a fully modular IFC can be achieved through this

approach, meaning that every module is fully independent, does not require other modules.

The counterpart of this approach is that the coherence of a building model is delegated to the

person or process in charge of the instantiated schema. Our approach is compared to some

initiatives that can either be integrated into our approach (i.e. data model dedicated to the

modelling of part of the information contained in the IFC schema), or can be similar in some

respect (i.e. simpleBIM for efficient queries). In order to consolidate the presented approach, a

methodical transformation of the IFC schema should be done, so as to ensure that all standardized

information can still be modelled through this approach.

Finally, the modelling of the geometric data was intentionally not included in our study, which

essentially focuses on the semantic information. Geometric information forms a big part of the

data within any IFC building models, and dealing with it efficiently potentially require specific

technical stacks, like binary data storage or GeoSPARQL (O’Donovan et al, 2019). While different

technologies will be tested in the BIM4Ren project, the next IFC versions could focus on providing

a technology-independent way of linking the semantic model with a geometry-dedicated

modelling and storage solution.

Acknowledgements

The BIM4Ren project has received funding from the European Union’s Horizon H2020

research and innovation programme under grant agreement No 820773.

References

Agostinho et al. (2007). EXPRESS to OWL morphism: making possible to enrich ISO10303 Modules. Dans Complex

Systems Concurrent Engineering (pp. 391-402). Springer. Balaji et al. (2016). Brick: Towards a unified metadata schema for buildings. Proceedings of the 3rd ACM

International Conference on Systems for Energy-Efficient Built Environments, 41--50. Barbau et al. (2012). OntoSTEP: Enriching product model data using ontologies. Computer-Aided Design, 44, 575-

590.

Beetz et al. (2009). A case of transforming EXPRESS schemas into ontologies. Artificial Intelligence for Engineering

Designe, Analysis and Manufacturing 23 (1) 89–101. Bonduel, M., Wagner, A., Pauwels, P., Vergauwen, M., & Klein, R. (2019) Including widespread geometry formats

in semantic graphs using RDF literals. Proceedings of the 2019 European Conference for Computing in

Construction (EC3). p.341-350

Bonino, D., & Corno, F. (2008). Dogont-ontology modeling for intelligent domotic environments. (Springer, Éd.)

International Semantic Web Conference, 790--803. buildingSMART (2000). Industry Foundation Classes (IFC) Releases. Available at

https://technical.buildingsmart.org/standards/ifc/ifc-schema-specifications/

Chbeir et al (2018). OntoH2G: A Semantic Model to Represent Building Infrastructure and Occupant Interactions.

Dans International Conference on Sustainability in Energy and Buildings 2018 (Springer Eds.), 148--158. Cyganiak, R. (2012). Buildings and rooms vocabulary. Available at http://vocab.deri.ie/rooms

Hamdan, A.-H. (2019). Uncertain Damage Ontology. Available at https://wisib.de/ontologie/damage/udo/ Hamdan, A.-H., & Bonduel, M. (2019a). Concrete Damage Ontology. Available at

https://wisib.de/ontologie/damage/cdo/ Hamdan et al. (2019). An ontological model for the representation of damage to constructions. Proceedings of the 7th

Linked Data in Architecture and Engineering for Construction Workshop. Available at

https://alhakam.github.io/dot/ Hogson et al (2014). QUDT-quantities, units, dimensions and data types ontologies, Available at http://qudt. org

March, 2014

LBD (2019), PRODUCT: Building Product Ontology. Available at https://github.com/w3c-lbd-cg/product Mendes et al. (2015). IfcWoD, semantically adapting IFC model relations into OWL properties. arXiv preprint

arXiv:1511.03897. Pauwels, P. (2018a). Building Element Ontology. Available at https://pi.pauwel.be/voc/buildingelement/index-

en.html Pauwels, P. (2018b). Distrbution Element ontology. Available at https://pi.pauwel.be/voc/distributionelement/index-

en.html Pauwels, P., & Roxin, A. (2016). SimpleBIM: From full ifcOWL graphs to simplified building graphs. Pauwels, P., & Terkaj, W. (2016). EXPRESS to OWL for construction industry: Towards a recommendable and usable

ifcOWL ontology. Automation in Construction, 63, 100-133. O’Donovan et al. (2019). A method for converting IFC geometric data into GeoSPARQL. Proceedings of the 7th

Linked Data in Architecture and Engineering for Construction Workshop. Rasmussen et al. (2017). Proposing a central AEC ontology that allows for domain specific extensions. Joint

Conference on Computing in Construction, 1, pp. 237-244. Available at https://w3c-lbd-cg.github.io/bot/

Rasmussen et al. (2018). OPM: An ontology for describing properties that evolve over time. Proceedings of the 6th

workshop on Linked data in Architecture and Construction Workshop, pp. 24-33. Available at https://w3c-

lbd-cg.github.io/opm/

Schevers, H., & Drogemuller, R. (2005). Converting the industry foundation classes to the web ontology language.

Semantics, Knowledge and Grid, 2005. SKG'05. First International Conference on, (pp. 73-73). Schneider, G. F., Rasmussen, M. H., Bonsma, P., Oraskari J. & Pauwels P. (2018) Linked building data for modular

building information modelling of a smart home. Proceedings of the 12th European Conference on Product

and Process Modelling (ECPPM) p.407-414

Terkaj et al. (2012). Virtual factory data model. Proceedings of the Workshop on Ontology and Semantic Web for

Manufacturing, Graz, Austria, (pp. 29-43).

Terkaj, W., & Pauwels, P. (2017). A method to generate a modular ifcOWL ontology. Proceedings of the Joint

Ontology Workshops 2017 Episode 3: The Tyrolean Autumn of Ontology (Vol. 2050). Presented at the 8th

International Workshop on Formal Ontologies meet Industry. van Berlo (2019) The curious case of the MVD. Available at https://blog.buildingsmart.org/blog/the-curious-case-of-

the-mvd Volk, R., Stengel, J., & Schultmann F. (2014) Building Information Modeling (BIM) for existing buildings —

Literature review and future needs. Automation in Construction, 38, 109-127.

Wagner, A. & Rüppel, U (2019). BPO: The Building Product Ontology for Assembled Products. Proceedings of the

7th Linked Data in Architecture and Construction workshop. Available at https://www.projekt-

scope.de/ontologies/bpo/

Wagner, A., Bonduel, M., Pauwels, P., & Rüppel, U. (2019) Relating geometry descriptions to its derivatives on the

web. Proceedings of the 2019 European Conference for Computing in Construction (EC3). p.304-313.

View publication statsView publication stats