icity-transportation
1.0
Under development. Please see report on iCity Ontology v1.
http://ontology.eil.utoronto.ca/icity/TransportationSystem/
Megan Katsumi
http://creativecommons.org/licenses/by/3.0/
iCity Transportation System Ontology
November 29, 2016
While most existing work attempts to describe the network based on its physical constructs, we model the network flow and the physical infrastructure separately. The motivation for this is that the constraints on transportation flow are something that is applied to the physical infrastructure. These constraints are distinct from the physical characteristics and so should be defined separately. Although some constraints may be related, such as flow constraints imposed by the size of the lane that an arc accesses, this is a specific relationship that should be captured rather than conflating the concepts. For example, there is nothing to stop a vehicle from going the wrong way on a road, except for the flow of traffic that is imposed on the system (and these constraints may change with time). This results in the identification of two key concepts: the Transportation Network (a directed graph), and the Transportation Infrastructure (a physical feature where transportation occurs).
We relate the Network and the Infrastructure by relating an Arc to a Transportation Complex (or other Road Segment) with the "accesses" property. In this way, we may define an Arc accessing various Transportation Complexes at different Levels of Detail (LOD).
In this representation Nodes do not access the Transportation Infrastructure nor are they part of it in any way. Both Nodes and Arcs may have implicit locations based on the infrastructure they access, however unlike the infrastructure classes, Nodes and Arcs are not Spatial Things. A Node may have a control (e.g. a signal) with a physical presence somewhere else (traffic lights apply to one side of the intersection, but are actually located on the other side of the intersection); by separating the physical infrastructure and the network flow we are able to accurately represent this.
Currently, there is no need to capture an aggregate Arc; in other words, we do not require a subArc relation. It is possible this may change as the requirements evolve.
Developed as part of the overall iCity ontology effort, the iCity-TransportationSystem ontology is designed to capture concepts related to the transportation system.
Changes from previous version:
-imported revised ontologies of activity (iCity-Activity) and change (iCity-Change).
Copyright @ 2016 Megan Katsumi, iCity Research Group
Added for organizational purposes, to identify all properties defined in the Transportation System ontology.
Future extensions should capture this semantics in greater detail.
AccessRestriction may apply to certain Vehicle types (bus, cab, eco-friendly), Vehicle properties (number of passengers), or attributes of the traveler themselves (e.g. no bicycles on transit between certain times).
1
1
1
1
1
1
1
1
2
1
1
1
1
1
1
1
Added for organizational purposes, to identify all classes defined in the Transportation System ontology.