The document discusses the need for formalization and standardization of the IFC (Industry Foundation Classes) in OWL (Web Ontology Language) format, emphasizing collaborative efforts among various research initiatives. It highlights the evolution and challenges faced from 2005 to 2015 in developing a unified IFCOWL structure while addressing open issues related to ontology names, URI naming conventions, and data types. The authors advocate for a more standardized approach to better utilize semantic web technologies in architecture and construction.

1. Towards an industry-wide
ifcOWL: choices and issues
Pieter Pauwels, Ghent University
María Poveda Villalón, UPM
3rd workshop on Linked Data in Architecture and Construction – 17 July 2015 - Eindhoven

2. • Diverse suggestions in academic research to make IFC available as an OWL
ontology to allow the usage of semantic web technologies
 Schevers and Drogemuller, 2005
 Beetz et al., 2009
• General purpose initiative to convert EXPRESS schemas and STEP file to OWL
ontology, not focused on IFC
 Krima et al., 2009 (OntoSTEP)
 Barbau et al., 2012 (OntoSTEP)
• From 2012 onwards, increasing uptake in research and developments
=> many different ifcOWL structures floating around
• Need for formalisation and standardisation
=> combine efforts and proceed in a more formalised, standard fashion
=> role of standardisation bodies: W3C, BuildingSMART
• BuildingSMART Technical Summit March 2015 (London) and October 2015
(Singapore)
we owe our past and present - 2005-2015

3. 1. Short intro to ifcOWL Pieter and Walter +
comparison with Nam’s work
2. Scope: the extended ifcOWL
3. Deciding on ifcOWL open issues
FOCUS for this
presentation
outline

4. SHORT INTRO TO IFCOWL (W&P)

5. Image courtesy: Nam Vu Hoang, Aalto University
conversion procedure / approach Nam

6. DOWNSTREAM
Image courtesy: Nam Vu Hoang, Aalto University
conversion procedure / approach Nam

7. DOWNSTREAM
EXTENDED IFCOWL
Image courtesy: Nam Vu Hoang, Aalto University
conversion procedure / approach Nam

8. DOWNSTREAM
EXTENDED IFCOWL
FILE-BASED CONVERSION RELYING
ON THE IFCOWL ONTOLOGY
Image courtesy: Nam Vu Hoang, Aalto University
conversion procedure / approach Nam

9. conversion procedure EXPRESS schema to OWL
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
-------- owl:ObjectProperty restriction on
ifc:hasSet
-------- indirect subclass of ifc:List
owl:class
-------- owl:unionOf ( owl:classes )
-------- one of ( owl:NamedIndividuals )
owl:class
-------- object properties
-
-
-
-

10. what is included in ifcOWL extended?
Image courtesy: Nam Vu Hoang, Aalto University
EXTENDED IFCOWL
Totally okay with ‘compartmentalization’ or ‘layers’
If it helps industry

11. differences (1)
Image courtesy: Nam Vu Hoang, Aalto University

12. differences (2)
Image courtesy: Nam Vu Hoang, Aalto University
OWL DL focus only
==> everything in there, should be enough

13. differences (3)
Image courtesy: Nam Vu Hoang, Aalto University
Leads to property renaming
==> 1 domain / range for each property

14. differences (4)
Image courtesy: Nam Vu Hoang, Aalto University
Wrap XSD types

15. differences (5)
Image courtesy: Nam Vu Hoang, Aalto University
Subclasses of simple datatypes
or other defined datatypes

16. differences (6)
Image courtesy: Nam Vu Hoang, Aalto University
| Can easily be changed
|
|
|
|
|
|
|

17. Step 2. Simple data types
ifc:REAL
rdf:type owl:Class ;
rdfs:subClassOf
[
rdf:type owl:Restriction ;
owl:allValuesFrom xsd:double ;
owl:onProperty ifc:has_double
] .
ifc:has_double
rdf:type owl:DatatypeProperty ;
rdf:type owl:FunctionalProperty ;
rdfs:label "has_double" ;
rdfs:domain
[
rdf:type owl:Class ;
owl:unionOf ( ifc:REAL )
] ;
rdfs:range xsd:double .
OWL

18. Step 3. Defined data types
IFC
Schema
Simple data type
Defined data type
ifcOWL
Ontology
owl:class + owl:DatatypeProperty restriction
owl:class
TYPE IfcAreaDensityMeasure = REAL;
END_TYPE;
ifc:IfcAreaDensityMeasure
rdf:type owl:Class ;
rdfs:subClassOf ifc:REAL .
EXPRESS
OWL

19. differences (6)
Image courtesy: Nam Vu Hoang, Aalto University

20. differences (7)
Image courtesy: Nam Vu Hoang, Aalto University
MANY OPTIONS HERE – LARGE IMPACT, as all geometric data (90% of IFC) is in
lists ==> huge impact on triple count

21. differences (8)
Image courtesy: Nam Vu Hoang, Aalto University
No policy here => we focused only on EXPRESS to OWL
RDF instances is a whole alternative area. If the Extended OWL Ontology is
followed, one should have enough and naming should not matter too much.

22. SCOPE: THE EXTENDED IFCOWL
VERSION

23. Image courtesy: Nam Vu Hoang, Aalto University
current status
ifcOWL
Walter
ifcOWL
Pieter
= identic. =
~ equiv. ~

24. Image courtesy: Nam Vu Hoang, Aalto University
targeted status
ifcOWL - e
Walter
ifcOWL - e
Pieter
= identic. =
= identic. =
ifcOWL - si
Walter
ifcOWL - si
Pieter
ifcOWL - st
Walter
ifcOWL - st
Pieter
= identic. =
= identic. =
= identic. =
= identic. =
importimport
Minimal aim for LDAC2015

25. DECIDING ON IFCOWL OPEN ISSUES

26. issue 1 - ontology name and provenance

27. issue 2 - URI naming convention
for object properties

28. issue 2 - URI naming convention
for object properties
Name_of_IfcRootName_of_IfcOrganization …Degree

29. issue 2 – alternative 1

30. issue 2 – alternative 1
Name
Name_of_IfcRootName_of_IfcOrganization …Degree

31. issue 2 – alternative 2

32. issue 2 – alternative 2
Name
Name_of_IfcRootName_of_IfcOrganization …Degree_of_IfcBSplineCurve
Degree
STANDARD / SIMPLE
EXTENDED (FULL)

33. issue 2 – alternative 3

34. issue 2 – alternative 3
Name_of_IfcRootName_of_IfcOrganization …Degree_of_IfcBSplineCurve

35. issue 3 - URI naming convention
for individuals in Enumerations
=> Similar to object property renaming, except for the domain and range restrictions
=> Alternatives: use all short names (ENUM individuals belong to multiple classes) or
use all long names ([]_of_[]) (ENUM individuals belong to one class only)

36. RECAP / CONCLUSIONS

37. Parallels in the extended ifcOWL (1)
Image courtesy: Nam Vu Hoang, Aalto University
OWL DL
Wrap XSD types
Subclasses of simple datatypes
or other defined datatypes
|
|
|
|
|
|
|
OWL DL
1
Can we follow the subproperty proposal?

38. Parallels in the extended ifcOWL (2)
Image courtesy: Nam Vu Hoang, Aalto University
MANY OPTIONS HERE – LARGE IMPACT, as all geometric data (90% of IFC) is in
lists ==> huge impact on triple count
Beyond development of an extended ifcOWL

39. Image courtesy: Nam Vu Hoang, Aalto University
explore options for compartmentalisation
ifcOWL - e
Walter
ifcOWL - e
Pieter
= identic. =
= identic. =
ifcOWL - si
Walter
ifcOWL - si
Pieter
ifcOWL - st
Walter
ifcOWL - st
Pieter
= identic. =
= identic. =
= identic. =
= identic. =
importimport
Minimal aim for LDAC2015

40. Thank you
Pieter Pauwels, Ghent University
pipauwel.pauwels@ugent.be
María Poveda Villalón, UPM Madrid
mpoveda@fi.upm.es