Engineering projects in the railway domain typically involve a large number of subsystems. Therefore a common understanding of the domain is essential. In the past this has been provided by XML-based data exchange standards and UML-based object-oriented models. With the increasing adoption of semantic technologies for engineering projects the demand to provide these standard data models in the form of ontologies has grown. We describe requirements and challenges to define an open standard ontology for railway topologies based on existing standards. The purpose of the finished ontology will be to enable topological queries and reasoning for railway networks in a standardized and reusable manner.
A common understanding of the different railway subsystems is vital for successful railway engineering projects. Historically, plans, drawings and lists were used to exchange information for engineering between stakeholders. Digital equivalents replaced these artifacts. To simplify railway simulation and operation applications, data exchange formats were standardized. Ideally, we could simply integrate rail data exports and thereby enable a domain expert to query data from a wide array of systems in an integrated knowledge graph system.
Different rail infrastructure systems and subsystems are modelled by different tools resulting in a number of independent files describing the same real-world station. Automatically integrating these files is hardly feasible due to different modelling approaches and the lack of a canonical naming scheme of all different entities. To pose a query to a system with integrated data, domain experts have to know the domain model of the system well. Introducing yet-another domain model puts system adoption at risk.
We start to address these two problems with a common unified railway topology, formalised as an OWL ontology. RDF and OWL together with an
ETL (extract, transform, load) pipeline should simplify the data integration
task and international standards as a base should increase adoption [
Our ontology engineering process is guided by three resources: competency questions, adherence to data exchange standards and best practices.
In a first iteration the following two competency questions were chosen: 1. If a train runs from A to B on the railway network, which infrastructure elements (including their direction and orientation) will be traversed? 2. What are the possible paths between A and B on the railway network?
We have the following requirements regarding modelling the railway domain and adherence to existing data exchange standards: (i) The ontology must be able to represent the (logical) topology of a railway network, (ii) The ontology must at least contain the main infrastructure elements found in every railway network, i.e., track, switches, signal and (iii) The (logical) position and orientation of these infrastructure elements in the railway network must be defined.
When designing the railway ontology we are following ontology engineering best practices as far as possible. Specifically, the ontology should be vendor independent, reusable and openly available. The concepts of the ontology must be well documented (especially important in engineering as it must be absolutely clear which concepts of the real world correspond to concepts of the ontology) and the ontology should be minimal, i.e., does not contain any aspects not related to the topology of railway networks. 3
Historically, many different models for railway systems topology have been
proposed, starting with straightforward graph-based models, for example by
Hansen [
The component-port model – here every relevant infrastructure element is
represented by a component which is connected to other elements by ports. The
EURIS method [
The double vertex graph model – which is an extension of a standard
graphbased model. Instead of a single vertex, double vertices are used, each vertex
representing one possible direction of a vehicle on the railway network. Commercial
tools like the railway network simulation tool OpenTrack [
The connexity graph model turns earlier ideas upside down: instead of crossings
and switches being modelled as nodes, the connexity graph [
None of the earlier existing work with comparable goals like RaCoOn [
To avoid some of these limitations, ensure adoption and avoid creating
yetanother rail domain model, we reuse existing standards as far as possible. For our
purposes and requirements the most relevant standards are RTM and RailML.
RTM and RailML share a similar goal with our approach to “foster the Federation
of Railway Digital Models” [
Although RailML provides XML-Schema files, automatically generated ontologies turned out impractical and needed considerable manual effort to be practically usable. For example it is unclear if XSD element types correspond to classes of the ontology or are merely a construct for structuring the XML 1 https://ontology.tno.nl/smart-rail/ 2 http://www.disit.org/km4city/schema elementA
nr12 leftBranch switch elementB signal1 track1 netElement
rightBranch netElement ne1 elementA nr13 elementB elementA
nr23 elementB ne3 netElement netElement track2 signal2 signal3 track3 file. Similar problems, although to a lesser extent, occurred when automatically transforming the RailML UML model to an ontology.
We expect the number of concepts and properties of a usable ontology to be relatively small, thus we use a bottom up approach, i.e., add those concepts that are mandatory for satisfying the requirements of our envisioned ontology.
Figure 2 models the example topology of Fig. 1 by using the adapted concepts of RTM and RailML. On the topological level, based on the RTM, NetElements (ne1, ne2, ne3) are connected to each other by NetRelations (nr12, nr13, nr23). Attributes define how ends of NetElements, e.g., ends of a track, are connected. Functional infrastructure entities from RailML, tracks, signals and switches, are then attached to the topology entities and thereby located. 5
Knowledge Graphs and Semantic Web technologies are promising technologies to integrate rail data from different systems. The graph nature of rail networks together with a large number of highly interconnected parts and components suits graph-based representations well.
XML standards such as RailML have been created to mitigate the proliferation
of schemas and object-oriented models for a domain, i.e., to at least allow a
tool-independent exchange of data. Building on top of these efforts and together
with the RailML community, we are currently in the process of defining a reusable
standard ontology for rail topology and specific parts of rail infrastructure to
support engineering. This is an ongoing effort and we invite everybody interested
to contact us via email or the RailML forum. We also plan to contact research
groups that have done similar work in the past, e.g., the RAISO ontology [
In a typical engineering tool the data of a RailML file is converted into a tool-specific data schema. This conversion step is no longer needed in a Knowledge Graph system as the instance data based on the RailML ontology can be imported directly and linked to additional data sources. This enables the reuse of queries and algorithms based on the ontology.
Furthermore, we are currently working on mappings from existing proprietary infrastructure data to the presented ontology as well as an implementation to answer our competency questions.
While some features of SPARQL 1.1, such as property path expressions, are powerful tools to explore an RDF graph, it is not clear yet if, or to what extent, our competency questions can be answered by a SPARQL endpoint with OWL reasoning alone – extensive postprocessing might be necessary.
To guide future developments, we are working with different user groups to formulate more competency questions relevant for their business.