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> > >Folks, > 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. > >Adam > > >>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 >> >>Jerry, >> 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' >><http://ontology.teknowledge.com:8080/rsigma/SKB.jsp?req=SC&skb=Merge&id=173> >> >>>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) >><http://ontology.teknowledge.com:8080/rsigma/SKB.jsp?req=SC&skb=Merge&id=441> >> >>during relates two 'TimeInterval'(s) (rather than relating a point and an >>interval) >><http://ontology.teknowledge.com:8080/rsigma/SKB.jsp?req=SC&skb=Merge&id=448> >> >> >> >>>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' >><http://ontology.teknowledge.com:8080/rsigma/SKB.jsp?req=SC&skb=Merge&id=89> >> >>> 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 >><http://ontology.teknowledge.com:8080/rsigma/SKB.jsp?req=SC&name=during&skb=Merge> >> >>>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 >>>instants. >>> >>>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 >><http://ontology.teknowledge.com:8080/rsigma/SKB.jsp?req=SC&name=before&skb=Merge> >> >>>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 >><http://ontology.teknowledge.com:8080/rsigma/SKB.jsp?req=SC&skb=Merge&id=191> >> >> >>> 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' >><http://ontology.teknowledge.com:8080/rsigma/SKB.jsp?req=SC&name=duration&skb=Merge> >>and 'TimeDuration' >>http://ontology.teknowledge.com:8080/rsigma/SKB.jsp?req=SC&skb=Merge&id=172 >> >>>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 >><http://ontology.teknowledge.com:8080/rsigma/SKB.jsp?req=SC&skb=Merge&id=389> >> >> >> >>>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 >>>alternative. >>> >>>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 >>>t >>> >>>(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 >><http://ontology.teknowledge.com:8080/rsigma/SKB.jsp?req=SC&skb=Merge&id=462> >> >>>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 >> >> >>Adam Pease >>Teknowledge >>(650) 424-0500 x571 > >Adam Pease >Teknowledge >(650) 424-0500 x571 Adam Pease Teknowledge (650) 424-0500 x571
This archive was generated by hypermail 2.1.4 : 03/26/02 EST