Copyright © 2006 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This document presents an ontology of temporal concepts, OWL-Time (formerly
DAML-Time) [3,5],
for describing the temporal content of Web pages and the temporal properties of
Web services. The ontology provides a vocabulary for expressing facts about topological relations
among instants and intervals, together with information about
durations, and about datetime information. We also demonstrate in detail, using the Congo.com and Bravo Air examples from OWL-S
[8], how this time
ontology can be used to support OWL-S, including use cases for defining input parameters
and (conditional) output parameters. A use case for meeting scheduling is also
shown.
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 will be a part of a larger document that will provide an introduction and overview of all ontology design patterns produced by the Semantic Web Best Practices and Deployment Working Group.
This document is an editor's draft and is expected to change. The SWBPD WG does not expect this document to become a Recommendation. Rather, after further development, review and refinement, it will be published and maintained as a WG Note.
This document is expected to become the First Public Working Draft. We encourage public comments. Please send comments to public-swbp-wg@w3.org
Publication as a draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or made obsolete by other documents at any time. It is inappropriate to cite this document as other than work in progress.
Temporal information is so common that it’s hard to find a real world Web
service without it. For example, whenever you place an online order, the order
date is always part of your order. When you reserve a car at a car rental site,
you have to specify the dates you need it. In response to this need, a temporal
ontology, OWL-Time (formerly DAML-Time), has been developed for
describing the temporal content of Web pages and the temporal properties of Web
services. Its development is being informed by temporal ontologies developed at
a number of sites and is intended to capture the essential features of all of
them and make them and their associated resources easily available to a large
group of Web developers and users. Although it can be used independently,
we have made sure it works well with OWL-S. Advantages of OWL-Time over XML
Schema datatype duration
and
dateTime
will be discussed.
This document only presents the OWL encodings of the ontology. For a first-order logic axiomatization of the ontology, see [3,5]. In an extension of the time ontology [4,7], we also allow temporal predicates to apply directly to events, should the user wish, but here we restrict our treatment to temporal entities.
A simple use case example: "Suppose someone has a telecon scheduled for 6:00pm EST on November 5, 2006. You would like to make an appointment with him for 2:00pm PST on the same day, and expect the meeting to last 45 minutes. Will there be an overlap?" In this use case we can specify the facts about the telecon and the meeting using our ontology in OWL that will allow a temporal reasoner to determine whether there is a conflict. See [A Use Case for Scheduling] section for details.
More examples: "Someone who does a Web search trying to find a place to buy a book needed before next Tuesday may or may not be able to use an online bookstore that promises delivery within five business days."
"Someone doing a genealogical search may want to specify that the birthdate of a person is between 15 and 45 years before a known marriage date."
More use case examples will be described in detail in [Use Cases for Web Services] section below.
In keeping with SWBP policy, the code within the body of the note is in N3. Most of the code was generated by Protégé from the original OWL code in RDF/XML. Details in alternative syntaxes are given by links.
There are two subclasses of TemporalEntity
: Instant
and Interval
,
and they are the only two subclasses of TemporalEntity
:
:Instant a owl:Class ; rdfs:subClassOf :TemporalEntity .
:Interval a owl:Class ; rdfs:subClassOf :TemporalEntity .
:TemporalEntity a owl:Class ; rdfs:subClassOf :TemporalThing ; owl:equivalentClass [ a owl:Class ; owl:unionOf (:Instant :Interval) ] .
Intervals are, intuitively, things with extent and instants are, intuitively, point-like in that they have no interior points. It is generally safe to think of an instant as an interval with zero length, where the beginning and end are the same.
hasBeginning
and hasEnd
are relations between instants and temporal entities, and the beginnings
and ends of temporal entities, if they exist, are unique. In some approach to infinite intervals, a positively infinite
interval has no end, and a negatively infinite interval has no beginning. Hence, we use the relations
hasBeginning
and hasEnd
in the ontology, rather than defining functions beginningOf
and endOf
, since the functions would not be
total. hasBeginning
, for example, can be specified as:
:hasBeginning a owl:ObjectProperty ; rdfs:domain :TemporalEntity ; rdfs:range :Instant .
inside
is a relation between an instant and an interval, and it is not intended to include
beginnings and ends of intervals. There is a before
relation on temporal
entities, which gives directionality to time. If a temporal entity T1
is before another temporal
entity T2
, then the end of T1
is before the beginning of
T2
. Thus, before can be considered to be basic to instants and derived for intervals.
Allen and Furgerson [1,2] have
developed a calculus of binary relations on intervals (e.g., meets, overlaps)
for representing qualitative temporal information and address the problem of
reasoning about such information. The relations between intervals defined in
their calculus can be defined in a relatively
straightforward fashion in terms of before
and identity on the beginning and end points. The standard interval calculus
assumes all intervals are proper, and we do that here
too. Proper intervals are ones whose beginning and end are different. It can be
specified as:
:ProperInterval a owl:Class ; rdfs:subClassOf :Interval ; owl:disjointWith :Instant .
OWL-Time provides the interval relations: intervalEquals
, intervalBefore
, intervalMeets
,
intervalOverlaps
, intervalStarts
, intervalDuring
, intervalFinishes
, and their reverse
interval relations: intervalAfter
, intervalMetBy
, intervalOverlappedBy
, intervalStartedBy
,
intervalContains
, intervalFinishedBy
. For example, the
specification of intervalEquals
is:
:interval
Equals
a owl:ObjectProperty ;
rdfs:domain :ProperInterval ;
rdfs:range :ProperInterval .
The duration of an interval (or temporal sequence) can have many different descriptions. An interval can be 1 day 2 hours, or 26 hours, or 1560 minutes, and so on. It is useful to be able to talk about these descriptions in a convenient way as independent objects, and to talk about their equivalences. We do this first in terms of a predicate called
durationOf
that takes eight arguments, one for a temporal thing, and one each for years, months, weeks, days, hours, minutes, and seconds. Then we will define a specific kind of individual called a "duration description", together with a number of functions relating the duration description to the values of each of the eight arguments. Thereby we convert the 8-ary predicate
durationOf
into eight binary relations that are more convenient for description logic-based markup languages, such as
OWL:
:DurationDescription a owl:Class ; rdfs:subClassOf [ a owl:Restriction ; owl:maxCardinality 1 ; owl:onProperty :seconds ] ; rdfs:subClassOf [ a owl:Restriction ; owl:maxCardinality 1 ; owl:onProperty :minutes ] ; rdfs:subClassOf [ a owl:Restriction ; owl:maxCardinality 1 ; owl:onProperty :hours ] ; rdfs:subClassOf [ a owl:Restriction ; owl:maxCardinality 1 ; owl:onProperty :days ] ; rdfs:subClassOf [ a owl:Restriction ; owl:maxCardinality 1 ; owl:onProperty :weeks ] ; rdfs:subClassOf [ a owl:Restriction ; owl:maxCardinality 1 ; owl:onProperty :months ] ; rdfs:subClassOf [ a owl:Restriction ; owl:maxCardinality 1 ; owl:onProperty :years ] .
An interval can have multiple duration descriptions (e.g., 2 days, 48 hours), but can only have one duration.
We use two different sets of properties for DateTimeDescription
and
DurationDescription
, because their ranges are different. For example, year
(in
DateTimeDescription
) has a range of xsd:gYear
, while years
(in
DurationDescription
) has a range of xsd:decimal
so that you can say duration of
2.5 years.
iCalendar [19] is a widely supported standard for personal data interchange. It provides the definition of a common format for openly exchanging calendaring and scheduling information across the Internet. The representation of temporal concepts in this time ontology can be straightforwardly mapped to iCalendar. For example, duration of 15 days, 5 hours and 20 seconds is represented in iCalendar as P15DT5H0M20S, which can be represented in the time ontology as:
:duration a :DurationDescription ; :seconds 20 ; :hours 5 ; :days 15 .
The relation durationDescriptionOf
is used to specify a duration description for a temporal entity:
:durationDescriptionOf a owl:ObjectProperty ; rdfs:domain :TemporalEntity ; rdfs:range :DurationDescription .
Other duration concepts can be straightforwardly defined. For example, duration "Year" can be defined as a subclass of "DurationDescription" with the
restrictions that the "years" property is required (with "cardinality" of 1) and
all other properties (e.g., "hours", "months") should not be present (with
"cardinality" of 0):
:Year a owl:Class ; rdfs:subClassOf :DurationDescription ; rdfs:subClassOf [ a owl:Restriction ; owl:cardinality 1 ; owl:onProperty :years ] ; rdfs:subClassOf [ a owl:Restriction ; owl:cardinality 0 ; owl:onProperty :months ] ; ... rdfs:subClassOf [ a owl:Restriction ; owl:cardinality 0 ; owl:onProperty :seconds ] .Here we use "cardinality = 0" instead of restricting the values of days, etc. to 0. The reason is that using "cardinality = 0" means all those properties/fields (days, etc.) should not be specified (i.e., the granularity is "year"), while restricting all those values to 0 means they all have a fixed value of 0 (i.e., x years 0 months 0 days ...) and the granularity is actually "second", which is not the correct semantics of "year".
It's worth pointing out that there is a distinction between a year as a duration and a calendar year. The year from December 22, 2004 to December 21, 2005 is the former but not the latter.
What hour of the day an instant is in is relative to the time zone. This is also true of minutes, since there are regions in the world, e.g., central Australia, where the hours are not aligned with UTC hours, but are, e.g., offset half an hour. Seconds are not relative to the time zone.
Days, weeks, months and years are also relative to the time zone, since, e.g., 2003 began in the Eastern Standard time zone three hours before it began in the Pacific Standard time zone. Thus, predications about all datetime intervals except seconds are relative to a time zone.
We have been referring to time zones, but in fact it is more convenient to work in terms of what we might call the "time standard" that is used in a time zone. That is, it is better to work with the Pacific Standard Time (PST) as a legal entity than with the PST zone as a geographical region. A time standard is a way of computing the time, relative to a world-wide system of computing time. For each time standard, there is a zone, or geographical region, and a time of the year in which it is used for describing local times. Where and when a time standard is used have to be axiomatized, and this involves interrelating a time ontology and a geographical ontology. These relations can be quite complex. Only the entities like PST and EDT, the time standards, are part of the time ontology.
If we were to conflate time zones (i.e., geographical regions) and time standards, it would likely result in problems in several situations. For example, the Eastern Standard zone and the Eastern Daylight zone are not identical, since most of Indiana is on Eastern Standard time all year. The state of Arizona and the Navajo Indian Reservation, two overlapping geopolitical regions, have different time standards during the daylight saving times -- one is Pacific and the other is Mountain.
Time standards that seem equivalent, like Eastern Standard and Central Daylight, should be thought of as separate entities. Whereas they function the same in the time ontology, they do not function the same in the ontology that articulates time and geography. For example, it would be false to say those parts of Indiana shift in April from Eastern Standard to Central Daylight time.
We have developed a time zone resource [9] in OWL for not only the US but also the entire world, including three parts: the time zone ontology file [10], the US time zone instance file [11], and the world time zone instance file [12].
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 [14], and ISO country instances [15].
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 6 to October 26 in 2003. 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.
For the details, see the documentation [16], which includes an outline of the time zone ontology and its anticipated use.
[RDF/XML]
A datetime description has the following properties/fields: unitType
,
year
, month
, week
, day
, dayOfWeek
,
dayOfYear
, hour
, minute
, second
, and timeZone
.
The property unitType
specifies the temporal unit type of the
datetime description, and its domain is TemporalUnit
:
:TemporalUnit a owl:Class ; owl:equivalentClass [ a owl:Class ; owl:oneOf (:unitSecond :unitMinute :unitHour :unitDay :unitWeek :unitMonth :unitYear) ] .
For example, the temporal unit type of 10:30 is minute (unitMinute
), and the
temporal unit type of March 20, 2003 is day (unitDay
). The unit type is
required. With a given temporal unit type, all the fields/properties for smaller
units will be ignored. For instance, if the temporal unit type is day (unitDay
),
the values of the field/property hour, minute, and second, if present, will be
ignored. Since datetime description is for describing datetime intervals,
we defined a property, called dateTimeDescriptionOf
with
DateTimeDescription
as the range, for datetime intervals. To represent "March 12 in 2002", for example, using datetime description, we need an instance of DateTimeDescription
that has values only for unitType
(unitDay
),
year
(2002), month
(3), and day
(12).
DateTimeDescription
and dateTimeDescriptionOf
are defined in OWL as:
:DateTimeDescription a owl:Class ; rdfs:subClassOf [ a owl:Restriction ; owl:cardinality 1 ; owl:onProperty :unitType ] ; rdfs:subClassOf [ a owl:Restriction ; owl:maxCardinality 1 ; owl:onProperty :second ] ; rdfs:subClassOf [ a owl:Restriction ; owl:maxCardinality 1 ; owl:onProperty :minute ] ; rdfs:subClassOf [ a owl:Restriction ; owl:maxCardinality 1 ; owl:onProperty :hour ] ; rdfs:subClassOf [ a owl:Restriction ; owl:maxCardinality 1 ; owl:onProperty :day ] ; rdfs:subClassOf [ a owl:Restriction ; owl:maxCardinality 1 ; owl:onProperty :dayOfWeek ] ; rdfs:subClassOf [ a owl:Restriction ; owl:maxCardinality 1 ; owl:onProperty :dayOfYear ] ; rdfs:subClassOf [ a owl:Restriction ; owl:maxCardinality 1 ; owl:onProperty :week ] ; rdfs:subClassOf [ a owl:Restriction ; owl:maxCardinality 1 ; owl:onProperty :month ] ; rdfs:subClassOf [ a owl:Restriction ; owl:maxCardinality 1 ; owl:onProperty :year ] ; rdfs:subClassOf [ a owl:Restriction ; owl:maxCardinality 1 ; owl:onProperty :timeZone ] . :dateTimeDescriptionOf a owl:ObjectProperty ; rdfs:domain :DateTimeInterval ; rdfs:range :DateTimeDescription .
DateTimeInterval
is a subclass of ProperInterval
.
Any TemporalEntity
has a duration, but only DateTimeInterval
can have
DateTimeDescription
(e.g., May 8 has a DateTimeDescription
, but the interval
from 1:30pm, May 8, to 1:30pm, May 9, does not. Both have a duration of a day.
A
DateTimeDescription
is always a description of an interval (DateTimeInterval
),
not an instant, which can be described by inDateTime
and inXSDDateTime
, as described later in the section.
The domain of the property dayOfWeek
is the class DayOfWeek
:
:DayOfWeek a owl:Class ; owl:equivalentClass [ a owl:Class ; owl:oneOf (:Sunday :Monday :Tuesday :Wednesday :Thursday :Friday :Saturday) ] .
Other datetime concepts can be straightforwardly defined. For example,
"January" can be defined as a a subclass of In order to specify that an instant is in a datetime interval, an
With this
We also defined in OWL two simpler relations,
To illustrate more clearly the difference between using We can see from this example that it’s much more concise to use the XML Schema datatype The namespace “tz-us” points to our US time zone data
[11]. Moreover, each field of [RDF/XML]
Congo.com and Bravo Air are the two examples used in the OWL-S 0.9 draft
release [18] (the most recent release is OWL-S 1.1 [13], and
we use code in 0.9 draft release here for illustrative purpose). Congo.com is a fictitious
book-selling service site, and Bravo Air is a fictitious airline-ticketing
service site. We use these two examples to demonstrate in detail how the time
ontology can be used to support OWL-S, including use cases for
defining input parameters and (conditional) output parameters. 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
The namespace “time” points to the location of the OWL code for
the time ontology. In this example In the Bravo Air example, our time ontology can be used to describe the
existing input 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. To add this output parameter may seem similar to the above Both Then we define an output property, called This definition says that These two definitions use Finally, Properties to output delivery durations when the user selects other delivery
types (FedExOneDay, UPS, and OrdinaryMail) can be defined similarly. [RDF/XML]
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: The telecon and the meeting are defined as intervals. [1] Allen, J. F. 1984. Towards a general theory of action
and time. Artificial Intelligence 23, pp. 123-154. [5] OWL-Time Homepage:
http://www.isi.edu/~pan/OWL-Time.html Classes (subclass
relations)DateTimeDescription
with the
restrictions that the unitType
property has allValuesFrom
unitMonth and
property month
hasValue
of 1:
:January
a owl:Class ;
rdfs:subClassOf :DateTimeDescription ;
rdfs:subClassOf
[ a owl:Restriction ;
owl:onProperty :unitType
owl:hasValue :unitMonth
] ;
rdfs:subClassOf
[ a owl:Restriction ;
owl:onProperty :month
owl:hasValue --01 ;
] .
inDateTime
property/relation is defined similarly to
dateTimeDescriptionOf
as follows:
:inDateTime
a owl:ObjectProperty ;
rdfs:domain :Instant ;
rdfs:range :DateTimeDescription .
inDateTime
relation, we can say that an instant happens at a
specific time. For example, the beginning of a meeting, which is
an instant, is at 6:00pm which is actually in a datetime interval of
[6:00:00, 6:01:00). With
inDateTime
you do not describe instants; you only approximate them
by confining them within an interval. This should generally be adequate. Where
it is not, you can always define an instant in a roundabout way as the beginning
of an interval.xsdDateTime
and inXSDDateTime
. The only difference between these two relations and the above
dateTimeDescriptionOf
and
inDateTime
relations is their ranges: these
two simpler relations use the XML Schema datatype dateTime
as their ranges,
while the above uses DateTimeDescription
:
:xsdDateTime
a owl:DatatypeProperty ;
rdfs:domain :DateTimeInterval ;
rdfs:range xsd:dateTime .
:inXSDDateTime
a owl:DatatypeProperty ;
rdfs:domain :Instant ;
rdfs:range xsd:dateTime .
DateTimeDescription
and using the XML datatype dateTime
, let’s look at a concrete
example: an instant that represents the start of a meeing, called meetingStart
,
happens at 10:30am EST on 01/01/2003 can
be expressed using both inXSDDateTime
and
inDateTime
in OWL as::meetingStart
a :Instant ;
:inDateTime
:meetingStartDescription ;
:inXSDDateTime
2003-01-01T10:30:00-5:00 .
:meetingStartDescription
a :DateTimeDescription ;
:unitType :unitMinute ;
:minute 30 ;
:hour 10 ;
:day 1 ;
:dayOfWeek :Wednesday ;
:dayOfYear 1 ;
:week 1 ;
:month 1 ;
:timeZone tz-us:EST ;
:year 2003 .
dateTime
. However, the advantage of using
DateTimeDescription
is that it can express more information than dateTime
, such as
"week", "day of week" and "day of year", so in the above example, we can also
know that 01/01/2003 is Wednesday, on the first day of the year, and in the
first week of the year. DateTimeDescription
is separate so that it's easier to extract the value of some fields for the
later use and easier to reason about.OWL code for the time ontology
Use Cases for Web Services
Use Cases for Input Parameters
CreditCardExpirationDate
:profile:CreditCardExpirationDate
a profile:ParameterDescription ;
profile:parameterName
creditCardExpirationDate ;
profile:restrictedTo
time:Instant ;
profile:referTo
congoProcess:creditCardExpirationDate .
Instant
is used to describe
CreditCardExpirationDate
, because the expiration date is actually
an instant -- the midnight, of the day the credit card expires. DepartureDate
and ArrivalDate
. We will change this to
the more appropriate DepartureTime
and ArrivalTime
. We can define DepartureTime
in the profile of the Bravo Air example (i.e. BravoAirProfile.owl) as:
profile:DepartureTime
a profile:ParameterDescription ;
profile:parameterName
DepartureTime ;
profile:restrictedTo
time:Instant ;
profile:referTo
ba_process:outboundDate_In .
DepartureTime
is defined as Instant
. With this definition, as
we discussed in the previous datetime description section, an instance of
DepartureTime
can has either an inXSDDateTime
property/relation
pointing to a specific value of XML Schema datatype dateTime, say
2003-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/2003, Wednesday. 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
Adding a
ProcessTime
output parameterProcessTime
is a conditional output parameter that specifies how long before
the book will be ready for delivery, say, 24 hours, which depends on whether the
book is in stock. In this use case, the process time is returned only if the
book is in stock. It can be defined in the process model of the Congo.com
example (i.e. CongoProcess.owl) as:
:ProcessTime
a owl:Class ;
rdfs:subClassOf time:Interval .
:fullCongoBuyProcessTime
a rdf:Property ;
rdfs:subPropertyOf process:output ;
rdfs:domain :FullCongoBuy ;
rdfs:range
[ a owl:Class ;
rdfs:subClassOf process:ConditionalOutput ;
rdfs:subClassOf
[ a owl:Restriction ;
owl:allValuesFrom :BookInStock ;
owl:onProperty process:coCondition
] ;
] ;
rdfs:subClassOf
[ a owl:Restriction ;
owl:allValuesFrom :ProcessTime ;
owl:onProperty process:coOutput
] .
ProcessTime
is defined as an interval, rather than a duration. As
discussed previously, in our time ontology durations are properties of
intervals. Thus to talk about a duration, i.e. a quantity of time, an interval
must be defined first. This approach may look roundabout at first glance.
However, the process time is not purely a quantity of time; it has a location on
the time line. The beginning of the process time is the time the user places the
order, and the end of the process time is the time the order is shipped out. An
advantage of defining ProcessTime
as an interval is that if the relationship
among the order time, the shipping time, and the process time is known, any one
of them (e.g. the shipping time) can be computed from the other two (e.g. the
order time and the process time) by temporal arithmetic. Adding a
DeliveryDuration
output parameterDeliveryDuration
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. 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
[17]), DeliveryType
cannot be directly used as a condition to determine the
delivery duration. Thus one property and one condition are defined for each
delivery type. DeliveryDuration
is defined with two boundaries: one minDeliveryDuration
and
one maxDeliveryDuration
. For example, an order with the FedEx2-3day delivery
type takes 2 to 3 days, so its min delivery duration is 2 days, and its max
delivery duration is 3 days. For the delivery duration of the order with
FedExOneDay delivery type, the min and max delivery duration will both be 1 day.
We can define DeliveryDuration
in the process model of the Congo.com example
(i.e. CongoProcess.owl) as:
:DeliveryDuration
a owl:Class ;
rdfs:subClassOf
[ a owl:Restriction ;
owl:cardinality 1 ;
owl:onProperty :maxDeliveryDuration
] ;
rdfs:subClassOf
[ a owl:Restriction ;
owl:cardinality 1 ;
owl:onProperty :minDeliveryDuration
] .
:maxDeliveryDuration
a rdf:Property ;
rdfs:domain :DeliveryDuration ;
rdfs:range time:Interval .
:minDeliveryDuration
a rdf:Property ;
rdfs:domain :DeliveryDuration ;
rdfs:range time:Interval .
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 .
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
] .
deliverySelectFedEx2-3day
is a
conditional output, and if FedEx2-3dayCondition
is true, an
instance of FedEx2-3dayDuration
class will be the output. FedEx2-3dayDuration
is not defined yet. In order to define it, we have to define its min delivery duration, i.e. 2
days, and max delivery duration, i.e. 3 days. Since the range of
minDeliveryDuration
and maxDeliveryDuration
is Interval
, intervals with specific
durations need to be created first. For
FedEx2-3dayDuration
, we need to define
Interval2Days
and
Interval3Days
first as follows:
:Interval2Days
a owl:Class ;
rdfs:subClassOf time:Interval ;
owl:subClassOf
[ a owl:Restriction ;
owl:hasValue P2D ;
owl:onProperty time:durationDescriptionDataType
] .
:Interval3Days
a owl:Class ;
rdfs:subClassOf time:Interval ;
owl:subClassOf
[ a owl:Restriction ;
owl:hasValue P3D ;
owl:onProperty time:durationDescriptionDataType
] .
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.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
] .
OWL code for these examples
A Use Case for Scheduling
:telecon
a :Interval ;
:hasBeginning :teleconStart .
:meeting
a :Interval ;
:hasBeginning :meetingStart ;
:durationDescriptionOf
: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 .
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.
References
[2] Allen, J. F. and Ferguson, G. 1997. Actions and events in
interval temporal logic. In Spatial and Temporal Reasoning. O. Stock,
ed., Kluwer, Dordrecht, Netherlands, 205-245.
[3] Hobbs, J. R. and Pan, F. 2004. An Ontology of Time for the Semantic Web.
ACM
Transactions on Asian Language Processing (TALIP): Special issue on Temporal
Information Processing, Vol. 3, No. 1, March 2004, pp. 66-85.
[4] Pan, F and Hobbs, J. R. 2004. Time in OWL-S. In Proceedings of the AAAI Spring Symposium on Semantic Web
Services, Stanford University, CA, pp. 29-36, 2004.
[6] OWL code of the time ontology.
http://www.isi.edu/~pan/damltime/time.owl
[7] OWL code of the entry sub-ontology of time.
http://www.isi.edu/~pan/damltime/time-entry.owl
[8] OWL-S homepage.
http://www.daml.org/services/owl-s/
[9] The homepage of the time zone resource in OWL.
http://www.isi.edu/~pan/timezonehomepage.html
[10] The time zone ontology file.
http://www.isi.edu/~pan/damltime/timezone-ont.owl
[11] The US time zone instance file.
http://www.isi.edu/~pan/damltime/timezone-us.owl
[12] The world time zone instance file.
http://www.isi.edu/~pan/damltime/timezone-world.owl
[13] OWL-S 1.1 release.
http://www.daml.org/services/owl-s/1.1/
[14] FIPS 55 County instance file.
http://www.daml.org/2003/02/fips55/
[15] ISO Country instance file.
http://www.daml.org/2001/09/countries/iso
[16] The documentation of the time zone ontology. http://www.isi.edu/~pan/damltime/time-zone-documentation.txt
[17] The process file of the OWL-S 0.9 release.
http://www.daml.org/services/owl-s/0.9/Process.owl
[18] OWL-S 0.9 release. http://www.daml.org/services/daml-s/0.9/
[19] Internet Calendaring and Scheduling Core Object
Specification (iCalendar), RFC2445.
http://www.ietf.org/rfc/rfc2445.txt
Appendix (summary of classes and properties)
TemporalEntity
Instant
Interval
ProperInterval
DateTimeInterval
DurationDescription
DateTimeDescription
TemporalUnit
DayOfWeek
Properties
Property Name |
Domain |
Range |
before |
TemporalEntity |
TemporalEntity |
after |
TemporalEntity |
TemporalEntity |
hasBeginning |
TemporalEntity |
Instant |
hasEnd |
TemporalEntity |
Instant |
inside |
Interval |
Instant |
intervalEquals |
ProperInterval |
ProperInterval |
intervalBefore |
ProperInterval |
ProperInterval |
intervalMeets |
ProperInterval |
ProperInterval |
intervalOverlaps |
ProperInterval |
ProperInterval |
intervalStarts |
ProperInterval |
ProperInterval |
intervalDuring |
ProperInterval |
ProperInterval |
intervalFinishes |
ProperInterval |
ProperInterval |
intervalAfter |
ProperInterval |
ProperInterval |
intervalMetBy |
ProperInterval |
ProperInterval |
intervalOverlappedBy |
ProperInterval |
ProperInterval |
intervalStartedBy |
ProperInterval |
ProperInterval |
intervalContains |
ProperInterval |
ProperInterval |
intervalFinishedBy |
ProperInterval |
ProperInterval |
years |
DurationDescription |
xsd;decimal |
months |
DurationDescription |
xsd;decimal |
weeks |
DurationDescription |
xsd;decimal |
days |
DurationDescription |
xsd;decimal |
hours |
DurationDescription |
xsd;decimal |
minutes |
DurationDescription |
xsd;decimal |
seconds |
DurationDescription |
xsd;decimal |
durationDescriptionOf |
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 |
dateTimeDescriptionOf |
DateTimeInterval |
DateTimeDescription |
xsdDateTime |
DateTimeInterval |
xsd;dateTime |