This paper introduces an approach to automatically convert the German data model for documenting infrastructure inspections (ASB-ING) into a semantic ontology. Thus, an extensive data model is created that enables the representation of infrastructure and maintenance-related facts in Linked Data and is compatible with the German standards and guidelines. The national standard "ASB-ING" contains about 120 classes and 500 attributes to describe a bridge or tunnel and its damages. It is the basis for the relational database program "SIB-Bauwerke", in which most bridges in Germany are recorded over the last 20 years. By converting the ASB-ING model into an Ontology, compatibility with this extensive available data set is ensured, enabling a direct translation of the existing asset data into Linked Data models. Concurrently, it is possible to relate the classes of this national data model with classes of other national or international ontologies. By mapping the ASB-ING Ontology to ifcOWL, the formerly only tabular data can be linked to standardised geometry models without requiring additionally developed geometric representation. Interlinking the ASB-ING Ontology with other international and national infrastructure data models can improve asset information exchange of cross-border projects.
Since infrastructure maintenance is expensive and inspections are still
predominantly done manually, [
To achieve comprehensive information models that interlink all these data sets, Linked Data can be utilised. Linked Data is a part of the Semantic Web Stack that has been speci cally built to enable interoperability between diverse data sets from di erent sources. A prerequisite for representing the existing data in Linked Data models are schemas or structured vocabularies, including ontologies, de ning the semantic framework for these data sets.
The documentation of infrastructure facility inspections is standardised and has to follow domain-speci c data models and conventions. These underlying structures can serve as a foundation for developing ontologies compatible with the existing inspection data. Applying this approach has the advantage of creating extensive ontologies whose base structure is already tested in the eld and created by domain experts. Using proven and agreed upon existing vocabularies eliminates the need to develop entirely new data structures and dependencies, which requires much e ort and expert knowledge.
In research documented in this paper, we apply this approach to the
"ASBING" - the German standard data model to describe infrastructural artefacts
in many use cases, including the documentation of bridge inspections[
The ASB-ING data model gets directly converted into the ASB-ING Ontology via an automated process. Thus, the ASB-ING Ontology contains the same content as the original data model but provides a Linked Data-compliant format, extending its functionality and scope of application. For example, the ASB-ING Ontology can be linked to other infrastructure ontologies and classi cations to create crosscutting data models or to ifcOWL to add geometric entities. Moreover, it becomes possible to represent the existing data sets of SIB-Bauwerke in Linked Data models since the data sets are compliant with the ASB-ING Ontology.
The paper is structured as follows: In section 2, related research activities are described and compared to our approach. Section 3 provides a brief overview of the standard landscape regarding bridge inspections and introduces the "ASBING" data model in more detail. Section 4 comprises the main part of this research and focuses on the conversion process of the domain model into a semantic ontology. Moreover, we present brie y how the proposed ontology can be used to transfer the existing inspection data of "SIB-Bauwerke" into a Linked Data Model in a further step. In the concluding chapter 5, we summarise the results of our work and identify unresolved issues and future research approaches. 2
Several research and development e orts have recently proposed solution approaches for digital representation and processing of infrastructural assets.
The ongoing IFC Infra initiative [
Hamdan and Scherer developed the Bridge Ontology "BROT" [
R. Helmerich developed an approach called "BRONTEX" [
All the approaches mentioned above have in common that they were developed manually and often in the scope of one speci c use case. While representing functional structures in their respective use cases and applications, their breadth and depth are often too limited to be useful in other practical applications. Moreover, the previous approaches do not have a solution for how existing data and processes can be aligned with their new models and concepts.
The European CEDR-INTERLINK Project, introduced in a paper from
Luiten et al. [
Related to this project is the development of the German data model
OKSTRAowl [
The INTERLINK project also includes test use cases to demonstrate and
test typical data transfer processes in national environments. One of these test
projects is the \Handover of BIM Linked Data". It is located in Germany and
uses BIM processes during the design phase of a bridge and for the data handover
after the construction phase. For this purpose, two test ontologies of the
ASBING model are developed to interlink asset entities de ned in OTL with national
classi cations [
In the context of these previous developments, the automatic conversion of the complete ASB-ING data model has several improvements and could be bene cial for projects like CEDR- INTERLINK.
Since the translation process requires a minimum of manual input, we do not have to focus on speci c parts of the data model but can convert the whole structure at once. Thus, an extensive ontology is created, including a hierarchical structure and logical dependencies and relations, to describe structural and maintenance related facts about bridges or tunnels. Moreover, an automatic translation of existing inspection data into Linked Data Models is possible due to the compatibility with SIB-Bauwerke, which stores the maintenance data for most infrastructure artefacts in Germany for more than 20 years. 3 3.1
The \Anweisung Stra eninformationsbank, Teilsystem Bauwerksdaten\
(ASBING) [engl.Instruction for Road Information Database, subsystem structural
data] [
The structure and content of ASB-ING follow the speci cations made in the
"Guideline for the uniform collection, assessment, recording and evaluation of
results of structural tests according to DIN 1076" (RI-EBW-PR UF) [
The ASB-ING is updated periodically to re ect new developments in the eld of infrastructure and maintenance. Currently, a new version of the ASB-ING standard is under development, modelled in UML. It is a hierarchical data structure containing about 120 classes, more than 500 attributes and 3000 prede ned value assignments, all related by restricted relations representing mandatory rules and standards. We have been given access to this new model for research purposes, but it has not yet been published. If we mention the ASB-ING model in the following sections, we refer to the new version from 2020. The ASB-ING data model covers general information, like the metadata or administrative data and structure related aspects, containing the building elements and their type and material speci cation. The building elements are related by aggregations to represent the modular building structure. Additionally, the ASB-ING model de ned classes to document the monitoring processes and the resulting structure assessments with determined damages and related (recommended) measures (see gure 1). The classes of the di erent domains are related by restricted associations to display the dependencies and logical or rule-based constraints (see diagram 1 and 2).
Each class can have several attributes. For attributes concerning numeric information, like geometry or quantity data, the values have de ned data types but can be lled individually (e.g. "Length" must be given in metres, the value can be any decimal number). There are also "union data types" that combine various simple attributes. For example, the data type "duration" consists of several individual attributes like "Years", "Months", "Days", and so on.
For attributes describing semantic information, the value assignment is managed via prede ned terms stored in "key table"/dictionary classes. Such dictionaries are similar to the standardise PSets in IFC, the ADEs in CityGML or the dictionaries in OKSTRA. In this way, a standardised description and de nition of entities are ensured. Each "key table" class covers one topic, e.g. "damage type" or "building element type". Each topic has speci cations, structured hierarchically and stored with an ordering number (the key). For example, the "damage type"-key table has the speci cation "4.2 { Surface damage metal" and "4.2.1.4 { Rusted". The ASB-ING model has about 240 of those "dictionaries" and more than 3000 de ned terms.
The ASB-ING is a detailed data model covering a signi cant proportion of entities needed for a comprehensive digital information model of bridges and tunnels and their maintenance data. Since relations and dependencies are modelled, rule-based queries can be derived from them. Due to its UML format, the content is easy to access for further processing.
For general purposes, not related to German inspection processes, the data structure could be too complex and should be broken down to its elementary structure. The value-assignment is not straightforward, but the standardised terms could be an entry point for automatic processing. What is missing are geometric model entities representing their semantic counterpart. 4 4.1
To develop the ASB-ING Ontology, we use the Web Ontology Language OWL. Since UML, in which the ASB-ING model is provided, and OWL are similarly structured, the conversion process is uncomplicated. To implement the ontology, we used the following name spaces: { asb: https://w3id.org/asbingowl/core# { asbkey: https://w3id.org/asbingowl/keys# { asbkey13: https://w3id.org/asbingowl/keys/2013# { owl: http://www.w3.org/2002/07/owl# { rdfs: http://www.w3.org/2000/01/rdf-schema# { xsd: http://www.w3.org/2001/XMLSchema# Classes and Properties The conversion of the UML entities follows the comparison displayed in table 1. The ontology classes get relation de nitions to other classes if required and additional information like a label and an explanatory comment if available.
The value restriction of an attribute, de ned in the ASB-ING model, determines if this attribute is converted into a OWL Datatype or Object Property of the ontology. Attributes having textual or numeric values are de ned as Datatype Properties. Their datatype classes from the UML model (e.g. "Character string" or "Length") are additionally mapped to a suitable XSD datatype. Attributes pointing to "key table"- or union datatype classes are implemented as Object Properties in the ontology since they refer to other classes. All properties have a de ned domain and range, and if available, a label, a comment or a sub-property relation.
The diagrams in gure 3 show a part of the initial UML model compared to the ontology. As can be seen, the general structure and content of the domain model are not changed but merely transferred to the respective OWL types. A current version of the complete ontology can be found via its URI an at GitHub 1. Key tables The translation of the key tables requires some more attention. Each key table contains a list of key-value pairs. The original concept of the ASB-ING model is to access them via the attributes "Text" and "Key" of the key class. However, we decided to transform each key-value pair into an individual class. A class is more expressive as a simple textual value, facilitates the value-assignment, can have several semantic annotations, and is easier to access via queries. Each "key-value-pair" class is named by combining the individual value name and its super-class (dictionary) name. The order number is stored using the attribute "Kennung". As the value-key pairs are structured hierarchically, the corresponding classes are related to each other via sub-class relations. Additionally, all "key-value-pair"-classes are sub-classes of their key table class. Figure 4 displays the key tables in the ASB-ING UML model and their conversion to OWL classes.
Since the value-key pairs are initially modelled as value options, their semantic meaning is di erent from the main classes of the ontology. Thus, we decided to create a sub-ontology/vocabulary for these classes. It uses a distinct namespace (with the pre x "asbkey") to distinguish between these di erent kinds of classes.
As mentioned in section 3.1, we work with the new, unpublished version of the ASB-ING model. Nevertheless, the current documentation of bridges and tunnels is based on the previous version, which also has key tables with about 20.000 key-value pairs. As the mapping of the old keys to the new keys is not yet nished, we decided to transform also the "old" key-value pairs into OWL classes to enable the processing of existing data without the mapping. These "old" key-value-pair classes form another sub-ontology/dictionary, having the transitionary pre x \asbkey13". Figure 5 shows that each old key-value-pair class is named by combining the key number and its text. The hierarchical structure is represented via sub-class relations, and an "rdfs comment" alternatively presents all superordinate terms to ensure a quick human interpretation of the data.
The two key-class sub-ontologies are not entirely independent modules but rather a structured collection/vocabulary of all classes that can be used as the value of an Object Property of the core ASB-ING Ontology. Implementation Contrary to the previous ASB-ING model or other domain standards, the new ASB-ING model is provided in UML. This feature is what enables the implementation of the conversion approach in the rst place.
In essence, the UML model is exported as an XMI le, from which the classes, attributes, value data types and relations are retrieved. They are then de ned as the respective ontological entities. The old keys are provided as an Excel sheet, from which each key (= each row) is fetched and de ned as an OWL class. The complete code for automatically converting the UML model into a semantic ontology and the codes for creating the sub-ontologies are on GitHub 2. 2 https://github.com/AnneGoebels/ASB-ING Ontology 4.2
Concept for converting existing inspection data into Linked Data models Inspection data of most bridges and tunnels in Germany is stored in SIBBauwerke, which is based on the ASB-ING data model. Currently, reading, writing, and processing this data is only possible within this commercial software. Exporting data from SIB-Bauwerke delivers a zip le containing database les and a folder with images and 2D plans. Each database le contains one table covering one main topic (e.g. \building materials" or \damages"). The data of one bridge is divided into 61 tables, having altogether about 1500 columns.
Manual inspection or even further processing of the data in this format is complicated and challenging. The column names are illegible, and key table values are only represented via their key number. But using the ASB-ING Ontology, including the key-table sub-ontologies and a mapping table, these extensive data sets are processed and converted into RDF within minutes. Thus the data is accessible for Linked-Data methods and interpretable for external applications. The detailed process will be presented in a forthcoming paper, but a brief description of the process is provided to demonstrate the application of the ontology. Figure 6 displays a graphical overview of it.
Broadly de ned, the tables are the classes of the ontology, and their columns are the properties. The cells contain the actual values as textual or numerical input or as an encrypted key number. For the latter, the respective key class is searched in the sub-ontologies and used instead of the number.
Two mapping processes are required as those tables are structured based on the previous version of the ASB-ING. First, the old table and column names are mapped to their respective counterpart of the new ASB-ING model. We got access to this prede ned mapping table from the responsible authority. In the next step, we extend this mapping table with the new developed Ontology classes and properties. Finally, we use this table as a reference to directly get the ontological entity of the tables and columns of SIB-Bauwerke. In this way, each data input from the inspection documentation gets processed and transformed into its Linked Data representation. Altogether, they form an RDF-Graph, representing the maintenance information of one infrastructure facility.
This graph serves as a starting point for further processing of the information. For example, the entities from the inspection data can be linked to external geometric representations, technical drawings or related pictures. One issue that can bene t signi cantly from interlinked Data is the localisation of damage, which is currently only done via textual description. By a visual representation of damage in 2D plans or 3D models, the inspection process can be made more e cient and spatial analysis of weak areas can be performed. 5
The presented approach succeeds in translating the existing data model for infrastructure inspections into an ontology. Thus, with a minimum of manual data creation, an extensive ontology is derived mostly automated, corresponding to the established data structures used in practice. The ontology enables converting existing maintenance data into Linked Data Models, which are the basis for additional use cases requiring interoperable digital processing and analysis such as structural health monitoring, predictive maintenance etc.
The next step is to link and map the ASB-ING Ontology to other domainrelevant ontologies and structures, like OTL, BOT, BROT, ifcOWL etc. This way, infrastructure and inspection information captured with the ASB-ING Ontology can be enriched with external data and used in other contexts and applications.
For example, links between the converted inspection data graph (as outlined in section 4.2) and an IFC model by mapping the structural component classes of the ASB-ING Ontology with ifcOWL classes enables a mutual enrichment of both. The inspection data gets visual representation and geometric entities, and the IFC model is semantically enriched with infrastructure-speci c classes without an additional extension of the IFC schema.
The inclusion of the ASB-ING Ontology into the OTL framework of the
INTERLINK Project [
However, since the ASB-ING Ontology is quite complex, further investigations are necessary to determine the relevant subsets of classes and properties needed for alignments or mappings to the respective external data structures.
This research is part of the "TwinGen" project funded by the Federal Ministry of Transport and digital Infrastructure (BMVI). We would like to thank the Landesamt fur Stra enbau und Verkehr Mecklenburg-Vorpommern for supporting us with the new ASB-ING model, as well as the Regierungsprasidium Tubingen for giving us access to the mapping concepts and tables.