http://creativecommons.org/licenses/by/3.0/
Megan Katsumi
Ontology to capture concepts related to public transit.
November 7, 2017
Public Transit Ontology
icity-transit
http://ontology.eil.utoronto.ca/icity/PublicTransit/1.1/
1.2
Copyright @ 2016 Megan Katsumi, iCity Research Group
Changes from previous version:
- updated foundational ontologies
- added to existing definitions
- introduced the TransitIncident and the TransitTrip class
- imported TransportationSystem, Activity, Trip ontologies
Under development. See report on iCity Ontology v1.
Added for organizational purposes, to identify all properties defined in the Public Transit ontology.
Associates a person with a particular transit pass (e.g. valid for some transit system, with some cost, etc).
A boolean representation to incidate whether a person has a transit pass.
Indicates whether the vehicle assigned to the trip will be able to accomodate a wheelchair(s).
Indicates whether wheelchair boarding is possible at a particular stop point. True if at least some vehicles at the stop can be boarded by a rider in a wheelchair.
False if wheelchair boarding is not possible at the stop.
Undefined otherwise.
An Access Method is the means of access to a Line
An AccessMethod has a Monetary Value.
An AccessMethod may be valid for a specific distance or time.
true
1
1
1
1
A Route consists of a series of Route Sections.
A Route has some directionality.
A Route is executed by various Vehicles at different points in time.
1
A Route Section is part of some Route and consists of Route Links.
A Route Section begins and ends at a Stop Point.
1
1
0
1
2
3
4
5
6
7
Routes change over time. RoutePD captures the entire entity of a route, i.e. the route perdurant.
1
1
A Route Section is part of a Route and consists of Route Links.
1
1
ScheduledTransitTrip is a type of RecurringEvent that only has TransitTrips as occurrences. A ScheduledTransitTrip is scheduled on some Route, RouteLink, or RouteSection, however it is not necessarily the case that the trip is accessible to travelers at the beginning stop point. It is possible that the scheduled trip will not pick up any passengers, or that passengers must pre-arrange in order to be picked up by the scheduled trip. A Scheduled Transit Trip may have a pick-up type and/or drop-off type as defined by some Trip Access Arrangement Type: as scheduled, not available, arranged with agency, or arranged with driver.
ScheduledTransitTrips may be used to specify route and stop timetables. Like a TransitTrip, a ScheduledTransitTrip may be described as inbound or outbound with the isOutbound data property. Scheduled trips may be defined to require only the assignment of vehicles that accommodate a wheelchair rider(s); this property may be captured with the isWheelchairAccessible data property.
ScheduledTransitTrips may be used to specify route and stop timetables.
1
A StationStopPoint is a specialized type of Stop Point that contains multiple Stop Points.
Distinct from the concept of the station building.
1
1
1
A Stop Point marks the start or end of a Route Link.
A Stop Point has a Location.
A Person may enter or exit the transit vehicle at a Stop Point.
A Stop Point has a stop code: a short text or a number that uniquely identifies the stop for passengers.
A Stop Point has a name that people will understand in the local and tourist vernacular.
A Stop Point may or may not be wheelchair accessible. The wheelchairAccessible data property value indicates whether wheelchair boardings are possible from the specified stop, station, or station entrance.
1
Transit Incidents are events of interest that occur on a particular transit trip. Typically, they are problematic, unplanned issues resulting in some delay.
A TransitIncident is a subclass of Activity.
It is associated with some station or stop point.
An incident may be described (and so classified) by a predefined code: hasCode only xsd:String.
An incident will have some resulting caused gap (i.e. the time from the incident until the next train arrives at the station).
Added for organizational purposes, to identify all classes defined in the Public Transit ontology.
1
A TransitSystem is a collection of Routes.
A TransitSystem may be owned by some Organization.
A TransitSystem may be accessed by some Fare or Transit Pass.
1
Transit Systems change over time. TransitSystemPD captures the entire entity of a transit system, i.e. the transit system perdurant.
1
1
1
1
1
Regarding hasTransitVehicleId data property for TransitVehicle. The rationale for introducing a new property is that the ID assigned by the transit organization may differ from the manufacturer's ID which is a property we anticipate will apply to vehicles in general. In addition, we've opted to define this as a data property, however should additional semantics be required we anticipate the creation of a general hasId property, and specialized ID classes, (e.g. in this case, TransitVehicle hasId only TransitVehicleId).
1
A Vehicle Block represents a grouping of transit trips to be allocated to a particular vehicle. A transit trip is part of a single block and each block may contain multiple transit trips, therefore the allocatedFor property relating vehicle blocks and transit trips is inverse functional. Each block may be allocated multiple vehicles, but only one vehicle at a given point in time therefore the allocatedTo property which relates vehicle blocks to vehicles is functional.