W3C

Time Zone Resource in OWL

W3C Editor's Draft 18 April 2006

This version:
http://www.w3.org/2001/sw/BestPractices/OEP/Time-Zone-20060418
Latest version:
http://www.w3.org/2001/sw/BestPractices/OEP/Time-Zone
Previous versions:
http://www.isi.edu/~pan/SWBP/time-zone-note/time-zone-note.html
Editors:
Feng Pan, University of Southern California / Information Sciences Institute 
Jerry R. Hobbs, University of Southern California / Information Sciences Institute

Copyright © 2006 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.


Abstract

In this document, we describe a time zone resource in OWL we developed for not only the US but also the entire world, including the time zone ontology, the US time zone instances, and the world time zone instances. The time zone ontology will be described in detail, and then an anticipated use section will discuss how this ontology can be used. A temporal aggregates ontology [3,4] in OWL-Time [1,2] can be used to describe the daylight saving policies. For example, in the US daylight saving starts on the first Sunday of every April.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document is expected to be a part of a larger document that is intended to provide an introduction and overview of all ontology design patterns produced by the Semantic Web Best Practices and Deployment Working Group.

This document is a W3C Editor's Draft produced by the Ontology Engineering Patterns Task Force of the Semantic Web Best Practices and Deployment Working Group. This editor's draft has not been formally published by the W3C and is expected to change prior to publication.

Publication as a draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or made obsolete by other documents at any time. It is inappropriate to cite this document as other than work in progress.

Table of Contents

  1. General issues
  2. Use case examples
  3. Syntax for code
  4. Time Zone Resource
  5. Time Zone Ontology
  6. Anticipated Use
  7. References
  8. Changes

General issues

What hour of the day an instant is in is relative to the time zone. This is also true of minutes, since there are regions in the world, e.g., central Australia, where the hours are not aligned with GMT hours, but are, e.g., offset half an hour. Probably seconds are not relative to the time zone.

Days, weeks, months and years are also relative to the time zone, since, e.g. 2003 began in the Eastern Standard time zone three hours before it began in the Pacific Standard time zone. Thus, predications about all clock and calendar intervals except seconds are relative to a time zone. 

We have been referring to time zones, but in fact it is more convenient to work in terms of what we might call the "time standard" that is used in a time zone. That is, it is better to work with the Pacific Standard Time (PST) as a legal entity than with the PST zone as a geographical region. A time standard is a way of computing the time, relative to a world-wide system of computing time. For each time standard, there is a zone, or geographical region, and a time of the year in which it is used for describing local times. Where and when a time standard is used have to be axiomatized, and this involves interrelating a time ontology and a geographical ontology. These relations can be quite complex. Only the entities like PST and EDT, the time standards, are part of a time ontology.

If we were to conflate time zones (i.e. geographical regions) and time standards, it would likely result in problems in several situations. For example, the Eastern Standard zone and the Eastern Daylight zone are not identical, since most of Indiana is on Eastern Standard time all year. The state of Arizona and the Navajo Indian Reservation, two overlapping geopolitical regions, have different time standards during the daylight saving times -- one is Pacific and the other is Mountain.

Time standards that seem equivalent, like Eastern Standard and Central Daylight, should be thought of as separate entities. Whereas they function the same in the time ontology, they do not function the same in the ontology that articulates time and geography. For example, it would be false to say those parts of Indiana shift in April from Eastern Standard to Central Daylight time.

Use case examples

Suppose someone has a telecon scheduled for 6:00pm EST on November 5, 2005. You would like to make an appointment with him for 2:00pm PST on the same day, and expect the meeting to last 45 minutes. Will there be an overlap? In order to specify the facts about the telecon and the meeting and reason about the relation between them, a time zone ontology would be necessary to help a time ontology (e.g. OWL-Time) to resolve the time difference between EST and PST. [Anticipated Use] will be described in detail in a later section.  

Syntax for code

In keeping with SWBP policy, the code within the body of the note is in N3. Most of the code was generated by Protégé from the original OWL code in RDF/XML.


Time Zone Resource

We have developed a time zone resource [5] in OWL for not only the US but also the entire world, including three parts: the time zone ontology file [6], the US time zone instance file [7], and the world time zone instance file [8]. 

The time zone ontology links a preliminary geographic ontology with a time ontology. It defines the vocabulary about regions, political regions (countries, states, counties, reservations, and cities), time zones, daylight saving policies, and the relationships between these concepts. Its instances also link to other existing data on the Web, such as US states instances [9] (<us-states>), FIPS 55 county instances [10], and ISO country instances [11] (<iso>). 

A temporal aggregates ontology in OWL-Time can be used to describe the daylight saving policies. For example, in the US daylight saving starts on the first Sunday of every April

It can handle all the usual time zone and daylight savings cases. For example, Los Angles uses PST, the time offset from Greenwich Mean Time (GMT) is -8 hours, and it observed daylight savings from April 6 to October 26 in 2003. But it handles unusual cases as well. For example, in Idaho the northern part is in the Pacific zone, the southern part in the Mountain. The city of West Wendover, Nevada is in the Mountain time zone, while the rest of Nevada is in the Pacific. 

Time Zone Ontology

We take PoliticalRegion to be a subclass of Region with the following properties:

This can be defined in OWL as:

:PoliticalRegion
      a       owl:Class ;
      rdfs:subClassOf :Region ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:maxCardinality 1 ;
                owl:onProperty :name
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:maxCardinality 1 ;
                owl:onProperty :hasParentRegion
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:maxCardinality 3 ;
                owl:onProperty :hasTimeZone
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:maxCardinality 1 ;
                owl:onProperty :observesDaylightSavingsTime
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:maxCardinality 1 ;
                owl:onProperty :hasDaylightSavingsPolicy
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:minCardinality 0 ;
                owl:onProperty :exceptionalRegion
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:minCardinality 0 ;
                owl:onProperty :timeZonePart
              ] .

Countries, states, counties, cities, and reservations are all subclass of political regions with different range types for the hasParentRegion property.

For example, Country and State can be defined in OWL as:

:Country
      a       owl:Class ;
      rdfs:subClassOf :PoliticalRegion .
:State
      a       owl:Class ;
      rdfs:subClassOf :PoliticalRegion ;
      owl:subClassOf
              [ a       owl:Restriction ;
               owl:onProperty :hasParentRegion ; 
               owl:allValuesFrom :Country                 
              ] .
Time zones have two properties:

This can be defined in OWL as:

:TimeZone
      a       owl:Class ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:maxCardinality 1 ;
                owl:onProperty :name
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:maxCardinality 1 ;
                owl:onProperty :GMToffset
              ] .

We assume default reasoning is used for this ontology. When a political region lacks one of its properties, we will use the one from its parent region. Thus all political sub-regions of the United States get their DaylightSavingsPolicy values from that of the United States, provided their observesDaylightSavingsTime property is true. All counties in California get their hasTimeZone values from California, whereas the hasTimeZone value 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. Here is the OWL code of Nevada and West Wendover in the US time zone instance file [7]:

:us-states:NV
      a       :State ;
      :hasParentRegion iso:US;
      :hasTimeZone :PST ;
      :observesDaylightSavingsTime true ;
      :exceptionalRegion :NVWestWendoverCity .

:NVWestWendoverCity
      a       :City ;
      :name "West Wendover City" ;
      :stateOf us-states:NV ;
      :hasTimeZone :MST ;
      owl:sameIndividualAs
              <http://www.daml.org/2003/02/fips55/NV.owl#p83730> .

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. Here is the OWL encoding of Idaho County, Idaho in our US time zone instance file [7]:

:IDIdaho
      a       :County ;
      :name "Idaho County" ;
      :hasParentRegion
              us-states:ID ;
      :timeZonePart
              :IDIdahoPST , :IDIdahoMST ;
      owl:sameIndividualAs
              <http://www.daml.org/2003/02/fips55/ID.owl#c049> .
DaylightSavingsPolicy has one property:

EnumeratedDaylightSavingsPolicy, a subclass of DaylightSavingsPolicy, has the following properties:

This can be defined in OWL as:

:EnumeratedDaylightSavingsPolicy
      a       owl:Class ;
      rdfs:subClassOf :DaylightSavingsPolicy ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:maxCardinality 1 ;
                owl:onProperty :DLSendDate
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:maxCardinality 1 ;
                owl:onProperty :DLSstartDate
              ] .

DLSstartDate and DLSendDate properties take a complex XML Schema datatype [12] that we defined consisting of a sequence of an XML Schema gYear, gMonth and gDay (Gregorian). In the current instance files, different daylight saving policies were only defined for year 2003 as instances of EnumeratedDaylightSavingsPolicy, e.g. USA2003DLS for the United States, and EU2003DLS for the European Union. 

Alternatively, a temporal aggregates ontology in OWL-Time can be used to describe the daylight saving policies. For example, in the US daylight saving starts on "the first Sunday of every April", which can be expressed in OWL as:

:tseq
      a       :TemporalSeq ;
      :hasTemporalAggregateDescription
              :firstSunEveryApril .
:tseq-everyApril
      a       :TemporalSeq ;
      :hasTemporalAggregateDescription
              :everyApril .
:everyApril
      a       :TemporalAggregateDescription ;
      :hasTemporalUnit
              :unitMonth ;
      :hasithTemporalUnit 4 .

:firstSunEveryApril
      a       :TemporalAggregateDescription ;
      :hasContextTemporalSeq
              :tseq-everyApril ;
      :hasContextTemporalUnit
              :unitMonth ;
      :hasithTemporalUnit 7 ;
      :hasTemporalUnit
              :unitDay ;
      :hasPosition 1 .

This defines the desired temporal sequence tseq of class TemporalSeq which has a hasTemporalAggregateDescription property that points to a temporal aggregate description firstSunEveryApril that describes the temporal sequence. In order to describe this two-layered temporal sequence ("the first Sunday" of "every April"), the outside layer ("every April"), i.e. the context temporal sequence (tseq-everyApril), needs to be defined first. This context temporal sequence also has its own hasTemporalAggregateDescription property that points to everyApril which describes that it is the every 4th (hasithTemporalUnit of 4) month (hasTemporalUnit of unitMonth). The desired temporal sequence is then defined as "the first (hasPosition of 1) Sunday (hasithTemporalUnit of 7 and hasTemporalUnit of unitDayOfWeek) of every April (hasContextTemporalSeq of tseq-everyApril and hasContextTemporalUnit of unitMonth)".

For details about the temporal aggregates ontology and its use case examples, please see [3,4].

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 says it's a location of a state without specifying the county or city it is 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, e.g. the country US, 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.

For example, suppose the input location is a location in West Wendover, Nevada, but at first we only know it's in Nevada (please see the OWL code [in the previous section]). 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, e.g. 1:50pm on 04/02/2003, we know the current time offset from the GMT at this location is -7 hours.


References

[1] Jerry R. Hobbs and Feng Pan. An Ontology of Time for the Semantic Web. ACM Transactions on Asian Language Processing (TALIP): Special issue on Temporal Information Processing, Vol. 3, No. 1, March 2004, pp. 66-85.

[2] OWL-Time Homepage: http://www.isi.edu/~pan/OWL-Time.html 

[3] Feng Pan and Jerry R. Hobbs. 2005. Temporal Aggregates in OWL-Time. In Proceedings of the 18th International Florida Artificial Intelligence Research Society Conference (FLAIRS-2005), Clearwater Beach, Florida, pp. 560-565, AAAI Press, 2005. 

[4] Feng Pan. 2005. A Temporal Aggregates Ontology in OWL for the Semantic Web. In Proceedings of the AAAI Fall Symposium on Agents and the Semantic Web, Arlington, Virginia, 2005. 

[5] The homepage of the time zone resource in OWL. http://www.isi.edu/~pan/timezonehomepage.html

[6] The time zone ontology file. http://www.isi.edu/~pan/damltime/timezone-ont.owl

[7] The US time zone instance file. http://www.isi.edu/~pan/damltime/timezone-us.owl

[8] The world time zone instance file. http://www.isi.edu/~pan/damltime/timezone-world.owl

[9] A US states instance file. http://www.daml.ri.cmu.edu/ont/USRegionState.daml

[10] FIPS 55 County instance file. http://www.daml.org/2003/02/fips55/

[11] ISO Country instance file. http://www.daml.org/2001/09/countries/iso

[12] The XML schema file. http://www.isi.edu/~pan/damltime/timezone-dt.xsd
 


Changes