From: Adam Pease (apease@ks.teknowledge.com)
Date: 04/23/02
apologies if you receive this more than once. I'm resending due to an
error in the list address on the first try
Folks,
Ian is on vacation for the next week and a half, and Jerry mentions he
shortly will be away as well. I'm excited about all the good content Jerry
has provided and the substantial agreement between his concepts and
SUMO. I'm not deep enough into the issue to respond effectively,
unfortunately, so we'll have to wait for Ian's return. Below I've included
content that Ian generated to support a notion equivalent to Jerry's "hath".
Adam
(instance TemporalCompositionFn TemporalRelation)
(instance TemporalCompositionFn TernaryPredicate)
(domain TemporalCompositionFn 1 TimeInterval)
(domainSubclass TemporalCompositionFn 2 TimeInterval)
(domain TemporalCompositionFn 3 NonnegativeInteger)
(rangeSubclass TemporalCompositionFn TimeInterval)
(documentation TemporalCompositionFn "The basic &%Function for expressing
the composition of larger &%TimeIntervals out of smaller &%TimeIntervals.
For example, if &%ThisSeptember is an &%instance of &%September,
(&%TemporalCompositionFn &%ThisSeptember &%Day 30) denotes the &%Class of
30 consecutive days that make up &%ThisSeptember.")
(=>
(equal (TemporalCompositionFn ?INTERVAL ?INTERVAL-TYPE ?NUMBER) ?CLASS)
(forall (?TIME1 ?TIME2)
(=>
(and
(instance ?TIME1 ?INTERVAL-TYPE)
(instance ?TIME2 ?CLASS))
(exists (?DURATION)
(and
(duration ?TIME1 ?DURATION)
(duration ?TIME2 ?DURATION))))))
(=>
(equal (TemporalCompositionFn ?INTERVAL ?INTERVAL-TYPE ?NUMBER) ?CLASS)
(equal (CardinalityFn ?CLASS) ?NUMBER))
(=>
(equal (TemporalCompositionFn ?INTERVAL ?INTERVAL-TYPE ?NUMBER) ?CLASS)
(forall (?TIME1 ?TIME2)
(=>
(and
(instance ?TIME1 ?CLASS)
(instance ?TIME2 ?CLASS)
(not (equal ?TIME1 ?TIME2)))
(or
(meetsTemporally ?TIME1 ?TIME2)
(meetsTemporally ?TIME2 ?TIME1)
(earlier ?TIME1 ?TIME2)
(earlier ?TIME2 ?TIME1)))))
(=>
(equal (TemporalCompositionFn ?INTERVAL ?INTERVAL-TYPE ?NUMBER) ?CLASS)
(exists (?TIME)
(and
(instance ?TIME ?CLASS)
(starts ?TIME ?INTERVAL))))
(=>
(equal (TemporalCompositionFn ?INTERVAL ?INTERVAL-TYPE ?NUMBER) ?CLASS)
(exists (?TIME)
(and
(instance ?TIME ?CLASS)
(finishes ?TIME ?INTERVAL))))
(=>
(equal (TemporalCompositionFn ?INTERVAL ?INTERVAL-TYPE ?NUMBER) ?CLASS)
(forall (?TIME1)
(=>
(and
(instance ?TIME1 ?CLASS)
(not (finishes ?TIME1 ?INTERVAL)))
(exists (?TIME2)
(and
(instance ?TIME2 ?CLASS)
(meetsTemporally ?TIME1 ?TIME2))))))
(=>
(equal (TemporalCompositionFn ?INTERVAL ?INTERVAL-TYPE ?NUMBER) ?CLASS)
(forall (?TIME1)
(=>
(and
(instance ?TIME1 ?CLASS)
(not (starts ?TIME1 ?INTERVAL)))
(exists (?TIME2)
(and
(instance ?TIME2 ?CLASS)
(meetsTemporally ?TIME2 ?TIME1))))))
(=>
(equal (TemporalCompositionFn ?INTERVAL ?INTERVAL-TYPE ?NUMBER) ?CLASS)
(forall (?TIME)
(=>
(and
(instance ?TIME TimePoint)
(temporalPart ?TIME ?INTERVAL))
(exists (?INSTANCE)
(instance ?INSTANCE ?CLASS)
(temporalPart ?TIME ?INSTANCE)))))
At 09:04 PM 4/17/2002 -0700, Jerry Hobbs wrote:
>I don't know how many people got Ian Niles comments on my initial
>proposal for a time ontology. I didn't, and didn't know about it
>until I got together with him and Adam Pease last week. In any case,
>here are my responses to the various points.
>
>-- Jerry
>
> > > For convenience, we can say that the start and end of an instant is
> > > itself.
> > >
> > > instant(t) --> start-of(t) = t
> > > instant(t) --> end-of(t) = t
>
> > This isn't possible in the SUMO given the current arg type
> > restrictions on 'BeginFn' and 'EndFn'. Furthermore, it seems
> > counterintuitive to me to speak of the start or end of
> > an extensionless point in time.
>
>I'm not sure whether this is useful or not. For me it depends on how
>many axioms it makes easier to write, and the truth will emerge about
>that. I could go either way.
>
>............
>
> > > It will be useful in characterizing clock and calendar terms to have a
> > > relation between instants and intervals that says that the instant is
> > > inside or the start of the interval.
> > >
> > > in-interval(t,T) <--> [start-of(T) = t v inside(t,T)]
>
> > This is the relation of 'temporalPart' in the SUMO.
>
>Actually, this relation does not include the ends of intervals, only
>the starts. The reason for this is my intuition that clock and
>calendar intervals are half open, including the start but not the end.
>I.e. midnight is part of the next day.
>
>.....................
>
> > > interval-between is a relation among a temporal-entity and two
> > > instants.
> > >
> > > interval-between(T,t1,t2)
> > > --> temporal-entity(T) & instant(t1) & instant(t2)
> > >
> > > The two instants are the start and end points of the temporal entity.
> > >
> > > interval-between(T,t1,t2)
> > > <--> start-of(T) = t1 & end-of(T) = t2
>
> > The relation "interval-between" maps to 'TimeIntervalFn' in
> > the SUMO. I'm not sure why this is represented as a
> > predicate here, since it is a total function from the time points
> > to the interval.
>
>Here I was trying to leave things open so that time could be only
>partially ordered, in which case there might be several intervals
>between two points. Time might be partially ordered in models that
>conflated possibility/knowledge with time, as in the branching futures
>approach. But if there is strong feeling that this should not be
>allowed, I can imagine yielding.
>
>....................
>
> > > The ontology is silent about whether the interval from t to t, if it
> > > exists, is identical to the instant t.
> > >
> > > The ontology is silent about whether intervals _consist of_ instants.
> > >
> > > The ontology is silent about whether intervals are uniquely determined
> > > by their starts and ends.
> > >
> > > We can define a proper-interval as one whose start and end are not
> > > identical.
> > >
> > > proper-interval(t) <--> interval(t) & start-of(t) =/= end-of(t)
>
> > In the SUMO, there is no distinction between intervals and
> > proper-intervals. To my mind, it doesn't make sense to
> > distinguish them, because all intervals which are not
> > proper-intervals would be time points.
>
>I wouldn't like to identify nonproper-intervals with time points,
>because most of the problems in representing scalar quantities like
>time arise when trying to specify the relation between 1-D and 0-D
>entities. I wanted to keep the ontology at arm's length from
>statements that intervals _consist of_ time points.
>
>The question of whether 0-length intervals exist is a matter of how to
>treat limiting cases of a concept. My view is that including the
>limiting case under the concept often eliminates extra disjuncts in
>axioms. But for me it's purely a matter of economy in axiomatization.
>
>....................
>
> > > 2.2. Before:
> > >
> > > There is a before relation on temporal entities, which gives
> > > directionality to time. If temporal-entity T1 is before
> > > temporal-entity T2, then the end of T1 is before the start of T2.
> > > Thus, before can be considered to be basic to instants and derived for
> > > intervals.
> > >
> > > before(T1,T2) <--> before(end-of(T1),start-of(T2))
> > >
> > > The end of an interval is not before the start of the interval.
> > >
> > > interval(T) --> ~before(end-of(T),start-of(T))
> > >
> > > The start of a proper interval is before the end of the interval.
> > >
> > > proper-interval(T) --> before(start-of(T),end-of(T))
> > >
> > > If one instant is before another, there is an interval between them.
> > >
> > > instant(t1) & instant(t2) & before(t1,t2)
> > > --> (E T) interval-between(T,t1,t2)
>
> > The SUMO differs from this only in that the SUMO has two relations.
> > We use 'earlier' for time intervals and 'before' for time
> > points. However, I'm not committed to this distinction.
>
>I think what to call predicates and how to split them will emerge
>while rationalizing predicate/function names.
>
>................
>
> > > The relation after is defined in terms of before.
> > >
> > > after(T1,T2) <--> before(T2,T1)
>
> > We don't have a relation "after" in the SUMO, since it's just the inverse
> > of 'earlier' or 'before'.
>
>I think the usability of a language is enhanced by providing for
>different perspectives by adding inverse relations explicitly.
>Programming languages usually have both < and >. But I have no strong
>feelings about this issue.
>
>.................
>
> > > In addition, it will be useful below to have a single predicate for
> > > "starts or is during". This is called "int-in".
> > >
> > > int-in(T1,T2) <--> [int-starts(T1,T2) v int-during(T1,T2)]
>
> > The SUMO predicate 'temporalPart' covers "int-in", since the arg
> > type restrictions on 'temporalPart' are 'TimePosition' and
> > 'TimePosition' is a superclass of 'TimeInterval' and 'TimePoint'.
>
>Again, the aim of this badly named predicate is to have something that
>includes starts and middles but not ends, for the half-open clock and
>calendar intervals.
>
>...................
>
> > > It will also be useful to have a single predicate for intervals
> > > intersecting in at most an instant.
> > >
> > > int-disjoint(T1,T2)
> > > <--> [int-before(T1,T2) v int-after(T1,T2) v
> int-meets(T1,T2)
> > > v int-met-by(T1,T2)]
>
> > I'm not sure why this relation would be useful,
> > but it can be defined in terms of 'earlier' and
> > 'meetsTemporally' in the SUMO.
>
>It is useful for dealing with concatenation of intervals, as in the
>predicate "Hath" below.
>
>...................
>
> > > 2.4. Linking Time and Events:
> > >
> > > The time ontology links to other things in the world through four
> > > predicates -- at-time, during, holds, and time-span-of. We assume
> > > that another ontology provides for the description of events -- either
> > > a general ontology of event structure abstractly conceived, or
> > > specific, domain-dependent ontologies for specific domains.
> > >
> > > The term "eventuality" will be used to cover events, states,
> > > processes, propositions, states of affairs, and anything else that can
> > > be located with respect to time. The possible natures of
> > > eventualities would be spelled out in the event ontologies.
>
> > We don't have anything like the notion of "eventuality"
> > in the SUMO, and this for good reason, I think. The sense in
> > which a proposition is true at a particular time is very
> > different from the sense in which a process or event occurs
> > at a particular time.
>
>I'm not arguing for eventualities here, but only using it for a cover
>term for anything that can be located in time. Distinctions between
>propositions, events, processes, states, and so on are a matter for
>the ontology of events, etc., and not for the time ontology.
>
>However, I should not have used "eventuality" as a predicate in the
>axioms below constraining the arguments of at-time and during, which
>should have been merely
>
> at-time(e,t) --> instant(t)
> during(e,T) --> interval(T)
>
>What e is is a matter for the event ontology to specify.
>
> > > The predicate at-time relates an eventuality to an instant, and is
> > > intended to say that the eventuality holds, obtains, or is taking
> > > place at that time.
> > >
> > > at-time(e,t) --> eventuality(e) & instant(t)
> > >
> > > The predicate during relates an eventuality to an interval, and is
> > > intended to say that the eventuality holds, obtains, or is taking
> > > place during that interval.
> > >
> > > during(e,T) --> eventuality(e) & interval(T)
> > >
> > > If an eventuality obtains during an interval, it obtains at every
> > > instant inside the interval.
> > >
> > > during(e,T) & inside(t,T) --> at-time(e,t)
>
> > We use 'holdsDuring' and 'time' for these relations in the SUMO.
>
>................
>
> > > Often the eventualities in the event ontology are best thought of as
> > > propositions, and the relation between these and times is most
> > > naturally called "holds". holds can be defined in terms of at-time
> > >>and during:
> > >
> > > holds(e,t) & instant(t) <--> at-time(e,t)
> > > holds(e,T) & interval(T) <--> during(e,T)
>
>This relation of "holds" maps to 'holdsDuring' in the SUMO.
>
>................
>
> > > The predicate time-span-of relates eventualities to instants or
> > > intervals. For contiguous states and processes, it tells the entire
> > > instant or interval for which the state or process obtains or takes
> > > place.
> > >
> > > time-span-of(T,e) --> temporal-entity(T) & eventuality(e)
> > > time-span-of(T,e) & interval(T) --> during(e,T)
> > > time-span-of(t,e) & instant(t) --> at-time(e,t)
> > > time-span-of(T,e) & interval(T) & ~inside(t1,T)
> > > & ~start-of(t1,T) & ~end-of(t1,T)
> > > --> ~at-time(e,t1)
> > > time-span-of(t,e) & instant(t) & t1 =/= t --> ~at-time(e,t1)
> > > >
> > > time-span-of is a predicate rather than a function because until the
> > > time ontology is extended to aggregates of temporal entities, the
> > > function would not be defined for noncontiguous eventualities.
> > > Whether the eventuality obtains at the start and end points of its
> > > time span is a matter for the event ontology to specify. The silence
> > > here on this issue is the reason time-span-of is not defined in terms
> > > of necessary and sufficient conditions.
>
> > The relation "time-span-of" maps to 'WhenFn' in the SUMO.
>
> > > The event ontology could extend temporal functions and predicates to
> > > apply to events in the obvious way, e.g.,
> > >
> > > ev-start-of(e) = t <--> time-span-of(T,e) & start-of(T) = t
> > >
> > > This would not be part of the time ontology, but would be consistent
> > > with it.
>
> > The relation ev-start-of can be easily composed with the functions
> > 'WhenFn' and 'BeginFn' in the SUMO.
>
>Exactly.
>
> > > 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. This is a matter for the event ontology to specify.
> > > This time ontology is neutral with respect to the choice.
>
> > The inherent complexity of these distinctions is one reason why we don't
> > distinguish states from events under 'Processes' in the SUMO.
>
>A DAML time ontology stands to gain the most users if it supports a
>wide spectrum of community practices.
>
>.....................
>
> > > 3. Measuring Durations
> > >
> > > 3.1. Temporal Units:
> > >
> > > This development assumes ordinary arithmetic is available.
> > >
> > > There are at least two approaches that can be taken 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've adopted the second approach in the SUMO. However, as
> > is pointed out below, this isn't a major issue since the
> > two approaches are interdefinable.
>
> > > The two approaches are interdefinable:
> > >
> > > seconds(T) = duration(T,*Second*)
> > > minutes(T) = duration(T,*Minute*)
> > > hours(T) = duration(T,*Hour*)
> > > days(T) = duration(T,*Day*)
> > > weeks(T) = duration(T,*Week*)
> > > months(T) = duration(T,*Month*)
> > > years(T) = duration(T,*Year*)
> > >
> > > Ordinarily, the first is more convenient for stating specific facts
> > > about particular units. The second is more convenient for stating
> > > general facts about all units.
> > >
> > > The aritmetic relations among the various units are as follows:
> > >
> > > seconds(T) = 60 * minutes(T)
> > > minutes(T) = 60 * hours(T)
> > > hours(T) = 24 * days(T)
> > > days(T) = 7 * weeks(T)
> > > months(T) = 12 * years(T)
>
> > The first four of these equivalences are in the SUMO. The
> > last one isn't, because a month is not a fixed duration - it
> > varies from 28 days to 31 days. Furthermore, not just any 12
> > months add up to a year. These months must be successive,
> > and possibly only the 12 months between December and January
> > of a given calendar year should be counted as making up a year.
>
>I once got a bill from a lawyer saying payment had to be made within
>two months of receipt of the bill, and it was clear what was meant.
>It's easy to imagine web sites wanting to encode information like
>this. So months are a legitimate and necessary measure. It's just
>that they have to be defined after the facts about the calendar have
>been specified, as I do below. You are right that there is no simple
>multiplicative relation between months and days.
>
>If someone has slept for 15 years over the course of his life, then he
>has slept for 180 months over the course of his life. So the
>multiplicative relation between years and months as measures is valid.
>Just how years are made up out of months is defined below.
>
> > > The relation between days and months (and, to a lesser extent, years)
> > > will be specified as part of the ontology of clock and calendar below.
> > > On their own, however, month and year are legitimate temporal units.
>
> > Month is a legitimate unit of temporal position, but I don't
> > think it's a legitimate unit of temporal duration for the
> > reasons given above.
>
>See above.
>
> > >
> > > In this development durations are treated as functions on intervals
> > > and units, and not as first class entities on their own, as in some
> > > approaches. In the latter approach, durations are essentially
> > > equivalence classes of intervals of the same length, and the length of
> > > the duration is the length of the members of the class. The relation
> > > between an approach of this sort (indicated by prefix D-) and the one
> > > presented here is straightforward.
> > >
> > > (A T,u,n)[duration(T,u) = n
> > > <--> (E d)[D-duration-of(T) = d & D-duration(d,u) = n]]
> > >
> > > At the present level of development of the temporal ontology, this
> > > extra layer of representation seems superfluous. It may be more
> > > compelling, however, when the ontology is extended to deal with the
> > > combined durations of noncontiguous aggregates of intervals.
>
> > In the SUMO, durations are first class entities. We
> > distinguish instances of 'TimePosition' from 'TimeDuration'
> > for the same reason that we distinguish objects from the
> > measures of those objects.
>
>That's probably the right approach for measuring the total duration of
>aggregates of intervals.
>
>....................
>
> > > Finally, we would like to say that the set S covers x. A simple way
> > > to say this is as follows:
> > >
> > > Hath(S,N,u,x)
> > > --> (A t)[inside(t,x)
> > > --> (E y)[member(y,S) & in-interval(t,y)]]
>
> > We use 'duration' to express the relationship between a
> > 'TimePosition' and a 'TimeDuration' in the SUMO.
>
>The problem is to say that any point in an interval in a point in one
>of the subintervals of which it is comprised.
>
> > > That is, if an instant t is inside x, there is a smaller unit y that t
> > > is inside or the start of.
> > >
> > > However, this is a good place to introduce notions of granularity. In
> > > describing the temporal properties of some class of events, it may
> > > make sense to specify their time with respect to some temporal unit
> > > but not with respect to a smaller temporal unit. For example, one
> > > might want to talk about an election as a point-like event being at
> > > some instant, and specifying the day that instant is in, but not
> > > specifying the hour or minute.
>
> > I don't see why this has to be so complex. To say that an
> > event, e.g. an election, occurs at some point in time, e.g. a
> > day, one can just write the following in the SUMO:
> >
> > (temporalPart (WhenFn ThisElection) Today)
>
>Maybe. I can imagine being talked out of this position. But I'd want
>to consider some other examples of granularity first.
>
> > > To accomodate this, the above axiom can be loosened by applying it
> > > only when the instant t is located in _some interval_ of size u. The
> > > axiom above would be modified as follows:
> > >
> > > Hath(S,N,u,x)
> > > --> (A t,y1)[inside(t,x) & inside(t,y1) & duration(y1,u)
> > > --> (E y)[member(y,S) & in-interval(t,y)]]
> > >
> > >
> > > Essentially, the conjuncts "inside(t,y1) & duration(y1,u)" specify
> > > that t can be viewed at a granularity of u.
> > >
> > > This treatment of Hath could be extended to measurable quantities in
> > > general.
> > >
> > > 3.3. The Structure of Temporal Units:
> > >
> > > We now define predicates true of intervals that are one temporal unit
> > > long. For example, "week" is a predicate true of intervals whose
> > > duration is one week.
> > >
> > > second(T) <--> seconds(T) = 1
> > > minute(T) <--> minutes(T) = 1
> > > hour(T) <--> hours(T) = 1
> > > day(T) <--> days(T) = 1
> > > week(T) <--> weeks(T) = 1
> > > month(T) <--> months(T) = 1
> > > year(T) <--> years(T) = 1
> > >
> > > We are now in a position to state the relations between successive
> > > temporal units.
> > >
> > > minute(T) --> (E S) Hath(S,60,*Second*,T)
> > > hour(T) --> (E S) Hath(S,60,*Minute*,T)
> > > day(T) --> (E S) Hath(S,24,*Hour*,T)
> > > week(T) --> (E S) Hath(S,7,*Day*,T)
> > > year(T) --> (E S) Hath(S,12,*Month*,T)
>
> > With the exception of a year's being 12 months in
> > length, all of this can be easily stated in the SUMO.
>
> > > >The relations between months and days are dealt with in
> > Section 4.4.
>
>....................
>
> > > The principal functions and predicates will specify a clock or
> > > calendar unit interval to be the nth such unit in a larger interval.
> > > The time zone need not be specified in this predication if it is
> > > already built into the nature of the larger interval. That means that
> > > the time zone only needs to be specified in the largest interval, that
> > > is, the Common Era; that time zone will be inherited by all smaller
> > > intervals. Thus, the Common Era can be considered as a function from
> > > time zones to intervals.
> > >
> > > CE(z) = T
>
> > We don't have this function, because it's assumed in the SUMO
> > that all times concern the Common Era.
>
>The main reason I introduced CE was to fill in the blank in
>
> December 3 is the 3rd day of December.
> Sunday is the 1st day of the week.
> Midnight to 1 A.M. is the 1st hour of the day.
> January is the 1st month of the year.
> 2002 is the 2002nd year of _______.
>
>I.e., it's because I'm axiomatizing the clock and calendar units in
>terms of the predicates clock-int and cal-int below.
>
>In addition, it turns out to be a good place to stash the time zone.
>
> > > Fortunately, this counterintuitive conceptualization will usually be
> > > invisible and, for example, will not be evident in the most useful
> > > expressions for time, in Section 4.5 below. In fact, the CE
> > > predication functions as a good place to hide considerations of time
> > > zone when they are not relevant.
> > >
> > > Time zones should not be thought of as geographical regions. Most
> > > places change their time zone twice a year, and a state or county
> > > might decide to change its time zone, e.g., from Central Standard to
> > > Eastern Standard. Rather it is better to have a separate ontology
> > > articulate the relation between geographical regions X times and time
> > > zones. For example, it would state that on a certain day and time a
> > > particular region changes its time zone from Eastern Standard to
> > > Eastern Daylight.
>
> > I agree that making time zone a subclass of geographical
> > region is a less than optimal solution to the problem (the
> > solution adopted in the SUMO, by the way), but I don't
> > think that I understand the counterproposal.
>
>Think of a time zone as its own kind of legal entity.
>
>.........................
>
> > > It is useful to have three ways of saying the same thing: the clock or
> > > calendar interval y is the nth clock or calendar interval of type u in
> > > a larger interval y in time zone z. This can be expressed as follows
> > > for minutes:
> > >
> > > min(y,n,x)
> > >
> > > Because y is uniquely determined by n and x, it can also be expressed
> > > as follows:
> > >
> > > minFn(n,x) = y
> > >
> > > For stating general properties about clock intervals, it is useful
> > > also to have the following way to express the same thing:
> > >
> > > clock-int(y,n,u,x)
> > >
> > > This expression says that y is the nth clock interval of type u in x.
> > > For example, the proposition "clock-int(10:03,3,*Minute*,[10:00,11:00])"
> > > holds.
> > >
> > > Here u is a member of the set of clock units, that is, one of
> > > *Second*, *Minute*, or *Hour*.
> > >
> > > In addition, there is a calendar unit function with similar structure:
> > >
> > > cal-int(y,n,u,x)
> > >
> > > This says that y is the nth calendar interval of type u in x. For
> > > example, the proposition "cal-int(12Mar2002,12,*Day*,Mar2002)" holds.
> > > Here u is one of the calendar units *Day*, *Week*, *Month*, and *Year*.
>
> > We express these things in SUMO a la Cyc with a set of cascading
> > functions. For example, the proposition above would be
> > written in the SUMO as '(DayFn 12 (MonthFn March (YearFn
> > 2002)))'. One advantage of this approach is that it's completely
> > compositional.
>
>Right. That's the second method I proposed.
>
> > > The am/pm designation of hours is represented by the function hr12.
> > >
> > > hr12(y,n,*am*,x) <--> hr(y,n,x)
> > > hr12(y,n,*pm*,x) <--> hr(y,n+12,x)
>
> > We use military time in the SUMO. If it were deemed
> > important, we could add this function to the SUMO.
>
> > > Each of the calendar intervals is that unit long; a calendar year is a
> > > year long.
> > >
> > > sec(y,n,x) --> second(y)
> > > min(y,n,x) --> minute(y)
> > > hr(y,n,x) --> hour(y)
> > > da(y,n,x) --> day(y)
> > > mon(y,n,x) --> month(y)
> > > yr(y,n,x) --> year(y)
>
> > All of these equivalences are in the SUMO.
>
>.................................
>
> > > The days of the week have special names in English.
> > >
> > > dayofweek(y,1,x) <--> Sunday(y,x)
> > > dayofweek(y,2,x) <--> Monday(y,x)
> > > dayofweek(y,3,x) <--> Tuesday(y,x)
> > > dayofweek(y,4,x) <--> Wednesday(y,x)
> > > dayofweek(y,5,x) <--> Thursday(y,x)
> > > dayofweek(y,6,x) <--> Friday(y,x)
> > > dayofweek(y,7,x) <--> Saturday(y,x)
> > >
> > > For example, Sunday(y,x) says that y is the Sunday of week x.
>
> > In the SUMO, we represent this by saying that, e.g. Wednesday
> > comes between Tuesday and Thursday in any given week:
> >
> > (=>
> > (and
> > (instance ?DAY1 Tuesday)
> > (instance ?DAY2 Wednesday)
> > (instance ?WEEK Week)
> > (temporalPart ?DAY1 ?WEEK)
> > (temporalPart ?DAY2 ?WEEK))
> > (meetsTemporally ?DAY1 ?DAY2))
> >
>
>In the development I proposed, these facts should be derivable from
>the axiomatization of cal-int.
>
> > > A day of the week is also a day of the month (and vice versa), and
> > > thus a day long.
> > >
> > > (A y)[[(E n,x) dayofweek(y,n,x)] <--> [(E n1,x1) da(y,n1,x1)]]
>
> > The 'DayFn' function in the SUMO takes care of the mapping
> > from a day of a month to a day of the week.
>
> > > One correspondance will anchor the cycle of weeks to the rest of the
> > > calendar, for example, saying that January 1, 2002 was the Tuesday of
> > > some week x.
> > >
> > > (A z)(E x) Tuesday(dayFn(1,monFn(1,yrFn(2002,CE(z)))),x)
> > >
> > > We can define weekdays and weekend days as follows:
> > >
> > > weekday(y,x) <--> [Monday(y,x) v Tuesday(y,x) v Wednesday(y,x)
> > > v Thursday(y,x) v Friday(y,x)]
> > >
> > > weekendday(y,x) <--> [Saturday(y,x) v Sunday(y,x)]
>
> > We can easily add the terms 'WeekDay' and 'WeekendDay' to the
> > SUMO if they're needed.
>
>........................
>
> > > 4.5. Time Stamps:
> > >
> > > Standard notation for times list the year, month, day, hour, minute,
> > > and second. It is useful to define a predication for this.
> > >
> > > time-of(t,y,m,d,h,n,s,z)
> > > <-->
>in-interval(t,secFn(s,minFn(n,hrFn(h,daFn(d,monFn(m,yrFn(y,CE(z))))))))
> > >
> > > For example, an instant t has the time
> > >
> > > 5:14:35pm PST, Wednesday, February 6, 2002
> > >
> > > if the following properties hold for t:
> > >
> > > time-of(t,2002,2,6,17,14,35,*PST*)
> > > (E w,x)[in-interval(t,w) & Wednesday(w,x)]
> > >
> > > The second line says that t is in the Wednesday w of some week x.
>
> > Time in the SUMO is expressed with the cascading time
> > functions ('SecondFn', 'MinuteFn', 'HourFn', etc.) and the
> > 'RelativeTimeFn' function (if one intends a time zone other
> > than coordinated universal time).
>
>My aim with time-of was to provide a way of specifying dates that is
>very close to the forms we all know and love, e.g., things like the
>"Wed, 10 Apr 2002 17:10:45 -0700" that we see in the headers of our
>email. I would think it would hinder widespread adoption if the only
>way to specify dates involved nested parenthese to a depth of 8. But
>I know you are against introducing predicates for merely
>presentational purposes. A matter for further debate.
>
>............................
>
> > > 5. Deictic Time
> > >
> > > Deictic temporal concepts, such as ``now'', ``today'', ``tomorrow
> > > night'', and ``last year'', are more common in natural language texts
> > > than they will be in descriptions of Web resources, and for that
> > > reason we are postponing a development of this domain until the first
> > > three are in place. But since most of the content on the Web is in
> > > natural language, ultimately it will be necessary for this ontology to
> > > be developed. It should, as well, mesh well with the annotation
> > > standards used in automatic tagging of text.
> > >
> > > We expect that the key concept in this area will be a relation
> > > _now_ between an instant and an utterance or document.
> > >
> > > now(t,d)
> > >
> > > The concept of "today" would also be relative to a document, and would
> > > be defined as follows:
> > >
> > > today(T,d) <--> (E t,n,x)[now(t,d) & in-interval(t,T) &
> da(T,n,x)]
> > >
> > > That is, T is today with respect to document d if and only if there is
> > > an instant t in T that is now with respect to the document and T is a
> > > calendar day (and thus the nth calendar day in some interval x).
> > >
> > > Present, past and future can be defined in the obvious way in terms of
> > > now and before.
>
> > Since "now" is such a problematic notion, we believe it's preferable
> > to define past and future in terms of other concepts. This is
> > the approach we have taken in the SUMO, where past and future
> > are relative to the temporal extent of a process or object.
>
>I am more confident than you that problems with "now" can be worked
>out, and I think the notion of a time of composition or validity of a
>web page is an essential notion to have in DAML, but I agree that
>dealing with aggregates of temporal entities should have more priority
>right now (=17Apr02).
Adam Pease
Teknowledge
(650) 424-0500 x571
This archive was generated by hypermail 2.1.4 : 04/23/02 EDT