5.1 Topological Temporal Relations

The basic structure of the ontology is based on an algebra of binary relations on intervals (e.g., meets, overlaps) developed by Allen and Ferguson [AL-84], [AF-97] for representing qualitative temporal information, and to address the problem of reasoning about such information.

This is implemented in the ontology starting with a class TemporalEntity which has properties that link to the temporal instants that define its beginning and end. There are two subclasses: Interval and Instant, and they are the only two subclasses of TemporalEntity. Intervals are, intuitively, things with extent and instants are, intuitively, point-like in that they have no interior points, but it is generally safe to think of an instant as an interval with zero length, where the beginning and end are the same. The class Interval has one subclass ProperInterval, which corresponds with the common understanding of intervals, in that the beginning and end are distinct, and whose membership is therefore disjoint from Instant. The class ProperInterval has one subclass, DateTimeInterval, whose position and extent may be expressed using a single GeneralDateTimeDescription or xsd:dateTime.

Allen and Ferguson [AL-84], [AF-97] 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, whose beginning and end are different.

5.2 Temporal reference systems, clocks, calendars

A set of ordered intervals (e.g. named dynasties, geological periods, geomagnetic reversals, tree rings) can make a simple form of temporal reference system that supports logical reasoning, known as an ordinal temporal reference system [ISO-19108].

Measurement of duration needs a clock. In its most general form a clock is just a regularly repeating physical event ('tick') and a counting mechanism for the 'ticks'. These counts may be used to logically relate two events and to calculate a duration between the events.

A calendar is a set of algorithms that enables clock counts to be converted into practical everyday dates and times related to the movement of astronomical bodies (day, month, year).

For many purposes it is convenient to make temporal calculations in terms of clock durations that exceed everyday units such as days, weeks, months and years, using a representation of temporal position in a temporal coordinate system [ISO-19108], i.e. on a number line with a specified origin, such as Julian date, or Unix time. This may be converted to calendar units when necessary for human consumption.

Nevertheless, in practice much temporal information is not well-defined, in that there may be no clear statement about the assumed underlying calendar and clock.

5.3 Time position and time units

Following the theoretical basis laid out by Allen and Ferguson, a time position has a finite extent, corresponding to the precision or temporal unit used. Thus,a GeneralDateTimeDescription or DateTimeDescription is strictly always a description of an interval (DateTimeInterval), not an instant, with a duration corresponding to the value of its unitType.

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

5.4 Duration

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. An interval can have multiple duration descriptions (e.g., 2 days, 48 hours), but can only have one duration.

Three classes support the description of the duration of an entity. Duration has properties to describe the duration using a scaled number (i.e. a temporal quantity). GeneralDurationDescription has a set of properties to specify a duration using calendar and clock elements, the definitions of which are given in the associated TRS description. Its subclass DurationDescription fixes the temporal reference system to the Gregorian calendar, so the hasTRS property may be omitted on individuals from this class.

7.1 iCalendar

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

7.2 Geologic timescale described as a graph of ProperInterval individuals

The geologic timescale is defined as a set of named intervals arranged in a hierarchy, such that there is only one subdivision of the intervals of each rank (e.g. 'Era') by a set of intervals of the next rank (in this case 'Period') [CR-05]. Since the relative ordering is well-defined this can therefore serve as an ordinal temporal reference system. Fig. 5 shows how the geologic timescale can be expressed as a set of :ProperIntervals related to each other using only intervalMetBy, intervalStartedBy, intervalFinishedBy. Many other interval relationships follow logically from the ones shown (for example 'Neogene Period' :intervalDuring 'Cenozoic Era') but these are sufficient to describe the full topology. 

For example, the interval known as the 'Phanerozoic Eon' is described as follows:

geol:Phanerozoic
  rdf:type :ProperInterval ;
  :hasBeginning geol:BasePhanerozoic ;
  :hasEnd geol:Present ;
  :intervalFinishedBy geol:Cenozoic ;
  :intervalMetBy geol:Proterozoic ;
  :intervalStartedBy geol:Paleozoic ;
  rdfs:label "Phanerozoic Eon"^^xsd:string ;
.

The beginning of the Phanerozoic is an Instant, described as follows:

geol:BasePhanerozoic
  rdf:type :Instant ;
  :inTimePosition [
      rdf:type :TimePosition ;
      :hasTRS <http://www.opengis.net/def/crs/OGC/0/ChronometricGeologicTime> ;
      :numericPosition "541.0"^^:Number ;
    ] ;
  rdfs:label "Base of Phanerozoic Eon"^^xsd:string ;
. 

Note that the position of this Instant is specified using a TimePosition, which is a numeric value relative to the temporal coordinate system indicated as the value of the hasTRS property.

The RDF representation of this example is available here.

7.3 DateTimeDescription vs dateTime

The following example illustrates the difference between using DateTimeDescription and using the XML datatype dateTime. An instant that represents the start of a meeting, called meetingStart, happens at 10:30am EST on 01/01/2006 can be expressed using both inXSDDateTime and inDateTime in OWL as:

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

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

It is much more concise to use the XML Schema datatype dateTime. Using DateTimeDescription more information can be expressed, such as "week", "day of week" and "day of year", so in the 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 US time zone data. Moreover, each field of DateTimeDescription is separate so that it is easier to extract the value of some fields for the later use and easier to reason about.

7.4 Temporal precision using DateTimeDescription vs dateTime vs TimePosition

For the purposes of radiocarbon dating (which is the technique used in geological age determination for materials up to around 60,000 years old) 1950 is conventionally defined as 'the Present' [RC-14]. This can be described as an individual :Instant, with its position expressed using any of the three alternatives:

geol:Present
  a :Instant ;
  :inDateTime [
      a :DateTimeDescription ;
      :unitType :unitYear ;
      :year "1950"^^xsd:gYear ;
    ] ;
  :inTimePosition [
      a :TimePosition ;
      :hasTRS <http://www.opengis.net/def/crs/OGC/0/ChronometricGeologicTime> ;
      :numericPosition "0.0"^^:Number ;
    ] ;
  :inXSDDateTime "1950-01-01T00:00:00Z"^^xsd:dateTime ;
  rdfs:label "The present"^^xsd:string ;
. 

Expressed using :DateTimeDescription the :unitType - which determines the precision - is set to:unitYear, and only the :year element is provided in the value. The TRS value is not provided explicitly, as it is fixed in the ontology description to <http://www.opengis.net/def/uom/ISO-8601/0/Gregorian>. In the :TimePosition variant, the TRS is given as <http://www.opengis.net/def/crs/OGC/0/ChronometricGeologicTime> which has units of millions of years, positive backwards. For the value expressed using xsd:dateTime the position within the year is set arbitrarily to midnight at the beginning of 1st January. This level precision is strictly spurious, but is required to satisfy the lexical pattern of the datatype.

7.5 Use of different temporal reference systems

The use of different temporal reference systems for the same absolute time is illustrated in the following examples. Abby's birthday is an Instant whose position may be expressed using the conventional XSD dateTime type as 2001-05-23T08:20:00+08:00:

ex:AbbyBirthday
     a :Instant ;
     :inDateTime ex:AbbyBirthdayHebrew ;
     :inTimePosition ex:AbbyBirthdayUnix ;
     rdfs:label "Abby's birthdate"^^xsd:string ;
     :inDateTime ex:AbbyBirthdayGregorian ;
     :inXSDDateTime "2001-05-23T08:20:00+08:00"^^xsd:dateTime ;
.

Using the DateTimeDescription class, the elements of the date and time using the Gregorian Calendar are split out into separate properties:

ex:AbbyBirthdayGregorian
     a :DateTimeDescription ;
     :day "---23"^^xsd:gDay ;
     :dayOfWeek :Wednesday ;
     :hour "8"^^xsd:nonNegativeInteger ;
     :minute "20"^^xsd:nonNegativeInteger ;
     :month "--05"^^xsd:gMonth ;
     :timeZone [
                     a tzont:TimeZone ;
                     tzont:GMToffset "+8" ;
                     tzont:name "AWST" ;
             ] ;
     :unitType :unitMinute ;
     :year "2001"^^xsd:gYear ;
.

The GeneralDateTimeDescription class may be used to express the same date using the Hebrew calendar:

ex:AbbyBirthdayHebrew
     a :GeneralDateTimeDescription ;
     :day "---01"^^:generalDay ;
     :hasTRS <http://dbpedia.org/resource/Hebrew_calendar> ;
     :month "--03"^^:generalMonth ;
     :year "5761"^^:generalYear ;
     :unitType :unitDay ;
.

The TimePosition class may be used to express the same position on the Unix time scale (i.e. the number of seconds since 1st January 1970):

ex:AbbyBirthdayUnix
     a :TimePosition ;
     :hasTRS <http://dbpedia.org/resource/Unix_time> ;
     :numericPosition 990577200 ;
     rdfs:label "Abby's birthdate in Unix time"^^xsd:string ;
.         

The RDF representation of this example is available here.

7.6 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"^^xsd:dateTime .

:meetingStart
      a       :Instant ;
      :inXSDDateTime
              "2006-11-05T14:00:00-8:00"^^xsd:dateTime .

: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.

7.7 Web commerce applications

Congo.com and Bravo Air are examples from the OWL-S 0.9 draft release [OWL-S]. Congo.com is a fictitious book-selling service site, and Bravo Air is a fictitious airline-ticketing service site. These examples demonstrate how the time ontology can be used to support OWL-S, including use cases for defining input parameters and (conditional) output parameters. 

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
              :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
              :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.

(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 :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 [PR-OS]), 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 :Interval .

:minDeliveryDuration
      a       rdf:Property ;
      rdfs:domain :DeliveryDuration ;
      rdfs:range :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 :Interval ;
      owl:subClassOf
              [ a       owl:Restriction ;
                owl:hasValue P2D ;
                owl:onProperty :durationDescriptionDataType
              ] .

:Interval3Days
      a       owl:Class ;
      rdfs:subClassOf :Interval ;
      owl:subClassOf
              [ a       owl:Restriction ;
                owl:hasValue P3D ;
                owl:onProperty :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.