Abstract

The OWL-Time ontology is an OWL-2 DL ontology [owl2-direct-semantics] of temporal concepts, for describing the temporal properties of resources in the world or described in Web pages. The ontology provides a vocabulary for expressing facts about topological relations among instants and intervals, together with information about durations, and about temporal position including date-time information.

The namespace for OWL-Time terms is http://www.w3.org/2006/time#

The suggested prefix for the OWL-Time namespace is time

The (revised) OWL-Time ontology itself is available here.

The original OWL-Time ontology is still available there.

Note

The original namespace (http://www.w3.org/2006/time) remains and will remain valid. Terms in the original namespace may be deprecated by future versions of this document but will not be deleted. This policy will hold when the revised ontology is merged with the original, later in the standardization process. This initial publication is designed to solicit comments on this and all aspects of the current work.

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 is the first version of the Time Ontology in OWL to be developed by the Spatial Data on the Web Working Group, a joint activity of W3C and OGC. It builds on the original work done in 2006 by the (now closed) Semantic Web Best Practices and Deployment Working Group, edited by Jerry Hobbs and Feng Pan.

For OGC

This is a Public Draft of a document prepared by the Spatial Data on the Web Working Group (SDWWG) — a joint W3C-OGC project (see charter). The document is prepared following W3C conventions. The document is released at this time to solicit public comment.

This document was published by the Spatial Data on the Web Working Group as a Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-sdw-comments@w3.org (subscribe, archives). All comments are welcome.

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.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. 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.

This document is governed by the 1 September 2015 W3C Process Document.

1. Motivation and background

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, has been developed for describing the temporal content of Web pages, or the temporal properties of any resource denoted using a web identifier (URI), including real-world things if desired. 

This document presents the OWL encodings of the ontology. For a first-order logic axiomatization of the ontology, see [HP-04].

2. Changes from previous versions

This version of OWL-Time was developed in the Spatial Data on the Web Working Group (a joint activity involving W3C and the Open Geospatial Consortium). It is based on the earlier draft by Hobbs and Pan, [ owl-time-20060927] with modifications proposed by Cox, [CO-16] to support more general temporal positions. Specifically:

A number of requirements relating to Time were identified in the Spatial Data on the Web Use Cases & Requirements.

Notes are included to indicate where these have been addressed, or where they should be addressed.

Issue 1

https://www.w3.org/2015/spatial/track/issues/64 Most of the properties defined in the original ontology have global constraints on the domain and range. If the rdfs:domain were left unspecified, the properties could be used more widely without undesirable entailments. Their use in the context of the classes in the ontology is adequately controlled through guarded restrictions (local cardinality constraints)

Issue 2

https://www.w3.org/2015/spatial/track/issues/65 The Time ontology is concerned only with formalizing temporal intervals and instants, and does not include any predicates to tie temporal objects to spatial entities or features, or other things. The editors note that predicates that concern temporal behaviour and properties will usually be part of an application or associated with a community of practice. Nevertheless, there may be some generic predicates that could be conveniently provided as part of the generic time ontology. Some may already exist in the ontology (before, after, hasEnd, hasBeginning) but their rdfs:domain is :TemporalEntity, so this would need to be generalized to avoid inappropriate entailments. Else predicates with similar names could be provided for linking to other entities.

Note

The SDWWG requirement 5.56 Valid time relates to https://www.w3.org/2015/spatial/track/issues/65.

Issue 3

https://www.w3.org/2015/spatial/track/issues/26 Temporal vagueness requirement. Extended Data/Time Format (EDTF) is a detailed proposal for how to encode temporal vagueness, and some other concerns, by extending the xsd:dateTime syntax . The editors consider that would be the wrong direction since it would make the encoding inconsistent with all XSD-based processors. On the other hand, specific RDF properties matching the ones proposed in EDTF could be used to make it amenable to RDF reasoning. However, we should consider doing this in a separate namespace. Note that some of the concerns in EDTF are already accommodated in OWL-Time (e.g. 'unspecified' appears to only require the timeUnit to be chosen appropriately). 

Note

The SDWWG requirement 5.49 Temporal vagueness relates to https://www.w3.org/2015/spatial/track/issues/26.

Issue 4

https://www.w3.org/2015/spatial/track/issues/15 Past, present future - this appears to already be supported using capabilities in OWL-Time, but needs to be verified.

3. Namespaces

The namespace for OWL-Time is http://www.w3.org/2006/time#. OWL-Time does not re-use elements from any other vocabularies, but does use some built-in datatypes from OWL and some additional types from XML Schema Part 2.

The table below indicates the full list of namespaces and prefixes used in this document.

Prefix Namespace
ex http://example.org/time/
geol http://example.org/geologic/
owl http://www.w3.org/2002/07/owl#
rdf http://www.w3.org/1999/02/22-rdf-syntax-ns#
rdfs http://www.w3.org/2000/01/rdf-schema#
time or
no prefix
http://www.w3.org/2006/time#
tzont http://www.w3.org/2006/timezone#
xsd http://www.w3.org/2001/XMLSchema#

4. Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words must, must not, required, should, should not, recommended, may, and optional in this specification are to be interpreted as described in [RFC2119].

Data conforms to OWL-Time if:

5. Principles and vocabulary overview

This section is non-normative.

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.

UML-style diagram of temporal entity classes
Fig. 1 Core model model of temporal entities.
Issue 5

:durationOf was mentioned in the original draft, but not in the published ontology. It appears to have been replaced by :hasDuration.

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

The position of an Instant may be given using the datatype xsd:dateTimewhich is built in to OWL 2 [ owl2-quick-reference], 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 16th 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 Time position and time units

OWL 2 has two built-in datatypes relating to time: xsd:dateTime and xsd:dateTimeStamp [ owl2-quick-reference]. Other XSD types such as xsd:date, xsd:gYear, xsd:gMonth and xsd:gMonth [xmlschema11-2] 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.

Three classes in the ontology support a more explicit description of temporal position. All have a property hasTRS to indicate the temporal reference system TRS. 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 has a set of properties to specify a date-time using calendar and clock elements. Its subclass DateTimeDescription fixes the temporal reference system to the Gregorian calendar, so the 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. 

UML-style diagram of classes for temporal position
Fig. 2 Classes for temporal position.

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.

Note

These classes address the 'date' and 'time' requirement from 5.7 Date, time and duration

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.

Issue 6

https://www.w3.org/2015/spatial/track/issues/63 What is the best URI for the Gregorian calendar/clock system? <http://dbpedia.org/resource/Gregorian_calendar> or <http://www.opengis.net/def/uom/ISO-8601/0/Gregorian> .

Note

DurationDescription covers the case that was in the original note, and retains the original class name.

UML representation of Duration Description and associated classes
Fig. 3 Classes for temporal duration.
Note

These classes address the 'duration' requirement from 5.7 Date, time and duration

6. Vocabulary specification

Note

The SDWWG requirement 5.25 Multilingual support relates to the documentation of the ontology.

6.1 Class: TemporalEntity

RDF Class: time:TemporalEntity
Definition: A temporal interval or instant.
Instance of: owl:Class
Union of: [ time:Instant , time:Interval ]

Two properties, before, after, support ordering relationships between two TemporalEntitys.

Property: before

RDF Property: time:before
Definition: 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.
Instance of: owl:ObjectProperty
Domain: time:TemporalEntity
Range: time:TemporalEntity

 

Property: after

RDF Property: time:after
Definition: Gives directionality to time. If a temporal entity T1 is after another temporal entity T2, then the beginning of T1 is after the end of T2.
Instance of: owl:ObjectProperty
Inverse Property: time:before

Two properties, hasBeginning, hasEnd, support the describing the bounds of a TemporalEntity.

Property: hasBeginning

RDF Property: time:hasBeginning
Definition: Beginning of a temporal entity.
Instance of: owl:ObjectProperty
Domain: time:TemporalEntity
Range: time:Instant

 

Property: hasEnd

RDF Property: time:hasEnd
Definition: End of a temporal entity.
Instance of: owl:ObjectProperty
Domain: time:TemporalEntity
Range: time:Instant

Two properties, hasDuration, hasDurationDescription, provide alternative ways to describe the extent of a TemporalEntity.

Property: hasDuration

RDF Property: time:hasDuration
Definition: Duration of a temporal entity, expressed as a scaled value or nominal value
Instance of: owl:ObjectProperty
Domain: time:TemporalEntity
Range: time:Duration

 

Property: hasDurationDescription

RDF Property: time:hasDurationDescription
Definition: Duration of a temporal entity, expressed using a structured description
Instance of: owl:ObjectProperty
Domain: time:TemporalEntity
Range: time:DurationDescription

One property hasMember supports the inclusion of temporal entities in other resources.

Property: hasMember

RDF Property: time:hasMember
Definition: Supports the inclusion of temporal entities in other resources, such as temporal reference systems.
Instance of: owl:ObjectProperty
Range: time:TemporalEntity

 

6.2 Class: Interval

RDF Class: time:Interval
Definition: A temporal entity with an extent or duration
Subclass of: time:TemporalEntity

One property inside links to an Instant that falls inside the Interval.

Property: inside

RDF Property: time:inside
Definition: An instant that falls inside the interval. It is not intended to include beginnings and ends of intervals.
Instance of: owl:ObjectProperty
Domain: time:Interval
Range: time:Instant

 

6.3 Class: ProperInterval

RDF Class: time:ProperInterval
Definition: A temporal entity with non-zero extent or duration, i.e. for which the value of the beginning and end are different
Subclass of: time:Interval
Disjoint with: time:Instant

Thirteen properties support the set of interval relations defined by Allen and Ferguson [AF-97].

Schematic of Interval Relations
Fig. 4 The possible relations between time periods (adapted from [AF-97])

Property: intervalEquals

RDF Property: time:intervalEquals
Definition: If a proper interval T1 is intervalEquals another proper interval T2, then the beginning of T1 is the beginning of T2, and the end of T1 is the end of T2
Instance of: owl:ObjectProperty
Domain: time:ProperInterval
Range: time:ProperInterval

 

Property: intervalBefore

RDF Property: time:intervalBefore
Definition: If a proper interval T1 is intervalBefore another proper interval T2, then the end of T1 is before the beginning of T2
Instance of: owl:ObjectProperty
Domain: time:ProperInterval
Range: time:ProperInterval
SubProperty of: time:before

 

Property: intervalAfter

RDF Property: time:intervalAfter
Definition: If a proper interval T1 is intervalAfter another proper interval T2, then the beginning of T1 is after the end of T2
Instance of: owl:ObjectProperty
Inverse of: time:intervalBefore

 

Property: intervalMeets

RDF Property: time:intervalMeets
Definition: If a proper interval T1 is intervalMeets another proper interval T2, then the end of T1 is the beginning of T2
Instance of: owl:ObjectProperty
Domain: time:ProperInterval
Range: time:ProperInterval

 

Property: intervalMetBy

RDF Property: time:intervalMetBy
Definition: If a proper interval T1 is intervalMetBy another proper interval T2, then the beginning of T1 is the end of T2
Instance of: owl:ObjectProperty
Inverse of: time:intervalMeets

 

Property: intervalOverlaps

RDF Property: time:intervalOverlaps
Definition: If a proper interval T1 is intervalOverlaps another proper interval T2, then the beginning of T1 is before the beginning of T2, the end of T1 is after the beginning of T2, and the end of T1 is before the end of T2
Instance of: owl:ObjectProperty
Domain: time:ProperInterval
Range: time:ProperInterval

 

Property: intervalOverlappedBy

RDF Property: time:intervalOverlappedBy
Definition: If a proper interval T1 is intervalOverlappedBy another proper interval T2, then the beginning of T1 is after the beginning of T2, the beginning of T1 is before the end of T2, and the end of T1 is after the end of T2
Instance of: owl:ObjectProperty
Inverse of: time:intervalOverlaps

 

Property: intervalStarts

RDF Property: time:intervalStarts
Definition: If a proper interval T1 is intervalStarts another proper interval T2, then the beginning of T1 is the beginning of T2, and the end of T1 is before the end of T2
Instance of: owl:ObjectProperty
Domain: time:ProperInterval
Range: time:ProperInterval

 

Property: intervalStartedBy

RDF Property: time:intervalStartedBy
Definition: If a proper interval T1 is intervalStarted another proper interval T2, then the beginning of T1 is the beginning of T2, and the end of T1 is after the end of T2
Instance of: owl:ObjectProperty
Inverse of: time:intervalStarts

 

Property: intervalDuring

RDF Property: time:intervalDuring
Definition: If a proper interval T1 is intervalDuring another proper interval T2, then the beginning of T1 is after the beginning of T2, and the end of T1 is before the end of T2
Instance of: owl:ObjectProperty
Domain: time:ProperInterval
Range: time:ProperInterval

 

Property: intervalContains

RDF Property: time:intervalContains
Definition: If a proper interval T1 is intervalContains another proper interval T2, then the beginning of T1 is before the beginning of T2, and the end of T1 is after the end of T2
Instance of: owl:ObjectProperty
Inverse of: time:intervalDuring

 

Property: intervalFinishes

RDF Property: time:intervalFinishes
Definition: If a proper interval T1 is intervalFinishes another proper interval T2, then the beginning of T1 is after the beginning of T2, and the end of T1 is the end of T2
Instance of: owl:ObjectProperty
Domain: time:ProperInterval
Range: time:ProperInterval

 

Property: intervalFinishedBy

RDF Property: time:intervalFinishedBy
Definition: If a proper interval T1 is intervalFinishedBy another proper interval T2, then the beginning of T1 is before the beginning of T2, and the end of T1 is the end of T2
Instance of: owl:ObjectProperty
Inverse of: time:intervalFinishes

 

6.4 Class: DateTimeInterval

RDFS Class: time:DateTimeInterval
Definition: DateTimeInterval is a subclass of ProperInterval, defined using the multi-element DateTimeDescription
Subclass of: time:ProperInterval

Any TemporalEntity has a duration, but only DateTimeInterval can have DateTimeDescription. For example, 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.

Property: hasDateTimeDescription

RDF Property: time:hasDateTimeDescription
Definition: Value of DateTimeInterval expressed as a structured value.
Instance of: owl:ObjectProperty
Domain: time:DateTimeInterval
Range: time:GeneralDateTimeDescription

 

Property: xsdDateTime

RDF Property: time:xsdDateTime
Definition: Value of DateTimeInterval expressed as a compact value. 
Instance of: owl:DatatypeProperty
Domain: time:DateTimeInterval
Range: xsd:dateTime
Issue 7

Verify that this satisfies the SDWWG requirement 5.53 Update datatypes in OWL Time

 

6.5 Class: Instant

RDF Class: time:Instant
Definition: A temporal entity with zero extent or duration
Subclass of: time:TemporalEntity

Three properties, inXSDDateTime, inTimePosition, and inDateTime provide alternative ways to describe the temporal position of an Instant.

Property: inXSDDateTime

RDF Property: time:inXSDDateTime
Definition: Position of an instant, expressed using xsd:DateTime
Instance of: owl:DatatypeProperty
Domain: time:Instant
Range: xsd:dateTime
Issue 8

This property uses xsd:dateTime which was available in OWL v1. The datatype xsd:dateTimeStamp, which makes the timezone element mandatory instead of optional, was added in OWL2. Should anything be added to OWL-Time to allow for this? Need to balance backward compatibility concerns. See SDWWG requirement 5.53 Update datatypes in OWL Time

 

Property: inTimePosition

RDF Property: time:inTimePosition
Definition: Position of an instant, expressed  as a temporal coordinate or nominal value
Instance of: owl:ObjectProperty
Domain: time:Instant
Range: time:TimePosition

 

Property: inDateTime

RDF Property: time:inDateTime
Definition: Position of an instant, expressed using a structured description
Instance of: owl:ObjectProperty
Domain: time:Instant
Range: time:GeneralDateTimeDescription

 

6.6 Class: TRS

The class TRS is for temporal reference systems.

RDFS Class: time:TRS
Definition: A temporal reference system, such as a temporal coordinate system (with an origin, direction, and scale), a calendar-clock combination, or a (possibly hierarchical) ordinal system.
Instance of: owl:Class

No specific properties are provided for the class TRS, the definition of which is beyond the scope of this ontology. Nevertheless, an ordinal temporal reference system, such as the geologic timescale, may be represented using this ontology as a set of ProperIntervals, along with enough inter-relationships to support the necessary ordering relationships. See example below of Geologic Timescale.

Note

A taxonomy of temporal reference systems is provided in ISO 19108:2002 [ISO-19108], including (a) calendar + clock systems; (b) temporal coordinate systems; (c) temporal ordinal reference systems.

Issue 9

https://www.w3.org/2015/spatial/track/issues/66 Should we define a vocabulary for the definition of the other temporal reference system types? (Calendar+clock, temporal coordinate reference system). Perhaps as an additional annex to this document, alongside the Time Zone resource?

One property hasTRS supports links from an resource that requires it to a temporal reference system description.

Property: hasTRS

RDF Property: time:hasTRS
Definition: The temporal reference system used by a temporal position or extent description.
Instance of: owl:ObjectProperty
Instance of: owl:FunctionalProperty
Range: time:TRS
Note

This TRS support addresses the following requirements from the SDWWG: 5.9 Different time models, 5.48 Temporal reference system, 5.28 Nominal temporal references.

 


6.7 Class: TimePosition

RDF Class: time:TimePosition
Definition: A temporal position described using either a (nominal) value from an ordinal reference system, or a (numeric) value in a temporal coordinate system.
Instance of: owl:Class
Subclass of: time:hasTRS exactly 1
Subclass of: (time:numericPosition exactly 1)  or (time:nominalPosition exactly 1)

Two properties nominalPosition and numericPosition support the alternative descriptions of position or extent. One of these is expected to be present.

Property: nominalPosition

RDF Property: time:nominalPosition
Definition: The (nominal) value indicating temporal position in an ordinal reference system
Instance of: owl:DatatypeProperty
Domain: time:TimePosition
Range: xsd:string

The temporal ordinal reference system should be provided as the value of the hasTRS property

Property: numericPosition

RDF Property: time:numericPosition
Definition: The (numeric) value indicating position within a temporal coordinate system
Instance of: owl:DatatypeProperty
Domain: time:TimePosition
Range: time:Number

The temporal coordinate system should be provided as the value of the hasTRS property

6.8 Class: GeneralDateTimeDescription

RDFS Class: time:GeneralDateTimeDescription
Definition: Description of date and time structured with separate values for the various elements of a calendar-clock system
Instance of: owl:Class
Subclass of: time:hasTRS exactly 1
Subclass of: time:timeZone max 1
Subclass of: time:unitType exactly 1
Subclass of: time:year max 1
Subclass of: time:month max 1
Subclass of: time:week max 1
Subclass of: time:day max 1
Subclass of: time:hour max 1
Subclass of: time:minute max 1
Subclass of: time:second exactly 1
Subclass of: time:dayOfYear max 1
Subclass of: time:dayOfWeek max 1

Three properties hasTRS, timeZone, and unitType provide for reference information concerning the reference system and precision of temporal position values.

Property timeZone

RDF Property: time:timeZone
Definition: The time zone for clock elements in the temporal position
Instance of: owl:ObjectProperty
Domain: time:GeneralDateTimeDescription
Range: tzont:TimeZone

An ontology for time zone descriptions is provided below.

Issue 10

The time zone ontology provided in the Annex is immature and incomplete. Use of a tzont:TimeZone from that ontology as the range of an ObjectProperty in OWL-Time creates an implied dependency which is not ideal. We propose adding a stub class time:TimeZone into the the main namespace (i.e. no properties) which can then be a super-class or equivalent class to any time zone formalization.(Compare with time:TRS which is handled this way.)

Property unitType

RDF Property: time:unitType
Definition: The temporal unit which provides the precision of a date-time value or scale of a temporal extent
Instance of: owl:ObjectProperty
Domain: time:GeneralDateTimeDescription or time:Duration
Range: time:TemporalUnit

Six datatype properties year, monthday, hour, minute, second, together with timeZone (defined above) support the description of components of a temporal position in a calendar-clock system.  These correspond with the 'seven property model' described in ISO 8601 [ISO-8601] and XML Schema Definition Language Part 2: Datatypes [ xmlschema11-2], except that the calendar is not specified in advance, but is provided through the value of the hasTRS property (defined above).

Property year

RDF Property: time:year
Instance of: owl:DatatypeProperty
Domain: time:GeneralDateTimeDescription

 

Property month

RDF Property: time:month
Instance of: owl:DatatypeProperty
Domain: time:GeneralDateTimeDescription

 

Property day

RDF Property: time:day
Instance of: owl:DatatypeProperty
Domain: time:GeneralDateTimeDescription

 

Property hour

RDF Property: time:hour
Instance of: owl:DatatypeProperty
Domain: time:GeneralDateTimeDescription
Range: xsd:nonNegativeInteger

 

Property minute

RDF Property: time:minute
Instance of: owl:DatatypeProperty
Domain: time:GeneralDateTimeDescription
Range: xsd:nonNegativeInteger

 

Property second

RDF Property: time:second
Instance of: owl:DatatypeProperty
Domain: time:GeneralDateTimeDescription
Range: xsd:decimal

Two additional properties week and dayOfYear allow for the the numeric value of the week or day relative to the year. 

Property week

RDF Property: time:week
Definition: The number of the week within the year
Instance of: owl:DatatypeProperty
Domain: time:GeneralDateTimeDescription
Range: xsd:nonNegativeInteger

 

Property dayOfYear

RDF Property: time:dayOfYear
Definition: The number of the day within the year
Instance of: owl:DatatypeProperty
Domain: time:GeneralDateTimeDescription
Range: xsd:nonNegativeInteger

The property dayOfWeek provides the name of the day.

Property dayOfWeek

RDF Property: time:dayOfWeek
Definition: The day of week, whose value is a member of the class time:DayOfWeek
Instance of: owl:ObjectProperty
Domain: time:GeneralDateTimeDescription
Range: time:DayOfWeek

 

6.9 Class: DayOfWeek

RDFS Class: time:DayOfWeek
Definition: The day of week
Instance of: owl:Class

Seven individual members of DayOfWeek are included in the ontology, corresponding to the seven days used in the Gregorian calendar, and using the English names Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday.

Note

In this version of the ontology, membership of the class DayofWeek is open, to allow for alternative week lengths and different day names.

6.10 Class: DateTimeDescription

RDFS Class: time:DateTimeDescription
Definition: Description of date and time structured with separate values for the various elements of a calendar-clock system. The temporal reference system is fixed to Gregorian Calendar, and the range of year, month, day properties restricted to corresponding XML Schema types xsd:gYear, xsd:gMonth and xsd:gDay, respectively.
Subclass of: time:GeneralDateTimeDescription
Subclass of: time:hasTRS value <http://dbpedia.org/resource/Gregorian_calendar>
Subclass of: time:year only xsd:gYear
Subclass of: time:month only xsd:gMonth
Subclass of: time:day only xsd:gDay

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:

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

 

6.11 Class: TemporalUnit

RDFS Class: time:TemporalUnit
Definition: A temporal unit of measure, which provides a scale factor for a time quantity.
Instance of: owl:Class

Seven individual members of TemporalUnit are included in the ontology, corresponding to the elements of the standard calendar-clock: unitYear, unitMonth, unitWeek, unitDay, unitHour, unitMinute and unitSecond.

Note

In this version of the ontology, membership of the class TemporalUnit is open, to allow for additional temporal units used in some technical applications (e.g. millions of years, Baha'i month).

6.12 Class: Duration

RDFS Class: time:Duration
Definition: Duration of a temporal extent expressed as a number scaled by a temporal unit
Instance of: owl:Class
Subclass of: time:numericDuration exactly 1
Subclass of: time:unitType exactly 1

 

Property numericDuration

RDF Property: time:numericDuration
Definition: Value of a temporal extent expressed as a number scaled by a temporal unit
Instance of: owl:DatatypeProperty
Domain: time:Duration
Range: time:Number

 

6.13 Class: GeneralDurationDescription

RDFS Class: time:GeneralDurationDescription
Definition: Description of temporal extent structured with separate values for the various elements of a calendar-clock system.
Instance of: owl:Class
Subclass of: time:hasTRS exactly 1
Subclass of: time:years max 1
Subclass of: time:months max 1
Subclass of: time:weeks max 1
Subclass of: time:days max 1
Subclass of: time:hours max 1
Subclass of: time:minutes max 1
Subclass of: time:seconds exactly 1

Seven datatype properties years, months, weeks, days, hours, minute, and seconds support the description of components of a temporal extent in a calendar-clock system. These correspond with the 'seven property model' described in ISO 8601 [ISO-8601] and XML Schema Definition Language Part 2: Datatypes [xmlschema11-2], except that the calendar is not specified in advance.

Property years

RDF Property: time:years
Instance of: owl:DatatypeProperty
Domain: time:GeneralDateTimeDescription
Range: time:Number

 

Property months

RDF Property: time:months
Instance of: owl:DatatypeProperty
Domain: time:GeneralDateTimeDescription
Range: time:Number

 

Property weeks

RDF Property: time:weeks
Instance of: owl:DatatypeProperty
Domain: time:GeneralDateTimeDescription
Range: time:Number

 

Property days

RDF Property: time:days
Instance of: owl:DatatypeProperty
Domain: time:GeneralDateTimeDescription
Range: time:Number

 

Property hours

RDF Property: time:hours
Instance of: owl:DatatypeProperty
Domain: time:GeneralDateTimeDescription
Range: time:Number

 

Property minutes

RDF Property: time:minutes
Instance of: owl:DatatypeProperty
Domain: time:GeneralDateTimeDescription
Range: time:Number

 

Property seconds

RDF Property: time:seconds
Instance of: owl:DatatypeProperty
Domain: time:GeneralDateTimeDescription
Range: time:Number

 

6.14 Class: DurationDescription

RDFS Class: time:DurationDescription
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 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 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):

Note

:Year was the only specialization of :DurationDescription defined in the original OWL-Time. It has been retained but marked "deprecated". 

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

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

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

6.15 Datatype: Number

RDFS Class: time:Number
Definition: Generalized number
Instance of: rdfs:Datatype
Equivalent class: xsd:double
or xsd:float
or xsd:decimal

The datatype Number provides for numbers expressed using any of the XSD types decimal (of which xsd:integer is a sub-type), float, or double (which allows exponential or scientific notation).

6.16 Datatype: generalYear

RDFS Class: time:generalYear
Definition: Year number - generalization of xsd:gYear, formulated as a text string with a pattern constraint to reproduce the same lexical form as gYear. Note that 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 ;
      ]
    ) 
Note

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 of this type.

6.17 Datatype: generalMonth

RDFS Class: time:generalMonth
Definition: Month of year - generalization of xsd:gMonth, formulated as a text string with a pattern constraint to reproduce the same lexical form as gMonth, except that values up to 20 are permitted, in order to support calendars with more than 12 months in the year. Note that 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 "--(0[1-9]|1[0-9]|20)(Z|(\\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00))?"^^xsd:string ;
      ]
    ) 
Note

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 of this type.

6.18 Datatype: generalDay

RDFS Class: time:generalDay
Definition: Day of month - generalization of xsd:gDay, formulated as a text string with a pattern constraint to reproduce the same lexical form as gDay, except that values up to 99 are permitted, in order to support calendars with more than 31 days in a month. Note that 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 "---(0[1-9]|[1-9][0-9])(Z|(\\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00))?"^^xsd:string ;
      ]
    ) 
Note

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 of this type.

7. Examples

This section is non-normative.

7.1 iCalendar

Note

This example carried over from [owl-time-20060927].

iCalendar [RFC2445] 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
      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. 

(Part of) the international chronostratigraphic chart, formalized as a set of proper intervals
Fig. 5 Part of the geologic timescale formalized as ProperIntervals, with ordering relationships described using the predicates defined in this ontology.

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

Note

This example carried over from [owl-time-20060927].

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

Note

This example carried over from [owl-time-20060927].

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

Note

This example carried over from [owl-time-20060927].

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.


A. Summary of Classes and Properties in the Time Ontology

A.1 Classes (subclass relations)

A.2 Properties

Property Name Domain Range
before TemporalEntity TemporalEntity
after TemporalEntity TemporalEntity
hasBeginning TemporalEntity Instant
hasEnd TemporalEntity Instant
hasDuration TemporalEntity Duration
hasDurationDescription TemporalEntity GeneralDurationDescription
hasMember
TemporalEntity
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
hasDateTimeDescription DateTimeInterval GeneralDateTimeDescription
xsdDateTime DateTimeInterval xsd:dateTime
inTimePosition Instant TimePosition
inDateTime Instant GeneralDateTimeDescription
inXSDDateTime Instant xsd:dateTime
hasTRS
TRS
numericDuration Duration Number
years GeneralDurationDescription Number
months GeneralDurationDescription Number
weeks GeneralDurationDescription Number
days GeneralDurationDescription Number
hours GeneralDurationDescription Number
minutes GeneralDurationDescription Number
seconds GeneralDurationDescription Number
numericPosition TimePosition Number
nominalPosition TimePosition xsd:string
timeZone GeneralDateTimeDescription tzont:TimeZone
unitType GeneralDateTimeDescription TemporalUnit
year GeneralDateTimeDescription
month GeneralDateTimeDescription
day GeneralDateTimeDescription
hour GeneralDateTimeDescription xsd:nonNegativeInteger
minute GeneralDateTimeDescription xsd:nonNegativeInteger
second GeneralDateTimeDescription xsd:decimal
week GeneralDateTimeDescription xsd:nonNegativeInteger
dayOfYear DateTimeDescription xsd:nonNegativeInteger
dayOfWeek DateTimeDescription DayOfWeek

 


B. Time Zone Vocabulary

Note

This section unaltered from [owl-time-20060927].

Issue 11

The time zone ontology and vocabularies is less mature than the time ontology. It includes a taxonomy of jurisdictions (Region, PoliticalRegion, Country, State, Reservation, County, City) which does not cover all international practice. It refers to GMT, rather than UTC. It has fixed dates for daylight savings start and end, else uses a time-sequence ontology which is not provided. Appears to need more work.

We have developed a time zone resource in OWL for the entire world, including three parts: the time zone ontology file, the US time zone instance file, and the world time zone instance file.

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 [FIPS], and ISO country instances [ISO-C].

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.

B.1 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.

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

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

:IDIdaho
      a       :County ;
      :name "Idaho County" ;
      :hasParentRegion us-states:ID ;
      :timeZonePart :IDIdahoPST , :IDIdahoMST ;
      owl:sameAs <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 [PA-05], [ PH-04].

B.2.1 OWL code for the time zone ontology

[RDF/XML]

B.3 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.

C. Acknowledgements

The editors would like to thank Jerry Hobbs and Feng Pan for producing the original draft.

D. References

D.1 Normative references

[RFC2119]
S. Bradner. IETF. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119

D.2 Informative references

[AF-97]
Allen, J. F.; Ferguson, G.. In: Spatial and Temporal Reasoning. O. Stock, ed., Kluwer, Dordrecht, Netherlands, pp. 205-245. Actions and events in interval temporal logic. 1997. URL: http://dx.doi.org/10.1007/978-0-585-28322-7_7
[AL-84]
Allen, J. F.. Artificial Intelligence 23, pp. 123-154. Towards a general theory of action and time. 1984. URL: http://dx.doi.org/10.1016/0004-3702%2884%2990008-0
[CO-16]
Cox, S. J. D.. Semantic Web Journal 7, pp. 201-209. Time Ontology Extended for Non-Gregorian Calendar Applications. 2016. URL: http://dx.doi.org/10.3233/SW-150187
[CR-05]
S.J.D. Cox; S.M. Richard. Geosphere 1 (2005) 119. A formal model for the geologic time scale and global stratotype section and point, compatible with geospatial information transfer standards. 2005. URL: http://dx.doi.org/10.1130/GES00022.1
[CR-14]
S.J.D. Cox; S.M. Richard. Earth Sci. Informatics 8 (2014) 5–19. A geologic timescale ontology and service. 2014. URL: http://dx.doi.org/10.1007/s12145-014-0170-6
[FIPS]
FIPS 55 County instance file. URL: http://www.daml.org/2003/02/fips55/
[HP-04]
Hobbs, J. R.; Pan, F.. ACM Transactions on Asian Language Processing (TALIP): Special issue on Temporal Information Processing, 3, No. 1, pp. 66-85. An Ontology of Time for the Semantic Web. March 2004. URL: http://dx.doi.org/10.1145/1017068.1017073
[ISO-19108]
ISO 19108:2002 Geographic information -- Temporal schema. 2002. URL: http://www.iso.org/iso/iso_catalogue/catalogue_detail?csnumber=26013
[ISO-8601]
ISO 8601:2004 Data elements and interchange formats -- Information interchange -- Representation of dates and times. 2004. URL: http://www.iso.org/iso/catalogue_detail?csnumber=40874
[ISO-C]
ISO Country instance file. URL: http://www.daml.org/2001/09/countries/iso
[MF-13]
X. Ma; P. Fox. Earth Sci. Informatics. 6 (2013) 31–46. Recent progress on geologic time ontologies and considerations for future works. 2013. URL: http://dx.doi.org/10.1007/s12145-013-0110-x
[OWL-S]
OWL-S homepage. URL: http://www.daml.org/services/owl-s/
[PA-05]
Pan, F.. In: Proceedings of the AAAI Fall Symposium on Agents and the Semantic Web, Arlington, Virginia, pp. 30-37. A Temporal Aggregates Ontology in OWL for the Semantic Web. 2005. URL: https://www.semanticscholar.org/paper/A-Temporal-Aggregates-Ontology-in-OWL-for-the-Pan/3147d5c652a7e4bf4787fdff781c56259bdb5a33/pdf
[PH-04]
Pan, F; Hobbs, J. R.. In: Proceedings of the AAAI Spring Symposium on Semantic Web Services, Stanford University, CA, pp. 29-36. Time in OWL-S. 2004. URL: http://www.isi.edu/%7Ehobbs/time/pub/pan-hobbs-AAAI-SSS04.pdf
[PR-OS]
The process file of the OWL-S 0.9 release. URL: http://www.daml.org/services/owl-s/0.9/Process.owl
[RC-14]
Radiocarb. Mag. Guidelines to Authors. 2014. URL: https://journals.uair.arizona.edu/index.php/radiocarbon/about/submissions#authorGuidelines
[RFC2445]
F. Dawson; D. Stenerson. IETF. Internet Calendaring and Scheduling Core Object Specification (iCalendar). November 1998. Proposed Standard. URL: https://tools.ietf.org/html/rfc2445
[owl-time-20060927]
Jerry Hobbs; Feng Pan. W3C. Time Ontology in OWL. 27 September 2006. W3C Working Draft. URL: https://www.w3.org/TR/2006/WD-owl-time-20060927/
[owl2-direct-semantics]
Boris Motik; Peter Patel-Schneider; Bernardo Cuenca Grau. W3C. OWL 2 Web Ontology Language Direct Semantics (Second Edition). 11 December 2012. W3C Recommendation. URL: https://www.w3.org/TR/owl2-direct-semantics/
[owl2-quick-reference]
Jie Bao; Elisa Kendall; Deborah McGuinness; Peter Patel-Schneider. W3C. OWL 2 Web Ontology Language Quick Reference Guide (Second Edition). 11 December 2012. W3C Recommendation. URL: https://www.w3.org/TR/owl2-quick-reference/
[xmlschema11-2]
David Peterson; Sandy Gao; Ashok Malhotra; Michael Sperberg-McQueen; Henry Thompson; Paul V. Biron et al. W3C. W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes. 5 April 2012. W3C Recommendation. URL: https://www.w3.org/TR/xmlschema11-2/