=Paper= {{Paper |id=Vol-3824/paper5 |storemode=property |title=infraspatialOT: An Ontology for the Representation of Spatial Relationships in Road Infrastructure |pdfUrl=https://ceur-ws.org/Vol-3824/paper5.pdf |volume=Vol-3824 |authors=Ina Heise,André Borrmann |dblpUrl=https://dblp.org/rec/conf/ldac/HeiseB24 }} ==infraspatialOT: An Ontology for the Representation of Spatial Relationships in Road Infrastructure== https://ceur-ws.org/Vol-3824/paper5.pdf

infraspatialOT: An Ontology for the Representation of
Spatial Relationships in Road Infrastructure
Ina Heise1,* , André Borrmann1
1
Technical University of Munich, Arcisstrasse 21, 80333 München, Germany

Abstract
Road infrastructure is a highly complex system whose functionality is of central importance to society.
Due to its complexity, the operation and maintenance of this system can benefit greatly from using
a digital representation of the actual system, including its current condition by means of a digital
twin. The challenge in designing such a digital twin lies in representing the road infrastructure as
an abstract system of systems. Several ontologies already describe the individual subsystems and the
aspects relevant to their operation. However, operating a road infrastructure system requires the separate
consideration of the subsystems and the relationships between the individual subsystems. This paper
deals with the formalisation of these relationships, emphasising spatiality. Following the best practice
of the W3C community, the simplicity approach is followed, in which only the spatial relationship of
the subsystems to each other is described, and reference is made to domain-specific ontologies (if they
exist) for subsystem-specific detailing. The result is an easy-to-use and maintain ontology that fills the
gap of considering the road infrastructure system without redefining concepts already defined in other
ontologies. Finally, the application of the proposed ontology is verified on a test data set consisting of
bridge and road data from Bavaria.

Keywords
road infrastructure, digital twin, road structure interaction, spatial interaction

1. Introduction
Road infrastructure serves as the physical conduit facilitating the spatial interconnectedness of
diverse locales, thereby facilitating the efficient transport of both humans and commodities.
Therefore, it is of central importance to society, and there is a great interest in ensuring the
functioning of this system now and in the future. To this end, the existing road infrastructure is
maintained, repaired and, if necessary, renewed, replaced or extended. Suitable documentation
of the existing infrastructure and its current condition is beneficial in several aspects to carry
out these measures: The individual defects are better accessible by analysing them in a context.
Thus, the resulting need for action in the form of maintenance or repair measures can be
better estimated. Also, it is possible to make statements about the performance of the existing
road infrastructure concerning specific criteria. In addition, the possibility of making more

LDAC 2024: 12th Linked Data in Architecture and Construction Workshop, June 13–14, 2024, Bochum, Germany
*
Corresponding author.
†
These authors contributed equally.
$ ina.heise@tum.de (I. Heise); andre.borrmann@tum.de (A. Borrmann)
https://www.cee.ed.tum.de/cms/team/ina-heise/ (I. Heise);
https://www.cee.ed.tum.de/cms/team/andre-borrmann/ (A. Borrmann)
0009-0009-9581-056X (I. Heise); 0000-0003-2088-7254 (A. Borrmann)
© 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

63
differentiated statements about the current condition of existing infrastructure combined with
their documentation over an extended period results in the recording of condition history.
Analysing this condition history and extrapolating it to an expected condition development
offers great potential. It improves the quality of calculation of the resources required for
maintenance. It allows the estimation of the effects of individual deficits on the condition
development based on the consideration of similar or related structural systems or components.
Furthermore, evaluating the progression of conditions in combination with the measures
carried out allows an assessment of their effectiveness. The challenge in realising this lies in
the size of the system to be considered, both in terms of its spatial extent and the number of
assets to be recorded. For example, the various existing systems for managing the Bavarian
road infrastructure already contain data on over 40,000 kilometres of road and over 27,800
structures. The road infrastructure subsystems are also very heterogeneous. As discussed in [1],
roads and bridges, e.g. have very different characteristics requiring different representations.
In addition, the individual components of the road infrastructure cannot be considered in
isolation, as they influence each other and are interdependent in their functionality. In order to
manage complexity and support human decision-making, a suitable digital representation of
the road infrastructure system is required that is able to represent the road infrastructure as a
system of individual, heterogeneous subsystems and their interactions in a scalable manner.
However, due to its heterogeneity, in practice the data is stored and maintained in different,
usually separate systems. This results in road infrastructure data being distributed across
heterogeneous, mostly siloed information systems. Furthermore, as Heise shows using the
example of German infrastructure management, these systems are often based on relational
database systems and partly only support file-based data exchange. Therefore, a flexible and
comprehensive analysis of this data across the various sub-systems is impossible. Thus, the
same problems of distributed, heterogeneous data exist in infrastructure management as in the
rest of the construction industry. To overcome this recurring limitation Beetz et al. presents the
application of linked data methods.
While there are already various modelling approaches for individual subsystems of road
infrastructure in existing research, their integration into the overall system with a description
of their relations is lacking. This paper presents a modelling proposal for capturing the inter-
actions of subsystems using graph-based methods. The proposed concept is implemented in
the infraspatialOT ontology, which focuses exclusively on describing spatial relationships. The
result is a lightweight ontology that can be easily combined with other ontologies that describe
individual subsystems in a more domain-specific way. Thus, this paper presents a modelling
approach that allows the integration of different subsystems into an overall system to create a
digital representation of the road infrastructure in a way that allows the spatial relationships
between the subsystems to be derived.

2. Related Works
To use the existing legacy data despite the use of linked data, several preliminary works have
dealt with converting legacy data into linked data graphs. Göbels and Göbels and Beetz present
an approach to convert data from the structure management system used throughout Germany

64
into RDF graphs. An ontology is developed that describes the ASB-ING data structure (a standard
published by the German Ministry of Transport in 2013 [5]) on which the system is based. In
addition, the translation of legacy data into rdf graphs based on the developed ontology is
presented. Additionally, in Beetz et al., a data conversion based on the OKSTRA schema (an
extensive German object catalogue for describing roads in all life cycle phases [7])is introduced.
With the object type library presented by Luiten et al., an approach exists that links the
description of road and structure data based on existing, established data structures. According to
Biswas et al., it aims to link the road asset management systems used across Europe by providing
a common data structure. The resulting EUROTL ontology is outlined by Marcovaldi. Hagedorn
et al. presents the conversion of road and structure data into graph-based representations
using these existing modelling approaches. It also shows how they can be linked to other
heterogeneous, maintenance-related infrastructure data. A structure and a road section are
considered, but the interaction of both is not examined. The existing research, therefore, shows
approaches to flexibly analyse the valuable existing data by describing the data structures using
ontologies and developing translators between legacy data and rdf graphs. Thus, they create
the prerequisites for using existing data to create a digital representation.
However, the existing data structures also have considerable disadvantages that preclude
their direct adoption in the modelling approaches of a digital twin of a road infrastructure
system. The OKSTRA schema tries to cover the whole area of road infrastructure with all
sub-aspects. This results in a complex data model that is difficult to handle and combine. In
addition, there is a lack of spatial relationships between the individual infrastructure elements.
The graphical representation in [10] and the description by Biswas et al. show that EUROTL also
covers roads, different types of structures and network elements as possible components of road
infrastructure. However, a description of the spatial relationships is missing. In addition, the
resulting ontology is also quite extensive, as it attempts to cover all asset management content
as completely as possible. It is, therefore, similar to okstraowl, potentially difficult to handle.
The concept of spatial topological relationships between geographical elements is addressed
in geoSPARQL, which is presented in [12]. The primary focus of geoSPARQL is to define
topological relationships between geographical objects. However, a more detailed description
of spatial relationships is necessary when it comes to road infrastructure and its constituent
elements. For instance, to accurately depict the relationship between a road and several signs
situated along it, it is essential to consider not only the signs’ proximity to the road but also
their placement in relation to the road and the order in which they are arranged. Unfortunately,
this specific information is not covered by geoSPARQL’s spatial relationship definitions.
Rasmussen et al. presents with BOT another modelling approach for topological relationships
in civil engineering. BOT describes the spatial relationships in buildings using the defini-
tion of zones. A bot:Zone can be adjacent (bot:adjacentZone) to another bot:Zone, contain
(bot:containsZone) it or intersect (bot:intersectsZone) it. While the defined concept is well
suited to describing spatial relationships within nested structures like buildings, it is not as
applicable to infrastructure structures. To address this limitation, Hamdan and Scherer have
proposed an extension called BROT specifically for bridges. However, this only applies the
description of the topological relationships of BOT to bridges and does not address the issue
that the large longitudinal extent of infrastructure structure, makes it difficult to fully describe
their required spatial relations using an approach for nested structures.

65
Figure 1: Road infrastructure as a system of subsystems

Borrmann et al. also conclude that the hierarchical spatial organisation of buildings is insuffi-
cient for infrastructure structures. As a solution, they propose extensions to the IFC standard
for bridges - suggesting the incorporation of linear referencing concepts and a new class, IfcRel-
Positions, to describe relationships between axis-related objects. By integrating the concept
of linear referencing based on DIN EN 19148 into the IFC schema, Borrmann et al. enable a
range of positioning and geometry description methods that are much better suited to capture
infrastructure structures. While adapting these principles to relationships of infrastructure
elements is possible, it’s important to note that ifcOWL, an ontology presented by Pauwels and
Terkaj that depicts the IFC standard, has some limitations. As Rasmussen et al. explain, the
ontology’s complex structure and size severely limit its usability and extensibility.
Therefore, a modelling approach for spatial relationships that is easy to combine, handle, and
scale to create a suitable digital representation of road infrastructure as a system consisting of
different, heterogeneous subsystems is still missing.

3. Concept
3.1. Modelling approach for spatial relationships in a road infrastructure
system
Three principles are used to break down the complex system and the relationships that occur
within it, as shown in Figure 1. Firstly, the entire system is divided into subsystems and sub-
systems of subsystems. This leads to smaller, more homogeneous units for which it is easier
to find formalised relationship descriptions. Supersystems are always more generalised than
subsystems. They summarise their subsystems into a spatial or functional unit. A network is
assumed to be the highest supersystem, establishing the relationships between linear reference
elements. The linear reference elements contextualised within this network represent the

66
connection point for the subsystems at the next lower level. This level contains road infrastruc-
ture elements, which can be physical, non-physical objects or, in turn, systems with possible
subsystems. However, the basic prerequisite for a road infrastructure element is that it can
be localised. This level predominantly contains assets such as bridges, roads, and equipment
elements that are considered either as objects or as systems. An example of a non-physical road
infrastructure element is data on traffic volumes on specific road sections. Below the level of
road infrastructure elements, if a road infrastructure element itself represents a system (e.g. in
the case of structures), further subdivision into additional subsystems is possible, which may
lead to a component level, for example. However, the exact subdivision is subsystem-specific
and cannot be generalised for a whole road infrastructure system.
Secondly, subsystems and their associated supersystems are linked. This allows information
at the subsystem level to be aggregated at the supersystem level (e.g. status levels assigned at the
subsystem level can be aggregated at the supersystem level to a status level of the supersystem).
In addition, relationships modelled at the supersystem level can also be interpreted at the
subsystem level.
Thirdly, not all existing relationships are modelled explicitly. Instead, a combination of
explicitly modelled and relationships that are implied is used. The idea is to only model the
relationships between a subsystem and its next higher supersystem explicitly, while other
relationships (such as those between subsystems) can be derived implicitly. This concept is
exemplified in Figure 1, where different arrow types are used between the subsystem levels
and within the road infrastructure element level. This significantly reduces the number and
heterogeneity of relationships to be explicitly captured, simplifies their formalisation and
makes the approach scalable. As these relationships describe the spatial relationships between
systems with varying levels of abstraction (supersystem and subsystem), they can be further
distinguished according to Bateman and Farrar into a description of the localization between
elements from an element perspective (implicitly included) and a description of the localization
about the corresponding reference system (explicitly included).
The area highlighted in Figure 1 is the subject of this paper, with a particular focus on analysing
the spatial relationships between road infrastructure components. Using the principles outlined
previously, the relationships between these elements within the designated area are described
through linear reference elements.

3.2. Modelling approach for spatial relationships at the road infrastructure
element level
The modelling of the spatial relationships between the road infrastructure element and the
reference element is divided into localisation and positioning (both shown in Figure 2). Lo-
calisation is used to describe the position of the road infrastructure element in relation to the
reference element in the longitudinal direction. Positioning describes the position of the road
infrastructure element in relation to the reference element in the transverse direction. A road
infrastructure element is localised on a reference element either by a start and end point as a
line object or a middle point as a point object.
The exact description of the location of each point on the reference element is based on
the principle of linear referencing as defined in DIN EN 19148. The method of absolute linear

67
Figure 2: The relationships between infrastructure element and reference element

referencing is used, where the distance from the starting point of the reference element specifies
the location. However, it would also be possible to use interpolative linear referencing (using a
ratio value instead of the distance). This explicitly modelled localisation of road infrastructure
elements then implicitly contains whether the road infrastructure elements are adjacent, inter-
secting or contained within each other in the longitudinal direction. The definition of adjacent,
intersecting and containing corresponds to the definitions made in [13] for bot:adjacentZone,
bot:intersectsZone and bot:containsZone. In addition, predecessor and successor relationships
and the size of the intersection can be derived.
The positioning is described in a horizontal and vertical direction, as shown in Figure 2 on
the right-hand side. A distinction is made between above, below, next_to and on. A distinction
is also made between positioning with distance and positioning without distance. Above, below,
and next_to are positionings with distance. A distance value is, therefore, defined for them. The
remaining on positioning is a positioning without distance and, therefore, must not have a distance
value. A detailed definition of the individual terms used can be found in the documentation of
the corresponding ontology class1 .
The SUMO ontology also contains definitions for key terms like SUMO:Above, SUMO:Below,
SUMO:Near, SUMO:Left, and SUMO:Right. However, the definitions made in SUMO are in-
tentionally not aligned with the proposed concept directly because of their specificity. SUMO
definitions all involve overlapping projections, which could potentially contradict statements
about other positioning directions. This finding is consistent with the analysis of Bateman and
Farrar, who argue that DOLCE Ultralight ontology (DUL) may be a better upper ontology for
ontologies describing concepts of spatiality due to its more open descriptions. Consequently,
we propose aligning the ontology implementing the concept with DUL in Section 4.3.

3.3. Application of the concept
The spatial relationships that are derived from the spatial relationships explicitly included in
the transverse direction vary greatly depending on the type of road infrastructure element
considered and the use case. Figures 3 and 4 illustrate the application of the concept to describe
two exemplary spatial relationships:
1
https://dtc-ontology.cms.ed.tum.de/infraspatialot/index.html

68
Figure 3: Example 1: A road lies partly on a bridge or a bridge lies on a road

Figure 4: Example 2: A road underpasses a bridge or a bridge overpasses a road

Figure 3 shows a lies on relationship between the bridge and the road it crosses. Both elements
are localised as line objects with start and endpoints. This results in the area marked in blue
on the left, where the two elements intersect in the longitudinal direction. The positioning,
corresponding to the right part of the figure 3, is described as on the reference element for both
elements. A combined view of localisation and positioning shows that the road in consideration
lies on the bridge and in which area.
Figure 4 shows the overpass relationship of the bridge to the road or the underpass relationship
of the road to the bridge. As in the first example, locating the road using a line object is
appropriate. (This will now refer to a reference element different than in the first example). A
point object is sufficient for this example to localise the bridge to the lower reference element.
These localisations result in a contained in relationship between the elements in the longitudinal
direction. The positioning of the elements is again shown in the right part of figure 4. The road
is again on the reference element. This time, however, the bridge is above the reference element.
Combining the information from both elements for localisation and positioning results in the
overpass or underpass relationships between the elements.

69
Figure 5: Excerpt of the infraspatialOT ontologie

4. The infraspatialOT ontology
4.1. Ontology Engineering Methodology
ElHassouni and Qadi conducted a comparison of various ontology engineering methods and
discovered that the approach presented by Hitzler and Krisnadhi had advantages in terms
of Ontology Design Pattern (ODP) usage, resulting ontology reusability and extensibility,
and avoidance of over-specific ontologies. This method, thereby, addresses the weaknesses
of existing road infrastructure ontologies identified by Lei et al.. The ontology engineering
methodology used in this paper is quite similar to Krishnadhi and Hitzler’s.
As a first step, workshops were conducted with Bavarian authorities to identify potential use
cases for a digital twin of a road infrastructure system. These use cases were compared with
existing systems to determine the requirements for their implementation based on available
data. Detailed results of this analysis can be found in [1]. The requirements analysis revealed a
fundamental challenge for all use cases: the lack of a scalable approach to describing spatial
relationships in infrastructure. Subsequently, existing approaches and their applicability to the
identified challenge were scrutinised (Section 2). These scrutinies led to a conceptual solution
(Section 3), afterwards implemented as an ontology using Protégé.

4.2. Content and modelling decisions
The defined ontology2 is mainly shown in Figure 5. infraspatialOT:RoadInfrastructureElement
and its subclasses contain the road infrastructure elements and reference elements are contained
in infraspatialOT:ReferenceElement. The relationships between the road infrastructure elements
2
https://dtc-ontology.cms.ed.tum.de/infraspatialot/index.html

70
and the reference elements are created via infraspatialOT:Localisation and infraOT:Positioning
with their respective subclasses. infraspatialOT:Localisation implements the concept of
localisation described above with its subclasses infraspatialOT:PointLocalisation and infraspa-
tialOT:LineLocalisation. They are linked accordingly with a subclass of infraspaialOT:Point,
which describes the exact position on the infraspatialOT:ReferenceElement via the value in
infraspatialOT:hasStation. The positioning is implemented according to the concept described
above in infraOT:Positioning and its subclasses and is linked to infraspatialOT:Localisation.
infraspatialOT:HorizontalPositioningNextTo, infraOT:VerticalPositioningAbove and in-
fraOT:VerticalPositioningBelow are defined as subclasses of infraOT:PositioningWithDistance
and infraOT:VerticalPositoiningOn and infraOT:HorizontalPositioningOn are defined as sub-
classes of infraOT:PositioningWithoutDistance. In addition, infraOT:PositioningWithDistance
and infraOT:PositioningWithoutDistance are in a disjoint relationship. The relationship
between a road infrastructure element and the associated reference element can therefore be
queried with SPARQL, as shown in Listing 1 for an example individual.
PREFIX infraOT:
PREFIX rdf:
SELECT ?isLocatedWith ?Localisation ?isPositionedWith ?Positioning ?isLocatedAt ?Point
?RefElment
WHERE {
infraOT:bridge2 ?isLocatedWith ?Localisation .
?Localisation ?isLocatedAt ?Point .
?Point infraOT:pointsOn ?RefElment .
?Localisation ?isPositionedWith ?Positioning .
?Positioning rdf:type infraOT:Positioning .
}

Listing 1: SPARQL query for explizitly modeled relations to the reference object

The listing 2 shows how to extract the information needed to derive the implicit relationships of
one infrastructure element to another. First the location of the element is determined. This area
is then searched for localised road infrastructure elements. The result is a subgraph containing
all found road infrastructure elements with their localisation and position information. This
subgraph can then be interpreted according to the respective use case and the elements found.
PREFIX infraOT:
PREFIX rdf:
CONSTRUCT {
?startP infraOT:hasStation ?Station .
?endP infraOT:hasStation ?Station .
?midP infraOT:hasStation ?Station .
?startP infraOT:pointsOn ?RefElement .
?endP infraOT:pointsOn ?RefElement .
?midP infraOT:pointsOn ?RefElement .
?startP infraOT:locates ?LineLoc .
?endP infraOT:locates ?LineLoc .
?midP infraOT:locates ?PointLoc .
?infraElementLine infraOT:isLocatedWith ?LineLoc .
?infraElementPoint infraOT:isLocatedWith ?PointLoc .
?LineLoc infraOT:isPositionedWith ?PositioningLine .
?PointLoc infraOT:isPositionedWith ?PositioningPoint .

71
}
WHERE {
# defining the area under consideration based on the initial element "bridge2":
infraOT:bridge2 infraOT:isLocatedWith ?LineLocRelArea .
?LineLocRelArea infraOT:isLocatedAtEndpoint ?endPRelArea .
?LineLocRelArea infraOT:isLocatedAtStartpoint ?startPRelArea.
?endPRelArea infraOT:pointsOn ?RefElement .
?startPRelArea infraOT:pointsOn ?RefElement .
?endPRelArea infraOT:hasStation ?endStationRelArea .
?startPRelArea infraOT:hasStation ?startStationRelArea .
OPTIONAL {
?startP infraOT:hasStation ?startStation .
?endP infraOT:hasStation ?endStation .
?LineLoc infraOT:isLocatedAtStartpoint ?startP .
?LineLoc infraOT:isLocatedAtEndpoint ?endP .
?LineLoc infraOT:locates ?infraElementLine .
?LineLoc infraOT:isPositionedWith ?PositioningLine .
FILTER ((?startStation >= ?startStationRelArea && ?endStation <= ?endStationRelArea)
|| (?startStation <= ?startStationRelArea && ?endStation >= ?endStationRelArea)
).
}# searching for linelocated elements in the area under consideration
OPTIONAL {
?PointLoc infraOT:locates ?infraElementPoint.
?PointLoc infraOT:isPositionedWith ?PositioningPoint.
?PointLoc infraOT:isLocatedAtMidpoint ?midP.
?midP infraOT:hasStation ?MidStation.
FILTER (?startStationRelArea < ?MidStation && ?MidStation < ?endStationRelArea).
}# searching for pointlocated elements in the area under consideration
}

Listing 2: SPARQL query for a subgraph of explicitly modeled relations between infraOT:bridge2 and
other infrastructure elements

4.3. Possible alignments
Alignment to the upper ontology DUL, as proposed by Bateman and Farrar for ontolo-
gies describing spatiality, is suitable: infraspatialOT:RoadinfrastructureElement, infraspa-
tialOT:ReferenceElement,infraspatialOT:Localisation, infraspatialOT:Positioning and infras-
patialOT:Point are spatially located, but may not necessarily have an associated mass.
They are therefore specifications of DUL:Object. infraspatialOT:isLocatedAt and infraspa-
tialOT:isPositionedWith are subclasses of DUL:hasLocation.
It is also conceivable to posit an alignment in which infraspatialOT:RoadinfrastructureElement
and infraspatialOT:ReferenceElement are defined as owl:sameAs geoSPARQL:SpatialObject.
This alignment enables the application of concepts delineated within geoSPARQL which are
eminently suited for describing the spatial relations of infrastructure elements relative to spatial
geographical elements, such as nature reserves.
The subclasses of infraspatialOT:RoadinfrastructureElement also represent connection points
to ontologies that describe the data set to be integrated in a domain-specific way. If BROT is used
to describe bridges, BROT:bridge can be defined as owl:sameAs infraspatialOT:Bridge. When
utilizing data from the German structure management, asb:Teilbauwerk can be a rdfs:subClassOf

72
infraspatialOT:RoadinfrastructureElement. The information required for localisation can be
derived from asb:Netzzuordnung and the associated DataProperties, and Sachverhalt and the
associated subclasses provide information on positioning. However, it should be noted that in
this case information contained as a string of a DataProperty in asb has to be interpreted as
links in infraspatialOT, so alignment is not entirely straightforward.

5. Instantiation of the infraOT with real-world data
In order to validate the proposed ontology, the modelling and subsequent querying of the spatial
relationships between the individual infrastructure elements is demonstrated. For this purpose,
real data of the Bavarian infrastructure are used. However, as described in [1], this data is
distributed in different relational database systems. Various preliminary works such as [3] or
[6] already show how different legacy datasets of German infrastructure data can be converted
fully automatically into RDF graphs. To instantiate the proposed ontology, we did not convert
the datasets completely but only extracted the information necessary to derive the relationship
between the assets and the reference elements.
Structures and roads are considered examples of road infrastructure subsystems. Elements
of the so-called ASB network defined throughout Germany are used as reference elements. In
Bavaria, road-related data is managed with the BAYSIS system, which accesses a relational
database system (TT-SIB) in the background. The data of the TTSIB can be accessed by a
WebFeatureService (WFS). The structure data is managed in another system, SIB-Bauwerke,
which is also based on a relational database system and only supports file-based data exchange.
As part of a research project, the authors were provided with a copy of the structure database.
The reference elements from the ASB and the road data were extracted from the TT-SIB.
Requests are sent to the WFS server to retrieve the data for the corresponding feature types. The
response is returned in XML format. In order to extract the relevant information for describing
the relation of a road object to its respective reference element, the attributes vst and bst must
be evaluated and combined with information on linked objects of other feature types (Itallglage
and AsbAbschn). Therefore, classes for the feature types were defined in an object-oriented
structure. These classes are instantiated with the parsed information from the FeatureType
objects. This allows the information to be restructured and made available in a suitable way to
instantiate the ontology.
To instantiate the ontology with structure instances and their relationships to reference
elements, the structure data was restored on an SQL server. This allows for automatic data
extraction using SQL queries. However, the information required for localisation and positioning
is spread across multiple disconnected tables that can be associated via an ID field in both tables.
Additionally, the values from the VON_NK and NACH_NK fields must be combined to identify
the reference element to which the localisation or positioning information pertains. To derive the
positioning information, the numerical keys in the corresponding LAGE field were interpreted
according to the ontology. It’s worth noting that in ASB-ING, the position of the reference
element is described from the bridge (e.g. "Oben liegend" (Engl. lying on top) corresponds to a
positioning on). An object-oriented structure was employed to interpret and restructure the
information extracted from the structure database. Based on their instances, the individuals

73
Figure 6: Comparison of the spatial information in the system already used in Germany (no semantic
spatiality description) and the spatiality derived using the concept presented

were generated. The resulting graph can then be queried for spatial relationships between
selected and other infrastructure elements using SPARQL, as shown in Listing 2. The results
can then be used to automatically generate a figure, as shown in Figure 6 on the right.

6. Results and Discussion
This paper presents an approach for modelling spatial relationships to create a digital represen-
tation of a road infrastructure system for support in operation. The main challenge lies in the
variety and quantity of possible relationships between the subsystems. These result both from
the heterogeneity of the subsystems and from the many ways in which they interact. At the
same time, the number of assets to be captured in representations of road infrastructure requires
scalability to be considered. Nevertheless, the overall system to be considered varies greatly in
size and scope depending on the use case under consideration. Therefore, an implementation
based on explicitly recording all spatial relationships occurring within a road infrastructure
system is inappropriate.
Instead, an approach based on introducing further abstraction is used. In this abstraction
level, all road infrastructure elements are considered point or line objects along a linear ref-
erence element. The resulting spatial relationship between the abstracted road infrastructure
elements and the reference element can be better formalised. They are explicitly described using
localisation and positioning. The relationships that are of interest between two infrastructure
elements can then be derived from their respective relationship to the reference element. This
makes it possible to significantly narrow down the potentially relevant spatial relationships
between infrastructure elements at a higher level of abstraction before they are analysed in
more detail. The subdivision into localisation and positioning further supports this effect.
The concept presented so far only considers spatial relationships between entire assets with-
out covering the relationship between individual components and other assets or between
components of different assets. However, IFC already provides concepts for describing struc-
tures based on linear referencing, which involves positioning components via a reference to a
linear element. The reference element used within the structure can also be considered a road
infrastructure element and linked to the reference element of the entire road infrastructure

74
system. This would enable determining the precise position of a component in relation to
the entire road infrastructure system or to components of other structures. A combination of
ifcOWL and the presented infraspatialOT is, therefore, particularly promising and will be part
of future work.
There is tremendous potential in extending the presented concept to infrastructure data in
other or legacy systems. This can be achieved by aligning ontologies that describe the data
structures of these systems with the infraspatialOT. This alignment would enable the analysis of
relationships between infrastructure assets that are stored in different legacy systems. Ontologies
that already contain information from which an assignment to a reference element can be
derived are particularly well-suited for this purpose, such as ASB-ING Ontology. Therefore, a
combination of ASB-ING Ontology and infraspatialOT will be part of future work. Additionally,
the authors see great potential in deriving the spatial relationships of an infrastructure element
to a reference element from its coordinates or geometry, as this would facilitate extending the
presented approach to all data sets whose position is described with coordinates.

Acknowledgments
The research presented in this paper has been funded by the Bavarian State Ministry for Housing,
Construction, and Transport in the frame of the research project "Digital twin for operating
road infrastructure". This is gratefully acknowledged.

References
[1] I. Heise, Requirements analysis for a digital road infrastructure twin, Proceedings of 34th
Forum Bauinformatik (2023). doi:10.13154/294-10105.
[2] J. Beetz, P. Pauwels, K. McGlinn, S. Tormä, Linked data im bauwesen, in: A. Borrmann,
M. König, C. Koch, J. Beetz (Eds.), Building Information Modeling, Springer Fachmedien
Wiesbaden, 2021, pp. 223–242. doi:10.1007/978-3-658-33361-4.
[3] A. Göbels, Conversion of infrastructure inspection data into linked data models, 32. Forum
Bauinformatik (2021). doi:10.18154/RWTH-2021-07268.
[4] A. Göbels, J. Beetz, Conversion of legacy domain models into ontologies for infrastructure
maintenance, 9. Linked Data in Architecture and Construction Workshop (2021). doi:10.
18154/RWTH-2021-07330.
[5] Bundesministerium für Verkehr, ASB-ING, 2013. URL: https://www.bast.de/DE/
Publikationen/Regelwerke/Ingenieurbau/Erhaltung/ASB-ING.html, date accessed:
12.02.2024.
[6] J. Beetz, J. Amann, A. Borrmann, Linked Data im Bereich des Straßenwesens, 2018.
URL: https://bast.opus.hbz-nrw.de/opus45-bast/frontdoor/deliver/index/docId/2181/file/
LinkedData_Schlussbericht_01.0195.pdf, date accessed: 08.02.2024.
[7] Bundestanstalt für Straßenwesen (bast), OKSTRA - Einführung, 2024. URL: https://www.
okstra.de/, date accessed: 08.02.2024.
[8] B. Luiten, M. Böhms, D. Alsem, A. O’Keeffe, Asset information management for european
roads using linked data, Proceedings of 7th Transport Research Arena (TRA) (2018).

75
[9] S. Biswas, J. Proust, T. Andriejauskas, A. Wright, C. V. Geem, D. Kokot, A. Antunes,
V. Marecos, J. Barateiro, S. Bhusari, J. Petrović, Demonstrating connectivity and ex-
change of data between bim and asset management systems in road infrastructure
asset management, Springer Science and Business Media B.V., 2022, pp. 379–392.
doi:10.1007/978-3-030-79801-7_27.
[10] E. Marcovaldi, buisness blueprint of an asset information
management core system, 2018. URL: https://www.cedr.eu/
download/other_public_files/am4infra_public_files/AM4INFRA-D3.
2-Business-Blue-Print-of-an-asset-information-management-core-system.pdf, date
accessed: 02.02.2024.
[11] P. Hagedorn, L. Liu, M. König, R. Hajdin, T. Blumenfeld, M. Stöckner, M. Billmaier,
K. Grossauer, K. Gavin, Bim-enabled infrastructure asset management using informa-
tion containers and semantic web, Journal of Computing in Civil Engineering 37 (2023).
doi:10.1061/(asce)cp.1943-5487.0001051.
[12] M. Perry, J. Herring, OGC GeoSPARQL-A Geographic Query Language for RDF Data, 2012.
URL: http://www.opengeospatial.org/legal/., date accessed: 02.02.2024.
[13] M. H. Rasmussen, M. Lefrançois, G. F. Schneider, P. Pauwels, K. Janowicz, BOT: The
Building Topology Ontology of the W3C Linked Building Data Group, Semantic Web 12
(2021) 143–161. doi:10.3233/SW-200385.
[14] A.-H. Hamdan, R. J. Scherer, Integration of BIM-related bridge information in an ontological
knowledgebase, Proceedings of the 8th Linked Data in Architecture and Construction
Workshop (2020) 77–90. URL: https://ceur-ws.org/Vol-2636/06paper.pdf.
[15] A. Borrmann, S. Muhic, J. Hyvärinen, T. Chipman, S. Jaud, C. Castaing, C. Dumoulin,
T. Liebich, L. Mol, The IFC-Bridge project – Extending the IFC standard to enable high-
quality exchange of bridge information models, 2019, pp. 377–386. doi:10.35490/EC3.
2019.193.
[16] A. Borrmann, J. Amann, T. Chipman, J. Hyvärinen, T. Liebich, S. Muhič, L. Mol, J. Plume,
P. Scarponcini, IFC Infra Overall Architecture Project Documentation and Guidelines, 2017.
URL: https://buildingsmart.org/wp-content/uploads/2017/07/08_bSI_OverallArchitecure_
Guidelines_final.pdf, date accessed: 23.03.2024.
[17] P. Pauwels, W. Terkaj, EXPRESS to OWL for construction industry: Towards a recom-
mendable and usable ifcOWL ontology, Automation in Construction 63 (2016) 100–133.
doi:10.1016/j.autcon.2015.12.003.
[18] J. Bateman, S. Farrar, Towards a generic foundation for spatial ontology, in: Proceedings
of the 3rd International Conference on Formal Ontology in Information Systems (FOIS-04),
IOS Press, 2004, pp. 237–248.
[19] J. ElHassouni, A. E. Qadi, Ontology Engineering Methodologies: State of the Art, 2022, pp.
59–72. doi:10.1007/978-3-031-07969-6_5.
[20] P. Hitzler, A. Krisnadhi, A Tutorial on Modular Ontology Modeling with Ontology Design
Patterns: The Cooking Recipes Ontology, CoRR (2018). URL: http://arxiv.org/abs/1808.
08433. arXiv:1808.08433.
[21] X. Lei, P. Wu, J. Zhu, J. Wang, Ontology-Based Information Integration: A State-of-the-Art
Review in Road Asset Management, Archives of Computational Methods in Engineering
29 (2022) 2601–2619. doi:10.1007/s11831-021-09668-6.