A Semantic Web Approach for defining Building Views

AnaROXIN–ana-maria.roxin@u-bourgogne.fr
TracisioMENDESDEFARIAS-tarcisio.mendes-de-farias@u-bourgogne.fr
A Semantic Web Approach
for
Defining Building Views
Tarcisio Mendes de Farias, Ana Roxin and
Christophe Nicolle
Standards Summit – Rotterdam
April 11 - April 14

Agenda
Motivation
• General context presentation
• Model View Definition (MVD)
IFC Dynamic
Views
• Case study: COBieMVD
• Defining user views
Case
studies
• Institut Var
• Medical Clinic
• High-school
April 12th 2016 MVD 2

MOTIVATION

Context and Motivations
buildingSMART
Linked Data
Working Group
(LDWG)
• Towards the definition
of a common ifcOWL
ontology
buildingSMART
community
proposes the
Model View
Definition (MVD)
approach
How to combine
MVD approach and
ifcOWL?

Model View Definition (MVD)
◼ Model View Definitions (MVDs) can be serialized in mvdXML format
 mvdXML 1.0
 mvdXML 1.1 - outcome of the buildingSMART International Project S1015
"Enabling trust in BIM deliveries"
◼ The main drawbacks of such approach for extracting building views
are:
Lack of logical formalisms (e.g. Description logic, Horn-like
rules)
MVD solely considers the IFC schema
An MVD-based view constructor is less flexible and dynamic
when compared with our approach

Scientific Background
◼ Horn-like rules (horn-clauses)
 A rule is composed of a rule head (consequent) and a body
(antecedent).
― p ∧ q ∧ ... ∧ t → u
― ¬p ∨ ¬q ∨ ... ∨ ¬t ∨ u
◼ There are several rule languages available and
implemented in Semantic Web technologies
 SWRL, RIF, F-logic, SPIN , N3-logic…

IFC DYNAMIC VIEWS

Dynamic view process definition
An abstract view can be
pre-defined as a set of
logical rules by using
ifcOWL vocabulary
• Those rules can be stored
with building data and
schema
A concrete view can be
automatically generated
based on rules and the
ifcOWL ontology
(populated)
Users can easily define
rule-based views !

Case study : COBieMVD
◼ COBieOWL: an ontology based on COBie standard

◼ MVD: external data constraints
COBie Table Column Reference
Contact Email IfcActor.Name
Contact CreatedBy
IfcActor.OwnerHistoryIfcOwnerHistory.OwningUser
IfcPersonAndOrganization.ThePersonIfcPerson.Ide
ntification
Contact CreatedOn IfcActor.OwnerHistoryIfcOwnerHistory.CreationDate
Contact Category
IfcActor.HasAssociations[*]IfcRelAssociatesClassifi
cation.RelatingClassificationIfcClassificationRefere
nce.Identification
Contact Company
IfcActor.TheActorIfcPersonAndOrganization.TheOrg
anizationIfcOrganization.Name
Floor Description IfcBuildingStorey.Description
Floor Elevation IfcBuildingStorey.Elevation

◼ MVD data constraints translated into Horn-like rules
 Schema alignment (reducing heterogeneity)
◼ Concept rule-based alignment
Contact ≡ IfcActor
ifcowl:IfcActor(x) → cobieowl:Contact(x)
cobieowl:Contact(x) → ifcowl:IfcActor(x)
Floor ≡ IfcBuildingStorey
ifcowl:IfcBuildingStorey (x) → cobieowl:Floor(x)
cobieowl:Floor(x) → ifcowl:IfcBuildingStorey (x)

◼ Look up the ifcOWL vocabulary (URIs) to produce rules
Column Reference Horn-like Rule based on ifcOWL terms
Email
(Contact)
IfcActor.Name
ifcowl:IfcActor(X) ∧ ifcowl:name_IfcRoot (X, Y) ∧
expr:hasString(Y, Z) → cobieowl:name(X,Z)
CreatedBy
(Contact)
IfcActor.OwnerHistoryIfcOwn
erHistory.OwningUserIfcPers
onAndOrganization.ThePerson
IfcPerson.Identification
ifcowl:IfcActor(X) ∧ ifcowl:ownerHistory… (X, Y) ∧
ifcowl:owningUser…(Y,Z) ∧ ifcowl:thePerson…(Z, K) ∧
ifcowl:identification…(K, L) ∧ expr:hasString(L, M) →
cobieowl:createdBy (X, M)
Company
(Contact)
IfcActor.TheActorIfcPersonAn
dOrganization.TheOrganizatio
nIfcOrganization.Name
ifcowl:IfcActor(X) ∧ ifcowl:theActor… (X, Y) ∧
ifcowl:theOrganization…(Y,Z) ∧ ifcowl:name…(Z, K) ∧
expr:hasString(K, M) →
cobieowl:company (X, M)
Description
(Floor)
IfcBuildingStorey.Description
ifcowl:IfcBuildingStorey(X) ∧ ifcowl:description… (X, Y) ∧
expr:hasString(Y, Z) → cobieowl:description(X,Z)
Elevation
(Floor)
IfcBuildingStorey.Elevation
ifcowl:IfcBuildingStorey(X) ∧ ifcowl:elevation
… (X, Y) ∧ expr:hasDouble(Y, Z) → cobieowl:elevation(X,Z)

◼ The choice of a horn-like rule syntax depends on the semantic graph
database or reasoner
 Stardog: SWRL, Stardog Rules Syntax
 Ontobroker: RIF, ObjectLogic
 EYE reasoner: N3Logic…
◼ Main benefits:
 Formal and logic-based
― Inference engine
 Ease of implementation for COBie MVD
― We only need to import rules in the database
― No needs to code a parser for mvdXML

◼ We can directly use a query language to retrieve COBie data that is
originally described using the IFC model
?x a cobieowl:Contact .
?x cobieowl:email ?email.
?x a ifcowl:IfcActor .
?x ifcowl:name_IfcRoot ?y.
?y expr:hasString ?z
becomes

Defining user views
Abstract views
• Pre-defined, stored and
exchanged
Concrete views
• Built from IFC data
• Using abstract view
definitions (i.e. rules).
Easily configurable
• Set of concepts (C)
• Set of GUIDs (G)
• Set of IFC relationships (R)
A rule-based system to construct
building views

User view definition

SCM example
#6=IFCPROPERTYSINGLEVALUE('IsExternal',$,IFCBOOLEAN(.T.),$);
#4=IFCPROPERTYSET('2pW3mRfBr7EwHldYmKP$PD',#33,'Pset_WindowCommon',$,(#1,#6));
#2=IFCRELDEFINESBYPROPERTIES('2yVDnLFbzAzx6B70P6n3aU',#33,$,$,(#1),#4);
#1=IFCWINDOW('1BYB9o9k5FZAAI8V0ct4P4',#33,'BK_tower_window:BK_tower_window:BK_tower_windo
w:145729',$,'BK_tower_window',#90910,#90904,'145729',2200.000000000015,1200.000000000011);

Defining a building envelope view
Horn-like rules
• Specify which
elements are
part of the view
Horn-like rules
• Definition of new
concepts
pertaining to the
considered view
Horn-like rules
• Map the newly
defined
concepts to the
view
ifcowl:IfcObject(X1) ∧ ifcowl:IfcRelDefines(X2) ∧ ifcowl:relatedObjects…(X2 , X1) ∧
ifcowl:relatingPropertyDefinition… (X2 , X3) ∧ ifcowl:IfcPropertySet(X3) → :hasPropertySet(X1 ,X3)
aei:hasPropertySet(X1 , X2) ∧ ifcowl:hasProperties… (X2 , X3) ∧ ifcowl:IfcProperty(X3) → :hasProperty(X1 , X3)
aei:hasProperty(X1 , X3) ∧ ifcowl:name_IfcProperty(X3, X4) ∧ expr:hasString(X4 , "IsExternal”) ∧
ifcowl:nominalValue… (X3, X5) ∧ expr:hasBoolean(X5 , X6)→ :isExternal(X1 , X6)
aei:isExternal(X , true) ∧ ifcowl:IfcWall(X) → :ExternalWall(X)
aei:isExternal(X , true) ∧ ifcowl:IfcDoor(X) → :ExternalDoor(X)
aei:isExternal(X , true) ∧ ifcowl:IfcWindow(X) → :ExternalWindow(X)
:ExternalDoor(X) → :BuildingEnvelope(X)
:ExternalWall(X) → :BuildingEnvelope(X)
:ExternalWindow(X) → :BuildingEnvelope(X)
For simplicity's sake, we consider as a building
envelope all external doors, windows and walls

APPLICATION CASE STUDIES

The Duplex building project
◼ It was produced in Weimar Germany for a design competition

Export phase inputs
C = {BuildingEnvelope}
G = { }
R = { IfcRelDecomposes, IfcRelContainedInSpatialStructure,
IfcRelVoidsElement, IfcRelFillsElement, IfcRelDefinesByProperties }.

Additional case studies
Institute Var Medical clinic High-school

Project: Institute Var
File sizes Original SPF file : 6 MB
Generated TTL file (with all original ˆdata): 35 MB
Building
view
Format: STEP Physical file
Query: All building doors
SPF size : 2.11 MB
C = {IfcDoor}
R = { IfcRelDecomposes,
IfcRelContainedInSpatialStructure,
IfcRelVoidsElement, IfcRelFillsElement,
IfcRelDefinesByProperties }.

Project: Medical clinic
Building
view
Query: All building doors and windows
SPF size : 1.64 MB
C = {IfcDoor, IfcWindow}
R = { IfcRelDecomposes,
IfcRelVoidsElement,
IfcRelFillsElement,
IfcRelDefinesByProperties }

Project: High-school
Building
view
Query: All building doors and stairs
SPF size : 21.5 MB
C = {IfcDoor, IfcStair}
R = {IfcRelDecomposes,
IfcRel-VoidsElement,
IfcRelFillsElement,
IfcRelDefinesByProperties }

Conclusions
Benefits of MVD by using
Web semantic technologies
Less or no code needed
Storage of abstract view along with data
and schema
Users can easily define building views:
•GUIDs, IFC concepts or personalized concepts (rules)
Benefits of semantic web
rule syntax
Automatic generation of concrete views
Easier exchange and implementation of
abstract views
No needs to develop a parser for mvdXML
Everything is already coded in the semantic
graph database

Thank you for your attention.
Tarcisio Mendes de Farias –
tarcisio.mendesdefarias@checksem.fr
Ana Roxin – ana-maria.roxin@u-bourgogne.fr

COBieOWL
Tarcisio Mendes de Farias, Ana Roxin and
Christophe Nicolle
Standards Summit – Rotterdam
April 11 - April 14

Agenda
Context
• Building lifecycle
• Building Information Modeling
• COBie standard
Related
work
• Adapting BIM standards to OWL
• Converting spreadsheets into OWL
Approach
• Conception of COBieOWL
• Extending and populating the COBieOWL ontology
Benefits
• Addressing SPARQL queries over COBieOWL
• Inferring new information
• Enriching the COBie model
• Integration with the Linking Open Data (LOD) cloud

GENERAL CONTEXT
Building lifecycle
Building Information Modeling
COBie standard

Building Lifecycle
Managing
Phase
Constructors
Project
Phase
ContractorContractor
Sub contractors
Restructuring
Phase
Study
Phase
Project Manager

Building Management
Managing
Phase
Constructors
Project Phase
ContractorContractor
Sub contractors
Restructuration
Phase
Study
Phase
Project Manager
Maintenance
Audit and Inventory
Human resources
Contracts
(Security, maintenance…)
Financial management
(leasing, sales, tax, maintenance, insurance…)
Legislation, norms…
Real estate management
Relocation
Environmental impact

Building Information Modeling (BIM)
◼ Latest approach for bridging interoperability gaps
among current systems in the AEC/FM
◼ IFC (Industry Foundation Classes)
 First BIM standard, in 1999 by buildingSMART
 Exchange of 3D building models
 Object oriented model
BIMApril 12th 2016 MVD 33

COBie standard
◼ Construction-Operations Building information exchange
◼ Created under the National Institute of Building Sciences (NIBS)
Facility Maintenance and Operations Committee
◼ For contractors, builders, designers and facility managers
◼ Novel method for sharing data during building life-cycle:
 Spreadsheet-based, no geometric/3D data
 Can be used on all building projects regardless of size and
technological complexity
 One COBie file per building project
General information about the COBie version and data
Yellow if required Green if specified as required

COBie deliverables
Early design
phase
• Sheet: Project,
site and facility
• Floor: Vertical
levels and
exterior areas
• Space: Spaces
• Zone: Sets of
spaces sharing
a specific
attribute
• Type: Types of
equipment,
products, and
materials
Detailed design
phase
• Component:
Individually
named or
schedule items
• System: Sets of
components
providing a
service
• Assembly:
Constituents for
types,
components
and others
• Connection:
Logical
connections
between
components
• Impact:
Economic,
environmental
and social
impacts at
various stages
in the life cycle
Construction
phase
• Document:
Inclusion of
submission and
approval
documents
• Type: Insertion
of manufacturer
and model
information
• Component:
Inclusion of
serial and tag
data
Facility
Management
phase
• Spare: Onsite
and
replacement
parts
• Resource:
Required
materials, tools,
and training
• Job: PM, safety,
and other job
plans
All Phases
• Document: All
applicable
document
references
• Attribute:
Properties of
referenced item
• Coordinate:
Spatial
locations in box,
line, or point
format
• Issue: Other
issues
remaining at
handover.
• Contact: People
and companies

COBie Data validation rules
◼ For referencing data present in other columns
Allowed values can be in form of a list, and must be also
present in the column Email from the Contact sheet.

OWL-based ontology
Decidable
Formal
DL-based
Problems with existing standards
Semantic heterogeneity
No logic
No
semantics
Static
formats
Use OWL for representing the
COBie standard = COBieOWL

RELATED WORK
Adapting BIM standards to OWL
Converting spreadsheets into OWL

Current approaches
• Adapting IFC into OWL [1]
• For leveraging all modelling constraints required by the object-oriented structure
of the IFC schema
• Integration with the LOD cloud - IfcWOD
Adapting BIM standards to OWL
• Connor et al. [2] “Mapping Master: a Flexible Approach for Mapping Spreadsheets to
OWL »
• Mapping language M² for generating OWL ontologies
• Bowers et al. [3] “Owlifier: Creating OWL-DL ontologies from simple spreadsheet-
based knowledge descriptions”
• Rules for creating, relating, and constraining concepts through spreadsheets
• Software-based conversion into OWL-DL ontologies
• Jupp et al. [4] “Populous: A tool for populating Templates for OWL ontologies”
• Ontology population from table-based forms
Converting spreadsheets into OWL
[1] De Farias, T.M., Roxin, A., Nicolle, C.: IfcWoD, Semantically Adapting IFC Model Rela-tions into OWL Properties. Proceedings of the
32nd CIB W78 Conference on Information Technology in Construction, Oct 2015, Eindhoven, Netherlands
[2] O’Connor, M. J., Halaschek-Wiener, C. and Musen, M. A.: Mapping Master: A flexible approach for mapping spreadsheets to OWL. In
The Semantic Web–ISWC 2010 (pp. 194-208). Springer Berlin Heidelberg (2010).
[3] Bowers, S., Madin, J. S., & Schildhauer, M. P.: Owlifier: Creating OWL-DL ontologies from simple spreadsheet-based knowledge
descriptions. Ecological Informatics, 5(1), 19-25 (2010).
[4] Jupp, S., Horridge, M., Iannone, L., Klein, J., Owen, S., Schanstra, J., Stevens, R. and Wolstencroft, K.: Populous: A Tool for Populating
Templates for OWL Ontologies. In SWAT4LS. (2010)

Lacks of the current approaches
Current approaches
• Use a mapping language:
• Each new version of
COBie standard implies
an update of the
mapping ensemble.
• Users need to learn the
mapping language
• Go against COBie’s initial
aim – avoiding additional
training
• Do not consider COBie
column color codes
Our approach
• Make use of the
spreadsheet data
validation functionality
for stating restriction
axioms and object
properties in the
ontology.
• Take column color codes
into consideration.

OUR APPROACH
Conception of COBieOWL
Extending and populating the COBieOWL ontology

Our contributions
• Each sheet from the COBie 2.4 template is
mapped as an OWL class.
• Columns from sheets are mapped as
OWL properties.
• Cells from each sheet are mapped as
property values.
Semi-automatic
conception of
the COBieOWL
ontology, based
on conversion
rules:
• Java-based COBieOWL generator
• Relies on Apache POI API (for handling
spreadsheets) and on OWL API
Method for
automatic
population of
COBieOWL

A portion of COBieOWL ontology
∀ 𝐶 ∈ 𝐶𝑂𝐵𝑖𝑒 𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒 𝑠ℎ𝑒𝑒𝑡 , 𝐶 ⊑ 𝐶𝑜𝑏𝑖𝑒𝑆ℎ𝑒𝑒𝑡 where 𝐶𝑜𝑏𝑖𝑒𝑆ℎ𝑒𝑒𝑡 ⊑ ⊤

COBie 2.4
template
OWL
Axioms
Example
Column that
points to
another
column
using “Data
Validation”
rule.
Functional
Object
Property
All COBie sheets, CreatedBy column has values from the
Email column from the Contact sheet.
cobie:createdBy = OWL object property with cobie:Contact as
its range
𝐶𝑜𝑛𝑡𝑎𝑐𝑡 ⊑ ⊤
⊤ ⊑ ∀𝑐𝑟𝑒𝑎𝑡𝑒𝑑𝐵𝑦. 𝐶𝑜𝑛𝑡𝑎𝑐𝑡
∃𝑐𝑟𝑒𝑎𝑡𝑒𝑑𝐵𝑦. ⊤ ⊑ 𝐶𝑜𝑏𝑖𝑒𝑠ℎ𝑒𝑒𝑡
Column that
points to
other sheet
rows using
cell values
separated
by commas.
Non-
functional
Object
Property
Contact sheet, ResourceNames column has values defined in
the Name column from the Resource sheet.
cobie:resourceNames = OWL non-functional property with
values from cobie:Resource
𝐽𝑜𝑏 ⊑ ⊤
𝑅𝑒𝑠𝑜𝑢𝑟𝑐𝑒 ⊑ ⊤
⊤ ⊑ ∀𝑟𝑒𝑠𝑜𝑢𝑟𝑐𝑒𝑁𝑎𝑚𝑒𝑠. 𝑅𝑒𝑠𝑜𝑢𝑟𝑐𝑒
∃𝑟𝑒𝑠𝑜𝑢𝑟𝑐𝑒𝑁𝑎𝑚𝑒𝑠. ⊤ ⊑ 𝐽𝑜𝑏
Specific Column Mapping Rules (1)

COBie 2.4
template
OWL
Axioms
Example
Columns
with values
from a
PickList
sheet
OWL
datatype
property with
values from
an OWL
enumeration
(owl:oneOf)
Category column in the Zone sheet takes values from the
ZoneType column
𝑍𝑜𝑛𝑒 ⊑ ∀𝑐𝑎𝑡𝑒𝑔𝑜𝑟𝑦. 𝑍𝑂𝑁𝐸𝑇𝑌𝑃𝐸
𝑍𝑂𝑁𝐸𝑇𝑌𝑃𝐸
≡ {𝐶𝑖𝑟𝑐𝑢𝑙𝑎𝑡𝑖𝑜𝑛 𝑍𝑜𝑛𝑒} ⊔ {𝐹𝑖𝑟𝑒 𝐴𝑙𝑎𝑟𝑚 𝑍𝑜𝑛𝑒} ⊔ …
⊔ {𝑉𝑒𝑛𝑡𝑖𝑙𝑎𝑡𝑖𝑜𝑛 𝑍𝑜𝑛𝑒}).
Column
with values
from
PickList
sheet with a
cardinality ≤
threshold t.
Functional
Datatype
Property
Category column, threshold t = 16
1) In Type sheet, it has values from CategoryProduct column
(about 6900)  values become instances of
cobie:CategoryProduct class.
∀𝑐𝑎𝑡𝑒𝑔𝑜𝑟𝑦. 𝐶𝑎𝑡𝑒𝑔𝑜𝑟𝑦𝑃𝑟𝑜𝑑𝑢𝑐𝑡
𝑠𝑢𝑝𝑒𝑟𝑐𝑙𝑎𝑠𝑠 𝑜𝑓 𝑐𝑜𝑏𝑖𝑒: 𝑇𝑦𝑝𝑒
2) In Floor sheet, it has values from PickList sheet (less than
16)
⊤ ⊑ ∀𝑐𝑎𝑡𝑒𝑔𝑜𝑟𝑦𝐷𝑎𝑡𝑎𝑡𝑦𝑝𝑒. 𝑥𝑠𝑑: 𝑠𝑡𝑟𝑖𝑛𝑔
𝐹𝑙𝑜𝑜𝑟
⊑ ∀𝑐𝑎𝑡𝑒𝑔𝑜𝑟𝑦𝐷𝑎𝑡𝑎𝑡𝑦𝑝𝑒. ({𝐹𝑙𝑜𝑜𝑟} ⊔ {𝑅𝑜𝑜𝑓 } ⊔ {𝑆𝑖𝑡𝑒}).

COBie 2.4
template
OWL
Axioms
Example
Required
Columns
(yellow)
Existential
restriction
𝐶𝑜𝑏𝑖𝑒𝑆ℎ𝑒𝑒𝑡 ⊑ ∃𝑐𝑟𝑒𝑎𝑡𝑒𝑑𝐵𝑦. 𝐶𝑜𝑛𝑡𝑎𝑐𝑡
𝐷𝑜𝑐𝑢𝑚𝑒𝑛𝑡 ⊑ ∃𝑛𝑎𝑚𝑒. 𝑥𝑠𝑑: 𝑠𝑡𝑟𝑖𝑛𝑔
Range definition for those properties is done via subsumption,
when it depends on their domain class:
∃𝑐𝑎𝑡𝑒𝑔𝑜𝑟𝑦. ⊤
⊑ 𝐶𝑜𝑛𝑡𝑎𝑐𝑡 ⊔ 𝐷𝑜𝑐𝑢𝑚𝑒𝑛𝑡 ⊔ 𝑇𝑦𝑝𝑒 ⊔ ⋯ ⊔ 𝐹𝑎𝑐𝑖𝑙𝑖𝑡𝑦 )
𝐶𝑜𝑛𝑡𝑎𝑐𝑡 ⊑ ∀𝑐𝑎𝑡𝑒𝑔𝑜𝑟𝑦. 𝐶𝑎𝑡𝑒𝑔𝑜𝑟𝑦𝑅𝑜𝑙𝑒
𝐷𝑜𝑐𝑢𝑚𝑒𝑛𝑡 ⊑ ∀𝑐𝑎𝑡𝑒𝑔𝑜𝑟𝑦. 𝐷𝑜𝑐𝑢𝑚𝑒𝑛𝑡𝑇𝑦𝑝𝑒
𝐹𝑎𝑐𝑖𝑙𝑖𝑡𝑦 ⊑ ∀𝑐𝑎𝑡𝑒𝑔𝑜𝑟𝑦. 𝐶𝑎𝑡𝑒𝑔𝑜𝑟𝑦𝐹𝑎𝑐𝑖𝑙𝑖𝑡𝑦
Other COBie
Columns
Functional
Datatype
Property
Property range missing in COBie template, we use COBie
Responsibility Matrix as an input for COBieOWL generator:
⊤ ⊑ ∀𝑐𝑜𝑜𝑟𝑑𝑖𝑛𝑎𝑡𝑒𝑋𝐴𝑥𝑖𝑠. 𝑥𝑠𝑑: 𝑑𝑜𝑢𝑏𝑙𝑒
⊤ ⊑ ∀𝑐𝑜𝑙𝑜𝑟. 𝑥𝑠𝑑: 𝑠𝑡𝑟𝑖𝑛𝑔
⊤ ⊑ ∀𝑐𝑟𝑒𝑎𝑡𝑒𝑑𝑂𝑛. 𝑥𝑠𝑑: 𝑖𝑛𝑡𝑒𝑔𝑒𝑟

COBieOWL TBox
Item Value
Classes 30
Object properties 32
Datatype properties 125
Individuals (PickList) 9418
Inverse properties 7
DL expressiveness ALCHIF(D)

Extending COBieOWL (1)
◼ Minor modeling problems solved manually
 Turtle version of COBieOWL imported into Protégé
 E.g. range of cobie:coordinateXAxis to xsd:double instead of xsd:string

Extending COBieOWL (2)
◼ Sheets with columns that point to rows in other sheets
 Identify all sheets having 2 columns with references to rows in other
sheets
 Definition of a new OWL object property [sheet name]To:
― Range: cobie:CobieSheet
– [𝑠ℎ𝑒𝑒𝑡 𝑛𝑎𝑚𝑒] ⊑ ⊤
– ⊤ ⊑ ∀[𝑠ℎ𝑒𝑒𝑡 𝑛𝑎𝑚𝑒]𝑇𝑜. 𝐶𝑜𝑏𝑖𝑒𝑆ℎ𝑒𝑒𝑡
– ∃[𝑠ℎ𝑒𝑒𝑡 𝑛𝑎𝑚𝑒]𝑇𝑜. ⊤ ⊑ [𝑠ℎ𝑒𝑒𝑡 𝑛𝑎𝑚𝑒]
― Domain: OWL class corresponding to the identified sheet
 Definition of respective inverse properties
― 𝑐𝑜𝑏𝑖𝑒: [𝑠ℎ𝑒𝑒𝑡 𝑛𝑎𝑚𝑒]𝑇𝑜
― 𝑐𝑜𝑏𝑖𝑒: ℎ𝑎𝑠[𝑠ℎ𝑒𝑒𝑡 𝑛𝑎𝑚𝑒]

Extending COBieOWL – example
Document sheet
Type sheet
∃𝒅𝒐𝒄𝒖𝒎𝒆𝒏𝒕𝑻𝒐. ⊤ ⊑ 𝐷𝑜𝑐𝑢𝑚𝑒𝑛𝑡
𝐷𝑜𝑐𝑢𝑚𝑒𝑛𝑡 ⊑ ⊤ ,
⊤ ⊑ ∀𝑑𝑜𝑐𝑢𝑚𝑒𝑛𝑡𝑇𝑜. 𝐶𝑜𝑏𝑖𝑒𝑆ℎ𝑒𝑒𝑡
ℎ𝑎𝑠𝐷𝑜𝑐𝑢𝑚𝑒𝑛𝑡 ≡ 𝑑𝑜𝑐𝑢𝑚𝑒𝑛𝑡𝑇𝑜−

BENEFITS OF COBIEOWL
Addressing SPARQL queries over COBieOWL
Inferring new information
Enriching the COBie model
Integration with the Linking Open Data (LOD) cloud

SPARQL queries over COBieOWL
◼ Extraction of sub-graphs of COBieOWL
◼ Return all building information as created by a given user
CONSTRUCT{
?x X3 ?o } WHERE {
?y a cobie:Contact.
?y cobie:email <mailto:user1@email.com>.
?x cobie:createdBy ?y.
?x X3 ?o }.

Inferring new information
◼ By applying a DL reasoner over a KB
 Backward-chaining reasoner as implemented in Stardog
◼ Object property cobie:hasDocument that is stated as an inverse
property of cobie:documentTo
 Automatic inference of new assertions regarding cobie:hasDocument property
 Based on explicitly asserted cobie:documentTo properties
 And vice-versa
Assertions:
cobie:documentTo(doc1,type1)
cobie:hasDocument(type2, doc2)
Inferences:
cobie:documentTo(type2,doc2)
cobie:hasDocument(type1, doc1),
(type1, type2 instances of cobie:Type)
(doc1, doc2 instances of cobie:Document)

Defining new concepts
◼ By using SWRL rules and swrlb built-ins
 For specifying additional information concerning elements of the TBox
◼ Definition of the cobie:Window concept
 Allows a mapping to the same concept in other ontologies (e.g. IfcWOD)
𝑐𝑜𝑏𝑖𝑒: 𝐶𝑜𝑚𝑝𝑜𝑛𝑒𝑛𝑡(? 𝑥) ∧ 𝑐𝑜𝑏𝑖𝑒: 𝑛𝑎𝑚𝑒(? 𝑥, ? 𝑦)
∧ 𝑠𝑤𝑟𝑙𝑏: 𝑐𝑜𝑛𝑡𝑎𝑖𝑛𝑠𝐼𝑔𝑛𝑜𝑟𝑒𝐶𝑎𝑠𝑒(? 𝑦, "𝑤𝑖𝑛𝑑𝑜𝑤" )
⟶ 𝑐𝑜𝑏𝑖𝑒: 𝑊𝑖𝑛𝑑𝑜𝑤(? 𝑥)

Integration with the LOD cloud
◼ Links to well-known LOD vocabularies for automatic enrichment of
COBieOWL
◼ FOAF (Firend-Of-A-Friend)
 Remove existential restrictions for cobie:Contact
 Assert the axioms :
◼ Dbpedia
 cobie:hasDBpedia datatype property containing the URI identifying a
resource on Dbpedia
― Domain: cobie:CobieSheet
― 𝑐𝑜𝑏𝑖𝑒: ℎ𝑎𝑠𝐷𝐵𝑝𝑒𝑑𝑖𝑎(: 𝐶𝑎𝑝𝑖𝑡𝑎𝑙_𝑇𝑜𝑤𝑒𝑟, 𝑑𝑏𝑝𝑒𝑑𝑖𝑎: 𝐶𝑎𝑝𝑖𝑡𝑎𝑙_𝑇𝑜𝑤𝑒𝑟_(𝑆𝑖𝑛𝑔𝑎𝑝𝑜𝑟𝑒) ) .
𝑐𝑜𝑏𝑖𝑒: 𝐶𝑜𝑛𝑡𝑎𝑐𝑡 ≡ 𝑓𝑜𝑎𝑓: 𝐴𝑔𝑒𝑛𝑡
∃𝑐𝑜𝑏𝑖𝑒: 𝑔𝑖𝑣𝑒𝑛𝑁𝑎𝑚𝑒. ⊤ ⊑ 𝑓𝑜𝑎𝑓: 𝑃𝑒𝑟𝑠𝑜𝑛
∃𝑐𝑜𝑏𝑖𝑒: 𝑓𝑎𝑚𝑖𝑙𝑦𝑁𝑎𝑚𝑒. ⊤ ⊑ 𝑓𝑜𝑎𝑓: 𝑃𝑒𝑟𝑠𝑜𝑛
𝑐𝑜𝑏𝑖𝑒: 𝑔𝑖𝑣𝑒𝑛𝑁𝑎𝑚𝑒 ≡ 𝑓𝑜𝑎𝑓: 𝑔𝑖𝑣𝑒𝑛𝑁𝑎𝑚𝑒
𝑐𝑜𝑏𝑖𝑒: 𝑓𝑎𝑚𝑖𝑙𝑦𝑁𝑎𝑚𝑒 ≡ 𝑓𝑜𝑎𝑓: 𝑓𝑎𝑚𝑖𝑙𝑦𝑁𝑎𝑚𝑒
𝑐𝑜𝑏𝑖𝑒: 𝑒𝑚𝑎𝑖𝑙 ≡ 𝑓𝑜𝑎𝑓: 𝑚𝑏𝑜𝑥

Conclusions
• COBieOWL ontology for the COBie standard
• Reduction of semantic heterogeneity
• Enrichment of building models
• Possible to address complex queries
• Integration in the LOD cloud
• Augmentation of data interoperability
Conclusions
• Aligning COBieOWL with other standards
• IfcWOD, OWL version of CityGML
• Address queries in natural language over such ontologies
Future works

Thank you for your attention
Tarcisio Mendes de Farias – tarcisio.mendesdefarias@checksem.fr
Ana Roxin – ana-maria.roxin@u-bourgogne.fr

A Semantic Web Approach for defining Building Views

More Related Content

Viewers also liked (13)

Similar to A Semantic Web Approach for defining Building Views (20)

More from Ana Roxin (13)

Recently uploaded (20)

A Semantic Web Approach for defining Building Views