Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 Automated Ontology Matching in the Architecture, Engineering and Construction Domain - A Case Study Georg Ferdinand Schneider1,2[0000−0002−2033−859X] 1 Fraunhofer Institute for Building Physics IBP, Fürther Straße 250, 90429 Nürnberg, Germany 2 Technische Hochschule Nürnberg, Fürther Straße 250, 90429 Nürnberg, Germany georg.schneider@ibp.fraunhofer.de Abstract. The ontology-based modelling of the built environment is deemed promising to successfully integrate disparate knowledge silos and has gained significant attraction in industry and academia. This interest has led to a proliferating number of ontologies and the manual definition of schema level alignments among them is a tedious task. Hence, this paper explores the possibilities of automated ontology matching methods in this regard. This work compares manually created and automatically generated alignments of six domain ontologies to the building topology ontology. The initial findings of this case study indicate that current state of the art ontology matching tools are in principle capable of detecting automatically correct alignments and that their is a strong need to define domain specific benchmarks. Keywords: Automated Ontology Matching · Architecture · Engineering · Construction · Facility Management · Heterogeneity · Building Topol- ogy Ontology. 1 Introduction Ontology-based modelling and associated implementations based on Semantic Web Technologies (SWT) [10] have gained attention by academia and indus- try in the Architecture, Engineering, Construction and Facility Management (AEC/FM) domain [23]. A main motivation to use the technology is its abil- ity to successfully address the problem of integrating heterogeneous information silos distributed across the AEC/FM domain [2]. The spread of the technology has lead to a proliferating development of do- main ontologies (cf. reviews in [7,23,25]). This development poses the risk of putting the benefits of the technology at stake as the defined ontologies over- lap and found ontological design patterns are reimplemented again and again making a reuse difficult. ’Thus, merely using ontologies, like using XML, does not reduce heterogeneity: it raises heterogeneity problems to a higher level.’ [12]. The principle of ontology reuse stipulated in well-known ontology engineering 35 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 methodologies [19,14] is frequently not followed, when designing domain ontolo- gies in the building domain. This makes it cumbersome for potential developers to implement applications as again a heterogeneous landscape of domain models appears. The Building Topology Ontology (BOT), initially defined in [25,26] and fur- ther developed by the members of the W3C Linked Building Data Community Group (W3C LBD CG) [32], has been proposed to define commonly reoccur- ring design patterns in domain ontologies of the AEC/FM domain. These design patterns then can be reused by developers in their respective domains through extending from BOT [29]. Following this approach, intrinsically a domain wide interoperability can be ensured. The successful manual alignment of five domain ontologies (SAREF4Buil- ding [24], BRICK [3,4], DogOnt [6], ThinkHome [27], ifcOWL [22]) to BOT is presented in an initial effort in Schneider [29]. The schema level alignment of ontologies is a tedious task, which potentially is as challenging as ontology engineering itself [12]. There exists a strong need to use automated ontology matching methods to automatically find alignments [7]. Also ontologies tend to evolve over time and alignments need to be updated and checked accordingly. The analysis of the current state of the art presented in section 2 indicates that the use of automated ontology matching methods has not been studied in depth in the AEC/FM domain so far. The contributions of this paper are two fold. First, manual alignments orig- inally defined in an earlier contribution [29] are revised and updated to reflect the latest version of BOT (v0.3.0). Second, a study is conducted, where an auto- mated ontology matching method [13] is utilised to align the respective domain ontologies to BOT. The generated alignments are compared to the manually found ones. The remainder of this paper includes a review of existing work (Section 2) related to the automated matching of ontologies in the AEC/FM domain. Then in Section 3 a methodology is presented to compare manually defined and auto- mated generated alignments of domain ontologies. Finally, in Section 4 revised manual alignments are presented and the results of the comparison to automat- ically generated alignments are presented in Section 5. 2 Related Work The field of ontology matching has been around for a number of years and the fundamentals of the technology are presented in Euzenat & Shvaiko [12,30]. Spe- cific matching algorithms are developed actively and their performance is evalu- ated yearly in benchmark tests under the supervision of the Ontology Alignment Evaluation Initiative (OAEI), where the results of the most recent event are pre- sented in Algergawy et al. [1]. A, yet limited, number of contributions, which investigate the topic of ontol- ogy matching in the context of the AEC/FM domain exist. 36 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 In their demand for interoperability in the smart cities domain, Costin & Eastman [7] conduct a thorough review of existing contributions in this regard. They conclude the ontology-based modelling of the domain based on SWT pro- vide means to address the prevalent heterogeneity. However, as the manual align- ment of domain ontologies is a tedious task, the demand for automated ontology matching methods is made. Otero-Cerdeira et al. [20] investigate the use of automated ontology match- ing methods in the context of smart cities. The present OntoPhil a ontology matching technique specifically designed for the matching of disparate knowl- edge sources in the context of smart cities. Beside the cited works no further documentation or download possibility of the OntoPhil tool has been found. Bellini et al. [5] present a system for the integration of disparate data sources in the context of smart cities. The system is designed to handle large data volumes and integrates them by mapping the data to the Knowledge Model for City (KM4City) ontology. The actual mapping is undertaken manually using the Karma Data Integration tool [15]. Gyrard et al. [16] present an approach to enrich ontology catalogues with do- main ontologies of smart cities. Their approach aims for interoperability among applications by providing an interface, the catalogue, to developers to easily find and reuse existing domain ontologies. An automated update is discussed ’but a manual checking is preferred to handle synonyms’ [16]. Espinoza-Arias et al. [11] review existing ontological representations of smart city data. No explicit mappings are defined among the ontologies but after a characterisation a number of reoccurring ontology design patterns are defined. The presented contributions indicate that automated ontology matching meth- ods seem to be promising to address heterogeneity of formats and formal models. Most work reviewed focuses on ontology matching and alignment in the domain of smart cities. The AEC/FM domain can be seen as a sub-domain of smart cities but it has not been discussed in detail to the best of the authors knowledge. 3 Methodology A methodology is established to evaluate and compare the manual and auto- mated matching of ontologies in the AEC/FM domain. In the study the defi- nition of alignments between BOT [25,26] and six domain ontologies is studied (SAREF4Building [24], BRICK [3,4], DogOnt [6], ThinkHome [27], ifcOWL [22], DERI Room [8]). The namespaces used in the work are reported in Table 1. In particular the following steps are conducted: 1. Manual definition of alignments on class and object property level; 2. Use of the AgreementMakerLight [13] tool to automatically generate align- ments; 3. Comparison of the obtained manual and automatically created alignments. The manual definition of alignments is an extension and revision of the work documented in an earlier contribution [29]. The step involves the retrieval and 37 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 local storage of the most recent version of all involved ontologies. The definition of an alignment ontology which performs a full import (owl:import) of BOT and the respective domain ontology. Finally, alignments are defined manually through the use of the Protégé ontology editor [18]. The defined alignments mainly use subsumption for alignment. This has been found beneficial in discussion within the W3C LBD CG as the semantic implied by subsumption are less rigid as compared the definition of equivalences. Equivalence (e.g. owl:equivalence- Class) implies that all statements on one class also are true for the other, which might not always be the case. An OWL DL reasoner is invoked on the resulting alignment ontology (Pellet [31]) to ensure the consistency. The defined ontologies are published in an online repository3 . A large number of tools and associated algorithms exist to perform auto- mated ontology matching [12,21,1]. An an initial attempt here the Agreement- MakerLight tool [13] is chosen from an extensive list of available tools4 . The usage of the AgreementMakerLight tool has been found intuitive and the tool is available open-source in as a compiled java library from a web repository. The tool is used with default settings and BOT is always used as the source ontology. Table 1. Namespaces and prefixes used in this work. Prefix Value rdf http://www.w3.org/1999/02/22-rdf-syntax-ns# rdfs http://www.w3.org/2000/01/rdf-schema# owl http://www.w3.org/2002/07/owl# bot https://w3id.org/bot# s4bldg https://w3id.org/def/saref4bldg# dog http://elite.polito.it/ontologies/dogont.owl# th https://www.auto.tuwien.ac.at/downloads/thinkhome/ ontology/BuildingOntology.owl# thvs https://www.auto.tuwien.ac.at/downloads/thinkhome/ ontology/BuildingOntologySharedVocabulary.owl# ifc http://www.buildingsmart-tech.org/ifcOWL/IFC4_ADD2# brick https://brickschema.org/schema/1.0.2/Brick# rooms http://vocab.deri.ie/rooms# 4 Manually Defined Alignments In this section the results of the extended, revised and manually defined align- ments between BOT ontology and other domain ontologies are reported. 3 https://github.com/w3c-lbd-cg/bot/tree/AlignmentRevision, Last accessed: 20 May 2019 4 http://www.mkbergman.com/2129/30-active-ontology-alignment-tools/, Last accessed: 20 May 2019 38 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 4.1 SAREF Extension for Building Devices The SAREF Extension for Building Devices (SAREF4Building) [24] ontology is an ontology to extend the SAREF ontology [9] into the buildings domain. A description of the ontology can be found in its documentation and reviews [24,23,29]. The defined alignments are reported in Table 2 and the rationale behind is described in the following paragraph. SAREF4Building describes the concepts of s4bldg:Buildings and s4bldg:- Spaces, which can be defined as specialisations of bot:Building and bot:Space. As the focus of SAREF and its extension to the buildings domain focus on the description of tangible devices, s4bldg:PhysicalObjects, s4bldg:Sensors and s4bldg:Actuators qualify as bot:Elements, which again has been formalised through subsumption. The, compared to the last iteration of alignments [29], newly introduced high level relationships bot:containsZone and bot:containsElement reflect on a high level the semantics of s4bldg:hasSpace and s4bldg:contains ob- ject properties of SAREF4Building and are aligned through defining them as subproperties of the respective BOT object properties (see Table 2). Table 2. Proposed alignment of BOT [25] and SAREF4Building [24]. Subject Predicate Object Class level: s4bldg:Building rdfs:subClassOf bot:Building s4bldg:PhysicalObject rdfs:subClassOf bot:Element s4bldg:Sensor rdfs:subClassOf bot:Element s4bldg:Actuator rdfs:subClassOf bot:Element s4bldg:BuildingSpace rdfs:subClassOf bot:Space Object property level: s4bldg:hasSpace rdfs:subPropertyOf bot:containsZone s4bldg:contains rdfs:subPropertyOf bot:containsElement 4.2 BRICK Uniform Schema for Representing Metadata in Buildings The BRICK ontology [3,4] is an ontology, which focuses on the description of building management systems and their domain concepts such as data points, HVAC equipment and the topology of the building. The defined and revised alignments are reported in Table 3 and explained in the following. The alignments are defined by using subsumption on class and object prop- erty level. A brick:Location is considered as a specialisation of bot:Zone as it is used as a super-concept from other concepts describing topological as- pects of a building. Hence, the alignment of brick:Building, brick:Floor, 39 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 brick:Basement, brick:Outside, brick:Room, brick:Space and brick:Wing is straightforward. A brick:Zone is considered to be a specialisation of a bot:- Space as BRICK uses this concepts to refer to HVAC zones often used in the context of the control of a building. The brick:Equipment of a building and brick:Points are considered as specialisations of bot:Element. In particular this holds for the concept brick:Point as BRICK describes for instance sensors or meters as tangible objects, which are located in some zone or space. The semantics of brick:contains can be directly mapped to bot:contains- Element and, hence, a specialisation is defined. Interesting is the brick:has- Part object property defined in BRICK. The property can be used to relate brick:Equipment to brick:Sensors, brick:Equipment to brick:Equipment or brick:Locations to brick:Locations [3], hence, it qualifies for an extension of bot:containsElement, bot:containsZone and bot:hasSubElement as defined. Similar semantics apply for the brick:hasPoint object property, which can be specialised from bot:containsZone and bot:containsElement as it allows to relate brick:Equipment to brick:Sensors and brick:Locations to brick:- Sensors. Table 3. Proposed alignment of BOT [25] and BRICK [3,4]. Subject Predicate Object Class level: brick:Location rdfs:subClassOf bot:Zone brick:Building rdfs:subClassOf bot:Building brick:Floor rdfs:subClassOf bot:Storey brick:Basement rdfs:subClassOf bot:Space brick:Outside rdfs:subClassOf bot:Space brick:Room rdfs:subClassOf bot:Space brick:Space rdfs:subClassOf bot:Space brick:Wing rdfs:subClassOf bot:Space brick:Zone rdfs:subClassOf bot:Space brick:Equipment rdfs:subClassOf bot:Element brick:Point rdfs:subClassOf bot:Element Object property level: brick:contains rdfs:subPropertyOf bot:containsElement brick:hasPart rdfs:subPropertyOf bot:containsZone brick:hasPart rdfs:subPropertyOf bot:containsElement brick:hasPart rdfs:subPropertyOf bot:hasSubElement brick:hasPoint rdfs:subPropertyOf bot:containsZone brick:hasPoint rdfs:subPropertyOf bot:containsElement 40 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 4.3 DogOnt - Ontology Modeling for Intelligent Domotic Environments DogOnt ontology is an ontology to formally describe the domain of domotic devices in home appliances. It is initially described in Bonino & Corno [6] but has since undergone many revision and extensions. The most recent version as of writing (4.0.1) can be obtained from a remote repository5 . A number of concepts of the ontology can be specialised from BOT. The defined alignments are reported in Table 4. In particular the ontology describes the concepts dogont:Building, dogont:Storey, dogont:Room, which can be mapped to respective BOT concepts. The general concept of dogont:Environ- ment can be seen of a generalisation of the bot:Zone concept as defined. Inter- esting is the definition of the concepts dogont:Ceiling and dogont:Floor as areas bounding a room. This complies to the definition of bot:Interface and can be aligned by specialisation. To reflect the different semantics the different sub-concepts of dogont:UnControllable need to be separately specialised (e.g. dogont:Furniture). In terms of aligning object properties a number of specialisation can be found. The object property dogont:contains is used in DogOnt to describe that some tangible object is fully contained in a dogont:BuildingEnviroment. Essentially this is the semantics of bot:containsElement. The object properties dogont:belongsTo and dogont:hasWallOpening allow to describe composition of classes which specialised from bot:Element. Hence, they are specialised from bot:hasSubElement, potentially its inverse where needed. Interesting are also the dogont:floorOf and dogont:ceilingOf object properties, which qualify as specialisation of bot:interfaceOf together with the specialisation of dogont:- Ceiling and dogont:Floor as bot:Interface as defined above. 4.4 ThinkHome Ontology The ThinkHome ontologies [27] are a family of ontologies to describe smart home systems formally and link this with adjacent domains. A detailed description of the ontologies can be found in its documentation and reviews [27,22,28]. Align- ments are defined to the BuildingOntology of the family of ontologies, which has been derived from the gbXML format6 . The common concepts of th:Campus, th:Building, th:BuildingStorey, th:Opening, th:Space, th:Zone and th:Equipment can be specialised directly from BOT. Interesting are the concepts th:Construction, th:Layer, th:- Material, which refer to different layers of a wall needed for instance in building performance simulation. The semantics comply to bot:Interface and hence a specialisation is defined. A number of object properties are defined in ThinkHome, which describe the containment of an element in a zone, a zone in a zone or composition of 5 https://github.com/iot-ontologies/dogont, Last accessed: 20 May 2019 6 http://www.gbxml.org/, Last accessed: 20 May 2019 41 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 Table 4. Proposed alignment of BOT [25] and DogOnt [6]. Subject Predicate Object Class level: dog:Building rdfs:subClassOf bot:Building dog:Storey rdfs:subClassOf bot:Storey dog:Room rdfs:subClassOf bot:Space bot:Zone rdfs:subClassOf dog:Environment dog:BuildingEnvironment rdfs:subClassOf bot:Zone dog:Room rdfs:subClassOf bot:Space dog:Balcony rdfs:subClassOf bot:Zone dog:Terrace rdfs:subClassOf bot:Zone dog:Controllable rdfs:subClassOf bot:Element dog:Device rdfs:subClassOf bot:Element dog:TechnicalSystem rdfs:subClassOf bot:Element dog:Vertical rdfs:subClassOf bot:Element dog:Furniture rdfs:subClassOf bot:Element dog:Ceiling rdfs:subClassOf bot:Interface dog:Floor rdfs:subClassOf bot:Interface Object property level: dog:contains rdfs:subPropertyOf bot:containsElement dog:belongsTo rdfs:subPropertyOf owl:inverseOf bot:hasSubElement dog:floorOf rdfs:subPropertyOf bot:interfaceOf dog:ceilingOf rdfs:subPropertyOf bot:interfaceOf dog:hasWall rdfs:subPropertyOf bot:adjacentElement dog:hasWallOpening rdfs:subPropertyOf bot:hasSubElement 42 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 elements. Hence, the object properties are specialised from the respective object properties in BOT as reported in Table 5. Table 5. Proposed alignment of BOT [25] and ThinkHome [27]. Subject Predicate Object Class level: th:Campus rdfs:subClassOf bot:Site th:Building rdfs:subClassOf bot:Building th:BuildingStorey rdfs:subClassOf bot:Storey th:Opening rdfs:subClassOf bot:Element th:Space rdfs:subClassOf bot:Space th:Zone rdfs:subClassOf bot:Zone th:Construction rdfs:subClassOf bot:Interface th:Layer rdfs:subClassOf bot:Interface th:Material rdfs:subClassOf bot:Interface th:SpaceBoundary rdfs:subClassOf bot:Interface th:Surface rdfs:subClassOf bot:Interface th:Equipment rdfs:subClassOf bot:Element Object property level: th:containsBuilding rdfs:subPropertyOf bot:hasBuilding th:containsBuildingStorey rdfs:subPropertyOf bot:hasStorey th:containsSpace rdfs:subPropertyOf bot:hasSpace th:containsSpaceBoundary rdfs:subPropertyOf bot:interfaceOf th:containsLighting rdfs:subPropertyOf bot:containsElement th:containsHydronicLoopEquipment rdfs:subPropertyOf bot:hasSubElement th:containsAirLoopEquipment rdfs:subPropertyOf bot:hasSubElement th:hasDefinedAdjacentSpace rdfs:subPropertyOf owl:inverseOf bot:adjacentZone th:isDefinedAdjacentSurfaceOf rdfs:subPropertyOf bot:interfaceOf thsv:isEquipmentOf rdfs:subPropertyOf owl:inverseOf bot:hasElement 4.5 Industry Foundation Classes 4 Addendum 2 No new or revised alignments to the OWL version of the Industry Foundation Classes (IFC) [17,22] from BOT are found in this work in comparison to the initial mapping [29]. However, the alignments are changed to subsumption as mentioned above. 4.6 DERI Room Ontology The DERI Room ontology [8] has been added to this study as is represents a light weight vocabulary, compared to the other ontologies, dedicated to the description of buildings. The found alignments are documented in Table 7 and almost all classes and object properties could be specialised from BOT. 43 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 Table 6. Proposed alignment of BOT [25] and ifcOWL4 Add2 [22]. Subject Predicate Object ifc:IfcSite rdfs:subClassOf bot:Site ifc:IfcBuilding rdfs:subClassOf bot:Building ifc:IfcBuildingStorey rdfs:subClassOf bot:Storey ifc:IfcSpace rdfs:subClassOf bot:Space ifc:IfcElement rdfs:subClassOf bot:Element Table 7. Proposed alignment of BOT [25] and DERI Room [8]. Subject Predicate Object Class level: rooms:Site rdfs:subClassOf bot:Site rooms:Building rdfs:subClassOf bot:Building rooms:Floor rdfs:subClassOf bot:Storey rooms:FloorSection rdfs:subClassOf bot:Storey rooms:Desk rdfs:subClassOf bot:Element rooms:Room rdfs:subClassOf bot:Space Object property level: rooms:contains rdfs:subPropertyOf bot:containsZone 4.7 Summary The results of the manually defined and revised alignments are summarised in Table 8. The respective domain ontologies are denoted and the considered version of the ontology, if applicable. All defined mappings are defined in a separated ontology file and the respective ontology is checked for consistency by invoking a OWL DL reasoner (Pellet [31]) and looking for inconsistencies. The total number of alignments between concepts and object properties are reported. It should be noted that the total number does not qualify as a metric to determine if BOT can be extended very well to the respective domain. In comparison to the last study [29] it is interesting that the number of ontologies, where a mapping on the object property level is possible has been significantly increased. 5 Automated Alignment As described in Section 3 a study is conducted in this work using the tool AgreementMakerLight [13] to automatically derive ontology alignments. Figure 1 shows as an example the result reported by the tool for matching BOT and the ThinkHome ontology. The tool reports the found alignments in the graphical user interface as well as exports them in RDF format. All automatically found alignments are reported in Table 9. The automated ontology matching tool has found from zero up to three alignments between concepts of the respective ontologies. No alignments 44 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 Table 8. Evaluation of manually defined alignments to BOT version v0.3.0. Consis- tency - Invoking Pellet [31] reasoner on the respective alignment ontology including owl:imports did not return any faults. Domain Version Consistency No. of Alignments No. of Alignments Ontology owl:Class owl:objectProperty S4BLDG [24] 1 OK 5 2 BRICK [3,4] 1.0.2 OK 11 6 DogOnt [6] 4.0.1 OK 15 6 ThinkHome [27] 1.12 OK 12 10 ifcOWL [22] 4Add2 OK 5 0 DERIRoom [8] - OK 6 1 Fig. 1. Results reported for automatically matching BOT and ThinkHome ontologies by the AgreementMakerLight tool [13]. 45 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 between object properties are found. The reported suggested alignment is always equivalence. One false alignment is reported mapping a bot:Space to ifc:- IfcSpaceType. AgreementMakerLight implements three types of primary matching algo- rithms: a lexical matcher, mediating matcher and word matcher and one sec- ondary type matching algorithm: a parametric string matcher [13]. An in depth treatment of the matching methods is beyond the scope of this paper. All algo- rithms take as an input the two to-be-aligned ontologies. The primary matching algorithms compare obtained terms and assert alignments if a similarity measure exceeds a threshold with different complexities. Hence, it should be noted that the chosen parameterisation of the thresholds, etc. has an impact on the results and should be studied in more detail on a elaborated benchmark defined for the AEC/FM domain. In the initial experiments conducted in this study the default suggested values are utilised. Table 9. Results reported for automatically matching BOT to the respective listed domain ontology. (1) - Domain Ontology, (2) - Number of found alignments, X - Falsely reported alignment. (1) (2) BOT Concept Target concept Type S4BLDG [24] 1 bot:Building s4bldg:Building Equivalence BRICKFrame [3,4] - - - - DogOnt [6] 2 bot:Storey dog:Storey Equivalence bot:Building dog:Building Equivalence ThinkHome [27] 3 bot:Space th:Space Equivalence bot:Building th:Building Equivalence bot:Building thsv:Building Equivalence ifcOWL [22] 2 bot:Element ifc:IfcBuildingElement Equivalence X bot:Space ifc:IfcSpaceType Equivalence DERIRoom [8] 2 bot:Site rooms:Site Equivalence bot:Building rooms:Building Equivalence 6 Discussion Automated ontology matching is a well-known discipline and the topic is re- searched since decades. A plethora of tools is available, see e.g. [1]. In this study only one tool has been used. A detailed study of methods and tools should be conducted to further clarify the abilities of automated ontology matching meth- ods for their application in the AEC/FM domain. The ontologies considered in this study mainly reside from the building au- tomation domain. This is mainly motivated by the authors expertise and research interest. However, other AEC/FM domains should be included in future studies on automated ontology matching. 46 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 7 Conclusion Within this paper manually defined and automatically obtained alignments be- tween domain ontologies from the Architecture, Engineering, Construction/ Fa- cility Management (AEC/FM) domain to the Building Topology Ontology (BOT) [25] are compared. The manual definition of alignments between ontologies is a tedious task and almost as difficult as developing ontologies from scratch. Ini- tial experiments show that automated matching methods can support finding alignments. The results are promising to also support not only the alignment of domain ontologies but the revision of alignments, e.g. because of schema level updates. The presented study can only be seen as a starting point and the following open questions for future research remain: – There is a strong need for the definition of a well-defined benchmark from AEC/FM domain, potentially including building product data, to establish the attention of ontology matching experts; – Addittional sub-domains of the AEC/FM domain should be added in future studies; – As ontologies evolve over time a future question is, if existing alignments can be reused as a starting point (”hot-start”) for matching methods. Acknowledgements This paper documents work conducted in a collaborative effort by the W3C LBD CG. The author gratefully acknowledges financial support from MOEEBIUS project, a Horizon 2020 research and innovation program under grant agreement No. 680517 and the initiative Mittelstand 4.0 by the German Federal Ministry for Economic Affairs and Energy. References 1. Algergawy, A., Cheatham, M., Faria, D., Ferrara, A., Fundulaki, I., et al.: Results of the ontology alignment evaluation initiative 2018. In: Proc. of OM. pp. 1–41. Monterey, USA (2018) 2. Anumba, C.J., Issa, R.R., Pan, J., Mutis, I.: Ontology based information and knowledge management in construction. Construction Innovation 8(3), 218–239 (2008). https://doi.org/10.1108/14714170810888976 3. Balaji, B., Bhattacharya, A., Fierro, G., Gao, J., Gluck, J., Hong, D., Jo- hansen, A., Koh, J., Ploennigs, J., Agarwal, Y., Berges, M., Culler, D., Gupta, R., Kjærgaard, M.B., Srivastava, M., Whitehouse, K.: Brick: Towards a unified metadata schema for buildings. In: Proc. of BuildSys. Palo Alto, USA (2016). https://doi.org/10.1145/2993422.2993577 4. Balaji, B., Bhattacharya, A., Fierro, G., Gao, J., Gluck, J., Hong, D., Johansen, A., Koh, J., Ploennigs, J., Agarwal, Y., Berges, M., Culler, D., Gupta, R.K., Kjærgaard, M.B., Srivastava, M., Whitehouse, K.: Brick : Metadata schema for portable smart building applications. Applied Energy 226, 1273–1292 (2018). https://doi.org/10.1016/j.apenergy.2018.02.091 47 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 5. Bellini, P., Benigni, M., Billero, R., Nesi, P., Rauch, N.: Km4city ontology building vs data harvesting and cleaning for smart-city services. Journal of Visual Languages & Computing 25(6), 827–839 (2014). https://doi.org/10.1016/j.jvlc.2014.10.023 6. Bonino, D., Corno, F.: DogOnt - Ontology Modeling for Intelligent Domotic Environments. Lecture Notes in Computer Science 5318, 790–803 (2008). https://doi.org/10.1007/978-3-540-88564-1 51 7. Costin, A., Eastman, C.: Need for interoperability to enable seamless information exchanges in smart and sustainable urban systems. Journal of Computing in Civil Engineering 33(3), 1–14 (2019) 8. Cyganiak, R.: Buildings and rooms vocabulary. http://vocab.deri.ie/rooms, Last accessed: 20 May 2019 (2012), Digital Enterprise Research Institute (DERI), Galway, Ireland 9. Daniele, L., den Hartog, F., Roes, J.: Created in Close Interaction with the Indus- try: The Smart Appliances REFerence (SAREF) Ontology. In: Cuel, R., Young, R. (eds.) Proc. of FOMI. pp. 100–112. Springer International Publishing, Cham, Switzerland (August 5 2015). https://doi.org/10.1007/978-3-319-21545-7 9 10. Domingue, J., Fensel, D., Hendler, J.A.: Handbook of semantic web technologies. Springer, Berlin, Germany (2011). https://doi.org/10.1007/978-3-540-92913-0 11. Espinoza-Arias, P., Poveda-Villalon, M., Garcia-Castro, R., Corcho, O.: Ontologi- cal representation of smart city data: From devices to cities. Applied Sciences 9(1) (2018). https://doi.org/10.3390/app9010032 12. Euzenat, J., Shvaiko, P.: Ontology matching, vol. 18. Springer, Heidelberg, Ger- many, 2nd edn. (2013). https://doi.org/10.1007/978-3-642-38721-0 13. Faria, D., Pesquita, C., Santos, E., Palmonari, M., Cruz, I.F., Couto, F.M.: The AgreementMakerLight Ontology Matching System. In: Proc. of ODBASE. Springer, Berlin, Germany (2013). https://doi.org/10.1007/978-3-642-41030-73 8 14. Fernández-López, M., Gómez-Pérez, A., Juristo, N.: Methontology: from ontolog- ical art towards ontological engineering. In: Proc. of AAAI. pp. 33–40. Stanford, USA (March 24-26 1997) 15. Gupta, S., Szekely, P., Knoblock, C.A., Goel, A., Taheriyan, M., Muslea, M.: Karma: A system for mapping structured sources into the semantic web. In: Proc. of ESWC. pp. 430–434 (2015) 16. Gyrard, A., Zimmermann, A., Sheth, A.: Building iot-based applications for smart cities: How can ontology catalogs help? IEEE Internet of Things Journal 5(5), 3978–3990 (Oct 2018). https://doi.org/10.1109/JIOT.2018.2854278 17. ISO: ISO 16739 - Industry Foundation Classes (2013) 18. Musen, M.A., Team, T.P.: Protégé Ontology Editor. In: Dubitzky, W., Wolken- hauer, O., Cho, K.H., Yokota, H. (eds.) Encyclopedia of Systems Biology. pp. 1763–1765. Springer, New York, USA (2013). https://doi.org/10.1007/978-1-4419- 9863-7 1104 19. Noy, N.F., McGuinness, D.L.: Ontology Development 101: A Guide to Creating Your First Ontology. Tech. Rep. SMI-2001-0880, Stanford University, Stanford, USA (2001) 20. Otero-Cerdeira, L., Rodrı́guez-Martı́nez, F., Gómez-Rodrı́guez, A.: Definition of an ontology matching algorithm for context integration in smart cities. Sensors 14(12), 23581–23619 (2014) 21. Otero-Cerdeira, L., Rodrı́guez-Martı́nez, F.J., Valencia-Requejo, T., Gómez- Rodrı́guez, A.: A new similarity measure for an ontology matching system. In: Fred, A., Dietz, J.L.G., Aveiro, D., Liu, K., Filipe, J. (eds.) Knowledge Discov- ery, Knowledge Engineering and Knowledge Management. pp. 257–272. Springer International Publishing, Cham, Switzerland (2015) 48 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 22. Pauwels, P., Terkaj, W.: EXPRESS to OWL for construction industry: Towards a recommendable and usable ifcOWL ontology. Automation in Construction 63, 100–133 (2016). https://doi.org/10.1016/j.autcon.2015.12.003 23. Pauwels, P., Zhang, S., Lee, Y.C.: Semantic web technologies in AEC indus- try: A literature overview. Automation in Construction 73, 145–165 (2017). https://doi.org/10.1016/j.autcon.2016.10.003 24. Poveda Villalon, M., Garcia Castro, R.: SAREF extension for build- ing devices (2017), http://ontoology.linkeddata.es/publish/saref4bldg/ index-en.html, [Online; last accessed 2017-09-12] 25. Rasmussen, M.H., Pauwels, P., Hviid, C.A., Karlshøj, J.: Proposing a Central AEC Ontology That Allows for Domain Specific Extensions. In: Proc. of LC3. vol. 1, pp. 237–244. Heraklion, Greece (2017). https://doi.org/10.24928/JC3-2017/0153 26. Rasmussen, M.H., Pauwels, P., Lefrançois, M., Schneider, G.F., Hviid, C.A., Karlshøj, J.: Recent changes in the Building Topology Ontology. In: Proc. of LDAC. Dijon, France (November 2017) 27. Reinisch, C., Kofler, M.J., Iglesias, F., Kastner, W.: Thinkhome energy efficiency in future smart homes. EURASIP Journal on Embedded Systems 2011(1), 104617 (2011). https://doi.org/10.1155/2011/104617 28. Schneider, G.F., Pauwels, P., Steiger, S.: Ontology-based Modeling of Control Logic in Building Automation Systems. IEEE Transactions on Industrial Informatics 13(6), 3350–3360 (2017). https://doi.org/10.1109/TII.2017.2743221 29. Schneider, G.F.: Towards Aligning Domain Ontologies with the Building Topology Ontology. In: Proceedings of the 5th Linked Data in Architec- ture and Construction Workshop (LDAC). pp. 1–8. Dijon, France (2017). https://doi.org/10.13140/RG.2.2.21802.52169 30. Shvaiko, P., Euzenat, J.: Ontology matching: state of the art and future challenges. IEEE Transactions on knowledge and data engineering 25(1), 158–176 (2013). https://doi.org/10.1109/TKDE.2011.253 31. Sirin, E., Parsia, B., Grau, B.C., Kalyanpur, A., Katz, Y.: Pellet: A practical OWL- Dl reasoner. Web Semantics: science, services and agents on the World Wide Web 5(2), 51–53 (2007) 32. W3C LBD CG: Building Data on the Web Working Group Charter. https:// w3c-lbd-cg.github.io/lbd/charter/, Last accessed: 20 May 2019 (2017), last accessed: 11 July 2017 49