From: Adam Pease (apease@ks.teknowledge.com)
Date: 02/07/02
Jerry, I should also point the work being done on the IEEE Standard Upper Ontology <http://suo.ieee.org> and one proposal to the effort that includes substantial temporal ontology content <http://ontology.teknowledge.com>. While I'm confident that there are at least several ontologies of time that would be suitable for representing any practical domain, the prospect of getting agreement among experts in the area is more in question. An interesting related body of discussion may be an exchange among Pat Hayes, Fritz Lehmann and Chris Welty, that I edited, which can be found at <http://ontology.teknowledge.com:8080/rsigma/dialog-3d-4d.html>. While not strictly about temporal ontology, it does cover related issues about modeling change and object identity. Adam 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_. > >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 >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. > >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 >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) > >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. Adam Pease Teknowledge (650) 424-0500 x571
This archive was generated by hypermail 2.1.4 : 03/26/03 EST