Time Zone Ontology Documentation Feng Pan and Jerry Hobbs USC Information Sciences Institute Outline of the Time Zone Ontology This ontology links a preliminary geographic ontology with a time ontology. Political regions, which are subclass of regions, have the following properties: name: at most one string. hasParentRegion: the parent political region (a subproperty of hasAncestorRegion) hasTimeZone: at most three time zones observesDaylightSavingsTime: true if the region goes on daylight savings time, false otherwise hasDaylightSavingsPolicy: the daylight saving policy that the region uses exceptionalRegion: exceptional sub-regions that have different time zones and/or daylight saving time policies (e.g. West Wendover, Nevada) timeZonePart: sub-non-political-regions that have different time zones and/or daylight saving time policies (e.g. two different time zone parts in Idaho County in Idaho State) Countries, states, counties, cities, and reservations are all subclass of political regions with different range types for the "hasParentRegion" property. EnumeratedDaylightSavingsPolicy, a subclass of DaylightSavingsPolicy, has the following properties: DLSstartDate: the date the region goes on daylight savings time DLSendDate: the date the region goes off daylight savings time When a political region lacks one of these properties, we will use the one from its parent region. Thus all political sub-regions of the United States get their "DaylightSavingsPolicy" from that of the United States, provided their "observesDaylightSavingsTime" property is true. All counties in California get their "hasTimeZone" from California, whereas the "hasTimeZone" is specified for each county in Kentucky and not for the state as a whole, since it is split between the Eastern and Central time zones. When most of a region is in one time zone, and only some exceptional sub-regions are in different time zones or have different daylight savings time policies, we use "exceptionalRegion" to point to each exceptional sub-region, e.g. West Wendover, which is in the Mountain time zone, is an exception in Nevada, which is otherwise in the Pacific time zone. When different parts of the same county are in different time zones, the "hasTimeZone" is not specified for the county. Instead the "hasTimeZone" is specified for each part with different time zones, and the "timeZonePart" property is used to point to the parts from the county instance, e.g. the two different time zone parts in Idaho County, Idaho. Flexible inputs and more efficiency are supported by using the "exceptionalRegion" and "timeZonePart" properties: if the input only says it's a location of a state without specifying the county/city it's in, then we can first go to its state and see whether we can find all the information we need there, i.e. time zone and daylight savings information. If the state doesn't have any "exceptionalRegion"s, then we don't need any more inputs for this location, and can safely go up along the political region hierarchy to the top of the hierarchy, which is the US country, and get all the information we need along the way to calculate the time offset from the GMT for this location. If the state does have any "exceptionalRegion"s, however, we have to check each exceptional region to see whether this location is in it or not, at this checking phase, more detailed information about this location may be needed, i.e., which county/city/reservation it is in. If it's in an exceptional county that further has "timeZonePart"s, then even more detailed information is needed from the input, i.e. which time zone part the location is in within this county. When reaching a sub-region with no "exceptionalRegion"s or "timeZonePart"s, we know for sure that no more input location information is needed and it's safe to go up along the political region hierarchy to the top, and get all the information we need to calculate the time offset from the GMT for this location. The properties "exceptionalRegion" and "timeZonePart" are redundant. The time zone information about regions with multiple time zones could be specified with either one. The heuristic we have used is to use "exceptionalRegion" when one part is very much larger than the other, and to use "timeZonePart" when they are roughly equal. Similarly, when only a few counties in a state differ from the rest of the state, we have used "exceptionalRegion", whereas when the number of counties in each time zone are roughly equal, we have spelled out the time zone information on a county-by-county basis. Currently the "DLSstartDate" and "DLSendDate" properties take a complex XMLSchema datatype that we defined consisting of a sequence of an XMLSchema gYear, gMonth and gDay (Gregorian). Currently this is defined only for the year 2003 as instances of "EnumeratedDaylightSavingsPolicy" for different daylight saving policies, e.g. "USA2003DLS" for the United States, and "EU2003DLS" for the European Union. We intend in the near future to implement an intensional description of these dates, so we can say daylight savings time starts on "the first Sunday in April" of every year. Time zones have two properties: name: at most one string GMToffset: an XMLSchema duration between -12 and +14 hours Instances are defined for the United States and the rest of the world separately. The OWL portions of the ontology are defined in the file http://www.isi.edu/~pan/damltime/timezone-ont.owl The OWL portions of the US instances are defined in the file http://www.isi.edu/~pan/damltime/timezone-us.owl The OWL portions of the world instances are defined in the file http://www.isi.edu/~pan/damltime/timezone-world.owl The XMLSchema portions of the ontology are defined in the file http://www.isi.edu/~pan/damltime/timezone-dt.xsd Anticipated Use The expected input to the ontology is a location, e.g., a city, and the output will be its current time offset, say -6 hours, from the Greenwich Mean Time(GMT). The ontology would be used as follows: given an input location, we first find in the ontology the lowest-level political region containing this location, say a county, then go up along the political region hierarchy based on the "hasParentRegion" property to the top of the hierarchy, usually a country. Along the path to the top, we get all the available information from each node (region) in order to calculate the time offset from the GMT. The information includes the time zone this location is in, whether it uses Daylight Savings (DLS) time, and if it does, what the start and end dates are. However, flexible inputs and more efficiency are supported by using the "exceptionalRegion" and "timeZonePart" properties, i.e. the location input does not have to be as detailed as the lowest-level political region, especially because usually only the information about what state it is in would be enough to calculate the time offset from the GMT for the input location. If the input only specifies the state without specifying the county, then we can first go to its state and see whether we can find all the information we need there, i.e. time zone and daylight savings information. If the state doesn't have any "exceptionalRegion"s, then we don't need any more inputs for this location, and can safely go up along the political region hierarchy to the top, and get all the information we need to calculate the time offset from the GMT for this location. If the state does have any "exceptionalRegion"s, however, we have to check each exceptional region to see whether this location is in it or not, at this checking phase, more detailed information about this location may be needed, say which county/city/reservation it is in. If it's in an exceptional county that further has "timeZonePart"s, then even more detailed information is needed from the input, i.e. which time zone part the location is in within this county. When reaching a region with no "exceptionalRegion"s or "timeZonePart"s, we know for sure that no more input location information is needed and it's safe to go up along the political region hierarchy to the top, and get all the information we need to calculate the time offset from the GMT for this location. For example, suppose the input location is a location in West Wendover, Nevada, but at first we only know it's in Nevada. In the ontology, we first find Nevada state, from which we see one exceptional region pointing to West Wendover City, then we ask for further input location information: which city is this location in? Say we get West Wendover City. Since it matches the exceptional region, we then go to the West Wendover City instance to get its time zone information, which is the Mountain time zone. Since there is no "exceptionalRegion"s or "timeZonePart"s in the West Wendover City instance, it's now safe for us to go up along the hierarchy to the top, the United States. Along the path, at Nevada State we learn this location uses DLS time, then at its parent region, the US, we learn the DLS policy used is "USA2003DLS" which specifies the start date of the DLS in 2003 is 04/06/2003 and the end date is 10/26/2003. Based on our current time which is 1:50pm on 04/02/2003, we know the current time offset from the GMT at this location is -7 hours.