As a transfer format between the infrastructure plan-
ning tools and the ontological model we make use of
an open source XML-schema named railML (Nash
et al., 2004), which offers a structured description
format for railway related content. We extended the
railML schema in order to cover a majority of infras-
tructural elements and their attributes as they are de-
fined in legal German directives for railway planning.
Then we adapted the concepts and correlations of
railML and created an initial conceptual OWL model.
During fruitful discussions this model is extended and
enriched by profound knowledge of railway experts.
3.1 railML - an XML Schema for the
Railway Domain
The railML XML schema has been developed since
2001 by the railML initiative, intending to establish
railML as an open-source standard format for data
exchange between diverse railway applications. This
includes tools for route simulation and disposition of
trains as well as timetable systems and applications
for railway infrastructure planning.
RailML consists of three subschemata covering
different aspects of the railway domain. There is
a subschema rolling stock in which elements and
attributes regarding train constellations and wagon
configurations are accumulated. A second is the
timetable subschema which is developed in order to
support the modeling of departure and arrival times
and the whole scheduling of train movements. At last
there is an infrastructure subschema. We focused on
this subschema of railML in which the representation
of physical elements concerning the railway route re-
sides. The element definitions range from tracks, sig-
nals and level crossings to security related parts like
train detection circuits or transponders for train de-
celeration and many more. Thus the infrastructure
subschema offers a good starting point for the under-
standing of infrastructural concepts and their correla-
tions. During our work we extended this subschema
in order to be capable to formalize the description of
interlocking elements as well.
3.2 Evolving a Formal Railway
Infrastructure Domain Model
We translated the hierarchical railway representation
of the railML infrastructure subschema into an en-
hanced ontological, meshed representation where the
hierarchical structure is broken open. RailML has
limitations thus is not comprehensive enough in or-
der to represent all infrastructural elements and their
attributes requested by , directives. In the ontological
model most of the original concepts and relations of
railML remain, but are augmented with sophisticated
interrelations tending to represent the legal directives.
As a concrete example we can have a look at the
concept signal in railML. A signal can be of the types
main-signal or distant-signal among others. In the
German railway infrastructure guidelines the correla-
tions between main and distant signals are defined in
a very detailed way. A distant signal, for instance, is
always placed before a main signal in order to notify
the engine driver what he has to be aware of. The
correct distances between the signals depend on the
maximum speed on the track as well as on the visibil-
ity of the signals, for example when they are placed in
bends. These directives cannot be encoded and veri-
fied using an XML schema, whereas the expressive-
ness of OWL and SWRL as ontology modeling lan-
guages permit the representation of such directives.
Our starting point was the key concept track,
where all other physical elements are aligned with.
Tracks as well as switches have a spatial extent and
can be interconnected among each other. All other
physical elements like signals, balises, train detection
elements and so forth are point-shaped and related to
tracks or switches. There do exist virtual elements
like routes and railway control centers, but these el-
ements are an overlay of physical elements and sub-
sume their spatial extent.
At figure 1 an excerpt of the class ontology is
shown. Classes are represented as ellipses. Indi-
viduals as red squares. Whereas datatype properties
are represented as named connections from classes to
blue squares showing their data type. At last object
properties are represented as named connections be-
tween classes. Base is the class where all other el-
ements are derived from. It contains the data type
properties id and name which provide a unique iden-
tifier and a human readable name for all instantiated
objects. Direct subclasses of Base are the classes Re-
lationalObject, DirectedPointObject and VirtualOb-
ject. RelationalObject is a base class for all phys-
ical elements which have a spatial extend namely
Tracks and Switches. DirectedPointObjects are uni-
dimensional aligned along the RelationalObjects via
the object property isOnRO and its corresponding in-
verse property hasDPO. As an example the Signal
class is shown at figure 1. It features a relation to
the class SignalType which basically consists of an
enumeration of possible signal types as defined in-
dividuals. In extracts the classification classes for
the verification tasks are shown. E.g. after a veri-
fication process the class Correct S Placement con-
tains all signals which are correctly positioned within
the bounds of their corresponding track elements re-
KMIS 2010 - International Conference on Knowledge Management and Information Sharing
178