Rationale for this version

This version results from the drafting of the localisation package, and amends 1.0rc1 accordingly. Main changes:

• The composite pattern, allowing to build topology elements by aggregating other topology elements or part of linear elements, is suppressed. It is replaced by references to locations on other elements or parts of elements, using the notions of linear or area location in the localisation package.
• The "hasPort" property, renamed "port", now has two subproperties "port 0", "port 1" to allow a distinction of ports that is not dependent on lexical conventions: such conventions can of course be kept, but they are not accessible to reasoners.
  • port0 and port1 are used on linear element and allow to orient them; orientation is needed for localisation ("where on the linear element...").
  • port0 can also be used on any non-linear element as a reference from which users can number the other ports, using any convention (e.g. clockwise, etc.).

In addition, there is one enhancement:

• Listed port, a subclass of Port and OWLList, allows to list ports in any suitable way (on nonlinear elements), if needed.

... and one simplification:

• The reified versions of connexities and navigabilities were removed. Reason is, while connexities and navigabilities can be seen as temporal objects (they may change with time, as network topology changes), their time bounds can be expressed using e.g. annotation properties, allowing filtering of connexities and navigabilities, detection of conflicts such as a navigability and a non-navigability applying at the same time to the same ports, etc.
  • The simplification is huge (no need to use property chains in order to link reified navigabilities with ordinary navigability properties);
  • The loss of expressiveness is negligible, as temporal reasoning is not expected to go beyond filtering.
  • Interoperability with the ERA ontology is maintained. As a matter of fact, ERA uses reified navigabilities, and a property chain in the ERA ontology adapter, similar to those removed from the present version of topology, will establish the link. Please keep in mind that the expressiveness of the present topology ontology is higher: ERA navigability data can be imported, but navigabilities in the present topology are transitive at MICRO level and all other levels as well, without the need to go back to MICRO. To our knowledge, no other topology implementation allows that.

Topology: main diagram

The diagram uses the Graphol language as implemented in the EDDY ontology editor (see under tooling). Foreign classes or properties are in light brown. Most used classes and properties are in green.

As previously, net elements have ports for communicating with other net elements. The properties linking ports are immaterial, in the sense that they do not generally correspond to artefacts such as "a stretch of track". Such links are:

• connexity: expresses that two net elements are adjacent, abutted to each other (e.g. two track segments), or similar. In some cases, adjacency is not required: think of a turntable or a transfer table. We assume connexity to be symmetric (until somebody comes up with a counter-example).
• navigability: expresses the ability for any rolling stock using the network to travel from port A to port B without reversing direction. Navigabilities are not symmetric (think of sprung switches and their modern avatars using sensors and actuators).
• connexity and navigability are always transitive (if PortA with PortB and PortB with PortC, then portA with PortC). Two important precautions are:
  • for connexity as well as navigability, we distinguish elementary properties (what needs to be input) from their transitive closure (what a reasoner, such as HermiT or Pellet, would infer). This is a common precaution when using transitive properties (see also SKOS vocabulary for instance).
  • for navigabilities to be transitive (regardless of the network representation level), it must be expressed "from exit to exit". This is how the direction of travel is taken into account.

Simplest example: suppose we have the following track layout, consisting of two linear elements A and B such as track segments:

portA0------Linear Element A------portA1 [abutted to] portB0------ Linear Element B------portB1

Here the connexity property :portA1 :connectedWith :portB0 suffices (as it is symmetric, you will infer that B0 is also connected with A1).

Concerning navigabilities, you should express the following:

• left to right: :portA1 :navigableTo :portB1 (not B0), and
• right to left: :portB0 :navigableTo :portA0 (not A1) So a vehicle moving from left to right will leave element A through port A1, reach element B wia the connected port B0, and navigability tells that it can travel on B until B1.

Imagine that we replace linear element B by non-linear element B': similarly, entering B via B0 could be following by travelling internally until we reach another port B'1, B'2... if there is a corresponding navigability.

Why such precautions?

The caution around the modelling of navigabilities may seem excessive. The criticism "navigabilities are an external constraint that you wrongly import into infrastructure description" is however unfounded. The author heard it only once in ten years, but let us take time to refute it because it might reveal some fundamental misunderstanding:

• infrastructure and the topology describing one aspect of infrastructure is, in general, not directional. Tracks can be run in both directions (although there may be a "normal" direction in revenue service, on double-track lines); signalling and train detection systems can be reversed although that is not, again, the general case.
• rolling stock can generally reverse direction (in the case of freight train consists, that would often imply moving the locomotive to the other end).
• operating tracks, rolling stock, signalling in one direction or the other sometimes requires special precautions (operating rules and procedures), sometimes not.
• network topology does not import any of these partial constraints. Such constraints will have to be expressed elsewhere, when relevant (e.g. in rolling stock topology modelling).
• train operations however avoids travel direction reversal like the plague, fundamentally because of travel time hit and, above all, of huge capacity loss. This is a railway system-wide requirement. A parallel with highways comes to mind (highways and trucks have no "natural orientation", but no normal trip can include a reversal of direction).

Inverse properties

Inverse properties are defined on another diagram, for clarity sake.

Note: in some cases, inverse properties are superfluous. For instance, properties port, port0, port1 share the same inverse property, namely onElement.

Property chains

Property leadsTo is "syntactic sugar", allowing to determine whether there is a navigable path from a net element to another one, not bothering about the direction to take and not mentioning ports at all.

Note: leadsTo (transitive) is not the transitive closure of leadsTo. If it were, reversing travel direction could not be excluded.