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 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.
This archive was generated by hypermail 2.1.4 : 03/26/03 EST