Representing Construction-Related Geometry in a Semantic Web Context: a Review of Approaches

Representing construction-related geometry in a semantic web context: A review of approaches

Citation for published version (APA): Wagner, A., Bonduel, M., Pauwels, P., & Uwe, R. (2020). Representing construction-related geometry in a semantic web context: A review of approaches. Automation in Construction, 115, [103130]. https://doi.org/10.1016/j.autcon.2020.103130

Document license: TAVERNE

DOI: 10.1016/j.autcon.2020.103130

Document status and date: Published: 01/07/2020

Document Version: Publisher’s PDF, also known as Version of Record (includes final page, issue and volume numbers)

Please check the document version of this publication:

• A submitted manuscript is the version of the article upon submission and before peer-review. There can be important differences between the submitted version and the official published version of record. People interested in the research are advised to contact the author for the final version of the publication, or visit the DOI to the publisher's website. • The final author version and the galley proof are versions of the publication after peer review. • The final published version features the final layout of the paper including the volume, issue and page numbers. Link to publication

General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.

• Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain • You may freely distribute the URL identifying the publication in the public portal.

If the publication is distributed under the terms of Article 25fa of the Dutch Copyright Act, indicated by the “Taverne” license above, please follow below link for the End User Agreement: www.tue.nl/taverne

Take down policy If you believe that this document breaches copyright please contact us at: [email protected] providing details and we will investigate your claim.

Download date: 25. Sep. 2021 Automation in Construction 115 (2020) 103130

Contents lists available at ScienceDirect

Automation in Construction

journal homepage: www.elsevier.com/locate/autcon

Representing construction-related geometry in a semantic web context: A T review of approaches ⁎ Anna Wagnera, , Mathias Bonduelb, Pieter Pauwelsc, Uwe Rüppela a Technische Universität Darmstadt, Department of Civil Engineering, Darmstadt, Germany b KU Leuven, Department of Civil Engineering, Technology Cluster Construction, Ghent, Belgium c Ghent University, Department of Architecture and Urban Planning, Ghent, Belgium

ARTICLE INFO ABSTRACT

Keywords: The exchange of construction-related data over the Web via Semantic Web Technologies is gaining interest in Geometry current research. However, most research focuses on non-geometric data, neglecting the description of geo- Linked Data metry. While several methods to include geometry descriptions into a Semantic Web context exist, no uniform Semantic Web Technologies approach or general recommendation exists for the endeavour of describing building components in their en- Construction industry tirety – including geometric descriptions –, leading to an increased suspension in applying Semantic Web Technologies in the construction domain. To therefore ease the description of geometric data in a Semantic Web context, we conduct an extensive literature review and analyse the identified, oftentimes isolated implementations for geometry descriptions in that context, with focus on requirements set by domain-specific use cases. Based on this analysis, we group the currently available implementations into approaches and compare them to offer means for deciding on which approach or implementation suits individual usecases. The identified approaches vary in their depth of the geometry description's integration into the SemanticWeb and are subsequently studied regarding their overall aptness and characteristics in consideration of their application for future industry and research projects. In respect of the ongoing research in the field of the application of Semantic Web Technologies, not only in the construction domain, this article poses as an important foundation by giving a clear overview of existing implementations and relevant open research questions. Having this overview, the suspense for adapting to Semantic Web methods for describing geometries can be overcome by users more easily, while software developers can start to connect their clients' use cases to suitable approaches and related implementations to represent geometry in a Semantic Web context.

1. Introduction Technologies even allows a more flexible workflow, for example the linking of different data sets – both geometric and non-geometric –, With the gaining popularity of data exchange over the Web, the obviating the need of ‘classical’ data exchange in general [5–7]. construction industry is also exploring how to share building informa- However, in order to support the entire data-based workflow of tion with web technologies. In particular, the application of Semantic Linked Building Data, the exchange and interlinking of geometric and Web Technologies for this industry has been an active field of research geometry-related data needs to be considered as well. Therefore, we for some years now [1]. More recent studies also show how the Building address the question of how geometric and non-geometric data can be Information Modelling (BIM) concept can be applied using Semantic combined in a Semantic Web context. Within this article, no novel Web Technologies for existing buildings [2]. By using Semantic Web implementations are presented, but existing work is analysed and Technologies, the current collaboration methods used in BIM processes grouped into different approaches as recommendations for future ap- – i.e. with exchanging entire files containing building information –can plications. In the remainder of this introduction, we first review the be optimised. Moreover, the exchange of modular building data can take different kinds of geometry schemes and linking methods, which will in- place instead [3,4]. By focusing on the data instead of files, methods form our review of geometry representation approaches in the re- can be created to define a more fine-grained data exchange and thereby mainder of the article. reduce unnecessary data traffic. The application of Semantic Web

⁎ Corresponding author. E-mail address: [email protected] (A. Wagner). https://doi.org/10.1016/j.autcon.2020.103130 Received 28 June 2019; Received in revised form 28 January 2020; Accepted 7 February 2020 Available online 25 March 2020 0926-5805/ © 2020 Elsevier B.V. All rights reserved. A. Wagner, et al. Automation in Construction 115 (2020) 103130

1.1. Geometry representations 1.2. Multiple geometry descriptions

This article focuses on different kinds of geometry – 2D and 3D– To overcome this challenge of continuous miscalculations and that are relevant for the construction industry within a Semantic Web misinterpretations of geometry representations by different geometry context. The observed geometry representations can be divided into kernels, we suggest to link a construction object to multiple geometry five different representation categories, which describe geometry ex- descriptions, each chosen in respect of specific use cases and their ap- plicitly (1–3) or implicitly (4–5) [8], ordered by their complexity in plied geometry kernels to ensure correct interpretations of the de- regard of required geometry kernel functionalities: scriptions. Ideally, this would be combined with an (open-source) geometry kernel to convert the different geometry representations. The 1. Point clouds idea of connecting multiple geometry representations to the same ob- 2. Tessellated (i.e. meshes) ject is not a new one and has been discussed in various contexts before 3. Boundary Representation (BREP) [10–13]. 4. Constructive Solid Geometry (CSG) A basic principle when using multiple geometry representations is 5. (Mathematical) Extrusion and Rotation (Bezier/B-Spline/NURBS) the understanding of geometry as a special property of a construction component and not as underlying information structure that is enriched An object's geometry is usually described using a geometry re- with non-geometrical information like it is often communicated by BIM presentation belonging to one of these categories. The resulting geo- authoring tools. In other words, geometry becomes an attribute of a metry description is then stored as a file following some geometry building component, and not the other way around. As a result, mul- schema, e.g. OBJ, that can be exchanged and subsequently interpreted tiple geometry descriptions can be used to depict different planning or by software applications which rely on a geometry kernel to interpret life cycle stages, levels of detail, as well as geometry representations of the geometry descriptions of various geometry schemes. Geometry one object for specific use cases. Subsequently, storing multiple geo- kernels are software components that provide methods to model, cal- metry descriptions allows a simple and straightforward exchange of culate and visualise geometries based on their descriptions. A wide geometry data while also reducing errors and inaccuracies from dif- array of different kernels under various licences and developed for ferent geometry kernel interpretations. varying fields of application exist. Accordingly, each kernel is basedon In the aspect of providing multiple geometry descriptions, the its own algorithms for interpreting geometry schemes – including linking method to connect the geometry descriptions to their objects is of common standard geometry schemes – and uses its own internal interest for easy querying and extraction of singular geometry de- schema for describing geometry. In some cases, however, it may occur scriptions. While the linking method is distinct by nature in cases where that a method from one geometry representation context is applied to only one geometry description is connected to an object, for multiple another geometry context, e.g. Boundary Representations that apply B- geometry descriptions, different linking methods could be applied at Splines. If such a situation arises, the more complex geometry re- the same time. In order to be able to easily query through multiple presentation context is considered within this article. geometry descriptions of different geometry schemes, the employed In general, most geometry kernels support complex representations, properties for the descriptions connections need to follow a uniform such as those in categories 2, 3 and 4, but using tessellated geometry linking method. descriptions (category 1) provides better performance in hindsight of Furthermore, storing multiple descriptions of the same geometry processing time, since no interpretation of the geometry description is can lead to data discrepancies where one description has been ma- needed. The latter, however, potentially causes higher inaccuracies nipulated while the others are not updated accordingly. To enhance the compared to complex geometry descriptions, as the geometry descrip- process of identifying such data discrepancies, connections between tion is discretised and thereby simplified, while complex geometry different geometry representations need to be introduced. With these descriptions hold a more exact mathematical description of the geo- connections, coherences between derived descriptions could be se- metry. Furthermore, the resulting tessellated geometry excludes the mantically meaningfully defined on instance level. In some cases, itis original geometry description, making it near to impossible to further for example possible to create meshes or even complex geometry re- edit the geometry according to its original description, e.g. a box with presentations from point clouds, while a transformation of the sec- height and width parameters lose those parameters. When considering ondary geometry representation back to point clouds does not produce the performance of geometry kernels, the application of point clouds the same geometry as the initial one due to the simplifications made (category 5) is the least attractive representation with a high compu- within the transformation algorithm. Yet, in other cases, e.g. complex tational effort that is required to visualise each point, though geometry decorative structures such as pillars in the form of statues, it would not in this context often holds the most detailed and truthful geometry be easily achievable to create complex geometry representations with description of existing structures in the built environment. the same geometric detail from the original point cloud. In summary, it Apart from the performance of geometry kernels, the underlying can be said that the topic of translating geometry representations is a algorithms to interpret geometry descriptions hold a significant impact complex one, and it is not possible to create a universally valid hier- on the data workflow of the construction industry. Since most software archy between different representations regarding derivability, geo- applications are based on different geometry kernels, the same geometrical detail, and simplicity. metry description may result in deviating calculated geometries due to the kernels' implementation. This challenge is especially striking for 1.3. Geometry in other contexts semantically richer geometry representations (categories 2, 3 and 4), which need to be interpreted and calculated by the geometry kernel. In Geometry is used in a number of contexts, also beyond the main- contrast, such miscalculations and misinterpretations seldom occur stream use case considered here, the AEC industry. Geometry descrip- when dealing with simplified geometries (categories 1 and 5), since no tions of buildings are closely related to the building topology [14], the interpretation is needed [9]. As these deviations impede the colla- definition of how building-related components are related toeach boration on geometric objects – both for the current workflow, i.e. other, e.g. a heater is contained in a space A, the space A is adjacent to using the Industry Foundation Classes (IFC) [10], and the proposed one space B, etc. The spatial relations between construction components can with (Semantic) Web technologies –, they are a pressing and complex be derived from geometry by using algorithms that check for adjacency, challenge in the construction industry. containment, connectedness and intersections of spatial building

2 A. Wagner, et al. Automation in Construction 115 (2020) 103130 elements. Topologies have different fields of application in the con- construction-relevant use cases in Section 3 and an overall methodology struction industry: they can be used to check the quality of geometry, or for the evaluation (Section 4). In Section 5, we present and evaluate the as information input for analyses and simulations of buildings and approaches with their currently available implementations. To also constructions (e.g. energy simulations, routing, structural analysis). provide recommendations regarding the suitability of singular ap- Another way in which geometry descriptions are used in the con- proaches and implementations for individual use cases, a comparison of struction industry is the geospatial description of entire cities, buildings the approaches is given in Section 6. Finally, this article concludes with and – especially in the infrastructure sector – construction components. a discussion and outlook on future works (Section 7). Many use cases therefore require a relation between detailed 3D geometry and geospatial locations, for instance shading simulations, city 2. Analysing geometry on the web layout, transport simulations and so forth. Geospatial information such as georeferences can be seen as metadata which can be connected to the In this section, we give an overview of already existing work and construction component itself (e.g. as presented in [15]), or as an ex- approaches to describe construction-related geometry on the Web. After tension of existing, non-geometric building ontologies. Hence, geospa- this review (Section 2.1), we summarise current state geometry tial information is not the focus of this article and the approaches dis- schemes of the construction industry (Section 2.2), followed by present cussed here are to be understood independent of the type of coordinate means to include geometry descriptions in a Semantic Web context and system – geographical or Cartesian. Still, we consider the developed apply Semantic Web Technologies on non-RDF geometric content methods and implementations for representing 2D and 3D geometry in (Section 2.3). geospatial contexts using Semantic Web Technologies, e.g. Well-Known Text (WKT) strings, within our research. 2.1. Related work Moreover, geometry descriptions are commonly interlinked with non-geometric properties in the construction industry. Due to the in- The most recent publication related to this article is presented by accuracies of geometry kernels when interpreting geometry descrip- McGlinn et al. [18]. Their article concentrates mainly on Well Known tions, any properties derived from the geometry are currently explicitly Text (WKT) in RDF literals and the application of RDF-based geometry stated within the non-geometric description to ensure data integrity. descriptions. It offers an overview and a qualitative assessment ofWKT Yet, this dealing causes redundant data which is often not synchronised and two existing geometry ontologies, i.e. OntoBREP and GEOM. It also and thereby produces inconsistent data all the same [16]. In the case of includes three practical use cases and a proposal on how to apply a parametric geometry and object descriptions, even more extensive de- geometry ontology with a building reference ontology to demonstrate pendencies between geometric and non-geometric properties of an the applicability of the discussed methods. object are required [17]. Even though parametric dependencies are not Also quite recently, Pauwels et al. [19] discuss how the current a main focus in this publication, the need for parametric dependencies geometry representation within the ifcOWL ontology could be en- between geometry descriptions and non-geometric information is an hanced. Within their publication, different approaches to represent important reason for taking the potential of adding metadata to geo- geometry in RDF graphs are discussed. Since the ifcOWL ontology is metry representations into account during our evaluation. closely connected to the IFC schema, the focus of their work are geometry descriptions that rely on the application of ordered lists, e.g. 1.4. Outline coordinates. These lists are verbose in the RDF data model and seldom used in real world use cases of that framework, i.e. querying of in- Based on the above background of multiple geometry schemes and dividual points and coordinates. To simplify the representation of lists, unified linking methods, this article aims to produce an extensive review various RDF-based approaches, the application of WKT and STEP/IFC of methods for describing geometry in a Semantic Web context and help excerpts using RDF literals are presented. users to decide on which method suits their individual needs for future In [20], Pauwels et al. give an extensive overview of non-RDF-based applications in industry and research. In order to give a structured re- geometry exchange formats and discuss and demonstrate the applica- view of these methods, we group them into approaches that can be tion of Semantic Web Technologies, i.e. RDF and rules, to enhance data implemented in different ways (see Fig. 1) and evaluate them in re- exchange of geometries. However, the proposed workflow for data spective of their applicability for the construction domain. The ap- exchange includes multiple steps, translating the geometric content proaches' implementations are defined in two parts: the applied geo- from non-RDF to RDF and from one web ontology to another, before metry schema and linking method, where the linking method may be serialising according to a standard file format. Yet, the authors conclude applicable for multiple approaches and defines which geometry that it is near to impossible to define complete sets of rules to allow schemes it can link to an object. converting one form of geometry into the other and back. We introduce no new implementations of the approaches, but use While the articles discussed above originate from the construction already existing ones, that we present in an exhaustive review of lit- industry, other industries, i.e. the mechanical engineering industry, erature and best practices in the upcoming Section 2. For a domain- have also been active in this field of research. For example, Qin etal. oriented evaluation of the implementations and approaches, we in- [21] present an overview for the application of ontologies to enhance troduce requirements for geometry descriptions that we extracted from the exchange of CAD data from different authoring tools. With this aim, most of the observed approaches are annotation ontologies to create a common understanding of feature and geometry descriptions. The overall goal of the presented work in their article is the definition of a mutual vocabulary in the form of web ontologies to enable mapping of authoring tools' geometry schemes for easier data exchange. Still, as outlined in [20], a full mapping or set of conversion routines is unlikely to be attained or maintained. Spagnuolo & Falcidieno [22] even give an overview of existing shape libraries and ontologies that serve to annotate external geometry files which is independent of the field of application in general. The authors also claim that ontologies and the Semantic Web will enhance the exchange of and interaction with geometry. Fig. 1. Architecture of approaches. Though these publications discuss the same topic as this article

3 A. Wagner, et al. Automation in Construction 115 (2020) 103130 does, there are several distinctions between the presented work and ours. For instance, we are looking into a wide array of current methodologies independent of the field of application. Therefore, we include modern web-based geometry schemes, namely glTF and GeoJSON, and current developments for geometry ontologies, while ignoring (depre- cated) ontologies that are not available online. Furthermore, we are not only focusing on the representation of lists for geometry definitions. In order to present recommendations for the construction industry, we also examine a broad field of construction-related use cases including a list of related requirements on geometry representations. Moreover, our aim differs from the ones presented in related research. This article is designed to give an exhaustive overview of geo- Listing 1. Example of a 2D line geometry in GeoJSON. metry representations in a Semantic Web context, independent from existing domain ontologies. Additionally, the content of this work is point cloud schema in detail is outside of the scope of this article. designated to ontologies and approaches to describe geometry and not In the ongoing InnoChain8 research project, the development of to purely annotate geometry kept in separate files. Besides, our in- Speckle9 was started. It is an open-source platform for exchanging vestigation is aiming to facilitate the implementation of geometry de- geometry over the Web between different CAD applications (i.e. scriptions that can be stored outside of software applications. McNeel Rhinoceros10 and Grasshopper,11 and Autodesk Dynamo12 and/ Consequently, the exchange of data is improved without needing or a Speckle web viewer. Geometry descriptions are exchanged in so- multiple and error-prone transformations between different tools. called Speckle streams, which are hard-coded for geometrical aspects, since the Speckle platform should be able to communicate with the 2.2. Current state geometry schemes of the construction industry supported geometry engines.

An overview of common CAD geometry schemes is given in [20]. 2.3. Geometry in a semantic web context The authors present a matrix listing the available features for representing 2D and 3D geometry per schema, including DWG [23], X3D 1 Apart from the geometry description itself, we also consider how a [24], OBJ, STEP [25], STL [26], DAE [27], IFC [10] and three common 2 3 4 geometry description can be used in a Semantic Web context – even if geometry kernels: ACIS, Parasolid and Open Cascade. This matrix is the description is not an RDF graph itself. This includes an overview of extended in [18] with changes regarding the COLLADA schema (DAE), available ‘linking methods’ as introduced in the introduction of this additional geographical geometry schemes (WKT [28] and GML [29]) article. We first introduce the option of integrating non-RDF geometry and ontologies for RDF-based geometry descriptions (GEOM [30] and into an RDF graph by utilising dedicated annotation ontologies (Section OntoBREP [31]). What is missing in both papers, however, are modern 2.3.1), before we elaborate on methods for linking geometric content to geometry schemes specifically designed for exchange and usage onthe non-geometric content as proposed by dedicated linking and domain Web, such as glTF [32] and GeoJSON [33], and point cloud schemes. ontologies (Section 2.3.2). For cases where the geometry description is The novel, API neutral and JSON-based geometry schema glTF can not in RDF, we also review possibilities to apply Semantic Web be seen as a sibling of the COLLADA schema. It is more oriented to- querying methods to non-RDF data (Section 2.3.3). wards efficient exchange of geometry on the Web and mainly aimsat the web visualisation aspect. As a result, the geometric part of the specification only takes meshes into consideration unlike other CAD 2.3.1. Annotation of geometry geometry schemes, e.g. COLLADA and STEP. Annotation of geometry can serve multiple goals: adding a structure In the geospatial domain, point, line and polygon geometries are to heterogeneous data, supplementing geometry files with metadata, often exchanged over the Web using the GeoJSON schema. It was using annotations to create means of conversion between different published in 2016 as an Internet Standard and is used in a wide range of schemes and enabling querying based on content of the external geo- web pages and web applications by now. Listing 1 contains an example metry files. snippet of GeoJSON describing a 2D line geometry with a nested list of For the first aim, the COINS project13 [35] defines an OWL ontology coordinates. aimed at the construction industry to annotate and define links between Point cloud geometry is often used in the construction industry in different documents that can be expressed in any data format. Examples the case of existing buildings and infrastructure. Several ASCII and of documents are CAD files, spreadsheets, photos, BIM models and RDF binary schemes exist, both neutral and proprietary, for example E57 files. Besides COINS, more generic file management ontologies exist, [34], PCD,5 LAS,6 etc. Additionally, some mesh schemes, e.g. OBJ and e.g. as implemented by Fedora14 and the Linked Data Platform.15 PLY,7 can also be used to store point cloud data. Besides X, Y and Z When annotating geometry files to attach metadata, dedicated me- coordinates, individual points can – depending on the point cloud tadata ontologies are applied. Such metadata can describe various kinds schema – also contain additional properties, such as intensity, colour, of information, e.g. type of geometry, units, file size, number of trian- grouping per scan and other values, for instance deviations and struc- gles/points, accuracy, authoring tools, feature definitions or (geo-)re- tural analysis results. Point clouds usually consist of millions to billions ferencing. Examples of annotation ontologies for metadata are pre- of points, resulting in large file sizes. Analysing the properties of every sented in [15,36,37]. The Finnish Geo-ontology16 (SUO) [15] contains

1 http://paulbourke.net/dataformats/obj/. 8 http://www.innochain.net/. 2 https://www.spatial.com/products/3d-acis-modeling. 9 https://speckle.works/. 3 https://www.plm.automation.siemens.com/global/en/products/plm- 10 https://www.rhino3d.com. components/parasolid.html. 11 https://www.rhino3d.com/6/new/grasshopper. 4 https://www.opencascade.com/content/open-source-core-technology. 12 https://dynamobim.org/. 5 http://pointclouds.org/documentation/tutorials/pcd_file_format.php. 13 http://coinsweb.nl. 6 https://www.usna.edu/Users/oceano/pguth/md_help/html/las_format. 14 https://duraspace.org/fedora/. htm. 15 https://www.w3.org/TR/ldp-primer/. 7 http://paulbourke.net/dataformats/ply/. 16 https://seco.cs.aalto.fi/ontologies/suo/.

4 A. Wagner, et al. Automation in Construction 115 (2020) 103130 information regarding the geo-location of an area as well as further triplestores can be considered for spatial queries calculating distances information about its names during different periods of time, while the and spatial relations, using extensions of the standardised SPARQL ontology presented in [36] allows users to annotate point cloud and language. For 2D spatial queries, GeoSPARQL [44] and stSPARQL [45] mesh geometry. The Common Shape Ontology (CSO) [37] defines can be used [46], while 3D spatial queries are supported by the Bim- names for shapes contained in geometry descriptions. The latter is the SPARQL extension [16]. The standardised GeoSPARQL extension is result of the European research project AIM@SHAPE17 and presents a implemented in several RDF triplestores compared to the spatio-tem- vocabulary for shapes in general to be used on geometry description poral querying extension stSPARQL that is applied in a limited amount files. This is similar to approaches that are used to annotate images, of triplestores. GeoSPARQL and stSPARQL require 2D WKT or GML videos, audio and are often based on the MPEG-7 standard (XML), descriptions in RDF literals, while BimSPARQL can be used with RDF which is also available in OWL.18 literals containing 3D WKT geometry descriptions only. For using annotation ontologies as basis of conversions between Furthermore, virtual Linked Data graphs over non-RDF databases different (CAD) file formats and geometry kernels, the CAD Ontology (e.g. Relational Database Management Systems (RDBMS)) allow to treat introduced by Tessier & Wang [11] or the Common Design Features external non-RDF geometry as if it was in RDF. This can be realised by Ontology (CDFO) presented by Abdul-Ghafour et al. [38–40] are de- mapping the content to an RDF-based geometry ontology using map- veloped. These ontologies define vocabularies to describe geometric ping languages, such as the RDF Mapping Language (RML, [47]), the features and their properties in order to connect them to the vocabulary RDB to RDF Mapping Language (R2RML, [48]), and so forth [49]. Be- used in different CAD tools. However, those ontologies are not meantto reta & Koubarakis discuss the Ontop23 extension for GeoSPARQL on an be used to describe geometry itself. existing PostGIS/Spatialite RDBMS [50]. The authors conclude that Lastly, annotation ontologies can be used to condense the content of both file size and query efficiency using their approach arebetter the geometric descriptions stored in an external file to allow querying compared to a Strabon24 RDF triplestore. Additionally, they argue that the content to a certain degree. This is implemented by the X3D-based their approach is better suited in cases where the geometry undergoes 3D Modelling Ontology (3DMO) [41] and demonstrated in different use frequent changes in the existing RDBMS, since the geometry does not cases to query geometries with a wanted geometrical detail, measured have to be entered in a spatial triplestore. by the quantity of meshes within the description. 3. Requirements for digital geometry in the construction industry 2.3.2. Geometry and domain ontologies Besides linking methods related to specific geometry schemes, there Within this section, we present an overview of common geometry are also methods that can be used to link construction objects, defined use cases in the construction industry. The observed use cases were according to domain ontologies, to geometry descriptions of any geo- analysed regarding their requirements on the geometry description of metry schema. We introduce the two most relevant of those linking their input files as well as common file formats and software applica- methods here. tions used to address them. We conducted this analysis based on The Building Topology Ontology19 (BOT) [14] is developed within common knowledge, expert interviews and literature reviews. The the W3C Linked Building Data Community Group. The current version latter includes several books, internet sources, and articles [51–56]. of BOT (v0.3.0) provides terminology to connect both RDF geometry We understand this overview not to be an exhaustive representation descriptions and non-RDF geometry descriptions to nodes representing of all building-related use cases. Instead, we are focusing on groups of construction objects. Both properties are generic in that they do not use cases on a more generic level in order to find commonalities within define the geometry schema which the connected geometry descrip- their requirements for digital geometry descriptions. Thus, we first tions are following. defined five groups of use cases: More generally valid, the Ontology for Managing Geometry20 V Visualisation (OMG) [42] is dedicated to establish linking methods between geo- SQ Spatial Querying metric and non-geometric descriptions in disregard of the considered F Fabrication domain. It also provides two generic properties to relate RDF and non- CA Computational Analysis RDF geometry descriptions to an RDF node that represents a non-geo- M Modelling metric description of an object. However, the OMG can be extended by Each of these groups contains a broad range of use cases. To gain an the Ontology for Geometry File formats21 (FOG) [43], that introduces impression of the geometric requirements, we consider various use subproperties of the generic OMG properties which are specified for cases per group with the goal to categorise those in sub-groups with the geometry schemes and also their individual version and extension. By most commonalities. The results of this process are described further in using these specified properties, users can request the geometry de- detail, including a general discussion of the use case groups and sub- scriptions following relevant schemes for their use case or identify the groups and detailed reviews of singular example use cases and their geometry scheme at hand without having to analyse the content in requirements for geometry descriptions. This survey is not meant to respect of the used schema. give an exhaustive review of all building-related use cases but to serve as an attempt to create a more generic evaluation of geometry requirements. Hence its results will not be applicable for every use case 2.3.3. Querying non-RDF geometry within each (sub-)group and we expect users to find their specific use In some cases, non-RDF geometry descriptions reside in RDF literals case to be an exception to the presented generalisation or in between of or in non-RDF databases. The geometric content of both can be queried several defined use case groups or sub-groups. as regular RDF statements using extensions of the standardised RDF query language named SPARQL.22 Geometry descriptions that are stored as RDF literals in RDF 3.1. Evaluation criteria

To collect requirements on the geometric description for the use 17 http://visionair.ge.imati.cnr.it/. cases, nine criteria were defined. These criteria are evaluated for each 18 http://rhizomik.net/ontologies/2017/05/Mpeg7-2001.owl. observed singular use case and subsequently generalised for the use 19 https://w3id.org/bot#. 20 https://w3id.org/omg#. 21 https://w3id.org/fog#. 23 https://ontop.inf.unibz.it/. 22 https://www.w3.org/TR/sparql11-query/. 24 http://www.strabon.di.uoa.gr/.

5 A. Wagner, et al. Automation in Construction 115 (2020) 103130 case's respective group or sub-group. For better readability, the criteria Table 1 are abbreviated as follows within the tables containing the evaluation's Evaluation of the Visualisation use case group. results: Visualisation (V) C1 Dimensions C2 Geometry Representation For experts For non-experts C3 Units C1 2D 3D C4 Georeferences C2 Any (pref. tessellated) Any (pref. tessellated) C5 Animation C3 Yes (units) No C6 Appearance C4 At least orientation No C7 Geometric Properties C5 No Yes C6 No Yes C8 Topology C7 Yes No C9 Response Time C8 Yes No C1. The first criterion describes the required spatial dimensions of C9 Short - middle Short the expected input geometry, namely 2D or 3D. Since it is by default possible to describe 2D geometry with 3D functionalities by levelling all objects, this criterion is answered by defining the highest dimension 3.2. Visualisation that can be described by the geometry schema. Optional values are therefore (2D) and (3D). The first use case group is related to visualisation, which isagain C2. Criterion 2 for geometry representations can be addressed by divided into the two sub-groups ‘for experts’ and ‘for non-experts’. listing which geometry representations can be described with it (e.g. Experts are hereby considered to have knowledge and experience at tessellated geometry, CSG, BREP and mathematical, see representation what they are viewing and therefore prefer simple and schematic vi- categories in Section 1.1). Since a comparison or listing of singular sualisations containing large amounts of information, whereas non-ex- features that are supported by the implementations seems unrewarding perts are considered to be inexperienced and easily overwhelmed by due to inconsistent naming conventions, only the upper-level re- abstract visualisation and information overflow. Accordingly, the representations contexts are considered. quirements on the geometry description differ from mostly two-di- C3. The third criterion focuses on units and can include a chosen mensional representations with a high amount of information, on the value range: (adj.) – adjustable units, that allow individual geometry one hand, and more accessible three-dimensional representations with descriptions to use different units (e.g. metrical or imperial system), a low amount of information, on the other hand, as can be seen in (fixed) – a fixed unit that is valid for any geometry description anddoes Table 1. Example use cases for these sub-groups (‘for experts’ and ‘for not allow variation, or (scaled) – geometry descriptions do not contain non-experts’) are: viewing during the building life-cycle, visual analysis any defined units and therefore require to be scaled during themod- of design and existing constructions, and visualising properties of elling process. building components for the ‘for experts’ sub-group and visualisation C4. Since we are observing the description of geometry on a general for clients, and VR/AR applications for the ‘for non-experts’ sub-group. level for the construction industry, the fourth criterion evaluates whe- Within the overall use case group (‘visualisation’), we identify use ther the geometry description must contain georeferences, i.e. geo-co- cases which originate from the one sub-group but hold some require- ordinates and orientation. ments of the other. Namely, the visual analysis of architects and in C5. Furthermore, criterion 5 defines observing the necessity of the existing constructions is mostly based on 3D geometry including the definition of a geometry's dynamic behaviour like animations. correct textural representation (appearance), while the visualisation for C6. Related to the previous criterion, criterion 6 is considering the navigation is often meant for non-experts and contains little additional appearance of geometries, including the possibilities to define colours, information and requires abstract 2D geometry descriptions. textures and texture-mapping. Additionally, the application of VR/AR as a use case holds further re- C7. Criterion 7 is concerned with the presence of geometric prop- quirements: The geometry should be represented close to the object's erties, but not their derivation or computation. This includes a differ- real appearance while not containing all details, since this could cause entiation between implicit and explicit properties. Implicit properties performance issues. This use case also requires the geometry loading are not a part of the geometry description itself but are computed from time to be almost instant for cases where re-buffering is applied. it, e.g. volumes and surface areas. On the other hand, explicit properties are defined as properties of the geometry description itself, e.g. height 3.3. Spatial querying of an extrusion. Criterion 7 comprises the three options of (no) – not supporting any geometric properties, (expl.) – supporting only explicit The second use case group on spatial querying is not further sub- geometric properties, or (impl.) – supporting implicit (and therefore also divided. This group addresses any use case that involves querying explicit) geometric properties. geometry with the goal of identifying singular geometries based on C8. Likewise, criterion 8 regarding topological relations spans over given spatial conditions or creating new (topological) dependencies. three options. Within an implementation, topological relations could For these use cases, we identify the requirements listed in Table 2. The not be supported at all (no), on the upper level only, e.g. building observed specific use cases are clash detection, compliance checking elements that are intersecting, touching, etc. (element), or on any geo- and deriving topology from geometry. metric item (detailed). Detailed topological relations are more detailed We only see one exception for this use case group: The required compared to element-based topology. While the element-based to- geometric detail may be depending on the planning phase, ranging pology only gives insights about the elements that are touching, de- from simplified representations, such as bounding boxes, to the highly tailed topology can further define this relation, e.g. face A of element 1 detailed true representation of a specific component. Since the latter is is touching face D of element 2. more common, this detail is chosen to be representative for this eva- C9. Finally, the ninth criterion takes the expected response time for luation. the generation of the object's geometry description into account. This Considering the required geometry representation context, current will be estimated rather generically in different steps from (im- non-proprietary implementations, such as GeoSPARQL or BimSPARQL, mediately)/(short) to (long). require tessellated geometry descriptions. Yet, as more complex or

6 A. Wagner, et al. Automation in Construction 115 (2020) 103130

Table 2 Table 4 Evaluation of the Spatial Querying use case group. Evaluation of the Computational Analysis use case group.

Spatial Querying (SQ) Computational Analysis (CA)

C1 3D On implicit geometry On explicit geometry C2 Any (pref. tessellated) C3 Yes (units) C1 3D 3D C4 No C2 Any Any (pref. tessellated) C5 No C3 Yes (units) Yes (units or scaling) C6 No C4 Rough location Rough location C7 No C5 No No C8 No C6 No No C9 Middle - long C7 Yes No C8 Yes No C9 Middle - long Middle - long Table 3 Evaluation of the Fabrication use case group. offer a variety of specific use cases, some examples of which are:(1) Fabrication (F) energy and thermal comfort simulations, HVAC dimensioning, and C1 3D simplified analyses for the first sub-group, and (2) FEM-based structural C2 Any (pref. tessellated) analysis, CFD-based simulations (Computational Fluid Dynamics) and C3 Yes (scaling) complex analyses for the second sub-group. The results of this ob- C4 No servation can be found in Table 4. C5 No Since this group contains a broad field of quite diverse use cases, C6 No C7 No Table 4 contains several generalisations that must be adapted in- C8 No dividually for each singular use case. For example, some of the use cases C9 Long only need geometry in 2D lines (i.e. structural analysis on portal frames, analysis on moist transport, calculation of waypoints and simulation of thermal bridges). On the other hand, for some use cases, namely the implicit geometry description contexts include more information, fu- FEM-based structural analysis and fire/smoke simulations, geometry ture implementations may be based on such geometry representation representations as 3D solids instead of tessellated geometry can be used. contexts. Still, analyses conducted on explicit geometry oftentimes rely on surfaces only, neglecting the geometry's composition or geometry de- 3.4. Fabrication scriptions of hidden objects. Thus, the application of tessellated, and mostly watertight, geometry descriptions is preferred in such cases. The fabrication use case group is again not further partitioned and is Also, the requirement for georeferences may differ for singular use meant to cover any use case that creates physical components from cases. For instance, lighting simulation requires the orientation and – if their digital description. The summarised requirements in Table 3 are the surroundings are also considered – exact location, while no location based on the use cases of 3D printing of components and entire build- is needed for use cases that focus on the building interior (e.g. interior ings, prefabrication of simple and complex structures, as well as CNC acoustics and fluids simulations, indoor navigation, and so forth). productions. Regarding the expected geometric detail, the use case of calculating Detailed mathematical descriptions may be ideal for the geometric waypoints does not need a high detail but can be addressed using representation in the case of prefabrication and CNC production, as simplified geometries, such as bounding boxes. these use cases can interpret and even use such representations for their production steps. Also, prefabrication may require topological relations between components in case they are part of the same complex system 3.6. Modelling that is being automatically fabricated. Finally, 3D printing holds some additional requirements to the geometric detail and the description it- Geometry modelling is the most complex use case group of the self: the geometry has to be described watertight [57] for the pre-pro- construction industry, as it can involve multiple users, version history cessing of the description and a minimal thickness must be fulfilled, of geometry, complex modelling operations, etc. The created geometry since small details cannot be printed. Modern 3D printing may also needs to be serialised, ideally in a software independent way, to ease need the definition of the geometry's appearance, as textures andcol- the data exchange between different software applications, e.g. for ours can also be printed. other use cases. Within this survey, requirements of this group are re- Regarding the geometry representation context, tessellated geo- lated to the final geometry description resulting from a modelling metry descriptions are preferred, as the accuracy and resolution of the process. The group is broken down into two sub-groups: (1) non-para- manufacturing systems, i.e. 3D printers, is limited [58]. Hence, the metric modelling, such as the modelling of existing buildings, proces- inaccuracies of tessellated geometries can be overlooked, and the sing of surveys from point clouds, and modelling of simple new build- benefits of an unambiguous geometry description and straightforward ings, and (2) parametric modelling for complex, new constructions or interpretation become more obvious. products (see Table 5). Within this group, we identify the exception of point cloud pro- 3.5. Computational analysis cessing requiring point clouds as geometry representation instead of detailed mathematical ones and a slightly longer acceptable response Use cases related to computational simulations and analyses on time. Furthermore, non-parametric modelling in general can be geometry are clustered in the computational analysis use case group. As achieved using any other kind of geometry representation as long as a this is a wide field of use cases, this group is split into two sub-groups: modelling tool supports editing these representations, while parametric Analyses based on the implicit geometry description, namely topology modelling can also be realised using BREP/CSG geometry representa- and derived geometric attributes, such as volumes or areas, and those tions. In the case of modelling dynamic buildings, animations must also based on the explicit geometry, the description itself. Both sub-groups be supported by the geometry description.

7 A. Wagner, et al. Automation in Construction 115 (2020) 103130

Table 5 supported import and export schemes of the six most commonly used Evaluation of the Modelling use case group. BIM/GIS software applications according to [59,60]. Modelling (M) The geometry representation type (2) is identical to Criterion C2, geometry representation (e.g. tessellated geometry, CSG, etc.), and is Non-parametric Parametric evaluated accordingly. Tessellated geometry is typically faster to load compared to representations that first have to be calculated, i.e. BREP, C1 3D 3D C2 BREP/CSG Detailed mathematical CSG and mathematical. C3 Yes Yes Although file sizes (3) are of considerably less importance andim- C4 Yes Yes (building) and no (product) pact in a (semantic) web world, we evaluate this feature as well. C5 No No Evaluation of file sizes is done using a collection of reference geometry C6 Yes (architect) and no (engineer) Yes (architect) and no (engineer) descriptions. This sample collection consists of 13 IFC 2 × 3 files that C7 Yes Yes 25 26 C8 No Yes are available online [61–63]. A script is used to remove non-geo- C9 Short Short metric content from the sample files, while still maintaining valid IFC 2 × 3 files. Furthermore, file size was reduced using the Solibri IFC Optimizer.27 With the pre-processed IFC files, a unified conversion 4. Methods for comparison of approaches process can yield geometry descriptions of different file formats with a minimum variation (see Fig. 3). To ensure comparable results, the In order to evaluate our findings – namely the approaches to de- conversion uses as little converters and geometry kernels as possible, scribe geometry in a Semantic Web context –, they must be evaluated with one converter, namely the CAD Exchanger28 software, producing systematically and in consideration of construction-relevant require- most of the desired geometry formats, including IFC, STEP, IGES, X3D, ments. In this evaluation, which will take place in Sections 5 and 6, we OBJ, STL, and 3DM (native Rhino format). Resulting converted files are separate between the general approach and the implementation level available online.29 (see Fig. 2). Since both levels differ in their purpose, different methods Missing geometry schemes are converted using Rhino, i.e. DWG and for their evaluation are presented in the upcoming sections. In short, we COLLADA – and thus glTF30 –, and individual converters dedicated consider the results from evaluating geometry schemes as the most specifically for less widespread RDF-based geometry schemes, i.e. precise assessment of an implementation, and the richness of possibi- GEOM,31 ifcOWL,32 OntoSTEP33 and OntoBREP.34 The RDF-based lities to extend a geometry schema as the most precise assessment of the geometry is serialised in or converted to the Turtle35 (TTL) syntax. general approach. As the resulting file sizes are dependent on the optimisation and internal settings of the conversion tool, the results of the presented 4.1. Evaluation of the implementations workflow are not to be understood as an exact benchmarking analysis. Rather, this process yields means to make estimates on file sizes. For the implementations' evaluation to be construction-relevant, the previously defined criteria of Section 3.1 are used. As the linking 4.2. Evaluation of the approaches methods have no influence on the content that can be described with each individual geometry schema, the evaluation is conducted on For the overall comparison of approaches, we define seven aspects geometry schemes only. that can be grouped in respective of their common aim: easy application Beginning with an analysis of the geometry schemes' specifications, and exploitation of Semantic Web benefits. Each aspect is defined in most of the criteria can already be addressed. Namely, criteria 1 to 8 more detail below. can be answered just by studying the conceptual capabilities of the Flexibility. This aspect measures how many implementations of considered schemes. Criterion 9 (acceptable response time) cannot ex- this approach exist and, thereby, how flexible users are in choosing plicitly be evaluated based on the schema specifications only. Due to its their most suitable geometry schema or linking method. indistinct value range (immediately - long), a meaningful comparison of Conciseness. The conciseness reflects on the verbosity of an ap- the implementations in terms of this criterion is difficult. Response time proach in average, either the triple count for RDF geometry descriptions is affected by (1) the support of the individual geometry schema, (2)the or file size for non-RDF geometry descriptions. geometry representation type and (3) the file size of the respective Simplicity. For this aspect, the approaches' geometry descriptions geometry description. are evaluated from a technical Semantic Web perspective. The simpli- To measure the level of support for a geometry schema (1), it is city of an approach considers technical issues that must be overcome for assessed in multiple aspects and then categorised into one of seven this approach to obtain valid RDF graphs. categories, visualised by a plus/minus scale. The considered questions Support. Most important aspect from the point of view of applying are: Is the schema convertible and visualisable? Can the schema be an approach without requiring much effort is the already existing queried? Is the schema an open standard? And is it supported by main support. This aspect gives insights on how well an approach is already BIM/GIS applications? The latter comprises an examination of supported by (established) software applications in the construction industry.

25 Complete overview available at: https://osf.io/yrz9m/?show=revision. 26 https://gitlab.iib.tu-darmstadt.de/Wagner/removepropertiesfromifc. 27 https://www.solibri.com/solibri-ifc-optimizer. 28 https://cadexchanger.com/. 29 https://osf.io/qhg9j/?show=revision. 30 By loading the COLLADA file with three.js v97 and exporting it as glTF using three.js GLTFLoader v102. 31 IFC2BIN2TTL2JS converter from 23.11.2018. 32 IFCtoRDF v0.3 https://github.com/pipauwel/IFCtoRDF. 33 Fig. 2. Architecture of approaches in respective of the evaluation. https://sourceforge.net/projects/osexpress/files/ontostep/. 34 Not publicly available. 35 https://www.w3.org/TR/turtle/.

8 A. Wagner, et al. Automation in Construction 115 (2020) 103130

Fig. 5. Methodology of approach 1.

Fig. 3. Overview of the pre-processing workflow. serialisation of RDF [64]). In contrast, approach 3 is relying on other technologies for the content structure, while using a Semantic Web Portability. From the perspective of the Semantic Web, the port- approach for linking and storing the geometry descriptions. The ap- ability of information indicates how convenient it is to share geometry proach which has the least accordance to the Semantic Web is approach descriptions with other RDF data. 4. It only uses RDF for linking to the geometry descriptions and depends Extensibility. Moreover, we evaluate the aspect of an approach's on other technologies for storage and structure of the content. extensibility by examining how easy it is to extend its implementations using dedicated ontologies to add features to the geometry descriptions. 5.1. First approach – RDF-based geometry descriptions This is mainly influenced by the ability to link to singular parts orva- lues of an approach's geometry description. The first approach is comprised of geometry descriptions that are Semantic Expressiveness. Finally, the semantic expressiveness is fully integrated into RDF. The descriptions are RDF-based and can be considered. This includes Semantic Web Technologies as (spatial) linked to the object's non-geometric description via object properties. In querying, automated reasoning and the application of rules. detail, Fig. 5 shows the geometry description being represented in multiple triples in its own graph and linked to an object. This approach 5. Approaches for representing building geometry in a semantic can be used with any valid RDF serialisation. web context In order to qualify as implementation of this approach, the geometry schemes must be defined in RDF. Since geometry descriptions heavily Within this section, we introduce four identified approaches to de- rely on ordered lists (e.g. polylines), describing geometries in RDF is scribe geometries in a Semantic Web context in more detail. The section deemed to be inefficient [19] and only few geometry schemes exist. The consists of one subsection per approach and covers the approaches' schemes shown in this publication are 3DMO [41], which is initially general characteristics and implementations, including an analysis of designed for annotation, OntoBREP [31], OntoSTEP [65], GEOM the implementations as defined in Section 4.1. [30,66], and ifcOWL [19,67]. Fig. 4 gives an overview of the approaches and describes which The second part of the approach's implementation – linking to the technologies an approach is based on. The overview differentiates be- geometry description – can be realised by a wide array of ontologies, tween three parts of the geometry description: The first part focuses on whereas only those implementations with relation to the construction how the geometry description is referred to – the linking method on industry will be listed in the following. As described in Section 2.3.2, implementation level. Meanwhile, the second part defines how the both BOT and OMG/FOG provide terminology to link a construction geometry description is stored, i.e. within an RDF graph using Semantic component to any RDF-based geometry description. By using FOG, Web Technologies or using other technologies. Third, the content part scheme-specific connections can be defined. Also, the ifcOWL ontology considers whether the content is structured according to the Semantic implements a connection between geometric and non-geometric data, Web specifications or whether it relies on other technologies. yet limits scope to IFC only. Approach 1 uses the Semantic Web for all three parts and is there- The available implementations and possibilities to combine them fore implemented with the closest alignment to the Semantic Web of all are shown in Fig. 6. The overview also gives insight on the applicability approaches. Similar, approach 2 can be implemented using only of linking methods to multiple approaches. If a linking method is lim- Semantic Web standards. However, the second and third part of it are ited to one approach, it is connected to the approach via a double line, more restricted, as the storage and structure of the geometry descrip- whereas linking methods that can be used in multiple approaches are tion are compliant to both RDF and JSON (i.e. using the JSON-LD connected by a single line. Furthermore, we differentiate between linking methods that establish generic connections between objects and their geometry description (grey lines) and those that specifically define which geometry schema is used (black lines). All these implementations respectively geometry schemes use the

Fig. 4. Overview of identified approaches. Fig. 6. Implementations of approach 1.

9 A. Wagner, et al. Automation in Construction 115 (2020) 103130

RDF data model. Thus, each geometric property, geometric operation, 5.1.4. GEOM point, coordinate, etc. is defined as property of some node or as anode The GEOM39 ontology is designed as part of the Concept Modelling itself. Since nodes are identified by URIs in RDF, this feature enables to Ontology with extensions (CMO with extensions) ontologies to describe directly link to almost any point of the geometry description to add complex construction related data – including geometry [30,66]. For metadata or supplementary details. Hence, all criteria addressing ad- reasons of modularity, the CMO with extensions are split into different ditional and not necessarily geometric traits (e.g. appearance or ani- domains: parametrics, processes and geometry. The GEOM part is mation) can be fulfilled by using dedicated ontologies not presented in modelled in close accordance to the geometric part of the IFC schema. this article to enrich the original description with such aspects. However, it consists of noticeably less concepts. The authors of GEOM provide supporting software for modelling, 5.1.1. 3DMO converting IFC files to GEOM, and viewing geometry descriptions in 40 The 3D Modelling Ontology36 (3DMO) is a translation of the X3D GEOM both in a web and desktop viewer. The tools rely on the closed, schema into RDF and is originally dedicated to annotate external files proprietary geometry kernel of the ontology's creators. containing X3D-based geometry descriptions [41]. However, since the When converting GEOM geometry descriptions directly from the ontology provides all concepts of the X3D schema, the 3DMO can also sample IFC files, no immediate errors occurred. Nonetheless, the geo- 41 be utilised for storing the geometry description itself. Yet, that is not the metries could not be visualised by the GEOM web viewer but only the 42 original intention of the ontology; hence, no tools are available to either desktop application. convert, model, or view geometry descriptions following its schema. Technically, GEOM introduces concepts to describe CSG, BREP, Thus, the 3DMO will not be considered in the comparison of file sizes, tessellated, and mathematical geometry representations. But practi- as no reasonable means to create 3DMO geometry descriptions of the cally, the concepts for BREP, tessellated, and mathematical geometry sample data are known to the authors. representations cannot be applied since GEOM does not implement Due to the lack of example data containing full geometry descrip- ordered lists for vertices, indices, points, etc. Instead, the schema relies tions following the 3DMO schema and specification of the schema itself, upon the order of multiple entries of the same property in the file not to the evaluation of the criteria is conducted on the specification of the change over time. Thereby, concepts that use lists will not be rendered X3D schema, assuming that the 3DMO is sufficiently equivalent to the correctly, once the data has been stored in a triple store or extracted by X3D schema. queries. Fig. 7 demonstrates the effect of the missing support for ordered lists. In this example, a BREP of a cube is shown and translated. By changing the order of one vertex, the visualised geometry alters 5.1.2. OntoBREP 37 significantly (see Listing 2). OntoBREP is an ontology dedicated to describe geometries in a If ordered lists would be introduced in GEOM, the resulting Turtle Boundary Representation context and originates from the field of ro- file could be structured as demonstrated in Listing 3. Still, more options botics and manufacturing [31,68]. The sample data used for comparing to include ordered lists in RDF exist [19]. The lack of ordered lists ac- file sizes is translated using a non-public conversion tool. Still, the cording to RDF also causes the average triple count ratio in comparison conversion tool caused performance issues and could only be executed to the ifcOWL to be distorted. Common RDF analysis tools would, for on three of thirteen sample models. Therefore, the average triple count example, return a lower triple count than Table 6 shows, since they ratio in comparison to the ifcOWL should be seen as an indicative count duplicate triples (i.e. Listing 2, line 6 and 10) only once. To show measure only. Public tools for visualising or modelling geometry using a representative triple count according to the intention of the GEOM the ontology are not known at the time of writing, though publications 38 schema, we include duplicate triples into the triple count. If we further indicate the existence of a Protégé plugin to visualise OntoBREP assume the implementation of ordered lists as shown in Listing 3, the components. average triple count would be 211% instead of 125% in comparison to The schema provides concepts to describe geometries in a BREP, the sample models in ifcOWL according to our estimation. allowing users to freely model desired shapes. By defining geometric constraints and topological relations, animations can also be described with OntoBREP. The schema does not support the geometry's appear- 5.1.5. ifcOWL ance, used dimensional units, or georeferences. The ifcOWL43 ontology is an RDF-compliant serialisation of the IFC schema itself. Accordingly, the ifcOWL translates every feature and 5.1.3. OntoSTEP definition of IFC and thereby fulfils the same criteria as IFC does.In Another option to describe geometry in RDF is the OntoSTEP on- respect of the accessibility of geometric properties and topological re- tology [65]. This ontology is a translation of the STEP format into RDF lations from within the RDF, the ifcOWL surpasses the original IFC and can be created automatically using any STEP Application Protocol schema, since these features are defined in RDF for the ifcOWL. (AP) file [69]. The same conversion tool for creating the schema itself Similar as in IFC, the geometry description is closely related to the can be used to translate STEP data into RDF-based data on the applied AP non-geometric part of the described (building) objects. While it is ontology. However, the published tool is still in its beta phase and could common for non-RDF schemes to be designed as monolithic and ex- not convert our sample models. Therefore, the sample data could not be tensive data models, when using RDF and linked data best practices,44 converted into OntoSTEP. Besides the conversion tool, no applications the goal should be to create concise ontologies that are combined with for viewing or modelling data in this schema are known to the authors. other ontologies for a modular and complete description. The ifcOWL For the analysis of this schema, the STEP AP 214 [25] for core data does not reach this goal, causing an overhead of defined but unused for automotive mechanical design processes is investigated, since this concepts for singular projects. AP is closely related to the other geometry schemes. As OntoSTEP is a For the ifcOWL schema, an open-source conversion tool is available, translation of the STEP APs from EXPRESS to RDF, results from the investigation of the STEP AP 214 specifications are re-used for the 39 ontology. http://rdf.bg/geometry.ttl. 40 While these tools are not publicly available on a website, they can be re- quested from the creators of GEOM. 36 http://web.archive.org/web/20180831114523/http://3dontology.org/ 41 Included in the IFC to GEOM conversion tool. 3d.ttl. 42 CMOViewer20181123 by RDF.bg. 37 https://github.com/OntoBREP/ontobrep/blob/master/owl/ontobrep.owl. 43 https://standards.buildingsmart.org/IFC/DEV/IFC4_1/OWL. 38 https://protege.stanford.edu/. 44 https://www.w3.org/TR/ld-bp/.

10 A. Wagner, et al. Automation in Construction 115 (2020) 103130

(a) Original geometry (b) Geometry after re- arranging vertices

Fig. 7. Demonstration of missing support for ordered lists in GEOM.

Fig. 8. Methodology of approach 2.

themselves. The only restriction on the variety of possible extensions is given by the geometry schemes and their supported geometry representation contexts: e.g. enhancing tessellated geometry by dimensional parameters may prove to be difficult in general. On the other hand, most of the implementations are poorly supported by (open- source) software applications.

5.2. Second approach – JSON-LD for web geometry

Listing 2. Changes made to the order of vertices in the GEOM TTL file. The second approach is somewhat similar to the first one. However, this approach imposes more restrictions on users: Instead of allowing any RDF serialisation, the second approach relies on the JSON-LD 1.0 [64] RDF serialisation for the geometry descriptions. As a result, one is likely to end up with two graphs – one for non- geometric data in any desired RDF serialisation and one for the geometry description in JSON-LD (see Fig. 8). On the other hand, the JSON-LD serialisation allows users to apply JSON-based geometry schemes in a Semantic Web context with little effort. Ergo, the benefits of the Semantic Web as well as the support of the JSON-based geometry schemes in software applications can be exploited. For this approach, only one implemented geometry schema currently exists, i.e. GeoJSON-LD.45 Still, other JSON-based geometry formats, e.g. glTF and Speckle JSON, which are used for web geometries, could be easily transformed to JSON-LD (listed in grey font, Fig. 9) Listing 3. Suggested implementation of GEOM with ordered lists in RDF. by inserting an appropriate JSON-LD context to resolve JSON keys and

Table 6 Evaluation of geometry schemes for approach 1.

C1 C2 C3 C4 C5 C6 C7 C8 Tools Triple count ratio [%]

3DMO 3D Tessell. Yes (adj.) Yes Yes Yes Yes (impl.) Noa –– BREP Math. OntoBREP 3D BREP Noa Noa Yes Noa Yes (impl.) Yes (detail) – 1368.99b Math. OntoSTEP 3D All yes (adj.) Noa Noa Yes Yes (expl.) Noa –– GEOM 3D CSGc Noa Noa Noa Yes Yes (expl.) Noa – 125.20d ifcOWL (v4 Add2) 3D All Yes (adj.) Yesa (building level) Noa Yes Yes (expl.) Noa – 100.00e

a By applying specialised ontologies, these criteria can be fulfilled to any desired detail, assumed the relevant geometric items aredefined. b Only 4 of 13 models could be converted. c Technically, BREP/mathematical/tessellated geometry are also supported, but require ordered lists, which are not implemented. d Intended triple count; due to lack of RDF compliant ordered list, the triple count is smaller than to be expected (e.g. 211.08% with proposed implementation). e The triple count ratio analysis is conducted on IFC 2 × 3 sample models in BREP converted to ifcOWL-based RDF. but support of other applications, such as visualisers and BIM applica- values to RDF resources. tions, is lacking. Since the geometry schemes comply with RDF, they can be linked to construction objects described in an RDF graph via object properties. The linking method for such a geometry description is implemented in 5.1.6. Findings GeoJSON-LD itself, OMG/FOG, and BOT. The first of these linking The results of analysing RDF-based geometry schemes based on methods (GeoJSON-LD) is designed to be used for GeoJSON-LD and their specifications are condensed in Table 6. Because of the schemes' RDF nature, the implementations of approach 1 can be easily extended by other ontologies to add details that are not provided by the schemes 45 http://geojson.org/geojson-ld/.

11 A. Wagner, et al. Automation in Construction 115 (2020) 103130

Fig. 11. Implementations of approach 3. Fig. 9. Implementations of approach 2.

method and the used geometry schema. A survey of available im- thereby in this approach only, while the second (OMG/FOG) and last plementations is shown in Fig. 11. linking method (BOT) can be used to connect to any type of geometry The applicable geometry schemes for this approach's implementa- description of this approach. An overview of all available im- tion are any non-RDF geometry schemes, for example COLLADA, IFC, plementations and their combinations is given in Fig. 9. STEP, point cloud formats, etc. Apart from common exchange schemes In disregard of the details of the existing geometry schemes for our and formats in the construction industry, more advanced implementa- second approach, a considerable technical issue must be mentioned. tions already exist for the Geography Markup Language (GML [29]) and Currently, JSON-LD v1.0 provides no means to resolve lists of lists (e.g. the Simple Feature Access (SFA [28]), with its implementations of Well as demonstrated for GeoJSON in Listing 1) to proper RDF. Un- Known Text (WKT) and Well Known Binary (WKB). fortunately, GeoJSON and other JSON-based geometry schemes require Since the idea to store geometry in simpler forms than RDF graphs lists of lists to describe an array of coordinates which are defined by an in a Semantic Web context is well discussed [18,19], several im- ordered list of two or more values (e.g. longitude, latitude and altitude). plementations for linking to geometry descriptions that are embedded The Speckle JSON and glTF schemes support tessellated geometries, in RDF literals exist. Some of the implementations are based on the which contain lists of points – ergo, lists of coordinates. translation of a broad schema into RDF and thereby rely on the original As a result, approach 2 can presently not be used for describing schema's geometry description, i.e. an OWL version of CityGML expects building geometries. The only implementation – GeoJSON-LD – is geometry descriptions to be stored in RDF literals following the GML therefore restricted to single points and thus qualifies rather as an im- schema [13]. Meanwhile, others aim to extend SPARQL to enable plementation for annotating objects with their georeference than de- spatial querying. Such implementations need to provide unified voca- scribing their geometries. bularies to define geometries and require the geometry description to always follow one – or in some cases a few – previously defined schema, 5.3. Third approach – Non-RDF geometry as RDF literals e.g. GML and SFA. These SPARQL extensions are stSPARQL [45], GeoSPARQL [44], and BimSPARQL [16] (see Section 2.3.3). In the third approach, a combination of Semantic Web Technologies Next to linking methods that are unique for this approach, the BOT and non-RDF-based geometry schemes is used. The object and its non- and OMG/FOG ontologies also provide terminology to link to geometry geometric description are represented in an RDF graph that also con- descriptions embedded in RDF literals. As for the previous approaches, tains the geometry description which is defined according to a non- BOT introduces generic terms and concepts for linking on the one hand, RDF-based geometry schema (see Fig. 10). This approach has the ad- and the OMG/FOG ontologies allow to add specialised links for each vantage that the entire data is stored within the same graph, while it is schema on the other hand. possible to use more concise and specialised schemes for describing Next, some common geometry schemes and the previously men- complex and mainly list-based geometry descriptions. Yet, the geo- tioned GML and SFA schemes are presented in more detail and eval- metry description's content cannot be incorporated for querying the uated. data in SPARQL without using extensions, as it is not following the principles of the Semantic Web. From the perspective of the Semantic Web, implementations of 5.3.1. Common geometry schemes approach 3 differ from those of the first two approaches, asthegeo- Non-RDF geometry schemes that can be used with approach 3 are metry is not represented by RDF nodes (linked with object properties) already introduced in Section 2.2. They can be split into schemes but by RDF literals (linked with datatype properties). In detail, a non- dedicated to simple geometry representations, such as tessellated geo- geometric description of any object can be enriched with a datatype metries, and schemes designed for complex geometry descriptions. property that directs to an RDF literal containing a geometry descrip- The first group contains the OBJ, STL and glTF geometry schemes. tion. The geometry description itself can be the content of an entire, The schemes were originally designed for visualisation and animation valid file according to the geometry schema or a snippet, e.g. omitting (OBJ and glTF) or for 3D printing (STL). Accordingly, the schemes' the file header. Again, the implementation can be separated into linking specifications are varying, but predominantly focus on tessellated geometry representations. OBJ also supports mathematical representations, but support in applications seems rather limited. While STL [26] can be used to describe geometry only, without any additional information, OBJ1 and glTF [32] also allow the definition of the geometry's appearance. The most advanced schema of this group is glTF, which also defines a fixed dimensional unit and provides methods to include animations of the geometry. The support of these schemes varies. While STL is well supported in BIM software applications – probably due to the domain's interest in 3D printing –, the web-focused OBJ and glTF schemes enjoy less support. However, OBJ is reasonably well supported in BIM authoring tools in contrast to the rather new glTF schema. Meanwhile, glTF is supported in software applications for animation, game design as well as in web applications in general. Fig. 10. Methodology of approach 3. Regarding file sizes, the conversion process generated tessellated

12 A. Wagner, et al. Automation in Construction 115 (2020) 103130 geometry for OBJ, (binary) STL and glTF. OBJ and STL achieve similar Since the introduction of IFC 4, that enabled the definition of tes- results (resp. 152% and 167% compared to the IFC 2 × 3 sample sellated geometry, any geometry representation can be depicted by the models in BREP representation), though STL does not contain any IFC. Moreover, the previously already included option to define geor- material information while OBJ does. At the same time, our conversion eferences was extended to also allow the definition of the used global process produces glTF files that are more than double in size incom- coordinate system. Other information, such as (geometric) properties parison to OBJ and STL (364% compared to the IFC sample models). and topological relations, may be defined in IFC but cannot be accessed Next to these geometry schemes for simple representations, schemes from the RDF graph the geometry description is embedded in. While for complex representations exist, which can again be differentiated this is true for any data stored in non-RDF geometry descriptions, depending on their intended use within or outside CAD applications. All geometric properties and topological relations are most likely relevant schemes from this group enable 3D modelling, the definition of ad- for querying as well. In conclusion, the evaluation shows that the ac- justable dimensional units and the description of geometry appearance cessible definition of such features is not possible in IFC, as theiden- to some extent. tifiers of definitions – in form of line numbers – are not persistent and Those schemes that are not aimed to serve as exchange format for change when the file/description is altered. If a persistent identification regular CAD data, i.e. COLLADA (DAE) [27] and X3D [24], support of properties or objects is needed, the schema provides means to define features that are typically not required for CAD applications, e.g. phy- Globally Unique Identifiers (GUIDs), though. sics, lighting or definitions of entire scenes. Thus, the schemes generate functional overhead for application in the built environment, which 5.3.2. Simple Feature Access (SFA) may be disadvantageous if these features have to be defined to retrieve The SFA schema – and its WKT and WKB serialisations – is mainly a valid file. COLLADA can describe tessellated geometry, while X3Dcan aimed at storing 2D geospatial data [28]. Hence, the schema is spe- also describe BREP and mathematical geometry representations. X3D cialised to describe 2D shapes, while it only provides polyhedral sur- also provides means to add georeferences to the description, while both faces and Triangular Irregular Networks (TINs) for depicting 3D geo- implement the representation of animations. As the schemes are not metries. Within the evaluation, we therefore treat the supported native to the construction domain, they are typically not well supported geometry representation context as being tessellated geometry, though in BIM software applications. it is arguable whether SFA enables the description of tessellated or The conversion from IFC to X3D via CAD Exchanger could not BREP geometries. Despite the possibility to define 3D geometry in SFA, compute for the three largest IFC models, which is why only ten models 3D geometries are not supported in further functionalities of SFA or are considered for its average file size ratio. Still, in direct comparison, most of its applications. Thus, the schema is scored to only support 2D X3D produces smaller files as COLLADA does (resp. 119% versus 372% geometries. Additionally, the determination of the dimensional unit of compared to BREP IFC sample models). Our conversion process results an object is connected to the used global coordinate system. in tessellated geometry descriptions for both X3D and COLLADA. The application of SFA – more precisely WKT – in RDF literals has Exchange schemes for CAD data are more suited to the needs of the been realised before and is supported by both the GeoSPARQL and construction domain, which in turn may hinder the application of in- stSPARQL extensions of the SPARQL query language for 2D spatial novative technologies from outside this domain. The standardised querying. BimSPARQL even demonstrates how 3D spatial querying can geometry schema IGES [70] supports all geometry representations, but be realised with 3D WKT geometry descriptions. lacks any functionality beyond pure geometry descriptions. For the geometries' appearances, IGES offers eight plain colours to choose from, 5.3.3. Geographic Markup Language (GML) which is rated in the evaluation as if the definition of appearances is not Similar to the STEP schema, GML is a schema that can be extended supported. Next, the DWG schema [23] cannot describe CSG re- by so-called Appearance Models [29]. Within this survey, we consider presentations or animations, but can add georeferences to the geo- the original GML schema. Like the SFA, the GML schema supports metry. When converting the sample IFC models to DWG according to tessellated geometry, since it can describe 3D geometries using poly- the workflow defined in 4.1, errors as missing export, misplacement hedral surfaces and TINs. Another parallel to the SFA is the definition of and detection for conversion of singular BREP or building objects oc- dimensional units that is implemented by defining the global co- curred. Another commonly used geometry schema is the STEP schema, ordinate system, and support by the SPARQL extensions GeoSPARQL of which we analyse the Application Protocol (AP) 214 as the closest and stSPARQL. Other functionalities are not supported, though the related AP to the construction domain [25]. In STEP AP 214, any CityGML Appearance Model, for instance, allows the definition of geometry representation and simple appearances without texture geometry appearances by re-using parts of the X3D schema. mapping can be stored. All three schemes are well understood by popular BIM software applications, with DWG being clearly the most 5.3.4. Findings widespread one. But also IGES is still recognised oftentimes, with STEP The overall results of the considered geometry schemes during their being a little less prominent – probably due to its origin in mechanical evaluation according to the defined criteria are shown in Table 7. Since engineering and manufacturing. approach 3 combines RDF data with non-RDF geometry descriptions, Both STEP and IGES produced BREP geometry descriptions from the the geometric data can be extended using dedicated ontologies, but not conversion process. Since DWG is a proprietary binary geometry in the same depth or detail as is possible for approach 1. Reason for this schema, it is not possible to determine the used geometry representa- is the inaccessibility of properties used within the geometry description tion. If these three schemes are compared to each other, it becomes due to the lack of persistent identifiers. obvious that IGES is not efficient regarding its file size (1240% com- Furthermore, the support of the singular schemes is lowered by one pared to IFC), while DWG is closest to the original IFC file size in step of the scale, as the geometry descriptions need to be escaped average (201%). The output STEP geometries have on average a file (string) and/or encoded (binary) to store them correctly in RDF literals. size between the results of IGES and DWG (665% compared to IFC). For example, IFC descriptions need to be escaped to ensure no RDF Finally, the IFC schema, which originated from the built environ- syntax related characters disturb the RDF graph's description. On the ment, is considered. While the analysis based on file sizes is conducted other hand, schemes that can or must be stored in binary files, e.g. on the previous IFC 2 × 3 version, this section relies on the most DWG, need to be encoded, e.g. in base64. Thus, a pre- and post-pro- current version, IFC4 Add2 [10]. Because of the missing backward cessing of the literals is necessary and hinders a direct application of the compatibility of the schema, the IFC4 schema is not yet fully in- descriptions. Such processing can be complex, if the user decides to corporated by all software vendors, as some of them still support the old store snippets without verbose headers of the schemes. In these cases, version exclusively. the snippets need to be combined and headers must be generated before

13 A. Wagner, et al. Automation in Construction 115 (2020) 103130

Table 7 Evaluation of geometry schemes for approach 3.

C1 C2 C3 C4 C5 C6 C7 C8 Tools File size ratio [%]

OBJ (v3.0) 3D Tessell. Noa Noa No Yes Noa Noa o 151.94 Math. STL (v1.0) 3D Tessell. Noa Noa No Nob Noa Noa + 167.24 glTF (v2.0) 3D Tessell. Yes (fix) aNo Yes Yes Noa Noa − 364.17 DAEc (v1.4.1) 3D Tessell. Yes (adj.) Noa Yes Yes Noa Noa o 372.37 X3D (v3.3) 3D Tessell. Yes (adj.) Yes Yes Yes Noa Noa − 119.41f BREP Math. IGES (v5.3) 3D All Yes (adj.) Noa No Nob Noa Noa o 1240.40 DWG (v2018) 3D Tessell. Yes (adj.) Yes No Yes Noa Noa + 201.15 BREP Math. STEP (AP214 v3) 3D All Yes (adj.) Noa No Yesd Noa Noa − 664.62 IFC (v4 Add2) 3D All Yes (adj.) Yes No Yes Noa Noa + + 100.00g SFA (v1.2.1) 2D Tessell.e Yes (adj.) Yes Noa Noa Noa Noa + + − GML (v3.3.0) 3D Tessell. Yes (adj.) Yes Noa Noa Noa Noa + + −

a By applying specialised ontologies, these criteria can be fulfilled to some extent depending on the character of the geometry description (monolithic orperpart/ assembly). b By applying specialised ontologies, simple appearances without texture mappings can be added. c COLLADA also has a version 1.5.0 that supports BREP and mathematical geometry representations, besides geo-referencing, but applications have limited support for it. d STEP supports the definition of materials and their (simple) appearance, but not texture mapping. e WKT/WKB can describe 2D geometry in primitives and polylines or 3D tessellated geometry. The latter is not supported by most applications. f Only 10 of 13 models could be converted to X3D (3 largest models failed). g The file size ratio analysis is conducted on IFC 2 × 3 sample models inBREP. obtaining valid files according to the schema. When binary geometry descriptions are encoded before entering them in RDF literals, the file size can increase depending on the selected encoding type. Though the IFC is rated to be best supported of all 3D geometry descriptions, it is not ideal to be combined with non-geometric data as an external geometry description. Because of its deep linkage between geometric and non-geometric data, it is not possible to create a valid IFC file that contains only geometric information. Thus, the IFCis considered for comparison rather than recommendation. Fig. 13. Implementations of approach 4. 5.4. Fourth approach – linking to non-RDF geometry files Specialised file annotation ontologies and methodologies exist to Lastly, the fourth approach represents non-RDF geometry descrip- interconnect heterogeneous data in semantically meaningful ways, e.g. tions that are stored in external files and linked from the RDF graph of COINS, Fedora and the Linked Data Platform (see Section 2.3.1), and the non-geometric data (see Fig. 12). Important for this approach to be can be used for this approach as well. Similarly, dedicated annotation comparable to the other ones is the accessibility of the external file, so it ontologies for singular geometry schemes could be applied. However, can be exchanged together with the non-geometric description in RDF. all of the above mentioned methods are restrained to approach 4 and Overall, this approach is closely related to the third approach with cannot be used for any other approaches presented in this article. Since the only difference of the geometry descriptions being stored in their we do not define each annotation or file management ontology buta native file formats. Subsequently, the same non-RDF geometry schemes generalisation of those types, individual methods may be restricted to can be used for approach 4 (Fig. 13). Regarding the linking method, the one singular geometry schema, e.g. the initial use of 3DMO, or could be two approaches differ due to the varying kinds of RDF properties that valid for any schema. Thus, the generalisation is marked with double are used. When approach 3 embedded the geometry description directly black and grey lines in Fig. 13. It is also possible to re-use the domain- in the graph, approach 4 requires pointers to the local or online location specific BOT or the OMG/FOG ontologies to link to external files ofany of the geometry description file (URLs). geometry schema. Since the geometry schemes are discussed in detail in Section 5.3.1, they are not analysed again in this section of approach 4. As a whole, Table 7 is also valid for this approach, only the support by tools is different, as the necessary processing – but also the supported spatial querying – are no longer needed respectively possible. An overview of the available support of geometry descriptions linked in approach 4 per geometry schema is given in Table 8. All common non-RDF geometry schemes except the GML and SFA are rated better for their available tools in this approach, as no pre- or post-processing is required for using the geometry description. However, GML and SFA are rated worse, since it is no longer possible to do SPARQL-based spatial querying on the descriptions if they are not Fig. 12. Methodology of approach 4. stored in RDF literals.

14 A. Wagner, et al. Automation in Construction 115 (2020) 103130

Table 8 Web Technologies well, while it holds disadvantages in its utilisation. Varying evaluation results of approach 4 Due to the complete integration of geometric content into RDF, the compared to approach 3 (Table 7). approach offers extensive possibilities regarding the semantic querying, Tools individual extension, and simple distribution by sharing or linking to URIs of geometry descriptions. However, enhanced querying methods OBJ + as spatial querying are not yet fully developed. On the other hand, the STL + + implementations of this approach are not well supported, and those that glTF – DAE + are, do not apply ordered lists properly. The issue of ordered lists in X3D – RDF also leads to a complexity and verbosity for the geometry de- IGES + scriptions, but it could be addressed by using a Hierarchical Data DWG + + Format (e.g. HDF547) or HDT48 (Header Dictionary Triples) compres- STEP o IFC + + + sion. HDF5 or HDT compressed RDF dumps are considerably smaller SFA + and faster to query, though the compression impedes updating the data GML + [71,72]. Regarding the freedom of choice for implementations, this approach currently provides only few implementations which can be seen as a restriction. 6. Comparison of the approaches The approach 2 (dashed, grey line) has similar characteristics as the first approach. Albeit, the approach holds more restrictions incom- After all approaches and their implementations are presented and parison to the first: Since approach 2 is a combination of an existing analysed in Section 5, the approaches are compared in this section. To JSON web format and RDF, it acts as a compromise between data sto- give further insights on the verbosity of the considered schemes, we rage and application level. Yet, due to the missing functionalities in the first briefly compare the individual results from the conversion process current JSON-LD standard, none of the hoped benefits in support or in that perspective, before moving on to a general comparison of the portability occur. Additionally, this approach might result in two se- approaches based on the aspects defined in Section 4.2. parate graphs – one for geometric and one for non-geometric data – that are stored and serialised in different ways. In that case, this approach 6.1. File size comparison would not lead up to full data integrity. Consecutively, the evaluated functionalities are similar to the ones of the first approach, but mostly Fig. 14 shows an overview of the produced relative file size or triple rated slightly worse. Since currently only one implementation exists, count increase respectively per geometry scheme for the thirteen IFC users are even more restricted in their flexibility to choose appropriate 2 × 3 sample BREP models.46 Before interpreting the results, some implementations, and with most JSON-based geometry schemes relying remarks need to be made: due to errors on the import side of the main on nested lists, their JSON-LD counterpart becomes even more complex conversion tool, e.g. missing detection of elements and misinterpreta- than implementations of approach 1. Moreover, the support is not ex- tion of detailed geometry, not all converted geometry models are istent at point of writing and, as the application of JSON-LD might lead completely true to the original geometry; the results of the conversion to file-based storage of descriptions, the portability is estimated tobe process are not necessarily optimised for each geometry schema; the impeded in comparison to RDF implementations in general. On the results of X3D comprise of only ten models, since the export failed for other hand, the geometric properties would be defined within an RDF the bigger samples; OntoBREP is not considered because of its small graph, even if they are not contained in the same RDF serialisation, and sample size; GEOM is shown twice, once for its original scheme and can thereby easily be accessed for extensions or querying. Also, the once with an assumed triple count if the intended lists were modelled as verbosity is expected to be – at least – similar as in approach 1. ordered lists in RDF (see Section 5.1.4). In contrast, approach 3 (solid, light grey line) re-uses non-RDF With this in mind, the comparison shows that geometry schemes geometry schemes to include them into RDF graphs using RDF literals. dedicated to visualisation or fabrication tend to result in more compact Thus, it provides some benefits from the Semantic Web, while still geometry descriptions than schemes dedicated for CAD applications. being rather simple to utilise. Because of the wide array of existing Moreover, the introduction of ordered lists according to RDF leads to geometry schemes that can be used for this approach, users are able to noticeably higher triple counts with the ifcOWL outperforming the pick a suitable schema for their use cases. The conciseness is highly GEOM schema on average, even if not all ifcOWL triples concern geo- dependent on the individual implementation, but according to the re- metry in a strict sense. Overall, the IFC schema seems to handle the sults of the brief comparison of file sizes, the average size is noticeably geometry description efficiently with only three geometry schemes smaller than the size of RDF-based geometry descriptions. This ap- (OBJ, X3D, GEOM) having medians below the IFC scheme's values and proach also enables users to apply snippets for their geometry de- none staying reliably below the 100% threshold. scriptions, enabling to ignore the redundant parts of geometry schemes' headers. Nonetheless, for preventing syntactical errors in RDF serial- 6.2. Approaches comparison isations, binary geometry schemes need to be encoded and text-based geometry schemes should be escaped to prevent syntactical errors in Considering the evaluation of the approaches themselves, it be- RDF. In the case of encoding binary geometry descriptions, the file size comes obvious from the previous section that neither of the approaches can increase depending on the selected encoding type. This point shows is superior in all aspects. Thus, we conclude each approach and discuss that, although adding geometry descriptions in RDF literals is less its advantages and disadvantages considering the seven aspects as de- complex than creating entire graphs with ordered lists, small technical scribed in Section 4.2: Flexibility, Conciseness, Simplicity, Support, issues have to be taken into account, which also leads to not as pro- Portability, Extensibility, Semantic Content. A visualisation of each found support as the original schemes experience. Still, since the entire approach's characteristic in those aspects is given in Fig. 15. Yet, it content – geometric and non-geometric – is stored within one graph, should be understood that this overview is a generalisation and singular this approach is convenient for exchanging data. In respect of the op- implementations may vary. portunities to extend or query the content of the descriptions, some Approach 1 (solid, dark grey line) exploits the benefits of Semantic

47 https://www.hdfgroup.org/solutions/hdf5/. 46 Exact values can be found at: https://osf.io/yrz9m/?show=revision. 48 http://www.rdfhdt.org/.

15 A. Wagner, et al. Automation in Construction 115 (2020) 103130

2,000 2,000

1,500 1,500 [%] Increase Count Triple

1,000 1,000

File Size Increase [%] 500 500

100 % 0 0 OBJ STL glTF DAE X3D IGES DWG STEP GEOM GEOM2

Fig. 14. Boxplot of relative file size increase compared to IFC (left) and relative triple amount of triples compared to ifcOWL (right) of the analysed geometryschemes with GEOM2 representing an estimation of triple count of GEOM with proper ordered lists.

strengths and implementations, leading to a comparison of the ap- Approach 1 Approach 2 Approach 3 proaches. Of all approaches, three can currently be considered for utilisation, while one still has to overcome technical challenges to make its Approach 4 application feasible (approach 2). The three at present usable approaches range from an intensive Flexibility integration into RDF by using RDF-based geometry schemes (approach 1) to linking to external files containing geometry descriptions in fre- quently used geometry schemes (approach 4). The first exploits the most benefits from applying Semantic Web Technologies, i.e. querying, Semantic Expressivity Conciseness extensibility and simple distribution over the Web via URIs and linking. Yet, at the point of writing, it also requires the most effort to deploy it in ongoing processes and common software applications. In contrast, approach 4 can be utilised easily and without disturbing the current processes and software applications, but it is limited in applying Semantic Web methods. As a compromise, another approach is to add geometry descriptions in arbitrary geometry schemes to the RDF graph using RDF literals (approach 3), and provides benefits and drawbacks in Extensibility Simplicity between the other approaches. The analysis resulting in this comparison is conducted in hindsight of collected requirements from typical use cases in the construction domain. As the collection of use cases indicates, the requirements as well as the software environment of this domain is rather heterogeneous. In combination with the approaches' functionalities that are dependent on the used geometry schema itself, the conclusion that no Portability Support overall recommendation towards one approach or geometry schema Fig. 15. Visualisation of the evaluation results. can be given must be drawn. Instead, we recommend to choose the best suitable approach and geometry scheme individually per use case or project. functionalities exist, e.g. spatial querying, yet direct links towards parts or properties of the geometry descriptions are only possible if the used schema has persistent identifiers for them. 7.1. Selecting the right approach for each use case Finally, approach 4 (dotted, black line) is the easiest approach to utilise, but also holds the least benefits of the Semantic Web. Since non- In order to select the best approach for a specific use case, one first RDF geometry descriptions are stored in their native format as external needs to answer a more general question regarding the project or re- files, users can choose any existing geometry schema and little tono search: What is the project or research aiming at: easy implementation of additional data needs to be created, keeping this approach concise. workflow or full use of Semantic Web potential? With the answer of this Linking to external files is a simple feature of RDF graphs and those files question, a pre-selection of approaches can already be conducted and can be used in any application that supports their schema without the singular implementations of the chosen approach(es) should be further ado. However, the availability of the external file needs to be considered in more detail. With the individual requirements of the ensured, and the geometric and non-geometric data will be stored in considered use case or project, a suitable geometry scheme can then be separate locations, complicating the exchange process. Also, the pos- identified based on the analysed criteria of each implementation (see sibilities to query or extend the files are limited and mostly rely on Section 5). For further understanding, two example use cases involving annotation ontologies that oftentimes result in redundant data. Heritage BIM and product descriptions respectively will be presented in the following paragraphs. 7. Conclusion The field of Heritage BIM consists of various applications and aims. For demonstration, we consider the three aims of (1) as-is doc- Within this article, we identify and present four different ap- umentation, (2) simulation and analysis, and (3) design of modifica- proaches for integrating geometry descriptions into a Semantic Web tions. Each of these aims requires different functionalities and geometry context. Each approach is discussed regarding their weaknesses, representations.

16 A. Wagner, et al. Automation in Construction 115 (2020) 103130

An as-is documentation (1) is typically performed with point clouds produced by surveys, old plan documents and photos. Thus, the geometry for this aim can be partially represented by point clouds and complex meshes derived from them. As these descriptions usually result in large files and no annotation or additional information on geometry object level is required, we recommend to use approach 4 (linking to external files) in combination with a binary geometry schema forpoint clouds or meshes. For simulation purposes (2), the geometry descriptions are oftentimes simplified and additional information, such as topological relations or material properties, may be needed in higher detail. Ergo, approach 3 (RDF literals) in combination with a geometry schema for tessellated geometry would suit this purpose best. However, the exact geometry schema should be chosen in consideration of the specific software application and its input formats. Lastly, the design of modifications (3), e.g. in the case of restoration, requires geometry descriptions that can easily be manipulated and might call for parametric modelling even. With this in mind, we suggest Fig. 16. Potential architectures to include multiple geometry descriptions. to use approach 3 if no parametric modelling is needed and approach 1 if it is. Nonetheless, the chosen geometry schema should support BREP, mathematical or CSG geometry representations to enable easy transfer individual geometry descriptions could then be converted from the of modifications. master geometry when needed, and conducted modifications can be On the other hand, product descriptions – especially of innovative written back into the master geometry. products – require more complex geometry descriptions in respect of While the second method seems more promising, as the conversion (parametric) modelling. Subsequently, tessellated geometry or point process could be standardised more easily, it cannot be implemented, clouds are not well suited for this approach, and CSG, BREP or math- currently. As the master geometry would need to contain any geometric ematical geometry representation contexts should be chosen. In addi- information each geometry description includes, the master geometry tion, in the case of innovative products, the geometry should be dy- must be structured according to a geometry schema that is superior to namic, as the products are usually not ready-made but manufactured all others in order to provide means to store any geometric information. individually according to the required measurements. Moreover, Since no such superior geometry schema exists, this method is not properties of products are important to simulations during the building feasible at point of writing. design and operational phases, so they should be as precise as possible Regardless which method is chosen, the introduced approaches for the related simulations. Due to the dependency between geometric allow to have one non-geometric description as an RDF resource and and non-geometric properties that often occurs, these dependencies combine it with one or multiple geometry descriptions. Since all ap- should be captured by the product description as well [73]. Concluding, proaches are based on principles of the Semantic Web, the approaches this use case demands approach 1 and a powerful geometry scheme can be combined freely. However, to enable intuitive and simple based on suitable geometry representation contexts, since this approach querying in disregard of the approach at hand, one should comply to promises the best possibilities to model dependencies between geo- uniform linking methods. Within our research, we identify two linking metric and non-geometric properties while still enabling powerful se- methods that are capable to establish connections for all considered mantic searches, e.g. for product search. approaches: BOT [14] and OMG/FOG [42,43]. Yet, to further enhance automatic processing of geometry descriptions from an RDF graph, the 7.2. Multiple geometry descriptions exact geometry schema that is used needs to be known. This requirement is only satisfied by the OMG/FOG linking method. As the example cases have shown, it rarely occurs that one geometry Furthermore, handling multiple geometry descriptions of the same object is used in just one use case or application. This implies that – if object leads to the danger of creating inconsistent and contradicting only one geometry description is used – a wide array of requirements data. Thus, the dependencies between multiple geometry descriptions from each use case must be met, potentially with some of the require- must be described in detail. In this aspect, the OMG ontology introduces ments contradicting each other. Furthermore, due to the heterogeneous concepts for defining dependencies between different geometry de- software environment in the construction domain and their different scriptions regarding their actual and potential derivation from each geometry kernels without uniform interpretation of geometry descrip- other. Moreover, the ontology introduces concepts for version histories tions, using one singular geometry description inevitably results in of geometry descriptions, which enables to automatically detect out- misinterpretations, inaccuracies and error-prone conversion processes. dated geometry descriptions. Based on these links between geometry Hence, we claim that the application of one singular geometry de- descriptions, the conversion process could be automated and realised scription per object is not feasible. application-independently to ensure a consistent data quality. Instead, we argue to support multiple, interlinked geometry de- In practice, multiple geometry descriptions are ideally implemented scriptions per object. Thereby, optimised geometry schemes can be by an agreement on a workflow for defining and synchronising re- applied for individual use cases and software applications. If conver- dundant geometry descriptions of different approaches and geometry sions between the geometry descriptions are needed or wanted, the schemes – including a definition for a reference geometry kernel forthe conducted conversion process as well as potential conversion processes individual project (phase). Corresponding conversion and synchroni- for future changes in the object's geometry can be defined un- sation processes can then be implemented as part of the framework that ambiguously. The architecture for handling multiple geometry de- handles the common data environment of the project consortium. scriptions can vary, as Fig. 16 shows on two examples. Method 1 suggests each geometry description to be connected di- 7.3. Future work rectly to the object, with conversions taking place in between the different geometry descriptions. Meanwhile, method 2 considers an in- Throughout this article, we identify several starting points and termediate geometry node to serve as a ‘master geometry’. The lacking functionalities or tools that can be addressed in future research.

17 A. Wagner, et al. Automation in Construction 115 (2020) 103130

Beginning with the first approach, we notice a lack of a convincing [4] G.F. Schneider, M.H. Rasmussen, P. Bonsma, J. Oraskari, P. Pauwels, Linked geometry schema which also enjoys extensive support by conversion, building data for modular building information modelling of a smart home, eWork and eBusiness in Architecture, Engineering and Construction (ECPPM 2018), CRC visualisation and modelling tools. The closest candidate to achieve this Press, Copenhagen, Denmark, 2018, pp. 407–414. position in respect of support is the GEOM ontology, for which we [5] E. Curry, J. O’Donnell, E. Corry, S. Hasan, M. Keane, S. O’Riain, Linking building observe a fundamental fault, i.e. no implementation of ordered lists data in the cloud: integrating cross-domain building data using linked data, Adv. Eng. Inform. 27 (2) (2013) 206–219, https://doi.org/10.1016/j.aei.2012.10.003. according to RDF. At the current state, GEOM is therefore not applic- [6] S. Törmä, Semantic linking of building information models, 2013 IEEE Seventh able for storing geometry descriptions in triple stores or for RDF-based International Conference on Semantic Computing, 2013, pp. 412–419, , https://doi. processing as querying. Regarding the other geometry schemes of this org/10.1109/ICSC.2013.80. approach, little to no support is available and the availability of existing [7] P. Pauwels, Supporting decision-making in the building life-cycle using linked building data, Buildings 4 (3) (2014) 549–579, https://doi.org/10.3390/ tools are limited. For this approach to gain popularity, its im- buildings4030549. plementations need to be faultless and better supported to reduce the [8] A. Borrmann, V. Berkhahn, Principles of geometric modeling, Building Information suspension for switching technologies entirely. Additionally, the ap- Modeling, Springer International Publishing, Cham, 2018, pp. 27–41, , https://doi. org/10.1007/978-3-319-92862-3_2 Ch. 2. URL http://link.springer.com/10.1007/ proach is currently not exploiting the full potential of the Semantic 978-3-319-92862-3_2. Web, as spatial querying is not yet implemented. [9] J. Verstraete, Dealing with rounding errors in geometry, Flexible Query Answering As the second approach is not applicable at this point, we cannot Systems, 2015 2015, pp. 417–428, , https://doi.org/10.1007/978-3-319-26154- 6_32. suggest improvements beyond establishing the basic functionality, i.e. [10] ISO/TC 59/SC 13, ISO 16739-1:2018: Industry Foundation Classes (IFC) for data addressing the issue of nested ordered lists in the JSON-LD serialisation sharing in the construction and facility management industries - part 1: data of RDF. schema, Tech. Rep, ISO, 2018. [11] S. Tessier, Y. Wang, Ontology-based feature mapping and verification between CAD The last two approaches are already well supported by software systems, Adv. Eng. Inform. 27 (1) (2013) 76–92, https://doi.org/10.1016/j.aei. applications, but their integration into the Semantic Web could be en- 2012.11.008. hanced. For approach 3, tools for automated and uniform escaping and [12] K. Ohori, H. Ledoux, F. Biljecki, J. Stoter, Modeling a 3D city model and its levels of detail as a true 4D model, ISPRS Int. J. Geo Inf. 4 (3) (2015) 1055–1075, https:// encoding would simplify processing the data and available tools for doi.org/10.3390/ijgi4031055. spatial querying could be extended to support 3D geometry and a wider [13] C. Métral, A.-F. Cutting-Decelle, Ontologies for interconnecting urban models, variety of geometry schemes. Additionally, both approach 3 and 4 Ontologies in Urban Development Projects. Advanced Information and Knowledge would benefit from a uniform annotation ontology that enables better Processing, 1 Springer, 2011, pp. 105–122, , https://doi.org/10.1007/978-0- 85729-724-2. extension and maybe even querying of the (external) geometry de- [14] M.H. Rasmussen, P. Pauwels, C.A. Hviid, J. Karlshøj, Proposing a central AEC on- scriptions. tology that allows for domain specific extensions, Lean and Computing in In general, for establishing links between non-geometric objects and Construction Congress - Volume 1: Proceedings of the Joint Conference on Computing in Construction, 2017, pp. 237–244, , https://doi.org/10.24928/JC3- their geometry descriptions, one method should be applied in a uniform 2017/0153. way. Since the BOT ontology has its focus on topological relations of [15] T. Kauppinen, R. Henriksson, R. Sinkkilä, R. Lindroos, J. Väätäinen, E. Hyvönen, buildings and building objects, we suggest to abstain from establishing Ontology-based disambiguation of spatiotemporal locations, Proceedings of the 1st IRSW2008 International Workshop on Identity and Reference on the Semantic Web generic connections to geometry from BOT and instead apply the more 422, accessed on 16.05.2019. URL https://seco.cs.aalto.fi/publications/2008/ specific concepts introduced in OMG/FOG, which aim at connecting kauppinen-et-al-spatiotemporal.pdf. non-geometric and geometric data in RDF only and therefore provide [16] C. Zhang, J. Beetz, B. de Vries, BimSPARQL: domain-specific functional SPARQL extensions for querying RDF building data, Semant. Web 9 (6) (2018) 829–855, more powerful concepts. Moreover, if multiple geometry descriptions https://doi.org/10.3233/SW-180297. are applied, additional metadata as up-axes and geospatial information [17] M. Schreyer, C. Pflug, BIM in industrial prefabrication for construction, Building should be added to the geometry descriptions. This could be realised by Information Modeling, Springer, 2018, pp. 413–420, , https://doi.org/10.1007/ 978-3-319-92862-3_25 Ch. 25. extending the available OMG/FOG method with an additional metadata [18] K. McGlinn, A. Wagner, P. Pauwels, P. Bonsma, P. Kelly, D. O’Sullivan, Interlinking module. geospatial and building geometry with existing and developing standards on the web, Autom. Constr. 103 (2019) 235–250, https://doi.org/10.1016/j.autcon.2018. Declaration of competing interest 12.026. [19] P. Pauwels, T. Krijnen, W. Terkaj, J. Beetz, Enhancing the ifcOWL ontology with an alternative representation for geometric data, Autom. Constr. 80 (2017) 77–94, The authors declare that they have no known competing financial https://doi.org/10.1016/j.autcon.2017.03.001. [20] P. Pauwels, D. Van Deursen, J. de Roo, T. Van Ackere, R. de Meyer, R. Van de Walle, interests or personal relationships that could have appeared to influ- J. Van Campenhout, Three-dimensional information exchange over the semantic ence the work reported in this paper. web for the domain of architecture, engineering, and construction, Artif. Intell. Eng. Des. Anal. Manuf. 25 (4) (2011) 317–332, https://doi.org/10.1017/ S0890060411000199. Acknowledgements [21] Y. Qin, W. Lu, Q. Qi, X. Liu, Y. Zhong, P.J. Scott, X. Jiang, Status, comparison, and issues of computer-aided design model data exchange methods based on standar- We would like to thank our interview partners for the collection of dized neutral files and web ontology language file, J. Comput. Inf. Sci. Eng.17(1) (2016) 010801, , https://doi.org/10.1115/1.4034325. the presented use case requirements. [22] M. Spagnuolo, B. Falcidieno, 3D media and the semantic web, IEEE Intell. Syst. 24 This work is part of the research project EnOB: SCOPE, founded by (2) (2009) 90–96, https://doi.org/10.1109/MIS.2009.20. the German Federal Ministry for Economic Affairs and Energy (BMWi). [23] ODA (Open Design Alliance), Open design specification for .dwg files, Tech. Rep., Open Design Alliance, Accessed on 03.06.2019, 2018 URL https://www. This research is funded by the Research Foundation Flanders (FWO) opendesign.com/files/guestdownloads/OpenDesign_Specification_for_.dwg_files. in the form of a personal Strategic Basic research grant. pdf. [24] Web3D Consortium, X3D standards for version V3.3, Tech. Rep., Web3D References Consortium, 2015 accessed on 03.06.2019. URL http://www.web3d.org/ standards/version/V3.3. [25] ISO/TC 184/SC 4, ISO 10303-214:2010 - industrial automation systems and in- [1] P. Pauwels, S. Zhang, Y.-C. Lee, Semantic web technologies in AEC industry: a lit- tegration – product data representation and exchange – part 214: application pro- erature overview, Autom. Constr. 73 (2017) 145–165, https://doi.org/10.1016/j. tocol: core data for automotive mechanical design processes, Tech. Rep, ISO, 2010. autcon.2016.10.003. [26] J.D. Hiller, H. Lipson, STL 2.0: a proposal for a universal multi-material additive [2] M. Bonduel, M.H. Rasmussen, P. Pauwels, M. Vergauwen, R. Klein, A novel work- manufacturing file format, Mechanical and Aerospace Engineering, 2009, pp. flow to combine BIM and Linked Data for existing buildings, EWork and eBusiness 266–278 accessed on 03.06.2019. URL http://sffsymposium.engr.utexas.edu/ in Architecture, Engineering and Construction (ECPPM 2018), 11 2018, pp. Manuscripts/2009/2009-23-Hiller.pdf. 347–354. [27] The Khronos Group Inc., COLLADA - digital asset schema release 1.4.1, Tech. Rep, [3] G.F. Schneider, Towards aligning domain ontologies with the building topology Khronos Group, 2008accessed on 03.06.2019. URL https://www.khronos.org/files/ ontology, in: University of Burgundy (Ed.), 5th Linked Data in Architecture and collada_spec_1_4.pdf. Construction Workshop, France, Dijon, 2017, p. 9, , https://doi.org/10.13140/RG. [28] OGC, OpenGIS® implementation standard for geographic information - simple 2.2.21802.52169. feature access - part 1: common architecture, Tech. Rep, OGC, 2011accessed on

18 A. Wagner, et al. Automation in Construction 115 (2020) 103130

16.05.2019. URL http://portal.opengeospatial.org/files/?artifact_id=25355E Web Semant. Sci. Serv. Agents World Wide Web 33 (2015) 141–169, https://doi. +Implementation+Standard+for+Geographic+information+-+Simple org/10.1016/j.websem.2015.03.001. +feature+access#1. [49] M. Hert, G. Reif, H.C. Gall, A comparison of RDB-to-RDF mapping languages, [29] Open Geospatial Consortium, OGC® Geography Markup Language (GML) v3.3.0, Proceedings of the 7th International Conference on Semantic Systems - I-Semantics Tech. Rep, OGC, 2012accessed on 03.06.2019. URL http://www.opengeospatial. ’11, ACM Press, New York, New York, USA, 2011, pp. 25–32, , https://doi.org/10. org/standards/gml. 1145/2063518.2063522. [30] P. Bonsma, I. Bonsma, A.E. Ziri, E. Iadanza, F. Maietti, M. Medici, F. Ferrari, [50] K. Bereta, M. Koubarakis, Ontop of geospatial databases, The Semantic Web-ISWC R. Sebastian, S. Bruinenberg, P.M. Lerones, Handling huge and complex 3D geo- 2016. Lecture Notes in Computer Science, Springer, 2016, pp. 37–52, , https://doi. metries with Semantic Web technology, IOP Conf. Ser. Mater. Sci. Eng. 364 (1) org/10.1007/978-3-319-46523-4_3. (2018) 012041, , https://doi.org/10.1088/1757-899X/364/1/012041. [51] A. Monteiro, J. Poças Martins, A survey on modeling guidelines for quantity takeoff- [31] A. Perzylo, N. Somani, M. Rickert, A. Knoll, An ontology for CAD data and geo- oriented BIM-based design, Autom. Constr. 35 (2013) 238–253, https://doi.org/10. metric constraints as a link between product models and semantic robot task de- 1016/j.autcon.2013.05.005. scriptions, 2015 IEEE/RSJ International Conference on Intelligent Robots and [52] A. Borrmann, M. König, C. Koch, J. Beetz, Building Information Modeling, Springer, Systems (IROS), 2015, pp. 4197–4203, , https://doi.org/10.1109/IROS.2015. 2015, https://doi.org/10.1007/978-3-658-05606-3. 7353971. [53] A. Borrmann, M. König, C. Koch, J. Beetz, Building Information Modeling, Springer, [32] The Khronos Group Inc, glTF 2.0 specification, Tech. Rep. Khronos Group, 2018, https://doi.org/10.1007/978-3-319-92862-3. 2017accessed on 03.06.2019. URL https://github.com/KhronosGroup/glTF/tree/ [54] S. Daum, A. Borrmann, Processing of topological BIM queries using boundary re- master/specification/2.0. presentation based methods, Adv. Eng. Inform. 28 (4) (2014) 272–286, https://doi. [33] H. Butler, Inc. Hobu, M. Daly, A. Doyle Cadcorp, S. Gillies, S. Hagen Mapbox, org/10.1016/j.aei.2014.06.001. T. Schaub, Planet labs, the GeoJSON format (RFC 7946), Tech. Rep, Internet [55] G.N. Lilis, G.I. Giannakis, D.V. Rovas, Automatic generation of second-level space Engineering Task Force (IETF), 2016accessed on 03.06.2019. URL https://tools.ietf. boundary topology from IFC geometry inputs, Autom. Constr. 76 (2017) 108–124, org/html/rfc7946. https://doi.org/10.1016/j.autcon.2016.08.044. [34] D. Huber, The ASTM E57 file format for 3D imaging data exchange, Proceedings of [56] S. Franz, U. Rüppel, T.E. Kuhn, J. Teizer, A multi-agent-based platform for the early the SPIE Vol. 7864A, Electronics Imaging Science and Technology Conference (IS& integration of photovoltaic systems in building façades, Proceedings of the T), 3D Imaging Metrology, 7864A 2011, p. 78640A, , https://doi.org/10.1117/12. International Conference on Computing in Civil and Building Engineering 2016, 876555. 2016, pp. 471–476. [35] BIM-Loket, COINS building objects virtual construction, accessed on 16.05.2019. [57] David Stutz, A formal definition of watertight meshes, accessed on 15.05.2019. URL, 2016. http://www.coinsweb.nl/. URL, 2018. https://davidstutz.de/a-formal-definition-of-watertight-meshes/. [36] T. Messaoudi, P. Véron, G. Halin, L. De Luca, An ontological model for the reality- [58] J. Teizer, A. Blickle, T. King, O. Leitzbach, D. Guenther, H. Mattern, M. König, BIM based 3D annotation of heritage building conservation state, J. Cult. Herit. 29 for 3D printing in construction, Building Information Modeling, 2018, pp. 421–446, (2018) 100–112, https://doi.org/10.1016/j.culher.2017.05.017. , https://doi.org/10.1007/978-3-319-92862-3_26 Ch. 26. [37] G. Vasilakis, A. Garcia-rojas, L. Papaleo, C.E. Catalano, M. Spagnuolo, F. Robbiano, [59] BIMCommunity, Which Software BIM is the Best for Me? BIMCommunity, 2018 M. Vavalis, M. Pitikakis, A common ontology for multi-dimensional shapes, SAMT accessed on 16.05.2019. URL https://www.bimcommunity.com/technical/load/ 2007 2nd International Conference on Semantic and Digital Media, MAReSO 443/which-software-bim-is-the-best-for-me. Workshop Proceedings, 2007, pp. 31–43 accessed on 27.01.2020. URL https://core. [60] GIS Geography, Mapping Out the GIS Software Landscape, GIS Geography, 2018 ac.uk/download/pdf/37832944.pdf. accessed on 16.05.2019. URL https://gisgeography.com/mapping-out-gis-software- [38] S. Abdul-Ghafour, P. Ghodous, B. Shariat, E. Perna, Towards an intelligent CAD landscape/. models sharing based on semantic web technologies, Collaborative Product and [61] J. Dimyadi, S. Henderson, D. Dimalen, Open IFC model repository, accessed on Service Life Cycle Management for a Sustainable World, 2008, pp. 195–203, , 16.05.2019. URL, 2019. http://openifcmodel.cs.auckland.ac.nz/. https://doi.org/10.1007/978-1-84800-972-1_18. [62] E.W. East, Common building information model files and tools - project 1. Duplex [39] S. Abdul-Ghafour, P. Ghodous, B. Shariat, E. Perna, Ontology development for the apartment, accessed on 16.05.2019. URL, 2011. https://www.nibs.org/page/bsa_ integration of CAD models in a collaborative environment, Improving Complex commonbimfiles. Systems Today. Advanced Concurrent Engineering, 33 Springer, 2011, pp. [63] S. van Schaijk, Github openBIMstandards - DataSetSchependomlaan/Design Model 207–214, , https://doi.org/10.1007/978-0-85729-799-0_24. IFC/IFC Schependomlaan.ifc, (2016), https://doi.org/10.17605/OSF.IO/NE2YU. [40] S. Abdul-Ghafour, P. Ghodous, B. Shariat, E. Perna, F. Khosrowshahi, Semantic [64] M. Sporny, D. Longley, G. Kellogg, M. Lanthaler, N. Londström, JSON-LD 1.0, Tech. interoperability of knowledge in feature-based CAD models, Comput. Aided Des. 56 Rep., W3C, 2014 accessed on 22.05.2019. URL https://www.w3.org/TR/json-ld/. (2014) 45–57, https://doi.org/10.1016/j.cad.2014.06.001. [65] R. Barbau, S. Krima, S. Rachuri, A. Narayanan, X. Fiorentini, S. Foufou, R.D. Sriram, [41] L.F. Sikos, A novel ontology for 3D semantics: ontology-based 3D model indexing OntoSTEP: enriching product model data using ontologies, Comput. Aided Des. 44 and content-based video retrieval applied to the medical domain, Int. J. Metadata (6) (2012) 575–590, https://doi.org/10.1016/j.cad.2012.01.008. Semant. Ontol. 12 (1) (2017) 59–70, https://doi.org/10.1504/IJMSO.2017. [66] P. Bonsma, I. Bonsma, T. Zayakova, A. van Delft, R. Sebastian, M. Böhms, Open 087702. standard CMO for parametric modelling based on Semantic Web, eWork and [42] A. Wagner, M. Bonduel, P. Pauwels, R. Uwe, Relating geometry descriptions to its eBusiness in Architecture, Engineering and Construction (ECPPM 2014), 2014, pp. derivatives on the web, Proceedings of the European Conference on Computing in 923–928 ISBN: 978-1-138-02710-7. Construction (EC3 2019), Chania, Greece, 2019, pp. 304–313, , https://doi.org/10. [67] P. Pauwels, W. Terkaj, EXPRESS to OWL for construction industry: towards a re- 35490/EC3.2019.146. commendable and usable ifcOWL ontology, Autom. Constr. 63 (2016) 100–133, [43] M. Bonduel, A. Wagner, P. Pauwels, M. Vergauwen, R. Klein, Including widespread https://doi.org/10.1016/j.autcon.2015.12.003. geometry formats in semantic graphs using RDF literals, Proceedings of the [68] A. Perzylo, N. Somani, M. Rickert, A. Knoll, OntoBREP: an ontology for CAD data European Conference on Computing in Construction (EC3 2019), Chania, Greece, based on a boundary representation, accessed on 16.05.2019. URL, 2018. https:// 2019, pp. 341–350, , https://doi.org/10.35490/EC3.2019.166. github.com/OntoBREP/ontobrep. [44] M. Perry, J. Herring, OGC GeoSPARQL - a geographic query language for RDF data, [69] R. Sudarsan, R. Barbau, S. Krima, OntoSTEP plugin, accessed on 15.05.2019. URL, Tech. Rep, OGC, 2012accessed on 16.05.2019. URL http://www.opengis.net/doc/ 2016. https://www.nist.gov/services-resources/software/ontostep-plugin. IS/geosparql/1.0. [70] U.S. Product Data Association, Initial graphics exchange specification (formerly [45] M. Koubarakis, K. Kyzirakos, M. Karpathiotakis, Introduction in stRDF and ANS US PRO/IPO-100-1996), Tech. Rep., US PRO, 1996 accessed on 03.06.2019. stSPARQL, Tech. Rep., Strabon, 2012 accessed on 16.05.2019. URL http://www. URL https://web.archive.org/web/20120821190122/http://www.uspro.org/ strabon.di.uoa.gr/files/stSPARQL_tutorial.pdf. documents/IGES5-3_forDownload.pdf. [46] G. Garbis, K. Kyzirakos, M. Koubarakis, Geographica: a benchmark for geospatial [71] J.D. Fernández, M.A. Martínez-Prieto, C. Gutiérrez, A. Polleres, M. Arias, Binary RDF stores, The International Semantic Web Conference (ISWC 2013), Lecture RDF representation for publication and exchange (HDT), J. Web Semant. 19 (2013) Notes in Computer Science (LNCS), Springer, 2013, pp. 343–359, , https://doi.org/ 22–41, https://doi.org/10.1016/j.websem.2013.01.002. 10.1007/978-3-642-41338-4_22. [72] T. Krijnen, J. Beetz, A SPARQL query engine for binary-formatted IFC building [47] A. Dimou, M. Vander Sande, P. Colpaert, R. Verborgh, E. Mannens, R. Van de Walle, models, Autom. Constr. 95 (2018) 46–63, https://doi.org/10.1016/j.autcon.2018. RML: a generic language for integrated RDF mappings of heterogeneous data, in: 07.014. C. Bizer, T. Heath, S. Auer, T. Berners-Lee (Eds.), Proceedings of the 7th Workshop [73] A. Wagner, L.K. Möller, C. Leifgen, U. Rüppel, SolConPro: describing multi-func- on Linked Data on the Web, Vol. 1184 of CEUR Workshop Proceedings, 2014 ac- tional building products using semantic web technologies, EWork and eBusiness in cessed on 16.05.2019. URL http://ceur-ws.org/Vol-1184/ldow2014_paper_01.pdf. Architecture, Engineering and Construction (ECPPM 2018), 12, 2018, pp. 447–455 [48] M. Rodríguez-Muro, M. Rezk, Efficient SPARQL-to-SQL with R2RML mappings, ISBN: 978-0-429-01364-5.