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. 76