Presentation given at the FOMI workshop - with Walter Terkaj - Formal Ontology Meets Industry - September 2017 - Bolzano, Italy

1. Walter TERKAJ
Pieter PAUWELS
A Method to generate a Modular
ifcOWL Ontology
Bolzano, 21 September 2017
3rd Joint Ontology Workshops
JOWO 2017
8th International Workshop on
Formal Ontologies meet Industry
FOMI 2017

2. Building Information Modeling
2

3. BIM and Ontology
Semantic Web offers opportunities to provide more effective solutions also for the
BIM domain, by exploiting its typical enablers in terms of formal modeling
language, data distribution, extensibility, and automatic reasoning. Possible BIM
solutions based on Semantic Web technologies include:
 an OWL version of IFC, named ifcOWL. Previous works demonstrated how
the ifcOWL can be automatically generated by converting the IFC EXPRESS
schema to OWL.
 development of novel ontologies for BIM that are based on the semantic web
principles and designed exploiting modularity and extensibility since the
beginning.
3
W3C Linked Building Data (LBD) Community Group is working on a
set of loosely related ontologies for Building Topology (BOT),
Product, Geometry, Automation and Control

4. ifcOWL
4
Industry Foundation Classes (IFC) by buildingSMART represents an open
specification for Building Information Modeling (BIM) data that is exchanged
and shared among the various participants in a building construction or
facility management project. The specification consists of the data schema,
represented as an EXPRESS schema specification (ISO 10303-11).
EXPRESSIFC-SPF
XSDXML
ifcOWLRDF

5. EXPRESS schema to OWL - ifcOWL
5
Automatic generation using a converter based on the pattern approved by buildingSmart Intl:
 http://www.buildingsmart-tech.org/future/linked-data/linked-data
 http://openbimstandards.org/standards/ifcowl/
IFC
Schema
Simple data type
Defined data type
Aggregation data type
SET data type --------
LIST & ARRAY data type --------
Constructed data type
SELECT data type --------
ENUMERATION data type --------
Entity data type
Attributes --------
Derive attr
WHERE rules
Functions
Rules
ifcOWL
Ontology
owl:class + owl:DatatypeProperty restriction
owl:class
owl:class
-------- non-functional owl:ObjectProperty
-------- indirect subclass of express:List
owl:class
-------- rdfs:subClassOf for owl:classes
-------- rdf:type for owl:NamedIndividuals
owl:class
-------- object properties
-
-
-
-
Pauwels P, Terkaj W (2016) EXPRESS to OWL for construction industry: Towards a recommendable and usable ifcOWL ontology. Automation
in Construction, 63:100–133
Pauwels P, Krijnen T, Terkaj W, Beetz J (2017) Enhancing the ifcOWL ontology with an alternative representation for geometric data.
Automation in Construction, 80:77-94

6. ifcOWL
Pros
o Adherence to the IFC standard
o Automatic conversion pattern to generate the Tbox ifcOWL
o Automatic conversion can be applied also to generate an IFC-RDF graph from an IFC
instance file, and vice-versa
Cons
o Missing a proper ontological analysis of the IFC standard
o The ifcOWL ontology has a monolithic structure. The complex structure of IFC
jeopardizes its exploitation by industrial domains outside the core AEC applications that may
need a simple model of building, spaces, elements and their relations with geometry,
topology, monitoring, automation and control, safety, etc.
6
o Simplification? What can be simplified?
o Modularity? How can the ontology be split into separate ontology modules?
Solutions?
IFC4_ADD1 EXPRESS schema
• 768 Entity data types
• 206 Enumeration data types
• 60 Select data types
• 131 defined data types
ifcOWL for IFC4_ADD1
• 1313 classes
• 1580 object properties
• 13867 logical axioms
• 1158 individuals

7. Simplified representations asked
7
Pieter Pauwels, Ana Roxin. SimpleBIM: from full ifcOWL graphs to simplified building graphs.
Proceedings of the 11th European Conference on Product and Process Modelling. p.11-18.
Chi Zhang, Jakob Beetz. Querying Linked Building Data Using SPARQL with Functional Extensions.
Proceedings of the 11th European Conference on Product and Process Modelling.

8. Ontology Modularization
As defined by d'Aquin et al. 2009, the task of partitioning an ontology is “the process of splitting
up the set of axioms into a set of modules {M1, ... , Mk} such that each Mi is an ontology and
the union of all modules is semantically equivalent to the original ontology O”.
Modularity is beneficial both during the design phase and during the deployment and
usage. Some of the benefits:
o scalability for querying data and reasoning on ontologies
o scalability for evolution and maintenance
o complexity management
o understandability
o context-awareness and personalization
o reuse
Modularization strategies:
o disjoint or overlapping modules
o semantics-driven strategies
o structure-driven strategies (e.g. using graph decomposition algorithms)
o machine learning strategies
o monitoring modularization and making it evolve
8
A modular ifcOWL is expected to improve:
• usability, end users and applications
select the modules that are actually going
to be used
• performance (e.g. query and reasoning)
• reduce the complexity, easier alignment
with other ontologies, also reducing
overlapping

9. ifcOWL & Modularization
At least two strategies can be envisioned to generate a modular ifcOWL:
1. modularization by content, i.e. the definition of classes and properties are separated
based on the knowledge domain they are related to, e.g. geometry, units of
measurement, building components, HVAC, etc.
2. modularization by axiom type, i.e. separating the different axioms that are included in
ifcOWL, such as definition of classes, subsumption, data/object properties,
domain/range of properties, equivalent classes, cardinality restrictions apart, etc.
9
IFC was developed in a
modular way and each
data type (i.e. entity,
enumeration, select,
defined) in the EXPRESS
schema belongs to a
specific sub-schema
Strategy n.1

10. Modularization Algorithm – Reqs & Goals
Requirements:
o Applicable to convert any EXPRESS schema (e.g. IFC, but also ISO~15531,
ISO~14649, etc.) to a modular OWL ontology.
o The modularization takes place while converting an EXPRESS schema to an
OWL ontology, instead of being executed on an already existing large
monolithic ontology (e.g. the already generated full ifcOWL).
o Once the algorithm assigns an EXPRESS definition to a module, then the
conversion to the corresponding OWL axiom is executed Pauwels et al. 2017
Goals:
o finding the best way of implementing a given input modularization by
minimizing the number of direct import relations between modules.
o avoid to create reciprocal dependencies between modules because it would
lead to circular import paths.
o Output: a graph where nodes=modules and arcs=import relations
10

11. Modularization Algorithm – Input and Structure
The algorithm receives as input the following pieces of information:
o content of a parsed EXPRESS schema in terms of data types (i.e. defined
data, entity, select, enumeration), subsumption relationships and attributes of
each entity data type.
o input modularization in terms of mapping between EXPRESS data types
and modules. This mapping can be the results of more or less sophisticated
methodologies, or it can be provided in a technical documentation (as in the
case of IFC), or it can be simply set by the user based on his/her needs.
o priority level associated with each module. This priority is used to set import
relations between modules. Ceteris paribus, the module with lower priority will
import the module with higher priority.
11
Main Routine SetModule
converts EXPRESS
definitions to OWL axioms
that are added to a
specific module set by
SetModule
incrementally adds import
relationships between
modules

12. Modularization Algorithm – Main Routine
12
STEP 1
STEP 2
STEP 3
STEP 4
STEP 5 Apply Transitive Reduction to the Graph generated after STEP 4
STEP
Processed EXPRESS
definitions
Generated
OWL axioms
Axioms added
to Module
1
All data types (Entities,
Enum, Select, Defined
datatype)
Class predefined
2
Subtypes of all data
types
subClassOf
returned by
SetModule
3 All items of Selects subClassOf
returned by
SetModule
4
All Attributes of all
Entities
object property,
restriction
returned by
SetModule

13. Modularization Algorithm - SetModule
Current Graph G=(M,I)
Module x and Module y where the classes involved in the axiom are defined
Priority p(x), p(y) of the modules x, y
13
Calculate the transitive closure of G
to get the reachability relations R
return x
return x
return y
add (y,x) to set I, return y
add (x,y) to set I, return x
yes
yes
yes
yes
no
no
no
no
Ordering of nodes
Topological
ordering
Directed Acyclic
Graph (DAG)

14. Experiments
o IFC4 schema
o Input modularization based on 38 IFC
sub-schemas
o Additional ontology modules
https://w3id.org/express
https://w3id.org/list that are
automatically included during the
EXPRESS to OWL conversion.
o Priority level associated with each
module based on the IFC layer
14

15. Experiments and Results
15
Testing 3 versions of modularization algorithm:
o Simple, i.e. STEP 1-4 of Main Routine
o Basic, i.e. STEP 1-4 of Main Routine + SetModule
o Full, i.e. STEP 1-5 of Main Routine + SetModule

16. Experiments and Results
16
Simple

17. Experiments and Results
17
Basic Full

18. Experiments and Results
18
Module #triples #classes
IFCACTORRESOURCE 851 15
IFCAPPROVALRESOURCE 241 3
IFCARCHITECTUREDOMAIN 933 16
IFCBUILDINGCONTROLSDOMAIN 396 18
IFCCONSTRAINTRESOURCE 520 12
IFCCONSTRUCTIONMGMTDOMAIN 504 20
IFCCOSTRESOURCE 303 9
IFCDATETIMERESOURCE 1206 33
IFCELECTRICALDOMAIN 1191 66
IFCEXTERNALREFERENCERESOURCE 833 22
IFCGEOMETRICCONSTRAINTRESOURCE 440 18
IFCGEOMETRICMODELRESOURCE 1336 42
IFCGEOMETRYRESOURCE 2062 75
IFCHVACDOMAIN 1752 99
IFCKERNEL 1716 62
IFCMATERIALRESOURCE 1053 28
IFCMEASURERESOURCE 1354 147
IFCPLUMBINGFIREPROTECTIONDOMAIN 291 15
IFCPRESENTATIONAPPEARANCERESOURCE 1852 77
IFCPRESENTATIONDEFINITIONRESOURCE 168 8
IFCPRODUCTEXTENSION 1778 71
IFCPROFILERESOURCE 1508 35
IFCPROPERTYRESOURCE 633 16
IFCQUANTITYRESOURCE 374 11
IFCREPRESENTATIONRESOURCE 750 25
IFCSHAREDBLDGSERVICEELEMENTS 502 30
IFCSHAREDCOMPONENTELEMENTS 315 14
IFCSTRUCTURALANALYSISDOMAIN 998 39
IFCSTRUCTURALELEMENTSDOMAIN 1063 29
IFCSTRUCTURALLOADRESOURCE 1048 28
IFCTOPOLOGYRESOURCE 407 23
IFCUTILITYRESOURCE 412 12
IFCPRESENTATIONORGANIZATIONRESOURCE 168 8
IFCPROCESSEXTENSION 673 19
IFCCONTROLEXTENSION 115 4
IFCSHAREDBLDGELEMENTS 1552 75
IFCSHAREDFACILITIESELEMENTS 400 11
IFCSHAREDMGMTELEMENTS 349 10
max 2062 147
min 168 3
TOT 32047 1245

19. Conclusions
A modular version of ifcOWL can help to solve practical problems related to its
usability and the scalability of software applications based on it.
Moreover, the resulting modularization can be exploited also to extract fragments of
the ifcOWL that are relevant for the specific applications.
Further developments will address:
o the investigation of other modularization strategies and the introduction of
criteria to at least partially control the definition of dependencies between
modules, e.g. by optimizing their priorities
o testing the benefits of working with a subset of ifcOWL modules from a
computational perspectives
o the integration of a fragment of the ifcOWL ontology with other ontologies
o the comparison of the modular ifcOWL with other ontologies for BIM that are
designed to be modular since the beginning
o modularization strategies for Abox ontologies that are compliant with ifcOWL
19

20. Walter TERKAJ
Pieter PAUWELS
A Method to generate a Modular
ifcOWL Ontology
Bolzano, 21 September 2017
3rd Joint Ontology Workshops
JOWO 2017
8th International Workshop on
Formal Ontologies meet Industry
FOMI 2017