http://creativecommons.org/licenses/by/3.0/ Megan Katsumi 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. November 29, 2016 iCity Transportation System Ontology icity-transportation http://ontology.eil.utoronto.ca/icity/TransportationSystem/ 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 1.0 Under development. Please see report on iCity Ontology v1. The WGS84 altitude of a SpatialThing (decimal meters above the local reference ellipsoid). altitude The WGS84 latitude of a SpatialThing (decimal degrees). latitude The relation between something and the point, or other geometrical thing in space, where it is. For example, the realtionship between a radio tower and a Point with a given lat and long. Or a relationship between a park and its outline as a closed arc of points, or a road and its location as a arc (a sequence of points). Clearly in practice there will be limit to the accuracy of any such statement, but one would expect an accuracy appropriate for the size of the object and uses such as mapping . location The WGS84 longitude of a SpatialThing (decimal degrees). longitude Added for organizational purposes, to identify the properties defined in the OTN. Added for organizational purposes, to identify all properties defined in the Transportation System ontology. Added for organizational purposes, to identify the data properties defined in the OTN. Added for organizational purposes, to identify the classes defined in the OTN. 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. $Date: 2009/04/20 15:00:30 $ A vocabulary for representing latitude, longitude and altitude information in the WGS84 geodetic reference datum. Version $Id: wgs84_pos.rdf,v 1.22 2009/04/20 15:00:30 timbl Exp $. See http://www.w3.org/2003/01/geo/ for more details. WGS84 Geo Positioning: an RDF vocabulary Recent changes to this namespace: $Log: wgs84_pos.rdf,v $ Revision 1.22 2009/04/20 15:00:30 timbl Remove the time bits which have been deal with elsewhere eg in iCal. Revision 1.21 2009/04/20 12:52:47 timbl try again Revision 1.20 2009/04/20 12:42:11 timbl Add Event (edited ages ago and never checked in), and location (following discussion http://chatlogs.planetrdf.com/swig/2009-04-20#T12-36-09) Revision 1.19 2009/04/20 12:36:31 timbl Add Event (edited ages ago and never checked in), and location (following discussion http://chatlogs.planetrdf.com/swig/2009-04-20#T12-36-09) Revision 1.18 2006/02/01 22:01:04 danbri Clarified that lat and long are decimal degrees, and that alt is decimal metres about local reference ellipsoid Revision 1.17 2004/02/06 17:38:12 danbri Fixed a bad commit screwup Revision 1.15 2003/04/19 11:24:08 danbri Fixed the typo even more. Revision 1.14 2003/04/19 11:16:56 danbri fixed a typo Revision 1.13 2003/02/19 22:27:27 connolly relaxed domain constraints on lat/long/alt from Point to SpatialThing Revision 1.12 2003/01/12 01:41:41 danbri Trying local copy of XSLT doc. Revision 1.11 2003/01/12 01:20:18 danbri added a link to morten's xslt rdfs viewer. Revision 1.10 2003/01/11 18:56:49 danbri Removed datatype range from lat and long properties, since they would have required each occurance of the property to mention the datatype. Revision 1.9 2003/01/11 11:41:31 danbri Another typo; repaired rdfs:Property to rdf:Property x4 Revision 1.8 2003/01/11 11:05:02 danbri Added an rdfs:range for each lat/long/alt property, http://www.w3.org/2001/XMLSchema#float Revision 1.7 2003/01/10 20:25:16 danbri Longer rdfs:comment for Point, trying to be Earth-centric and neutral about coordinate system(s) at the same time. Feedback welcomed. Revision 1.6 2003/01/10 20:18:30 danbri Added CVS log comments into the RDF/XML as an rdfs:comment property of the vocabulary. Note that this is not common practice (but seems both harmless and potentially useful). revision 1.5 date: 2003/01/10 20:14:31; author: danbri; state: Exp; lines: +16 -5 Updated schema: Added a dc:date, added url for more info. Changed the rdfs:label of the namespace from gp to geo. Added a class Point, set as the rdfs:domain of each property. Added XML comment on the lat_long property suggesting that we might not need it (based on #rdfig commentary from implementors). revision 1.4 date: 2003/01/10 20:01:07; author: danbri; state: Exp; lines: +6 -5 Fixed typo; several rdfs:about attributes are now rdf:about. Thanks to MortenF in #rdfig for catching this error. revision 1.3 date: 2003/01/10 11:59:03; author: danbri; state: Exp; lines: +4 -3 fixed buglet in vocab, added more wgs links revision 1.2 date: 2003/01/10 11:01:11; author: danbri; state: Exp; lines: +4 -4 Removed alt from the as-a-flat-string property, and switched from space separated to comma separated. revision 1.1 date: 2003/01/10 10:53:23; author: danbri; state: Exp; basic geo vocab geo A comma-separated representation of a latitude, longitude coordinate. lat/long