=Paper=
{{Paper
|id=Vol-3081/11paper
|storemode=property
|title=Dynamic BIM model conversion as inference-based ontology alignment
|pdfUrl=https://ceur-ws.org/Vol-3081/11paper.pdf
|volume=Vol-3081
|authors=Pierre Bourreau,Jyrki Oraskari
|dblpUrl=https://dblp.org/rec/conf/ldac/BourreauO21
}}
==Dynamic BIM model conversion as inference-based ontology alignment==
https://ceur-ws.org/Vol-3081/11paper.pdf
Proceedings of the 9th Linked Data in Architecture and Construction Workshop - LDAC2021
Dynamic BIM model conversion as
inference-based ontology alignment?
Pierre Bourreau1 and Jyrki Oraskari2
1
Nobatek/INEF4, 9 rue Jean-Paul Alaux, 33000 Bordeaux, France
pbourreau@nobatek.inef4.com
2
CAAD RWTH Aachen, Templergraben 55, 52062 Aachen, Germany
Jyrki.Oraskari@dc.rwth-aachen.de
Abstract. The AEC sector is known to be highly fragmented, differ-
ent experts requiring different information. Current BIM collaborative
practices can be described as static as they are based on file exchange,
mainly using IFC files. Instead, in an ideal level 3 BIM platform, dif-
ferent stakeholders could work together on a single centralized building
model, using different domain-specific vocabularies, and updating the
model synchronously. We propose an approach based on semantic rule
reasoning to dynamically convert information in different vocabularies.
While existing alignments only cover class conversions, we develop infer-
ence rules that handle conversion of relations in a dynamic and transpar-
ent way, being executed by a reasoner. The approach is implemented and
tested on converting models from ifcOWL to BIM4Ren, a BOT-based on-
tology. The scalability of the implementation is discussed as well as its
limitation.
Keywords: BIM, alignment, logic programming, interoperability
1 Introduction
The fragmentation of the AEC industry is a well-known issue in construction
projects: different AEC (Architecture and Engineering in Construction) actors
use different vocabularies and information to describe the same building. BIM as
a collaborative process supported by digital tool and models intends to ease data
exchange between project stakeholders. To do so, the industry delivered IFC or
the ISO 10303-21 IFC-SPF file format, which aims at being a standard exchange
model to which all software vendors can comply, at the cost of a translation
mechanism. We call such a data exchange ’static’ as each transferred model is
a picture of the model at some instant; indeed, if multiple actors are allowed to
update it, some file merging functionalities become necessary. In an ideal BIM
level 3 environment, as mentioned in the literature, all actors work on a single
and centralized model, and updates are handled automatically so that each actor
?
The BIM4Ren project has received funding from the European Union’s Horizon
H2020 research and innovation programme under grant agreement No 820773
Copyright 2021 for this paper by its authors. Use permitted under Creative
Commons License Attribution 4.0 International (CC BY 4.0)
127
Proceedings of the 9th Linked Data in Architecture and Construction Workshop - LDAC2021
works on the latest model version. In the present article we investigate a linked
data-based approach that reduces model conversion to an ontology mapping
problem, for a model stored in a single triple store. With such approach, different
users may use different vocabularies to work on the very same centralized model.
It could be used for ’horizontal’ (i.e. from one model to another, like IFC2x3 to
gbXML) or ’vertical’ conversion (i.e. from one model version to another one, like
IFC2x3 to IFC4)
Ontology mapping can be seen as a task where concepts (i.e. entities and
relations) of different vocabularies are mapped based on their semantic corre-
spondence and organisation, keeping the intended interpretations [9,10]. In the
Linked Building Data domain, a few ontology alignments exist [16]. While many
ontology mapping techniques exist, the article focuses on logic-based mapping
by elaborating inference rules that are interpreted by a reasoner that can dy-
namically generate matching relations.
The article is structured as follows: section 2 introduces the problem of col-
laboration and model conversion in the BIM community, and ontology mapping.
We also introduce ifcOWL and the BIM4Ren ontology as the two ontologies used
to test our approach. Section 3 presents different ontology mapping strategies
used to align the two ontologies above. In section 4, we introduce the implemen-
tation, test it, discuss issues and solutions proposed, and compare the approach
with a programmatic one.
2 BIM collaboration and ontology mapping
2.1 BIM collaboration
BIM is the main asset towards a digitization of the AEC community. The sector
being highly fragmented, data exchange between project stakeholders is an issue
that BIM collaborative process supported by BIM models intends to solve. In
this direction, BIM levels are often used to describe the collaboration maturity
of a project: while almost no collaboration are required in a BIM level 0 or 1,
BIM level 2 requires project stakeholders to exchange information through files.
In an ideal BIM level 3, all actors work on the very same model, without any
need of exchanging files.
At the moment, the community seems to focus its efforts on improving BIM
level 2, through the delivering of different BIM standards: IFC (Industry Founda-
tion Classes) is the main one; it is rich, extensible and covers most AEC domains.
But its complexity seems to be a barrier to software vendors, and reaching an
agreement on the vocabulary and the required information that needs to be in
such digital model is highly challenging, considering different countries or re-
gions may have different requirements, and even projects can have their own
specificities [2]. COBie is another lightweight building model, that focuses on
non-geometrical information; in energy modelling gbXML is a de facto standard
for building energy models. More recently, knowledge graph-based modelling
gained some interests as a new paradigm to deliver BIM models: [1,12] pro-
posed ifcOWL as an OWL translation of the IFC EXPRESS schema format;
128
Proceedings of the 9th Linked Data in Architecture and Construction Workshop - LDAC2021
[15] proposed BOT (Building Ontology Topology) as a minimal knowledge rep-
resentation for any building project.
It therefore seems that while the community is aware of the need for stake-
holders to share information, more and more data models are created. This could
be contradictory with BIM level 3 principle where a single model, and therefore
a single vocabulary is potentially used, unless some automatic conversions are
implemented. While many such converters exist, they are all written in some spe-
cific programming language (Java, Python . . . ) and their implementation into a
single BIM repository does not seem trivial.
2.2 Ontology mapping
In linked data, a knowledge graph is a set of statements in which nodes and edges
have well-defined meanings. Linking knowledge graphs, known in the literature
as ontology mapping or ontology matching, is done to benefit from the work
of a specialized community; the resulting ontology linkage is a set of relations
between concepts of different ontologies, known as an ontology alignment [5].
Ontology mappings can be done in different ways: for instance word distance,
translation from one language to another, or graph pattern similarities, can be
used to discover similarities between graphs.
The present work focuses on semantic matching techniques [17,7], which relies
on logical inference to deduce alignments between models. This is done defining:
1. (Axioms): direct ontology alignments between classes/relations; those take
the form ` Ax where Ax is a list of triples (i.e. usually called literals in formal
logic) where s belongs to an ontology O1 , o to an ontology O2 and
p is an alignment predicate.
2. (Inference rules) create logical rules that can be triggered thanks to the
creation of new alignments; those are of the form (A ` C, where A and C are
list of triples respectively called antecedents and consequents)
Triples in inference rules are usually open triples, i.e. they contain variables.
Nevertheless, only safe rules can be triggered correctly; a rule is said to be safe
when every variable in its consequent is already declared in its antecedent.
As an example, the transitive closure of the rdfs:subClassOf relation can be
achieved with the two following rules: (i) states that an instance of owl:Class is
a subclass of itself (i.e. reflexivitiy); and (ii) that a rdfs:subClassOf of a class
y, is a subclass of all super classes of y (i.e. transitivity).
(i) (?x rdfs:type owl:Class) ` (?x ex:transSubClass ?x)
(ii) (?x rdfs:subClassOf ?y) (?y ex:transSubClass ?z)
` (?x ex:transSubClass ?z)
Finally, reasoners can evaluate rules in different ways: (i) a forward-chaining
reasoning considers every triple in the ABox that instantiates the antecedent
of a rule to generate new triples instantiating the consequent; the operation is
129
Proceedings of the 9th Linked Data in Architecture and Construction Workshop - LDAC2021
repeated until a goal statement is reached, or no more triples are added to the
ABox. (ii) a backward-chaining approach triggers rules on request to satisfy the
instantiation of the consequent, through an instantiation of its antecedents. It is
known that a forward-chaining avoids iterating in infinite loop, but is memory-
consuming. On the other hand, backward-chaining can run in infinite loops if no
memoization is turned on, but does not store unnecessary information. Combin-
ing both forward and backward-chaining evaluable rules is called hybrid reason-
ing.
2.3 ifcOWL and BIM4Ren
The present work focuses on converting ifcOWL models into the BIM4Ren vo-
cabulary. IfcOWL [1,12] is the direct translation of the EXPRESS-based IFC
schema into the OWL language; its coverage is therefore as wide as the IFC one.
The BIM4Ren data model [3] embodies a set of ontologies with the aim of mod-
elling energy-efficient renovations. It resides on three independent layers (core,
product and domain) and a transversal one (utility) as represented in Figure 1,
which makes it a product-centric model in the sense that: (i) the core layer is
made of ontologies that help relate products between them or inside a specific
building context, (ii) the product layer is a taxonomy used to assign a specific
class to a product, and (iii) the domain layer is used to associate properties to
a product; according to specific domains.
Fig. 1. The BIM4Ren data model architecture
Full modularity (i.e. sub-ontologies are pairwise independent: none needs im-
porting another BIM4Ren ontology but from the Utils layer) is achieved through
130
Proceedings of the 9th Linked Data in Architecture and Construction Workshop - LDAC2021
a multiple instantiation mechanism, that allow importing modules on demand.
This enables one to use only small models of interest for a specific task instead
of a complex multi-domain model.
As an example, a boiler _:boiler1 may be modelled as an instance of
bot:BuildingElement to locate it in the building; of sot:SystemElement to
describe its role in the MEP networks; of ifc4:Boiler-WATER in the distribu-
tion elements model; and of elec:Consumer in the electrical ontology, where
elec:Consumer comes with a elec:nominalPower relation.
At the technical level, the BIM4Ren ontology uses (i) an extension of BOT [15]
to describe buildings, with reference to Omniclass classification to assign func-
tional properties to buildings (i.e. apartment, allotment,. . . ) and spaces (kitchen,
bedroom,. . . ); (ii) the product layer is made of taxonomies extracted from if-
cOWL to classify distribution3 and building elements4 , where enumerated prod-
uct types are transformed into classes; (iii) and the property layer uses SML, the
property modelling on-going standard provided by the CEN[4], which is based
on QUDT [6] and Ontology for Property Management (OPM) level 2 [14].
3 Model conversion as inference
In the present section, a rule-based ifcOWL to BIM4Ren conversion is presented.
As mentioned in section 2.2, we first identify the relations used to align the two
models (i.e. the axioms ) and then detail the inference rules that are used.
3.1 Axioms
Different vocabularies can be used to directly map classes or relations of different
models. The rdfs:subClassOf or owl:equivalentClass relations are used in
the current implementation to map classes, in the same way as it is done in the
existing alignment between BOT and ifcOWL 5 . Extending this approach to the
SOT ontology leads to the following set of rules:
ifc:IfcDistributionSystem rdfs:subClassOf sot:System.
ifc:IfcDistributionElement rdfs:subClassOf sot:SystemComponent.
ifc:IfcDistributionPort rdfs:subClassOf sot:TransportElement.
ifc:IfcFlowTerminal rdfs:subClassOf sot:TerminalElement.
These rules form the axioms of our conversion process from ifcOWL to
BIM4Ren. Nevertheless, it is worth mentioning that other vocabularies are used
to map the BIM4Ren models with other vocabularies, in particular Omniclass
and Property Set Definition (PSD).
3
https://pi.pauwel.be/voc/distributionelement/index-en.html
4
https://pi.pauwel.be/voc/buildingelement/index-en.html
5
https://raw.githubusercontent.com/w3c-lbd-cg/bot/master/IFCOWL4_
ADD2Alignment.ttl
131
Proceedings of the 9th Linked Data in Architecture and Construction Workshop - LDAC2021
As mentioned in 2.3, Omniclass is used to extend BOT with concepts on
building and space types. Because to our knowledge no web referenceable ver-
sion of Omniclass exists, every created subclass is bound to its correspond-
ing associated Omniclass code through the rdfs:isDefinedBy relation (e.g.
buildings:Bathroom rdfs:isDefinedBy "Omniclass 13-65 13 15".
In addition, properties of the domain layer are mapped with their PSD coun-
terpart, which are web referenceable through the buildingSmart Data Dictionary
(bsDD). A BIM4Ren property may be associated to multiple bsDD properties
(see Figure 2), using the skos vocabulary.
Fig. 2. Example of alignment with IFD through bsDD
3.2 Inference rules
The presented axioms are limited to mapping ifcOWL classes to BIM4Ren, as a
direct mapping (using rdfs:subPropertyOf for instance) is impossible. Indeed,
while relations in ifcOWL are often objectified (i.e. a class is used to model them,
with the IfcRel prefix), linked building data ontologies simplify modelling using
a single relation. This is illustrated in Figure 3.
Fig. 3. Example of deobjectification of relations
Deobjectifying a relation can easily be translated as an inference rule:
(?z rdf:type ?cl) (?cl rdfs:subClassOf bot:Zone)
(?c ifc:relatingStructure_IfcRelContainedInSpatialStructure ?z)
(?c ifc:relatedElements_IfcRelContainedInSpatialStructure ?p)
` (?z bot : hasElement ?p)
132
Proceedings of the 9th Linked Data in Architecture and Construction Workshop - LDAC2021
Some complementary internal rules need to be elaborated to deal with the list
structure of ifcOWL. For instance the range of the IfcRelNests_relatedObjects
relation is a list, which type in ifcOWL is https://w3id.org/list; it is a LISP-
like list structure made of list:hasContents to get the head, and list:hasNext
to return the list from which the top element was removed [13]. Handling lists
in the converter requires to have a way to directly check whether an element is
in a list, which can be done with the following recursive rules:
(?l list:hasContents ?elt) ` (?elt list:isIn ?l)
(?l list:hasNext ?q) (?elt list:isIn ?q) ` (?elt list:isIn ?l)
Finally, classes in the Product layer of the BIM4Ren data model also need
to be aligned with the corresponding enumerated types in IFC. For each enu-
merated type, a conversion rule can be elaborated as below:
(?z rdf:type ifc:IfcBoiler) (?z ifc:predefinedType_Boiler ifc:WATER)
` (?z rdf:type distribution:Boiler-WATER).
In order to deal with all enumerated types in the Distribution and Building
element ontologies, a Python script was developed. This leads to generating 693
rules amongst the 708 total rules.
4 Implementation and tests
In order to evaluate our approach, we compare it with a program-based converter
considering (i) correctness of the conversion, (ii) performance, (iii) maintenance,
(iv) the full conversion workflow.
4.1 Description
An implementation of our approach was done on an Apache Jena instance. All
rules were implemented according to the Generic Rule Reasoner file format.
The program-based converter to which results were compared is a Java-based
converter6 , an extension of the IFCtoLBD [11] converter. Regarding the inference
engine approach, we tested two different reasonings: a simple forward-chaining
and a hybrid one, which differs from the former in that:
(i) It uses an ad hoc subClass relation: the inference rules need to check
that some individuals are instances of specific classes, or of descendant of such
classes. The b4r:subClassOf) is the transitive closure of rdfs:subClassOf but
it is restricted to ancestor classes used in the inference rules (i.e. bot:Zone,
sot:System and sot:SystemComponent).
(ii) It uses backward-chaining on complex rules: all rules used to align
the core layer are converted to top-down rules. This can be simply done in Jena’s
reasoner7 .
6
https://github.com/jyrkioraskari/IFCtoB4R-DM_OpenAPI/
7
https://jena.apache.org/documentation/inference/index.html#RULEbackward
133
Proceedings of the 9th Linked Data in Architecture and Construction Workshop - LDAC2021
(iii) It memorizes recurrent inferred triples: Some of the rules do not
directly solve alignment issues but can be seen as utility rules. This is the case
of the b4r:subClassOf and list:isIn rules. Because these rules can be used
extensively inside other rules and because they potentially generate a high num-
ber of triples, a memorization mechanism is enable to allow keeping results in
memory and to avoid infinite loops.
Two different IFC models were considered for testing. The first one (called
Dunant.ifc) results from the scanning of a multi-dwelling building in Paris as
part of the BIM4Ren project. The corresponding ifcOWL ttl file is made of
10033 individuals, from which only 138 are not related to geometry; those are
instances of IfcSite, IfcBuilding, IfcStorey, IfcSlab, IfcCovering, IfcWall,
IfcDoor and IfcWindow. To test how scalable the approach is, the Duplex_MEP
model [8] was considered. Duplex is two-storeys appartement model, well-known
in the IFC community8 ; it is made of 687363 individuals (apart from geometric
information) and more importantly for our experiments, contains instances of
IfcSpace of the DistributionElement hierarchy, so most of the inference rules
can be tested. Those rules were created to infer the hasBuilding, hasStorey,
hasSpace and hasElement relations in BOT, and the hasElements (i.e. when an
element is a component of a system) and connectedWith (i.e. when two MEP
products are connected) relations in SOT.
Table 1. Summary of expected relations - generated with IFC2BOT
Relations Dunant Duplex_MEP
bot:hasStorey 2 3
bot:hasSpace 0 42
bot:hasElement 59 926
bot:containsElement 0 167
Regarding the methodology, (i) we ensure the correctness of the rules through
a comparison of the BOT classes and relations output by our converters (ob-
tained through SPARQL query) with the ones output by the IFC2BOT 9 ; (ii)
we compare the execution performance of the inference engine approach with
the one of the programmatic approach; to do so, we perform queries on a triple
store for which an inference engine is running, and on another one on which the
model output by the IFCtoLBD tool was uploaded.
4.2 Results
First, the tests prove some scalability issues for the forward-chaining approach:
Jena stopped with a "java.lang.OutOfMemoryError: Java heap space" error, af-
ter the execution hang for more than 30 minutes on the first query performed on
8
availableat https://github.com/buildingSMART/Sample-Test-Files/tree/
master/IFC%202x3/Duplex%20Apartment
9
https://github.com/NIRAS-MHRA/IFC2BOT
134
Proceedings of the 9th Linked Data in Architecture and Construction Workshop - LDAC2021
the Duple_MEP model. As already mentioned, forward-chaining reasoning may
require keeping in memory useless triples, and by default the GenericRuleRea-
soner infers all new triples on the first query performed. The hybrid reasoner
runs successfully on all models, and all queries, proving the efficiency of the
different modifications performed.
Regarding the correctness of the approach, the hybrid reasoning’s BOT out-
puts are sound and complete with respect to the IFC2BOT outputs, on both the
Dunant and Duplex_MEP files, ensuring its correctness. The same happens for
the forward-chaining reasoning on the Dunant file.
Regarding execution performance, the results are described in Table 2. Op-
erations were run in the same order given as in the table.
Table 2. Performance test results (times in ms)
Operation Forward-chaining Hybrid IFCtoLBD
Dunant Duplex Dunant Duplex Dunant Duplex
1.Get all bot:Building 4138 Err 159 225 725 3902
2.Get all bot:Space 766 Err 157 150 645 4338
3.Get all bot:Zone 745 Err 138 10 915 4406
4.Get all bot:containsZone 3 Err 20 39 938 3607
5.Get all bot:hasElement 4 Err 5 92 977 4494
6.Get all sot:SystemComponent 732 Err 137 150 - -
First of all, for the forward-chaining reasoning, getting all buildings takes
longer than getting all spaces or zones, but this is due to the testing procedure:
getting buildings was the first query performed, and it therefore triggers the
reasoner that infers all new triples, a time-consuming operation. In fact when
repeating the query, answers are provided within approximately 700ms.
The hybrid evaluation performs better than the forward-chaining one on
queries 1, 2 and 3 on Dunant. The performed queries are of the form: SELECT
?z WHERE {?z a ?cl. ?cl REL ENT.}, where ENT is to be replaced with the
goal class (bot:Building on 1., bot:Space on 2. and bot:Zone on 3.) and REL
with rdfs:subClassOf* (i.e. the transitive closure of rdfs:subClassOf) for the
forward-chaining evaluation, and with b4r:subClassOf for the hybrid one. This
gives an idea of the efficiency provided by adding the former over the latter.
To confirm it, getting all buildings on Duplex in the hybrid approach with the
rdfs:subClassOf* relation takes 22 533ms.
Generally speaking, the hybrid reasoning outperforms the forward-chaining
one for almost all queries on the Dunant file; this tends to show there is no clear
advantages on computing all inferred triples at initialization. This is surprisingly
clear with queries 4 and 5, where the relations are inferred with the help on
non-axiomatic rules and may therefore require high runtime computation in the
hybrid implementation. Moreover, the more different queries are run on the
hybrid model, the better it performs. Indeed, memorization of the results (either
135
Proceedings of the 9th Linked Data in Architecture and Construction Workshop - LDAC2021
intermediate or final) of multiple queries ensures those can be reused without
any computational cost for future queries.
In addition, queries on a logic-based approach are competitive with the Java
program, if not outperforming it, in the case of the hybrid implementation. The
high difference between the hybrid approach and IFCtoLBD seems again to
reside on the use of the b4r:subClassOf relation.
Regarding maintenance, the inference rule-based approach may not be as
easy to develop or make evolve as a program-based approach. Indeed, debugging
inference rules in Jena using a configuration file for the rules is not trivial, and,
to our knowledge, no tool exists to assist developers in this task as opposed
to debugging environments for long-time consolidated programming languages.
Moreover, the syntax for the inference rules may differ from a triple store to
another one.
Finally, regarding the workflow, the inference rule-based approach resides
in using a triple store as a central model storage, and its native engine as a
converter; no deployment effort is therefore needed as all required functionalities
are available within Jena or any other triple store. The program-based conversion
requires (i) to download the ifcOWL model, (ii) convert it to the BIM4Ren
model, (iii) upload it again to the triple store. This process can probably be
automatized, but the advantage in using an inference-rule based approach is that
every changes made, using IFC (resp. BIM4Ren) vocabulary, is automatically
reflected in the BIM4Ren (resp. IFC) one.
5 Conclusion
5.1 Advantages and limitations
The experiments show that the linked-data approach is efficiently dealing with
the conversion of models from IFC to BIM4Ren. Nevertheless, the approach is
scalable at the cost of some tuning on the rules evaluation. The hybrid approach
differs from the forward-chaining one as the latter converts parts of the model on-
demand, while the former maintains the conversion at run time. Nevertheless,
both dynamically convert only the necessary part of the model, which is the
main difference with a programmatic approach, that converts the the full model
at once. A programmatic approach may have a wider coverage, being able to deal
with geometry conversion as well as properties, but our approach is language-
independent, can be directly implemented on any triple store and is dynamic.
The current work also led to some diagnosis on ifcOWL. As mentioned, we
created specific rules for the isIn relation, which checks the presence of an ele-
ment inside an owl:OWLList. Using rdf:List instead, the built-in swrlb:member
could be used10 , which may improve the overall performance of the converter.
Finally, some experiments were done on backward conversions, i.e. from
BIM4Ren to ifcOWL. The main issue is that backward inference rules are unsafe,
because ifcOWL uses objectified relations, introducing therefore more concepts
10
see 8.7 of https://www.w3.org/Submission/SWRL/
136
Proceedings of the 9th Linked Data in Architecture and Construction Workshop - LDAC2021
than BIM4Ren. In practice, this can be bypassed using the makeTemp Jena built-
in function. This is illustrated in the rule above where the variable ?c is the
objectified relation to create (i.e. the main element in the consequent), and as
such, it needs to be declared in the antecedent.
(?z rdf:type ?clz) (?clz b4r:subClassOf ifc:IfcSpatialElement)
(?z bot:hasElement ?p)
(?p rdf:type ?clsp) (?clsp b4r:subClassOf ifc:IfcProduct)
makeTemp(?c)
-> (?c rdf:type ifc:IfcRelCointainedInSpatialStructure)
(?c ifc:relatingStructure_IfcRelContainedInSpatialStructure ?z)
(?c ifc:relatedElements_IfcRelContainedInSpatialStructure ?p)
5.2 Future work
In the future, the approach should be extended to cover PSD properties and
geometry. Regarding properties, a mapping will be done in the BIM4Ren project
between the model and a POBIM (ISO 12006-3) implementation, that is used
to describe product properties. If a formal ontology for PSD properties arises, it
will also be used to convert such properties into relations in the Domain layer of
the BIM4Ren model.
Extending the approach to geometry would require a deeper work, because
the amount of geometry information in BIM is high, and the scalability of such
approach cannot be easily ensured. In addition, dealing with geometry in a linked
data environment is still a reasearch topic in itself to the authors knowledge.
Ideally, such conversion should also imply geometry representation conversion,
i.e. bounding boxes, B-REP. . .
Extending the approach to models used in the industry, in particular gbXML
or COBie, is another interesting topic as it would deliver a more impacting use
case to the overall AEC industry.
Other alignment methodologies may also be explored to solve BIM issues in
the AEC community; for instance the rule-based alignment is manually done
through the elaboration of the rules, but other approaches can be tested to
discover alignments automatically (patterns discovery, word distance...).
Overall, in a BIM level 3 implementation, our approach could be used to
allow stakeholders to use their own vocabularies, which we consider crucial to
federate the sector. Such an approach strongly differs from bringing a single
unified standard. Other tests could be performed to ensure the scalability of the
solution on bigger models, concurrency issues on triple stores when updating the
model,. . .
References
1. Beetz, J., van Leeuwen, J., de Vries, B.: IfcOWL: A case of transforming EXPRESS
schemas into ontologies. AI EDAM 23(1), 89–101 (2009)
137
Proceedings of the 9th Linked Data in Architecture and Construction Workshop - LDAC2021
2. van Berlo, L.: BuildingSMART tehnical roadmap (2020), published on buildings-
mart.org, version 30 april 2020
3. Bourreau, P., Charbel, N., Werbrouck, J., Senthilvel, M., Pauwels, P., Beetz, J.:
Multiple inheritance for a modular BIM. In: Teulier, R., Marquès, S. (eds.) Le BIM
et l’évolution des pratiques: Ingénierie et architecture, enseignement et recherche.
pp. 63–82. Eyrolles (2020)
4. CEN: prEN 17632:2021, Semantic Modelling and Linking (SML) (2020), (out for
first ballot in March 2021)
5. Euzenat, J., Shvaiko, P., et al.: Ontology matching, vol. 18. Springer (2007)
6. Hodgson, R., Keller, P.J., Hodges, J., Spivak, J.: QUDT-quantities, units, dimen-
sions and data types ontologies. USA Available http://qudt. org March 156 (2014)
7. Jean-Mary, Y.R., Shironoshita, E.P., Kabuka, M.R.: Ontology matching with se-
mantic verification. Journal of Web Semantics 7(3), 235–251 (2009)
8. Johnson, M., Fallon, K.K.: Experimental building information models. Tech. rep.,
Construction Engineering Research Laboratory (US) (2011)
9. Kalfoglou, Y., Schorlemmer, M.: Ontology mapping: the state of the art. In:
Dagstuhl Seminar Proceedings. Schloss Dagstuhl-Leibniz-Zentrum für Informatik
(2005)
10. Mao, M.: Ontology mapping: An information retrieval and interactive activation
network based approach. In: The Semantic Web, pp. 931–935. Springer (2007)
11. Oraskari, J., Bonduel, M., McGlinn, K., Pauwels, P., Priyatna, F., Wagner, A.,
Kukkonen, V., Steyskaland, S., Lehtonen, J.: jyrkioraskari/IFCtoLBD: IFCtoLBD
2.5 (Sep 2020). https://doi.org/10.5281/zenodo.4056940, https://doi.org/10.
5281/zenodo.4056940
12. Pauwels, P., Terkaj, W.: EXPRESS to OWL for construction industry: Towards a
recommendable and usable ifcowl ontology. Automation in Construction 63, 100–
133 (2016)
13. Pauwels, P., Terkaj, W., Krijnen, T., Beetz, J.: Coping with lists in the ifcOWL
ontology. In: 22nd EG-ICE International Workshop. pp. 113–122 (2015)
14. Rasmussen, M., Lefrançois, M., Bonduel, M., Hviid, C., Karlshøj, J.: OPM: An
ontology for describing properties that evolve over time. In: 6th Linked Data in
Architecture and Construction Workshop (2018)
15. Rasmussen, M.H., Lefrançois, M., Schneider, G.F., Pauwels, P.: BOT: the building
topology ontology of the w3c linked building data group. Semantic Web 12, 1–19
(2019)
16. Schneider, G.F.: Towards aligning domain ontologies with the building topology
ontology. In: Proceedings of the 5th Linked Data in Architecture and Construction
Workshop (LDAC 2017) (2017)
17. Shvaiko, P.: Iterative schema-based semantic matching. Ph.D. thesis, University of
Trento (2006)
138
Proceedings of the 9th Linked Data in Architecture and Construction Workshop - LDAC2021
A Axioms
@prefix : .
@prefix owl: .
@prefix rdf: .
@prefix xsd: .
@prefix rdfs: .
@prefix dcterms: .
@prefix bot: .
@prefix sot: .
@prefix ifc4: .
@prefix ifc2x3: .
bot:Site owl:equivalentClass ifc4:IfcSite ;
owl:equivalentClass ifc2x3:IfcSite.
bot:Building owl:equivalentClass ifc4:IfcBuilding ;
owl:equivalentClass ifc2x3:IfcBuilding .
bot:Storey owl:equivalentClass ifc4:IfcBuildingStorey ;
owl:equivalentClass ifc2x3:IfcBuildingStorey .
bot:Space owl:equivalentClass ifc4:IfcSpace ;
owl:equivalentClass ifc2x3:IfcSpace .
bot:Element owl:equivalentClass ifc4:IfcElement ;
owl:equivalentClass ifc2x3:IfcElement .
ifc2x3:IfcDistributionSystem rdfs:subClassOf sot:System.
ifc4:IfcDistributionSystem rdfs:subClassOf sot:System.
ifc2x3:IfcDistributionElement rdfs:subClassOf sot:SystemComponent.
ifc4:IfcDistributionElement rdfs:subClassOf sot:SystemComponent.
ifc2x3:IfcDistributionPort rdfs:subClassOf sot:TransportElement.
ifc4:IfcDistributionPort rdfs:subClassOf sot:TransportElement.
ifc2x3:IfcFlowTerminal rdfs:subClassOf sot:TerminalElement.
ifc4:IfcFlowTerminal rdfs:subClassOf sot:TerminalElement.
139
Proceedings of the 9th Linked Data in Architecture and Construction Workshop - LDAC2021
.
B Extract of the hybrid rules used in the experiments
@prefix owl: .
@prefix rdf: .
@prefix rdfs: .
@prefix list: .
@prefix bot: .
@prefix sot: .
@prefix b4r-building: .
@prefix distribution: .
@prefix building: .
@prefix b4r: .
@prefix ifc: .
[equivalent1: (?a owl:equivalentClass ?b) -> (?a rdfs:subClassOf ?b) (?b
rdfs:subClassOf ?a)]
-> table(b4r:subClassOf).
[transSubClassZone: -> (bot:Zone b4r:subClassOf bot:Zone)]
[transSubClassSystemComponent: -> (sot:SystemComponent b4r:subClassOf
sot:SystemComponent)]
[transSubClassSystem: -> (sot:System b4r:subClassOf sot:System)]
[transSubClass1: (?cls1 b4r:subClassOf ?cls2) <- (?cls1 rdfs:subClassOf ?cls2)]
[transSubClass2: (?cls1 b4r:subClassOf ?cls3) <- (?cls1 rdfs:subClassOf ?cls2)
(?cls2 b4r:subClassOf ?cls3)]
-> table(list:isIn).
[isIn1: (?elt list:isIn ?l) <- (?l list:hasContents ?elt)]
[isIn2: (?elt list:isIn ?l) <- (?l list:hasNext ?queue) (?elt list:isIn ?queue)]
[botHasElement-IFC: (?z bot:hasElement ?p) <-
(?c ifc:relatingStructure_IfcRelContainedInSpatialStructure ?z)
(?c ifc:relatedElements_IfcRelContainedInSpatialStructure ?p)
(?z rdf:type ?cl) (?cl b4r:subClassOf bot:Zone)]
[relHasBuilding-IFC2x3: (?z1 bot:hasBuilding ?z2) <-
(?rel ifc2x3:relatingObject_IfcRelDecomposes ?z1)
(?rel ifc2x3:relatedObjects_IfcRelDecomposes ?z2)
(?z1 rdf:type ?cl1) (?cl1 b4r:subClassOf bot:Zone)
(?z2 rdf:type ?cl2) (?cl2 b4r:subClassOf bot:Building)]
[relHasStorey-IFC2x3: (?z1 bot:hasStorey ?z2) <-
(?rel ifc2x3:relatingObject_IfcRelDecomposes ?z1)
(?rel ifc2x3:relatedObjects_IfcRelDecomposes ?z2)
(?z1 rdf:type ?cl1) (?cl1 b4r:subClassOf bot:Zone)
(?z2 rdf:type ?cl2) (?cl2 b4r:subClassOf bot:Storey)]
[relHasSpace-IFC2x3: (?z1 bot:hasSpace ?z2) <-
(?rel ifc2x3:relatingObject_IfcRelDecomposes ?z1)
(?rel ifc2x3:relatedObjects_IfcRelDecomposes ?z2)
(?z1 rdf:type ?cl1) (?cl1 b4r:subClassOf bot:Zone)
(?z2 rdf:type ?cl2) (?cl2 b4r:subClassOf bot:Space)]
[relContainsZone-IFC4: (?z1 bot:containsZone ?z2) <-
(?rel ifc4:relatingObject_IfcRelAggregates ?z1)
(?rel ifc4:relatedObjects_IfcRelAggregates ?z2)
140
Proceedings of the 9th Linked Data in Architecture and Construction Workshop - LDAC2021
(?z1 rdf:type ?cl1) (?cl1 b4r:subClassOf bot:Zone)
(?z2 rdf:type ?cl2) (?cl2 b4r:subClassOf bot:Zone)]
[connectedWith-IFC: (?elt1 sot:connectedWith ?elt2) <-
(?c ifc:relatingPort_IfcRelConnectsPorts ?p1) (?c
ifc:relatedPort_IfcRelConnectsPorts ?p2)
(?elt1 rdf:type ?cls1) (?cls1 b4r:subClassOf sot:SystemComponent)
(?elt2 rdf:type ?cls2) (?cls2 b4r:subClassOf sot:SystemComponent)
(?n1 ifc:relatingObject_IfcRelNests ?elt1) (?n1 ifc:relatedObjects_IfcRelNests
?list1) (?p1 list:isIn ?list1)
(?n2 ifc:relatingObject_IfcRelNests ?elt2) (?n2 ifc:relatedObjects_IfcRelNests
?list2) (?p2 list:isIn ?list2)]
[sotHasElements-IFC: (?s sot:hasElements ?elt) <-
(?c ifc:relatingGroup_IfcRelAssignsToGroup ?s)
(?c ifc:relatedObjects_IfcRelAssigns ?elt)
(?s rdf:type ?cls) (?cls b4r:subClassOf sot:System)
(?elt rdf:type ?clse) (?clse b4r:subClassOf sot:SystemComponent)]
[ifcToLbdAirTerminalBox-USERDEFINED:(?z rdf:type ifc:IfcAirTerminalBox) (?z
ifc:predefinedType_AirTerminalBox ifc:USERDEFINED) -> (?z rdf:type
distribution:AirTerminalBox-USERDEFINED) .
[ifcToLbdAirTerminalBox-VARIABLEFLOWPRESSUREDEPENDANT:(?z rdf:type
ifc:IfcAirTerminalBox) (?z ifc:predefinedType_AirTerminalBox
ifc:VARIABLEFLOWPRESSUREDEPENDANT) -> (?z rdf:type distribution:AirTerminalBox-
VARIABLEFLOWPRESSUREDEPENDANT) .
[ifcToLbdAirTerminalBox-VARIABLEFLOWPRESSUREINDEPENDANT:(?z rdf:type
ifc:IfcAirTerminalBox) (?z ifc:predefinedType_AirTerminalBox
ifc:VARIABLEFLOWPRESSUREINDEPENDANT) -> (?z rdf:type distribution:AirTerminalBox-
VARIABLEFLOWPRESSUREINDEPENDANT) .
[ifcToLbdAirTerminalBox-CONSTANTFLOW:(?z rdf:type ifc:IfcAirTerminalBox) (?z
ifc:predefinedType_AirTerminalBox ifc:CONSTANTFLOW) -> (?z rdf:type
distribution:AirTerminalBox-CONSTANTFLOW) .
[ifcToLbdAirTerminalBox-NOTDEFINED:(?z rdf:type ifc:IfcAirTerminalBox) (?z
ifc:predefinedType_AirTerminalBox ifc:NOTDEFINED) -> (?z rdf:type
distribution:AirTerminalBox-NOTDEFINED) .
[ifcToLbdValve-ANTIVACUUM:(?z rdf:type ifc:IfcValve) (?z ifc:predefinedType_Valve
ifc:ANTIVACUUM) -> (?z rdf:type distribution:Valve-ANTIVACUUM) .
….
141