From: Jerry Hobbs (hobbs@ai.sri.com)
Date: 02/06/02

I know of some work that has been done by DAML contractors on an
ontology for time (e.g., DAML-S, Cycorp, CMU, Kestrel), and I'm sure
there is a lot of other work.  It seemed to me that it would be useful
for those interested in working on this to collaborate and come up
with a common ontology.  Such collaboration would result in something
that could be adopted much more widely than any single site's efforts.

The purposes of the temporal ontology would be both for expressing
temporal aspects of the contents of web resources and for expressing
time-related properties of web services.

I think it would be good if people interested in this topic could get
things rolling with a lunchtime get-together at the PI meeting next
week.  Please contact me if you would like to be involved in this.

To get the discussion rolling, I have appended a description of what
seem to me to be the chief required features of an ontology of time.
I have divided it into three parts -- topological relations among
instants, intervals, and events; measures of intervals; and clock and
calendar time.  The first of these is already a part of DAML-S, so
I've copied the part describing that in our DAML-S paper.  For the
other two I've just sketched the outlines of a possible approach or two.

-- Jerry

		    Topological Temporal Relations

For the initial version of DAML-S we have defined a very simple upper
ontology for time.  There are two classes of entities---_instants_ and
_intervals_.  Each is a subclass of _temporal-entity_.

There are three relations that may obtain between an instant and an
interval, defined as DAML-S properties:

	The _start-of_ property whose domain is the Interval class
		and whose range is an Instant.

	The _end-of_ property whose domain is the Interval class and
		whose range is an Instant.

	The _inside_ property whose domain is the Interval class and
		whose range is an Instant.

No assumption is made that intervals _consist of_ instants.

There are two possible relations that may obtain between a process and
one of the temporal objects.  A process may be in an _at-time_
relation to an instant or in a _during_ relation to an interval.
Whether a particular process is viewed as instantaneous or as occuring
over an interval is a granularity decision that may vary according to
the context of use.  These relations are defined in DAML-S as
properties of processes.

	The _at-time_ property: its domain is the Process class
		and its range is an Instant.

	The _during_ property: its domain is the Process class and
		its range is an Interval.

Viewed as intervals, processes could have properties such as startTime
and endTime which are synonymous (daml:samePropertyAs) with the
start-Of and end-Of relation that obtains between intervals and

One further relation can hold between two temporal entities---the
_before_ relation.  The intended semantics is that for an instant or
interval to be before another instant or interval, there can be no
overlap or abutment between the former and the latter.  In DAML-S the
_before_ property's domain is the Temporal-entity class and its range
is a Temporal-entity.

Different communities have different ways of representing the times
and durations of states and events (processes).  In one approach,
states and events can both have durations, and at least events can be
instantaneous.  In another approach, events can only be instantaneous
and only states can have durations.  In the latter approach, events
that one might consider as having duration (e.g., heating water) are
modeled as a state of the system that is initiated and terminated by
instantaneous events.  That is, there is the instantaneous event of
the start of the heating at the start of an interval, that transitions
the system into a state in which the water is heating.  The state
continues until another instantaneous event occurs---the stopping of
the heating at the end of the interval.  These two perspectives on
events are straightforwardly interdefinable in terms of the ontology
we have provided.  Thus, DAML-S supports both.

The various relations between intervals defined in Allen's temporal
interval calculus (Allen and Kautz, 1985) can be defined in a
straightforward fashion in terms of _before_ and identity on the
start and end points.  For example, two intervals meet when the end of
one is identical to the start of the other.  Thus, in the near future,
when DAML is augmented with the capability of defining logical rules,
it will be easy to incorporate the interval calculus into DAML-S.  In
addition, in future versions of DAML-S we will define primitives for
measuring durations and for specifying clock and calendar time.

			 Measuring Durations

Let _interval-between_ be a mapping from Instants x Instants to
Intervals.  For two instants t1 and t2, interval-between(t1,t2) is an
interval whose start-of is t1 and whose end-of is t2.  We will
probably want to insist that t1 be less than or equal to t2.  With
this function in hand, we can proceed entirely in terms of intervals.

There are at least two approaches we can take toward measuring
intervals.  The first is to consider units of time as functions from
Intervals to Reals, e.g., 

	minutes: Intervals --> Reals
	minutes([5:14,5:17]) = 3

The other approach is to consider temporal units to constitute a set
of entities -- call it TemporalUnits -- and have a single function
_duration_ mapping Intervals x TemporalUnits into the Reals.

	duration: Intervals x TemporalUnits --> Reals
	duration([5:14,5:17], Minute) = 3

Probably the best approach is to support both modes of expression.

When a more expressive dialect of DAML becomes available, then the
relations among the temporal units can be expressed in rules, e.g.,
seconds(i) = 60 * minutes(i).

The unit _month_ (and to a lesser extent, _year_) requires the
calendar ontology if it is to be related to other temporal units, but
on its own, it is a legitimate temporal unit.

			  Clock and Calendar

I will outline two approaches, one that I tend to favor and the one
Cyc uses.  I could go with either one or a reasonable third

In the first approach, time, day, date, month, and year are viewed as
properties of temporal intervals.  For example, _January_ is a
property that is true of every interval that is a January, that is,
the interval from midnight December 31 to midnight January 31 in any
year.  _hr22PST_ would be a property true of every interval from 10:00pm
to 11:00pm, Pacific Standard Time, on any day.  Then to specify the time

(1)	5:14pm PST, Wednesday, February 6, 2002

we would say that the instant t was inside intervals i1 through i5
with the following properties:

	min14(i1), hr17PST(i2), Wednesday(i3), date6(i3), 
	February(i4), yr2002(i5)

Additionally, parallel predicates could be true of every temporal
entity within the intervals.  Thus, inJanuary(t) would be true of
every temporal entity contained within a January.

The hour functions could be viewed as functions of an interval and a
time zone or other geographical region.

	hr17(i2, PSTZone)  or  hr17(i2, California)

meaning time interval i2 is between 5:00pm and 6:00pm in the Pacific
Standard Time zone or in California.

It would of course also be possible to split the numbers out as
separate arguments:

	min(i1, 14), hr(i2, 17, PST), date(i3,6), yr(i5,2002)

Thus, min(i1, 14) would be true of every time interval i1 that was the
14th (or 15th?) minute of some hour.

In the second approach (Cyc), _yearFn_ is a function that takes a
positive or negative integer and returns an interval of time, namely,
that year in the Gregorian calendar.  _monthFn_ is a function that
takes a month name and a year (i.e., a time interval that is returned
by _yearFn_) and returns a time interval, namely, that month of that
year.  And so on, for days of the month, hours, minutes, and seconds.
Days of the week are treated as in the first approach as properties of
time intervals.

In this approach, time (1) would be represented as follows:

	minFn(14, hrFn(17, PSTZone, dateFn(6, monthFn(February, yrFn(2002)))))

with the further property that the interval returned by dayFn is also
a Wednesday.

Either approach is adequate for expressing what needs to be expressed,
and there is no particular reason a DAML ontology couldn't support
both approaches.

When an adequately expressive dialect of DAML becomes available, we
would want to encode the topolological facts about these intervals,
e.g., that Tuesday meets Wednesday, and that the seven days of the
week exhaust the week.

We would also want to encode the facts about the duration of these
intervals.  Thus, the duration of a day interval would be a day and of
an hour interval an hour.

At this point we are ready to state the facts concerning months and
years.  For example,

	August(i) --> days(i) = 31, or
	August(i) --> duration(i, Day) = 31, or
	duration(monthFn(August, y), Day) = 31, etc.

A reasonable approach to defining _month_ as a unit of temporal
measure would be to specify that the start and end points have to be
on the same days of successive months.  So months would be related to
days only indirectly.

The facts about years would be stated similarly.  Of course the facts
about February and leap years have to be described in tandem and
require arithmetic.

_weekday_ and _weekendday_ would be properties of day intervals that
followed from their day-of-the-week property.  _holiday_ could be a
relation between day intervals and geographical regions.  For example,

	day4(i) & inJuly(i) --> holiday(i,USA)

A _workingday_ in a geographical region is then a weekday that is not
a holiday in that region.

With this machinery we would be able to state and reason about, for
example, requirements in the Foreign Clearance Guide involving "15
working days before" some event.

This archive was generated by hypermail 2.1.4 : 03/26/03 EST