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.
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 determination 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 approximate 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 communication, not automated processing or analysis. However, for the digital transformation and modernisation of bridge maintenance processes, it is essential to make the documented inspection information accessible and compatible with state-of-the-art techniques like Building Information Modelling (BIM). To achieve this transformation, the implicit spatial information 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.
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 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.
The RELOC Ontology was created using the seven-step method described by Noy and Mcguinness [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.
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-languagebased 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.
The primary development and application context of the RELOC Ontology is the bridge maintenance 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 position 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.
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?"
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 (2Dor 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".
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 here2 . rdf:type owl:ObjectProperty ; rdfs:label "front"@en ; rdfs:label "Vorne"@de ; skos:altLabel "Anfang"@de, "beginning"@en, "Vorderseite"@de, "front side"@en, rdfs:subPropertyOf reloc:longitudinalAxisRelation .
:Abutment :Bridge
The front abutment
The abutment at the beginning of the bridge rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# rdfs: http://www.w3.org/2000/01/rdf-schema# reloc: http://w3id.org/reloc# skos: http://www.w3.org/2004/02/skos/core# 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 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.
Since the RELOC Ontology was developed in the context of processing existing bridge documentation data, we added a small functional extension that covers an alternative method that is 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 general reloc:hasRelativeSpatialRelationTo property to define the reference location (e.g., reloc: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").
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.
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 components 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 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). 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.
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 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, should be as classes instead of properties, as 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 diagonal/oblique positions to each other. Additionally, the ontology's informative value is limited for components with complex geometries lacking clearly defined lateral surfaces.
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 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.
This research is part of the Raumlink project funded by the German Research Foundation (DFG) -Project number 501812634.