Abstract

This document presents The OWL-Time ontology is an OWL-2 DL ontology [ owl2-direct-semantics ] of temporal concepts, OWL-Time (formerly DAML-Time) [ 4 , 10 ], for describing the temporal content of Web pages and the temporal properties of resources in the world or described in Web services. pages. The ontology provides a vocabulary for expressing facts about topological relations among instants and intervals, together with information about durations, and about datetime information. We also demonstrate in detail, using the Congo.com and Bravo Air examples from OWL-S [ 11 ], how this time ontology can be used to support OWL-S, temporal position including use cases for defining input parameters and (conditional) output parameters. A use case date-time information.

The namespace for meeting scheduling OWL-Time terms is also shown. In http://www.w3.org/2006/time#

The suggested prefix for the appendix we also describe a OWL-Time namespace is time zone resource

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 OWL we developed for not only the US original namespace may be deprecated by future versions of this document but also will not be deleted. This policy will hold when the entire world, including revised ontology is merged with the time zone ontology, original, later in the US time zone instances, standardization process. This initial publication is designed to solicit comments on this and all aspects of the world time zone instances. current work.

Status of this This Document

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

This document was prepared by is the first version of the Time Ontology Engineering and Patterns Task Force 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 (SWBPD). , edited by Jerry Hobbs and Feng Pan.

For OGC

This work is part a Public Draft of a document prepared by the Spatial Data on the W3C Semantic Web Activity . This Working Group ( SDWWG ) — a joint W3C -OGC project (see charter ). The document is a prepared following W3C First Public Working Draft published conventions. The document is released at this time to solicit comments from interested parties. public comment.

This document was published by the Spatial Data on the Web Working Draft Group as a Working Draft. This document is not expected intended to become a W3C Recommendation. Comments on If you wish to make comments regarding this document are encouraged and may be sent document, please send them to public-swbp-wg@w3.org public-sdw-comments@w3.org ; please include the text "comment" in the subject line. ( subscribe , archives ). All messages received at this address comments are viewable in a public archive . welcome.

At the time of publication the charter of the Semantic Web Best Practices and Deployment Working Group is expiring. A new Publication as a Working Group, Draft does not imply endorsement by the Semantic Web Deployment (SWD) Working Group, W3C Membership. This is commencing. The charter of the SWD Working Group permits it to choose to take up this a draft document and consider further work. At the time of publication no decision has been made may be updated, replaced or obsoleted by the SWD Working Group regarding further other documents at any time. It is inappropriate to cite this document as other than work in this area. progress.

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

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. 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 (formerly DAML-Time), OWL-Time, has been developed for describing the temporal content of Web pages and pages, or the temporal properties of Web services. Its development is being informed by temporal ontologies developed at a number of sites and is intended to capture the essential features of all of them and make them and their associated resources easily available to any resource denoted using a large group of Web developers and users. Although it can be used independently, we have made sure it works well with OWL-S. Advantages of OWL-Time over XML Schema datatype duration and dateTime will be discussed. web identifier (URI), including real-world things if desired. 

This document only presents the OWL encodings of the ontology. For a first-order logic axiomatization of the ontology, see [ 4 , 10 HP-04 ]. In an extension

2. Changes from previous versions

This version of OWL-Time was developed in the time ontology 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, [ 5 , 9 owl-time-20060927 ], we also allow ] with modifications proposed by Cox, [ CO-16 ] to support more general temporal predicates positions. Specifically:

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

A simple use case example: "Suppose someone has a telecon scheduled for 6:00pm EST on November 5, 2006. You would like Notes are included to make an appointment with him for 2:00pm PST 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 same day, domain and expect range. If the meeting to last 45 minutes.  Will there rdfs:domain were left unspecified, the properties could be an overlap?" In this used more widely without undesirable entailments. Their use case we can specify in the facts about context of the telecon and classes in the meeting using our ontology in OWL 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 allow usually be part of an application or associated with a temporal reasoner to determine whether 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 a conflict. See [ A Use Case :TemporalEntity , so this would need to be generalized to avoid inappropriate entailments. Else predicates with similar names could be provided for Scheduling linking to other entities.

Note

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

More examples: "Someone who does
Issue 3

https://www.w3.org/2015/spatial/track/issues/26 Temporal vagueness requirement. Extended Data/Time Format (EDTF) is a Web search trying detailed proposal for how to find a place 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 buy make it amenable to RDF reasoning. However, we should consider doing this in a book needed before next Tuesday may or may not 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 able 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 an online bookstore that promises delivery within five business days." some built-in datatypes from OWL and some additional types from XML Schema Part 2.

"Someone doing a genealogical search may want to specify that The table below indicates the birthdate full list of a person is between 15 namespaces and 45 years before a known marriage date." 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.

More use case examples will The key words must , must not , required , should , should not , recommended , may , and optional in this specification are to be interpreted as described in detail in [ Use Cases for Web Services RFC2119 ] section below. ].

Data conforms to OWL-Time if:

5. Principles and vocabulary overview Syntax for code

In keeping with SWBP policy, the code within the body This section is non-normative.

5.1 Topological Temporal Relations

The basic structure of the note ontology is in N3. Most based on an algebra of the code was generated by Protégé from the original OWL code in RDF/XML. Details in alternative syntaxes are given binary relations on intervals (e.g., meets, overlaps) developed by links. Allen and Ferguson [ AL-84 ], [ AF-97 Topological Temporal Relations ] 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 of TemporalEntity : subclasses: Instant Interval and Interval Instant , and they are the only two subclasses of TemporalEntity : :Instant a owl:Class ; rdfs:subClassOf :TemporalEntity . :Interval a owl:Class ; rdfs:subClassOf :TemporalEntity . :TemporalEntity a owl:Class ; rdfs:subClassOf :TemporalThing ; owl:equivalentClass [ a owl:Class ; owl:unionOf (:Instant :Interval) ] . . Intervals are, intuitively, things with extent and instants are, intuitively, point-like in that they have no interior points. It 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 hasBeginning Interval and has one subclass hasEnd are relations between instants and temporal entities, and ProperInterval , which corresponds with the beginnings and ends common understanding of temporal entities, if they exist, are unique. In some approach to infinite intervals, a positively infinite interval has no end, and a negatively infinite interval has no beginning. Hence, we use in that the relations hasBeginning beginning and end are distinct, and whose membership is therefore disjoint from hasEnd in the ontology, rather than defining functions Instant . The class beginningOf ProperInterval and endOf , since the functions would not be total. has one subclass, hasBeginning DateTimeInterval , for example, can be specified as: :hasBeginning a owl:ObjectProperty ; rdfs:domain :TemporalEntity ; rdfs:range :Instant . inside is a relation between an instant and an interval, and it is not intended to include beginnings whose position and ends of intervals. There is extent may be expressed using a single before GeneralDateTimeDescription relation on temporal entities, which gives directionality to time. If a temporal entity or T 1 xsd:dateTime .

is before another UML-style diagram of temporal entity classes
Fig. 1 Core model model of temporal entity T 2 entities. , then the end of T 1
Issue 5

:durationOf is before was mentioned in the beginning of T 2 . Thus, before can be considered to be basic original draft, but not in the published ontology. It appears to instants and derived for intervals.  have been replaced by :hasDuration.

Allen and Furgerson Ferguson [ 1 , 2 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, and we do that here too. Proper intervals are ones whose beginning and end are different. It

5.2 Temporal reference systems, clocks, calendars

The position of an Instant may be given using the datatype xsd:dateTime which 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 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 as: origin, such as Julian date, or Unix time. This may be converted to calendar units when necessary for human consumption.

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

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

5.3 Time position and time units

OWL 2 has two built-in datatypes relating to time: intervalEquals , xsd:dateTime and intervalBefore , xsd:dateTimeStamp [ owl2-quick-reference ]. Other XSD types such as intervalMeets xsd:date , intervalOverlaps xsd:gYear , intervalStarts , xsd:gMonth and intervalDuring , 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 intervalFinishes , 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 their reverse interval relations: clock elements. Its subclass intervalAfter , DateTimeDescription fixes the temporal reference system to the Gregorian calendar, so the intervalMetBy , hasTRS property may be omitted on individuals from this class.
Note

intervalOverlappedBy , 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 intervalStartedBy , GeneralDateTimeDescription or intervalContains , DateTimeDescription is strictly always a description of an interval ( intervalFinishedBy 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, the specification year (in DateTimeDescription ) has a range of intervalEquals xsd:gYear , while years is: (in GeneralDurationDescription ) has a range of xsd:decimal so that you can say duration of 2.5 years.

:Equals a owl:ObjectProperty ; rdfs:domain :ProperInterval ; rdfs:range :ProperInterval .
Note

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

5.4 Duration Description

The duration of an interval (or temporal sequence) can have many different descriptions. An interval can be 1 day 2 hours, or 26 hours, or 1560 minutes, and so on. It is useful to be able to talk about these descriptions in a convenient way as independent objects, and to talk about their equivalences. We do this first in terms 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 predicate called duration using calendar and clock elements, the definitions of which are given in the associated TRS description. Its subclass durationOf 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 takes eight arguments, one 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 TemporalEntity s.

Property: before

RDF Property: time:before
Definition: Gives directionality to time. If a temporal thing, entity T 1 is before another temporal entity T 2 , then the end of T 1 is before the beginning of T 2 . Thus, before can be considered to be basic to instants and one each derived for years, months, weeks, days, hours, minutes, and seconds. Then we will define intervals.
Instance of: owl:ObjectProperty
Domain: time:TemporalEntity
Range: time:TemporalEntity

 

Property: after

RDF Property: time:after
Definition: Gives directionality to time. If a specific kind temporal entity T 1 is after another temporal entity T 2 , then the beginning of T 1 is after the end of T 2 .
Instance of: owl:ObjectProperty
Inverse Property: time:before

Two properties, hasBeginning , hasEnd , support the describing the bounds of individual called a "duration description", together with TemporalEntity .

Property: hasBeginning

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

 

Property: hasEnd

RDF Property: time:hasEnd
Definition: End of functions relating the duration description a temporal entity.
Instance of: owl:ObjectProperty
Domain: time:TemporalEntity
Range: time:Instant

Two properties, hasDuration , hasDurationDescription , provide alternative ways to describe the values extent of each 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 eight arguments. Thereby we convert inclusion of temporal entities in other resources.

Property: hasMember

RDF Property: time:hasMember
Definition: Supports the 8-ary predicate 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 durationOf inside links to an Instant into eight binary relations that are more convenient 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 description logic-based markup languages, such as OWL: 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 ].

:DurationDescription a owl:Class ; rdfs:subClassOf [ a owl:Restriction ; owl:maxCardinality 1 ; owl:onProperty :seconds ] ; rdfs:subClassOf [ a owl:Restriction ; owl:maxCardinality 1 ; owl:onProperty :minutes ] ; rdfs:subClassOf [ a owl:Restriction ; owl:maxCardinality 1 ; owl:onProperty :hours ] ; rdfs:subClassOf [ a owl:Restriction ; owl:maxCardinality 1 ; owl:onProperty :days ] ; rdfs:subClassOf [ a owl:Restriction ; owl:maxCardinality 1 ; owl:onProperty :weeks ] ; rdfs:subClassOf [ a owl:Restriction ; owl:maxCardinality 1 ; owl:onProperty :months ] ; rdfs:subClassOf [ a owl:Restriction ; owl:maxCardinality 1 ; owl:onProperty :years ] .
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 T 1 is intervalEquals another proper interval T 2 , then the beginning of T 1 is the beginning of T 2 , and the end of T 1 is the end of T 2 . 
Instance of: owl:ObjectProperty
Domain: time:ProperInterval
Range: time:ProperInterval

An  

Property: intervalBefore

RDF Property: time:intervalBefore
Definition: If a proper interval can have multiple duration descriptions (e.g., T 1 is intervalBefore another proper interval T 2 days, 48 hours), , then the end of T 1 is before the beginning of T 2 . 
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 T 1 is intervalAfter another proper interval T 2 , then the beginning of T 1 is after the end of T 2 . 
Instance of: owl:ObjectProperty
Inverse of: time:intervalBefore

 

Property: intervalMeets

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

 

Property: intervalMetBy

RDF Property: time:intervalMetBy
Definition: If a proper interval T 1 is intervalMetBy another proper interval T 2 , then the beginning of T 1 is the end of T 2 . 
Instance of: owl:ObjectProperty
Inverse of: time:intervalMeets

 

Property: intervalOverlaps

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

 

Property: intervalOverlappedBy

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

 

Property: intervalStarts

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

 

Property: intervalStartedBy

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

 

Property: intervalDuring

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

 

Property: intervalContains

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

 

Property: intervalFinishes

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

 

Property: intervalFinishedBy

RDF Property: time:intervalFinishedBy
Definition: If a proper interval T 1 is intervalFinishedBy another proper interval T 2 , then the beginning of T 1 is before the beginning of T 2 , and the end of T 1 is the end of T 2 . 
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 can only DateTimeInterval can have one duration. 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

We use two different sets  

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 properties 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 DateTimeDescription 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 DurationDescription TRS , because their ranges are different. For example, 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 year ProperInterval (in s, 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 DateTimeDescription hasTRS ) has supports links from an resource that requires it to a range 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 xsd:gYear , while 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 years hasTRS (in 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 DurationDescription hasTRS , timeZone , and unitType ) has 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 xsd:decimal time:TimeZone so that you into the the main namespace (i.e. no properties) which can say duration of 2.5 years. 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

iCalendar Six datatype properties year , month ,  day , 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 [ 3 ISO-8601 ] and XML Schema Definition Language Part 2: Datatypes [ xmlschema11-2 ], except that the calendar is a widely supported standard 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 personal data interchange. It 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 definition name of the day.

Property dayOfWeek

RDF Property: time:dayOfWeek
Definition: The day of week, whose value is a common format for openly exchanging calendaring and scheduling information across member of the Internet. class time:DayOfWeek
Instance of: owl:ObjectProperty
Domain: time:GeneralDateTimeDescription
Range: time:DayOfWeek

 

6.9 Class: DayOfWeek

RDFS Class: time:DayOfWeek
Definition: The representation day of temporal concepts 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 ontology 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 mapped to iCalendar. defined. For example, duration of 15 days, 5 hours and 20 seconds is represented in iCalendar as P15DT5H0M20S, which "January" can be represented in defined as a a subclass of DateTimeDescription with the time ontology as: restrictions that the unitType property has allValuesFrom unitMonth and property month hasValue of 1:

:duration a :DurationDescription ; :seconds 20 ; :hours 5 ; :days 15 . 
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 The relation
Definition: A temporal unit of measure, which provides a scale factor for a time quantity.
Instance of: owl:Class

Seven individual members of hasDurationDescription 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 used open, to specify 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 duration description 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 entity: 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.

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

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

:Year 
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
              ] .
Here we

We use "cardinality = 0" instead of restricting the values of days, etc. to 0. The reason is that using "cardinality = 0" means all those properties/fields (days, etc.) should not be specified (i.e., the granularity is "year"), while restricting all those values to 0 means they all have a fixed value of 0 (i.e., x years 0 months 0 days ...) and the granularity is actually "second", which is not the correct semantics of "year".

It's worth pointing out 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 Time Zones
Definition: Generalized number
Instance of: rdfs:Datatype
Equivalent class: xsd:double
or xsd:float
or xsd:decimal

What hour The datatype Number provides for numbers expressed using any of the day an instant is in is relative to the time zone. This XSD types decimal (of which xsd:integer is also true of minutes, since there are regions in the world, e.g., central Australia, where the hours are not aligned with UTC hours, but are, e.g., offset half an hour. Seconds are not relative to the time zone. Days, weeks, months and years are also relative to the time zone, since, e.g., 2006 began in the Eastern Standard time zone three hours before it began in the Pacific Standard time zone. Thus, predications about all datetime intervals except seconds are relative to a time zone. sub-type), float , or double (which allows exponential or scientific notation).

We have been referring to time zones, but in fact it is more convenient to work in terms

6.16 Datatype: generalYear

RDFS Class: time:generalYear
Definition: Year number - generalization of what we might call the "time standard" that is used in a time zone. That is, it is better to work with the Pacific Standard Time (PST) xsd:gYear, formulated as a legal entity than text string with a pattern constraint to reproduce the PST zone same lexical form as a geographical region. A time standard is a way of computing gYear. Note that the time, relative to a world-wide system of computing time. For each time standard, there value-space is not defined, so a zone, or geographical region, and a time 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 year in which it correct lexical form, the value-space is used for describing local times. Where and when not defined, so a time standard is used have to be axiomatized, and generic OWL2 processor cannot compute ordering relationships of values of this involves interrelating type.

6.17 Datatype: generalMonth

RDFS Class: time:generalMonth
Definition: Month of year - generalization of xsd:gMonth, formulated as a time ontology and text string with a geographical ontology. These relations can be quite complex. Only the entities like PST and EDT, the time standards, are part of pattern constraint to reproduce the time ontology. If we were same lexical form as gMonth, except that values up to conflate time zones (i.e., geographical regions) and time standards, it would likely result 20 are permitted, in problems order to support calendars with more than 12 months in several situations. For example, the Eastern Standard zone and year. Note that the Eastern Daylight zone are value-space is not identical, since most defined, so a generic OWL2 processor cannot compute ordering relationships of Indiana was on Eastern Standard time all year. The state values of Arizona and the Navajo Indian Reservation, two overlapping geopolitical regions, have different time standards during 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 daylight saving times -- one is Pacific and correct lexical form, the other value-space is Mountain. not defined, so a generic OWL2 processor cannot compute ordering relationships of values of this type.

Time standards that seem equivalent, like Eastern Standard and Central Daylight, should be thought

6.18 Datatype: generalDay

RDFS Class: time:generalDay
Definition: Day of month - generalization of xsd:gDay, formulated as separate entities. Whereas they function the same in the time ontology, they do not function a text string with a pattern constraint to reproduce the same in the ontology lexical form as gDay, except that articulates time and geography. For example, it would be false values up to say those parts of Indiana shifted 99 are permitted, in April from Eastern Standard order to Central Daylight time. See 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 (
      [ Appendix B
        xsd:pattern "---(0[1-9]|[1-9][0-9])(Z|(\\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00))?"^^xsd:string ;
      ] for
    ) 
Note

While this pattern achieves the details about correct lexical form, the value-space is not defined, so a time zone resource we developed in OWL. generic OWL2 processor cannot compute ordering relationships of values of this type.

7. Examples DateTime Description

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

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

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 temporal unit type definition of 10:30 is minute ( unitMinute ), a common format for openly exchanging calendaring and scheduling information across the temporal unit type of March 20, 2006 is day ( unitDay ). Internet. The unit type is required. With a given representation of temporal unit type, all the fields/properties for smaller units will concepts in this time ontology can be ignored. straightforwardly mapped to iCalendar. For instance, if the temporal unit type is day ( unitDay ), the values example, duration of the field/property hour, minute, 15 days, 5 hours and second, if present, will be ignored. Since datetime description 20 seconds is for describing datetime intervals, we defined a property, called hasDateTimeDescription with DateTimeDescription as the range, for datetime intervals. To represent "March 12 represented in 2006", for example, using datetime description, we need an instance of DateTimeDescription that has values only for unitType ( unitDay ), year (2006), month (3), and day (12). DateTimeDescription and hasDateTimeDescription are defined iCalendar as P15DT5H0M20S, which can be represented in OWL the time ontology as: :DateTimeDescription a owl:Class ; rdfs:subClassOf [ a owl:Restriction ; owl:cardinality 1 ; owl:onProperty :unitType ] ; rdfs:subClassOf [ a owl:Restriction ; owl:maxCardinality 1 ; owl:onProperty :second ] ; rdfs:subClassOf [ a owl:Restriction ; owl:maxCardinality 1 ; owl:onProperty :minute ] ; rdfs:subClassOf [ a owl:Restriction ; owl:maxCardinality 1 ; owl:onProperty :hour ] ; rdfs:subClassOf [ a owl:Restriction ; owl:maxCardinality 1 ; owl:onProperty :day ] ; rdfs:subClassOf [ a owl:Restriction ; owl:maxCardinality 1 ; owl:onProperty :dayOfWeek ] ; rdfs:subClassOf [ a owl:Restriction ; owl:maxCardinality 1 ; owl:onProperty :dayOfYear ] ; rdfs:subClassOf [ a owl:Restriction ; owl:maxCardinality 1 ; owl:onProperty :week ] ; rdfs:subClassOf [ a owl:Restriction ; owl:maxCardinality 1 ; owl:onProperty :month ] ; rdfs:subClassOf [ a owl:Restriction ; owl:maxCardinality 1 ; owl:onProperty :year ] ; rdfs:subClassOf [ a owl:Restriction ; owl:maxCardinality 1 ; owl:onProperty :timeZone ] . :hasDateTimeDescription a owl:ObjectProperty ; rdfs:domain :DateTimeInterval ; rdfs:range :DateTimeDescription . 
:hasDurationDescription
      a       :DurationDescription ;
      :seconds 20 ;
      :hours 5 ;
      :days 15 .
DateTimeInterval is

7.2 Geologic timescale described as a subclass graph of ProperInterval . Any TemporalEntity has a duration, but only DateTimeInterval can have DateTimeDescription (e.g., May 8 has a DateTimeDescription , but the interval from 1:30pm, May 8, to 1:30pm, May 9, does not. Both have individuals

The geologic timescale is defined as a duration set of named intervals arranged in a day. A DateTimeDescription hierarchy, such that there is always a description only one subdivision of an interval ( DateTimeInterval ), not an instant, which can be described by  inDateTime and inXSDDateTime , as described later in the section. The domain intervals of each rank (e.g. 'Era') by a set of intervals of the property dayOfWeek is the class DayOfWeek : :DayOfWeek a owl:Class ; owl:equivalentClass [ a owl:Class ; owl:oneOf (:Sunday :Monday :Tuesday :Wednesday :Thursday :Friday :Saturday) ] . next rank (in this case 'Period') [ CR-05 Other datetime concepts ]. Since the relative ordering is well-defined this can be straightforwardly defined. For example, "January" therefore serve as an ordinal temporal reference system. Fig. 5 shows how the geologic timescale can be defined expressed as a a subclass set of :ProperIntervals related to each other using only DateTimeDescription with the restrictions that the unitType property has intervalMetBy , allValuesFrom unitMonth and property intervalStartedBy , month intervalFinishedBy . Many other interval relationships follow logically from the ones shown (for example 'Neogene Period' : hasValue 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 1: 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:

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

In order to specify that an instant The beginning of the Phanerozoic is in a datetime interval, an inDateTime property/relation is defined similarly to hasDateTimeDescription Instant , described as follows:

:inDateTime a owl:ObjectProperty ; rdfs:domain :Instant ; rdfs:range :DateTimeDescription . 
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 ;
.

With this inDateTime relation, we can say Note that an instant happens at a specific time. For example, the beginning position of a meeting, which is an instant, is at 6:00pm which this Instant is actually in specified using a datetime interval of [6:00:00, 6:01:00). With inDateTime you do not describe instants; you only approximate them by confining them within an interval. This should generally be adequate. Where it TimePosition , which is not, you can always define an instant in a roundabout way numeric value relative to the temporal coordinate system indicated as the beginning value of an interval. We also defined in OWL two simpler relations, xsdDateTime and inXSDDateTime . The only difference between these two relations and the above hasDateTimeDescription and inDateTime hasTRS relations property.

The RDF representation of this example is their ranges: these two simpler relations use the XML Schema datatype dateTime as their ranges, while the above uses DateTimeDescription : available here .

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

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

Note

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

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

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

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

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 .

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

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

OWL code

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 time 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 [ RDF/XML 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 .

Use
Cases

: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 Services commerce applications

Note

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

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

Use Cases for

Input Parameters

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

profile:CreditCardExpirationDate a profile:ParameterDescription ; profile:parameterName creditCardExpirationDate ; profile:restrictedTo time: ; profile:referTo congoProcess: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 time: ; profile:referTo ba_process:outboundDate_In . 
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.

Use Cases for

(Conditional) Output Parameters

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

Adding a ProcessTime output parameter

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

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

      rdfs:subClassOf :Interval .

:fullCongoBuyProcessTime
      a       rdf:Property ;
      rdfs:subPropertyOf process:output ;
      rdfs:domain :FullCongoBuy ;
      rdfs:range       
              [ a       owl:Class ;

        [ 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 : ;

                owl:allValuesFrom :ProcessTime ;

                owl:onProperty process:coOutput
              ] .

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

Adding a DeliveryDuration output parameter

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

To add this output parameter may seem similar to the above ProcessTime example. However, since an instance of Condition is a logical formula that evaluates to true or false (see the comment with the definition of Condition [ 14 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 time: .

      rdfs:range :Interval .

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

      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 . 
:FedEx2-3dayCondition
      a       owl:Class ;
      rdfs:subClassOf process:Condition .

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

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

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

:Interval2Days
      a       owl:Class ;
      rdfs:subClassOf time: ;

      rdfs:subClassOf :Interval ;

      owl:subClassOf
              [ a       owl:Restriction ;
                owl:hasValue P2D ;
                owl:onProperty time:

                owl:onProperty :durationDescriptionDataType

              ] .
:Interval3Days
      a       owl:Class ;
      rdfs:subClassOf time: ;

      rdfs:subClassOf :Interval ;

      owl:subClassOf
              [ a       owl:Restriction ;
                owl:hasValue P3D ;
                owl:onProperty time:

                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.

OWL code for these examples [ RDF/XML ] A Use Case for Scheduling Suppose someone has a telecon scheduled for 6:00pm EST on November 5, 2006. You would like to make an appointment with him for 2:00pm PST on the same day, and expect the meeting to last 45 minutes.  Will there be an overlap? In this use case we can specify the facts about the telecon and the meeting using our ontology in OWL that will allow a temporal reasoner to determine whether there is a conflict: :telecon a :Interval ; :hasBeginning :teleconStart . :meeting a :Interval ; :hasBeginning :meetingStart ; :hasDurationDescription :meetingDuration . :teleconStart a :Instant ; :inXSDDateTime 2006-11-05T18:00:00-5:00 . :meetingStart a :Instant ; :inXSDDateTime 2006-11-05T14:00:00-8:00 . :meetingDuration a :DurationDescription ; :minutes 45 . The telecon and the meeting are defined as intervals. hasBeginning is used for specifying the start times of the meetings. The datetimes are specified using inXSDDateTime . The duration of the meeting is specified using the duration description class.

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

A.1 Classes (subclass relations)

A.2 Properties

years DurationDescription xsd;decimal months DurationDescription xsd;decimal weeks DurationDescription xsd;decimal days DurationDescription xsd;decimal hours DurationDescription xsd;decimal minutes DurationDescription xsd;decimal seconds DurationDescription xsd;decimal hasDurationDescription TemporalEntity DurationDescription unitType DateTimeDescription TemporalUnit year DateTimeDescription xsd;gYear month DateTimeDescription xsd;gMonth week DateTimeDescription xsd;nonNegativeInteger day DateTimeDescription xsd;gDay dayOfWeek DateTimeDescription DayOfWeek dayOfYear DateTimeDescription xsd;nonNegativeInteger hour DateTimeDescription xsd;nonNegativeInteger minute DateTimeDescription xsd;nonNegativeInteger second DateTimeDescription xsd;decimal timeZone DateTimeDescription tzont;TimeZone inDateTime Instant DateTimeDescription inXSDDateTime Instant xsd;dateTime hasDateTimeDescription DateTimeInterval xsdDateTime DateTimeInterval xsd;dateTime
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

 

Appendix B. Time Zone Resource in OWL 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 [ 15 ] in OWL for not only the US but also the entire world, including three parts: the time zone ontology file [ 16 ], , the US time zone instance file [ 17 ], , and the world time zone instance file [ 18 ]. .

The time zone ontology links a preliminary geographic ontology with a time ontology. It defines the vocabulary about regions, political regions (countries, states, counties, reservations, and cities), time zones, daylight saving policies, and the relationships between these concepts. Its instances also link to other existing data on the Web, such as FIPS 55 county instances [ 19 FIPS ], and ISO country instances [ 20 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. [ Anticipated Use ] will be described in detail in a later section.     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 . 
:Country
      a       owl:Class ;
      rdfs:subClassOf :PoliticalRegion .

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

This can be defined in OWL as: 

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

We assume default reasoning is used for this ontology. When a political region lacks one of its properties, we will use the one from its parent region. Thus all political sub-regions of the United States get their DaylightSavingsPolicy values from that of the United States, provided their observesDaylightSavingsTime property is true. All counties in California get their hasTimeZone values from California, whereas the hasTimeZone value is specified for each county in Kentucky and not for the state as a whole, since it is split between the Eastern and Central time zones. When most of a region is in one time zone, and only some exceptional sub-regions are in different time zones or have different daylight savings time policies, we use exceptionalRegion to point to each exceptional sub-region, e.g. West Wendover, which is in the Mountain time zone, is an exception in Nevada, which is otherwise in the Pacific time zone. Here is the OWL code of Nevada and West Wendover in the US time zone instance file [ 17 ]: : 

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

      :observesDaylightSavingsTime true ;

      :exceptionalRegion :NVWestWendoverCity .
:NVWestWendoverCity
      a       :City ;
      :name "West Wendover City" ;

      :name "West Wendover City" ;

      :stateOf us-states:NV ;
      :hasTimeZone : ;
      owl:sameIndividualAs
              <<a href=
"http://www.daml.org/2003/02/fips55/NV.owl#p83730">http://www.daml.org/2003/02/fips55/NV.owl#p83730> .

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

:IDIdaho
      a       :County ;
      :name "Idaho County" ;
      :hasParentRegion
              us-states:ID ;
      :
              : ;
      owl:sameIndividualAs
              <http://www.daml.org/2003/02/fips55/ID.owl#c049> .

      :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.  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
      a       :TemporalSeq ;
      :hasTemporalAggregateDescription
              :firstSunEveryApril .
:tseq-everyApril a :TemporalSeq ; :hasTemporalAggregateDescription :everyApril . 
:tseq-everyApril
      a       :TemporalSeq ;
      :hasTemporalAggregateDescription
              :everyApril .
:everyApril a :TemporalAggregateDescription ; :hasTemporalUnit :unitMonth ; :hasithTemporalUnit 4 . 
:everyApril
      a       :TemporalAggregateDescription ;
      :hasTemporalUnit
              :unitMonth ;
      :hasithTemporalUnit 4 .
:firstSunEveryApril
      a       :TemporalAggregateDescription ;
      :hasContextTemporalSeq
              :tseq-everyApril ;
      :hasContextTemporalUnit
              :unitMonth ;
      :hasithTemporalUnit 7 ;
      :hasTemporalUnit
              :unitDay ;
      :hasPosition 1 .

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

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

For details about the temporal aggregates ontology and its use case examples, please see [ 6 , 7 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 References

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

[1] Allen, J. F. 1984. Towards a general theory of action and time. Artificial Intelligence 23, pp. 123-154. 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 [2]

D.2 Informative references

[AF-97]
Allen, J. F. and F.; Ferguson, G. 1997. Actions and events in interval temporal logic. In G.. In: Spatial and Temporal Reasoning . 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 [3] Dawson, F.
[AL-84]
Allen, J. F.. Artificial Intelligence 23, pp. 123-154. Towards a general theory of action and Stenerson, D. 1998. Internet Calendaring 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 Scheduling Core Object Specification (iCalendar), RFC2445. http://www.ietf.org/rfc/rfc2445.txt 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-0166-2 [4]
[FIPS]
FIPS 55 County instance file . URL: http://www.daml.org/2003/02/fips55/
[HP-04]
Hobbs, J. R. and R.; Pan, F. 2004. An Ontology of Time for the Semantic Web. F.. ACM Transactions on Asian Language Processing (TALIP): Special issue on Temporal Information Processing , Vol. Processing, 3, No. 1, March 2004, pp. 66-85. [5] Pan, F and Hobbs, J. R. 2004. Time in OWL-S. In Proceedings An Ontology of Time for the AAAI Spring Symposium on Semantic Web Services , Stanford University, CA, pp. 29-36. . 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 [6] Pan, F
[ISO-8601]
ISO 8601:2004 Data elements and Hobbs, J. R. 2005. Temporal Aggregates in OWL-Time. In Proceedings interchange formats -- Information interchange -- Representation of the 18th International Florida Artificial Intelligence Research Society Conference (FLAIRS) , Clearwater Beach, Florida, pp. 560-565, AAAI Press. 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 [7] Pan, F. 2005. A Temporal Aggregates Ontology in OWL
[MF-13]
X. Ma; P. Fox. Earth Sci. Informatics. 6 (2013) 31–46. Recent progress on geologic time ontologies and considerations for the Semantic Web. In 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 , Web, Arlington, Virginia, pp. 30-37.  30-37. [8] A Temporal Aggregates Ontology in OWL code of for the time ontology. http://www.w3.org/2006/time Semantic Web . 2005. URL: https://www.semanticscholar.org/paper/A-Temporal-Aggregates-Ontology-in-OWL-for-the-Pan/3147d5c652a7e4bf4787fdff781c56259bdb5a33/pdf [9] OWL code
[PH-04]
Pan, F; Hobbs, J. R.. In: Proceedings of the entry sub-ontology of time. http://www.w3.org/2006/time-entry [10] OWL-Time Homepage: http://www.isi.edu/~pan/OWL-Time.html AAAI Spring Symposium on Semantic Web Services, Stanford University, CA, pp. 29-36. [11] Time in OWL-S homepage. http://www.daml.org/services/owl-s/ . 2004. URL: http://www.isi.edu/%7Ehobbs/time/pub/pan-hobbs-AAAI-SSS04.pdf [12] OWL-S 0.9 release. http://www.daml.org/services/daml-s/0.9/ [13] OWL-S 1.1 release. http://www.daml.org/services/owl-s/1.1/
[PR-OS]
[14] The process file of the OWL-S 0.9 release. release . URL: http://www.daml.org/services/owl-s/0.9/Process.owl
[RC-14]
Radiocarb. Mag. Guidelines to Authors [15] The homepage of the time zone resource in OWL. http://www.isi.edu/~pan/timezonehomepage.html . 2014. URL: https://journals.uair.arizona.edu/index.php/radiocarbon/about/submissions#authorGuidelines
[RFC2445]
F. Dawson; D. Stenerson. IETF. [16] The time zone ontology file. http://www.w3.org/2006/timezone 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. [17] The US time zone instance file. http://www.w3.org/2006/timezone-us 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. [18] The world time zone instance file. http://www.w3.org/2006/timezone-world 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. [19] FIPS 55 County instance file. http://www.daml.org/2003/02/fips55/ 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. [20] ISO Country instance file. http://www.daml.org/2001/09/countries/iso W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes . 5 April 2012. W3C Recommendation. URL: https://www.w3.org/TR/xmlschema11-2/