optimised design methodologies for...

This project has received funding from the European Union Seventh Framework Programme

under grant agreement n° 609349.

OPTIMISED DESIGN METHODOLOGIES FOR ENERGY-EFFICIENT

BUILDINGS INTEGRATED IN THE NEIGHBOURHOOD ENERGY SYSTEMS

eeEmbedded

D5.2 Interoperability System

Responsible Authors:

Pit Stenzel & Mathias Kadolsky

Co-Authors:

Romy Guruz, Arne Ton, Klaus Linhard, Amrita Sukumar,

Tuomas Laine, Peter Katranuschkov, Raimar Scherer

Due date: 31.12.2015

Issue date: 31.05.2016

Nature: Prototype

Coordinator: R. J. Scherer, Institute for Construction Informatics, Technische Universität Dresden, Germany

D5.2

Interoperability System

Version 0.1

/59

© eeEmbedded Consortium www.eeEmbedded.eu

Start date of project: 01.10.2013 Duration: 48 months

Organisation name of lead contractor for this deliverable:

Fraunhofer Gesellschaft zur Foerderung der angewandten Forschung e.V. (EAS)

History

Version Description Lead Author Date

0.1 Initial document and draft deliverable structure

Pit Stenzel (EAS) 09.04.2015

0.2 Input document structure Mathias Kadolsky (CIB) 14.12.2015

0.3 Revision document structure Input Interoperability of Domain Models


0.4 Input Exchange Requirements and Multi-Model View Definition


0.5 Revision document structure Input Link Ontology Concept

Pit Stenzel (EAS), Mathias Kadolsky (CIB)

17.03.2016

Review document and comments Input Link Ontology approach

Mathias Kadolsky (CIB), Romy Guruz (CIB), Peter Katranuschkov (CIB)

25.04.2016

0.7 Input Domain Model Interoperability Pit Stenzel (EAS) 27.05.2016

0.8 Pre-Final Version Pit Stenzel (EAS), Mathias Kadolsky (CIB)

29.05.2016

0.9 Final Version Pit Stenzel (EAS), Mathias Kadolsky (CIB)

30.05.2016

1.0 Checked and approved by Coordinator CIB 31.05.2016

Copyright

This report is © eeEmbedded Consortium 2015. Its duplication is restricted to the personal use

within the consortium, the funding agency and the project reviewers. Its duplication is allowed

in its integral form only for anyone's personal use for the purposes of research or education.

Citation

Stenzel, P. & Kadolsky, M. (2016); eeEmbedded D5.2: Interoperability System, © eeEmbedded Consortium, Brussels.

Acknowledgements

The work presented in this document has been conducted in the context of the seventh framework

programme of the European community project eeEmbedded (n° 609349). eeEmbedded is a 48

month project that started in October 2013 and is funded by the European Commission as well as by

the industrial partners. Their support is gratefully appreciated. The partners in the project are

Technische Universität Dresden (Germany), Fraunhofer-Gesellschaft zur Förderung der angewandten

Forschung E.V (Germany), NEMETSCHEK Slovensko, S.R.O. (Slovakia), Data Design System ASA

(Norway), RIB Information Technologies AG (Germany), Jotne EPM Technology AS (Norway),

Granlund OY (Finland), SOFISTIK HELLAS AE (Greece), Institute for applied Building Informatics IABI

(Germany), FR. SAUTER AG (Switzerland), , Obermeyer Planen + Beraten (Germany), Centro de

Estudios Materiales y Control de Obras S.A. (Spain), STRABAG AG (Austria) and Koninklijke BAM

Group NV (The Netherlands). This report owes to a collaborative effort of the above organizations.

Project of SEVENTH FRAMEWORK PROGRAMME OF THE EUROPEAN COMMUNITY

D5.2


Version 0.1

/59


Dissemination Level

PU Public X

PP Restricted to other programme participants (including the Commission Services)

RE Restricted to a group specified by the consortium (including the Commission Services)

CO Confidential, only for members of the consortium (including the Commission Services)

D5.2


Version 0.1

/59


Abbreviations

BACS Building Automation and Control Systems

BIM Building Information Modelling

CFD Computational Fluid Dynamics

DV Decision Values

eeBIM Energy-enhanced BIM

eeeBIM Energy-enhanced embedded BIM

eeE eeEmbedded – EU project Optimised Design Methodologies For Energy-Efficient Buildings Integrated In The Neighbourhood Energy Systems

ESIM Energy System Information Model

FM Facility Management

HESMOS Holistic Energy Efficiency Simulation and Life Cycle Management of Public Use Facilities (EU research project, 2010-2013)

HVAC Heating Ventilation and Control Systems

IDM Information Delivery Manual

IFC Industry Foundation Classes

KPI Key Performance Indicators

LCA Life Cycle Assessment

LCC Life Cycle Costing

LEED Leadership in Energy and Environmental Design

LOD Level of development

LoD Level of Detail

LoA Level of Approximations

MCDA Multi-Criteria Decision Analysis

MM Multi-Model

MMC Multi-Model Container

(M)MVD (Multi)-Model View Definition

SOA Service Oriented Architecture

UC Use Case

VDL Virtual Design Laboratory

D5.2


Version 0.1

/59


Table of Content

Executive Summary ________________________________________________________________ 6

1 Introduction __________________________________________________________________ 7

2 The Usage of Ontology-Based Interoperability _______________________________________ 9

2.1 State of the Art Interoperability Concepts ________________________________________ 9

2.2 Link Ontology in the eeE Use Cases _____________________________________________ 11

2.3 Role of the Link Ontology in the eeE Ontology Framework __________________________ 14

2.4 Link Ontology addressed to the Ontology Platform ________________________________ 15

3 Domain Models in the eeE Design Process _________________________________________ 17

3.1 Simple district test case ______________________________________________________ 17

3.2 Domain Models ____________________________________________________________ 18

3.3 Design phase and level of detail _______________________________________________ 21

4 Link Ontology in the eeE Design Process ___________________________________________ 23

4.1 Benefits of the Link Model Ontology____________________________________________ 23

4.2 Process and task related Multi-Models __________________________________________ 24

5 Link ontology approach ________________________________________________________ 30

5.1 Link Model Idea ____________________________________________________________ 30

5.2 Link Type Definition _________________________________________________________ 32

5.3 Key Link Object Sets ________________________________________________________ 35

5.4 Transforming content of an ontology model to the content of a relational data model ____ 40

5.5 Task-specific linking _________________________________________________________ 40

6 Link Ontology Application ______________________________________________________ 42

7 Exchange Requirement and Key Point integration ___________________________________ 46

7.1 eeE Model View Definition Methodology ________________________________________ 46

7.2 eeE Multi-Model View Definition Methodology ___________________________________ 49

8 Ontology API ________________________________________________________________ 51

9 Conclusions and outlook _______________________________________________________ 56

References ______________________________________________________________________ 58

D5.2


Version 0.1

/59


Executive Summary

The objective of the Deliverable 5.2 "Interoperability System" is to describe the concept of the

ontology-based interoperability system, which facilitates the integration of various heterogeneous

data sources and to ensure the semantic interoperability among domain models, design phases and

Level of Detail (LoD).

The deliverable D5.2 is successor of D5.1 and connected with D4.1 “BIM Multi-Model, D4.2 “Energy

System Information Model“ and D4.3 “Link Model”. It is structured into 9 Chapters:

In Chapter 1 the intention of D5.2 “Interoperability System” is motivated.

The concept of the ontology-based interoperability is presented in Chapter 2. This includes the state

of the art of interoperability concepts. Different approaches, e.g. Link Model (LM) and Multi-Model

Container (MMC) as well as different link interdependencies will be presented and analysed. Further

the relation of the envisaged Link Ontology in the eeE design process and the role in the eeE

Ontology Platform will be addressed.

In Chapter 3 the interoperability between different heterogeneous domain models, design phases

and levels of detail (LoD) will be presented.

The utilization of the Link Ontology within the eeE Design Process will be described Chapter 4.

Through a gap analysis of the existing Multi-Model Container the requirements for the Link Model

Ontology have been elaborated. The basic interoperability models (Multi-Models) is elaborated on

task-level.

The Link Ontology Approach is specified based on the identified gaps and requirements in Chapter 5.

A Link Type Definition for Element Links and Models Links as well as detailed sets of key link objects

are defined in this Chapter.

Different uses cases and applications of the Link Ontology, like ontology access, matching tables,

error handling as well as Exchange Requirements (ER) and Multi-Model View Definition (MMVD)

checking are described in Chapter 6.

The eeE design process is characterized by so called Key Points (KP) checks. These KP checks include

among others checking of Exchange Requirements (ER) and Multi-Model View Definitions (MMVD).

In Chapter 7 an overview of eeE MVD and eeE MMVD specification methodology is presented.

Chapter 8 describes the ontology API within eeEmbedded with the purpose (1) to enable storing,

retrieving and use of the Link Ontology data, and (2) to provide other services on the eeE platform

with the capability to access the ontology management (OMS) and ontology verification services

(OVS).

A conclusion and a brief outlook to following tasks is given in Chapter 9.

All partners were involved and each partner has contributed from their expert viewpoint as follows:

EAS: Lead/ First Author

CIB: First Author

All Partners: Input via discussions.

D5.2


Version 0.1

/59


1 Introduction

Information come from different domains and have to be combined creating an overall information

basis and providing the input for the envisaged external simulation tools and their related simulation

models. This combined information stored in link models is task specific and in the most cases the

link models differ only slightly regarding the usage of different simulation software. So, embedding

link models and relating quality checks in a context and making them available for a restricted group

or even for unrestricted use will lead to more reliability.

Next to reliability the generation of such link models should be transparent and easy to realize. So,

the overall link concept will be based on a two layer approach, an application layer formed by a

relational data concept allowing an easy creation of links and an information layer formed by an

ontology concept providing complex rule inferencing and based on the open world character of

ontologies an increased information exchange and reliability. The relational data model approach

describes the current linking situation in tabular form. The ontology stores this information in an

overall process concept providing the envisaged reliability.

The interoperability model of the domain models will be developed. It will be based on the link

model, the link model relation types will be further detailed and the set of key objects in each

model will be identified, which are interoperability link points for each model. These sets of key

objects should be minimal in order to keep the interoperability model reasonably small. Therefore,

the key objects should be as generic (abstract) as possible. Appropriate inheritance methods will be

developed to support automated identification of the right objects in each particular context. This

needs knowledge encapsulated in rules and an inference mechanism, which is part of the link

ontology model.

The interoperability model of the design phases and the levels of detail are very similar on the

abstract level to the interoperability of the domain models. The interoperability of the design phases

and the LoD are strongly inter-related and depend on the design process (activity), which has to be

taken into consideration. The same holds for the construction process and the FM, which have to be

considered through simulation. Hence, the inter-relationship between operation phases and LoD

interoperability has to be considered as well, and in addition, interoperability to the design phase has

to be provided, where the simulation is done. This results in non-trivial interoperability methods,

beyond the technical interoperability captured by straightforward link relations. Therefore, a

considerable part of the work will be dedicated to the development of cross link model

interoperability, which means in particular the cross interoperability of key object sets and the

related rules and restrictions.

D5.2


Version 0.1

/59


Figure 1: Interoperability System

D5.2


Version 0.1

/59


2 The Usage of Ontology-Based Interoperability

In this section the envisaged usage of the ontology-based interoperability in the design phases will be

described. First a short overview of interoperability concept will be presented with focus on multi

model and link model use. After this the use of the eeE link model in the design phases will be

described based on in D2.3 & D8.1.

2.1 State of the Art Interoperability Concepts

The interoperability models facilitate the integration of heterogeneous data sources, of different

level of detail. In general they ensure a semantic interoperability. Semantic interoperability requires

a shared understanding of the meaning of the exchanged data. To achieve this, the meaning of the

input and output data of all used software systems within eeE is necessary.

The already defined use cases and their corresponding Exchange Requirements (ER) in each process

step show the versatility of required data and information (Calleja-Rodriguez, 2014). By mapping of

the ERs to standardized data schemas the semantic within each schema is ensured. As far

standardized data models are used, the meaning of data is known because the data models are well

documented and the documentation is available for all. However, as mentioned most of the process

steps require information that cannot be provided by a single data source or elementary model

respectively. Therefore the integration of heterogeneous data by means of interoperability models is

required. An interoperability models can be seen as Link Models that interlinks elements of different

data sources.

As pointed out in (Scherer & Schapke 2014) Link Models represent a list of Link Elements that show

link interdependencies of certain types between Elementary Models. A basic distinction (depicted in

Figure 2) is drawn between:

Horizontal interdependencies among domain models of different domains and formats

Vertical interdependencies among domain models of different detailing and

D5.2


Version 0.1

/59


Longitudinal interdependencies among domain models of different versions

Figure 2: Interdependencies between different domain models are linked via single objects based on (Scherer & Schapke 2014)

The link elements in the Link Model are designed as multi-valued relations and each contains a set of

related links in which n selected elements are referenced from m domain models. A link primarily

consists of the specification of the domain model to be linked and the GUID of the element in this

model. Furthermore, the individual links can be enriched with additional information to deal

amongst others with ID conflicts. This might even be key/value pairs. The combination of all links of a

link element has to be unique, that is, there must not be two link elements with the same amount of

links.

For Link model and Multi-Model as XML schema specification, see also D4.3 “Link Model”. The

corresponding XSD diagrams are shown in Figure 3 and Figure 4 respectively.

Figure 3:Multi-Model Container specification (Sukumar, 2015)

D5.2


Version 0.1

/59


Figure 4: Link model specification (Sukumar, 2015)

2.2 Link Ontology in the eeE Use Cases

This section describes the basic links of the Link ontology with regard to the generic workflows as

well as its additional tasks. Please note that the workflows presented in Figure 5 and Figure 6 are

generic and were examined in D2.3 & D8.1.

Sequence: Set up 2.2.1

As described in Figure 5, the initial step in a project comprises the initialisation of the processes and

planning phases, the key point framework, the Level of Detail (LoD) specifications expressed in

Exchange Requirements, Level of Development (LOD) and the linking of the Templates (e.g. climate ,

material). To realize the eeE collaborative processes, the initial linking is stated in this pre-phase.

Following the generic workflow, the linking process starts within the Set up workflow.

First step: setup of the initial ontology data based on project type (interlinked with site and building type)

Second step: setup of the Key Point Framework (linking Key Points and Objects (e.g. KDP ”Thermal transmittance” linked to IfcWallStandardCase)

Third step: Linking Level of Development and Exchange Requirements specifications (ER)

Forth step: setup templates

D5.2


Version 0.1

/59


Figure 5: Workflow "Set up" Decision Makers View (Zellner et al., 2015)

Sequence: Designers’ View 2.2.2

Following the generic workflow, the linking ontology is used within the Designers’ view workflow

(Figure 6):

First step: using Link ontology for Initialisation step (Architecture, HVAC, BACS, FM), within the ScM the designers select the former interlinked templates

Second step: after finalizing the Design, the IFC file is saved and later used to create an eeBIM model. For using in the Ontology it needs to be converted with an IFC2OWL service.

Third step: To check all linked in the ontology repository, it is needed to (1) save the link data, (2) check their correctness, and (3) report the result back to the MMNavigator.

Fourth step: Final check of the Ley points, LoD, exchange requirements

Fifth step: after finalizing the design, the LOD for tasks has to be checked with the ontology.

D5.2


Version 0.1

/59


Figure 6: Workflow "Designer’s View"(Zellner et al., 2015)

Sequence: Analysts’ View 2.2.3

Within the analysts’ view in the generic workflow, the linking ontology is used for:

First step: similar using Link ontology for Initialisation step (energy exterts and analysts) as in the designers view.

Second step: after finalizing the simulations and cost calculations, the LOD for task has to be checked with the ontology.

Sequence: Decision Makers’ View 2.2.4

Within the analysts’ view in the generic workflow, the linking ontology is used for:

First step: Link ontology is used for Decision Value Setup as in the designers view.

Second step: after finalizing the decision, the LOD for phase has to be checked with the ontology.

D5.2


Version 0.1

/59


2.3 Role of the Link Ontology in the eeE Ontology Framework

The link ontology mainly fulfills two issues; on the one side it is responsible for integrating the

different data coming from different sources and on the other side it provides the checking of the

correctness of the data.

Figure 7: Integrating and Checking of Models

The model integration comprises five steps:

Single Model Filtering: The single model filtering filters out the data required for the next step. This kind of filtering is done with a filtering language operating on the origin format the single model is given.

Mapping model to OWL Structure: For mapping the instantiated Models to OWL two core mapping methods will be applied. The first method realizes the mapping from IFC to OWL. Here, the existing mapping approach of Beetz (Beetz, van Leeuwen, & de Vries, 2009) is used. Next to the IFC mapping a mapping method for transforming XML documents into OWL will be offered. The XML2OWL mapping will be described in XMLT. The different XMLT mapping rules for the different XML documents will be managed by the ontology.

Predefined Model Linking: Based on predefined configurations defined in inferencing rules corresponding instances of two different models will be linked. This is only possible for unambiguous relations between instances.

Model Linking Support: For links, which cannot identified as unambiguous, the ontology provides mechanism to present the user creating the links manually meaningful possible links.

Detailed Model Mapping to OWL: For detailed analyses of links also the content of the linked data has to be transferred into a common model. So, if the content is harmonized the precondition is fulfilled to check if two linked classes really correspond.

Model Linking Support

Detailed Mapping Model to

OWL

Link Existence Check

Data Allocation

Check

Single Model Filtering

Mapping Model to

OWL Structure

Predefined Model Linking

Model Integration

Data Dependency

Check

Value Range Check

Analytical Check

Result Selecting

Error Handling

Model Checking

D5.2


Version 0.1

/59


The model checking comprises also five steps:

Link Existence Check: This inspection checks, if all background model were correctly instantiated and the relations between the instances follows the cardinality restrictions.

Data Allocation Check: This inspection checks, if all instances have the correct meta-data and if the meta-data of two related background model-instances are plausible.

Data Dependency Check: This inspection checks is an extension of the previous check, so that more than two instances and their links will be checked based on few content data.

Value Range Check: This inspection checks, if the data value ranges of two related background model-instances are plausible.

Analytical Check: This step belongs to inspection methods strongly based on analysis methods of certain standard regulations like the Eurocode. These regulations formulated in ontology rules are firstly applied on the Meta-data and then in the final step on the complete integrated data.

During all checking steps error handling methods will be applied, if some minor errors are

detected an can be solved without spending much effort and next to this selection methods will

be invoked after this to select out unusable results.

2.4 Link Ontology addressed to the Ontology Platform

As in (Kadolsky, 2016) specified, the ontology platform forms the core information infrastructure,

which responsible for storing different multi model information and offering a certain access to the

information storage. Furthermore, it provides services for checking the quality of the required

information and generated results.

Figure 7: Ontology Platform (Kadolsky, 2016)

In (Kadolsky, 2016) the ontology platform was defined as follows: “The ontology platform consists of

four main layers: Ontology Access Service Layer (OAS), Ontology Management Services Layer (OMS),

Ontology Verification Services (OVS) and the Ontology Repository Layer. The Ontology Access Service

Ontology Access Services

Access to ScM Access to BIM+ Access to SIM

Ontology Management Services

Linking Services

Filtering Services

Transform. Services

Extending Services

Ontology Verification Services

Error Handling Services

Prerequisite Checking Services

Result Quality Checking Services

Ontology Repository

Schema/Instances Storage

Access to EDM

D5.2


Version 0.1

/59


Layer provides the access to the ScM for receiving checking requests and sending results back, to

EDM/BIM+ for receiving IFC and Link Models and to the Simulation Tools for generating simulation

models and receiving simulation results.”

The Ontology Management Service Layer provides service for model extension, transformation,

filtering and linking.

D5.2


Version 0.1

/59


3 Domain Models in the eeE Design Process

Within the past decades the complexity of construction projects and especially the complexity of

energy systems increased explicitly – not least because of the integration of renewable energy

resources. Energy supply is no longer a downstream process starting on the supplier site guiding to

the customer. Instead of a one-way task during former times the energy supply is getting a multi-

dimensional and multi-layered task within the design and operational phase of a building situated

embedded within the neighbourhood. The reduction of the area- or volume-related energy demand

within the building and the more intelligent user-specific equipment does not simplify the overall

situation. Furthermore the aspiration of high-efficiency energy production, distribution and usage

produces challenges for energy system design including modelling, analysis and optimization but also

operation.

One of the main challenges in a holistic collaborative design process is to ensure the interoperability

of heterogeneous data sources. There exist various data models within different domains of

nowadays construction projects, either standardized or proprietary. The challenge is to integrate

these data sources to ensure interoperability and without losing information.

Further interoperability of design phases as well as Level of Detail are explained.

3.1 Simple district test case

This Chapter introduces the simple district test case, which will be utilized (1) to discuss different

aspects of interoperability (domain, design phase and LoD interoperability) in Chapter 3, and (2) to

illustrate the eeE process and task related Multi-Models, including Domain Models and Link Model,

in Chapter 4.

In general the simple district example comprises two existing buildings, which are condition by a local

heating and cooling system. Both building share a common energy production (see Figure 8).

Figure 8: As-Is Situation - Simple district test case

The local heating system consists of two radiators connected to the shared heat energy production

and the local cooling system comprises one fan-coil connected to the common cooling energy

production (see Figure 9).

D5.2


Version 0.1

/59


Figure 9: Existing Building - Heating & Cooling System

Figure 10: PI diagram - Heating & cooling system

The building owner’s intention is the extension of the existing district by one more building (see

Figure 11). Therefore the owner expresses among others the following requirements:

Energy-efficient embedding of a new building in an existing energy infrastructure

Design, optimization and integration of a district energy system and energy system controls for energy efficient operation

Maximized usage of renewable energy resources and integration in existing energy system

Different alternative of building cubatures and energy system concepts should serve as decision basis

Figure 11: To-Be Situation - Simple district test case

Starting with the As-Is situation and reaching the To-Be situation is a multi-disciplinary process, which

needs a holistic collaborative design methodology.

3.2 Domain Models

In the following Chapter different domain models and interoperability aspects are discussed. The

interoperability system (see Figure 12) enables task-related integration of heterogeneous data, e.g.

different domain model or template data, by means of interoperability models (Link Models). The

Pump

Fan-CoilRH

T

Q

T

Q

Pump

Q

Fan-Coil Controller

Room Controller BACS

Interface Energy Production

(Heat Exchanger)

Radiator

Radiator

Radiator Thermostat

Radiator Thermostat

WW

Energy Production

T

WS

Weather Station (Physical or Service)

3x Multi Sensor

Energy Meter (Cooling)

Energy Meter (Heating)

T

T

T

CO2

T T

D5.2


Version 0.1

/59


interoperability system has to consider different aspects of interoperability as introduced in Chapter

2.1.

The interoperability system forms the core approach for realizing the interoperability between the

different domain models and external data and is also related to the design process. Thereby, this

approach comprises two level of data integration. On the lower level only the linking information

between the different models is harmonized and represented in a uniform semantic, the origin

models remain as they are. This approach is very simplified and mostly made for data exchange. For

a controlled data exchange the semantic information of the origin models is mapped into ontology

format offering the possibility for deriving information, additional filtering methods, rule based

calculation methods and quality checks envisaged by the KP method (Kadolsky, 2016).

Figure 12 shows the interoperability system, it can be see the Link Ontology and examples of Domain

Ontologies (BIM, ESIM, NIM and BACS Ontology). As mentioned above for a controlled data exchange

the semantic information of the origin models is mapped into the ontology and the origin models

remain unmodified and in their original exchange format.

Figure 12: Interoperability System

In the following a short overview of the most important domain models within the eeE design

process (Urban Design, Early Design, Detailed Design).

BIM Ontology

The BIM ontology holds information of the Architectural Model (IFC), the HVAC model, BACS model

as well as Facility Management related information. To ensure interoperability in general the BIM

ontology does not require geometrical information. So only non-geometrical information are

mapped form IFC models.

ESIM Ontology

The ESIM ontology corresponds to the domain model describing the energy system on district level

the. The ESIM per definition is a domain specific model that provides information of the urban and

building energy system including the automation and control systems. It provides concepts to

D5.2


Version 0.1

/59


represent functional, structural and physical descriptions of the systems as master data and

additional operational data.

Figure 13: ESIM core parts and shared property concepts (Kaiser & Stenzel, 2015)

The conceptual specification of the newly ESIM was elaborated in Deliverable D4.2 “Energy System

Information Model”, it consists of core part concepts and optional property groups (see Figure 13).

Core parts represent data which is mandatory needed to describe an energy system with its main

structure, function and behaviour. The description of each core part within an energy system is

based on re-usable shared property groups.

BACS Ontology

The BACS Ontology can be seen as a subset of the ESIM core part Automation and Control System

(ACS) on building level. The BACS ontology provides schematic and functional information of the

automation system and its components. Building Automation Systems over the whole automation

pyramid (Field Level, Automation Level and Management Level) can be described from a schematic

and functional view

NIM Ontology (IFC)

The neighbourhood and environment information are provided by the Neighbourhood Information

Model (NIM) Ontology. Within eeEmbedded the IFC data model represents the NIM, though other

data sources like cityGML or GIS are possible. Typical information provided by the NIM ontology are

for example topology, ground quality and meteorological information.

Beside the mentioned elementary models above there are other data sources or data sets possible.

For example the linking of climate data, occupancy data, material data or simulation data provided

by templates could be linked using the link model ontology.

The illustration in Figure 14 shows an example of domain model interoperability. The placement

(position) and physical representation of the technical building system, e.g. controller, sensors and

actuators, is consists to the IFC model. Whereas, the functions, functional relations and schematic

representation of the technical building system and its components is part of the domain model

ESIM. A link model ensures the semantic interoperability between different domain models.

D5.2


Version 0.1

/59


Figure 14: Example - Interoperability of domain models

The conceptualization and finally implemented of the domain model ontologies will be done in Task

T5.3 “Domain Model Ontology”.

3.3 Design phase and level of detail

The interoperability of the design phases and the levels of detail are very similar on the abstract level

to the interoperability of the domain models. The interoperability of the design phases and the LoD

are strongly inter-related with design process.

depend on the design process

cross link model interoperability

cross interoperability of key object sets

Figure 15: Example - Interoperability of design phases and level of detail (LoD)

The interoperability system ensures the semantic interoperability of heterogeneous data sources

taking into account (1) horizontal interdependencies among domain models of different domains and

formats, (2) vertical interdependencies among domain models of different detailing, and (3)

longitudinal interdependencies among domain models of different versions.

In general the ontology-based concept allows the integration of data on three abstraction levels. On

the lowest level the external data are only linked by a certain URL. The content of the linked data file

is unknown. On the next level additionally to the URL link-address Meta data are integrated. On the

D5.2


Version 0.1

/59


highest level the external data are completely integrated. The integration of the data is next to its

representation in different abstraction levels dependent on the data set, which is selected to be

integrated in the ontology.

D5.2


Version 0.1

/59


4 Link Ontology in the eeE Design Process

In this section the gaps of existing linking approaches will be discussed firstly. It will be presented

what benefits the envisaged eeE link model approach provides. After this the different multi models

in the different design phases will be listed.

4.1 Benefits of the Link Model Ontology

Besides the known Multi-Model approach (Scherer & Schapke 2014), the Link Model can also be

expressed in RDF (Resource Description Framework), which leads to a more acknowledged and

standardized way of resource linking based on specifications from the World Wide Web Consortium

(W3C). The advantage of such an ontology-based model is the possibility to give links detailed

semantics and constraints. It is also possible to use query technologies like SPARQL for retrieving

specific model elements. Also reasoning mechanisms are possible through applying defined rule sets

to the datasets.

The general advantages of an ontology-based interoperability system compared to the Multi-Model

Container developed in (Scherer & Schapke 2014) are as follows:

Standardized W3C technology

Many free software tools on the market to edit or visualize the datasets

Deeper semantics possible

Easy extension possible through linking to other web ontologies

Up-to-date approach similar to current international Link Data efforts (Open Linked Data initiative)

Power reasoning and querying mechanisms by using rule sets and SPARQL are available

Using the Link Model approach within the eeE design process has further advantages compared to

the Multi-Model Container for some specific use cases. A selection of possible benefits are shortly

discussed in the following.

Figure 16: MMC for different tasks

D5.2


Version 0.1

/59


For some tasks in the eeE design process not all Links or linked information respectively is required.

Taking that into the Link ontology concept follows a task dependent approach, which has the

advantages the number of links is reduced.

A further issue of the Multi-Model Container (MMC) is the high probability of wrong or missing Links,

e.g. the wrong link between a Steel Column and Formwork Costs cannot be resolved (Figure 17).

Figure 17: MMC including wrong Links

Therefore the MMC could contain solutions to solve the wrong Links. Error Handling mechanism by

suggesting correct link elements as illustrated in Figure 18 are possible by using the ontology-based

Link Ontology.

Figure 18: Link Model Error Handling – Providing solutions for wrong Links

4.2 Process and task related Multi-Models

The ontology-based interoperability approach is elaborated process- or task- related respectively. For

that the basis forms the eeE design process description (Urban Design, Early Design and Detailed

Design) and the exchange requirement specification (Calleja-Rodriguez, 2014). In this Chapter the

detailed specification of the Multi-Models and the involved elementary models are presented. It will

D5.2


Version 0.1

/59


be shown on the eeE Urban Design phase in detail. However, the Link Models including elementary

models for the eeE Early Design and eeE Detailed phase have been elaborated in the same way.

The Figure 19 shows the eeE urban design phase and the related exchange requirements are

summarized in Table 1 (Calleja-Rodriguez, 2014).

Figure 19: Exchange requirements for the urban design phase (Calleja-Rodriguez, 2014)

Table 1: Input and output ER table for urban design phase (based on Calleja-Rodriguez, 2014)

Task Input ER Tables Output ER Tables

1.1 Design cubature ER 1.2 SIM I*

ER 1.4 SIM II*

ER 1.5 LCC*

ER 1.6 DV*

ER 1.1 ARCH

1.2 Simulation I ER 1.1 ARCH ER 1.2 SIM I

1.3 Energy Concept ER 1.1 ARCH

ER 1.2 SIM I

ER 1.4 SIM II*

ER 1.5 LCC*

ER 1.6 DV*

ER 1.3 ESIM

1.4 Simulation II ER 1.1 ARCH

ER 1.3 ESIM

ER 1.4 SIM II

1.5 Lifecycle Costing ER 1.1 ARCH

ER 1.3 ESIM

ER 1.4 SIM II

ER 1.5 LCC

1.6 Decision Making ER 1.4 SIM II

ER 1.5 LCC

ER 1.6 DV

The illustrated process map represents all involved domains (actors), the activities (tasks) and the

required data that has to be exchanged. For a better understanding of the shown process map, the

following explanations were given in Deliverable D1.3 (Calleja-Rodriguez, 2014):

D5.2


Version 0.1

/59


“The blue color is related with the ER generated by the expert domains such as the Architecture and

the Energy System (ES) domain. The orange color is related to the ER generated by the simulation

and calculation domains. The green color is used for the decision making domain. The grey color is

used to note the feedbacks. The arrow with the unbroken line is used to connect activities (tasks) in

sequence. The arrow with broken line is used to specify messages (flows of information) between

activities which are not sequential. For instance, the exchange requirements listed in the table “ER

ARCH 1.1” have the Exchange requirements generated by the Architecture domain and given to the

Simulation domain to run the Simulation I. These ERs will be also given to the ES and LCC domains to

create the energy concept, to run the Simulation II and to calculate the lifecycle costs.”

The task-related ontology-based Multi-Models are illustrated for each Task of the Urban Design

phase. Each table consist of three columns and is divided into an input part and an output part,

means for each task two Multi-Models are specified. In the “ER Tables” column the task-related input

and output exchange requirements are listed. The “Elementary Models” column shows the ER-

related elementary models of the exchanged Multi-Model. And in the second column the

corresponding illustration of Link Model and Elementary Models are shown.

Table 2: Multi-Model - 1.1 Design Cubature

ER Tables 1.1 Design Cubature Elementary Models

Input

ER 1.2 SIM I*

ER 1.4 SIM II*

ER 1.5 LCC*

ER 1.6 DV*

KDP To-Be Model

Neighbourhood Model

Simulation Results

Output

ER 1.1 ARCH

KDP To-Be Model

Architectural Model

D5.2


Version 0.1

/59


Table 3: Multi-Model - 1.2 Simulation I

ER Tables 1.2 Simulation I Elementary Models

Input

ER 1.1 ARCH

KPI To-Be Model

Architectural Models

Neighbourhood Model

Output

ER 1.2 SIM I

KPI To-Be Model


Neighbourhood Model

Simulation Results

Table 4: Multi-Model - 1.3 Energy Concept

ER Tables 1.3 Energy Concept Elementary Models

Input

ER 1.1 ARCH

ER 1.2 SIM I

ER 1.4 SIM II*

ER 1.5 LCC*

ER 1.6 DV*

KDP To-Be Model


Neighbourhood Model

Energy System Model

Simulation Results

Output

ER 1.3 ESIM

KDP To-Be Model

Energy System Model

D5.2


Version 0.1

/59


Table 5: Multi-Model - 1.4 Simulation II

ER Tables 1.4 Simulation II Elementary Models

Input

ER 1.1 ARCH

ER 1.3 ESIM

KPI To-Be Model

Architectural Model

Energy System Model

Output

ER 1.4 SIM II

KPI To-Be Model

KPI As-Is Model

Architectural Model

Energy System Model

Table 6: Multi-Model – 1.5 Lifecycle costing

ER Tables 1.5 Lifecycle costing Elementary Models

Input

ER 1.1 ARCH

ER 1.3 ESIM

ER 1.4 SIM II

KPI To-Be Model

Architectural Model

Energy System Model

Simulation Results

Output

ER 1.5 LCC

KPI To-Be Model

KPI As-Is Model

Architectural Model

Energy System Model

D5.2


Version 0.1

/59


Table 7: Multi-Model - Decision making

ER Tables 1.6. Decision making Elementary Models

Input

ER 1.4 SIM II

ER 1.5 LCC

DV To-Be Model

Architectural Model

Energy System Model

Simulation Results

Output

ER 1.6 DV

DV To-Be Model

DV As-Is Model

Architectural Model

Energy System Model

Simulation Results

D5.2


Version 0.1

/59


5 Link ontology approach

Mapping a model to an ontology structure follows the idea to semantically enhance the origin model

with new concepts and new methods, which are not considered or could not be formulated in an

appropriate way. Some of these new model extensions are task independent and got a generic

character. In this case it make sense to integrate them directly in the domain and the corresponding

ontology. Next to this there are extensions which are very close related to a certain subject, process

or task. Integrating these new concepts, rules or restrictions also into the ontology would lead to

overloaded ontology approach.

Task dependent concepts are representing the connection points between the different ontologies.

Generally, these new concepts can be integrated in the existing inheritance hierarchy of the related

domain ontology. Caused by the temporal character of their use it makes sense to store them in a

separate ontology called interface ontology and to describe the connections like inheritance relations

to the domain ontology by references. Next to the inheritance relationships to the domain ontology

the interface ontology establishes own hierarchies, which could also be represented in separate

ontologies. On the first level there are generic concepts regarding to a certain subject like

construction physics. These generic concepts are formulated in a separate ontology. On the next

level there are concepts regarding to a certain construction physical process like thermal energy

analysis. This will be also represented in a separate ontology with inheritance or aggregation

relationships to the generic ontology. On the last level there are the connection points for a certain

task. So, the resulting interface ontology is a combination of different interface ontologies

representing a certain level of detail.

In the following the idea of the ontology-based Link Model approach will be explained. Further the

different link types and their interpretation will be shown.

5.1 Link Model Idea

Linking of data is a procedure of generating relations. So, linking can be also realized using relational

data bases. The concept of relational data bases is easy to understand and its use is in step with

actual practice. From this point of view it makes sense to include the relational data model in the

envisaged linking approach. So, the relational data model and its tables will form the practical part

and the application layer and the ontology will form the strongly networked complex part and the

information layer (Kadolsky, 2016).

D5.2


Version 0.1

/59


Figure 20: Relational Data Model and Ontology Model combined (Kadolsky, 2016)

The multi model generation and the link quality control/ pre-condition check are realized in the

combined models in the following steps:

1 Integration of Semantic Data: Only the data, which are relevant for linking will be integrated in the ontology. These data are semantic data; this means geometry data will be excluded.

2 Semantic Enrichment, Pre-Linking: The data coming from the origin models will be first harmonized. In a second step enrichment rules will be applied to derive additional information and to enrich the model; so, a room could be identified as cellar for example. Next to this, based on linking rules instances of different models will be as far as possible automatically linked.

3 Task dependent Filtering, Table Filling: Regarding the planed task the data within the ontology model will be filtered and mapped into the relational data models.

4 Data Modifying, Data Linking: The mapped data will be modified regarding the upcoming task; so, data values could be adapted. Next to this, the linking between the instances will be done supported by using matching tables (s. next section).

5 Data Checking, Link Checking: The entered data will be checked against the ranges defined in type tables. The link checking is based on the matching tables (s. next section).

6 Re-Writing Data and Links: The adapted data and the defined links will be mapped back into the ontology.

7 Complex Semantic Checking, Rules Extension: Complex checks, which are not based on a simple comparison of values, are realized within the ontology like transitivity checks. New linking rules defined in the relational data model are mapped into ontology rules.

The link ontology model is used to describe the complete linking between the different domain

models and the external data. In contrast to the semantic reached approach integrating semantic

data from the different domain models this simplified approach harmonizes only the link information

in a unified link model. So, the link model consist of three different components: the elements, the

element classes and the link element. The elements represent the elements from the different

domains which has to be linked with each other. They got the same ID as in the origin models. For

supporting the filtering the elements are also connected with their related classes. The actual link is

described with the link element. Link elements can be linked with different elements, so that n-ary

links can be realized.

OntologyModel

Relational DataModel

1Integration of semantic Data

Origin Data Models

Experts

2Semantic Enrichment,Pre-Linking

3

Task dependent Filtering, Table Filling

4Data Modifying,Linking

5Data Checking,Link Checking

6 Re-Writing7

Complex Semantic Checking, Rules Extension

D5.2


Version 0.1

/59


Link Concept of Multi Model should remain and only smoothly adapted. Domain Model related Tasks Domain Tools Link Model related Tasks Link Ontology Framework

Link Type Definition for Views, Checking & Error Handling

Detail Level of Link Type Definition depends on Class Detail Level of the Domain Models to be linked.

Link Types are predefined and definable.

Definable Link Types requires an Agreement Step

Link Model Structure

Link Model o ID o Process/Task

Domain Models o ID o Format

Domain Model Elements o ID o Instantiated Class/Type

Links o ID o Link Type

Matching Tables/Checking Rules/Transformation Rules

5.2 Link Type Definition

Each Link in the Link Model is realized as n-ary Link. The advantage of an n-ary Link is consistency. A

drawback is two links are always required instead of one Link and one extra Element.

Figure 21: n-ary Link in Link Model

In general there are two kinds of Links: Model Links linking Models, and Element Links linking

Instances of Classes. Both kinds of Links can be specified on Type Level. There are three different link

combinations conceivable:

Model Link – Model Link (e.g. linking architectural model and HVAC model)

Element Link – Model Link (e.g. linking building object and climate model)

Element – Element Link (e.g. linking wall object and material)

Model Link

Corresponding to the Multi-Model Approach and the three aspects of interoperability three Link

Types on Model Level are predefined. These Link Types are (1) Reduction Link Type, (2) Domain Link

Type, (3) Adaption Link Type, and (4) Version Link Type, which are illustrated in Figure 22.

D5.2


Version 0.1

/59


Figure 22: Link Types for Model Linking

Element Link

Corresponding to the Multi Model Approach on Element Level four Link Types are predefined and six

additional Sub-Types:

Reduction Link Type o Abstraction Link Type o Selection Link Type

Domain Link Type o Outer Domain Link Type o Inner Domain Link Type

Adaption Link Type o Correction Link Type o Variation Link Type

Version Link Type

After defining the two general Link Types, including their Sub-Link Types a selection of possible Link

Type interpretations is discussed.

Link Type Interpretation I:

A Reduction Link, a Domain Link or an Adaption Link Type could be the result of a new version (see

Figure 23). A new version could also result of changed information, which are not the consequence

of a reduction or a new or changed domain link, like the U-value as attribute value. So, a Reduction

Link Type or Domain Link Type can be sub classes of a Version Link Type, but a Version Link Type

could be also directly instantiated.

Figure 23: Link Type Interpretation I

Link Type Interpretation II:

D5.2


Version 0.1

/59


Reduction, Domain and Version Link Type are belonging to the Models, the sub types belonging to

the Elements, see Figure 24.

Figure 24: Link Type Interpretation II

Link Type Interpretation III:

The Sub Types of the Reduction Link Type are only defined on Element Level. A Selection Link Type

indicates, that one of the linked Elements contains a Sub Set of the Information of the other Element;

an Abstraction Link Type indicates, that the Information of one Element was reduced, cause of an

Abstraction Step (see Figure 25).

Figure 25: Link Type Interpretation III

Link Type Interpretation IV:

The Sub Types of the Domain Link Type are only defined on Element Level. An Inner Domain Link

Type indicates, that one of the linked Elements contains Overlapping Information of the other

Element; an Outer Domain Link Type indicates, that the Information of one Element is not

overlapping with the Information of another Element (see Figure 26).

D5.2


Version 0.1

/59


Figure 26: Link Type Interpretation IV

Link Type Interpretation V

The Sub Types of the Adaption Link Type are only defined on Element Level. A Correction Link Type

indicates, that one of the linked Elements were changed and this changed Element represents not a

Variation. If a Variation is meant the corresponding Link Type can be selected (see Figure 27).

Figure 27: Link Type Interpretation V

5.3 Key Link Object Sets

In order to follow the intended ontology-based interoperability concept appropriated link objects

among the different heterogeneous data sources (elementary models) have been defined in this

Chapter. The intention is to keep the key objects as generic as possible, so working with

generalizations and specializations is aimed, and the sets of key objects should be minimal in order to

keep the interoperability model manageable.

Based on first rough link object definitions, that have been identified and elaborated in Task 4.3 “Link

Model” (D4.3) as well as in Task 4.2 “Energy System Information Model” (D4.2), more detailed Key

Link Objects have been worked out.

The following Figure 28 shows this rough overview on possible links as mentioned in (Kaiser &

Stenzel, 2015) from Energy System Information Model (ESIM) point of view. Among other there exist

Link Object Sets for linking Energy System Components, Energy Systems, Spatial Structure Elements,

HVAC Systems, HVAC Components and Building Automation & Control System.

D5.2


Version 0.1

/59


Figure 28: Key link objects from ESIM point of view (Kaiser & Stenzel, 2015)

The tables below include the interoperability concepts representing the Key Link Objects

(“Interoperability Concepts”), the short description of these interoperability concepts (“Description),

the type of data (“Type of data”) as well as the reference to other concept specifications (“Reference

to Concept”). The tables are structured according to the identified Key Object Sets in Figure 28.

D5.2


Version 0.1

/59


Table 8: Interoperability Concepts - Link Model and Elementary Model

DescriptionType of

dataReference To Concept

STRING -

has STRING -

has Global Unique Identifier of the Link Model STRING

has Project Corresponding project of a specific link model STRING Project

has Corresponding process of a specific link model STRING Process

has Corresponding task of a specific link model STRING Task

has Elementary models that are connected using the link model STRING ElementaryModel

hasA link that connects elementary models (ModelLink) or elements of differnt

elementary models (Element Link) STRINGLink

-

is ElementLink Linking of instances of classes. Most abstract element link. STRING -

is SpatialStructureElement Element link for spatial structure elements STRING SpatialStructureElement

is EnergySystem Element link for energy systems STRING EnergySystem

is EnergySystemComponent Element link for energy system component STRING EnergySystemComponent

is TechnicalBuildingSystem Element link for technical building systems STRING TechnicalBuildingSystem

is TechnicalBuildingSystemComponent Element link for technical building system components STRING TechnicalBuildingSystemComponent

is BuildingAutomationAndControlSystem Element link for BACS STRING BuildingAutomationAndControlSystem

is BACS_Component Element link for BACS component STRING BACS_Component

is ModelLink Link conncets on model level URL -

is ClimateData Element link for URL ClimateData

is OccupancyData Element link for URL OccupancyData

is MaterialData Element link for URL MaterialData

is SimualtionData Element link for URL SimulationData

has Global Unique Identifier STRING -

hasCorresponding to the Multi Model Approach three Link Types are

predefined (Reduction Link Type, Domain Link Type, Version Link Type) STRING-

is ReductionLinkType Reduction Link Type STRING -

is AbstractionLinkType Abstraction link type STRING -

is SelectionLinkType selection link type STRING -

is DomainLinkType Domain link type STRING -

is OuterDomainLinkType Outer domain link type STRING -

is InnerDomainLinkType Inner domain link type STRING -

is VersionLinkType Version link type STRING -l inked

With LinkElement Class/Type of an Elementary Model STRING -

decompos

ed By LinkElement Class/Type of an Elementary Model STRING -

sameAs LinkElement Class/Type of an Elementary Model STRING -

STRING -

is ArchitecturalModel Elementary model for architectural design STRING -

is HvacModel Elementary model for HVAC system concept and design STRING -

is BacsModelElementary model for building automation and control system concept and

design STRING-

is EnergySystemModel Elementary model for district energy system concept. STRING -

is ClimateModel Climate model provites climate data for a specific location, e.g. TRY STRING -

is KeyPointModelKey Point model covers the Key Design Parameter, Key Performance

Indicator and Decision ValuesSTRING -

is CostModel Cost model covers cost information for LCC STRING -

is Further domain models possible STRING -

has MetaData The meta data of an elementary model, e.g. GUID, format, STRING -

has GUID Global Unique Identifier STRING -

has Schema The data schema of the elementary model, e.g. IFC, ESIM, GAEB, etc. STRING -

has Format SPF, XML, RDF/XML, Turtle, ifcXML etc. STRING -

has Elementary model has level of detail STRING -

has Elementary represents specific level of development. STRING -

hasFurther meta data of the elementary model, like file name, description,

author, software tool, etc.STRING -

…

LoD

LOD

…

Interoperability Concepts

LinkModel

Link

ElementaryModel

MetaData

Link

GUID

Process

Task

ElementaryModel

GUID

LinkType

D5.2


Version 0.1

/59


Table 9: Interoperability Concepts - Energy System and Energy System Components

Table 10: Interoperability Concepts - Project, Process and Task

DescriptionType of


EnergySystemComponent STRING -

isEnergy source component of an energy system that provides public accessible unified description of on-

site or nearby available energy resourcesSTRING -

is Describe energy transformation facilities like heat exchanger, boiler, heat pumps and similar devices. STRING -

isRepresents various types of distribution systems like electricity, heat, natural gas as well as water and

waste water networksSTRING -

is

Describes various energy storages types that are available on large scale district level and on building

level, storing e.g. electricity, heat, natural gas, hydrogen or potential energy within pumped-storage

power plants

STRING -

isEnergy consumption component provides standardized profiles which deliver information about

energy and media consumption (quality and quantity, time-depending) for e.g. buildingSTRING -

is Components like actuators, controller, sensors are automation and control elements. STRING -

STRING -

has Sub systems of an energy system, like energy distribution or energy storage system STRING -

is The composition of one or more energy transformation facilities STRING -

is The composition of one or more energy distribution components STRING -

is The composition of one or more energy storage components STRING -

isThe automation and control part of the energy system connects the system to the supplier and service

provider as well as the building user. STRING -

hasEnergy systems or sub-systems ussually consist of energy system components, like energy sources and

consumer etc. STRING -

services The spatial structure element, e.g. neighbourhood or building which is serviced by the energy system STRING -

EnergySubSystem

EnergyTransformationSystem

EnergyDistributionSystem

EnergyStorageSystem

AutomationAndControlSystem

EnergySystemComponent

SpatialStructureElement


AutomationAndControlElement

EnergyConsumer

EnergySource

EnergyTransformationFacility

EnergyDistributionElement

EnergyStorage

EnergySystem

DescriptionType of


STRING

has The type of project. STRING

is Refurbishment Refurbishment project STRING

is Retrofitting Retrofitting project STRING

is Design Design project STRING

is Construction Construction project STRING

is … … project STRING

has A partner that is involved in the project. STRING

hasA specific role within the project. A role can be held by more than one partner or a partner can

have more than one role.STRING

is Architect Role for architectural design. STRING

is MEP_Planner Role for MEP design. Design of technical building systems from conceptual to detailed design. STRING

is BACS_Planer Role for BACS design. Design of building automation systems from conceptual to detailed design. STRING

is FM_Planer Role for facility management planning. STRING

is EnergyExpert Expert for thermal energy analysis. STRING

is CostExpert Expert for lifecycle cost analysis. STRING

is DecisionMaker Role takes decisions about design alternatives. STRING

has WorldCoordinates. Longitude, Latitude STRING

has Process The process specification of a project. STRING Process

STRING

has Process Sub process that decomposes a process, e.g. urban design, early design, detailed design. STRING Process

has Task that decomposes a process or sub-process, e.g. energy system concept STRING Task

has LevelOfDevelopment e.g. LOD 100, LOD 200, LOD 300, LOD 400 and LOD 500 STRING

STRING

hasSub task that decomposes another task, e.g. Simulation is decomposed by pre-processing, run

simulation and post-prcessing.STRING Task

has Reference to the task-related Model View Definiton URL

has Reference to the task-related Exchange Requirement Model/Table URL

hasLevel of Detail (LoD) is essentially how much detail/information is included in the model or

objectSTRING

has The URL to a template library, e.g. BACS Template Library; MEP Template Library URL

Task

MVD

ER

LevelOfDetail

TemplateLibrary

Task

Process

Project

Task

Interoperability Concept

ProjectType

ProjectPartner

ProjectRole

WorldCoordinate

D5.2


Version 0.1

/59


Table 11: Interoperability Concepts - Technical Building System and Building Automation& Control System

Table 12: Interoperability Concepts - Spatial Structure

Description Type of data Reference To Concept

TechnicalBuildingSystem STRING -

is

Conditioned air distribution system for purposes of maintaining a temperature

range within one or more spaces.STRING -

isHeatingSystem

Heating system, e.g. water or steam heated from a boiler and circulated through

radiators.STRING -

is CoolingSystem Cooling System STRING -

is DomesticHotWaterSystem Heated potable water distribution system STRING -

is DomesticColdWaterSystem Unheated potable water distribution system STRING -

isVentilationSystem

Ventilation air distribution system involved in either the exchange of air to the

outside as well as circulation of air within a spatial structure elementSTRING -

isLightingSystem

A technical system dedicated for lighting, such as a fixture having sockets for

lamps.STRING -

is CommunicationSystem Communication system STRING

is ElecticalSystem A circuit for delivering electrical power. STRING -

services SpatialStructureElement The spatial structure element that is serviced by the technical building system STRING -

TechnicalBuildingSystemComponent STRING -

is EnergyConversionDeviceA component used to perform energy conversion or heat transfer and typically

participates in a flow distribution systemSTRING -

is FlowControllerA component of a distribution system that is used to regulate flow through a

distribution systemSTRING -

is FlowFittingA component used as junction or transition in a flow distribution system, such as

an elbow or teeSTRING -

is FlowMovingDevice

A component used to distribute, circulate or perform conveyance of fluids,

including liquids and gases (such as a pump or fan), and typically participates in a

flow distribution system.

STRING -

is FlowSegment A segment of a flow distribution system STRING -

is FlowStorageA component that participates in a distribution system and is used for temporary

storage (such as a tank)STRING -

is FlowTerminalA permanently attached element that acts as a terminus or beginning of a

distribution system (such as an air outlet, drain, water closet, or sink)STRING -

BuildingAutomationAndControlSystem STRING -

is LocalControlSystem The local control system of a technical building system component. STRING -

is RoomControlSystemThe automation and control system of a spatial structure element on automation

level, room automation according to VDI3813STRING -

is BuildingControlSystem The global building control system on management level STRING -

has BACS_SubSystem Each system can be decompesed by sub systems STRING BuildingAutomationAndControlSystem

has BACS_ComponentAutomation and control systems consists in general of actuators, controller and

sensor.STRING BACS_Component

STRING -

is Actuator, e.g. valve STRING -

is Controller STRING -

is Sensor, e.g. temperature sensor STRING -

Actuator

Controller

Sensor

BACS_Component


AirConditioningSystem

DescriptionType of


SpatialStructureElement STRING -

is District A type of administrative division, contains one or more buildings. STRING -

has Project Relation to the root object of the spatial structure. STRING Project

has Site A district can be decomposed by sites. STRING SpatialStructureElement --> Site

is STRING -

has Project Relation to the root object of the spatial structure. STRING Project

has District Relation to the district containing the site. STRING SpatialStructureElement --> District

has Building Relation to buildings contained on the site. STRING SpatialStructureElement --> Building

is STRING -

has BuildingStorey Relation to a building story that is aprt of a building. STRING SpatialStructureElement --> BuildingStorey

has SpatialZone Relation to a spatial zone STRING SpatialStructureElement --> Zone

is STRING -

has Building Relation to the building containing the building storey. STRING SpatialStructureElement --> Building

has Space Relation to the spaces dcomposing the building storey STRING SpatialStructureElement --> Space

has SpatialZone Relation to a spatial zone. STRING SpatialStructureElement --> Zone

is STRING -

has BuildingStory Realtion to the building storey. STRING SpatialStructureElement --> BuildingStorey

has SpatialZoneRelation to the spatial zone. A space can be decomposed by spatial

zones or can be a partial spatial zone.STRING SpatialStructureElement --> SpatialZone

is STRING -

has Space Relation to a space. STRING SpatialStructureElement --> Space

composes SpatialStructureElementA spatial structure element composes other spatial structure element,

e.g. building has building storySTRING SpatialStructureElement

decomposed_by SpatialStructureElementA spatial structure element can be decomposed by other spatial

structure element, e.g. building has building storySTRING SpatialStructureElement

serviced_by TechnicalBuildingSystemA spatial structure element can be serviced by a technical building

system.STRING TechnicalBuildingSystem

serviced_by EnergySystem A site or a building can be serviced by an energy system. STRING EnergySystem

has OccupancyData Any spatial structure element can have an occupancy profile URL OccupacyData


Space

SpatialZone

Site

Building

BuildingStorey

D5.2


Version 0.1

/59


5.4 Transforming content of an ontology model to the content of a relational data model

Figure 29 shows the most important transformation steps to generate a relational data model from

the underlying ontology model. On schema level the linking between the classes and extended

classes will be realized using matching tables. On instances level in the first step the instances will be

linked to the extended classes based on the matching tables. In the next step then the extended

instances will be linked also based on the corresponding matching tables. Following these steps all

properties tables and load tables can be connected with the building model. Thereby, the matching

tables establishing a method for supporting and checking the correct linking (Kadolsky, 2016).

Figure 29: Interface Ontology Concept (Kadolsky, 2016)

5.5 Task-specific linking

Linking is a task specific issue. So, for an office building the energy requirements and the related

material could be fulfilled, but for a hospital the quality for the related material is not enough.

Furthermore, for a specific task not all possible checks should be applied and in this sense only an

appropriate matching table should be provided.

Link models can be described by an explicit model or by a functional model. Using an explicit model

the links are already created before the runtime. However, using a functional approach, the links will

Information Basis

Schema Relations between Classes and extended Classes -> Matching Table containing given Class of a Domain Model and a Link to a Type Table containing the Specialization of the Domain Classes.

Instances Relations between Instances and extended Instances -> Linking Table containing given Instances of a Domain Model and a Link to a Type Table containing the Special. of the Domain Instances.

Instances Relations between two Instances of two differnt Domain Models -> Linking Table containing ext. Instances of a Domain Model and a Link to ext. Instances of another Domain Model.

D5.2


Version 0.1

/59


Domain Ontology A

Domain Ontology B

Task i

Link Ontology AB

Domain Ontology A

Domain Ontology B

Task j ~ Task i

Link Ontology AB

Select (1,2,3)

Selection

be generated during the runtime. On the one hand it doesn’t make sense to store an explicit link

model for each task, on the other hand it is not efficient to generate each link model reiteratively

during runtime. The envisaged approach is based on an ontology framework, which opens up the

possibility to (de)select links and reducing the link model as well as extending the link model by using

deriving rules. In this sense the ontology approach follows the idea of identifying similar tasks, which

could be grouped and whose link models can be developed by selection and extension based on an

explicit link model as starting point. So, the implementation result for such task groups is a core link

model explicitly represented and selection queries and deriving rules attached to this core model and

related to the corresponding tasks (Kadolsky, 2016).

Figure 30: Task-Specific Selection of Link Concepts (Kadolsky, 2016)

D5.2


Version 0.1

/59


6 Link Ontology Application

A link describes the relation between different models each represented in a different format. This

means no internal relationships will be captured by the following concepts, but only external

relationships. For capturing the external relationships an external model is preferred in contrast to

storing the links internally in an existing model. The advantage is, that an external link model can

specify links between different models format independent especially on schema level. This is for the

envisaged task specific approach and the aim of increasing the reliability of linking an important

point.

Link Definition

The simplest way to describe a link between two elements of two different models is to merge their

IDs, so that a new unique ID is created representing the link. Pre-condition for this is, that each

element, which should be linked got an unique ID. The link itself represents an element opens up the

possibility to realize n-ary relationships. Based on the idea making linking practicable and easy to

manage so called linking tables are introduced representing the linking between the elements of two

models in table form.

The table form allows three kinds of linking:

Linking of two models: In this case only the first and the last column and the link column containing values. If elements of two models are linked this kind of linking is automatically derived.

Linking between elements and models: This is the case for example if building elements are not directly related to a certain material, but to the catalogue the material is specified. Here, the element side is completely filled and on the model side only the model column contains values.

Linking between elements: Linking between elements requires all columns of the table filled with values.

The specification of the instanced classes allows the search for specific relationships and views like

the search for all walls related to costs. Next to this it allows to describe linking on a higher level

required for supporting reliability.

Figure 31: Link Definition Example

D5.2


Version 0.1

/59


Matching Tables

Matching tables describe the linking between models on schema level and therefore they are format

independent. From the technical point of view matching tables are linking tables without the

instances columns. So, the meaning of a row is that a class of the one model matches to a class of the

other model. Thereby, both classes could be connected by a certain linking type.

Figure 32: Matching Table

Similarly to a lexicon this stored information can be used to check an existing linking table regarding

correctness. This will be done by checking if the instantiated classes in the linking table also exist in

the matching table applied for the check.

Matching Tables (MT) allows more checks and more not even obvious checks by a more specialized

Class/Type specification. If a detailed class specification is not in the origin schema deriving methods

could provide such a detailing. So, depending on the underlying Model Schemas different kinds of

MTs could be defined:

• First Order MTs are MTs including no class/type, which could not directly mapped from the

origin schema to the MT.

• Second Order MTs are MTs including at least one class/type, which could not directly

mapped from the origin schema to the MT, but requires a deriving method for specializing a

given class using one additional information like an attribute (e.g. Material: Steel).

• Third Order MTs … using two additional information … (e.g. Material: Steel + Structural

Properties: Loadbearing -> Loadbearing Steel Column).

Matching Tables are very close connected with Exchange Requirements (ER). So, the classes/types

should be included in the ERs and the additional information needed for specialization should be at

least inferable. Class specialization can be derived by using property information, see Figure 33.

D5.2


Version 0.1

/59


Reduction Link Type

Domain Link Type

Adaption Link Type

Version Link Type

Stand t+2

Stand t+1

Stand t

Figure 33: Derivation of Class specialization

Error Handling

The matching tables can be also used during the linking and generating a linking table. In this case all

possible candidates for an element of a model will be listed based on the used matching table.

Cause of the fact that links are also elements and can be also linked in separate linking table with

other elements, the type of the error by a mismatch can be additionally linked.

Figure 34 Matching Tables for Linking Support

Advanced Link Model Checking

Figure 355 Link Type Concepts (Kadolsky, 2016)

The previous description of the linking tables and matching tables shows a method for a simplified

check of correctness. This check is a simple syntax check, which could be done in a spreadsheet

D5.2


Version 0.1

/59


application. For a more complex check Link Types will be introduced. Here, a very generic approach

will be presented, which can be easily extended.

Link Type Extension

The envisaged generic approach of link types is based on idea, that a model can be adapted, detailed,

be linked with another model and changed based on a new version:

Reduction Link Type o Abstraction Link Type: It indicates, that the Information of one Element was reduced,

cause of an Abstraction Step (e.g. Construction Costs instead of Formwork Costs) o Selection Link Type: It indicates, that one of the linked Elements contains a Sub Set of

the Information of the other Element

Domain Link Type o Outer Domain Link Type: It indicates that the Information of one Element is not

overlapping with the Information of another Element. o Inner Domain Link Type: It indicates that one of the linked Elements contains

Overlapping Information of the other Element.

Adaption Link Type o Correction Link Type: It indicates that one of the linked Elements was changed and

this changed Element represents not a Variation. o Variation Link Type: It indicates that a new Variation was created. o Version Link Type: It indicates that a new Version was created.

First, this definition of types gives the user of the linking tables new information. So, an inner link

type indicates overlapping section and a simulator could react in an appropriate way. He could delete

overlapping section or create variants based on these. Next, the link types open up new possibilities

for more complex checking methods.

Transitivity checks

Since the previous link checks considered only one relation by checking two classes the link checks

based on link types aims to check link chains and transitivity of links. This kind of checks realized

within the ontology model. The ontology model is preferred for these kinds of checks cause of the

underlying description logic and easy the possibility to define implication chains.

Figure 366: Example for a Transitivity Check (Kadolsky, 2016)

Two Elements of different Domains are linked together via an Inner Link Type. If both of these

Elements are linked to two different Elements of a third Domain then it has to be checked if the two

Elements of the third domain are in a Selection Relation.

LM

Domain 1

Domain 1, detailed

LM

Element

Domain 1

Element

Domain 1, detailed

If one Model is a Reduction of an otherModel then at least oneElement should exists, which also represents a reduced Element

D5.2


Version 0.1

/59


7 Exchange Requirement and Key Point integration

The eeE design process is characterized by so called Key Points (KP) checks. KP include either the Key

Design Requirement verification, the Key Performance Indicator validation or the decision making

based on Decision Values (Guruz, 2015). Basis for these KP checks are among others checking of

Exchange Requirements (ER) and Multi-Model View Definitions (MMVD). This Chapter provides an

overview of the eeE MVD and eeE MMVD specification methodology and the utilization of the

MMVD in the ontology-based interoperability system.

7.1 eeE Model View Definition Methodology

The eeE MVD methodology follows the MVD methodology specified in (Liebich, 2013). For the first

step, Extend Exchange Requirements (ER) to Exchange Requirement Models (ERM), the identified ER

have been mapped to existing data schemas (see Figure 37). After analyzing the ERs the following

data models were identified as most important:

Building Information Model (IFC) – Architectural Model, HVAC Model, BACS Model and FM Model

Energy System Information Model (ESIM)

Neighbourhood and Environment Model (IFC)

Figure 37: IDM Methodology. STEP 4: Extend to Exchange Requirement Models

The following agreed data sources were used in the Exchange Requirement Model:

IFC – The required information or set of information is mapped to IFC (IFC4 schema specification) exclusively

IFC/ESIM – The required information or set of information is mapped to the IFC (IFC4 schema specification) and a reference to the ESIM is provided to access detailed information.

ESIM – The required information or set of information is mapped to the ESIM exclusively

Other standardized or proprietary data sets or templates, e.g. climate data, occupancy data, cost data etc., are provided via reference

D5.2


Version 0.1

/59


For the second step, unify to Model View Definition, the IfcDoc for MVD specification (IfcDoc, 2014)

was used, see Figure 38. According to the definition in (Liebich, 2013) the Model View Definition

(MVD) is a subschema of the IFC data schema that is needed to satisfy one or many exchange

requirements in the eeE design process. It provides a kind of guideline for software solution provider

to implement their software interfaces.

Figure 38: IDM Methodology. STEP 5: Unify to Model View Definition

For each eeE design phase – Urban Design, Early Design and Detailed Design –, we intend to define a

separate MVD (eeE Urban Design, eeE Early Design and eeE Detailed Design). Each of them will

satisfy the occurring exchange requirements in the corresponding design phase (Figure 39). For

instance, the exchange requirements listed in ER 1.1 Architecture and ER 1.3 ESIM are satisfied by

MVD eeE Urban Design.

Figure 39: eeE Model View Definition using IfcDoc

According to (Chipman, 2012a), we perform the following steps to define the mentioned eeE Model View Definition:

Use IFC baseline to access the corresponding IFC4 schema

D5.2


Version 0.1

/59


Create model views and exchanges

Create or reuse concept templates

Use concept templates to define model views content

Export mvdXML files and generate MVD documentation One of the IfcDoc advantages is the reuse of already defined model view definition or concept

templates respectively. This eases and speeds up the definition in comparison to the former MVD

specification methodology. The objective within eeEmbedded is to reuse predefined concept

templates as much as possible.

The eeE MVD methodology above and as described in D1.3 was extended in the following with Key

Design Requirements (KDR), Key Performance Indicators (KPI) and Decision Values (DV). Further the

transformation of the specified MVD to an ontology was elaborated. Figure 40 gives an overview on

the extended eeE MVD methodology.

Figure 40: Workflow extended eeE MVD Methodology

eeE MVD transformation

The transformation of the eeE MVD as mvdXML to the eeE MVD as RDF/XML is necessary for the

integration in the ontology-based interoperability system.

D5.2


Version 0.1

/59


7.2 eeE Multi-Model View Definition Methodology

Figure 41: IFC baseline extension

Figure 42: Import of XSD

D5.2


Version 0.1

/59


Figure 43: Manual extension of RDF file

Figure 44: Manual extension of mvdXML file

D5.2


Version 0.1

/59


8 Ontology API

This chapter describes the ontology API within eeEmbedded. Its purpose is twofold: (1) to enable

storing, retrieving and use of the Link Ontology data, and (2) to provide other services on the eeE

platform with the capability to access the ontology management (OMS) and ontology verification

services (OVS).

Basically, all ontologies developed and used in eeEmbedded are persistently stored in an Ontology

Repository upon which SPARQL queries are used to create / parse / resolve model links and to verify

model and key point data. For that purpose the Apache Jena FUSEKI Server is used (Grobe 2009;

Apache Jena 2015). Fuseki is a SPARQL server that provides REST-style SPARQL HTTP Update, SPARQL

Query, and SPARQL Update using the SPARQL protocol over HTTP.

Below the use of the OMS-API to access the Ontology Repository is shown on the example of the

Early Design Scenario. Its use in the other addressed scenarios is principally the same. The technical

OMS-API specification will be available online via the project web site.

Requirements / Key Point Setup

Activities: Elementary Models:

Setting up the initial ontology data including exchange requirements specifications, high level key points (KP) and Level of Detail (LoD). This data is selected on the basis of the chosen project type (e.g. LEED) from existing (pre-stored) static information in the repository and is used to populate initially the active ontology models.

Type Ontology (Specializing the given Classes)

Key Point Ontology (KPs connected to certain types defining the requirements)

Setup Templates

D5.2


Version 0.1

/59



Determining additional or refined exchange requirements on the basis of the selected applicable process templates by the BIM manager.



Initialisation (Architecture, HVAC, BACS)


This is similar to the above but applied to process templates selected by the designer (Architect, as shown, or HVAC or BACS designer)



Process Ontology (Embedding the KPs in a certain Process)

ScM

Ontology Repository

OMS

Template setup OMS-API

1 OntoReq (ChosenERTemplate)

Determines additional or refined ER based on the templates

BIM Manager

ScM

Ontology Repository

OMS

Process Template choice

1 OntoReq (LOD, ProcessStep)

OMS-API

optional

Architect

D5.2


Version 0.1

/59


Save IFC


When a BIM design alternative is developed in the respective CAD system of the designer (Architect, HVAC, BACS designer) the model has to be exported to the eeEmbedded Virtual Lab as an IFC file on which basis the interoperable eeBIM is created. While this is a straightforward process for the BIM-IFC repository, in order to use the model in the ontology it has to be converted to its dedicated ontology representation in OWL using a supporting IFC2OWL service.

BIM-IFC model

BIM Ontology, containing only the major IFC elements needed and excluding geometry

Collect Templates / Create & Check Link Model


Using templates or other external data, the original BIM exported from CAD is enriched. This is done by the end user via the MMNavigator and the resulting integrated eeBIM is stored in the bim+ repository. However, to check if all linked data is correct the ontology repository is accessed to (1) save the link data, (2) check their correctness, and (3) report the result back to the MMNavigator for visual feedback to the end user.

BIM Ontology

Data Templates (climate, occu-pancy, material properties etc.)

External Model Data

Link Ontology

CAD (Revit or Allplan)

Export IFC

ScM

Finalize process step

IFC2OWL Mapping

IFC file1

URL: uploadIFC()Each repository returns the resp. URL

IFC2OWL

Ontology Repository

OMSBIM-API

2Onto Data

Architect

MMNav

3 Ok or errors to visualise

Climate Data

bim+1

bim+ API

Occupancy Data

Material Data

etc.

bim+/MAS

1.

Collect Templates

Select Templates

Link Templates

1b.

Modify templates

…

2. Create & Save Link

Data

optional

1. Create LM2. Check LM

& KDP

Ontology Repository

2 Save Link Data

OMSOMS API

Architect

D5.2


Version 0.1

/59


Handover


In the handover step the model data created by one project partner are passed to the next one in the process. This is done via the eeE Scenario Manager (ScM) which also optionally packages all linked data in a multimodel container (MMC). However, before that a final check of the data (key points, LoD, exchange requirements) is performed by the OVS to ensure the quality of the data and guarantee that the related design task is completed.

Link Ontology

BIM Ontology


External Model Data

ScM

Energy Expert iVEL 3

BCF-API

ScM

Architect iVEL

BCF Repository

BCF Messages

Send BCF Message

BIM--ItBCF-API

2

Final KDP & ER Check (opt.)

Get BCF Message

4

1

bim+

Ontology Repository

Q. & ER Check

OMS

EDM

optional

Save Link Data

D5.2


Version 0.1

/59


Initialisation (Energy Expert)


The intialisation process with regard to the use of simulation and analysis tools by the Energy Experts is more complex than in the similarprocess related to the designers. It requires not only to detail the sub-processes (via process templates) but also to parse the link data and transform the eeBIM data correctly to the required simulation input, also enabling the option to make various model data variations. From ontology point of view it concerns the dynamic adaptation of the processes using the applied templates and the retrieval of the linked eeBIM data.

Link Ontology

BIM Ontology


External Model Data

Decision Value Setup


This is the final step in the overall process, related to the decision regarding the design solution and eventual update of the overall Decision Values (DV) for the next process stage. In case that DVs and KDPs are changed they are respectively updated in the Ontology Repository

Key Point Ontology

Type Ontology

ScM

Energy Expert iVEL

Process Template choice

1. Check BPMN2.

optional

3. Lookup Link Model4. Get linked data

5. Construct & save MMC

Ontology Repository

2

OMS

OntoReq (LOD, ProcessStep)

OMS-API

3

OMS-API

bim+

EDM

EDM API

BIM+ API

4

(BIM-API)

ScM

Ontology Repository

OMS

OMS-API

1 OntoReq (Templates) incl. DVs

MMNav

Decision Maker iVEL

D5.2


Version 0.1

/59


9 Conclusions and outlook

After introducing and motivating the intention of D5.2 “Interoperability System” in Chapter 1 the

concept of the ontology-based interoperability was presented in Chapter 2. This include the state of

the art of interoperability concepts. Different approaches, e.g. Link Model (LM) and Multi-Model

Container (MMC) as well as different link interdependencies were presented and analysed. Further

the relation of the envisaged Link Ontology in the eeE design process and the role in the eeE

Ontology Platform was addressed.

In Chapter 3 the interoperability between different heterogeneous domain models, design phases

and levels of detail (LoD) were presented.

Chapter 4 describes the utilization of the Link Ontology within the eeE Design Process. Through a gap

analysis of the existing Multi-Model Container the requirements for the Link Model Ontology have

been elaborated. The basic interoperability models (Multi-Models), comprising link model and

domain models, have been illustrated for each task in the eeE Urban Design phase by means of a

simple test case.

Based on the identified gaps and requirements the Link Ontology Approach was specified in Chapter

5. A Link Type Definition (i.e. Reduction Link Type, Domain Link Type, Version Link Type) for Element

Links and Models Links as well as detailed sets of key link objects have been defined.

Different uses cases and applications of the Link Ontology, like ontology access, matching tables,

error handling as well as Exchange Requirements (ER) and Multi-Model View Definition (MMVD)

checking were described in Chapter 6.

The eeE design process is characterized by so called Key Points (KP) checks. These KP checks include

among others checking of ER and MMVD. In Chapter 7 an overview of eeE MVD and eeE MMVD

specification methodology is presented.

Chapter 8 describes the ontology API within eeEmbedded with the purpose (1) to enable storing,

retrieving and use of the Link Ontology data, and (2) to provide other services on the eeE platform

with the capability to access the ontology management (OMS) and ontology verification services

(OVS).

Outlook:

Based on the specification of the interoperability system the prototype of the Ontology System, in

detail the prototype of the Domain Model ontology (T5.4) and Link Model ontology (T5.5) containing

the key link object sets and link types, will be implemented in OWL in the ongoing tasks.

In T5.4, the Domain Model ontology, specifically the IFC ontology (IfcOWL) and the ESIM ontology,

will be implemented. It contains the representation of the key link object sets in OWL of each domain

model and the development of the rule set for the automatic inheritance and the support of the

instantiation of the objects to be linked in the actual context of the project progress.

In T5.5 the link model ontology will be implemented. Based on the link types definition (Reduction

Link Type, Domain Link Type, Version Link Type and their specializations), link definition as well as

other necessary interoperability concepts will be represented in OWL. Further rules and knowledge

D5.2


Version 0.1

/59


to semi-automatically instantiate and check the links of the actual project depending on the actual

process context, the required LoD and the involved domains will be developed

The results of T5.4 and T5.5 will be summarized in Deliverable D5.3. “Ontology System”

D5.2


Version 0.1

/59


References

Apache Jena (2015): Apache Jena Fuseki Documentation,

https://jena.apache.org/documentation/fuseki2/

Beetz, J., van Leeuwen, J., & de Vries, B. (2009). IfcOWL: A case of transforming EXPRESS schemas

into ontologies. Artificial Intelligence for Engineering Design, analysis and Manufacturing.

buildingSMART International Ltd, ifcDoc Tool Summary [online], http://www.buildingsmart-

tech.org/specifications/specification-tools/ifcdoc-tool/ifcdoc-beta-summary

Calleja-Rodriguez & G., Guruz, R. (2014); eeEmbedded Deliverable D1.3: Interoperability and

collaboration requirements © eeEmbedded Consortium, Brussels.

Chipman, T. & Liebich, T.: IFC Documentation Guide, 2012.

Chipman, T.: IFCDOC Usage Guide, 2012.

Chipman, T., Liebich, T. & Weise, M. (2012): mvdXML – Specification of a standardized format to

define and exchange Model View Definitions with Exchange Requirements and Validation

Rules.

eeEmbedded 2013-17, EU FP7 Project No. 609349.

eeEmbedded [online], http://www.eeEmbedded.eu.

Geißler, M.C., Guruz, R., van Woudenberg, W. (2014); eeEmbedded Deliverable D1.1: Vision and

requirements for a KPI-based holistic multi-disciplinary design, © eeEmbedded Consortium,

Brussels.

Geißler, M.C., Guruz, R., van Woudenberg, W. (2014); eeEmbedded Deliverable D1.2: Use case

scenarios and requirements specification, © eeEmbedded Consortium, Brussels.

Grobe, M. (2009): RDF, Jena, SPARQL and the Semantic Web. In: Proceedings of the 37th Annual ACM

SIGUCCS Fall Conference - Communication and Collaboration.

Guruz, R., Rodriguez, G. C., & Geißler, M. C. (2015). eeEmbedded D2.1 Holistic multi-disciplinary Key

Point-based design framework. Brussels: eeEmbedded Consortium.

Guruz, R., Calleja Rodríguez, G. & Geißler, M.-C. (2015): eeEmbedded Deliverable D2.3: Holistic KPI

based design methodology © eeEmbedded Consortium, Brussels.

ISES 2011-7, EU FP7 Project No. 288819.

ISES [online], http://ises.eu-project.info.

Kaiser, J. & Stenzel, P., (2015); eeEmbedded D4.2: Energy System Information Model - ESIM, ©

eeEmbedded Consortium, Brussels.

Kadolsky M. & Scherer, R. (2016); Task-Specific Linking for Generating an eeBIM Model based on an

Ontology Framework. In: European Conference on Product and Process Modelling (ECPPM).

Kadolsky M. (2016); eeEmbedded Deliverable 5.1: Interoperability and ontology framework ©


https://jena.apache.org/documentation/fuseki2/

http://www.buildingsmart-tech.org/specifications/specification-tools/ifcdoc-tool/ifcdoc-beta-summary

http://www.buildingsmart-tech.org/specifications/specification-tools/ifcdoc-tool/ifcdoc-beta-summary

http://www.eeembedded.eu/

http://ises.eu-project.info/

D5.2


Version 0.1

/59


Liebich, T., Stuhlmacher, K., Weise, M., Guruz, R., Katranuschkov, P., Scherer, R.J. (2013): HESMOS D+

Additional Deliverable Information Delivery Manual Work within HESMOS, © HESMOS

Consortium, Brussels.

Mosch, M. & Kaiser J. (2015); eeEmbedded D4.1: BIM Multi-Model, Multi-Physics Models and

Management Methods, © eeEmbedded Consortium, Brussels.

Scherer R. J. & Schapke S.-E. (eds.) (2014): Informationssysteme im Bauwesen – Modelle, Methoden

und Prozesse (Information Systems in Building Construction – Models, Methods and

Processes), Springer Vieweg, DOI 10.1007/978-3-642-40883-0, 609 p.

Solvik, K., Kaiser, J., Geißler, M. C., Stenzel, P., (2014); eeEmbedded D1.4: Requirements for

knowledge-based design support and templates, © eeEmbedded Consortium, Brussels.

Sukumar, Amrita (2015); eeEmbedded Deliverable D4.3: Link Model, © eeEmbedded Consortium,

Brussels.

XML2RDF converter [online], http://www.gac-grid.org/project-products/Software/XML2RDF.html

Zellner, R., Guruz, R., Mosch, M., Katranuschkov, P., Tøn, A. & Kaiser, J., (2015): eeEmbedded

Deliverable D1.5: System Architecture of the virtual holistic design lab and office ©


Zellner, R. et al., (2015). eeEmbedded Deliverable D2.2: Templates for fast semi-automatic detailing

© eeEmbedded Consortium, Brussels.

http://www.gac-grid.org/project-products/Software/XML2RDF.html

http://www.gac-grid.org/project-products/Software/XML2RDF.html

optimised design methodologies for...

Documents