5.1 3.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 :TemporalEntity which has properties that link to the temporal instants that define its beginning and end. There are two subclasses: Interval :Interval and Instant :Instant , and they are the only two subclasses of TemporalEntity :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 :Interval has one subclass ProperInterval :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 :Instant . The class ProperInterval :ProperInterval has one subclass, DateTimeInterval :DateTimeInterval , whose position and extent may be expressed using a single GeneralDateTimeDescription :GeneralDateTimeDescription or xsd:dateTime xsd:dateTimeStamp .

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 :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 3.2 Temporal reference systems, clocks, calendars

The position of an Instant may be given using the datatype xsd:dateTime xsd:dateTimeStamp (or one of the truncated forms xsd:date , xsd:gYearMonth , xsd:gYear ) which is built in to OWL 2 [ owl2-quick-reference OWL-2 ], and uses the conventional Gregorian calendar and 24-hour clock. While this satisfies most web applications, many other calendars and temporal reference systems are used in particular cultural and scholarly contexts. For example, the Julian calendar was used throughout Europe until the 16 ^th century, and is still used for computing key dates in some orthodox Christian communities. Lunisolar (e.g. Hebrew) and lunar (e.g. Islamic) calendars are currently in use in some communities, and many similar have been used historically. In scientific and technical applications, Julian date counts the number of days since the beginning of 4713 BCE, and Loran-C, Unix and GPS time are based on seconds counted from a specified origin in 1958, 1970 and 1980, respectively. Archaeological and geological applications use chronometric scales based on years counted backwards from ‘the present’ (defined as 1950 for radiocarbon dating [ RC-14 ]), or using named periods associated with specified correlation markers [ CR-05 ], [ , CR-14 ], [ , MF-13 ]. Dynastic calendars (counting years within eras defined by the reign of a monarch or dynasty) were used earlier in many cultures. In order to support these more general applications, the representation of temporal position and duration must be flexible, and annotated with the temporal reference system in use.

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 3.3 Time position and time units

OWL 2 has two built-in datatypes relating to time: xsd:dateTime and xsd:dateTimeStamp [ owl2-quick-reference OWL-2 ]. Other XSD types such as xsd:date , xsd:gYear , xsd:gMonth and xsd:gMonth [ xmlschema11-2 xsd:gYearMonth [ XSD-D ] are also commonly used in OWL applications. These provide for a compact representation of time positions using the conventional Gregorian calendar and 24-hour clock, with timezone offset from UTC if required. UTC.

Three classes in the ontology support a more explicit description of temporal position. All have a property hasTRS :hasTRS to indicate the temporal reference system TRS.  :TRS . TimePosition :TimePosition has properties to alternatively describe the position using a number (i.e. a temporal coordinate), or a nominal value (e.g. geologic time period, dynastic name, archeological era). GeneralDateTimeDescription :GeneralDateTimeDescription has a set of properties to specify a date-time using calendar and clock elements. Its subclass DateTimeDescription :DateTimeDescription fixes the temporal reference system to the Gregorian calendar, so the hasTRS :hasTRS property may be omitted on individuals from this class. Note DateTimeDescription covers the case that was defined in the original note, and retains the original class name. 

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

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

5.4 3.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.  entity. Duration :Duration has properties to describe the duration using a scaled number (i.e. a temporal quantity). GeneralDurationDescription :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 :DurationDescription fixes the temporal reference system to the Gregorian calendar, so the hasTRS :hasTRS property may be omitted on individuals from this class.

Issue 6

6.14 5.1 Class: DurationDescription DateTimeDescription vs dateTime

The following example illustrates the difference between using time:DurationDescription :DateTimeDescription Definition: Description of temporal extent structured with separate values for the various elements of a calendar-clock system. The temporal reference system is fixed to Gregorian Calendar, and using the range of each of the numeric properties is restricted to xsd:decimal Subclass of: time:GeneralDurationDescription Subclass of: time:hasTRS value <http://dbpedia.org/resource/Gregorian_calendar> Subclass of: time:years only xsd:decimal Subclass of: time:months only xsd:decimal Subclass of: time:weeks only xsd:decimal Subclass of: time:days only xsd:decimal Subclass of: time:hours only xsd:decimal Subclass of: time:minutes only xsd:decimal Subclass of: time:seconds only xsd:decimal Other duration concepts can be straightforwardly defined. For example, duration "Year" could be defined as a subclass of "DurationDescription" with the restrictions XML datatype xsd:dateTimeStamp . An instant that represents the "years" property is required (with "cardinality" start of 1) and all other properties (e.g., "hours", "months") should not a meeting, called ex:meetingStart , happens at 10:30am EST on 01/01/2006 can be present (with "cardinality" of 0): Note expressed using both :inXSDDateTime :Year was the only specialization of :DurationDescription and :inDateTime defined in the original OWL-Time. It has been retained but marked "deprecated".  OWL as:

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

      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:cardinality 0 ;
                owl:onProperty :seconds
              ] .

ex:meetingStartDescription
  a           :DateTimeDescription ;
  :unitType   :unitMinute ;
  :minute     30 ;
  :hour       10 ;
  :day        1 ;
  :dayOfWeek  :Sunday ;
  :dayOfYear  1 ;
  :week       1 ;
  :month      1 ;
  :timeZone   <https://www.timeanddate.com/time/zones/est> ;
  :year       2006 .

We It is much more concise to use "cardinality = 0" instead of restricting the values of days, etc. to 0. The reason is that XML Schema datatype xsd:dateTimeStamp . However, using "cardinality = 0" means all those properties/fields (days, etc.) should not :DateTimeDescription more information can be specified (i.e., expressed, such as "week", "day of week" and "day of year", so in the granularity example, we can also know that 01/01/2006 is "year"), while restricting all those values to 0 means they all have a fixed value Sunday, on the first day of 0 (i.e., x years 0 months 0 days ...) the year, and in the granularity first week of the year. Since, each field of :DateTimeDescription is actually "second", which separate it is not easier to extract the correct semantics value of "year". some fields for the later use and easier to reason about.

Note that there is a distinction between a year as a duration and a calendar year. The year from December 22, 2006 :timeZone property points to December 21, 2007 is the former but not the latter. a definition of US Eastern Standard Time.

6.15 5.2 Datatype: Number Use of different temporal reference systems

The datatype use of different temporal reference systems for the same absolute time is illustrated in the following examples. Abby's birthday is an Number :Instant provides for numbers whose position may be expressed using any of the conventional XSD types decimal (of which xsd:integer xsd:dateTimeStamp is a sub-type), float , or type as double (which allows exponential or scientific notation). 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:dateTimeStamp ;
.

Using the 6.16 Datatype: generalYear :DateTimeDescription RDFS Class: 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   <https://www.timeanddate.com/time/zones/awst> ;
  :unitType   :unitMinute ;
  :year       "2001"^^xsd:gYear ;
.

The time:generalYear :GeneralDateTimeDescription Definition: Year number - generalization of xsd:gYear, formulated as a text string with a pattern constraint class may be used to reproduce express the same lexical form as gYear. Note that date using the value-space is not defined, so a generic OWL2 processor cannot compute ordering relationships of values of this type.  Instance of: rdfs:Datatype Subclass of: owl:onDatatype xsd:string ;   owl:withRestrictions (       [         xsd:pattern "-?([1-9][0-9]{3,}|0[0-9]{3})(Z|(\\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00))?"^^xsd:string ;       ]     )  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 Note :TimePosition While this pattern achieves class may be used to express the correct lexical form, same position on the value-space is not defined, so a generic OWL2 processor cannot compute ordering relationships Unix time scale (i.e. the number of values 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 ;
.

Each of these examples refers to either a temporal reference system or time zone described externally, using its URI. RDF representations are available from DBPedia (e.g. http://dbpedia.org/resource/Unix_time ) though these do not have specific time semantics.

The RDF representation of this type. example is available here .

6.17 5.3 Datatype: generalMonth Temporal precision using DateTimeDescription vs dateTime vs TimePosition

For the purposes of xsd:gMonth, formulated as a text string with a pattern constraint to reproduce radiocarbon dating (which is the same lexical form as gMonth, except that values up to 20 are permitted, technique used in order geological age determination for materials up to support calendars with more than 12 months in the year. Note that the value-space around 60,000 years old) 'the Present' is not defined, so a generic OWL2 processor cannot compute ordering relationships of values of this type. Instance of: rdfs:Datatype Subclass of: owl:onDatatype xsd:string ;   owl:withRestrictions (       conventionally fixed at 1950 [         xsd:pattern "--(0[1-9]|1[0-9]|20)(Z|(\\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00))?"^^xsd:string ;       ]     )  RC-14 ]. This can be described as an individual Note :Instant While this pattern achieves the correct lexical form, the value-space is not defined, so a generic OWL2 processor cannot compute ordering relationships of values , with its position expressed using any of this type. 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:dateTimeStamp ;
  rdfs:label "The present"^^xsd:string ;
.

Expressed using : 6.18 Datatype: generalDay :DateTimeDescription RDFS Class: the : time:generalDay :unitType Definition: Day of month - generalization of xsd:gDay, formulated as a text string with a pattern constraint to reproduce which determines the same lexical form as gDay, except that values up to 99 are permitted, in order precision - is set to support calendars with more than 31 days :unitYear , and only the :year element is provided in a month. Note that the value-space value. The TRS value is not defined, so a generic OWL2 processor cannot compute ordering relationships of values of this type.  Instance of: rdfs:Datatype Subclass of: owl:onDatatype xsd:string ;   owl:withRestrictions (       [         xsd:pattern "---(0[1-9]|[1-9][0-9])(Z|(\\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00))?"^^xsd:string ;       ]     )  provided explicitly, as it is fixed in the ontology description to http://www.opengis.net/def/uom/ISO-8601/0/Gregorian .

In the Note :TimePosition While this pattern achieves the correct lexical form, variant, the value-space TRS is not defined, so a generic OWL2 processor cannot compute ordering relationships given as http://www.opengis.net/def/crs/OGC/0/ChronometricGeologicTime which has units of values millions of this type. years, starting from the present, positive backwards.

For the value expressed using xsd:dateTimeStamp the position within the year is set arbitrarily to midnight at the beginning of 1st January. This section level of precision is non-normative. strictly spurious, but is required to satisfy the lexical pattern of the datatype.

7.1 5.4 iCalendar

iCalendar [ RFC2445 DE-09 ] 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:

:hasDurationDescription
       ;
       20 ;
       5 ;
       15 .

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

The iCalendar homepage features the example of Abraham Lincoln's birthday as celebrated in 2008. This may be represented in multiple ways using OWL-Time, including the following.

As a :DateTimeInterval using the :DateTimeDescription form:

_:DTI-1
  rdf:type :DateTimeInterval ;
  dc:coverage """LOCATION:Hodgenville, Kentucky
    GEO:37.5739497;-85.7399606""" ;
  dc:date "2015-04-21T14:14:03.00"^^xsd:dateTimeStamp ;
  dc:description """Born February 12\\, 1809\\nSixteenth President (1861-1865)
    http://AmericanHistoryCalendar.com""" ;
  dc:subject "Civil War People" ;
  dc:subject "U.S. Presidents" ;
  rdfs:label "Abraham Lincoln" ;
  skos:closeMatch <2008-04-28-04-15-56-62-@americanhistorycalendar.com> ;
  :hasDateTimeDescription [
    rdf:type :DateTimeDescription ;
    :day "---12"^^xsd:gDay ;
    :hasTRS <http://www.opengis.net/def/uom/ISO-8601/0/Gregorian> ;
    :month "--02"^^xsd:gMonth ;
    :unitType :unitDay ;
    :year "2008"^^xsd:gYear ;
  ] ;
.

The boundaries of the interval are implicitly the beginning and end of the day specified in the :DateTimeDescription.

As a :DateTimeInterval using the :xsdDateTime form:

al:DTI-3  rdf:type :DateTimeInterval ;  rdfs:label "Abraham Lincoln" ;  :xsdDateTime "2008-02-12T00:00:00.00-05:00"^^xsd:dateTimeStamp ;
.

In this formulation, the length of the entity is implicitly one day, as there is no sub-day value provided in the :xsdDateTime property.

As a :TemporalEntity using the :TimePosition to define the beginning and end:

_:TE-2
  rdf:type :TemporalEntity ;
  rdfs:label "Abraham Lincoln" ;
  :hasBeginning [
    rdf:type :Instant ;
    :inTimePosition [
      rdf:type :TimePosition ;
      :hasTRS <http://dbpedia.org/resource/Unix_time> ;
      :numericPosition "1202752800"^^:Number ;
    ] ;
  ] ;
  :hasDuration [
    rdf:type :Duration ;
    :numericDuration "1"^^:Number ;
    :unitType :unitDay ;
  ] ;
  :hasEnd [
    rdf:type :Instant ;
    :inTimePosition [
      rdf:type :TimePosition ;
      :hasTRS <http://dbpedia.org/resource/Unix_time> ;
      :numericPosition "1202839200"^^:Number ;
    ] ;
  ] ;
.

In this formulation, the length of the entity is explict, as the value of the :hasDuration property.

Several other formulations are possible, some of which are shown in the RDF representation is available here .

7.2 5.5 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 graph can therefore serve as an ordinal temporal reference system. Fig. 5 shows how the geologic timescale can be expressed as a set of :ProperIntervals :ProperInterval s related to each other using only intervalMetBy :intervalMetBy , intervalStartedBy :intervalStartedBy , intervalFinishedBy :intervalFinishedBy . Many other interval relationships follow logically from the ones shown (for example 'Neogene Period' : intervalDuring :intervalDuring 'Cenozoic Era') but these the ones shown are sufficient to describe the full topology.  topology.

For example, the interval known as the 'Phanerozoic Eon' is a :ProperInterval 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 Eon is an Instant :Instant , described as follows:

geol:BasePhanerozoic
  rdf:type :Instant ;
  :inTimePosition [
      rdf:type :TimePosition ;
      :hasTRS <http:
      :numericPosition  ;
    ] ;

    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 :Instant is specified using a TimePosition :TimePosition , which is a numeric value relative to the temporal coordinate system indicated as the value of the hasTRS :hasTRS property.

The RDF representation of this example is available here .

7.3 5.6 DateTimeDescription vs dateTime Specialization by sub-classing

It may be useful to define specialized concepts by specialization.

January

The following example illustrates the difference between using For example, "January" can be defined as a a subclass of DateTimeDescription :DateTimeDescription and using with the XML datatype dateTime . An instant restrictions that represents the start of a meeting, called meetingStart , happens at 10:30am EST on 01/01/2006 can be expressed using both :unitType property has inXSDDateTime allValuesFrom unitMonth and property inDateTime :month in OWL as: hasValue of 1:

ex: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 ;
  ] .

Year

It is much more concise to use the XML Schema datatype dateTime . Using DateTimeDescription more information can For example, duration "Year" could be expressed, such defined as "week", "day of week" and "day a subclass of year", so in "DurationDescription" with the example, we can also know restrictions that 01/01/2006 is Sunday, on the first day "years" property is required (with "cardinality" of the year, 1) and in the first week all other properties (e.g., "hours", "months") should not be present (with "cardinality" of the year. 0):

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

The namespace “ tz-us ” points to US time zone data. Moreover, each field We use "cardinality = 0" instead of DateTimeDescription is separate so that it is easier to extract restricting the value values of some fields for the later use and easier days, etc. to 0. The reason about. 7.4 Temporal precision is that using DateTimeDescription vs dateTime vs TimePosition For "cardinality = 0" means all those properties/fields (days, etc.) should not be specified (i.e., the purposes of radiocarbon dating (which granularity is the technique used in geological age determination for materials up "year"), while restricting all those values 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 0 means they all have a fixed value of the three alternatives: geol:Present a :Instant ; :inDateTime [ a :DateTimeDescription ; :unitType :unitYear ; :year ^^xsd:gYear ; ] ; :inTimePosition [ a :TimePosition ; :hasTRS <http: :numericPosition ; ] ; :inXSDDateTime ^^xsd:dateTime ; rdfs:label ^^xsd:string ; . Expressed using : DateTimeDescription the : unitType - which determines the precision - is set to: unitYear , 0 (i.e., x years 0 months 0 days ...) 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 granularity is given as <http://www.opengis.net/def/crs/OGC/0/ChronometricGeologicTime> actually "second", 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 not the lexical pattern correct semantics of the datatype. "year".

The use of different temporal reference systems for the same absolute time is illustrated in the following examples. Abby's birthday Note that there is an Instant whose position may be expressed using the conventional XSD dateTime type a distinction between a year as 2001-05-23T08:20:00+08:00 : ex:AbbyBirthday a :Instant ; :inDateTime ex:AbbyBirthdayHebrew ; :inTimePosition ex:AbbyBirthdayUnix ; rdfs:label ^^xsd:string ; :inDateTime ex:AbbyBirthdayGregorian ; :inXSDDateTime ^^xsd:dateTime ; . Using the DateTimeDescription class, the elements of the date a duration and time using the Gregorian Calendar are split out into separate properties: ex:AbbyBirthdayGregorian a :DateTimeDescription ; :day ^^xsd:gDay ; :dayOfWeek :Wednesday ; :hour ^^xsd:nonNegativeInteger ; :minute ^^xsd:nonNegativeInteger ; :month ^^xsd:gMonth ; :timeZone [ a tzont:TimeZone ; tzont:GMToffset ; tzont:name ; ] ; :unitType :unitMinute ; :year ^^xsd:gYear ; . The GeneralDateTimeDescription class may be used to express the same date using the Hebrew calendar: ex:AbbyBirthdayHebrew a :GeneralDateTimeDescription ; :day ^^:generalDay ; :hasTRS <http: :month ^^:generalMonth ; :year ^^:generalYear ; :unitType :unitDay ; . a calendar year. The TimePosition class may be used year from December 22, 2006 to express the same position on December 21, 2007 is the Unix time scale (i.e. former but not the number of seconds since 1st January 1970): ex:AbbyBirthdayUnix a :TimePosition ; :hasTRS <http: :numericPosition ; rdfs:label ^^xsd:string ; . The RDF representation of this example is available here . latter.

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

       ;
       .
      
       ;
       ;
      
               .

ex:telecon
  a             :Interval ;
  :hasBeginning ex:teleconStart .
       ;
      
              "2006 .

ex:meeting
  a                       :Interval ;
  :hasBeginning           ex:meetingStart ;
  :hasDurationDescription ex:meetingDuration .
       ;
      
              "2006 .

ex:teleconStart
  a               :Instant ;
  :inXSDDateTime  "2006-11-05T18:00:00-5:00"^^xsd:dateTimeStamp .
       ;
       45 .

ex:meetingStart
  a               :Instant ;
  :inXSDDateTime  "2006-11-05T14:00:00-8:00"^^xsd:dateTimeStamp .
ex:meetingDuration
  a         :DurationDescription ;
  :minutes  45 .

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

7.7 5.8 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.  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 ex: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 :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 ex:DepartureTime ;
  profile:restrictedTo  :Instant ;
  profile:referTo       ba_process:outboundDate_In .

DepartureTime is defined as Instant :Instant . With this definition, as we discussed in the previous datetime description section, an instance of DepartureTime can has either an inXSDDateTime :inXSDDateTime property/relation pointing to a specific value of XML Schema datatype dateTime, say 2006-01-01T10:30:00-5:00, or an inDateTime :inDateTime object-property/relation pointing to an instance of DateTimeDescription :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 .

ex: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
                        ] ;

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

        ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:allValuesFrom :ProcessTime ;
                owl:onProperty process:coOutput
              ] .

    ] ;
  rdfs:subClassOf
    [ a                 owl:Restriction ;
      owl:allValuesFrom ex: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
              ] .

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

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

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

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

ex:minDeliveryDuration
  a           rdf:Property ;
  rdfs:domain ex: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:

       ;
       .

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

ex:deliverySelectFedEx2-3day
  a                   rdf:Property ;
  rdfs:subPropertyOf  process:output ;      
  rdfs:domain         ex:SpecifyDeliveryDetails ;
  rdfs:range 
    [ a               owl:Class ;
      rdfs:subClassOf process:ConditionalOutput ;
      rdfs:subClassOf
        [ a                 owl:Restriction ;
          owl:allValuesFrom ex:FedEx2-3dayDuration ;
          owl:onProperty    process:coOutput
        ] ;
      rdfs:subClassOf
        [ a                 owl:Restriction ;
          owl:allValuesFrom ex: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 :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
              ] .

ex:Interval2Days
  a               owl:Class ;
  rdfs:subClassOf :Interval ;
  rdfs: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
              ] .

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

These two definitions use durationDescriptionDataType , a relatively simpler duration property of Interval :Interval using the XML Schmea datatype duration xsd:duration as its range. P2D and P3D are values of the XML Schema datatype duration xsd: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
              ] .

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

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