Time (on behalf of Bob Balzer)

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.


> -----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