Fwd: Re: Time

From: Adam Pease (apease@ks.teknowledge.com)
Date: 02/14/02

>Date: Wed, 13 Feb 2002 13:26:03 -0800
>To: pat hayes <phayes@ai.uwf.edu>, "Richard Fikes" <fikes@KSL.Stanford.EDU>
>From: Adam Pease <apease@ks.teknowledge.com>
>Subject: Fwd: Re: Time
>Cc: Jerry Hobbs <hobbs@ai.sri.com>
>   Here's a message I sent to Jerry mapping the points in his message to 
> our work on the IEEE SUO.  The URLs embedded give you pages from our 
> ontology browser.  You can also access the latest KIF source at 
> <http://ontology.teknowledge.com/cgi-bin/cvsweb.cgi/SUO/Merge.txt> or 
> more directly at 
> <http://ontology.teknowledge.com/cgi-bin/cvsweb.cgi/~checkout~/SUO/Merge.txt?rev=1.26&content-type=text/plain>. 
> Do a find on "TEMPORAL CONCEPTS" to go to the temporal ontology content 
> in the source.
>>Date: Thu, 07 Feb 2002 09:30:29 -0800
>>To: Jerry Hobbs <hobbs@ai.sri.com>
>>From: Adam Pease <apease@ks.teknowledge.com>
>>Subject: Re: Time
>>Cc: iniles
>>   Here's some further detail from the IEEE SUO work we're doing.  I 
>> think we have a lot of the concepts you mention already covered.  The 
>> ontology is free and also has a DAML version (see <> although it's not 
>> completely up to date with respect to the KIF version of the 
>> ontology).  Since the whole DAML program may not be interested in all 
>> this detail I'm sending it just to you but feel free to post or 
>> circulate this material if you wish.  I'm cc'ing Ian Niles since he did 
>> the bulk of the work on the ontology, and he can correct me if I get 
>> some of this wrong.  By the way, it would be great to have your 
>> involvement in the IEEE effort, there's a lot you could contribute.
>>   More below:
>>At 06:34 PM 2/6/2002 -0800, Jerry Hobbs wrote:
>>>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_.
>>'TimePosition' has subclasses 'TimePoint' and 'TimeInterval'
>>>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.
>>'BeginFn' and 'EndFn' take 'TimeInterval'(s) and return 'TimePoint'(s)
>>during relates two 'TimeInterval'(s) (rather than relating a point and an 
>>>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.
>>see 'time' 
>>>         The _during_ property: its domain is the Process class and
>>>                 its range is an Interval.
>>We don't have this directly, but you can use the 'time' relation to get 
>>the 'TimePosition' of the 'Process' and then use the 'during' relation
>>>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.
>>see the 'before' relation at 
>>>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.
>>We didn't have a clear way of distinguishing events and processes so we 
>>could use your advice here.
>>>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.
>>We include all the standard Allen relations.  See 
>>>                         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.
>>We don't have the function, but you could just reify the interval and 
>>assign the two instants as its endpoints.
>>>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
>>We have the latter case with 'duration' 
>>and 'TimeDuration' 
>>>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).
>>We have those axioms, see for example 
>>>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)
>>That's what we have, see 'DayFn' etc 
>>>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.
>>I don't think we have time zones.  I'll check with Ian, and make sure we 
>>add this if don't have it already.
>>>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.
>>We need to add the concepts about the lengths of months, leap years etc.
>>Adam Pease
>>(650) 424-0500 x571
>Adam Pease
>(650) 424-0500 x571

Adam Pease
(650) 424-0500 x571

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