From: Brandon Amundson (bamundson@bbn.com)
Date: 02/07/02
This isn't my area of expertise, but isn't a major point of the ontological work in DAML that you don't have to reach agreement on a common ontology to import and use someone else's markup. Rather than trying to reach agreement on a common ontology which might depend on how each participant expected to use the markup data, would it make sense to agree that this is a good area in which to test the ontological mapping tools as there are already several alternative ontologies. Regards, Bob > -----Original Message----- > From: owner-daml-all@mail.daml.org > [mailto:owner-daml-all@mail.daml.org]On Behalf Of Adam Pease > Sent: Wednesday, February 06, 2002 9:09 PM > To: Jerry Hobbs; daml@ai.sri.com; daml-all@daml.org > Subject: Re: Time > > > 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