=Paper=
{{Paper
|id=Vol-3824/paper7
|storemode=property
|title=Relative Location Ontology: An Ontological Model for Representing Directional Topological Relationships between Spatial Entities in Oriented Space
|pdfUrl=https://ceur-ws.org/Vol-3824/paper7.pdf
|volume=Vol-3824
|authors=Anne Göbels,Jakob Beetz
|dblpUrl=https://dblp.org/rec/conf/ldac/GobelsB24
}}
==Relative Location Ontology: An Ontological Model for Representing Directional Topological Relationships between Spatial Entities in Oriented Space==
https://ceur-ws.org/Vol-3824/paper7.pdf
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