Relative Location Ontology: An Ontological Model for Representing Directional Topological Relationships between Spatial Entities in Oriented Space Anne Göbels1,* , Jakob Beetz1 1 Chair of Design Computation, RWTH Aachen University, Schinkelstr. 1, 52062 Aachen , Germany Abstract This paper introduces the Relative Location Ontology (RELOC), which enables the expression of the spatial relationship between two entities using directional-topological terms. The ontology is designed to be compatible with the natural language-based approach of describing relative locations, enabling the conversion of existing location descriptions into structured spatial graph representations. The ontology provides directional, axis-related properties (e.g., longitudinal axis relations: front, center, rear) and topological properties (e.g., meet, contained in, intersect). These properties are finally merged into combined properties (e.g., containedInFront) to reflect the spatial information of statements like ’A is in the front part of B’. The application context of the RELOC Ontology is the processing of existing damage documentation of bridges. By converting existing textual bridge inspection datasets into structured spatial graphs, the ontology contributes to integrating legacy data into enhanced bridge management approaches. Keywords Ontology, Linked Data, Natural Language Localisation, Damage Documentation Processing, Bridge Maintenance, 1. Introduction Directional terms are commonly used in natural language (NL) to communicate about space. Terms such as "left", "right", "above", "below", "in front of", and "behind" only require the deter- mination of the viewing direction to define an entire reference space. Additionally, topological terms such as "next to", "within", and "between" convey a spatial arrangement and approxi- mate distance of two entities. These terms are universally understood by humans and can communicate spatial relationships effectively and concisely. As this type of spatial communication does not rely on external reference models, it is also used for maintenance processes in the Architecture, Engineering, Construction, and Operation (AECO) industry, where often no geometric models are available [1]. Also, during the bridge inspection process in Germany, natural-language-based directional terms are used to describe damage locations at individual components [2]. The documented damage location descriptions are primarily intended for human commu- nication, not automated processing or analysis. However, for the digital transformation and LDAC 2024: 12th Linked Data in Architecture and Construction Workshop, June 13–14, 2024, Bochum, Germany $ goebels@dc.rwth-aachen.de (A. Göbels); beetz@dc.rwth-aachen.de (J. Beetz)  0000-0002-6175-6499 (A. Göbels); 0000-0002-9975-9206 (J. Beetz) © 2024 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). CEUR ceur-ws.org Workshop ISSN 1613-0073 Proceedings 91 modernisation of bridge maintenance processes, it is essential to make the documented in- spection information accessible and compatible with state-of-the-art techniques like Building Information Modelling (BIM). To achieve this transformation, the implicit spatial informa- tion of the textual damage documentation must be extracted and converted into an explicit machine-readable structure. Since existing assets usually involve many heterogeneous resources, Linked Data technologies are suitable for structuring and linking this data. Web ontologies enable the representation of the assets as defined (topological) graph structures. In the bridge maintenance domain, the Bridge Topology Ontology (BROT) [3] and the Damage Topology Ontology (DOT) [4] exist, which can represent the bridge structure and its damage areas as topological graphs. However, they cannot depict the spatial relationships that natural language descriptions can express and thus cannot directly be used to reflect the information of the textual data. To close this gap, we have developed the Relative Location Ontology (RELOC), which is compatible with the axis-based, directional approach of natural-language-based localisation. Due to this compatibility, the ontology can convert existing (damage) location descriptions into defined spatial relationships. Furthermore, it enables the creation of spatial building/bridge graphs that can be queried using directional terms. Thus, the RELOC Ontology allows for the automatic processing of spatial statements such as "the third beam from the right" and "damage at the rear, left side surface". Thereby, the RELOC Ontology manages to convert the existing textual bridge data sets into structured spatial graphs. Besides the advantages of spatial analysis (of approx. 40,0000 existing bridge data sets [5]), the ontology facilitates the integration of existing inspection data into modern object-oriented applications. This paper outlines the concept and structure of the RELOC Ontology and demonstrates its practical application in processing existing inspection data. As natural language location descriptions can find application in various domains, we have chosen not to restrict the RELOC Ontology to a specific domain or model it as an extension of an existing ontology such as BROT. This approach ensures that the ontology can be easily reused. Nevertheless, we provide examples of how the RELOC Ontology can be aligned with existing ontologies used in the bridge and maintenance sector. 2. Related Work Spatial relations have been explored in various works, with topology primarily addressed in the field of geography and Geographic Information Systems (GIS). One of the fundamental works in this area was carried out by Egenhofer and Franzosa, developing the 4-Intersection model of binary point-set-topological relations in two-dimensional space [6]. This model compares the interior and boundary of two objects to define eight different topological relations: Disjoint, Meet, Contains, Inside, Covers, Covered by, Overlap, and Equal. Based on that, the extended 9-Intersection model was developed, allowing for more precise distinctions by considering the exterior of objects as well [7]. The approach was adapted to 3D space by Zlatanova, who also investigated the relationships 92 between objects with different dimensionality [8]. However, while these relationships can be technically defined, they do not always have equivalents in natural language [9]. In research related to image recognition, directional spatial relations are considered in the work of Freeman, defining a set of primitive spatial expressions (left of, right of, in front of, behind, above, below, near, far, inside, outside, etc.) that humans use to encode the relations of objects detected in images [10]. Hudelot et al. developed an ontological model to represent these spatial relations in the context of image recognition in combination with a fuzzyness approach [11]. While spatial relations have been extensively studied in these fields, the approaches focus on deriving topological or directional relations from given spatial structures (depicted in images or maps) and less on deriving spatial arrangements based on these relations. Moreover, most of the works presented are limited to two-dimensional space. However, the RELOC Ontology can build on these approaches and adopt their fundamental concepts. Topological relations are also an integral part of the ontologies of the Linked Building Data (LBD) domain. The Building Ontology Topology (BOT)[12] defines containment, adjacency, and intersection relations between building components and zones, while the BROT Ontology [3] adapts these relations for bridge components and zones. The DOT Ontology [4] offers a model to describe topological relations between components, damage areas, damage patterns, and damage elements. However, none of these models include directional information. The Area of Interest Ontology (AOI)[13] is an auxiliary ontology for damage documentation that includes directional information. The AOI ontology enables the definition of subareas of a specific component surface, reflecting the damaged areas. It defines five different area types: the lower, central, and upper area for the vertical axis and the central and peripheral area for the horizontal axis. Additionally, it includes definitions of edge and surface (top, bottom, periphery) and distinguishes between interior and exterior. However, the directional information is kept general, with no distinction between right and left, and the longitudinal axis is not considered as it is only a two-dimensional approach. Moreover, defining the particular surface of the component must happen with external references (e.g., "north side") and is not part of the model. All LBD ontologies presented share the common objective of recording and analysing spatial data in a structured way (DOT, AOI) or representing complex spatial structures in a simplified way (BOT, BROT). However, compatibility with natural language localisation is not within the scope of these ontologies. Thus, the proposed RELOC Ontology aims to fill this gap by enabling the use of directional expressions in conjunction with these topological models. In this way, existing natural-language-based data sets can benefit from the methods provided by these ontologies supporting enhanced data management. 3. Relative Location Ontology The RELOC Ontology was created using the seven-step method described by Noy and Mcguin- ness [14]. The first step involved defining the domain and scope of the ontology. In section 3.4, we introduce the main idea and terminologies of the ontology. We then describe the technical implementation in section 3.5. Based on the analysis of existing ontologies in section 2, we outline an alignment of them with the RELOC Ontology and finally demonstrate its application. 93 3.1. Concept and Scope The RELOC Ontology is designed to describe the topological and directional relations between two spatial objects. Its primary goal is to transfer the spatial information of natural-language- based location terms into a formally defined relation that can enrich existing, non-geometrical data of a spatial asset or concept with structured spatial information. The key concept of the RELOC Ontology is the separate definition of spatial relationships per axis. This creates compatibility with natural language spatial descriptions, as these expressions are only valid for a specific axis. For instance, if you want to precisely describe a position in three-dimensional space, you have to combine axial spatial expressions, such as "the upper right corner at the front". In addition, this concept enables spatial relationships that refer only to a specific feature of the reference object, expressing, for example, the same height or a particular alignment. Since only one spatial axis is considered at a time, the ontology can be used for 2D and 3D objects (e.g., component and damage areas). The prerequisite is defining a common viewing direction/orientation so all objects share the same axis reference system. Another essential characteristic of the RELOC Ontology is the combination of topological and directional terms. This approach is intended to reflect the variety of NL expressions and also to decompose them into their topological and directional aspects, contributing to deriving complex spatial structures from these expressions. 3.2. Application Domain The primary development and application context of the RELOC Ontology is the bridge main- tenance domain (see section 4). The inherent orientation of a bridge structure allows the convenient use of directional location descriptions to locate damage areas or describe the po- sition of components. However, these descriptions are primarily intended to be read by the inspectors to find the damage areas on site. Thus, the motivation for developing the RELOC Ontology is to translate existing, implicit, textual location descriptions of bridge damage into an explicit, structured spatial relationship between component/bridge and damage. Since the overall process should not depend on externally created geometry models (which often do not exist), we also use the ontology to define the spatial relation between the bridge components. Combined with the concepts of the BROT ontology, a spatial graph of the bridge can be created that is used to process the damage data. Thus, the RELOC Ontology not only allows us to be independent of external models but also creates a graph that can be spatially queried with natural language terms, which is necessary for processing the damage location descriptions. The application context also determines the expressiveness and accuracy of the RELOC Ontology. Its information cannot exceed that available in natural language. For example, the topological terms are intended to depict the difference between "in front of" and "in the front" and not to infer exact geometric-mathematical values. However, the ontology itself is not limited to the bridge maintenance domain. Thus, it can be used to express the spatial relations between any objects that share a common oriented space. 94 reloc:2DTopologicalRelation reloc:hasRelative A SpatialRelationTo B reloc:meet reloc:intersect reloc:containedIn reloc:equal A B A B A B reloc:front reloc:longitudinalAxisRelation reloc:meetFront reloc:intersectFront reloc:containedInFront Parallel to reference direction „directly in front of“ „intersects with „contained in front of“ the front of“ AB A B reloc:equal reloc: longitudinal Reference (viewing) direction reloc:containedIn Longitudinal Center LongitudinalCenter „contained in longitudinal „same longitudinal central area of“ center and lenght as“ B A B A B A reloc:rear reloc:meetRear reloc:intersectRear reloc:containedInRear „directly behind“ „intersects with the „contained in front back of“ area of“ A B A B A B reloc:left Orthogonal to reference direction reloc:transversalAxisRelation reloc:meetLeft reloc:intersectLeft reloc:containedInLeft reloc:directionalRelation „directly left of“ „intersects with the „contained in left side of“ left area of“ A B A B reloc: transversal Reference (viewing) direction reloc:containedIn reloc:equal Center TransversalCenter Transversal „contained in transversal central area of“ „same transversal center and width as“ B A B A B A reloc:right reloc:meetRight reloc:intersectRight reloc:containedInRight „directly right of“ „intersects with the right side „contained in right area of“ of“ reloc: reloc: reloc: B A A containedIn reloc:top meetTop intersectTop Top „directly above“ „intersects with B „contained in reloc:verticalAxisRelation A the top side of“ B upper area of“ A reloc: B reloc: containedIn vertical A VerticalCenter „contained in reloc:equal Center vertical central Vertical B area of“ „same vertical center and height as“ reloc: reloc: A reloc: B intersect B containedIn reloc:bottom meetBottom Bottom Bottom B „directly under“ A „intersects with A „contained in the bottom side of“ lower area of“ Figure 1: Graphical overview table of the RELOC Ontology properties 3.3. Competency Questions When applying the Relative Location Ontology, it is possible to make spatial queries, answering, for example, the following competency questions (CQ): • CQ1: What is the vertical, transversal or longitudinal relation between two entities? • CQ2: Do axis-related extents of two entities have a topological adjacency, containment, intersection, or equality relationship? • CQ3: What are the directional and topological properties of the natural language term "A is at the beginning of B?" 95 3.4. Terms and Design of the Ontology The core of the RELOC Ontology is the property has Relative Spatial Relation To, which relates two spatial entities to each other. The domain and range for that property is the class Spatial Entity, which can represent any kind of entity that has spatial features and can be located in two- or three-dimensional space. In the application context, these entities can be individual component or damage objects. The idea of the ontology is to further specify this higher-level relationship by defining a hierarchy of sub-relations, where the final level of properties expresses a directional topological relation between the referencing entity and its reference entity. In the following, the referencing entity is called A, and its reference entity is called B. Since the ontology defines axis-dependent relationships, the terms A and B do not refer to entire (2D- or 3D-) objects but only to the areas/extensions of the objects on the specific axis. As displayed in figure 1, the ontology contains 2D topological relations and directional relations. The topological relations are subdivided into the four categories meet, intersect, contained in and equal, based on the terms defined in the 4-Intersection model [6] (see section 2). The meet property expresses an adjacency relationship between A and B. The intersect relationship states A and B are partly overlapping, and the contained in relationship declares that A is inside of B. The equal relationship means that A and B are identical. The categories covers/covered by and disjoint of the 4-Intersection model are not in the scope of the RELOC Ontology, as the first ones are too specific to be derived from a natural-language description, and the latter is too broad to derive a spatial dependency from it. The contains relation, as opposite from contained in, is (currently) not part of the ontology since it cannot be combined with a directional location term in our approach. The directional relations are separated by axis reference, leading to longitudinal axis relation, transversal axis relation and vertical axis relation, where the reference axis/viewing direction of the described space corresponds with the longitudinal axis direction. Each of these properties has three sub-properties, dividing the space related to the respective axis into one central area and two peripheral areas (front, longitudinal center, rear; left, transversal center, right; bottom, vertical center, top). The final level of properties combines each directional with each topological relation (where applicable), leading to 24 expressive spatial relations. The directional information is to be interpreted referring to the target/reference object (B). For example, the relation A meetFront B means "A is in front of B", and A containedInRight B indicates that "A is inside the right area of B". 3.5. Technical Implementation The technical implementation of the RELOC Ontology is made using the Web Ontology Language (OWL)1 . The namespace for the ontology is https://w3id.org/reloc#, and the suggested prefix is reloc. A preliminary ontology specification draft can be found here 2 . 1 http://www.w3.org/2002/07/owl 2 https://w3id.org/reloc 96 reloc: Spatial Entity reloc : https://w3id.org/reloc# rdfs:domain rdfs:range owl: http://www.w3.org/2002/07/owl# rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# reloc:hasRelativeSpatialRelationTo rdfs: http://www.w3.org/2000/01/rdf-schema# reloc:2DTopologicalRelation reloc:directionalRelation reloc:meetFront "directly in front of" owl:SymmetricProperty reloc:meetRear "directly behind" reloc:longitudinalAxisRelation reloc:meet reloc:meetLeft "directly left from" reloc:front reloc:meetRight reloc:longitudinalCenter "directly right from" reloc:meetBottom reloc:rear "directly under" reloc:meetTop "directly on top of" reloc:intersectFront "intersects with front side of" reloc:intersectRear owl:SymmetricProperty "intersects with rear side of" reloc:intersectLeft reloc:intersect "intersects with left side of" reloc:transversalAxisRelation reloc:intersectRight reloc:left "intersects with right side of" reloc:intersectBottom reloc:transversalCenter "intersects with bottom of" reloc:right reloc:intersectTop "intersects with top of" reloc:containedInFront "contained in front area of" reloc:containedInLongitudinalCenter "contained in longitudinal central area of" reloc:containedInRear "contained in rear area of" owl:TransitiveProperty reloc:verticalAxisRelation reloc:containedInLeft "contained in left area of" reloc:top reloc:containedIn reloc:containedInTransversalCenter "contained in transversal central area of" reloc:verticalCenter reloc:containedInRight reloc:bottom "contained in right area of" reloc:containedInTop "contained in upper area of" reloc:containedInVerticalCenter "contained in vertical central area of" reloc:containedInBottom "contained in lower area of" owl:TransitiveProperty, owl:Class owl:SymmetricProperty reloc:equalLongitudinal rdfs:subPropertyOf "same long. center and length as" rdf:type reloc:equal reloc:equalTransversal "same transv. center and width as" owl:inverseOf owl:ObjectProperty reloc:equalVertical rdfs:label "same vertical center and height as" Figure 2: Technical diagram of the RELOC Ontology 97 rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# reloc: http://w3id.org/reloc# rdfs: http://www.w3.org/2000/01/rdf-schema# skos: http://www.w3.org/2004/02/skos/core# reloc:front :Abutment rdf:type owl:ObjectProperty ; The front abutment rdfs:label "front"@en ; reloc: containedIn rdfs:label "Vorne"@de ; Front skos:altLabel "Anfang"@de, "beginning"@en, The abutment at the "Vorderseite"@de, "front side"@en, beginning of the bridge :Bridge rdfs:subPropertyOf reloc:longitudinalAxisRelation . Figure 3: Example of alternative labels for a directional property and their use in the application The spatial relations are implemented as owl:ObjectProperty objects and the hierarchy is expressed by rdfs:subPropertyOf relations. Figure 2 displays the full technical diagram of the RELOC Ontology. Each property’s label(s) express their equivalent in natural language terms. This is intended to explain the meaning of the property and to create a mapping of the ontology to natural language. To extend this mapping to different spatial expressions, which would be represented by the same property in the ontology, we used the SKOS vocabulary 3 to define alternative labels. Figure 3 shows an example of using alternative labels for the property reloc:front and their use for processing different textual expressions which refer to the same location (see also figure 7). The label definitions are, therefore, a central component of the ontology that enables the processing of textual descriptions. 3.5.1. Functional Extension Since the RELOC Ontology was developed in the context of processing existing bridge docu- mentation data, we added a small functional extension that covers an alternative method that is 3 http://www.w3.org/2004/02/skos/core owl:ObjectProperty owl:DatatypeProperty owl:Class reloc:hasOffsetValue xsd:float reloc: rdfs:domain reloc:Relative Spatial reloc:hasRelative rdfs:range rdfs:range Location rdfs:domain Entity LocationWithOffset WithOffset reloc:hasOffsetValueUnit xsd:string owl:disjointWith reloc:hasRelativeSpatialRelationTo rdfs:range TBox ABox "28 m from the front of the structure" "28.0"^^xsd:float "28m vom Bauwerksanfang" reloc:hasOffsetValue :Damage reloc:hasOffsetValueUntit "m"^^xsd:string reloc:hasRelativeLocationWithOffset :blankNode Area reloc:containedInFront :Bridge Figure 4: Functional extension of the ontology to define offsets to locations 98 reloc:containedInFront reloc:intersectFront Object A reloc:containedInRight Object B Object A reloc:containedInRight Object B reloc:meetTop reloc:containedInTop brot:adjacentZone / brot:adjacentComponent bot:adjacentZone / bot:adjacentElement bot:intersectsZone / bot:intersectingElement bot: https://w3id.org/bot# brot: https://w3id.org/brot# reloc:containedInFront reloc: https://w3id.org/reloc# Object A reloc:containedInRight Object B Legend: Vertical Axis reloc:containedInTop Longitudinal Axis Transversal Axis brot:containsZone / brot:containsComponent bot:containsZone / bot:containsElement Figure 5: Derivation of three-dimensional topological relations from RELOC property combinations used for locating damage. The extension enables the expression of a defined/measured distance of a location to a reference location. For instance, the damage location "28m from the front of the structure" references a directional area of a specific spatial entity and then defines a distance to that location. The ontological structure for this localisation approach is shown in figure 4. The class reloc:RelativeLocationWithOffset is introduced, being in the domain of the gen- eral reloc:hasRelativeSpatialRelationTo property to define the reference location (e.g., re- loc:containedInFront), and of the datatype property reloc:hasOffsetValue to define the distance (e.g., "28.00" xsd:float). The documented dimension of the distance value is stored as a string using the property reloc:hasOffsetValueUnit (e.g., "m"). 3.5.2. Alignment with Existing Ontologies As the main class of the ontology, "reloc:SpatialEntity", can represent any kind of spatial concept or object that can be physically located, the alignment with other ontologies is straightforward. For our use case in the bridge maintenance domain, we have explicitly aligned the DOT, BOT, and BROT Ontology with the RELOC Ontology by defining their respective main classes (bot:Element, bot:Zone, brot:Component, brot:SpatialZone, dot:DamageArea, dot:DamageElement, dot:DamagePattern) as subclasses of reloc:SpatialEntity. We stored these definitions in a small alignment module 4 . Besides the direct class alignment, it is also possible to derive axis-independent topological relationships defined in the BOT and BROT Ontology if two spatial entities are related by a RELOC property for each axis. Figure 5 illustrates spatial arrangements, their definition using the RELOC Ontology and possible equivalent topological relationships of the BOT or BROT ontology, depending on the class types of the related entities. 4 https://annegoebels.github.io/reloc/Alignment.ttl 99 Front Substructure Girder and its sub-components Equal Transversal Equal Longitudinal ContainedIn Top Girder Equal Girder Transversal Deck MG "same width as" MG Girder Meet Left Main Girder Meet Meet ContainedIn Bottom Bottom Bottom Abutment "under" Abutment or ContainedIn Right or Pierzone Pierzone ContainedIn Intersect Front Longitudinal Contained In Front ""intersects with the front Center ""is contained in the side of" front area of" Span firstSpan Figure 6: Application of RELOC properties to define spatial relations between bridge components 4. Application To apply the RELOC Ontology, first, the viewing direction must be determined, which defines the orientation of the space to be described. In our use case of processing existing bridge inspection data, this direction was already implicitly part of the documented spatial descriptions. In the bridge maintenance domain, it is usually a predefined "inspection direction," which refers to a direction expressed by city references or cardinal points. However, the direction definition is not in the scope of the RELOC Ontology and must be defined externally. We applied the ontology to define the spatial relationships between individual bridge com- ponents and between components and damage areas. The original bridge maintenance data sets were primarily stored in a relational database. In previous steps, we converted these data records into Resource Description Format (RDF) graphs [15] [16]. Figure 7 shows as input data a (simplified) example of a converted damage entry of a maintenance data set in RDF (the translation in the brackets is only inserted for clarification). Based on the converted bridge maintenance graph, we created a structural bridge graph containing individual components using the BROT and Bridge Components Ontology (BRCOMP) 5 . As described in section 3.5.2, we have aligned these ontologies with the RELOC Ontology, thus, all bridge component and damage area instances created also belong to reloc:SpatialEntity. We spatially linked the components to each other using the RELOC Ontology, based on implicit spatial knowledge of typical bridge structures (e.g., "The substructure is under the superstructure", "The caps are right and left of the roadway", etc.). Figure 6 shows, for example, these "typical" spatial relationships of a front substructure to a girder (left illustration) and the spatial composition of a main girder element (right illustration). The resulting spatial bridge graph (see upper part of figure 7) subsequently served as the basis for processing the damage locations. This workflow was separated into two steps: finding the damaged component based on its type and position information and spatially linking the 5 https://w3id.org//brcomp 100 rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# brot: https://w3id.org/brot# Graph rdfs: http://www.w3.org/2000/01/rdf-schema# reloc: https://w3id.org/reloc# reloc:front brcomp: https://w3id.org//brcomp# skos: http://www.w3.org/2004/02/skos/core# [rdfs:label: "Front", "Beginning"] brcomp:Abutment brcomp:Girder brot:Bridge rdfs:subPropertyOf TBox a ABox a a reloc:equalTransversal reloc:equalTransversal :Abutment 01 reloc:containedInFront :Girder reloc:equalLongitudinal :Bridge reloc:meetBottom reloc:containedInTop Input Output (Converted db tables as RDF Graph) SPARQL Query PREFIX asb: SELECT DISTINCT ?abutment PREFIX asbkey: PREFIX : WHERE{ ?abutment a brcomp:Abutment; :Damage01 ?relocProperty ?refObject. :Abutment 01 a asb:Schaden [Damage] ; asb:Bauteil [component] asbkey:Widerlager [Abutment] ; ?relocProperty rdfs:subPropertyOf ?axisRelation. asb:Ortsangabe [location] asbkey:Vorne [front] , ?axisRelation rdfs:subPropertyOf* reloc:directionalRelation. asbkey:Vorderseite [front side] , ?axisRelation rdfs:label | skos:altLabel ?label. asbkey:Unten [bottom] , FILTER (regex (?label, 'front') || regex (?label, 'beginning') ) asbkey:Links [left] . FILTER EXISTS { {?refObject reloc:equalLongitudinal | reloc:containedInFront | The abutment The front reloc:intersectFront ?bridge. at the beginning abutment ?bridge a brot:Bridge.} UNION of the bridge {?refObject a brot:Bridge} } } Figure 7: Querying the bridge graph for a component based on a textual location description (The input data comes from the converted maintenance graph and is not written as free text. However, in the following illustrations, we have placed the textual information as continuous text in speech bubbles for easier comprehensibility.) damage area object to this component. Figure 7 shows an example of the first step, searching the bridge graph for the front abutment. There were different possibilities to define the respective query pattern. To keep the query flexible for different textual inputs, we decided to compare the textual term used in the bridge documentation with the labels of the property we are searching for. The figure actually combines two examples, showing a query based on two different textual expressions to illustrate the functionality of the alternative labels, explained in section 3.5. As the component was found, the location terms describing the damage area were processed. As we worked with semi-structured data of the bridge documentation and had a limited, predefined collection of location terms, we used a mapping table that defines which terms are converted into which RELOC properties. Simplified parts of this table are displayed in figure 8 and 9. For each damage of the bridge documentation data set, we created a damage area instance of the dot:DamageArea class. This damage instance was then linked to the found component by the RELOC properties taken from the mapping table based on the documented location terms (see figure 8). 101 brcomp: https://w3id.org/brcomp# Input Graph reloc: https://w3id.org/reloc# Mapping Table : dot: https://w3id.org/dot# Terms to properties :Abutment 01 dot:DamageArea brcomp:Abutment Location term RELOC property front side containedInFront TBox ABox a a Damage is at the low containedInBottom reloc:containedInLeft front abutment; left containedInLeft :Damage 21 reloc:containedInFront :Abutment 01 in the lower, left area of the front side.. reloc:containedInBottom dot:hasDamageArea Figure 8: Transfer of a damage location description to graph representation using the RELOC Ontology. brcomp: https://w3id.org/brcomp# brstr:https://w3id.org/brstr# Graph reloc: https://w3id.org/reloc# dot: https://w3id.org/dot# Mapping Table : Terms to properties brcomp:Girder :GirderDeck dot:DamageArea brstr:Span Deck Location term RELOC property TBox front containedInFront Damage is at the ABox a reloc:containedInLeft a a Girder Deck, in the low containedInBottom front area of the second span. :Damage 21 reloc:containedInBottom :GirderDeck left containedInLeft At the left of the bottom side.. reloc:containedInFront :Span 02 dot:hasDamageArea Figure 9: Transfer of a damage location description to graph representation using the RELOC Ontology, having two different reference objects As the created links only express spatial relations, we additionally linked the component semantically to the damage area by dot:hasDamageArea. This distinction is important, as a damage area can be located in reference to multiple different components or spatial zones, as can be seen in figure 9. Once all damage entries have been processed, an object-oriented, spatially structured bridge maintenance graph is created from natural-language-based textual information, allowing spatial insights to be gained. 5. Discussion The application of the RELOC Ontology enables the retrieval of information as formulated in the competency questions (see section 3.3). Through the sub-property relationships of the final RELOC properties to their directional and topological super-properties and the division of the directional properties into the three spatial axes, the different qualities/types of a relationship can be easily queried. Thus, Q1 and Q2 can be easily implemented by requesting or determining the super-properties of a specific relationship in a SPARQL query. By defining (alternative) natural language labels for the relationships, the first part of Q3 (What are the directional and topological properties of the natural language term "A is at the beginning of B" ?) can be answered. The term "at the beginning of" refers to the longitudinal axis-related property "front". However, the precise topological relationship cannot be derived directly from this, as the NL term leaves room for interpretation. By including the object types of A and B into the query (e.g., A = Damage, B = Component), a topological relationship can be 102 inferred (e.g., contained in), but this cannot be inferred solely from using the RELOC Ontology. Therefore, if the data set should be queried using free text input or a direct conversion from text to properties (instead of a mapping table) is desired, the RELOC Ontology must be considered in its interaction with the other ontologies used. Combining topological and directional relations in one property effectively implements a complex spatial relationship without creating multiple triples. This aspect allows easy reverse spatial queries, respectively, inferring reverse spatial relations of objects (e.g.: A meetLeft B == B meetRight A), supporting flexible spatial queries/entry points to the data. This merging can be criticised as the higher-level directional properties (front, right, top, etc.) do not really describe spatial relations but indicate locations. Thus, more precisely, they should be defined as classes instead of properties, as seen in the AOI ontology [13]. For our application, however, the simplicity of only one combined property outweighs the (more accurate) combination of classes and properties. We demonstrated the applicability and benefits of the RELOC Ontology for the use case of processing existing text data from bridge maintenance data sets. However, we are aware that it is a simplified representation of complex spatial relationships. It is primarily suitable for expressing rectangular relationships and cannot express diagonal/oblique positions to each other. Additionally, the ontology’s informative value is limited for components with complex geometries lacking clearly defined lateral surfaces. 6. Conclusion and Outlook This paper has introduced the Relative Location Ontology, which was developed to convert natural-language-based location descriptions into structured spatial relationships. The ontology is characterised by the combined specification of directional and topological relationships and the separate consideration of individual axes to ensure compatibility with natural-language expressions. We have demonstrated how the ontology contributes to transforming textual, semi-structured datasets of bridge maintenance into RDF graphs that can be spatially queried and are structurally compatible with object-based data models. By that, the ontology enables the straightforward integration of legacy data into modern data structures and workflows. In the following stage, we aim to implement this conversion process for a larger number of datasets (approx. 10,000 bridges) to enable comprehensive spatial analyses. By that, we want to open up the vast dataset of existing bridge documentation as a knowledge and experience database. In addition, the converted data sets can be used as training data to extend the processing of spatial natural language data to unstructured data sets in the future. Acknowledgments This research is part of the Raumlink project funded by the German Research Foundation (DFG) – Project number 501812634. 103 References [1] V. Saback, C. Popescu, T. Blanksvärd, B. Täljsten, Asset Management of Existing Concrete Bridges Using Digital Twins and BIM: A State-of-the-Art Literature Review, Nordic Concrete Research 66 (2022) 91–111. doi:10.2478/ncr-2021-0020. [2] Bundesministerium für Verkehr, Bau und Stadtentwicklung, Abteilung Straßenbau., ASB- ING 2013 Anweisung Straßeninformationsbank Segment Bauwerksdaten, 2013. [3] A.-H. Hamdan, R. J. Scherer, Integration of BIM-related bridge information in an ontological knowledgebase, in: Proceedings of the 8th Linked Data in Architecture and Construction Workshop - (LDAC), CEUR-WS, 2020, pp. 77–90. [4] A.-H. Hamdan, M. Bonduel, R. J. Scherer, An ontological model for the representation of damage to constructions, in: Proceedings of the 7th Linked Data in Architecture and Construction Workshop - (LDAC), CEUR-WS, 2019, pp. 64–77. [5] Bundesanstalt für Straßenwesen, Brückenstatistik, 2024. URL: https://www.bast.de/DE/ Statistik/Bruecken/Brueckenstatistik.pdf?__blob=publicationFile&v=21. [6] M. J. Egenhofer, R. D. Franzosa, Point-set topological spatial relations, Interna- tional journal of geographical information systems 5 (1991) 161–174. doi:10.1080/ 02693799108927841. [7] M. J. Egenhofer, D. M. Mark, J. e. Herring, The 9-Intersection: Formalism and Its Use for Natural-Language Spatial Predicates (94-1) (1994). URL: https://escholarship.org/uc/item/ 5nj6647c. [8] S. Zlatanova, 3D GIS for Urban Development, number no. 69 in ITC Dissertation, Interna- tional Institute for Aerospace Survey and Earth Sciences ; Institute for Computer Graphics and Vision, Graz University of Technology, 2000. [9] G. Gröger, B. George, Geometry and Topology, in: W. Kresse, D. Danko (Eds.), Springer Handbook of Geographic Information, Springer International Publishing, 2022. [10] J. Freeman, The modelling of spatial relations, Computer Graphics and Image Processing 4 (1975) 156–171. doi:10.1016/S0146-664X(75)80007-4. [11] C. Hudelot, J. Atif, I. Bloch, Fuzzy spatial relation ontology for image interpretation, Fuzzy Sets and Systems 159 (2008) 1929–1951. doi:10.1016/j.fss.2008.02.011. [12] M. H. Rasmussen, P. Pauwels, C. A. Hviid, J. Karlshøj, Proposing a Central AEC Ontology That Allows for Domain Specific Extensions, in: Proceedings of the Joint Conference on Computing in Construction, Heriot-Watt University, 2017, pp. 237–244. doi:10.24928/ JC3-2017/0153. [13] A.-H. Hamdan, R. J. Scherer, Areas of Interest - Semantic description of component locations for damage assessment, in: EG-ICE 2020 Proceedings: Workshop on Intelligent Computing in Engineering, Berlin, 2020. [14] N. Noy, D. Mcguinness, Ontology development 101: A guide to creating your first ontology, Knowledge Systems Laboratory 32 (2001). [15] A. Göbels, Conversion of infrastructure inspection data into Linked Data models, in: 32. Forum Bauinformatik 2021, Darmstadt, 2021. [16] A. Göbels, J. Beetz, Conversion of legacy domain models into ontologies for infrastructure maintenance, in: Proceedings of the 9th Linked Data in Architecture and Construction Workshop - LDAC 2021, CEUR-WS, Luxembourg, 2021. 104