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.
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) [
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 [
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
ifeld 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 [
The approach was adapted to 3D space by Zlatanova, who also investigated the relationships
between objects with diferent dimensionality [
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 [
Topological relations are also an integral part of the ontologies of the Linked Building Data
(LBD) domain. The Building Ontology Topology (BOT)[
The Area of Interest Ontology (AOI)[
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 [
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 diference 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. reloc:meet A
B reloc:meetFront „directly in front of“
B
A reloc:meetRear „directly behind“
A
B reloc:meetLeft „directly left of“ B A A B
Reference (viewing) direction B
A reloc:meetRight „directly right of“ reloc: meetTop „directly above“
B
A reloc:intersectRight „intersects with the right side of“ reloc: intersectTop „intersects with the top side of“ reloc: meetBottom „directly under“ reloc: intersect Bottom „intersects with the bottom side of“ A
B reloc:intersectFront „intersects with the front of“ B
A A
B reloc:intersectLeft „intersects with the
left side of“ reloc:intersectRear „intersects with the back of“ reloc:containedInRear „contained in front
area of“ A
B reloc:containedInFront „contained in front of“
A
B reloc:containedIn LongitudinalCenter „contained in longitudinal central area of“
B A
A
B A
B reloc:containedInLeft „contained in left area of“ reloc:containedIn TransversalCenter „contained in transversal central area of“
B
A reloc:containedInRight „contained in right area of“
A B A B B A reloc: containedIn Top „contained in upper area of“ reloc: containedIn VerticalCenter „contained in vertical central area of“ reloc: containedIn Bottom „contained in lower area of“
A B reloc:equal Longitudinal „same longitudinal center and lenght as“
A B reloc:equal Transversal „same transversal center and width as“
A
B reloc:equal
Vertical „same vertical center and height as“ reloc:hasRelative SpatialRelationTo reloc:intersect reloc:containedIn
When applying the Relative Location Ontology, it is possible to make spatial queries, answering, for example, the following competency questions (CQ): intersection, or equality relationship? is at the beginning of B?" • 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, • CQ3: What are the directional and topological properties of the natural language term "A
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 [
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 here 2. 1http://www.w3.org/2002/07/owl 2https://w3id.org/reloc reloc:2DTopologicalRelation owl:SymmetricProperty reloc : https://w3id.org/reloc# owl: http://www.w3.org/2002/07/owl# rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# rdfs: http://www.w3.org/2000/01/rdf-schema#
reloc:directionalRelation reloc:longitudinalAxisRelation reloc:longitudinalCenter reloc:front rdf:type rdfs:label rdfs:label skos:altLabel owl:ObjectProperty ; "front"@en ; "Vorne"@de ; "Anfang"@de, "beginning"@en, "Vorderseite"@de, "front side"@en, rdfs:subPropertyOf reloc:longitudinalAxisRelation .
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 diferent 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 diferent textual expressions which refer to the same location (see also ifgure 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 documentation data, we added a small functional extension that covers an alternative method that is owl:ObjectProperty owl:DatatypeProperty Object A reloc:containedInFront reloc:containedInRight Object B
reloc:meetTop brot:adjacentZone / brot:adjacentComponent bot:adjacentZone / bot:adjacentElement
reloc:intersectFront Object A reloc:containedInRight reloc:containedInTop
Object B bot:intersectsZone / bot:intersectingElement bot: https://w3id.org/bot# brot: https://w3id.org/brot# reloc: https://w3id.org/reloc# Legend: Vertical Axis
Longitudinal Axis Transversal Axis reloc:containedInFront reloc:containedInRight reloc:containedInTop Object A
Object B brot:containsZone / brot:containsComponent
bot:containsZone / bot:containsElement 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:RelativeLocationWithOfset 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:hasOfsetValue 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:hasOfsetValueUnit (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. Front Substructure
Girder and its sub-components
Equal Transversal "same width as" Contained In Front ""is contained in the front area of"
Abutment
or Pierzone
Girder
Meet Bottom "under" Intersect Front ""intersects with the front
side of" firstSpan
Equal Transversal
Equal Longitudinal
ContainedIn Top
MGMG Girder Meet Left
ContainedIn Bottom ContainedIn Right
Girder Deck Main Girder ContainedIn Longitudinal
Center
Span
Abutment
or Pierzone
Meet Bottom
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 [
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 TBox ABox brcomp:Abutment a
reloc:equalTransversal :Abutment 01 reloc:containedInFront reloc:front [rdfs:label: "Front", "Beginning"] 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 diferent possibilities to define the respective query pattern. To keep the query lfexible for diferent 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 diferent 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).
Input TBox ABox dot:DamageArea brcomp:Abutment
a :Abutment 01 brcoDmepc:Gkirder
a :GirderDeck brcomp: ht ps:/ w3id.org/brcomp# brstr:ht ps:/ w3id.org/brstr# reloc: ht ps:/ w3id.org/reloc# dot: ht ps:/ w3id.org/dot# brstr:Span
a :Span 02
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 diferent 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 diferent 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 efectively 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 [
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.
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.
This research is part of the Raumlink project funded by the German Research Foundation (DFG) – Project number 501812634.