W3C

Time Ontology in OWL

W3C Working Draft 27 September 2006

This version:
http://www.w3.org/TR/2006/WD-owl-time-20060927/
Latest version:
http://www.w3.org/TR/owl-time
Previous versions:
(this is the first public version)
Editors:
Jerry R. Hobbs, University of Southern California / Information Sciences Institute
Feng Pan, University of Southern California / Information Sciences Institute 

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

Abstract

This document presents an ontology of temporal concepts, OWL-Time (formerly DAML-Time) [4,10], for describing the temporal content of Web pages and the temporal properties of Web services. The ontology provides a vocabulary for expressing facts about topological relations among instants and intervals, together with information about durations, and about datetime information. We also demonstrate in detail, using the Congo.com and Bravo Air examples from OWL-S [11], how this time ontology can be used to support OWL-S, including use cases for defining input parameters and (conditional) output parameters. A use case for meeting scheduling is also shown. In the appendix we also 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.

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 was prepared by the Ontology Engineering and Patterns Task Force of the Semantic Web Best Practices and Deployment Working Group (SWBPD). This work is part of the W3C Semantic Web Activity.

This document is a W3C First Public Working Draft published to solicit comments from interested parties. This Working Draft is not expected to become a W3C Recommendation. Comments on this document are encouraged and may be sent to public-swbp-wg@w3.org; please include the text "comment" in the subject line. All messages received at this address are viewable in a public archive.

At the time of publication the charter of the Semantic Web Best Practices and Deployment Working Group is expiring. A new Working Group, the Semantic Web Deployment (SWD) Working Group, is commencing. The charter of the SWD Working Group permits it to choose to take up this document and consider further work. At the time of publication no decision has been made by the SWD Working Group regarding further work in this area.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. The group does not expect this document to become a W3C Recommendation. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted 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. Topological Temporal Relations
  5. Duration Description
  6. Time Zones
  7. DateTime Description
  8. Use Cases for Web Services
    1. Use Cases for Input Parameters
    2. Use Cases for (Conditional) Output Parameters
  9. A Use Case for Scheduling
  10. Appendix A. Summary of Classes and Properties in the Time Ontology
  11. Appendix B. Time Zone Resource in OWL
  12. References
  13. Acknowledgments

General issues

Temporal information is so common that it’s hard to find a real world Web service without it. For example, whenever you place an online order, the order date is always part of your order. When you reserve a car at a car rental site, you have to specify the dates you need it. In response to this need, a temporal ontology, OWL-Time (formerly DAML-Time), has been developed for describing the temporal content of Web pages and the temporal properties of Web services. Its development is being informed by temporal ontologies developed at a number of sites and is intended to capture the essential features of all of them and make them and their associated resources easily available to a large group of Web developers and users. Although it can be used independently, we have made sure it works well with OWL-S. Advantages of OWL-Time over XML Schema datatype duration and dateTime will be discussed.

This document only presents the OWL encodings of the ontology. For a first-order logic axiomatization of the ontology, see [4,10]. In an extension of the time ontology [5,9], we also allow temporal predicates to apply directly to events, should the user wish, but here we restrict our treatment to temporal entities.

Use case examples

A simple use case example: "Suppose someone has a telecon scheduled for 6:00pm EST on November 5, 2006. 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 this use case we can specify the facts about the telecon and the meeting using our ontology in OWL that will allow a temporal reasoner to determine whether there is a conflict. See [A Use Case for Scheduling] section for details.

More examples: "Someone who does a Web search trying to find a place to buy a book needed before next Tuesday may or may not be able to use an online bookstore that promises delivery within five business days."

"Someone doing a genealogical search may want to specify that the birthdate of a person is between 15 and 45 years before a known marriage date."

More use case examples will be described in detail in [Use Cases for Web Services] section below.

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. Details in alternative syntaxes are given by links.

Topological Temporal Relations

There are two subclasses of TemporalEntity: Instant and Interval, and they are the only two subclasses of TemporalEntity:

:Instant
      a       owl:Class ;
      rdfs:subClassOf :TemporalEntity .
:Interval
      a       owl:Class ;
      rdfs:subClassOf :TemporalEntity .
:TemporalEntity
      a       owl:Class ;
      rdfs:subClassOf :TemporalThing ;
      owl:equivalentClass
              [ a       owl:Class ;
                owl:unionOf (:Instant :Interval)
              ] .

Intervals are, intuitively, things with extent and instants are, intuitively, point-like in that they have no interior points. It is generally safe to think of an instant as an interval with zero length, where the beginning and end are the same.

hasBeginning and hasEnd are relations between instants and temporal entities, and the beginnings and ends of temporal entities, if they exist, are unique. In some approach to infinite intervals, a positively infinite interval has no end, and a negatively infinite interval has no beginning. Hence, we use the relations hasBeginning and hasEnd in the ontology, rather than defining functions beginningOf and endOf, since the functions would not be total. hasBeginning, for example, can be specified as:

:hasBeginning
      a       owl:ObjectProperty ;
      rdfs:domain :TemporalEntity ;
      rdfs:range :Instant .

inside is a relation between an instant and an interval, and it is not intended to include beginnings and ends of intervals. There is a before relation on temporal entities, which gives directionality to time. If a temporal entity T1 is before another temporal entity T2, then the end of T1 is before the beginning of T2. Thus, before can be considered to be basic to instants and derived for intervals. 

Allen and Furgerson [1,2] have developed a calculus of binary relations on intervals (e.g., meets, overlaps) for representing qualitative temporal information and address the problem of reasoning about such information. The relations between intervals defined in their calculus can be defined in a relatively straightforward fashion in terms of before and identity on the beginning and end points. The standard interval calculus assumes all intervals are proper, and we do that here too. Proper intervals are ones whose beginning and end are different. It can be specified as:

:ProperInterval
      a       owl:Class ;
      rdfs:subClassOf :Interval ;
      owl:disjointWith :Instant .

OWL-Time provides the interval relations: intervalEquals, intervalBefore, intervalMeets, intervalOverlaps, intervalStarts, intervalDuring, intervalFinishes, and their reverse interval relations: intervalAfter, intervalMetBy, intervalOverlappedBy, intervalStartedBy, intervalContains, intervalFinishedBy. For example, the specification of intervalEquals is:

:intervalEquals
      a       owl:ObjectProperty ;
      rdfs:domain :ProperInterval ;
      rdfs:range :ProperInterval .

Duration Description

The duration of an interval (or temporal sequence) can have many different descriptions. An interval can be 1 day 2 hours, or 26 hours, or 1560 minutes, and so on. It is useful to be able to talk about these descriptions in a convenient way as independent objects, and to talk about their equivalences. We do this first in terms of a predicate called durationOf that takes eight arguments, one for a temporal thing, and one each for years, months, weeks, days, hours, minutes, and seconds. Then we will define a specific kind of individual called a "duration description", together with a number of functions relating the duration description to the values of each of the eight arguments. Thereby we convert the 8-ary predicate durationOf into eight binary relations that are more convenient for description logic-based markup languages, such as OWL:

:DurationDescription
      a       owl:Class ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:maxCardinality 1 ;
                owl:onProperty :seconds
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:maxCardinality 1 ;
                owl:onProperty :minutes
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:maxCardinality 1 ;
                owl:onProperty :hours
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:maxCardinality 1 ;
                owl:onProperty :days
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:maxCardinality 1 ;
                owl:onProperty :weeks
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:maxCardinality 1 ;
                owl:onProperty :months
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:maxCardinality 1 ;
                owl:onProperty :years
              ] .

An interval can have multiple duration descriptions (e.g., 2 days, 48 hours), but can only have one duration.

We use two different sets of properties for DateTimeDescription and DurationDescription, because their ranges are different. For example, year (in DateTimeDescription) has a range of xsd:gYear, while years (in DurationDescription) has a range of xsd:decimal so that you can say duration of 2.5 years.

iCalendar [3] is a widely supported standard for personal data interchange. It provides the definition of a common format for openly exchanging calendaring and scheduling information across the Internet. The representation of temporal concepts in this time ontology can be straightforwardly mapped to iCalendar. For example, duration of 15 days, 5 hours and 20 seconds is represented in iCalendar as P15DT5H0M20S, which can be represented in the time ontology as:

:duration
      a       :DurationDescription ;
      :seconds 20 ;
      :hours 5 ;
      :days 15 .

The relation hasDurationDescription is used to specify a duration description for a temporal entity:

:hasDurationDescription
      a       owl:ObjectProperty ;
      rdfs:domain :TemporalEntity ;
      rdfs:range :DurationDescription .

Other duration concepts can be straightforwardly defined. For example, duration "Year" can be defined as a subclass of "DurationDescription" with the restrictions that the "years" property is required (with "cardinality" of 1) and all other properties (e.g., "hours", "months") should not be present (with "cardinality" of 0):

:Year
      a       owl:Class ;
      rdfs:subClassOf :DurationDescription ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:cardinality 1 ;
                owl:onProperty :years
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:cardinality 0 ;
                owl:onProperty :months
              ] ;
      ...

      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:cardinality 0 ;
                owl:onProperty :seconds
              ] .
Here we use "cardinality = 0" instead of restricting the values of days, etc. to 0. The reason is that using "cardinality = 0" means all those properties/fields (days, etc.) should not be specified (i.e., the granularity is "year"), while restricting all those values to 0 means they all have a fixed value of 0 (i.e., x years 0 months 0 days ...) and the granularity is actually "second", which is not the correct semantics of "year".

It's worth pointing out that there is a distinction between a year as a duration and a calendar year. The year from December 22, 2006 to December 21, 2007 is the former but not the latter.

Time Zones

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 UTC hours, but are, e.g., offset half an hour. Seconds are not relative to the time zone.

Days, weeks, months and years are also relative to the time zone, since, e.g., 2006 began in the Eastern Standard time zone three hours before it began in the Pacific Standard time zone. Thus, predications about all datetime 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 the 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 was 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 shifted in April from Eastern Standard to Central Daylight time.

See [Appendix B] for the details about a time zone resource we developed in OWL.

DateTime Description

A datetime description has the following properties/fields: unitType, year, month, week, day, dayOfWeek, dayOfYear, hour, minute, second, and timeZone. The property unitType specifies the temporal unit type of the datetime description, and its domain is TemporalUnit:

:TemporalUnit
      a       owl:Class ;
      owl:equivalentClass
              [ a       owl:Class ;
                owl:oneOf (:unitSecond :unitMinute :unitHour :unitDay :unitWeek :unitMonth :unitYear)
              ] .

For example, the temporal unit type of 10:30 is minute (unitMinute), and the temporal unit type of March 20, 2006 is day (unitDay). The unit type is required. With a given temporal unit type, all the fields/properties for smaller units will be ignored. For instance, if the temporal unit type is day (unitDay), the values of the field/property hour, minute, and second, if present, will be ignored. Since datetime description is for describing datetime intervals, we defined a property, called hasDateTimeDescription with DateTimeDescription as the range, for datetime intervals. To represent "March 12 in 2006", for example, using datetime description, we need an instance of DateTimeDescription that has values only for unitType(unitDay), year(2006), month(3), and day(12). DateTimeDescription and hasDateTimeDescription are defined in OWL as:

:DateTimeDescription
      a       owl:Class ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:cardinality 1 ;
                owl:onProperty :unitType
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:maxCardinality 1 ;
                owl:onProperty :second
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:maxCardinality 1 ;
                owl:onProperty :minute
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:maxCardinality 1 ;
                owl:onProperty :hour
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:maxCardinality 1 ;
                owl:onProperty :day
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:maxCardinality 1 ;
                owl:onProperty :dayOfWeek
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:maxCardinality 1 ;
                owl:onProperty :dayOfYear
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:maxCardinality 1 ;
                owl:onProperty :week
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:maxCardinality 1 ;
                owl:onProperty :month
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:maxCardinality 1 ;
                owl:onProperty :year
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:maxCardinality 1 ;
                owl:onProperty :timeZone
              ] .
              
:hasDateTimeDescription
      a       owl:ObjectProperty ;
      rdfs:domain :DateTimeInterval ;
      rdfs:range :DateTimeDescription .

DateTimeInterval is a subclass of ProperInterval. Any TemporalEntity has a duration, but only DateTimeInterval can have DateTimeDescription (e.g., May 8 has a DateTimeDescription, but the interval from 1:30pm, May 8, to 1:30pm, May 9, does not. Both have a duration of a day. A DateTimeDescription is always a description of an interval (DateTimeInterval), not an instant, which can be described by inDateTime and inXSDDateTime, as described later in the section.

The domain of the property dayOfWeek is the class DayOfWeek:

:DayOfWeek
      a       owl:Class ;
      owl:equivalentClass
              [ a       owl:Class ;
                owl:oneOf (:Sunday :Monday :Tuesday :Wednesday :Thursday :Friday :Saturday)
              ] .

Other datetime concepts can be straightforwardly defined. For example, "January" can be defined as a a subclass of DateTimeDescription with the restrictions that the unitType property has allValuesFrom unitMonth and property month hasValue of 1:

:January
      a       owl:Class ;
      rdfs:subClassOf :DateTimeDescription ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:onProperty :unitType
                owl:hasValue :unitMonth
              ] ;
     rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:onProperty :month
                owl:hasValue --01 ;
              ] .

In order to specify that an instant is in a datetime interval, an inDateTime property/relation is defined similarly to hasDateTimeDescription as follows:

:inDateTime
      a       owl:ObjectProperty ;
      rdfs:domain :Instant ;
      rdfs:range :DateTimeDescription .

With this inDateTime relation, we can say that an instant happens at a specific time. For example, the beginning of a meeting, which is an instant, is at 6:00pm which is actually in a datetime interval of [6:00:00, 6:01:00). With inDateTime you do not describe instants; you only approximate them by confining them within an interval. This should generally be adequate. Where it is not, you can always define an instant in a roundabout way as the beginning of an interval.

We also defined in OWL two simpler relations, xsdDateTime and inXSDDateTime. The only difference between these two relations and the above hasDateTimeDescription and inDateTime relations is their ranges: these two simpler relations use the XML Schema datatype dateTime as their ranges, while the above uses DateTimeDescription:

:xsdDateTime
      a       owl:DatatypeProperty ;
      rdfs:domain :DateTimeInterval ;
      rdfs:range xsd:dateTime .

:inXSDDateTime
      a       owl:DatatypeProperty ;
      rdfs:domain :Instant ;
      rdfs:range xsd:dateTime .

To illustrate more clearly the difference between using DateTimeDescription and using the XML datatype dateTime, let’s look at a concrete example: an instant that represents the start of a meeing, called meetingStart, happens at 10:30am EST on 01/01/2006 can be expressed using both inXSDDateTime and inDateTime in OWL as:

:meetingStart
      a       :Instant ;
      :inDateTime
              :meetingStartDescription ;
      :inXSDDateTime
              2006-01-01T10:30:00-5:00 .

:meetingStartDescription
      a       :DateTimeDescription ;
      :unitType :unitMinute ;
      :minute 30 ;
      :hour 10 ;
      :day 1 ;
      :dayOfWeek :Sunday ;
      :dayOfYear 1 ;
      :week 1 ;
      :month 1 ;
      :timeZone tz-us:EST ;
      :year 2006 .

We can see from this example that it’s much more concise to use the XML Schema datatype dateTime. However, the advantage of using DateTimeDescription is that it can express more information than dateTime, such as "week", "day of week" and "day of year", so in the above example, we can also know that 01/01/2006 is Sunday, on the first day of the year, and in the first week of the year.

The namespace “tz-us” points to our US time zone data [17]. Moreover, each field of DateTimeDescription is separate so that it's easier to extract the value of some fields for the later use and easier to reason about.

OWL code for the time ontology

[RDF/XML]

Use Cases for Web Services

Congo.com and Bravo Air are the two examples used in the OWL-S 0.9 draft release [12] (the most recent release is OWL-S 1.1 [13], and we use code in 0.9 draft release here for illustrative purpose). Congo.com is a fictitious book-selling service site, and Bravo Air is a fictitious airline-ticketing service site. We use these two examples to demonstrate in detail how the time ontology can be used to support OWL-S, including use cases for defining input parameters and (conditional) output parameters.

Use Cases for Input Parameters

In the profile of the Congo.com example (i.e. CongoProfile.owl), for example, our time ontology is currently used for describing the input parameter CreditCardExpirationDate:

profile:CreditCardExpirationDate
      a       profile:ParameterDescription ;
      profile:parameterName
              creditCardExpirationDate ;
      profile:restrictedTo
              time:Instant ;
      profile:referTo
              congoProcess:creditCardExpirationDate .

The namespace “time” points to the location of the OWL code for the time ontology. In this example Instant is used to describe CreditCardExpirationDate, because the expiration date is actually an instant -- the midnight, of the day the credit card expires.

In the Bravo Air example, our time ontology can be used to describe the existing input parameters, DepartureDate and ArrivalDate. We will change this to the more appropriate DepartureTime and ArrivalTime. We can define DepartureTime in the profile of the Bravo Air example (i.e. BravoAirProfile.owl) as: 

profile:DepartureTime
      a       profile:ParameterDescription ;
      profile:parameterName
              DepartureTime ;
      profile:restrictedTo
              time:Instant ;
      profile:referTo
              ba_process:outboundDate_In .

DepartureTime is defined as Instant. With this definition, as we discussed in the previous datetime description section, an instance of DepartureTime can has either an inXSDDateTime property/relation pointing to a specific value of XML Schema datatype dateTime, say 2006-01-01T10:30:00-5:00, or an inDateTime object-property/relation pointing to an instance of DateTimeDescription class specifying a specific time, say 10:30am EST on 01/01/2006, Sunday. It would be the user’s decision to define the time in either way based on the trade-offs discussed in the previous section.

Use Cases for (Conditional) Output Parameters

In fact, there is much more that our time ontology can do to support OWL-S. In the Congo.com and Bravo Air examples, the time ontology is not used for any output parameters. However, in the real world many service outputs are time-related. For example, in the Congo.com example we can add two outputs that are very common in real world book-selling sites: process time and delivery duration.

Adding a ProcessTime output parameter

ProcessTime is a conditional output parameter that specifies how long before the book will be ready for delivery, say, 24 hours, which depends on whether the book is in stock. In this use case, the process time is returned only if the book is in stock. It can be defined in the process model of the Congo.com example (i.e. CongoProcess.owl) as:

:ProcessTime
      a       owl:Class ;
      rdfs:subClassOf time:Interval .

:fullCongoBuyProcessTime
      a       rdf:Property ;
      rdfs:subPropertyOf process:output ;
      rdfs:domain :FullCongoBuy ;
      rdfs:range       
	      [ a       owl:Class ;
      		rdfs:subClassOf process:ConditionalOutput ;
      		rdfs:subClassOf
              		[ a       owl:Restriction ;
                	owl:allValuesFrom :BookInStock ;
                	owl:onProperty process:coCondition
              		] ;
	      ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:allValuesFrom :ProcessTime ;
                owl:onProperty process:coOutput
              ] .

ProcessTime is defined as an interval, rather than a duration. As discussed previously, in our time ontology durations are properties of intervals. Thus to talk about a duration, i.e. a quantity of time, an interval must be defined first. This approach may look roundabout at first glance. However, the process time is not purely a quantity of time; it has a location on the time line. The beginning of the process time is the time the user places the order, and the end of the process time is the time the order is shipped out. An advantage of defining ProcessTime as an interval is that if the relationship among the order time, the shipping time, and the process time is known, any one of them (e.g. the shipping time) can be computed from the other two (e.g. the order time and the process time) by temporal arithmetic.

Adding a DeliveryDuration output parameter

DeliveryDuration is a conditional output parameter that specifies how long it will take for the customer to receive the book after it is shipped out, which depends on the delivery type the customer selects. As defined in the process model of the Congo.com example (i.e. CongoProcess.owl), the current delivery types are FedExOneDay, FedEx2-3day, UPS, and OrdinaryMail.

To add this output parameter may seem similar to the above ProcessTime example. However, since an instance of Condition is a logical formula that evaluates to true or false (see the comment with the definition of Condition [14]), DeliveryType cannot be directly used as a condition to determine the delivery duration. Thus one property and one condition are defined for each delivery type.

DeliveryDuration is defined with two boundaries: one minDeliveryDuration and one maxDeliveryDuration. For example, an order with the FedEx2-3day delivery type takes 2 to 3 days, so its min delivery duration is 2 days, and its max delivery duration is 3 days. For the delivery duration of the order with FedExOneDay delivery type, the min and max delivery duration will both be 1 day. We can define DeliveryDuration in the process model of the Congo.com example (i.e. CongoProcess.owl) as:

:DeliveryDuration
      a       owl:Class ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:cardinality 1 ;
                owl:onProperty :maxDeliveryDuration
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:cardinality 1 ;
                owl:onProperty :minDeliveryDuration
              ] .

:maxDeliveryDuration
      a       rdf:Property ;
      rdfs:domain :DeliveryDuration ;
      rdfs:range time:Interval .

:minDeliveryDuration
      a       rdf:Property ;
      rdfs:domain :DeliveryDuration ;
      rdfs:range time:Interval .

Both minDeliveryDuration and maxDeliveryDuration are defined as properties of DeliveryDuration. For the same reason discussed for the process time example, both properties use Interval as their ranges. The cardinality of 1 for both properties in the definition of DeliveryDuration indicates that an instance of DeliveryDuration must have one and only one property value for minDeliveryDuration and maxDeliveryDuration respectively. For example, in order to define delivery duration for FedEx2-3day, we have to first define a condition of FedEx2-3day being selected:

:FedEx2-3dayCondition
      a       owl:Class ;
      rdfs:subClassOf process:Condition .

Then we define an output property, called deliverySelectFedEx2-3day that is conditional on FedEx2-3dayCondition defined above:

:deliverySelectFedEx2-3day
      a       rdf:Property ;
      rdfs:subPropertyOf process:output ;      
      rdfs:domain :SpecifyDeliveryDetails ;
      rdfs:range 
      	      [ a       owl:Class ;
      	      	rdfs:subClassOf process:ConditionalOutput ;
      	      	rdfs:subClassOf
              	      	[ a       owl:Restriction ;
                      	owl:allValuesFrom :FedEx2-3dayDuration ;
                      	owl:onProperty process:coOutput
              	      	] ;
      	      	rdfs:subClassOf
              	      	[ a       owl:Restriction ;
                      	owl:allValuesFrom :FedEx2-3dayCondition ;
                      	owl:onProperty process:coCondition
              ] .

This definition says that deliverySelectFedEx2-3day is a conditional output, and if FedEx2-3dayCondition is true, an instance of FedEx2-3dayDuration class will be the output. FedEx2-3dayDuration is not defined yet. In order to define it, we have to define its min delivery duration, i.e. 2 days, and max delivery duration, i.e. 3 days. Since the range of minDeliveryDuration and maxDeliveryDuration is Interval, intervals with specific durations need to be created first. For FedEx2-3dayDuration, we need to define Interval2Days and Interval3Days first as follows:

:Interval2Days
      a       owl:Class ;
      rdfs:subClassOf time:Interval ;
      owl:subClassOf
              [ a       owl:Restriction ;
                owl:hasValue P2D ;
                owl:onProperty time:durationDescriptionDataType
              ] .

:Interval3Days
      a       owl:Class ;
      rdfs:subClassOf time:Interval ;
      owl:subClassOf
              [ a       owl:Restriction ;
                owl:hasValue P3D ;
                owl:onProperty time:durationDescriptionDataType
              ] .

These two definitions use durationDescriptionDataType, a relatively simpler duration property of Interval using the XML Schmea datatype duration as its range. P2D and P3D are values of the XML Schema datatype duration, meaning 2 days and 3 days.

Finally, FedEx2-3dayDuration restricts the value of minDeliveryDuration and maxDeliveryDuration to class Interval2Days and Interval3Days respectively as follows:

:FedEx2-3dayDuration
      a       owl:Class ;
      rdfs:subClassOf :DeliveryDuration ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:allValuesFrom :Interval3Days ;
                owl:onProperty :maxDeliveryDuration
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:allValuesFrom :Interval2Days ;
                owl:onProperty :minDeliveryDuration
              ] .

Properties to output delivery durations when the user selects other delivery types (FedExOneDay, UPS, and OrdinaryMail) can be defined similarly.

OWL code for these examples

[RDF/XML]

A Use Case for Scheduling

Suppose someone has a telecon scheduled for 6:00pm EST on November 5, 2006. 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 this use case we can specify the facts about the telecon and the meeting using our ontology in OWL that will allow a temporal reasoner to determine whether there is a conflict:

:telecon
      a       :Interval ;
      :hasBeginning :teleconStart .
      
:meeting
      a       :Interval ;
      :hasBeginning :meetingStart ;
      :hasDurationDescription
              :meetingDuration .

:teleconStart
      a       :Instant ;
      :inXSDDateTime
              2006-11-05T18:00:00-5:00 .

:meetingStart
      a       :Instant ;
      :inXSDDateTime
              2006-11-05T14:00:00-8:00 .

:meetingDuration
      a       :DurationDescription ;
      :minutes 45 .

The telecon and the meeting are defined as intervals. hasBeginning is used for specifying the start times of the meetings. The datetimes are specified using inXSDDateTime. The duration of the meeting is specified using the duration description class.

Appendix A. Summary of Classes and Properties in the Time Ontology

Classes (subclass relations)

Properties

Property Name

Domain

Range

before

TemporalEntity

TemporalEntity

after

TemporalEntity

TemporalEntity

hasBeginning

TemporalEntity

Instant

hasEnd

TemporalEntity

Instant

inside

Interval

Instant

intervalEquals

ProperInterval

ProperInterval

intervalBefore

ProperInterval

ProperInterval

intervalMeets

ProperInterval

ProperInterval

intervalOverlaps

ProperInterval

ProperInterval

intervalStarts

ProperInterval

ProperInterval

intervalDuring

ProperInterval

ProperInterval

intervalFinishes

ProperInterval

ProperInterval

intervalAfter

ProperInterval

ProperInterval

intervalMetBy

ProperInterval

ProperInterval

intervalOverlappedBy

ProperInterval

ProperInterval

intervalStartedBy

ProperInterval

ProperInterval

intervalContains

ProperInterval

ProperInterval

intervalFinishedBy

ProperInterval

ProperInterval

years

DurationDescription

xsd;decimal

months

DurationDescription

xsd;decimal

weeks

DurationDescription

xsd;decimal

days

DurationDescription

xsd;decimal

hours

DurationDescription

xsd;decimal

minutes

DurationDescription

xsd;decimal

seconds

DurationDescription

xsd;decimal

hasDurationDescription

TemporalEntity

DurationDescription

unitType

DateTimeDescription

TemporalUnit

year

DateTimeDescription

xsd;gYear

month

DateTimeDescription

xsd;gMonth

week

DateTimeDescription

xsd;nonNegativeInteger

day

DateTimeDescription

xsd;gDay

dayOfWeek

DateTimeDescription

DayOfWeek

dayOfYear

DateTimeDescription

xsd;nonNegativeInteger

hour

DateTimeDescription

xsd;nonNegativeInteger

minute

DateTimeDescription

xsd;nonNegativeInteger

second

DateTimeDescription

xsd;decimal

timeZone

DateTimeDescription

tzont;TimeZone

inDateTime

Instant

DateTimeDescription

inXSDDateTime

Instant

xsd;dateTime

hasDateTimeDescription

DateTimeInterval

DateTimeDescription

xsdDateTime

DateTimeInterval

xsd;dateTime

Appendix B. Time Zone Resource in OWL

We have developed a time zone resource [15] in OWL for not only the US but also the entire world, including three parts: the time zone ontology file [16], the US time zone instance file [17], and the world time zone instance file [18].

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 FIPS 55 county instances [19], and ISO country instances [20].

It can handle all the usual time zone and daylight savings cases. For example, Los Angles uses PST, the time offset from Coordinated Universal Time (UTC) is -8 hours, and it observed daylight savings from April 2 to October 29 in 2006. 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.

Use case examples

Suppose someone has a telecon scheduled for 6:00pm EST on November 5, 2006. 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.    

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 [17]:

: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 [17]:

: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 have the range of xsd:date. In the current instance files, different daylight saving policies were only defined for year 2006 as instances of EnumeratedDaylightSavingsPolicy, e.g. USA2006DLS for the United States, and EU2006DLS 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 [6,7].

OWL code for the time zone ontology

[RDF/XML]

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 USA2006DLS which specifies the start date of the DLS in 2006 is 04/02/2006 and the end date is 10/29/2006. Based on our current time, e.g. 1:50pm on 09/06/2006, we know the current time offset from the GMT at this location is -7 hours.

References

[1] Allen, J. F. 1984. Towards a general theory of action and time. Artificial Intelligence 23, pp. 123-154.

[2] Allen, J. F. and Ferguson, G. 1997. Actions and events in interval temporal logic. In Spatial and Temporal Reasoning. O. Stock, ed., Kluwer, Dordrecht, Netherlands, 205-245.

[3] Dawson, F. and Stenerson, D. 1998. Internet Calendaring and Scheduling Core Object Specification (iCalendar), RFC2445. http://www.ietf.org/rfc/rfc2445.txt

[4] Hobbs, J. R. and Pan, F. 2004. 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.

[5] Pan, F and Hobbs, J. R. 2004. Time in OWL-S. In Proceedings of the AAAI Spring Symposium on Semantic Web Services, Stanford University, CA, pp. 29-36.

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

[7] Pan, F. 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, pp. 30-37. 

[8] OWL code of the time ontology. http://www.w3.org/2006/time

[9] OWL code of the entry sub-ontology of time. http://www.w3.org/2006/time-entry

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

[11] OWL-S homepage. http://www.daml.org/services/owl-s/

[12] OWL-S 0.9 release. http://www.daml.org/services/daml-s/0.9/

[13] OWL-S 1.1 release. http://www.daml.org/services/owl-s/1.1/

[14] The process file of the OWL-S 0.9 release. http://www.daml.org/services/owl-s/0.9/Process.owl

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

[16] The time zone ontology file. http://www.w3.org/2006/timezone

[17] The US time zone instance file. http://www.w3.org/2006/timezone-us

[18] The world time zone instance file. http://www.w3.org/2006/timezone-world

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

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

Acknowledgements

The editors would like to thank Deborah McGuinness, Chris Welty, and the reviewers of the earlier versions of the doucment, i.e., Jeremy Carroll, John McClure, Libby Miller, and Guus Schreiber, for their very helpful feedbacks and comments to the document.