Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 An ontological model for the representation of damage to constructions Al-Hakam Hamdan1, Mathias Bonduel2, and Raimar J. Scherer1 1 Institute of Construction Informatics, Technische Universität Dresden, Dresden, Germany Al-Hakam.Hamdan@tu-dresden.de 2 Dept. of Civil Engineering, Technology Cluster Construction, KU Leuven, Ghent, Belgium Abstract. The Damage Topology Ontology (DOT) is presented, a web ontol- ogy that provides terminology to represent construction-related damages and their topology as well as relations to affected construction elements and spatial zones. Besides the topology, classes and properties for documentation manage- ment and a minimal structural assessment have been proposed in DOT. In this re- gard, DOT provides all classes and properties needed for practical use in construc- tion inspections and damage assessment. The ontology is developed to be used with the modular Linked Building Data ontologies structure, where DOT works as core damage ontology which can be extended with multiple modules related to detailed damage classification, damage assessment, mechanical degradation and other application scenarios. Geometrical damage representations are separated from the topology, so that it is possible to initially record damages during the inspection without any geometrical properties and link it later with a correspond- ing representation using terminology from geometry-related ontologies. In con- clusion, DOT can be applied as a stand-alone web ontology to represent damages in a machine-interpretable format and replace conventional record approaches. Therefore, a generic terminology is used that enables the inclusion of various types of damage, which can be extended with domain-specific information. Keywords: Damage Recording · Building Information Modeling · Ontologies · Linked Data. 1 Introduction Building Information Modeling (BIM) offers new ways for modeling constructions in a digital and collaborative environment. However, existing commercial BIM applications are mainly intended to support the design phase and thus are limitedly applied for already existing constructions [16]. For instance, in 2017, 69% of all construction work in Germany was carried out on existing buildings [5]. Consequently, the status of BIM is in contradiction with a large part of the current development of construction services. In order to create rich digital representations of existing constructions it must be possible to connect them to other data, e.g. related to damages, project phasing or deconstruction processes. In this regard, multiple stakeholders, e.g. damage assessment teams, architects or structural engineers can benefit in particular from a digital representation of damages and its data exchange, since degradation occurs during the entire life cycle of a construction and has an impact on the usability as well as the structural capability. 64 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 In this research a model for damage representations has been developed by utilizing web technologies, more specifically Linked Data that allow to easily define new structured terminology based on web standards such as the Resource Description Framework (RDF)1, RDF-Schema(RDFS)2 and Web Ontology Language (OWL)3. Therefore, the Damage Topology Ontology (DOT) was developed as a modular web ontology for defining damage objects and their topology. Due to its generality, DOT can be utilized as part of the BIMification process [14], where an in depth survey of damages is an important process step. Besides defining the damage topology, DOT also serves as a core ontology for the digital representation of degradation. Thereby, DOT can be extended by additional ontologies that allow to add more detailed damage classifications and the structural mechanics of damages as well as ontologies for damage assessment according to specific standards. In this regard, one primary objective is the compatibility with existing web ontologies created within the W3C Linked Building Data Community Group (LDB CG), such as the Building Topology Ontology (BOT) [12] or ifcOWL [10]. The aim of this paper is the description of DOT, as well as introducing extension ontologies for damage classification, damage assessment and structural mechanics. Furthermore, the web ontologies are tested on a use case where inspected damages are modeled on ontological models which represent existing constructions. Lst. 1 contains an overview of the used prefixes throughout this research paper. Listing 1: Used RDF prefixes in this paper. @prefix rdf: . @prefix rdfs: . @prefix owl: . @prefix bot: . @prefix brot: . @prefix dot: . @prefix cdo: . @prefix dasb: . @prefix dmo: . @prefix omg: . @prefix fog: . # namespace for example node instances @prefix inst: . 2 Related Work 2.1 Geometry dependent BIM for Damage Representation In order to digitize defects and damages of constructions, various approaches have been developed that are dependent on a BIM model with geometry, including several ones 1 https://www.w3.org/RDF/ 2 https://www.w3.org/TR/rdf-schema/ 3 https://www.w3.org/OWL/ 65 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 that propose to extend the Industry Foundation Classes (IFC)4, a standardized data exchange format for BIM. One of the first approaches for representing damages has been developed by Hammad et al. [6], where damage information has been linked with other inspection relevant information about the bridge life cycle stages in a 4D model that uses definitions from IFC for the representation of the 3D bridge model and combines them with time-dependent data. In the project SeeBridge [13] the IFC extension ‘Inspection BIM Model’ has been defined for bridge constructions. It consists of damages modeled in 3D as boundary shape representations combined with meaningful damage parameters (e.g. damage type or size measurements) and attached texture images. The defect elements are linked with construction elements by using the aggregation relationship ‘IfcRelAggregates’. Based on this research, Tanaka et al. [15] developed a bridge information model, using degradation elements, as well as measured and repaired regions as primary elements. Additionally, a new subtype of ‘IfcRelConnects’, named ‘IfcRelConnectsToTimeVariations’ has been created to link equivalent degradation elements from different inspection dates with each other, so that the degradation progress could be represented. Despite the aforementioned methods for modeling damage representations in IFC or other geometrical BIM formats, they are still not supported by current BIM modeling tools and formats. One of the reasons is related to the process of creating 3D geometrical construction representations, which is more complicated for existing constructions. To get a 3D geometry model, geometric information reflecting the as-is state of the existing construction (e.g. via a laser scan or from existing plans) is necessary. Furthermore, a 3D solid geometry of each construction component has to be created - either manually or semi-automatically - before these objects can be classified, get properties and can be related to damages that affect them. Both steps can have a serious impact on the price and time to complete a BIM model. The first step can be expensive if accurate as-built documentation is lacking because of the survey equipment or expertise while the second step, depending on the aimed accuracy, requires a relatively long modeling time. Another problem, that concerns the IFC extensions for damage representation is the monolithic structure of IFC which leads to a slower approval process of new proposed extensions in the main schema. This problem could be avoided when using a more modular data structure that can be extended over time. Consequently, no such data structure exists that supports linking a damage representation with geometry, assessment, documentation and digital construction elements. However, this is necessary to enable a collaborative data environment between multiple stakeholders. Therefore, in the following section, the usage of Linked Data for defining damages is studied more in detail. 2.2 Linked Data Approach for Damage Representation To use BIM without the need to solve the problem of modeling a 3D geometry of an existing construction, Bonduel et al. [2] suggests a more flexible workflow utilizing Linked Data, by starting to describe the building topology without geometry. As a result, it is directly possible to classify building components and to connect them with other data. In a later phase, when the need arises, geometrical data can be connected to the earlier created building topology. By utilizing this approach, it would be possible to connect 4 http://www.buildingsmart-tech.org/specifications/ifc-overview 66 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 damages to an existing construction even before a 3D geometry is available and use them together with a construction topology ontology, like BOT in case of buildings or with other future infrastructure web ontologies. The use of Linked Data principles is based on open web standards published by the W3C such as RDF, RDFS, OWL and SPARQL. Linked Data offers several advantages when it comes to representing damages and the affected construction elements, such as the usage of HTTP URIs to identify objects which allow us to connect different disparate datasets, a standardized querying language (SPARQL), generic reasoning engines and the use of a shared data terminology (TBox) that provides definitions of classes and relations. Furthermore, RDF data represents a directed graph of connected nodes that allows for more flexible data structures. Linked Data technologies also allow the partitioning of one data model into a modular structure, consisting of multiple smaller interlinked data schemas or web ontologies. Smaller and more modular web ontologies are considered easier to understand for software developers and software applications can select which ontologies they support for their case. Several web ontologies have been developed for representing damages, damage classifica- tion and inferring implicit knowledge about them. Lee et al. [9] developed a web ontology utilized in a management system for querying specific defect cases based on construction conditions derived from a BIM model. Therefore, multiple instances, named as ‘cases’ are predefined in the ABox of the web ontology. Each of these instances belongs to a certain amount of classes that define defects as well as construction properties (e.g. component type or material) so that defect patterns could be concluded. However, the web ontology aims to use its instances mainly as categorization templates and does neither support modeling the topology of damage representations nor linking damages to construction components. To the best of our knowledge, the ontology of Lee et al. [9] is not publicly available online, which hinders its application. One of the most extensive approaches towards representing damages in an ontological model has been developed in the project MONDIS, which focuses on damage to cultural heritage and monuments [4]. The publicly available web ontology utilized in MONDIS5 allows modeling damage representations, as well as linking them to certain objects such as construction elements. Furthermore, the damage causation can be defined as well as additional properties for damages and affected components. Despite the possibility to define topological relations between damages and construction components, additional terminology to represent a detailed damage topology is missing. Examples of such terminology could be related to methods to define relations between adjacent damages or to group collections of smaller damages in a damaged area. Moreover, the web ontology contains concepts not related to damages such as classes to represent construction elements and therefore is not modular, which leads to a lesser compatibility with existing web ontologies from the LBD CG, such as BOT. To support the already existing Linked Data ontologies developed by the LBD group, a publicly available web ontology for a wide variety of damage representations related to different types of constructions has been developed in this research. It possesses a modular structure that is compatible with the LBD ontologies and will be described in detail in the following sections. 5 https://kbss.felk.cvut.cz/ontologies/2011/monument-damage-core.owl 67 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 3 Structure of the Damage Topology Ontology (DOT) The Damage Topology Ontology or DOT provides the necessary terminology and definitions (TBox) defined in OWL (Web Ontology Language) to support the modeling of generic damage representations and their topology, where documents and other information that is assembled during the different phases of inspection can be connected to each damage instance. Furthermore, a simple classification of each generic damage regarding the influence on the structural capability is supported. Thus, DOT works as a core ontology, which can be used for any type of damage or construction. The ontology is published on Github6 and has a public HTML documentation that can be accessed via the base URI7. 3.1 Topological Components DOT is designed for defining and linking damage representations to instances classified by other web ontologies that define a construction (e.g. instances of BOT classes for buildings). Thereby, the instances for damage representations are topologically structured based on damage definitions of different detail levels. The OWL classes and object properties used for this purpose are shown in Figure 1. Fig. 1: Overview of the topological classes and object properties defined by DOT. Damages can be modeled and assigned to affected components by using one of two subclasses of the class dot:Damage. Thereby, individual damage representations can be modeled by using the class dot:DamageElement and be linked to any in- stance of a construction component, e.g. bot:Element by using the object property dot:hasDamageElement. A detailed damage geometry could then be linked to the instance of dot:DamageElement at a later point in time by utilizing additional ontologies such as the Ontology for Managing Geometry (OMG)8 and File Ontology for Geometry formats (FOG)9 [17,3], or the Information Container for Data Drop (ICDD) [7]. The ICDD stores all used geometry files as well as other documents in a data container and links 6 https://github.com/Alhakam/dot 7 https://w3id.org/dot# 8 https://w3id.org/omg# 9 https://w3id.org/fog# 68 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 them with DOT instances via RDF linksets. However, modeling damages as detailed as possible is not always advisable, e.g. in the case of structural analysis, since using this discrete approach for a huge amount of damages could lead to intolerable computation times. Furthermore, modeling geometry of complex damage patterns manually, such as a collection of hairline cracks, is a time consuming activity. Therefore, a damaged area that represents a conceptual bounding box for multiple smaller damages can be modeled by using the class dot:DamageArea which can be linked to a more simplified geometry. Instances of dot:DamageArea can be linked to damaged construction components via the object property dot:hasDamageArea. To assign instances of dot:DamageElement to a dot:DamageArea instance, the object property dot:aggregatesDamageElement is used. However, it is also possible to model a dot:DamageArea instance without defining the individual dot:DamageElement instances it aggregates, if it is only used for a simplified damage representation. To define damages that have a physical connection with other damages, such as adjacent cracks, multiple instances of dot:DamageElement can be linked together with the object property dot:adjacentDamageElement. By utilizing this property, complex patterns of damages can be modeled. To refer to these patterns, e.g. for documen- tation or addition of metadata, a pattern of physically connected damages is represented by an instance of the class dot:DamagePattern in which instances of dot:DamageElement can be grouped via the object property dot:groupsDamageElement. The pattern is then connected to an instance of dot:DamageArea through the dot:aggregatesDamagePattern object property. In addition, by applying a reasoning engine to the ontology, instances of dot:DamageElement that are linked via dot:adjacentDamageElement can be derived through a property chain axiom as grouped elements in a dot:DamagePattern instance. Thereby, at least one of the connected instances of dot:DamageElement must be linked to the dot:DamagePattern instance. The same is achieved via a property chain axiom for adjacent instances of dot:DamageElement in a dot:DamageArea instance. 3.2 Documentation Data An important part of each inspection is a detailed documentation of all detected damages. Therefore, multiple documents e.g. photos, sketches, reports or test protocols are created during the various inspection and damage assessment phases. These documents can be stored in an ICDD and linked with the damage instances from DOT trough RDF linksets. To ensure, that the model can be used without being dependent on other data models, the class dot:ExternalResource is used for representing documents that describe damage related information. By using the data property dot:filePath the location in a file system can be referred. Instances of dot:ExternalResource can be linked to any instance node that represents a damage, a construction component or the whole construction via the object property dot:hasDocumentation. For non-damage related documents, classes and properties from other ontologies, like schema:DigitalDocument could be used. Additionally, small textual descriptions for damage information can be connected to the same instances by using the class dot:Description. Instances of dot:Description can be linked with various metadata as well as with the actual textual content of the description. For the latter the datatype property dot:descriptionContent should be used. For an enhanced management of multiple inspections that are processed through the construction lifecylce, the class dot:Inspection should be used for assigning detected instances of dot:Damage via the object property dot:belongsToInspection. In addition, 69 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 the corresponding inspector can be represented through an instance of dot:Inspector. Furthermore, the damage causation can be defined through the class dot:Causation and linked with an instance of dot:Damage. However, it is recommended to specify further subclasses of dot:Causation in domain specific extensions for practical application. 3.3 Classes for Structural Assessment In order to differentiate damages by their impact on structural capability, the two classes dot:StructuralDamage and dot:Defect have been implemented. While dot:StructuralDamage classifies every damage that influences the structural ca- pability, dot:Defect works as an opposite class and marks a damage as harmless to the structural properties of the construction. However, defects can still have an impact on the durability or traffic safety of the construction. It is recommended to use these classes always for instances of dot:DamageElement, to infer the structural impact of dot:DamageArea or dot:DamagePattern through aggregated instances. 3.4 Supported Extensions of DOT One main objective of the presented damage ontology is its modularity and extensibility. Therefore, DOT contains only generic damage concepts that are always applicable for describing any type of damage related to any type of structure. Other classes for classifying damages further or additional properties, e.g. for mechanical behavior or damage assessment, should be implemented in DOT ontology extensions. Therefore, three additional ontologies have been developed as sample extensions10 for DOT. The Concrete Damage Ontology (CDO) classifies damages in reinforced concrete and thus can be considered a specialized damage taxonomy. The DASB Ontology11 adds assessment parameters for damaged bridges based on DIN 1076 [1]. Lastly, the Damage Mechanics Ontology (DMO) defines reduced material parameters to describe the mechanical influence of damages during a structural analysis. In the current version only the smeared crack structural analysis approach is supported and thus the classes and properties of DMO are only applicable for instances of dot:DamageArea. In the following section, a demo data set is introduced applying the aforementioned DOT extensions. 4 Application of DOT To demonstrate the developed ontology and its extensions, two sample (ABox) datasets have been published in a part 112 and a part 213, together with example queries which 10 https://github.com/Alhakam/dot/tree/master/Extension 11 DASB is a German acronym and stands for: ”Deutsche Anweisung Straßeninformationsbank für (Ingenieur)Bauten” 12 https://raw.githubusercontent.com/Alhakam/dot/master/ABox- Examples/dotSampleData pt1.ttl 13 https://raw.githubusercontent.com/Alhakam/dot/master/ABox- Examples/dotSampleData pt2.ttl 70 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 were applied in a demo14 utilizing the SPARQL-Visualizer15. In this regard, DOT is ap- plied on two different ABox graphs. The first ABox dataset represents a structural frame that is modeled with BOT. The triples of the second ABox graph, which is used in section 5.2 for query application, represent a damaged bridge construction and therefore use ter- minology from DOT, CDO, DASB and DMO. In addition, BROT [8], an ontology that is currently under development, has been used for defining the topology and classification of bridges and their components. In this section, methods for creating and querying RDF data (ABox) using terminology from DOT and its extensions (TBox) are described. 4.1 Methods for creating damage representations with DOT DOT allows the digital representation of damages and assigning them to construction components. Therefore, several methods are possible for linking damages to such components and defining a damage topology. The methods, presented in this section are applied to an example structural frame named inst:structuralFrameA that aggregates two columns and one beam using the BOT terminology (see Listing 2). Listing 2: Definition of the structural frame and its aggregated components inst:structuralFrameA a bot:Element ; bot:aggregates inst:frameA-beam1 , inst:frameA-column1 , inst:frameA-column2 . inst:frameA-beam1 a bot:Element . inst:frameA-column1 a bot:Element . inst:frameA-column2 a bot:Element . Method 1: Listing 3 illustrates the most intuitive method for modeling damages, where an instance of dot:DamageElement is directly linked to a construction component. However this method should only be used for representing significant individual damages, such as big cracks or spallings and not for groups of smaller damages. Listing 3: Assigning a single damage element to a component # asserted triple inst:frame1-column1 dot:hasDamageElement inst:damageElement1 . # inferred triples inst:damageElement1 a dot:DamageElement , dot:Damage . inst:frame1-column1 dot:hasDamage inst:damageElement1 . Method 2: An alternative and often more time-efficient method for modeling collections of small damages in a damaged area, is using an instance of dot:DamageArea as damage representation and linking it to a component (See Listing 4). Listing 4: Assigning a damaged area to a component # asserted triple inst:frameA-column2 dot:hasDamageArea inst:damageArea2 . 14 https://madsholten.github.io/sparql-visualizer/?file=https://raw.githubusercontent. com/Alhakam/dot/master/ABox-Examples/dot-demo.json 15 https://github.com/MadsHolten/sparql-visualizer 71 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 # inferred triples inst:damageArea2 a dot:DamageArea , dot:Damage . inst:frameA-column2 dot:hasDamage inst:damageArea2 . Method 3: While it is allowed to define an instance of dot:DamageArea without aggre- gated instances of dot:DamageElement for a simpler damage recording, the method as shown in Listing 5 should be preferred. This method operates on two detail levels and links the simplified representation of a damaged area with its more detailed aggregated single damage representations. Listing 5: Assigning a damaged area with aggregated damages to a component # asserted triples inst:frame1-beam1 dot:hasDamageArea inst:damageArea3 . inst:damageArea3 dot:aggregatesDamageElement inst:damageElement3-1, inst:damageElement3-2 . # inferred triples inst:damageArea3 a dot:DamageArea , dot:Damage . inst:damageElement3-1 a dot:DamageElement , dot:Damage . inst:damageElement3-2 a dot:DamageElement , dot:Damage . inst:frame1-beam1 dot:hasDamageElement inst:damageElement3-1 , inst:damageElement3-2 . inst:frame1-beam1 dot:hasDamage inst:damageElement3-1 , inst:damageElement3-2 . Method 4: Instances of dot:DamageArea define damaged areas on the lowest detail level. Therefore, instances of dot:DamageArea should not be aggregated. To group damages at a higher detail level, an instance of dot:DamagePattern should be aggregated in a dot:DamageArea instance that defines a group of physically connected damages (see Listing 6). Instances of dot:DamagePattern should only be aggregated in instances of dot:DamageArea. Thus, they should not be directly linked to affected components. Listing 6: Assigning a damaged area with aggregated damage pattern to a component # asserted triples inst:frame1-beam1 dot:hasDamageArea inst:damageArea4 . inst:damageArea4 dot:aggregatesDamagePattern inst:damagePattern4 . # inferred triples inst:damageArea4 a dot:DamageArea , dot:Damage . inst:damagePattern4 a dot:DamagePattern . inst:frame1-beam1 dot:hasDamage inst:damageArea4 . Method 5: When defining an instance of dot:DamagePattern it is recommended to group instances of dot:DamageElement with it as shown in Listing 7. Instances of dot:DamageElement that are adjacent to each other can be inferred as aggregated by the same instance of dot:DamagePattern. Additionally all grouped instances of dot:DamageElement can be inferred as aggregated to the corresponding instance of dot:DamageArea. 72 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 Listing 7: Damage Pattern grouping multiple damages aggregated in a damaged area # asserted triples inst:frameA-column2 dot:hasDamageArea inst:damageArea5 . inst:damageArea5 dot:aggregatesDamagePattern inst:damagePattern5 . inst:damagePattern5 dot:groupsDamageElement inst:damageElement5-1 . inst:damageElement5-1 dot:adjacentDamageElement inst:damageElement5-2 , inst:damageElement5-3 . # inferred triples inst:damageArea5 a dot:DamageArea , dot:Damage . inst:damagePattern5 a dot:DamagePattern . inst:damageElement5-2 a dot:DamageElement , dot:Damage . inst:damageElement5-3 a dot:DamageElement , dot:Damage . inst:damageElement5-2 dot:adjacentDamageElement inst:damageElement5-1 . inst:damageElement5-3 dot:adjacentDamageElement inst:damageElement5-1 . inst:damageArea5 dot:aggregatesDamageElement inst:damageElement5-1 , inst:damageElement5-2 , inst:damageElement5-3 . inst:frameA-column2 dot:hasDamageElement inst:damageElement5-1 , inst:damageElement5-2 , inst:damageElement5-3 . inst:frameA-column2 dot:hasDamage inst:damageElement5-1 , inst:damageElement5-2 , inst:damageElement5-3 . Fig. 2: A structural frame with examples of the five methods to define damages in DOT 4.2 Queries for DOT and extensions Based on the available properties of DOT and its extensions, various queries can be applied on digital representations of damaged constructions that enhance the inspection and assessment process. Query 1: An essential part for the damage assessment of a construction is obtaining 73 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 information about all damaged construction components. Therefore, the query in Listing 8 selects all components that are affected by an instance of dot:DamageArea or dot:DamageElement. With an active reasoner, additional instances of dot:DamageElement that are aggregated in a dot:DamageArea will be returned, as they are now inferred to be directly connected to a damaged construction component. If available, the query will also return every instance of dot:DamagePattern that is aggregated by the dot:DamageArea or that is grouping individual dot:DamageElement instances. If this query would be used without reasoning, it would not return dot:DamageElement instances that are defined using modeling method 3 and 5. Listing 8: SELECT all damaged construction components (with reasoning) SELECT ?component ?hasDamage ?damage ?damagePattern WHERE { ?component ?hasDamage ?damage . FILTER (?hasDamage IN (dot:hasDamageArea , dot:hasDamageElement)) . OPTIONAL { ?damagePattern dot:groupsDamageElement ?damage } OPTIONAL { ?damage dot:aggregatesDamagePattern ?damagePattern } } Query 2: Defects such as surface damages or damaged coatings have almost no impact on the structural capability of a construction and thus do not need to be considered during a structural analysis. To filter for damages that influence the structural capa- bility, the query in Listing 9 selects all components that are affected by instances of dot:StructuralDamage. By using reasoning, aggregated dot:DamageElement instances related to instances of dot:DamageArea or dot:DamagePattern, are also evaluated. Listing 9: SELECT all structurally damaged construction components (with reasoning) SELECT ?component ?hasDamage ?structuralDamage WHERE { { # dot:DamageElement or dot:DamageArea ?component ?hasDamage ?structuralDamage. ?structuralDamage rdf:type dot:StructuralDamage . FILTER (?hasDamage IN (dot:hasDamageArea , dot:hasDamageElement)) } UNION { # dot:DamagePattern ?component dot:hasDamageArea ?damageArea . ?damageArea ?hasDamage ?structuralDamage . FILTER (?hasDamage = dot:aggregatesDamagePattern) ?structuralDamage rdf:type dot:StructuralDamage . } } Query 3: During inspections it is possible that a recorded damage could not immediately be classified as a defect or a structural damage. Throughout the subsequent damage assessment these undefined damage representations and their affected components need to be selected for a retrospective classification. A certified engineer can then add the correct class to these undefined damage instances. Therefore, the query in Listing 10 selects all components that are not affected by a known dot:StructuralDamage 74 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 instance and affected by at least one instance of dot:DamageElement, dot:DamageArea or dot:DamagePattern that is not also an instance of dot:Defect. Listing 10: SELECT all components with an undefined damage (with reasoning) SELECT ?component ?hasDamage ?undefinedDamage WHERE { # component should have at least one dot:DamageArea, dot:DamageElement # or dot:DamagePattern that is not of class dot:Defect { ?component ?hasDamage ?undefinedDamage. FILTER (?hasDamage IN (dot:hasDamageArea , dot:hasDamageElement)) } UNION { ?component dot:hasDamageArea ?damageArea1 . ?damageArea1 ?hasDamage ?undefinedDamage . FILTER (?hasDamage = dot:aggregatesDamagePattern) } FILTER NOT EXISTS { ?undefinedDamage a dot:Defect } # component has no damage individual that is of class # dot:StructuralDamage FILTER NOT EXISTS { { # dot:DamageElement or dot:DamageArea ?component dot:hasDamageArea|dot:hasDamageElement ?structuralDamage. } UNION { # dot:DamagePattern ?component dot:hasDamageArea ?damageArea . ?damageArea dot:aggregatesDamagePattern ?structuralDamage . } ?structuralDamage a dot:StructuralDamage . } } Query 4: To use queries referring to the taxonomy of damage, such as cracks in concrete, an extension compatible with DOT is required. Therefore, the CDO extension has been developed that defines a taxonomy for various damage types in reinforced concrete and additional properties to describe them (e.g. crack width or spalling area). By utilizing these extensions, more specific queries could be created, such as the query shown in Listing 11, where all cracks (instances of cdo:Crack) are selected that are aggregated in a specific instance of dot:DamageArea and that have a crack width of more than 3 mm. The query also returns the specific CDO crack type that was asserted. Listing 11: SELECT all cracks wider than 3 mm (with reasoning) SELECT ?damageElement ?crackType ?width WHERE { BIND(inst:D1_6 AS ?damageArea) ?damageArea dot:aggregatesDamageElement ?damageElement . ?damageElement rdf:type ?crackType. GRAPH { ?crackType rdfs:subClassOf cdo:Crack . 75 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 } FILTER (?crackType != cdo:Crack) ?damageElement cdo:crackWidth ?width. FILTER (?width > 3) } 5 Conclusions and Future Work In this research, a web ontology named DOT for defining digital damage representations and their topology is proposed. Besides topological terminology, DOT contains classes for documentation management and structural assessment. Using DOT requires a separate web ontology for representing the affected construction and its components (e.g. BOT or BROT). Furthermore, it is recommended to use DOT as a modular core ontology in combination with additional web ontologies as extensions when adding more specific information, e.g. taxonomies for various damage types or national assessment standards. In this regard, three example ontologies have been developed that extend DOT with a taxonomy for damages in reinforced concrete (CDO), mechanical parameters for damaged areas (DMO) and properties based on the German inspection standard DIN 1076 [1] (DASB). DOT damage instances can be linked to geometrical representations via specialized ontologies such as OMG-FOG or by using the ICDD approach for linking them to geometrical files and other documents via RDF linksets in a unified data container. Future research will focus, how existing ontologies such as MONDIS for defining damage causes, can be utilized for a combined use with DOT. Another important issue is the versioning of damages and how they evolve over time. Since damage representations from earlier inspections must not be removed to derive the damage progression, an ontology for version control of damages, similar as the Ontology for Property Management (OPM) [11] does for properties and OMG for geometries, should be developed. It should also be possible to link damages with repair and maintenance actions. 6 Acknowledgments This research work was enabled by the support of the Federal Ministry of Education and Research of Germany through the funding of the projects wiSIB (project number 01—S16031C). References 1. 1076:1999-11, D.: Engineering structures in the course of roads and paths - monitoring and testing (1999), [in German, original title: Ingenieurbauwerke im Zuge von Straßen und Wegen - Überwachung und Prüfung] 2. Bonduel, M., Rasmussen, M.H., Pauwels, P., Vergauwen, M., Klein, R.: A novel workflow to combine BIM and Linked Data for existing buildings. In: 12th European Conference on Product and Process Modelling (ECPPM). Copenhagen, Denmark (2018) 3. Bonduel, M., Wagner, A., Pauwels, P., Vergauwen, M., Klein, R.: Including Widespread Geometry Formats in Semantic Graphs Using RDF Literals. In: Proceedings of the European Conference on Computing in Construction (EC3 2019). Chania, Greece (In Press) 76 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 4. Cacciotti, R., Blaško, M., Valach, J.: A diagnostic ontological model for dam- ages to historical constructions. Journal of Cultural Heritage 16, 40–48 (2015). https://doi.org/10.1016/j.culher.2014.02.002 5. Gornig, M.: Structural data on production and employment in construction - Calculations for 2017 (2018), [in German, original title: Strukturdaten zur Produktion und Beschäftigung im Baugewerbe - Berechnungen für das Jahr 2017] 6. Hammad, A., Zhang, C., Hu, Y., Mozaffari, E.: Mobile Model-Based Bridge Lifecycle Management System. Computer-Aided Civil and Infrastructure Engineering 21(7), 530–547 (oct 2006). https://doi.org/10.1111/j.1467-8667.2006.00456.x 7. Iso/np 21597: Information container for data drop (icdd). Standard, International Organization for Standardization (2017) 8. Kozak, T.: Development of a method to transform semantic data of bridge models from IFC format into an ontology. Master’s thesis, Technische Universität Dresden, Germany (2019, unpublished) 9. Lee, D.Y., lin Chi, H., Wang, J., Wang, X., Park, C.S.: A linked data sys- tem framework for sharing construction defect information using ontologies and BIM environments. Automation in Construction 68(May), 102–113 (2016). https://doi.org/10.1016/j.autcon.2016.05.003 10. Pauwels, P., Terkaj, W.: EXPRESS to OWL for construction industry: To- wards a recommendable and usable ifcOWL ontology. Automation in Construc- tion 63, 100–133 (mar 2016). https://doi.org/10.1016/J.AUTCON.2015.12.003, https://www.sciencedirect.com/science/article/pii/S0926580515002435 11. Rasmussen, M.H., Lefrançois, M., Bonduel, M., Hviid, C.A., Karlshøj, J.: OPM: An ontology for describing properties that evolve over time. In: 6th Linked Data in Architecture and Construction Workshop (LDAC), CEUR Workshop Proceedings. London, UK (2018) 12. Rasmussen, M.H., Pauwels, P., Hviid, C.A., Karlshøj, J.: Proposing a Central AEC On- tology That Allows for Domain Specific Extensions. In: LC3 2017: Volume I - Proceedings of the Joint Conference on Computing in Construction (JC3). pp. 237–244. Heriot-Watt University, Heraklion, Greece (July 2017). https://doi.org/10.24928/JC3-2017/0153 13. Sacks, R., Kedar, A., Borrmann, A., Ma, L., Brilakis, I., Hüthwohl, P., Daum, S., Kattel, U., Yosef, R., Liebich, T., Barutcu, B.E., Muhic, S.: SeeBridge as next generation bridge in- spection: Overview, Information Delivery Manual and Model View Definition. Automation in Construction 90, 134–145 (jun 2018). https://doi.org/10.1016/J.AUTCON.2018.02.033 14. Scherer, R.J., Katranuschkov, P.: BIMification: How to create and use BIM for retrofitting. Advanced Engineering Informatics 38, 54–66 (2018). https://doi.org/10.1016/j.aei.2018.05.007 15. Tanaka, F., Tsuchida, M., Onosato, M., Date, H., Kanai, S., Hada, Y., Nakao, M., Kobayashi, H., Hasegawa, E., Sugawara, T., Oyama, T.: Bridge Information Modeling based on IFC for supporting maintenance management of existing bridges. Tampere (2018) 16. Volk, R., Stengel, J., Schultmann, F.: Building Information Modeling (BIM) for existing buildings — Literature review and future needs. Automation in Construction 38, 109–127 (2014). https://doi.org/10.1016/j.autcon.2013.10.023 17. Wagner, A., Bonduel, M., Pauwels, P., Rüppel, U.: Relating Geometry Descriptions to its Derivatives on the Web. In: Proceedings of the European Conference on Computing in Construction (EC3 2019). Chania, Greece (In Press) 77