SWIMING: H

Transcription

1 SWIMING: H Semantic Web for Information Modelling in Energy Efficient Buildings Deliverable number D2.3 Deliverable title Main Authors Guidelines and best practices for BLCEM process and data management - Phase II Matthias Weise, Kris McGlinn Grant Agreement number Project ref. no H Project acronym Project full name Starting date (dur.) SWIMing Ending date 01/02/2017 Project website Semantic Web for Information Modelling in Energy Efficient Buildings 01/02/2015 (24 months) Coordinator Address Kristian McGlinn F 35, Computer Science, Trinity College Dublin

2 Reply to Phone +353 (0) Document Identifier D2.3 Class Deliverable Version SWIMing EU-EEB V5 Document due date 31/12/2016 Submitted 31/12/2016 Responsible Reply to Document status Nature Dissemination level WP/Task responsible(s) Contributors Distribution List Reviewers Document Location Matthias Weise Final R(Report) PU(Public) WP2 H Matthias Weise, Kris McGlinn, Hendro Wicaksono, Ioanna Petri, Nikolaos Kaklanis, Dimitrios Tzovaras, Willie Lawton Consortium Partners swiming-project.eu/?page_id= Page 2 of 91

3 Page 3 of 91 H Executive Summary This deliverable completes the set of guidelines and best practices to support data management in BLCEM processes. The guidelines follow the methodology proposed by SWIMing consortium (see D2.2), which similar to the IDM/MVD approach from buildingsmart is divided into two parts: (1) the capture of use-case specific domain knowledge and (2) the translation of conceptual models defined by domain experts into technical specifications ideally reusing existing solutions. The focus of the D2.3 has been on the second part, in particular the mapping of data requirements to ontologies and the identification of ontology alignments. The methodology itself has been applied to a set of use cases not only to validate the presented approach but also to get an overview about the current state of research in EEB-related use cases. Conducted results have been summarized in an interactive domain/use case matrix that is available at [8] as well as an overview about used ontologies that is provided in this deliverable. The result of this research is leading to a number of findings that not only proof a number of assumptions but also show current research challenges when moving to Linked Building Data and Semantic Web technologies. The following findings shall be highlighted: Importance for properly documenting use case requirements: It is often difficult to review research results and to check whether developed solutions in terms of specifications, tools and data sets can reused or integrated into own developments. Accordingly, it is important to thoroughly document developed use cases. First of all it is important to be able to classify developments for instance based on the matrix proposed in SWIMing. Additionally, it is then necessary to be able to check detailed requirements including the technical implementation. Ideally, the information is managed in a similar structure and published as a searchable resource as for instance done in SWIMing by the use of the BIM*Q tool. Integration of different data sources is becoming more and more important, even with BIM: Although BIM and IFC enables to integrate most important building data there is an increasing need to connect to other data sources, either to keep the link to none-sharable, highly specialized building data or to make use of data that is outside the scope of the AEC industry. Almost all projects are faced with the challenge to integrate different data sources. Semantic web technology is recognized as solution for data integration: A number of projects have started to use Semantic Web technology not only to link different data sources but also as a technology to manage and manipulate the data, even though there are still a number of barriers like for instance the necessity to convert data to Semantic Web-enabled representations. Linked Building Data approaches are moving from data exchange to data sharing solutions: This step potentially reduces data conversion and data losses. However, shared data may comes with a number limitations, in particular in terms of completeness (some concepts may not be expressable) and efficiency (data query and manipulation could be more difficult and time consuming than with proprietary solutions). Completeness and efficiency issues might be handled

4 H by extensions so that extensibility becomes a major requirement for LBD solutions. Reuse of ontologies is limited due to context dependency: A key principle of LBD is to reuse existing resources, not only in terms of data but also in terms of semantic definitions. However, it is very likely that existing definitions do not fully fit to own requirements. Accordingly, it is difficult to give general recommendations about ontologies without knowing the context of its use. Proper data publication is a prerequisite for using LBD approaches: In order to contribute to LBD developments it is important to properly publish and promote own ontologies and datasets. This essentially means to enrich developments with the right meta-data and to make it available for the community. Results of this deliverable give an overview about achievements in the area of EeBrelated Use Cases. Many specifications, tools and datasets have been developed for solving specific issues in the life-cycle of a building. However, it is still very difficult to find and integrate those developments into own use cases. This deliverable shall help to get a better overview about the current state-of the art, which is rapidly changing as a result of the large amount of research still being conducted. Therefore, an important message of the SWIMing consortium is to improve and harmonize the documentation of developed solutions and published data sets. Semantic Web and Linked Building Data is already embedded into standardization initiatives from W3C and buildingsmart driven by an active community and provide a basis for this multidisciplinary development that in many cases already go beyond the traditional building domain. Page 4 of 91

5 Document Information IST Project Number Full Title Project URL Document URL EU Project Officer H Acronym SWIMing Guidelines and best practices for BLCEM process and data management - Phase II swiming-project.eu/?page_id=7 Jose Riesgo Deliverable Number D2.3 Title Guidelines and best practices for BLCEM process and data management - Phase II Workpackage Number WP2 Title Guidelines and best practices for industry Date of Delivery Contractual 01/01/2016 Actual 01/01/2016 Status version 4 final Nature prototype report dissemination Dissemination public consortium level Authors (Partner) Responsible Author Abstract (for dissemination) Keywords AEC3, CERTH, TCD, KIT, UCC Name Matthias Weise mw@aec3.de Partner AEC3 Phone This deliverable presents the Guidelines and best practices for BLCEM process and data management - Phase II in the SWIMing project (WP2). SWIMing, Guidelines and Best Practices Version Modification(s) Date Author(s) 1 ToC 26/10/ Initial Content 16/11/ Second Draft 9/12/2016 Matthias Weise, Kris McGlinn Matthias Weise, Kris McGlinn, Hendro Wicaksono, Nikolaos Kaklanis, Ioanna Petri Matthias Weise, Kris McGlinn, Hendro Wicaksono, Ioanna Petri, Nikolaos Page 5 of 91

6 3 Final Draft 22/12/ Final 30/12/2016 Kaklanis, Willie Lawton Matthias Weise, Kris McGlinn, Hendro Wicaksono, Ioanna Petri, Nikolaos Kaklanis, Dimitrios Tzovaras, Willie Lawton Matthias Weise, Kris McGlinn, Hendro Wicaksono, Ioanna Petri, Nikolaos Kaklanis, Dimitrios Tzovaras, Willie Lawton Page 6 of 91

7 Project Consortium Information Participants The Provost, Fellows, Foundation Scholars & The Other Members of Board of The College of the Holy & Undivided Trinity of Queen Elizabeth near Dublin (Trinity College Dublin, Ireland) Institute for Information Management in Engineering Contact Kris McGlinn Hendro Wicaksono Centre for Research and Technology Hellas Information Technologies Institute Tyndall National Institute, University College Cork Dimitrios Tzovaras Willie Lawton AEC3 Ltd. Matthias Weise Page 7 of 91

8 Table of Contents 1 Introduction Steps covered in this deliverable Current state of documented use cases Goals (to be) addressed in this deliverable Linked Building Data and Semantic Web Monolithic data schemata vs. Semantic Web-based ontologies Link approaches COINS Multi-Model Container Linked Data based on Semantic Web Technologies Use of LBD in research projects Challenges and research questions Approach for Evaluation of Collected Use Cases Overall vision for sharing use case definitions Use cases overview - link to domains and BLC stages EeB Project Use Cases Assessment Analysis by BLC Stages Analysis by Domain Analysis of Findings Used Ontologies and Standards Use cases and ontologies Description of referenced Ontologies and Standards IFC (including ifcowl) CityGML Common Information Model (CIM) Green Building XML Schema (gbxml) Open Building Information Exchange (obix) Gemeinsame Ausschuss Elektronik im Bauwesen XML (GAEB-XML) Semantic Sensor Network Ontology (SSN) SimModel Construction-Operations Building information exchange (COBie) buildingsmart Data Dictionary (bsdd - Formerly IFD) Suggested Upper Merged Ontology (SUMO) Page 8 of 91

9 Page 9 of 91 H LandXML Collada Open Standard Concept Modelling Ontology (CMO) with Extensions Energy Enhanced BIM Model (eebim) Extended Environments Markup Language (EEML) Energy Market Information Exchange (emix) Energy Resource Ontology (ERO) ESIM Ontology eedim Ontology ee-district Ontology Geographic JSON (GeoJSON) Geonames Knoholem RDF Data Cube REMO Schema.org Semanco Energy Model Sensor Model Language (SensorML) System Interoperability Ontology (SIO) Unit of Measurement (OM) WGS The Smart Appliances REFerence (SAREF) Language(s): OWL Analysis of Use Case Ontologies According to BLC and Data Domains Summary and recommendation Mapped requirements and ontology alignments Data Requirements Harmonization across Use Cases Discussion and SWIMing Recommendations Context dependency Criteria for evaluation of ontologies Recommendations for data publication Conclusion Experiences Using the BIM*Q Tool and the SWIMing Methodology in Horizon2020 Projects OptEEmal Project NewTrend Project DAREED Project... 76

10 STREAMER Project References Appendix A Appendix B... 1 Appendix C... 3 Page 10 of 91

11 Table of Figures Figure 1: Second part of the SWIMing methodology covered by D Figure 2 Continuous Improvement Cycle supported by the SWIMing approach Figure 3: Classical argument for the BIM/IFC development. (a) multiple interfaces for intersectoral communication, (b) communication through a neutral, common and shared BIM standard Figure 4: Global architecture of a COINS-compatible Building Information System (CBIS).The blue area marks the actual CBIS, while the gray objects describe the interaction environment Figure 5: Example of a Multi-Model Container including different domain models connected through a separate link model Figure 6: Web of Data, Figure 7: Use cases in BIM*Q which have indicated potential or actual alignments with IFC4 for data exchange Figure 8: Use case standardized format Figure 9: Screenshot of Use Case Classification Table Figure 10: EeB Use Cases for the Design Stage Figure 11: EeB Use Cases for the Construction Stage Figure 12: EeB Use Cases for the Commissioning Stage Figure 13: EeB Use Cases for the Operational Stage Figure 14: EeB Use Cases for the Re-Design Stage Figure 15: EeB Use Cases for the Building Product Domain Figure 16: EeB Use Cases for the Building Devices Domain Figure 17: EeB Use Cases for the Building Control & Behavior Domains Figure 18: EeB Use Cases for the Building Data & Communications Domains Figure 19: EeB Use Cases for the Geolocation & Weather Domains Figure 20: EeB Use Cases for the Energy Domain Figure 21: EeB Use Cases per Building Life-Cycle Stage. Error! Bookmark not defined. Figure 22: EeB Use Cases per Data Domain Figure 23: EeB Use Cases per BLC and Domain Figure 24: Snapshot of Table of Use Cases Mapped to Ontologies Figure 25: Ontologies representing more than one Use Case Figure 26: Data Models per BLC Stage Figure 27: Data Models per Data Domain Figure 28: Use Case Ontology Representation (at least once) Figure 29: BIM*Q structured requirement definitions and further definitions like descriptive text, type information or the mapping to IFC Figure 30: Screenshot of the BIM*Q tool showing requirements of the OptEEmAL project Figure 31: Screenshot of the BIM*Q tool showing requirements of the NewTrend project Figure 32: High Level Use Case Template Figure 33 High Level Use Case Wiki Example Figure 34 Overview of Use Cases in BIM*Q Figure 35 Defining Processes in BIM*Q Figure 36 Defining Stakeholders/Actors in BIM*Q Figure 37 Defining Available Ontologies in BIM*Q Page 11 of 91

12 Figure 38 Concept Definition and Alignment with Processes and Ontologies in BIM*Q. 86 Figure 39 A Specific Data Exchange Defined in BIM*Q Tool List of Abbreviations Abbreviation BIM BIM_LD LD LBD BLC BLCEM E2B (OR EEB) Definition Building Information Modelling Building Information Modelling Linked (Open) Data Linked Data Linked Building Data Building Life Cycle Building Life Cycle Energy Management Energy Efficient Buildings Page 12 of 91

13 1 Introduction The goal of WP2 is to provide a set of guidelines and best practices that support data management in BLCEM processes. This work is being carried out in close cooperation with the Linked Building Data community [1], buildingsmart [2] and research projects working in the area of energy efficient buildings (EeB) through active engagement in the use and improvement of the suggested methodology. Further activities have been started by the community based on this engagement, which for instance include: development of an MVD white paper, proposal of simplebim and BOT ontology, model linking approaches, discussion about data management based on LBD, ontology modelling recommendations. Those activities were also leading to more general discussions about Linked Building Data and potential consequences for BIM data management and quality control. This deliverable is extending the work which has been previously presented in the D2.2 [3], D1.1 [4] and D1.2 [5]. However, instead of being a new revision with updated content the D2.3 is a new deliverable covering different topics than those in D2.2 [3]. This first chapter gives an overview about our activities and the content of this deliverable. 1.1 Steps covered in this deliverable The overall methodology proposed and followed by SWIMing is described in deliverable D2.2. It is derived from the IDM/MVD methodology [6] from buildingsmart and is based on a sequence of specification steps that either require specific domain knowledge of the use case or IT knowledge for implementation in software. Accordingly, there are mainly two types of experts involved in that process: (1) domain experts that are familiar with the business case and (2) IT experts that are able to translate those domain requirements into technical specifications and software. While D2.2 focused on steps 1-4, this deliverable is dealing mainly with the second part steps 5-8, in particular the mapping of data requirements to ontologies (step 5) and the identification of ontology alignments (step 7). Nonetheless, a summary of findings from Steps 1-3 are provided at the end of Chapter 3, as this inform the analysis conducted in Chapter 4. The parts of the SWIMing methodology covered by this deliverable are highlighted in Figure 1. For more information on these steps see Appendix A. Existing use cases as developed in EU-funded EeB research projects have been documented in an open Wiki [7] and partially reviewed in more depth in the BIM*Q database 1. Achieved results show the potential of collecting and harmonizing use case definitions. However, it also makes clear that there are many ways to describe data requirements. It not only depends on the use case itself but also on the background of the user describing the requirements, who themselves may already be familiar with conducting data modelling and also have knowledge about existing ontologies. 1 Page 13 of 91

14 Figure 1: Second part of the SWIMing methodology covered by D2.3 Steps 5 to 8 (Figure 1) are the main focus of this deliverable and set out to enable not only the harmonization of data requirements for comparison, but also to identify alignments between ontologies and identify standards and ontologies for supporting data publication. Alignments essentially specify the link that is needed to interconnect different data sources, as required in the Linked Building Data approach. Additionally, it also helps to identify gaps leading to the development of new ontologies. Besides presenting results this deliverable will explain those steps in more detail so that it can be successfully applied to other projects. It is important to understand that it is an ongoing process of extending or refining use case definitions that are part of the well-known continuous improvement cycle (Figure 2). Figure 2 Continuous Improvement Cycle supported by the SWIMing approach. Page 14 of 91

15 In order to successfully start new developments, it is therefore important to know what is already available to easily identify existing gaps. Accordingly, the SWIMing consortium believes that it is necessary to document use cases in a standardized way and to make that data available to be easily used and maybe queried from a single database, like BIM*Q. 1.2 Current state of documented use cases Currently there are over 50 use cases shared on the Wiki [7], 45 of these are directly accessible through the overview page [8] with a further 22 use cases available through the BIM*Q tool [9] The high level use cases on the Wiki have been shared with the projects, which have had the opportunity to validate their accuracy. This information is captured during steps 1-3. While the Wiki provides high level information, the BIM*Q tool provides much more depth into the use cases, providing not only definitions of the stakeholders and processes (and at a higher granularity than life cycle stages of the Wiki) but also detailed descriptions of the conceptual data model and required data exchanges to support the processes. This modelling represents Steps 1-4. The BIM*Q tool is designed to be flexible in use, so that all stakeholders involved in the process of data requirements capture can participate in the defining of the use cases. These steps/tasks are covered in more detail in Appendix A, where a manual of the SWIMing methodology is presented as a whole. It is encouraged when developing identifying processes, stakeholders, data domains, and data requirements for use cases, that all stakeholders be present when possible to provide input, so that they can collaboratively articulate exactly what data is important to achieve their particular process. The basic process for capturing data requirements consists of defining a concept and properties for that concept, for example the concept Building can be defined followed by properties such as: ID, Type, Location, Address etc. These are captured in a tree like structure. The flexibility provided by the BIM*Q tool means that the structure of the data reflects the conceptual models of the user for organizing data. For example, IT experts who are familiar with object oriented programming may organize data as classes and variables, describing inheritance through the placement of concepts in a hierarchy. So they have a super class Product, which has a subclass Building, which it is implied, inherits the variables associated with Product. Non IT experts may model in other ways. These experiences of users of the tool are discussed in more detail in section 6.1. The downside of this type of flexibility comes when attempting to harmonize data requirements, as it may be difficult to identify similar concepts when there is too much variance between use cases. Therefore, the process of using the BIM*Q tool usually begins with some instruction and examples by members of the SWIMing project. The continuing efforts at harmonizing data across use cases will be discussed in greater detail in section 1.3. This harmonization process has led to insights into the use of data across EeB pro- Page 15 of 91

16 jects, which inform our recommendations about future directions for BIM and Building Data in Chapter Goals (to be) addressed in this deliverable Building Information Modelling (BIM) is a synonym for integrating all relevant data of a building into a single, consistent data model. The idea of BIM and related standards have been developed by the Architecture, Engineering and Construction (AEC) community and is used as a data source and coordination point for many AEC processes [10]. The use of BIM is not limited to the core AEC business such as building design and construction. It is also used to support operation, maintenance, refurbishment and demolition of a building. Meanwhile further use cases are proposed trying to extend the current scope of BIM. While BIM has stimulated the development of new use cases such as for instance different kinds of building simulations it also true that it is not the purpose of BIM to address all data requirements in all domains (e.g. weather data). It is commonly accepted in the AEC community that there will not be a single BIM standard or ontology that covers all potential use case requirements. Out of scope are for instance weather profiles for energy simulations, geographical data for smart city scenarios and energy tariffs for optimizing energy costs. Similarly, data that is typically not shared between domain experts such as for instance finite element meshes or tool specific settings are also out of scope for BIM-based data exchange scenarios. New technologies like Semantic Web and Linked Data are proposing a new way of interconnecting different types of data sources [11]. SWIMing project partners and the Linked Building Data community [1] are aware of the big potential of this emerging technology in particular when it comes to use cases that are beyond the scope of the AEC domain for solving interoperability issues. However, there are a couple of questions related to the use of LBD. Are there specific use cases for LBD, or is it capable of completely replacing traditional STEP and XML technology? Do we still talk about data exchange as being the focus of IFC, or will it move to data sharing scenarios without local data replication as already proposed by product model servers? Is an ontology equal or comparable to a so-called Application Protocol in the STEP technology? Do we still need standards or is it sufficient to publish proprietary ontologies in the OWL format? What will be the role of BIM/IFC be in such scenarios? If ontologies are used as an open knowledge representation for encoding relevant process and product knowledge the question is whether there is still a need to differentiate between neutral data exchange standards and internal tool specific data formats or if both will be merged. The SWIMing project has contributed to the various discussions related to LBD. Specific goals and questions reported in this deliverable have been: Page 16 of 91

17 Identify and discuss research questions derived from the LBD approach. Do we for instance need a reference ontology, which level of semantics/knowledge is required in an ontology to support data exchange and maybe data processing? Is it possible to provide a list of recommended ontologies, and maybe tools, to be used in the domains and life-cycle stages identified in the SWIMing project? What are the steps proposed? What ontologies or data structures are used, how do they overlap and what are the main use cases? How is the BIM*Q being used and what are the benefits? Get an overview about the use and relevance of LBD. Who is using Semantic Web technologies or have they considered using it? 2 Linked Building Data and Semantic Web This chapter provides a discussion about Linked Building Data and the use of Semantic Web technologies. It compares the BIM approach developed by the AEC community with the idea to embed building data into the Web of Data as proposed by the Semantic Web community and consequently to use the relevant developed technologies. It highlights the state-of-the art of LBD, presents findings from several workshops and identifies open research questions. It is meant to be a neutral, but critical view on current solutions and future expectations. 2.1 Monolithic data schemata vs. Semantic Web-based ontologies BIM is a solution to integrate and share building data; however in most cases the information exchange is restricted due to the specific needs per use case. Furthermore, even though the information provided is rich and in great technical detail, the semantics around it is quite limited, hence leading to the fact that explicit communication between domains and building lifecycle stages is needed. A solution towards solving this issue was introduced with the Semantic Ontologies which provide a common vocabulary that can be utilized in establishing consistent and uniform data exchange among different domains and stages. A characteristic example is the standard for representing, accessing, and sharing a building model, which is the Industry Foundation Classes (IFCs) data model. Huge efforts have been made by research and industry to develop the IFC standard and to implement IFC import and export interfaces. IFC is basically an agreement about (1) the data that is important to be shared between the different stakeholders involved in building processes and (2) how to encode and structure that data, i.e. how to represent it in an IT-enabled data model. The development of IFC started in 1995 based on research results and the ISO STEP standard (10303) pushed by success stories of the mechanical and automotive industry. Page 17 of 91

18 Figure 3: Classical argument for the BIM/IFC development. (a) multiple interfaces for intersectoral communication, (b) communication through a neutral, common and shared BIM standard A main motivation of this development was the goal to replace the huge number of interfaces 2 that would be needed without a neutral BIM standard (or shared project model see Figure above). The technology chosen at this time was the EXPRESS modelling language (ISO ) based on the object-oriented concept and several modelling principles trying to ensure an easy to use and extendible model structure. The result is meanwhile a large and complex schema specification that follows a fixed release cycle for extending the scope of the IFC standard. Extensions must be agreed in a group of international experts and then added to a new release of the standard. This is a rather slow process, not necessarily supporting all original requirements and is adding more complexity to the IFC data structure. Accordingly, there are disadvantage like complexity, slow extension cycles and the limited scope leading to solutions based on Semantic Web and Linked Data technologies. However, the effort taken by the LBD community to translate IFC into an OWL ontology shows that there is still a need for IFC. A main driver for using Semantic Web and LBD is the need to connect building data to other data sources, in particular if that data is already available in an open standard like CityGML or out of scope for BIM like weather data. The Semantic Web community is already working on the Web of Data vision being a large, interconnected data source for any kind of data queries. For instance it would be interesting to publish and interlink building data to work on smart city scenarios. The technology developed for that vision is 2 For n software tools with n proprietary data formats a number of n*(n-1)/2 interfaces would be needed. Page 18 of 91

19 seen as a sound basis not only for data publication (and the support of the web of data vision) but also for a lot of other AEC specific data management topics. 2.2 Link approaches Integration and linking of different data sources is a common topic for nearly all of the use cases. Accordingly, several approaches have been made to solve related issues. These approaches were discussed in detail during the 2016 ECPPM workshop on Sharing Interlinked Building Data chaired by Seppo Törmä. A summary of this discussion is given below COINS The European funded project COINS (Construction Objects and the INtegration of Processes and Systems) 3 is an open BIM standard that is developed since 2009 by a Dutch consortium of various governmental authorities, contractors, educational and research institutes (Nederveen et al., 2010 [11]). COINS supports the exchange of containers for BIM, infra, and GIS related data. In this approach, models and documents can be combined in a container (a ZIP file with a standard folder structure), see Figure 4. Each information object in a container has its own identifier (URI). An additional OWL file is then provided in the container which describes how these information objects are related or linked to each other. While the COINS approach is comprehensive and identifies many of the issues for linking data, and the use of containers can be conceptually useful for those not familiar with how data is structured on the web (i.e. many of the potential stakeholders), if this data is described purely in RDF (see 2.2.3), it could be accessed using existing approaches already developed for data on the web without the need for containers [12]. Figure 4: Global architecture of a COINS-compatible Building Information System (CBIS).The blue area marks the actual CBIS, while the gray objects describe the interaction environment. 3 Page 19 of 91

20 2.2.2 Multi-Model Container The concept of Multi-Models is also being actively developed by TU Dresden, since Multi-models also work on the principle of exchange containers or MMC. These can be combined with separate link models to provide linking (see Figure 5). Figure 5: Example of a Multi-Model Container including different domain models connected through a separate link model. There can be realized as a compressed archive file which contains all models, as a Multi-Model that contains only the links and refers to the linked resources outside of itself, or as a message that contains a link to a file which again contains links to those link models. The container possesses an (XML-based) description of its contents and provides information about the subjects, detailing and data format as well as the creators or contributors of each elementary model. These elements of different elementary models are connected/linked via unique identifiers (IDs) [12]. These mechanisms support interlinking the BIM domain models with other models, like climate and user behavior models, BACS and ESIM. Like the COINS approach, multimodels provide a comprehensive method for linking models. Like COINS, the MMC approach could benefit from the Linked Data approach, as links could equally be managed through the use of RDF Linked Data based on Semantic Web Technologies Linked Data (LD) is an approach to expose, share, and connect related data on the Web [11][13]. It uses W3C standards such as the Resource Description Framework (RDF) as a data model for representing structured content and Uniform Resource Identifiers (URIs) as a unique identifier of information resources. RDF describes information as a directed graph, where a set of nodes are connected with directed edges [14]. RDF defines a triple consisting of a subject, predicate and object that can be queried using SPARQL [15]. LD is implemented using standard Web protocols and dereferencing mechanisms. Due to this fact, the LD cloud is inherently associated with human-readable descriptions (mainly in HTML) of the resources described in RDF. This implies that RDF and textual (HTML) content do not just live next to each other on the Web of Data (Figure 6), but are also indirectly connected to each other. Page 20 of 91

21 Figure 6: Web of Data, In modern AEC, data related to different domains such as: building geometry and topology data, sensor data, behavior data, geo data etc. are generated and consumed across BLC stages. The combination of BIM and LD has the potential to meet the requirements for storing and sharing those data. However, data must be represented or at least tagged using RDF. Several research and standardization initiatives have been developing linked data representations for those different domains, for example FIEMSER [16] and SAREF [17] for devices and energy domains, Semantic Sensor Network (SSN) for devices domain [18], Adapt4EE Occupancy Ontology for behavior domain [19], Geonames for geolocation domain [20], and also KnoHolEM and Serum-iB which cover multiple domains [21], [22]. In addition to the development of new ontologies further research is done to convert existing standards to Semantic Web technology. For instance generic conversion strategies have been developed for transforming existing AEC data to Web-enabled resources and for linking web-enables AEC data like IFC, gbxml etc. to other Web resources. Important agreements have been reached within the LBD community and meanwhile ifcowl is a draft standard published by buildingsmart. ifcowl [23] is generated by transforming the well-established IFC standard defined in EXPRESS schema into OWL to enable reasoning and querying using SPARQL and to improve the extensibility of the data model. A similar approach has also been developed to transform XSD into OWL [24]. Page 21 of 91

22 2.3 Use of LBD in research projects SWIMing analyzed the use cases of numerous EeB research projects funded by EU (see D1.1 and D1.2) and examined the use of linked data to address those use cases. Most of the projects required some kind of linking of data to facilitate the integration of heterogeneous data sources. However, even though model linking seems to be a common challenge not all projects are using Semantic Web technologies to support linking and data management issues. There are various reasons for using other solutions like for instance the technical barrier to convert BIM/IFC and other legacy data sources to an RDF graph or uncertainty about the status of ifcowl before it was accepted by buildingsmart for standardization. This chapter shortly describes a few projects that are already using Semantic Web technologies. A strong motivation for using Semantic Web seems to be the need to manage huge amounts of data, in particular if different data representation formats are used like IFC (STEP) and CityGML (XML), if other Web-enabled data shall be integrated or research benefits of Semantic Web like reasoning are of interest. The project OptEEmAL [25] for example develops a platform to support an optimized, integrated and systematic design for building and retrofitting projects. The platform supplies necessary information to simulation tools based on given district condition. Linked data will be utilized to facilitate the integration of highly heterogeneous data, such as building data, district/city data, weather data, sensor data, etc. The existing linked-data schemas to represent the data are considered to be use, i.e. ifc2owl for building data, CityGML for district/city and Semantic Sensor Network (SSN) for sensor data. Τhe eeembedded [26] project develops a holistic energy system information model and an integrated information management framework for designing energy-efficient buildings and their optimal energetic embedding in the neighborhood. The linked data approach is considered to interlink multiple physical and mathematical models which are based on industry standards, such as IFC, STEP, and CityGML. The DAREED [27] project develops a platform that provides services to citizens, energy providers, and policy makers to improve the energy efficiency in the smart city context. Those services generate and consume data from multiple, originally unrelated domains, where in most cases data translation and communication links are necessary to ensure interoperability. The linked data approach in DAREED interlinks the generated and existing data to facilitate the data integration. DAREED reuses and interlinks existing models and vocabularies from heterogeneous domains to address the project use cases, for instance IFC and SAREF for product model, SSN for device model, OM and data cube ontology for building data, and GeoNames, Schema.org, and Basic Geo for geolocation data. Linked data can be expressed using OWL to enable the logical expression and rule integration. The KnoHolEM [28] project, for example, uses OWL to formalize knowledge of multiple actors having different knowledge background, such as facility managers and Page 22 of 91

23 electrical engineers. OWL can be integrated with rules represented with SWRL to enable reasoning in the model. KnoHolEM integrated different domains i.e. building element, building device, behavior, actor, etc. into an OWL ontology. Further information, regarding these projects along with other projects as well, is available in the Wiki [7]. 2.4 Challenges and research questions As shown in the previous chapter a number of research projects are already using Semantic Web technologies not only for interlinking different data sources but also to query and manipulate building data or to run various kinds of simulations. There are a couple of challenges when using Semantic Web and LBD. Some of them are of more general nature and some are specific to this technology. Benjamins et al. [29] have identified six main challenges from using the Semantic Web: Availability of content; Ontology availability, development and evolution; Scalability; Multilinguality; Visualization and Stability of Semantic Web languages. Ten years later and these challenges are still a reality, with Linked Data providing solutions as well as challenges. Focusing on the data models availability, which is inextricably connected with the other five challenges, the SWIMing project has worked on analysing existing issues both in regards to previous work (publications, projects, events, etc.) but also through active engagement with involved stakeholders in domains such as Research, Academia, Industry, Energy, Architecture, Engineering and Construction, towards highlighting essential shortcomings that will act as deterrent factors for future work. With the Q&A sections in the SWIMing clustering workshops leading the findings, an overview of the issues/challenges still pending is provided below: How to improve or even automate the identification of ontology alignments (see word matching algorithms)? As the number of ontologies keeps increasing (see following sections) and the overlapping among them gets bigger due to different representation of the same entity, there is a necessity to identify ontology alignments (ontology matching). Shvaiko et al. [30] have analysed this issue in detail and presented eight general challenges for ontology matching, addressing of which should facilitate and even accelerate the progress of the ontology matching field. Large Scale Evaluation, Efficiency, Page 23 of 91

24 Use of Background Knowledge, Matcher Selection and self-configuration, User Involvement, Explanation Documentation, Alignment Infrastructure. Following their work, Otero-Cardeira et al. [31] extended that list to fourteen more detail points that need to be addressed: Automated acquisition of reference alignment for evaluating large scale matching systems. Creating large datasets to asses matching algorithms. Define good tools that are easy to use for non-experts. Develop high quality and fast intelligent combinations of string-based and new semantic-similarity measures. Holistic ontology matching. How to effectively complement automatic computation with human validation. How to minimize involvement of users when turning matches into mapping. Human readable explanations for matches. Improving the mapping process through semi-automatic machine learning. Integration of domain knowledge into alignment techniques. Learning what metrics to choose in which scenario. Precision and Recall of automatic methods. Scalability and parallelization of the matching. Semantic mapping. Most of these points were discussed between ontology and data modelling experts in the SWIMing workshops, and are integrated as main features of the BIM*Q tool. How to foster reuse of existing ontology definitions? Ideally, use of existing ontologies is something that can provide further insight in data models that are already adopted by commercial tools and industrial stakeholders in regards to new aspects and additional use cases. However, in most cases, research projects tend to create new models when an existing one isn t sufficiently documented, doesn t fully cover their needs, isn t based on a specific standard, etc. As Simperl [32] points out, ontology reuse is quite the troublesome task since it is based significantly on the proper ontology alignment as well as the human intervention, which leads to the need for a task and context-oriented approach to ontology reuse. Discussion on this matter highlighted the fact that there is a need for defining methods and tools that will allow new requirements to be handled by compiling existing ontology standards with only very few extensions [32]. Page 24 of 91

25 How to manage linked data, in particular in a collaborative environment where data is constantly updated? How to keep consistency; deal with access rights and data versioning. What is the right collaboration strategy? This is an active issue with little literature background and refers to the need for active support and constant extension of existing ontologies towards supporting new requirements in terms of concepts, technologies, and tools. Quite a few ontologies and data models that were once complete and could provide valuable infrastructure aren t selected due to the fact that aren t maintained anymore, while others that are still actively engaged do not evolve quick enough to support new features and attributes. How is it possible to effectively query information from highly heterogeneous data sources? Another well-known and quite studied problem is the heterogeneity of available data sources in the Semantic Web and the LBD. Querying heterogeneous and distributed third-party databases is one of the most time and cost consuming effort in retrieving useful information from the Semantic Web. Freitas et al. [33] identified three high-level categories of approaches for querying linked data: strategies inherited from the information retrieval (IR) space in which keyword search is mixed with elements from structure queries; natural language queries; and structured SPARQL queries over distributed datasets. The semantic gap between the way users express their information needs and the representation of the data is identified as the major origin of the discussed issue. Once again, by properly aligning existing ontologies and data models, it would be possible to widely mitigate this challenge. Do we still need a shared vocabulary (maybe as a simplified version), which often means a compromise for a specific use case, or does LBD allow to focus on highly optimized, use case specific ontologies? There is some discussion over how generic and shared vocabularies tend to limit the contained knowledge in terms of both detail length and depth. Through the opinions shared it seems that LBD can open a new way of exploring specific ontologies. This is a question that remains to be seen how the Linked Data community will handle in the years to come. BIM/IFC is an interesting example to that challenge, and its active role is still under evaluation. Through the work presented in this document and the overall effort of the SWIMing consortium the above issues have been identified as active challenges, and in some degree Page 25 of 91

26 valuable insight has been provided towards aiding the Linked Building Community and future EeB projects into coming a step closer to optimally dealing with them and even solving some of them in the years to come. The following chapters present some of the most interesting results from analyzing EeB projects Use Cases, both in terms of BLC Stages and Data Domains, leading to the Chapter 5 which concludes this work with the SWIMing recommendations and some further discussion regarding BLCEM process and data management. Page 26 of 91

27 3 Approach for Evaluation of Collected Use Cases H Overall vision for sharing use case definitions The methodology for generating and publishing BIM data has been already presented in D2.2 and D1.2. The initial steps in this methodology consist of capturing use cases. For EeB projects, the application of the methodology has been conducted using a combination of the Wiki and also the BIM*Q tool which not only supports the collection of requirements for a single EeB research project, but also supports sharing and reuse of definitions with other research projects, which in turn can increase the impact of those projects by promoting their outcomes. New projects can also examine these outcomes to discover where projects have successfully aligned their data requirements with existing standards, like IFC, reducing the effort of undergoing this process from scratch. Accordingly, the motivation of the approach in SWIMing and the use of a tool like BIM*Q is not only to share requirements and all related definitions between project partners, but also to share it with other projects, especially ones that are at their beginning. The BIM*Q tools consists of a web-based interface, which supports the modelling of data requirements and specifications that are relevant to implement a data exchange scenario. The initial steps in the SWIMing methodology consists of identifying the involved stakeholders (who is responsible to deliver that information), relevant stages and processes (when and why is something needed) (Steps 1 3). Next, it enables the capture of relevant data exchanges in a structured way (Step 4). Figure 7: Use cases in BIM*Q which have indicated potential or actual alignments with IFC4 for data exchange BIM*Q has features to specify a use case, which includes to label and describe processes and stakeholders and to capture at a conceptual level the different data requirements. These can then also be associated with the processes and stakeholders by defining if a particular property is needed as input and who is responsible to maintain that property. The conceptual data model may also be further annotated with suggestions for alignments with existing standards, for example, IFC or CityGML (Step 5). In Figure 7 a use Page 27 of 91

28 case has been selected for the purposes of discovering other use cases which share the same alignments to an existing data schema. Using the BIM*Q tool, the user selects a data schema, in this case it is the IFC4 data schema, and then gets a list of use cases which are also using that data schema. Further details about which parts of IFC4 are being used can be explored by clicking on the appropriate use case. A key feature of BIM*Q is that alignments can be made between identified concepts and ontologies as a precursor to identifying potential links, where more than one ontology is required to meet the requirements of a use case. The use of LD can of course provide many of the benefits we have highlighted previously when conducting the linking process. As more use cases are added, more knowledge about concepts and their relation a provided, and the potential to make better informed decisions about the most suitable candidate concepts for linking occurs. Accordingly, it will be easier for everybody to be part of a joined continuous improvement process so that existing solutions can be reused and jointly extended. 3.2 Use cases overview - link to domains and BLC stages The use cases from different EeB research projects (see D1.1) are systematically collected and captured in the SWIMing Wiki [7], in a standardized format (below figure). Figure 8: Use case standardized format 4 Despite the standardization of the information format, it is still difficult for the user to identify which use cases are similar to his based purely on a Wiki representation, as it results in lists of use cases which they must search through. Therefore, SWIMing also developed a web-based overview of use cases [8], whose screenshot is depicted in Figure 9. The overview is generated automatically by a software that automatically read and parse the use case entries in the Wiki. This parser, developed by SWIMing partners led by KIT, allows real-time automatic update of the web-based overview based on changes performed on the Wiki. The web-based overview presents a use cases classification based on BLC stages, where data are generated and also where data are consumed. The use cases (UC1, 4 Page 28 of 91

29 UC2, UC3, etc.) are also classified based on the domain of the generated/consumed data (see Figure 9). Each box contains links to the Wiki page describing the corresponding information. If the user hovers on a use case box, the corresponding project on the bottom of the matrix will be highlighted. It also happens vice versa, if the user hovers on a project box. Therefore, the user can quickly identify which use cases correspond to a certain project, domain or BLC stage. As the overview, developed by TCD, is based on HTML5, CSS3 and JavaScript, extending or changing the look and feel of the interface can be achieved relatively quickly. This particular view is intended to provide additional information for people interested in EU projects in the EeB domain. Other views are possible which only include use case descriptions, or potentially, alignment with other themes and clusters, for example, those explored in the sister CSA EEBER s [34]. Figure 9: Screenshot of Use Case Classification Table Page 29 of 91

30 3.3 EeB Project Use Cases Assessment This section provides a short break down of projects according to BLC stages and Data Domains as derived from the Use Case overview. In section a more in-depth analysis is carried out with respect to the data models each use case requires. During the analysis, we only include one use case per project. This decision was made to ensure that projects with many use cases did not affect the weighting of models used by a particular project. It should be assumed that for each project, use cases often can be broken down into sub use cases. So we picked the use cases which were most representative of the project in terms of data model coverage. This results in a total of 32 use cases. Of these 32 the EeBGuide is a project which addresses Operational Guidance for Life Cycle Assessment Studies of the Energy Efficient Buildings Initiative. Therefore, we do not include it here as it does not set out to itself address energy reduction, but rather provides guidelines in the form of recommended models for life cycle assessment to support other EeB projects achieve greater energy efficiency, e.g. ISO 14040, EN 15804, and EN This leaves 31 projects analyzed here. The following sections provide findings along with a short analysis of projects broken down according to BLC stage, and according to data domains. More information on what each BLC stage and Domain represent can be found in D1.1 and also the Wiki Analysis by BLC Stages This analysis looks into the correlation between Use Cases and the Building Life-Cycle stages, i.e. when data is generated and utilized. Although it is evident that most solutions utilize information from the BLC stage that are created for, some solutions require or are enhanced through the use of data which is generated in other (generally earlier, but not in the case of re-design and operation) BLC stages. Where project use cases required data generated in other BLC stages to enable their solutions, these are noted with the additional advice that for further information reference the Wiki, BIM*Q and associated project information to discover more about this data. Here we focus on the data that is consumed by processes, as this is where, it is assumed, the energy efficiency take place. Design Stage Only four projects (Proficient, Design4Energy, CityOpt and Streamer) Use Cases are directly developing solutions which address the design stage. That is, they are creating a solution which will improve the energy efficiency of the building as a result of optimized building design. On the other hand, 21 Use Cases require data generated during the design phase of the building. This means that data is either required, or will enhance the solution when applied during the later stages. Page 30 of 91

31 25 Design Stage Directly Address this Stage Require Data to be Generated at this Stage Not Relevant 0 # Use Cases Construction Stage: Figure 10: EeB Use Cases for the Design Stage None of the analyzed projects are directly addressing optimization of the construction process. Of the 31 projects, only two have use cases which require data generated during construction (Design4Energy, Hit2Gap). This means that these projects require additional information which is generated during the construction stage Construction Stage # Use Cases Directly Address this Stage Require Data to be Generated at this Stage Not Relevant Commissioning Stage: Figure 11: EeB Use Cases for the Construction Stage None of the analyzed projects are directly addressing optimization of the commissioning process. Of the 31 projects, only three have use cases which require data generated during commissioning stage (Design4Energy, GreenCom and Hit2Gap). This means that these projects require additional information which is generated during commissioning. Page 31 of 91

32 Commissioning Stage # Use Cases Directly Address this Stage Require Data to be Generated at this Stage Not Relevant Operational Stage Figure 12: EeB Use Cases for the Commissioning Stage The vast majority of projects (27) address optimization of operation. Operational solutions include new methods for monitoring and controlling the building environment (devices, occupants). They also include new decision support tools for FMs and building operators, and solutions which address behavioral change of occupants. The projects which look at these types of solutions are; Ideas, Origin, Proficient, ICT-Beams, EEPOS, E-Balance, Desgin4Energy, Seam4US, Resilient, EeEmbedded, Semanco, KnoHolEM, NewTrend, DAREED, NRG4Cast, GreenCom, Dimmer, CossMic, Ambassador, Campus21, S4EoB, Tribute, CityOpt, Performer, SmartKye, Cascade, Hit2Gap and E- Balance. All but one project (Streamer) also make use of data generated during this stage Operational Stage # Use Cases Directly Address this Stage Require Data to be Generated at this Stage Not Relevant Figure 13: EeB Use Cases for the Operational Stage Page 32 of 91

33 Re-design (Retrofitting, Refurbishment, Reconfiguration) Stage The second largest BLC stage addressed is re-design (11 projects). These projects are directly addressing solutions which improve the energy efficiency through re-design. This covers the installation of new devices/equipment, reconfiguration of existing devices/equipment, and retrofitting and refurbishment with new energy efficient materials, facades, etc. The projects which address this stage are; OptEEmAL, EcoDistrict, Proficient, Design4Energy, Seam4US, NewTrend, GreenCom, CityOpt, Hit2Gap and Streamer. 14 projects make use of data generated during this stage. It should be noted that redesign feedback back into operation, and the re-design cycle can be seen in terms of the full life cycle, i.e. design, implementation, testing, operation, re-design and disposal/recycling. Therefore changes made during re-design will be important for the operational stage of the building. Additionally, the potential exists for these finding to feed into new building design. Re-design Stage # Use Cases Directly Address this Stage Require Data to be Generated at this Stage Not Relevant Figure 14: EeB Use Cases for the Re-Design Stage Demolition Stage None of the 31 projects set out to address this stage. From these findings, we choose to focus on the BLC stages which are utilized by projects when analyzing the different data domains. These are the design, operation and redesign stages, which align with the major clusters as presented in D Analysis by Domain Here only the domains addressed by use cases are examined. It should be noted, that Data and Communications are here presented as one domain, the same for Control and Behavior. This is because these are quite related. For communications, often the type and structure of the data message is relevant and related to the type of communication Page 33 of 91

34 protocol and constraints related to this. Similarly for Control, control systems are highly dependent on behavior models, for example, occupancy schedules. We also give a breakdown of the types of domains which are covered for the BLC stages that solutions occur. Product Of the 31 use cases, 14 are using data models which cover product modelling. These projects are; Proficient, Design4Energy, eeembedded, NewTrend, DAREED, Seeds, GreenCOM, DIMMER, Cossmic, Campus21, Ambassador, CityOpt, Streamer, Hit2Gap, SmartKye. This can be further broken down by the three BLC stages solution address; Design: 3, Operation:13, Re-design: Product Domain #14 UCs # Use Cases Design Operational Re-design Figure 15: EeB Use Cases for the Building Product Domain Devices 28 are using data models which cover device modelling. These projects are; OptEEmAL, EcoDistrict, Ideas, Origin, Proficient, ICT-BEAMS, EEPOS, E-Balance, Design4Energy, RESILIENT, eeembedded, KnoHolEM, NewTrend, DAREED, NRG4Cast, Seeds, GreenCOM, DIMMER, Cossmic, Campus21, Ambassador, Performer, CityOpt, Tribute, S4ECoB, Hit2Gap, Cascade, SmartKye Broken down by the three BLC stages solution address; Design: 3, Operation: 25, Redesign: 9 Page 34 of 91

35 Devices Domain #28 UCs # Use Cases Design Operational Re-design Figure 16: EeB Use Cases for the Building Devices Domain Control and Behavior 27 are using data models which cover control and behavior modelling. These projects are; OptEEmAL, EcoDistrict, Ideas, Origin, Proficient, EEPOS, Design4Energy, SEAM4US, RESILIENT, eeembedded, E-Balance, KnoHolEM, NewTrend, NRG4Cast, GreenCOM, DIMMER, Cossmic, Campus21, Ambassador, Performer, CityOpt, Tribute, S4ECoB, Hit2Gap, Cascade, SmartKye. Broken down by the three BLC stages solution address; Design: 3, Operation: 25, Redesign: Control & Behaviour Domains #27 UCs # Use Cases Design Operational Re-design Figure 17: EeB Use Cases for the Building Control & Behavior Domains Data and Communications 22 are using data models which cover data and communications modelling. These projects are; Ideas, Origin, Proficient, ICT-BEAMS, EEPOS, E-Balance, SEAM4US, eeem- Page 35 of 91

36 bedded, KnoHolEM, NewTrend, DAREED, Seeds, GreenCOM, DIMMER, Campus21, Performer, CityOpt, Tribute, Streamer, Hit2Gap, Cascade. Broken down by the three BLC stages solution address; Design: 3, Operation: 21, Redesign: Data & Communications Domains #22 UCs Design Operational Re-design 0 # Use Cases Figure 18: EeB Use Cases for the Building Data & Communications Domains Geolocation and Weather 13 are using data models which cover geolocation and weather modelling. These projects are; Ideas, Origin, Proficient, SEAM4US, eeembedded, KnoHolEM, NewTrend, DAREED, DIMMER, Ambassador, CityOpt, Streamer. Broken down by the three BLC stages solution address; Design: 2, Operation: 13, Redesign: 3 Geolocation & Weather Domains #13 UCs # Use Cases Design Operational Re-design Figure 19: EeB Use Cases for the Geolocation & Weather Domains Page 36 of 91

37 Energy 28 are using data models which cover energy modelling. These projects are; OptEEmAL, EcoDistrict, Ideas, Origin, Proficient, ICT-BEAMS, EEPOS, E-Balance, Design4Energy, SEAM4US, RESILIENT, eeembedded, KnoHolEM, NewTrend, DAREED, NRG4Cast, GreenCOM, DIMMER, Cossmic, Campus21, Ambassador, Performer, CityOpt, S4ECoB, Streamer, Hit2Gap, SmartKye. Broken down by the three BLC stages solution address; Design: 3, Operation: 25, Redesign: 10 Energy Domain #28 UCs # Use Cases Design Operational Re-design Figure 20: EeB Use Cases for the Energy Domain Analysis of Findings The main data domains covered across use cases are related to Devices (28), Energy (28), Control and Behavior (27) and Data and Communications (22) (Table 1 - Figure 21). This is to be expected due to the high number of use cases which address the operational stage. Here many solutions address the devices in the building, their control and communication and monitoring of building state and behavior. Further breaking down the data by BLC stages (Table 2 - Figure 22), it becomes clear that at the Design stage all domains are equally important, with the exception of geolocation and weather. This reflects the requirement that design integrates complex 3D solid models to conduct simulations in order to determine the most optimized design with respect to energy efficiency. During Operation, some solutions do simulation, but others do not and so do not require knowledge of the building geometry or elements (walls, u-values etc.) as they address the monitoring and behavior of spaces and the devices and occupants in those spaces. Similarly during Re-design, building elements like walls and windows require replacement, and, once again product modelling is important. Thus the proportion of use cases covering product in re-design is higher with respect to the other domains. Page 37 of 91

38 Table 1: Break down of Project Use Cases by Domain Product Devices Control & Behavior Data & Comms Geolocation & Weather Energy Total Product Devices Control and Behaviour Data & Communication Geolocation & Weather Energy # Use Cases Figure 21: EeB Use Cases per Data Domain Table 2: Break down of Project Use Cases by Domain and BLC stage Product Devices Control & Behavior Data & Comms Geolocation & Weather Energy Design Operation Re-design Design Operational Re-design Product Devices Control and Behaviour Data & Communication Geolocation & Weather Energy Figure 22: EeB Use Cases per BLC and Domain Page 38 of 91

39 The installation and configuration of devices and control systems (wireless systems for example) plays the most significant role during this stage, as can be seen by the high numbers in related domains. Geolocation and weather are important for running energy simulations, and so these have some presentation in operation where it is assume energy simulations are being conducted. They are also relevant for district modelling, and so they provide a link to district energy management, which several projects address (e.g. CityOpt, Dimmer). From this analysis of the work conducted in SWIMing and which covers steps 1-3 of the methodology, we derive some interesting findings which can help to direct our analysis of the data models which these projects map to. In the next section we explore steps 5-8 and provide further analysis of the data models being used across the projects based on the different BLC stages and data domains covered. We then give some recommendations regarding the use of these data models for EU projects, which can either; provide for their requirements (Step 5), be extended (step 6), be linked (step 7) and which can then be used for publishing their data (step 8). Page 39 of 91

40 4 Used Ontologies and Standards In this chapter we present ontologies and standards extracted from our analysis of EU EeB project deliverables, and through our interaction with those projects developing their use cases on the Wiki and through the use of the BIM*Q tool. The ontologies and standards found cover a variety of research and industry sectors with significant differences in their size, complexity and application domains. Each was analysed and some of the most common characteristics are presented below along with some interesting findings and statistical results. This list builds upon existing work presented in D1.1 and D2.2, and conducted by the R4SC project 6. Before we present the different ontologies and our analysis, the next section describes where this information can be found. 4.1 Use cases and ontologies To support the evaluation of the captured requirement definitions SWIMing has developed another overview about the usage of ontologies per use case. For each use case in the Wiki, ontologies or data standards which are used are listed. Appendix B presents a table of all the ontologies used or which are referenced by that particular use case in the Wiki. A snapshot of the table is shown in Figure 23. This kind of evaluation for instance shows that most use cases require more than one ontologies, which clearly indicates the need of Linked Building Data. Figure 23: Snapshot of Table of Use Cases Mapped to Ontologies It also shows that for those projects, EeB topic, which have been modelled in the BIM*Q tool, BIM/IFC is the most important ontology. Other standards like CityGML, gbxml, or obix may follow IFC (depending on BLC stage). These typically have a specific focus and therefore are not relevant for each use case. Other ontologies, in particular those with only one use case usage are most likely the result of a specific project and are public, but not standardized. Therefore, they deal with project specific solutions that are more difficult to reuse in other use cases or environments and typically are less thoroughly documented. 6 Page 40 of 91

41 It should also be noted, that a large number of standards, protocols, libraries, etc. where discover during the SWIMing EeB projects clustering and Use Case identification which were indirectly references, or are protocols rather than data models. This have not been included. A full overview list is presented in Appendix C. 4.2 Description of referenced Ontologies and Standards Here we look at the ontologies themselves in greater detail and provide some analysis with respect to the use cases, BLC stages and data domains. After these are presented an analysis of these models is presented with reference to the different BLC stages and domains IFC (including ifcowl) Language(s): EXPRESS (reference specification), OWL (derived from IFC EXPRESS, with information loss), XSD (derived from IFC EXPRESS with information loss) Syntax: RDF/XML, N3, Turtle Natural Language: English Current Version: IFC4 Online Availability: Yes - Documentation: Domains: Building Product, Building Device, Building Control, Building Data, Building Communication, Energy, Actors, Geolocation and Weather Standard: yes, international standard developed by the non-profit organization buildingsmart, accepted as ISO Extensibility: through property set mechanism (key-value pair attached to objects), unknown elements can be captured through proxy elements Linking: enables to set references to external sources (documents, classification systems); other buildingsmart developments: ifczip container, extension approaches of the multi-model container ( Linked UC(s): UC1a/b, UC3, UC4, UC7, UC13, UC16, UC18, UC19, UC27, UC34, UC44, UC53, UC54, UC59, UC64. SWIMing Findings/Comments: It is an object-based file format with a data model developed to facilitate interoperability in the architecture, engineering and construction (AEC) industry, and is a commonly used collaboration format in Building information modeling (BIM) based projects. The IFC data model is the one mostly found within EeB projects and is linked to almost one third of the SWIMing Use Cases (16 of the 31 UC(s)). As such, it consist the ontology/model that best describes the requirements derived from EeB projects and BIM aspects. With a variety of AEC tools using IFC as a primary data format (i.e. Autodesk Revit, ArchiCad, etc.), and the multi-domain coverage, IFC consist one of more complete data models for EeB projects CityGML Language(s): XSD, (also available in OWL) Syntax: XML Natural Language: English Current Version: 2.0 Online Availability: Yes - Page 41 of 91

42 Documentation: Domain(s): Geolocation/District Standard: OGC Standard Extensibility: Through the use of Application Domain Extensions (ADE) : Specific hooks in the CityGML schema allow to define application specific extensions, for example for noise pollution simulation, or to augment CityGML by properties of the new National Building Information Model Standard (NBIMS) in the U.S. Linking: There have been several research initiatives examining the linking of GIS and BIM data for different scenarios, e.g. [35], [36], [37]. CityGML supports linking through the capability to extend the standard with a specific Application Domain Extension (ADE) [38]. Linked UC(s): UC1a/b, UC4, UC7, UC13, UC16, UC64 SWIMing Findings/Comments: The information in CityGML about buildings is very basic, when compared to standards like IFC. Nonetheless, for use cases which require, for example, only simple visualization of a buildings envelope, CityGML may be sufficient, which is evident from the seven (7) SWIMing Use Cases where it was utilized. If more detailed information is required, for example, about the structure of the building and about the elements that make up the building, linking IFC and CityGML can provide the bridge between District and Building energy management Common Information Model (CIM) Language(s): MOF (Managed Object Format), XSD, UML, XSD, OWL Syntax: XML, RDF Natural Language: English Current Version: 2.0 Online Availability: Yes - Documentation: or Domains: Building data (metering data) Standard: IEC and DMTF Standard Extensibility: The CIM common schema can be extended through the use of extension schemas to meet different use cases, for example, related to energy storage [39], or other technology specific extensions. This can mean adding a property to an existing class or subclass of the CIM, adding a new class or set of classes to the CIM or creating your own namespace and schema 7. Linking: The linking of CIM for smart grids has been specifically addressed in the Dutch project CERISE 8. They have developed a CIM profile for Smart Grids 9 Linked UC(s): UC4, UC7, UC15, UC53, UC54 SWIMing Findings/Comments: CIM is referenced in a number of project use cases due to its central role as a standard in electrical transmission and its relation to IEC 61970, which deals with APIs for energy management systems (EMS). The application of CIM in Page 42 of 91

43 EU projects though is harder to determine, which is depicted in the small number of Use Cases using this schema (5 SWIMing UCs). For example, the RESILIENT project referred to its use at the 4 th SWIMing workshop [40] but in later discussions, the use of the standard was no longer being considered. Nonetheless, CIM provides clear documentation for anyone familiar with UML diagrams, and can potential meet the exchange requirements within the smart cities and districts domains Green Building XML Schema (gbxml) Language(s): XSD Syntax: XML Natural Language: English Current Version: 6.0 Online Availability: Yes - Documentation: Domain(s): Building Product, Energy, Geolocation Standard: No, although has wide adoption by leading BIM vendors including Autodesk, Trimble, Graphisoft, and Bentley. Extensibility: gbxml can be extended through the use of XSDs. Linking: As a purely XML based standard, linking to other domains is very limited. Linked UC(s): UC4, UC16, UC19, UC34, UC44 SWIMing Findings/Comments: gbxml is a popular choice for exchange data required for energy simulation. NewTrend has evaluated both IFC and gbxml for its own use case, and concluded that currently gbxml is more appropriate as it has better support for aspects such as thermal and related characteristics, necessary for energy modelling. The bottom up approach may also make it easier for new developers to work with gbxml, as they do not have to learn the complex relationships required to understand and use IFC. This comes at the expense of the greater expressivity of IFC, and the wider range of domains which IFC supports. However, gbxml has limited and specific role in EeB projects, covering mostly building aspects representation which explains why it is aligned only with five (5) Use Cases through the SWIMing analysis Open Building Information Exchange (obix) Language(s): XSD Syntax: XML, CoAP, EXI, and JSON Natural Language: English Current Version: 1.1 Online Availability: Yes - csprd02.html Documentation: Domain(s): Building Control, Building Devices, Building Data and Communications Standard: Organization for the Advancement of Structured Information Standards (OA- SIS) Extensibility: Through the use of XSDs. Linking: As a purely XML based standard, linking to other domains is very limited. Linked UC(s): UC4, UC7, UC44 Page 43 of 91

44 SWIMing Findings/Comments: While obix is referenced in a few EU projects, clear examples of its use are still hard to establish. obix support for multiple popular BCS protocols (BacNET, LonWorks, ModBus, KNX, etc.) through standard RESTful Web Services-based interfaces has the potential to provide better interoperability to enable building control. The SWIMing analysis showed that three (3) technical control/management Use Cases used obix as the schema for building control Gemeinsame Ausschuss Elektronik im Bauwesen XML (GAEB- XML) Language(s): XSD Syntax: XML Natural Language: German Current Version: 1.0 Online Availability: Yes - Documentation: Domain(s): Building Product, Energy, Geolocation Standard: A German Joint Committee for Electronics in Construction Standard Extensibility: Through the use of XSDs. Linking: XSD schemas can be linked or imported. Several use cases have looked at incorporating GAEBXML into a wider energy efficient BIM framework through the use of Multi-Models. Linked UC(s): UC13, UC16, UC44 SWIMing Findings/Comments: GAEB-XML is a standard used in Germany, and as such, other more widely used standards would be more appropriate. Three (3) Use Cases were linked to this schema, which is very limited due to language restrictions Semantic Sensor Network Ontology (SSN) Language(s): OWL Syntax: RDF/XML, N3, Turtle Natural Language: English Current Version: 1.0 Versions: Namespace has changed to a permanent W3C address Online Availability: Yes - Domain(s): Building Devices (Sensors) Standard: W3C Standard Extensibility: Using existing OWL approaches, for example the smart building domain [41] Linking: - Linked UC(s): UC4, UC46, UC59 SWIMing Findings/Comments: SSN, combined with the O&M ontology can provide most of the needs for modelling sensors and their measurements. It was recognized only in three (3) occasions SimModel Language(s): XSD, OWL Syntax: XML, XML/RDF Page 44 of 91

45 Natural Language: English Current Version: 1.2.2, (1.2.3 under development) Online Availability: Yes - Documentation: Domain(s): Building Energy Simulation Standard: No Extensibility: Yes, but would require input from Digital Alchemy Pro (current owners of SimModel) Linking: As a purely XML based standard, linking to other domains is very limited. Linked UC(s): UC1a/b, UC59 SWIMing Findings/Comments: This model is one of the few efforts to provide a data model that will cover the entire building operation for simulation purposes towards preventing information loss. It consists a rather new interoperable XML-based data model for the building simulation domain. Through alignments with other known formats, such as IFC and gbxml, the SimModel objects ontology moves away from tool-specific, nonstandard nomenclature by implementing an industry-validated terminology, however it s use is still rather limited in the EeB projects since only three (3) SWIMing Use Cases were correlated with SimModel Construction-Operations Building information exchange (CO- Bie) Language(s): OWL, XSD Syntax: RDF/XML, N3, Turtle Natural Language: English Current Version: 2.4 Online Availability: Yes Documentation: Domain(s): Building Devices, Geolocation Standard: Part of the NBIMS-US Extensibility: see IFC Linking: see IFC Linked UC(s): UC7 SWIMing Findings/Comments: COBie is based almost entirely to IFC and is used to deliver facility asset (equipment and spaces) information. Although it is more specific than the overall IFC, supports translation of the information through a more user friendly method (spreadsheets) and has been integrated to the United States National Building Model Standard, it s more of a specification than a standard for particularly applying the IFC standard. Through the SWIMing analysis it was found to be used in one (1) SWIMing Use Cases, where overlapping with IFC was expected buildingsmart Data Dictionary (bsdd - Formerly IFD) Language(s): XSD Syntax: XML Natural Language: Multi-Language Current Version: 1.0 Page 45 of 91

46 Online Availability: Yes - Documentation: Domain(s): Cross Domain Standard: Based on ISO Extensibility: Addition of more languages to already specified GUIDs is supported by joining the Community, while suggestions for new GUIDs can be made. Linking: As a purely XML based standard, linking to other domains is very limited. Linked UC(s): UC7 SWIMing Findings/Comments: bsdd can best be described as a mapping tool that can automatically translate the idea of a concept in one context or language to another. Although as a concept it is really intriguing and can solve the limitations that can be found from the use of different languages in various ontologies, its use has been found to be quite limited in EeB projects since only one (1) SWIMing Use Cases is using bsdd Suggested Upper Merged Ontology (SUMO) Language(s): SUO-KIF, OWL Syntax: KIF, RDF Natural Language: English Current Version : Online Availability: Yes - Documentation: Domain(s): Generic upper ontology that can potentially be used across all domains. Standard: No Extensibility: As an upper ontology, the purpose of SUMO is to provide generic concepts which can be extended with more domain specific knowledge. This can be done through standard OWL extensions. Linking: Standard RDF linking. SUO-KIF also supports expressing links, which support complex, axiom-based, formal interrelations to be expressed. Linked UC(s): UC53, UC54 SWIMing Findings/Comments: SUMO is an upper formal ontology that covers generic concepts and offers a superset model for many cases. However, due to that particular generic aspect the SUMO model has not been easily selected by projects for covering their requirements, which is evident by the fact that only two (2) Use Cases adopt this ontology. In most cases, projects tend to select ontologies that are more specific to their needs LandXML Language(s): XSD Syntax: XML Natural Language: Current Version: 2.0 Online Availability: Documentation: Domain(s): Geolocation Standard: No Extensibility: Through the use of XSDs. Page 46 of 91

47 Linking: As a purely XML based standard, linking to other domains is very limited. Research has been explored to support linking between LandXML and CityGML [42]. Linked UC(s): UC7 SWIMing Findings/Comments: LandXML provides capabilities to capture information relevant to new construction projects. Within the context of EeB though, LandXML is not seen as a central model of import, which is depicted by the fact that only one (1) SWIMing Use Cases have used that schema Collada Language(s): XSD Syntax: XML Natural Language: English Current Version : 1.5 Online Availability: Documentation: Domain(s): Building Product Standard: ISO/PAS Extensibility: Through the use of XSDs. Linking: As a purely XML based standard, linking to other domains is very limited. Linked UC(s): UC3 SWIMing Findings/Comments: Collada is a popular exchange format for 3D assets. Therefore it could play an important role for managing the visual representation of building products in the future as existing 3D tools keep advancing and new ones emerge day by day. However, for the time being only one EeB project has selected this schema and only one (1) of the SWIMing extracted Use Cases adopts it for 3D representation Open Standard Concept Modelling Ontology (CMO) with Extensions Language(s): OWL Syntax: Turtle Natural Language: English Current Version: - Online Availability: Yes - Documentation: Domain(s): Generic upper ontology, can potentially be used across all domains Standard: No Extensibility: Standard OWL extensibility. Linking: Standard linking with existing Turtle mechanisms. Linked UC(s): UC3 SWIMing Findings/Comments: CMO is an upper formal ontology that covers generic concepts and offers a superset model for many cases. However, due to that particular generic aspect, CMO has not been easily selected by projects (even less than SUMO) for covering their requirements, which is evident by the fact that only one (1) Use Case adopts this ontology. Page 47 of 91

48 Energy Enhanced BIM Model (eebim) Language(s): EXPRESS, OWL Syntax: SPF, RDF Natural Language: English Versions: first version defined by the HESMOS project, updated in the ISES (OntoBIM) and Design4Energy project Online Availability: None Domain(s): Building Product, Building Devices, Building Control, Building Behaviour, Building Communication, Building Data, Energy, Geolocation, Weather, Standard: partially reusing IFC (building structure, space boundaries) Extensibility: yes, other data sources can be integrated through model links Linking: eebim as a conceptual framework is implementing a multi-model approach based on links (using Semantic Web technology) Linked UC(s): UC13 SWIMing Findings/Comments: eebim is not a single consistent schema, and has evolved through several research projects. It is based on the IFC schema, but extended by all data that is needed for energy simulation. Thus, it already represents a Linked Building Data approach. Only one (1) Use Case is using this information model Extended Environments Markup Language (EEML) Language(s): XSD Syntax: XML Natural Language: English Current Version: Online Availability: Yes - Documentation: Domain(s): Building Devices, Building Communication and Data Standard: No Extensibility: Through the use of XSDs. Linking: As a purely XML based standard, linking to other domains is very limited. Linked UC(s): UC4 SWIMing Findings/Comments: EEML is a protocol for sharing sensor data between remote responsive environments, both physical and virtual. Although EEML was used by the ICT-BEAMS project and was found to represent one (1) use case, it is not proposed for future reference since development looks like it was discontinued; therefore it s not an actively supported schema Energy Market Information Exchange (emix) Language(s): XSD Syntax: XML Natural Language: English Current Version: 1.0 Online Availability: Yes - cs02.html Documentation: Page 48 of 91

49 Domain(s): Building Product, Energy Standard: Organization for the Advancement of Structured Information Standards (OA- SIS) Extensibility: - EMIX provides an abstract information model that can be extended to address different domains, e.g. the EMIX Power schema (POWER.XSD) can be viewed as the first extension of EMIX into a particular domain. Linking: As a purely XML based standard, linking to other domains is very limited. Linked UC(s): UC4 SWIMing Findings/Comments: While this standard is referenced in the ICT-BEAMS project documentation, it is difficult to determine whether it was employed successfully. Moreover, the schema in hand was only found in one (1) SWIMing Use Case. Nonetheless, it provides detailed documentation for describing aspects related to standardized product information and tariffs, relevant to the development of future smart grids Energy Resource Ontology (ERO) Language(s): OWL Syntax: RDF/XML Natural Language: English Current Version: 1.03 Online Availability: Yes - owl Documentation: Domain(s): Building Product, Building Devices, Building Behaviour, Energy, Geolocation and Weather Standard: No Extensibility: Extensible through OWL extension features, e.g. creating sub-classes Linking: Since it is represented using RDF, it can be easily linked with other ontologies Linked UC(s): UC46 SWIMing Findings/Comments: As an ontology representing energy information for Smart Home Systems, ERO could possibly have a more active role in the upcoming EeB projects. Although only one (1) Use Case is adopting this ontology and the current version is quite old, the ontology describes analytically the requirements of a Smart Home. The DAREED project has adopted this ontology as one of the data models that created the DAREED ontology ESIM Ontology Language(s): OWL Syntax: RDF/XML, N3, Turtle Natural Language: English Current Version: 1.0 Online Availability: No (currently not available online) Documentation: Domains: Building Product, Building Devices, Geolocation and Weather, Energy, Building Data, Best Practices Methods and Technologies Page 49 of 91

50 Standard: No Extensibility: Yes, in general by shared property concepts. The ESIM ontology is in development, so extensions of additional concepts are still possible. Linking: The ESIM ontology supports the multi-model approach. For that the ontology includes linking concepts. Linked UC(s): UC16 SWIMing Findings/Comments: The ESIM ontology derives from the eeembedded project ( which is still undergoing its lifecycle. Therefore, the ESIM ontology is still considered an under development knowledge model and cannot be fully analysed. Through the SWIMing analysis, the ESIM ontology was connected with one (1) Use Case eedim Ontology Language(s): OWL Syntax: RDF/XML, Natural Language: English Current Version: Only 1 eedim version Online Availability: No (currently not available online) Documentation: Domains: Geolocation, Energy, Behaviour Standard: No Extensibility: No specific mechanisms, reuse possible through semantic web best practice Linking: No specific mechanisms, reuse possible through semantic web best practice Linked UC(s): UC15 SWIMing Findings/Comments: eedim is another ontology which addresses district energy (demand profiles, DER descriptions and schedules, network descriptions and topologies for power and heat, sociotechnical concepts such as ownership). Due to the lack of an online version, it is currently difficult to make any strong recoemndations about its applicability ee-district Ontology Language(s): OWL Syntax: RDF/XML, Natural Language: English Current Version: Only 1 version currently available Online Availability: and (for source) Documentation: and WISDOM website Domains: Geolocation, Energy, Control and Behaviour, Data and Communications. Standard: No Extensibility: No specific mechanisms, reuse possible through semantic web best practice Linking: No specific mechanisms, reuse possible through semantic web best practice Linked UC(s): UC15 Page 50 of 91

51 SWIMing Findings/Comments: The ee-district ontology is unique among the models presented in that it is targeting the water utility (GIS, network topology, social actors, measurement, telemetry, alarms, cyber-physical concepts),, as well as smart homes (smart metering, appliances, social concepts, use patterns, smart metering, demandside integration). Reuses most of SSN ontology and has alignments with INSPIRE utility network spec, IFC and SAREF Geographic JSON (GeoJSON) Language(s): GeoJSON Syntax: JSON Natural Language: English Current Version: 1.0 Online Availability: Yes - Domain(s): Geolocation Standard: Yes, IETF RFC7946 Extensibility: JSON schema may be extended Linking: JSON-LD Linked UC(s): UC34 SWIMing Findings/Comments: RFC7946 is a standard for encoding a variety of geographic data structures, replacing the previously known GeoJSON. GeoJSON was format that hasn t really been used much in EeB projects, only one (1) Use Case has used the data structure provided, but can have potentially interesting future results after the new standard being published on 2016 (August). In cases where simple geographical features, along with their non-spatial attributes needs to be represented this standard can adequately support any Geolocation features Geonames Language(s): RDF/OWL Syntax: RDF/XML Natural Language: English with translation to multiple languages Current Version: 3.1 Online Availability: Yes - or access through web service Documentation: Domains: Geolocation Standard: yes, World Geodetic System 1984 (WGS84) Extensibility: Extensible, enabling users to expand existing information or contribute new content Linking: basic geo location (WGS 84), DBpedia, Asset Description Metadata Schema (ADMS), schema.org Linked UC(s): UC46 SWIMing Findings/Comments: GeoNames provides geolocation and supports linking through employing geospatial semantic information, thus providing also geolocation through the World Wide Web. GeoNames is supported by a well build API that enables Page 51 of 91

52 an easy integration and interesting visualisation of geospatial information. GeoNames is used in one (1) SWIMing Use Case Knoholem Language(s): OWL and SWRL (rules) Syntax: RDF/XML Natural Language: English Versions: - Online Availability: No Documentation: Domains: Building Product, Building Devices, Building Behaviour, Building Control (mostly high level concepts) Standard: No Extensibility: KnoHolEM ontology is already aligned with IFC. However it does not rewrite all IFC concepts. KnoHolEM ontology provides explicit mapping of its OWL classes to IFC entities through class annotations. KnoHolEM ontology can be exended through linking to more detailed models, for instances: (1) Interlinks the subclasses of high level class BulildingElement to ifc2owl ontology (2) Interlinks the subclasses of high level class BuildingControl to SSN or ifc2owl ontology (3) Interlinks the subclasses of high level class Behavior to Adapt4EE ontology Linking: see above Linked UC(s): UC18 SWIMing Findings/Comments: The topological approach taken views the building as collections of zones which are subclasses of building. Zone in turn contains building elements, like sensors. This approach appears to be popular for managing building data in the operational stage, although the fact that the Knoholem model isn t online available makes it harder to re-use. Knoholem is used in one (1) SWIMing Use Case and due to the fact that it s based on other known models (IFC, SSN and Adapt4EE) there are quite a few overlaps RDF Data Cube Language(s): OWL, RDF, RDF-S Syntax: Turtle Natural Language: English Versions: 0.2 Online Availability: Yes - Documentation: Domain(s): Cross-domain Standard: No Extensibility: Yes, through SDMX extension vocabulary to support the publication of additional context to statistical data and extension to support metadata for surveys or publication of statistical reference metadata Linking: through standard RDF mechanism Linked UC(s): UC46 Page 52 of 91

53 SWIMing Findings/Comments: This vocabulary allows multi-dimensional data, such as statistics, to be published in RDF. The Data Cube vocab is used in one (1) SWIMing Use Case REMO Language(s): OWL Syntax: RDF/XML Natural Language: English Current Version: Unknown Online Availability: Unknown Documentation: Jayan-poster.pdf Domain(s): Building Behaviour, Building Control, Geolocation/District, Weather, Energy Standard: No Extensibility: Extensible through OWL extension features, e.g. creating sub-classes Linking: Through standard RDF mechanisms Linked UC(s): UC15 SWIMing Findings/Comments: Due to the lack of documentation, it is difficult to give any concrete findings regarding this ontology. The REMO ontology is used in one (1) SWIMing Use Case Schema.org Language(s): RDF Schema Syntax: RDFa, Microdata, JSON-LD, etc. Natural Language: English Current Version: 3.1 Online Availability: Yes - or Documentation: Domain(s): Building product, Cross-Domain Standard: No Extensibility: through two kind of extensions: reviewed/hosted extensions and external extensions which add subclasses and properties to the core elements. Linking: The RDF syntax allows a direct linking to other ontologies Linked UC(s): UC46 SWIMing Findings/Comments: Schema.org vocabulary creates, maintains, and promotes schemas for structured data on the Internet, on web pages, in messages, and beyond. Although application so far is found to be limited to EeB projects, only one (1) SWIMing Use Case uses this vocabulary, the ongoing use of web-based applications for monitoring and management platforms is expected to expand its use Semanco Energy Model Language(s): OWL Syntax: RDF/XML Natural Language: English Current Version: Page 53 of 91

54 Online Availability: Yes - Documentation: Domain(s): Geolocation/District, Energy Standard: No Extensibility: through two kind of extensions: reviewed/hosted extensions and external extensions which add subclasses and properties to the core elements. Linking: The RDF syntax allows a direct linking to other ontologies Linked UC(s): UC17 SWIMing Findings/Comments: The SEMANCO Energy Model offers a joint information model in regards of geolocation and energy domains, while enabling semantic tools to access the data stemming from these domains and relevant applications. Thus it s an ontology that could be used in most EeB projects. However due to the fact that the last version is quite old (2014), it is believed that this model isn t actively being supported. The Semanco Energy Model is used in one (1) SWIMing Use Case Sensor Model Language (SensorML) Language(s): XSD Syntax: XML Natural Language: English Current Versions: 2.0 Online Availability: Documentation: Domain(s): Building Devices Standard: OGC standard Extensibility: SensorML 2.0 enables property extension using external schema, and also support inheritance. Linking: As a purely XML based standard, linking to other domains is very limited. Linked UC(s): UC4 SWIMing Findings/Comments: SensorML enables a robust and semantically-tied means of defining processes and processing components associated with the measurement and post-measurement transformation of observations while also supporting the definition of physical characteristics and functional capabilities. This ontology can offer added value since semantic information is also supported within its capabilities. However, once again this model seems not to be maintained (last version on 2014) which explains why it s only used by one (1) Use Case System Interoperability Ontology (SIO) Language(s): OWL Syntax: RDF Natural Language: English Current Version: Unknown Online Availability: No Documentation: The ontology is discussed in public deliverables [43], [44], and papers [45]. Domain(s): Geolocation/District, Building Product, Building Devices, Building Control Page 54 of 91

55 Standard: No Extensibility: through two kind of extensions: reviewed/hosted extensions and external extensions which add subclasses and properties to the core elements. Linking: The RDF syntax allows a direct linking to other ontologies Linked UC(s): UC4 SWIMing Findings/Comments: Due to the lack of a publicly available version of this ontology it is difficult to provide any concrete findings regarding this ontology. The ontology does have as a basis SAREF [46] which is now an accepted ETSI standard, which does support extension and linking. Nonetheless, the deliverables describe an interesting ontology which could provide a basis for district energy modelling. SIO is referenced in one (1) SWIMing Use Case Unit of Measurement (OM) Language(s): OWL (developed form original UML) Syntax: XML Natural Language: English Current Version: 1.8 Online Availability: Yes, Documentation: Domains: Building Data Standard: Initiative of the Intelligent Systems group at Wageningen UR- Food & Biobased Research, the Netherlands Extensibility: yes, extensibility of OWL Linking: Linking to other ontologies, such as the SSN ontology, can be done subsequently in RDFS and OWL axioms, and maintained as linksets separate from the structure model. Linked UC(s): UC46 SWIMing Findings/Comments: In most cases the Units of measurements or observations are integrated either as a property or a simple string element to most ontologies following known Metric Systems (i.e. the International System of Units - SI). Thus, a unit specific ontology isn t promoted to use. UM is referenced in one (1) SWIMing Use Case WGS84 Language(s): RDF-S Syntax: RDF/XML Natural Language: English Current Version: EGM 2008 Online Availability: Yes - Documentation: Domain(s): Geolocation Standard: Yes WGS84, EGM2008 Extensibility: - Linking: - Linked UC(s): UC46 Page 55 of 91

56 SWIMing Findings/Comments: This is one of the oldest and most used model which also supports the Global Positioning Systems and consist of a basic RDF vocabulary that provides a namespace for representing latitude, longitude and other information about spatially-located things. Moreover this model is used as the foundation for more recent ontologies (i.e. GeoNames) while also being updated providing a constant improved data model. Although this model was found in only one (1) SWIMing Use Case, it is still one of the best geolocation models for simple geospatial elements The Smart Appliances REFerence (SAREF) Language(s): OWL Languages: OWL Syntax: RDF/XML, Turtle Natural Language: English Versions: 1.0 (2.0 is currently under development) Online Availability: Documentation: Domains: Devices (Smart Appliances/IoT) Standard: SAREF has been officially standardized by ETSI in Technical Specification TS , V1.1.1 in November 2015 (see 01p.pdf) Extensibility: 3 extensions of SAREF: 1) SAREF4ENER is an extension for demand/response use case in the energy domain based on CENELEC TC59x WG7, pren50631-x (to appear), 2) SAREF4BLDG is an extension in the building domain based on the ISO standard (IFC), and 3) SAREF4ENVI is an extension in the environment domain. Moreover, we will be soon releasing an alignment with the onem2m Base Ontology. Linking: See above SWIMing Findings/Comments: The SAREF ontology, while not being directly used by any use case, is mentioned many times and also used as a reference ontology. SAREF is undergoing new development iterations and is a very promising standard for capturing aspects of building devices which are relevant to EeB use cases Analysis of Use Case Ontologies According to BLC and Data Domains In this section we provide some additional analysis of the ontologies according to the different BLC stages, which builds upon the analysis provided in section When looking at ontologies/standards used over all, those which are most represented across the highest number of use cases (i.e. greater than 1) are; IFC (16), CityGML (7), gbxml (5), CIM (5), obix (3), GAEB-XML (3), SSN (3), SimModel (3), SUMO(2). Page 56 of 91

57 CIM CityGML GAEBXML gbxml IFC obix SIMModel SSN SUMO Figure 24: Ontologies representing more than one Use Case A high number of the models are only represented by one use case; COBie, BsDD, SU- MO, LandXML, Collada, CMO with Extensions, eebim, EEML, emix, ERO, ESIM, GeoJSON, Geonames, KnoHolEM, RDF Data Cube, R.E.M.O., Schema.org, Semanco, SensorML, SIO, OM and WG S84. Break down according to BLC stages Design (4 Use Cases); IFC (3), CityGML (2) 1 use case; Collada, CMO with Extensions, eebim, GAEB-XML, Operation (28 Use Cases); IFC (13), CityGML (5), gbxml (5), CIM (5), obix (3), GAEB-XML (3), SSN (3), 1 use case; SimModel, COBie, BsDD, SUMO, LandXML, Collada, CMO with Extensions, eebim, EEML, emix, ERO, ESIM, GeoJSON, Geonames, KnoHolEM, RDF Data Cube, R.E.M.O., Schema.org, Semanco, SensorML, SIO, OM and WG S84. Re-design (11 Use Cases): IFC (8), CityGML (5), SimModel (3), gbxml (2), SSN (2), 1 use case; CIM, obix, GAEB-XML, SUMO, eebim, EEML, emix, SensorML. Page 57 of 91

58 Design Operational Re-design 2 0 Break down according to Data Domain Figure 25: Data Models per BLC Stage Product (14 Use Cases) 15 Data Models (Collada, eebim, emix, ERO, ESIM, GAEB- XML, gbxml, IFC, Knoholem & SIO and 5 cross domain) Devices (28 Use Cases) 16 Data Models (COBie, eebim, EEML, ERO, ESIM, IFC, Knoholem, obix, SensorML, SSN & SIO and 5 cross domain) Control & Behaviour (27 Use Cases) 13 Data Models (eebim, ee-district, ERO, IFC, Knoholem, obix, REMO & SIO and 5 cross domain) Data & Communications (22 Use Cases) - 13 Data Models (CIM, eebim, EEML, ESIM, IFC, UM, obix & SSN - and 5 cross domain) Geolocation and Weather (13 Use Cases) - 21 Data Models (COBie, CityGML, eebim, ee-district, ERO, ESIM, GAEB-XML, gbxml, GeoSON, GeoNames, IFC, LandXML, REMO, Semanco, SIO & WGS84 - and 5 cross domain) Energy (28 Use Cases) 16 Data Models (eebim, ee-district, emix, ERO, ESIM, GAEB-XML, gbxml, IFC, REMO, SIMModel & Semanco and 5 cross domain) Page 58 of 91

59 Cross Domain Energy Geolocation and Weather Data & Communications Control & Behaviour Devices Product COBIE Collada CIM CityGML CMO eebim Link EEML emix ERO ESIM GAEBXML gbxml GeoJSON GeoNames IFC bsdd Knoholem LandXML UM obix Data Cube REMO Schema.org SIMModel SEM SensorML SSN SIO SUMO WGS84 ee-district Figure 26: Data Models per Data Domain UC1a UC1b UC3 UC4 UC7 UC13 UC15 UC16 UC17 UC18 UC19 UC46 UC27 UC34 UC44 UC53 UC54 UC59 UC64 Figure 27: Use Case Ontology Representation (at least once) 1.1 Summary and recommendation As can be seen from the above breakdown, several ontologies are referenced multiple times even across BLC stages. This indicates that these ontologies can function as bridging, or reference ontologies. IFC for example (unsurprisingly as its role as a major standard in BIM) is popular in all three BLC stages (Figure 25) and is the data model that represents the most EeB identified use cases (Figure 24). Also of note is the role CityGML plays across BLC stages. This is a popular model when integrating BIM data Page 59 of 91

60 with the wider district. As it provides only simply descriptions of the building (with respect to IFC), the linking of these models is being actively researched in projects such as: OptEEmAL, EeEmbedded and Streamer. A surprising finding is that the gbxml model does not play any role in use cases at design stage of the building. As a model for exchanging energy information, it is assumed that other models are fulfilling this role during design and that gbxml is only being employed during energy analysis at operational and redesign stages. Similarly, SimModel, another model for exchanging energy simulation models, here only plays a significant (3 use cases) role at the re-design stage. These findings may also reflect a movement towards EU funded projects which are looking at energy simulations for retrofitting to enable more energy efficient building operation. CIM plays a role only in the operational stages of the building, and this is perhaps not surprising as CIM is related to energy markets and tariffs, which is most relevant at the operational stage. During operation other models of note are obix and SSN, which are related to monitoring and observing a building, as well as controlling a building, which again is most relevant to operation, but also re-design where buildings can be monitored to assess the need for retrofitting or where new monitoring and control systems are installed and configured to support energy efficient operation. Another interesting result is that Geolocation and Weather is found as the Data Domain most covered (Figure 26) by the ontologies identified in the EeB projects, highlighting the importance of environmental conditions as well as positioning when dealing with Energy Efficiency in Buildings. Following in the second place, Product, Devices and Energy provide a more clear view of the information engaged in EeB projects. Finally, it is worth mentioning that certain use cases have quite a few data models representing their information exchange (Figure 27), with UC4 (Assessment of Energy Optimization Scenarios) being the most highlighted with nine different models covering the specified requirements. Based on the findings from the analysis of the SWIMing project some overall comments are listed below: - Ontologies that are able to represent more than one domains, or more than a few concepts are preferred than too specific ontologies/data models. - In most cases, ontologies created based on standardized models tend to overlap with each other and the original standard - Actively maintained models that are available online are easier to extend and link due to existing support and extended documentation - Ontologies created specifically for one project are not easily re-used and due to limited documentation, they are discontinued. - Data models that get standardized are more likely to be reused due to better dissemination, documentation and traceability While the list of ontologies here is not exhaustive, it does represent some of the more significant models being used across use cases and EU projects, for example; IFC, CityGML, gbxml and CIM. These models should therefore be considered as potential recommendations for publishing data. Page 60 of 91

61 1.2 Mapped requirements and ontology alignments In this section we explore some of the different methods for discovering alignments between ontological concepts, and there relation to SWIMing. Matching concepts between ontologies and discovering alignments is an active area of research [47]. Ontology matching aims at finding correspondences between semantically related entities of different ontologies [47], for example, if a model like IFC has a concept called Door, how is this related to a concept in another ontology, for example SAREF, called Door? One might assume these concepts are equivalent, but on closer inspection, one discoveries that constraints in the schema may result in equivalence statements being untrue. In SAREF Door or Window are subtypes of BuildingObject AND a building object is an object in the building that can be controlled by devices, such as a door or a window that can be automatically opened or closed by an actuator [46]. In IFC4 IfcDoor or IfcWindows can exist even without any kind of automatic control. So, even in this simple example, some of the issues when making relations between models are exposed (for more on this topic see the 3 rd SWIMing Workshop Report D3.9 [48]. Why is this important? Well, if one wishes to query a data set for all automated doors and the query asks for all instances of Door, if one asserts Door in IFC4 and SAREF Door are equivalent, you will have a situation where you get a response which includes Doors which are not automated. Therefore, it is necessary to be aware of these issues when conducting ontology matching. The types of correspondences between ontological concepts include equivalence as well as other relations, such as consequence, subsumption, or disjointness. The matching process consists of taking a pair of ontologies and discovering these correspondences, to determine some alignment. An alignment asserts something that concept A and concept B are equivalent, subsume, etc. These may also have a confidence value associated between 0 and 1, to determine the level of confidence of the assertion. Euzenat et al. [47] present several ontology matching techniques, which can be classified as Element-level techniques, i.e. those which consider concepts in isolation from their relations with other concepts, and structure-level techniques, i.e. those which compare the relationships of concepts to other concepts. We will not present a full list of potential methods here, but that they range from for example string-based which match the names of concepts with one another, breaking them up into strings of characters, working on the principle that the more similar two strings are, the more likely they are to be the same, to graph-based techniques, which are algorithms that consider the input ontologies as labelled graphs, and the similarity comparison is based on the analysis of the position of two nodes within the graph. All of these methods have advantages and disadvantages. The example given at the start of this chapter was derived by work done by an ontology matching algorithm developed by Jerome Euzenat and applied at the R4SC VoCamp, in Savona, which SWIMing Page 61 of 91

62 participated [48]. Here a linguistic based method was applied, which was useful for the initial concept matching phase. It was necessary though for domain experts to then play a part, as matching based purely on word similarity did not result in correct alignments in all instances. SWIMing has therefore taken a heuristic approach which relies on the use of domain experts to support the matching process. In addition, the BIM*Q tool through engagement with domain experts and IT experts, supports the mapping of requirements with concepts and properties, allowing the identification of necessary definitions for a more complete modelling based on a project needs. As shown in Figure 9, each concept has been mapped with specific properties and it s accompanied with additional information regarding description, type, etc. Interested third parties can navigate through the BIM*Q tool templates and discover information that will aid them to either expand already identified concepts or identify new ones that were eluding them to that point. Figure 28: BIM*Q structured requirement definitions and further definitions like descriptive text, type information or the mapping to IFC. To further support interoperability and common data vocabularies, the BIM*Q tool includes alignment with known ontologies (e.g. IFC, CityGML, SSN, etc.), providing valuable insight regarding selection of the optimal ontology, or set of ontologies, towards describing a domain, a model or even a specific class. The described knowledge not only aids towards selecting the most suitable ontology but also introduces the classes and Page 62 of 91

63 sub-classes that fit best, facilitating at the same time the usage optimization of the selected ontology (Figure 23). While over 22 use cases have undertaken the SWIMing methodology using BIM*Q with respect to steps 1-4, the other 45 having only taken steps 1-3 (Appendix B), here we discuss some findings regarding six represented use cases, OptEEmAL, NewTrend, EeEmbedded, Streamer, DAREED and Cascade (see [5] for more details on these). Experiences using the BIM*Q tool are given for four of these use cases in section 6.1, followed by some findings regarding their inputs. As can be seen in Appendix B for the above mentioned use cases, ontologies such as IFC, CityGML and gbxml have been found to optimally describe EeB aspects and properties, creating various overlapping s between use cases. Furthermore, it is apparent that some classes and properties are described accurately with more than one ontology; leading to not only vertical but also horizontal overlapping s as well. Both requirements and ontology mappings were limited to information availability. In cases where the data models were not public or the information shared was limited, it was not feasible to recreate the information required for the BIM*Q tool. In some cases, communication with the projects where the use case was extracted provided additional aspects that helped enrich the limited documentation. In the next section we will briefly examine some of the findings in SWIMing with respect to data harmonization across use cases. 1.3 Data Requirements Harmonization across Use Cases Through the analysis of the EeB projects and their different views on data representation it is apparent that there are many possible ways to classify use case concepts, and these may fall under one or more of the data domains identified in SWIMing. It is also very difficult to analyze all concepts defined within projects, as the level and depth of the data models is considerable, covering different BLC stages and many different domains in differing levels of granularity. Nonetheless, the process of examining the use cases using the SWIMing methodology has led to some relevant findings. Certain domains have consistent concepts represented as indicated in D1.2 [5] and these concepts should be aligned with standards and targeted across EeB projects to ensure consistent representations of data. For example, the spatial concept and spatial relations are used across use cases, and therefore, space could be a potential concept for managing equivalence relations, allowing one domain to reference a space which is also reference by another domain. This has led to the development of simplified ontologies which can provide a bridge between existing standards such as IFC, and the web development community. The LBD community group is working on the standardization of a Building Topology Ontology (BOT) to support this process through its work with the W3C community [49]. With mod- Page 63 of 91

64 els like BOT, different domains can then be associated with spaces. For example, products such as building elements and devices can belong to a space, likewise, behaviours. In the next section, we explore some of our findings with respect to the use of BIM*Q to satisfy the SWIMing methodology. Page 64 of 91

65 5 Discussion and SWIMing Recommendations Based on the review of several research EeB projects presented in this and other SWIMing deliverables, participation in a number of workshops as well as discussions with many experts in the area of EeB data requirements and Linked Building Data, this chapter is trying to give an overall conclusion and further recommendations. A particular focus and aim of SWIMing is to support data integration of various EeB-related information sources used throughout the life-cycle of a building. This is justified by the fact that a common challenge of all reviewed projects is the need to work with different data models (or ontologies) and data sources. In most cases BIM and in particular the open IFC format is used as a neutral description or reference model of the building. The BIM data set is then enriched by use case specific data so that for instance specific kinds of energy simulation or other types of analysis can be done. This data enrichment is typically part of an iterative design process and therefore must be able to deal with updates of the BIM model or other data sources. This is evident collaboration problem of multidisciplinary AEC processes. Model linking is seen as a solution to avoid redoing time-consuming data enrichment whenever a changed BIM is available. The basic idea of model linking is to reuse existing data sources as much as possible, to add and keep the relationships between those data sources and to enrich the data as needed to support specific use cases 10. Accordingly, these projects are moving from data import/export solutions to real data sharing approaches. This chapter is organized in three parts. The first part is discussing differences between data exchange and data sharing. It shows a typical data sharing scenario and challenges. The second part is discussing typical constraints for making decisions about technology, standards and workflows when implementing new use cases. Finally, the last part of this chapter gives recommendations on how to publish own data sets, including used ontologies, so that it can be more easily reused in other environments. Availability of data sources based on Semantic Web technology is seen as an important step towards Linked Building Data solutions. 5.1 Context dependency A goal of the SWIMing consortium is to give recommendations about ontologies depending on the data domains and building life-cycle stages covered by a use case. In fact it is very difficult to reuse existing ontologies without further extensions or changes. Although there is a lot of common building data typically subsumed under the term BIM, there is also use case specific data that for instance is needed to support a new simulation algorithm, to have a better way of representing same information (in many cases motivated by better performance when working with the data or less data to be managed in the 10 First bullet point in the LDWG Modelling Guideline discussed in buildingsmart says: Maximal reuse of existing LD/SW specifications. Page 65 of 91

66 database) or to support tool specific settings. Accordingly, a discussion about recommended ontologies is very difficult. A frequently given answer to this question was that it depends on the context 11 which has a strong relationship to a particular use case i.e. that a particular model will reflect how it is required to be applied. This in fact points to the challenges associated with data sharing and also proves the need of clearly specified data requirements as proposed by the SWIMing methodology. In SWIMing, context is provided on three dimensions; the building life cycle stages, data domains and use cases. Following the SWIMing methodology, use cases have been defined for projects and classified according to these different dimensions. Before further recommendations are given here based on this analysis, it is important to understand that Semantic Web and Linked Building Data is more than a way to communicate with other domains. It is a technology that is not only used to manage but also to work with the data. This in fact is different to classical data exchange approaches where a neutral BIM is converted to an internal data format by import and export interfaces. In that scenario the ontology is like a foreign language that is only used for communication, i.e. information needs to be translated from and to a native language in order to be able to work with the data (querying and manipulation). Accordingly, such ontologies are pure data exchange standards limited to the knowledge about common concepts and properties. Very often this data conversion process will lead to some amount of data loss or restructuring of information. Consequently, it is also difficult to control data changes and to keep links between different data sources. The use of LBD and Semantic Web tries to avoid data conversions by re-using available structures. Relying on the fact that missing knowledge can be extended, this data sharing approach followed by model linking solutions is able to work with shared concepts, or at least is able to keep the link to more specific concepts derived from common data. However, this approach sounds easier than it is implemented in practice. For instance, IFC is a strong contended for a reference ontology as it is highly represented across use cases. During the operational stage (which represents the largest number of use cases across the EeB projects reviewed here) IFC is represented in only 13 of the 28 use cases, so it may not be appropriate as a reference ontology for all use cases in the operational stage. This may be related to the perceived difficulty of the standard by web developers, who not familiar with AEC processes may find it difficult to directly work with the IFC structures. Accordingly, there are also efforts like simplebim [50] or the Building Ontology Topology (BOT) [49] to reduce the perceived complexity of IFC with a simplified version of some of its core concepts. The advantage of these simpler approaches is that a: they provide a quicker hook for new developers to begin working and modelling with BIM. Secondly, by aligning their concepts with existing standards like IFC, the potential to directly map data developed 11 The meaning of Context is not fully specified, but it essentially describes all constraints for using an ontology. Most important is the view on the building, i.e. the data subset or idealization that is needed to analysis the building. Page 66 of 91

67 during the earlier life cycle stages of the building to later stages, is supported. Also, these simpler views of the IFC data model, may also avoid some of the issues related to IP which many companies may view their developed models as being. For instance, BIM queries can be optimized if objectified relationships modelled as IfcRel are replaced by object references or if properties modelled as key/value pairs through IfcProperty are embedded in the ontology specification. Not surprisingly it is often found easier to get rid of all boundaries of an existing ontology and to develop a new one that perfectly fits to all use case requirements. But even if new ontologies are developed, the benefit of Linked Building Data is to be able to keep and manage the links to shared concepts. Because of these findings, it is difficult to give general recommendations about ontologies as it is very likely that it does not perfectly fit to all use cases. The selection of an ontology is always influenced by the context, which not only depends on use case requirements but also on other constraints discussed in the next section. Nonetheless, there are some examples from the use cases we have analysed, that point towards certain standards available to meet particular domains during certain BLC stages. 5.2 Criteria for evaluation of ontologies This chapter gives an overview about constraints for selecting an ontology to be used as a basis for further developments. A main criteria for that kind of analysis are of course captured requirements (see step 4 in the SWIMing methodology) and the ability of an ontology to deal with those requirements (step 5). It should be noted that SWIMing derives all of its data from that gathered through interaction and analyses of projects. This involved analysis of deliverables, contact and discussion, where possible, with project partners, and then more in depth use case development with, for example, BIM*Q. The result of the analysis stage often demonstrates the need for extensions or the development of a new ontology (step 6). However, coverage of data requirements is only one of many more criteria that needs to be considered when selecting an ontology. The following list gives an overview about constraints being relevant for selecting an ontology or technology: Availability of required data: New developments often have to work with available data sets such as for instance cadastral maps, facility management data, material or weather databases etc. Accordingly, the data format of those data sets must be supported by import interface or API calls. A data conversion into another ontology might be too time consuming or requires too much resources so that the given structure and technology (e.g. relational database accessed by SQL) hast to be reused. Availability of tools: A similar constraint as for data sets can be defined by tools and their native data formats or APIs. If new developments need to integrate specific tools like for instance to work with a specific simulation package then the import and export interfaces of this tool must be supported. For instance, design tools are typically using either a binary or XML-based data format, but not an Page 67 of 91

68 RDF-graph ideally hosted on a server offering a SPARQL endpoint. Again, the necessary data conversion may influence further project decisions. Openess vs. closed development: Openess is a prerequisite for reusing data provided by other players. There should be a natural interest in selecting open data and well-documented ontologies. Beside good documentation the licence agreement is an important criteria to be usable in own applications. In any case it is necessary to be aware of the license agreements and conditions for using and may modify it. Level of standardization: If possible it is recommended to rely on standards. A standard that is published by a well-known standardization body is normally a sign of quality and trust. Thus, acceptance by the industry is typically higher than using proprietary definitions. Additionally, there are many types or levels of standards. Some might be accepted on international level whereas others support a local market only. There are also draft standards that might be accepted in future, or may undergo further changes. Using a standard also means that there is an agreement how to represent shared concepts and that there is a neutral body who is able to resolve issues. Contrary to that a de-facto standard is established by the market. It might be equal to a standard in terms of functionality but often is under control of a single market player. Support by the community: If an ontology is published as-is, for instance as a result of a research project then it becomes important to see whether there is a community that is able to provide support in case of issues or questions. Accordingly, unless an ontology fits very well to the requirements of those in the community, and thus is seen as a good basis for adjustments, it is generally risky to undergo an unknown learning curve on how to use this ontology. An indication of a good community support is a well-defined documentation with example data and of course a lively discussion in forums or other platforms. Maintenance: Established specifications normally went through steps of refinement and thus come with a version history. Accordingly, it is a good sign if an ontology is used and maintained for several years. It is of course difficult to give an outlook to future developments, but a long version history is pointing to an active community that already went through validation and improvement cycles. It is more likely that this will also happen in future. Used technology: In general there are many criteria related to technology. A main aspect when it comes to data modelling is the expressiveness of a modelling language. A language like EXPRESS or OWL for instance offer more features for encoding knowledge than XSD. A main argument for using OWL is for instance to be able to use first order logic and reasoning due to formal semantics. Accordingly, a more expressive technology may already enable to encode a lot of knowledge into the ontology. Technology is also relevant when it comes to implementation. It normally requires a set of tools to be productive, for instance for Page 68 of 91

69 H parsing, manipulation and management of data. Thus, a good set of tools, maybe even available free of charge, will also have a noteworthy impact for selecting a technology. Extensibility (linking): As discussed in chapter 5.1 an ontology will probably never perfectly fit to specific user requirements. Accordingly, it becomes important to be able to extend or change the ontology. A prerequisite is to have access to the specification and necessary tools, not only for refining the specification but also to generate and work with the data. Above list shows quite a number of external constraints that influence decisions regarding the use of a specific ontology. This list may not even be complete and might be extended by other criteria. However, it shows that a decision is normally a compromise between different options. Thus, in particular for so called downstream applications, i.e. tools that highly depend on input from other tools like for instance energy simulation that must use the BIM from the architect, the freedom for choosing preferred ontologies is rather limited unless major data processing efforts are acceptable. For instance, using ifcowl normally would mean to first convert BIM data to the OWL format. Meanwhile this conversion is standardized by the LBD community and buildingsmart so that the barrier for adopting Semantic Web is already lowered. It should be clear that those constraints apply to the implementation of new use cases. It mainly describes the barriers for integrating external data sources. Similar constraints may apply when it comes to hand-over of own data sets, for instance if simulation results must be reported back to the architect. However, publication of data sets should try to lower the barrier for reusing the data and thus should put special emphasis on selecting the right data publication strategy. 5.3 Recommendations for data publication A key factor in multidisciplinary work is to be able to reuse other datasets. Accordingly, it becomes important how to publish generated datasets, in particular if it is not clear who, when and how data shall later be used. The overall strategy for data publication is therefore to preserve as much data as possible relying on open standards. The topic of data preservation and proper documentation was already presented in deliverable D2.1. From that description it can be seen that it is mainly meta-data, i.e. data about the data that is important to be attached to published data sets in order to be reusable in other, yet unknown use cases. Additionally, the meta-data should be available in a machine-readable format to be automatically searchable and processable in queries. For projects which wish to publish data, here we provide some of our general recommendations based on our analysis of project use cases and data models based on the three main life cycle stages that are covered: Design: IFC and CityGML are both models which can be utilized for publishing data relevant for supporting design processes. IFC addresses many of the domains which are relevant to design, in particular product modelling, and provides a comprehensive set of Page 69 of 91

70 entities and relations to meet many of the requirements for optimized design which leads to energy efficient operation in buildings. IFC combined with CityGML can provide a means to integrate BIM with the wider district and city modelling, a necessary step for integrating buildings into the smart grid. Operation: IFC plays a leading role during the operational stage of projects, with 13 of the 28 use cases involved in this stage referencing it. Therefore, it is suggested that IFC remains a core reference ontology during the operational stage, although, as mentioned previously new developments toward simplified versions of IFC for developers is recommended (e.g. simplebim, the building topology ontology). Other ontologies and models are also recommended for data publication relevant to operation. Again, CityGML provides a bridge to the wider district and city. The Common Information Model (CIM) is another well-developed standard which can provide a means for publishing data relevant to electrical transmissions and energy management systems. For managing control systems in buildings, obix is currently the highest represented ontology for this domain. GbXML can also play a role during operation for managing data related to energy simulations. The SSN ontology provides capabilities to describe sensors and linking to ontologies for describing measurements. One ontology which while not directly being used in projects, is being referenced by many data models is SAREF. SAREF provides excellent capabilities for describing aspects related to building devices and energy. Foe geolocation GeoJSON and Geonames make good candidates. While not mentioned in projects, GeoSPARQL [51] should also be considered. Re-design: Again IFC plays a lead role in this BLC stage, again providing the means to describe product information relevant to re-design of the building. Linked with CityGML these can play an important role for managing data related to district and building modelling. SimModel and gbxml are two models which can provide the capability to support energy modelling in order to test and evaluate new re-design solutions. For installation of new monitoring systems, SSN again can play a role for data publication about sensor networks. Other topics which must be considered when publishing data using the aforementioned models are: License: It is necessary to know the conditions for using a data set. If license information is missing, the dataset cannot be integrated in own use cases. For linked data applications it is recommended to choose an open license that removes copyright restrictions from content. Some open licenses come with limitations for commercial applications, which again restricts the use of the data. Quality: Data should be checkable against relevant quality criteria, namely accuracy, completeness and consistency of the data. If a dataset does not include all required data, is not accurate enough or may contains contradictory statements then the data set requires further data processing or may not be usable at all. A prerequisite for checking the data quality is to know about the semantics of the data, typically captured by the formal ontology. Furthermore it is necessary to have further context information such as the time when the data was generated, Page 70 of 91

71 H original purpose of the data, the status of the data, authors, used tools etc. For instance it is an important difference if a BIM data set represents an early design proposal or the as-built data of a building. Availability: The dataset must be available in a machine-readable format. Ideally, it can be downloaded as a file using an open, non-proprietary data format and could be found in a data set catalogue. If existing data sets cannot be discovered or are not available for download or accessible through other APIs, it cannot be integrated in own use cases. If using Semantic Web technology the main task for data publication is to provide relevant meta-data including the underlying ontology, to make the data available in the web and to promote the data set in data set catalogues, on websites and other information channels. More detailed information about data publication can be found in the D2.1 which references W3C Best Practices 12, and in [52] Page 71 of 91

72 6 Conclusion This deliverable completes the set of guidelines and best practices to support data management in BLCEM processes. The guidelines follow the methodology proposed by SWIMing consortium (see D2.2), which similar to the IDM/MVD approach from buildingsmart is divided into two parts: (1) the capture of use-case specific domain knowledge and (2) the translation of conceptual models defined by domain experts into technical specifications ideally reusing existing solutions. The focus of the D2.3 has been on the second part, in particular the mapping of data requirements to ontologies and the identification of ontology alignments. The methodology itself has been applied to a set of use cases not only to validate the presented approach but also to get an overview about the current state of research in EEB-related use cases. Conducted results have been summarized in an interactive domain/use case matrix that is available at [8] as well as an overview about used ontologies that is provided in this deliverable. The result of this research is leading to a number of findings that not only proof a number of assumptions but also show current research challenges when moving to Linked Building Data and Semantic Web technologies. The following findings shall be highlighted: Importance for properly documenting use case requirements: It is often difficult to review research results and to check whether developed solutions in terms of specifications, tools and data sets can reused or integrated into own developments. Accordingly, it is important to thoroughly document developed use cases. First of all it is important to be able to classify developments for instance based on the matrix proposed in SWIMing. Additionally, it is then necessary to be able to check detailed requirements including the technical implementation. Ideally, the information is managed in a similar structure and published as a searchable resource as for instance done in SWIMing by the use of the BIM*Q tool. Integration of different data sources is becoming more and more important, even with BIM: Although BIM and IFC enables to integrate most important building data there is an increasing need to connect to other data sources, either to keep the link to none-sharable, highly specialized building data or to make use of data that is outside the scope of the AEC industry. Almost all projects are faced with the challenge to integrate different data sources. Semantic web technology is recognized as solution for data integration: A number of projects have started to use Semantic Web technology not only to link different data sources but also as a technology to manage and manipulate the data, even though there are still a number of barriers like for instance the necessity to convert data to Semantic Web-enabled representations. Linked Building Data approaches are moving from data exchange to data sharing solutions: This step potentially reduces data conversion and data losses. However, shared data may comes with a number limitations, in particular in terms of completeness (some concepts may not be expressable) and efficiency (data query and manipulation could be more difficult and time consuming than Page 72 of 91

73 H with proprietary solutions). Completeness and efficiency issues might be handled by extensions so that extensibility becomes a major requirement for LBD solutions. Reuse of ontologies is limited due to context dependency: A key principle of LBD is to reuse existing resources, not only in terms of data but also in terms of semantic definitions. However, it is very likely that existing definitions do not fully fit to own requirements. Accordingly, it is difficult to give general recommendations about ontologies without knowing the context of its use. Proper data publication is a prerequisite for using LBD approaches: In order to contribute to LBD developments it is important to properly publish and promote own ontologies and datasets. This essentially means to enrich developments with the right meta-data and to make it available for the community. Results of this deliverable give an overview about achievements in the area of EeBrelated Use Cases. Many specifications, tools and datasets have been developed for solving specific issues in the life-cycle of a building. However, it is still very difficult to find and integrate those developments into own use cases. This deliverable shall help to get a better overview about the current state-of the art, which is rapidly changing as a result of the large amount of research still being conducted. Therefore, an important message of the SWIMing consortium is to improve and harmonize the documentation of developed solutions and published data sets. Semantic Web and Linked Building Data is already embedded into standardization initiatives from W3C and buildingsmart driven by an active community and provide a basis for this multidisciplinary development that in many cases already go beyond the traditional building domain. Real case scenarios where practical application of the SWIMing methodology and the recommendations proposed have already been experienced by new Horizon2020 EeB projects that participated in the SWIMing effort. The following section highlights the feedback received from these projects. 6.1 Experiences Using the BIM*Q Tool and the SWIMing Methodology in Horizon2020 Projects Here we provide some feedback from project experiences with the BIM*Q tool which has been collected through direct communication with project members who participated in the use of BIM*Q. Here we cover four projects, OptEEmAL, NewTrend, DAREED and Streamer. These are shortly described in this section. OptEEmal Project By adopting the SWIMing methodology the OptEEmal project [25] has managed to identify relations (alignments) between ontologies selected within the project (CityGML OWL, ifcowl, SimModel OWL) as well as the needed RDF transformation in accordance to the ontologies selected and their alignment, facilitating thus the creation of Ad Hoc con- Page 73 of 91

74 nectors between energy data models and particular simulation models (see Figure 29 for a snapshot of their inputs into BIM*Q). Figure 29: Screenshot of the BIM*Q tool showing requirements of the OptEEmAL project Currently the OptEEmAL project has reverted to an excel based method for capturing data requirements. This method does not provide the depth of functionality that BIM*Q does, but does provide a method for selecting which ontology is relevant for a particular data exchange. The excel sheet also provides capabilities to add comments relevant to particular data exchanges, e.g. different kinds of uses which must be addressed from an implementation perspective, which are available to other project members upon sharing. Page 74 of 91

75 The OptEEmAL team members using the BIM*Q have made the following recommendations for upgrading BIM*Q: Provide functionality to upload ontologies, so that when aligning, you can choose from available standards, e.g. from a dropdown menu. o Ideally, all concepts would also be made available for a particular ontology. Capability to add notes relevant to a particular data exchange. For the functionality that BIM*Q provides though, it is currently seen as user friendly, and OptEEmAL are considering going back to its use when they need to begin making more fine grained alignments between data requirement concepts and standards. NewTrend Project The NewTrend project [53]started in the beginning of The initial contact to the project coordinator has been established in the SWIMing VoCamp held in March 2016 in Dublin. After a set of initial telefon conferences a half day meeting was scheduled for May 2016 where NewTrend project partners have been introduced to the SWIMing methodology and the BIM*Q tool. Based on an initial requirements analysis the BIM*Q tool was used to specify exchange requirements, in particular to select and structure relevant data. The strategy of using the BIM*Q tool has been the following: high-level data capture of the model data follow a iterative approach: o o o definition of basic components as objects and attributes to agree on a vocabulary; (objects were mainly treated as containers for collections of attributes) stitch the data together into a basic schema high-level mapping to gbxml (where possible), and adding mandatory/optional/not required flags An example of the generated use case definition is shown in Figure 30. The feedback reported back from NewTrend partners can be summarized as follows: The overall experience was positive. Incremental approach was chosen to work on the data mapping an hour per day. Some server issues in the beginning, but solved later No issues with data loss due to any server instability. Page 75 of 91

76 The resulting data model, whilst still just high-level details, serves as a useful starting point for discussions between partners as to the data to be exchanged. Figure 30: Screenshot of the BIM*Q tool showing requirements of the NewTrend project DAREED Project DAREED [27] adopts the SWIMing methodology in applying linked data for the integration of heterogeneous and uncorrelated data from multiple sources, for example simulation data, metering data, statistical data from municipalities, and open data available in the internet. KIT, which is also a partner in SWIMing, is responsible for the technical coordination and data integration of DAREED project. The successful application of SWIMing methodology in DAREED has been presented and discussed in almost every workshop organized by SWIMing. Furthermore, it also has been presented in other events, such as Vocabulary Camp (VoCamp) workshop series, W3C TPAC meetings, conferences, and other events, where SWIMing partners participated. DAREED approach reuses and interlinks existing ontology and vocabularies which fulfil the data requirements of the use cases. For example, DAREED reuses geonames ontology for representing geolocation, SSN ontology for modelling building devices, schema.org for representing building on the high level, OM ontology for modelling the meas- Page 76 of 91

77 urement data, etc. The application of SWIMing methodology in DAREED is documented in wiki and in the BIM*Q Tool. STREAMER Project STREAMER [54] is a 4 year Integrated Project funded by the European Union that was started in 2013 already. An own installation of the BIM*Q tool was made available to STREAMER partners by AEC3. All data requirements have been documented in this database, but with special focus on mvdxml-based model checking. Accordingly, all data requirements are provided with detailed mapping definitions to the IFC data structure. The work with the BIM*Q database was guided by AEC3. One workshop has been organized and two 1,5 day meetings have been carried out discussing and reviewing data requirements provided by domain experts. Additional work was afterwards needed to consolidate the database, mainly to restructure and formalize discussed requirements. Similar to the structure of WP2 deliverables the work was divided into agreements made by domain experts and the work on technical specifications. The definition of data requirements went through an (unexpected) number of iteration cycles. New insights, extended requirements or new agreements about the IFC mapping were leading to a several revisions. BIM*Q was finally used as documentation tool reflecting latest agreements within the STREAMER consortium. Only few people were responsible to maintain the content in BIM*Q, which basically means to document the outcome of discussions. Trying to directly document all requirements in BIM*Q is difficult because the discussion often went like a brainstorming session leading to several substantial changes in the structure of requirements. Page 77 of 91

78 7 References [1] LBD Group, Linked Building Data Community. [Online]. Available: [2] buildingsmart, BuildingSMART Home Page, [Online]. Available: Page 78 of 91 H [3] M. Weise and K. McGlinn, SWIMing: D2.2 Guidelines and best practices for BLCEM process and data management - Phase I, [4] H. Wicaksono and K. McGlinn, SWIMING : D1.1 Business Use Cases for the Use of BIM-LOD in BLCEM Phase I, [5] H. Wicaksono and K. McGlinn, SWIMIng: D1.2 Business Use Cases for the use of BIM-LOD in BLCEM Phase II. [6] J. Wix, IDM Technology General Overview. [7] SWIMing Wiki- Seed Use Cases. [Online]. Available: [8] Kris McGlinn and Hendro Wicaksono, Use Case Classification Table. [Online]. Available: [Accessed: 18-Dec-2016]. [9] AEC3, BIM*Q - Manage your Employer s Information Requirements with BIM*Q, [Online]. Available: [10] S. Azhar, Building Information Modeling (BIM): Trends, Benefits, Risks, and Challenges for the AEC Industry, Leadersh. Manag. Eng., vol. 11, no. 3, pp , Jul [11] C. Bizer, T. Heath, and T. Berners-Lee, Linked data-the story so far, Serv. Interoperability, [12] T. U. Dresden, F. Noack, T. U. Dresden, M. Kadolsky, T. U. Dresden, T. Fraunhofer, F. H. R. F. Fouchal, S. M. Bassanino, and S. T. Fernando, Design4Energy D4.1 Domain models and meta model specifications, [13] T. Heath and C. Bizer, Linked Data: Evolving the Web into a Global Data Space, Synth. Lect. Semant. Web Theory Technol., vol. 1, no. 1, pp , Feb [14] W. W. W. Consortium, RDF 1.1 Concepts and Abstract Syntax, [15] E. Prud and A. Seaborne, Sparql query language for rdf, [16] FIEMSER. [Online]. Available: [17] L. Daniele, F. den Hartog, and J. Roes, Created in close interaction with the industry: the smart appliances reference (SAREF) ontology, Int. Work. Form., [18] M. Compton, P. Barnaghi, and L. Bermudez, The SSN ontology of the W3C semantic sensor network incubator group, Web Semant. Sci., [19] Adapt4EE. [Online]. Available: [Accessed: 08-Oct-2013].

79 Page 79 of 91 H [20] B. Vatant and M. Wick, GeoNames Ontology - Geo Semantic Web. [Online]. Available: [Accessed: 19- Dec-2016]. [21] H. Wicaksono, P. Dobreva, P. Häfner, and S. Rogalski, Methodology to Develop Ontological Building Information Model for Energy Management System in Building Operational Phase, vol Berlin, Heidelberg: Springer Berlin Heidelberg, [22] H. Wicaksono, K. Aleksandrov, and S. Rogalski, An intelligent system for improving energy efficiency in building using ontology and building automation systems [23] ifcowl ontology file added for IFC4_ADD1 Linked Building Data Community Group. [Online]. Available: [Accessed: 31-Aug-2015]. [24] M. Kofler and W. Kastner, Towards an ontology representing building physics parameters for increased energy efficiency in smart home operation, Proc. 2nd Cent. Eur., [25] OptEEmAL - Home. [Online]. Available: [Accessed: 19-Dec-2016]. [26] J.-R. Noemi, EEEMBEDDED Papers, eeembedded Project, [Online]. Available: [27] DAREED Home Page. [Online]. Available: [28] KnoholEM : Project Overview. [Online]. Available: [Accessed: 22-Jan-2013]. [29] J. Contreras, O. Corcho, and A. Gómez-Pérez, Six Challenges for the Semantic Web, [30] P. Shvaiko and J. Euzenat, Ontology matching: state of the art and future challenges, IEEE Trans. Knowl., [31] L. Otero-Cerdeira and F. Rodríguez-Martínez, Ontology matching: A literature review, Expert Syst. with, [32] E. Simperl, Reusing ontologies on the Semantic Web: A feasibility study, Data Knowl. Eng., [33] A. Freitas, E. Curry, and J. Oliveira, Querying heterogeneous datasets on the linked data web: Challenges, approaches, and trends, IEEE Internet, [34] Eebers. [Online]. Available: [Accessed: 19-Dec-2016]. [35] S. Donkers, H. Ledoux, J. Zhao, and J. Stoter, Automatic conversion of IFC datasets to geometrically and semantically correct CityGML LOD3 buildings, Trans. GIS, [36] L. Zhu and H. Mao, Building Interior Model Interpolation between IFC and CityGML, Open Constr. Build. Technol., [37] G. Lilis, G. Giannakis, and K. Katsigarakis, Simulation model generation

80 combining IFC and CityGML data, Proc., Page 80 of 91 H [38] CityGML-ADEs - CityGML Wiki. [Online]. Available: [Accessed: 16-Dec-2016]. [39] N. Hargreaves, G. Taylor, and A. Carter, Smart grid interoperability use cases for extending electricity storage modeling within the IEC common information model, th Int., [40] K. Stelios, K. McGlinn, and M. Weise, SWIMing: D3.10 e Report of the 4th Workshop. [41] J. Ploennigs, A. Schumann, and F. Lecue, Extending Semantic Sensor Networks for Automatically Tackling Smart Building Problems. [42] K. Huat SOON, R. Thompson, and V. Khoo, Semantics-based Fusion for CityGML and 3D LandXML. [43] Mathias Axling, D2.4 DIMMER Ontologies: report, [44] F. B. Edoadrdo Patti, D2.2.2 DIMMER Interoperability Implementation, [45] P. Brizzi, D. Bonino, and A. Musetti, Towards an ontology driven approach for systems interoperability and energy management in the smart city, Energy Sci., [46] Laura Daniele, SAREF Ontology. [Online]. Available: [47] J. Euzenat and P. Shvaiko, Ontology matching [48] D. Tzovaras and K. Mcglinn, SWIMING : D3.9 3rd Workshop Report, [49] P. Pauwels and K. McGlinn, Building Data on the Web Working Group Charter. [Online]. Available: [Accessed: 22-Dec- 2016]. [50] P. Pauwels and A. Roxin, SimpleBIM: From full ifcowl graphs to simplified building graphs, 11th Eur. Conf. Prod., [51] GeoSPARQL - A Geographic Query Language for RDF Data OGC. [Online]. Available: [Accessed: 24- Dec-2016]. [52] Ready4SmartCities D4.2 - Requirements and guidelines for energy data publication. [53] NewTREND New integrated methodology and Tools for Retrofit design towards a next generation of ENergy efficient and sustainable buildings and Districts. [Online]. Available: [Accessed: 22-Dec-2016]. [54] STREAMER Research Results. [Online]. Available: [55] The Protégé Ontology Editor and Knowledge Acquisition System. [Online]. Available: [Accessed: 01-Mar-2013]. [56] WebProtege. [Online]. Available: [Accessed: 20-Dec-2016].

81 [57] S. Staab and R. Studer, Handbook on ontologies H [58] C. Debruyne, T.-K. Tran, and R. Meersman, Grounding Ontologies with Social Processes and Natural Language, J. Data Semant., vol. 2, no. 2 3, pp , Jun [59] A. De Nicola, M. Missikoff, and R. Navigli, A proposal for a unified process for ontology building: UPON, Int. Conf., [60] M. Jarrar and R. Meersman, Ontology Engineering The DOGMA Approach, in Advances in Web Semantics I, Berlin, Heidelberg: Springer Berlin Heidelberg, 2008, pp [61] K. Kaljurand, ACE View---an Ontology and Rule Editor based on Attempto Controlled English., OWLED, [62] NeOn Project. [Online]. Available: [Accessed: 21-Dec-2016]. [63] M. Suárez-Figueroa and A. Gomez-Perez, The NeOn methodology for ontology engineering, Ontol. Eng., [64] H. Wicaksono, K. Tonev, and P. Dobreva, Linked Data for Data Integration based on SWIMing Guideline: Use Cases in DAREED Project, in 4th International Workshop on Linked Data in Architecture and Construction (LDAC), [65] M. Weise and K. Mcglinn, SWIMING : D2.1 Data Management Plan, Page 81 of 91

82 Appendix A SWIMing Methodology and its relationship to the Wiki and BIM*Q Tool This section describes the SWIMing methodology which has been previously presented in D2.2 [3] and provides specific reference to the use of the shared wiki and also the BIM*Q tool. As described in D2.2 the following 5 steps based on the IDM/MVD Methodology have been introduced: Step one (1) is to identify the BLC stages which have been defined within the context of the Linked Building Data community and consist of: Design, Construction, Commissioning, Operation, Retrofitting/ Refurbishment/ Reconfiguration, Demolition/Recycling. 13 Figure 31: High Level Use Case Template Step two (2) is to identify the different actors involved in the different processes required to complete the use case. 13 This data is first recorded using an open shared wiki [7], described in D1.1 [4]. The shared wiki provides a template (Figure 31) which allows BLC stages to be added to a description of the use case. Page 82 of 91

83 The purpose of this process is to enable the quick identification of responsible stakeholders for generating and processing data exchanges. For each process identified in the use case at least one actor must be defined who is responsible for generating that data. Step three (3) is to identify at a high level the data domains that the use case requires and consist of [7], [4]: Product Device Control Behaviour Communications Data Measures Energy Weather Geolocation The purpose of this process is to provide a quick reference to data structures best suited for a particular domain. Again this data is added to the wiki, resulting in a description of the use case, for example the use case Decision support tool for district renovation planning 14 is shown in Figure 32. The high level use cases are used to automatically generate the use case overview [8] Figure 32 High Level Use Case Wiki Example 14 Page 83 of 91

84 After the high level use cases is described, the steps 4-5 require more functionality, and so we recommend the use of the BIM*Q tool. The first steps are to align the data from the wiki with the BIM*Q tool. To achieve this one must currently take the wiki use case title and description and add these to a new use case templates created in the BIM*Q tool (Figure 33). Once this has been completed, the user must continue to copy and paste data across to the BIM*Q tool. Step 1 and 2 are shown in the BIM*Q in Figure 34 and Figure 35 respectively. In Step 3, particular ontologies are added for each domain as can be seen in Figure 36. Once these steps have been completed, it is possible to begin Steps 4-5. Figure 33 Overview of Use Cases in BIM*Q Page 84 of 91

85 Figure 34 Defining Processes in BIM*Q Figure 35 Defining Stakeholders/Actors in BIM*Q Figure 36 Defining Available Ontologies in BIM*Q Page 85 of 91

86 Step four (4) is to identify in greater detail the specific data requirements for each process in the use case. The purpose of this step is to understand the exact structure of the data required to meet the use case. Each data value that is required must be captured and described. This involves structuring the data as concepts and properties. These classes are then aligned with the processes and actors. Step five (5) is where the conceptual model is aligned with existing ontologies and standards (Figure 37). The purpose of this step is to provide a quick reference point for the identification of alignments within existing domain models, thus supporting those who wish to enable similar use cases. The alignment process is based upon expert knowledge of the existing domain models and therefore may need to undergo several review steps to ensure that the data alignments are correct (see Step/Task 8 in D2.2). Figure 37 Concept Definition and Alignment with Processes and Ontologies in BIM*Q Figure 38 A Specific Data Exchange Defined in BIM*Q Tool Page 86 of 91