From: Jerry Hobbs ([email protected])
Date: 03/13/02
This is a follow-up message on our discussions at the February DAML PI
meeting. I'm sending it out to daml-time, and also to other people I
know who have done work on time and may not be involved in DAML.
Excuse duplicates; I don't know who is on daml-time. (Let me know if
you don't want further email on this.)
I have appended a first cut at the abstract characterization of an
ontology of time for DAML. This should be viewed as a very
provisional sketch. I have tried to elaborate on each of the domains
we talked about in February, describing the concepts and facts that
seem to me to be central in each of the domains. I've used "textbook"
first-order predicate logic for expressing the facts. Obviously, the
final DAML version will look much different, but hopefully will cover
the same ground.
I have no commitment to the names used for predicates and functions.
Often they were just what occurred to me at the moment of writing.
In the spirit of DAML, I have tried to make the time ontology cleanly
separated from other ontologies one might build, such as for events,
where the interface between them will involve the minimum of elements.
The only ontology I have assumed is arithmetic, although I point out a
couple of places where the ontology of time could be built on a more
basic ontology of scalar quantities.
I've included a MAPPINGS subsection at the end of each section,
relating the ontology presented here to some of the other prominent
temporal ontologies, but I've done it in only a very very sketchy
fashion, since each of them is known much more thoroughly by its
developers. In particular, I have been cautious not to say what some
ontology does NOT cover; we all know how difficult it is to prove the
NONexistence of something.
What have I left out? What concepts and facts that are essential for
an ontology of time are missing?
What concepts and facts could be treated in a better manner? What
mistakes are there?
What difficulties arise in trying to construct a mapping from your own
ontology to this one?
-- Jerry
A DAML Ontology of Time
1. Introduction
A number of sites, DAML contractors and others, have developed
ontologies of time (e.g., DAML-S, Cycorp, CMU, Kestrel, Teknowledge).
A group of us have decided to collaborate to develop a representative
ontology of time for DAML, which could then be used as is or
elaborated on by others needing such an ontology. It is hoped that
this collaboration will result in an ontology that will be adopted
much more widely than any single site's product would be.
We envision three aspects to this effort:
1. An abstract characterization of the concepts and their
properties, expressed in first-order predicate calculus.
2. A translation of the abstract ontology into DAML code, to
whatever extent possible given the current state of DAML
expressivity.
3. Mappings between the DAML ontology and individual sites'
ontologies.
DAML is under development and is thus a moving target, and that is why
separating 1 and 2 is desirable. Level 1 can stabilize before DAML
does. A mapping in 3 may be an isomorphism, or it may be something
more complicated. The reason for 3 is so DAML users can exploit the
wide variety of resources for temporal reasoning that are available.
Moreover, it will aid the widespread use of the ontology if it can be
linked easily to, for example, the temporal portion of Teknowledge's
IEEE Standard Upper Ontology effort or to Cycorp's soon-to-be widely
used knowledge base.
The purposes of the temporal ontology are both for expressing temporal
aspects of the contents of web resources and for expressing
time-related properties of web services.
The following document outlines the principal features of a
representative DAML ontology of time. It is informed by ontology
efforts at a number of sites and reflects but elaborates on a
tentative consensus during discussions at the last DAML meeting. The
first three areas are spelled out in significant detail. The last three
are just sketches of work to be done.
There are a number of places where it is stated that the ontology is
silent about some issue. This is done to avoid controversial choices
in the ontolgy where more than one treatment would be reasonable and
consistent. Often these issues involve identifying a two-dimensional
entity and a one-dimensional entity with one another.
In general, functions are used where they are total and have a unique
value; predicates are used otherwise. The order of arguments usually
follows the subject-object-object of preposition order in the most
natural use in an English sentence (except for "Hath", where
topicalization applies).
A note on notation: Conjunction (&) takes precedence over
implication(-->) and equivalence (<-->). Formulas are assumed to be
universally quantified on the variables appearing in the antecedent of
the highest-level implication. Thus,
p1(x) & p2(y) --> q1(x,y) & q2(y)
is to be interpreted as
(A x,y)[[p1(x) & p2(y)] --> [q1(x,y) & q2(y)]]
At the end of each section there is a subsection on MAPPINGS. These
are sketches of the relations between some highly developed temporal
ontologies and the one outlined here.
2. Topological Temporal Relations
2.1. Instants and Intervals:
There are two subclasses of temporal-entity: instant and interval.
instant(t) --> temporal-entity(t)
interval(T) --> temporal-entity(T)
(In what follows, lower case t is used for instants, upper case T for
intervals and for temporal-entities unspecified as to subtype. This
is strictly for the reader's convenience, and has no formal
significance.)
start-of and end-of are functions from temporal entities to instants.
temporal-entity(T) --> instant(start-of(T))
temporal-entity(T) --> instant(end-of(T))
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
inside is a relation between an instant and an interval.
inside(t,T) --> instant(t) & interval(T)
This concept of inside is not intended to include starts and ends of
intervals, as will be seen below.
Infinite and half-infinite intervals can be handled by positing time
instants at positive and negative infinity, and using them as start
and end points.
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)]
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 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)
The ontology is silent about whether there are any intervals that are
not proper-intervals.
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 ontology is silent about whether there is an interval from t to t.
If an instant is inside a proper interval, then the start of the
interval is before the instant, which is before the end of the
interval. The converse is true as well.
instant(t) & proper-interval(T)
--> [inside(t,T) <--> before(start-of(T),t) & before(t,end-of(T))]
Intervals are contiguous with respect to the before relation, in that
an instant between two other instants inside an interval is inside the
interval.
before(t1,t2) & before(t2,t3) & inside(t1,T) & inside(t3,T)
--> inside(t2,T)
The before relation is anti-symmetric and transitive.
before(T1,T2) --> ~before(T2,T1)
before(T1,T2) & before(T2,T3) --> before(T1,T3)
The relation after is defined in terms of before.
after(T1,T2) <--> before(T2,T1)
The ontology is silent about whether time is linearly ordered.
2.3. Interval Relations:
The 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.
interval(T1) & interval(T2)
--> [int-equals(T1,T2)
<--> start-of(T1) = start-of(T2) & end-of(T1) = end-of(T2)]
interval(T1) & interval(T2)
--> [int-before(T1,T2) <--> before(T1,T2)
interval(T1) & interval(T2)
--> [int-after(T1,T2) <--> after(T1,T2)
interval(T1) & interval(T2)
--> [int-meets(T1,T2) <--> end-of(T1) = start-of(T2)
interval(T1) & interval(T2)
--> [int-met-by(T1,T2) <--> int-meets(T2,T1)]
interval(T1) & interval(T2)
--> [int-overlaps(T1,T2)
<--> before(start-of(T1),start-of(T2))
& before(start-of(T2),end-of(T1))
& before(end-of(T1),end-of(T2))]
interval(T1) & interval(T2)
--> [int-overlapped-by(T1,T2) <--> int-overlaps(T2,T1)]
interval(T1) & interval(T2)
--> [int-starts(T1,T2)
<--> start-of(T1) = start-of(T2) & before(end-of(T1),end-of(T2)]
interval(T1) & interval(T2)
--> [int-started-by(T1,T2) <--> int-starts(T2,T1)]
interval(T1) & interval(T2)
--> [int-during(T1,T2)
<--> (before(start-of(T2),start-of(T1))
& before(end-of(T1),end-of(T2))]
interval(T1) & interval(T2)
--> [int-contains(T1,T2) <--> int-during(T2,T1)]
interval(T1) & interval(T2)
--> [int-finishes(T1,T2)
<--> before(start-of(T2),start-of(T1)) & end-of(T1) = end-of(T2)]
interval(T1) & interval(T2)
--> [int-finished-by(T1,T2) <--> int-finishes(T2,T1)]
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)]
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)]
So far, the concepts and axioms in the ontology of time would be
appropriate for scalar phenomena in general.
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.
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)
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, and is assumed to be provided by the event
ontology.
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)
The event ontology may provide other ways of linking events with
times, for example, by including a time parameter in predications.
p(x,t)
This time ontology provides ways of reasoning about the t's; their use
as arguments of predicates from another domain would be a feature of
the ontology of the other domain.
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 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.
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.
MAPPINGS:
Teknowledge's SUMO has pretty much the same ontology as presented
here, though the names are slightly different. An instant is a
TimePoint, an interval is a TimeInterval, start-of is BeginFn, ans so
on. SUMO implements the Allen calculus.
Cyc has functions #startingPoint and #endingPoint that apply to
intervals, but also to eventualities. Cyc implements the Allen
calculus. Cyc uses a holdIn predicate to relate events to times, but
to other events as well. Cyc defines a very rich set of derived
concepts that are not defined here, but could be.
For instant Kestral uses Time-Point, for interval they use
Time-Interval, for start-of they use start-time-point, and so on.
PSL axiomatizes before as a total ordering.
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
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 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.
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.
3.2. Hath:
The multiplicative relations above don't tell the whole story of the
relations among temporal units. Temporal units are _composed of_
smaller temporal units. The basic predicate used here for expressing
the composition of larger intervals out of smaller clock and calendar
intervals is "Hath", from statements like "30 days hath September" and
"60 minutes hath an hour." Its structure is
Hath(S,N,u,x)
meaning "A set S of N calendar intervals of type u hath the calendar
interval x." That is, if Hath(S,N,u,x) holds, then x is composed of
the disjoint union of N intervals of type u; S is the set of those
intervals. For example, if x is some month of September and S is the
set of the successive days of that September, then "Hath(S,30,*Day*,x)"
would be true.
The principal properties of Hath are as follows:
The type constraints on its arguments: S is a set, N is an integer, u
is a temporal unit, and x is an interval:
Hath(S,N,u,x) --> set(S) & integer(N) & temporal-unit(u) & interval(x)
The elements of S are intervals of duration u:
Hath(S,N,u,x) --> (A y)[member(y,S) --> interval(y) & duration(y,u) =
1]
S has N elements:
Hath(S,N,u,x) --> card(S) = N
The elements of S are disjoint:
Hath(S,N,u,x)
--> (A y1,y2)[member(y1,S) & member(y2,S) & y1 =/= y2
--> int-disjoint(y1,y2)]
There are elements in S that start and finish x:
Hath(S,N,u,x) --> (E y1)[member(y1,S) & int-starts(y1,x)]
Hath(S,N,u,x) --> (E y2)[member(y2,S) & int-finishes(y2,x)]
Except for the first and last elements of S, every element of S has an
element that precedes and follows it:
Hath(S,N,u,x)
--> (A y1)[member(y1,S)
--> [int-finishes(y1,x)
v (E y2)[member(y2,x) & int-meets(y1,y2)]]]
Hath(S,N,u,x)
--> (A y2)[member(y2,S)
--> [int-starts(y2,x)
v (E y1)[member(y1,x) & int-meets(y1,y2)]]]
If time is linearly ordered, the existential quantifier E in the last
four axioms can be replaced by E!.
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)]]
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.
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)
The relations between months and days are dealt with in Section 4.4.
3.4. Temporal Arithmetic:
Coming attraction.
MAPPINGS:
Teknowledge's SUMO has some facts about the lengths of temporal units
in terms of smaller units.
Cyc reifies durations. Cyc's notion of time covering subsets aims at
the same concept dealt with here with Hath.
Kestrel uses temporal units to specify the granularity of the time
representation.
PSL reifies and axiomatizes durations. PSL includes a treatment of
delays between events. This is not treated here, but could be.
4. Clock and Calendar
4.1. Time Zones:
What hour of the day an instant is in is relative to the time zone.
This is also true of minutes, since there are regions in the world,
e.g., central Australia, where the hours are not aligned with GMT
hours, but are, e.g., offset half an hour. Probably seconds are not
relative to the time zone.
Days, weeks, months and years are also relative to the time zone,
since, e.g., 2002 began in the Eastern Standard time zone three hours
before it began in the Pacific Standard time zone. Thus, predications
about all clock and calendar intervals except seconds are relative to
a time zone.
This can be carried to what seems like a ridiculous extreme, but turns
out to yield a very concise treatment. The Common Era (C.E. or A.D.) is
also relative to a time zone, since 2002 years ago, it began three
hours earlier in what is now the Eastern Standard time zone than in
what is now the Pacific Standard time zone. What we think of as the
Common Era is in fact 24 (or more) slightly displaced half-infinite
intervals. (We leave B.C.E. to specialized ontologies.)
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
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.
Moreover, time zones that seem equivalent, like Eastern Standard and
Central Daylight, should be thought of as separate entities. Whereas
they function the same in the time ontology, they do not function the
same in the ontology that articulates time and geography. For
example, parts of Indiana are always on Eastern Standard Time, and it
would be false to say that they shift in April from that to Central
Daylight time.
In this treatment it will be assumed there is a set of entities called
time zones. Some relations among time zones are discussed in Section
4.5.
4.2. Clock and Calendar Units:
The aim of this section is to explicate the various standard clock and
calendar intervals. A day as a calender interval begins at and
includes midnight and goes until but does not include the next
midnight. By contrast, a day as a duration is any interval that is 24
hours in length. The day as a duration was dealt with in Section 3.
This section deals with the day as a calendar interval.
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*.
The unit *DayOfWeek* will be introduced below in Section 4.3.
The relations among these modes of expression are as follows:
sec(y,n,x) <--> secFn(n,x) = y <--> clock-int(y,n,*sec*,x)
min(y,n,x) <--> minFn(n,x) = y <--> clock-int(y,n,*min*,x)
hr(y,n,x) <--> hrFn(n,x) = y <--> clock-int(y,n,*hr*,x)
da(y,n,x) <--> daFn(n,x) = y <--> cal-int(y,n,*da*,x)
mon(y,n,x) <--> monFn(n,x) = y <--> cal-int(y,n,*mon*,x)
yr(y,n,x) <--> yrFn(n,x) = y <--> cal-int(y,n,*yr*,x)
Weeks and months are dealt with separately below.
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)
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)
A distinction is made above between clocks and calendars because they
differ in how they number their unit intervals. The first minute of
an hour is labelled with 0; for example, the first minute of the hour
[10:00,11:00] is 10:00. The first day of a month is labelled with 1;
the first day of March is March 1. We number minutes for the number
just completed; we number days for the day we are working on. Thus,
if the larger unit has N smaller units, the argument n in clock-int
runs from 0 to N-1, whereas in cal-int n runs from 1 to N. To state
properties true of both clock and calendar intervals, we can use the
predicate cal-int and relate the two notions with the axiom
cal-int(y,n,u,x) <--> clock-int(y,n-1,u,x)
The type constraints on the arguments of cal-int are as follows:
cal-int(y,n,u,x) --> interval(y) & integer(n) & temporal-unit(u)
& interval(x)
There are properties relating to the labelling of clock and calendar
intervals. If N u's hath x and y is the nth u in x, then n is between
1 and N.
cal-int(y,n,u,x) & Hath(S,N,u,x) & member(y,S) --> 0 < n <= N
There is a 1st small interval, and it starts the large interval.
Hath(S,N,u,x)
--> (E y)[member(y,S) & cal-int(y,1,u,x)]
Hath(S,N,u,x) & cal-int(y,1,u,x) --> int-starts(y,x)
There is an Nth small interval, and it finishes the large interval.
Hath(S,N,u,x)
--> (E y)[member(y,S) & cal-int(y,N,u,x)]
Hath(S,N,u,x) & cal-int(y,N,u,x) --> int-finishes(y,x)
All but the last small interval have a small interval that succeeds
and is met by it.
cal-int(y1,n,u,x) & Hath(S,N,u,x) & member(y1,S) & n < N
--> (E y2)[cal-int(y2,n+1,u,x) & int-meets(y1,y2)]
All but the first small interval have a small interval that precedes
and meets it.
cal-int(y2,n,u,x & Hath(S,N,u,x) & member(y2,S) & 1 < n
--> (E y1)[cal-int(y1,n-1,u,x) & int-meets(y1,y2)]
If time is linearly ordered, the existential quantifier E can be
replaced by E! in the above axioms.
4.3. Weeks
A calendar week starts at midnight, Saturday night, and goes to the
next midnight, Saturday night. It is independent of months and years.
However, we can still talk about the nth week in some larger period of
time, e.g., the third week of the month or the fifth week of the
semester. So the same three modes of representation are appropriate
for weeks as well.
wk(y,n,x) <--> wkFn(n,x) = y <--> cal-int(y,n,*Week*,x)
As it happens, the n and x arguments will often be irrelevant.
A calendar week is one week long.
wk(y,n,x) --> week(y)
The day of the week is a temporal unit (*DayOfWeek*) in a larger
interval, so the three modes of representation are appropriate here as
well.
dayofweek(y,n,x) <--> dayofweekFn(n,x) = y
<--> cal-int(y,n,*DayOfWeek*,x)
Whereas it makes sense to talk about the nth day in a year or the nth
minute in a day or the nth day in a week, it does not really make
sense to talk about the nth day-of-the-week in anything other than a
week. Thus we can restrict the x argument to be a calendar week.
dayofweek(y,n,x) --> (E n1,x1) wk(x,n1,x1)
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.
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)]]
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)]
4.4. Months and Years
The months have special names in English.
mon(y,1,x) <--> January(y,x)
mon(y,2,x) <--> February(y,x)
mon(y,3,x) <--> March(y,x)
mon(y,4,x) <--> April(y,x)
mon(y,5,x) <--> May(y,x)
mon(y,6,x) <--> June(y,x)
mon(y,7,x) <--> July(y,x)
mon(y,8,x) <--> August(y,x)
mon(y,9,x) <--> September(y,x)
mon(y,10,x) <--> October(y,x)
mon(y,11,x) <--> November(y,x)
mon(y,12,x) <--> December(y,x)
The number of days in a month have to be spelled out for individual
months.
January(m,y) --> (E S) Hath(S,31,*Day*,m)
March(m,y) --> (E S) Hath(S,31,*Day*,m)
April(m,y) --> (E S) Hath(S,30,*Day*,m)
May(m,y) --> (E S) Hath(S,31,*Day*,m)
June(m,y) --> (E S) Hath(S,30,*Day*,m)
July(m,y) --> (E S) Hath(S,31,*Day*,m)
August(m,y) --> (E S) Hath(S,31,*Day*,m)
September(m,y) --> (E S) Hath(S,30,*Day*,m)
October(m,y) --> (E S) Hath(S,31,*Day*,m)
November(m,y) --> (E S) Hath(S,30,*Day*,m)
December(m,y) --> (E S) Hath(S,31,*Day*,m)
The definition of a leap year is as follows:
(A z)[leap-year(y)
<--> (E n,x)[year(y,n,(CE(z))
& [divides(400,n) v [divides(4,n) & ~divides(100,n)]]]
We leave leap seconds to specialized ontologies.
Now the number of days in February can be specified.
February(m,y) & leap-year(y) --> (E S) Hath(S,29,*Day*,m)
February(m,y) & ~leap-year(y) --> (E S) Hath(S,28,*Day*,m)
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.
month(T)
<--> (E d1,d2,n,x,m)[in-interval(start-of(T),d1)
& in-interval(end-of(T),d2)
& da(d1,n,monFn(m,x))
& da(d2,n,monFn(mod+(m,1,12),x))]
Here "mod+" is modulo addition to take care of months spaning December
and January. So the month as a measure of duration would be related
to days as a measure of duration only indirectly, mediated by the
calendar.
To say that July 4 is a holiday in the United States one could write
(A d,m,y)[da(d,4,m) & July(m,y) --> holiday(d,USA)]
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.
The relations among time zones can be expressed in terms of the
time-of predicate. Two examples are as follows:
h < 8 --> [time-of(t,y,m,d,h,n,s,*GMT*)
<--> time-of(t,y,m,d-1,h+16,n,s,*PST*)]
h >= 8 --> [time-of(t,y,m,d,h,n,s,*GMT*)
<--> time-of(t,y,m,d,h-8,n,s,*PST*)]
time-of(t,y,m,d,h,n,s,*EST*) <--> time-of(t,y,m,d,h,n,s,*CDT*)
MAPPINGS:
Teknowledge's SUMO distinguishes between durations (e.g., HourFn) and
clock and calendar intervals (e.g., Hour).
The treatment of dates and times via functions follows Cyc's treatment.
Kestrel's roundabout attempts to state rather straightforward facts
about the clock and calendar are an excellent illustration of the lack
of expressivity in DAML+OIL.
The ISO standard for dates and times can be represented
straightforwardly with the time-of predicate or the unitFn functions.
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.
Another feature of a treatment of deictic time would be an
axiomatization of the concepts of last, this, and next on anchored
sequences of temporal entities.
6. Sequences of Temporal Entities
A number of common expressions and commonly used properties are
properties of sequences of temporal entities. These properties may be
properties of all the elements in the sequence, as in ``every
Wednesday'', or they may be properties of parts of the sequence, as in
``three times a week'' or ``an average of once a year''. We are also
postponing development of this domain until the first three domains
are well in hand.
This may be the proper locus of a duration arithmetic, since we may
want to know the total time an intermittant process is in operation.
7. Vague Temporal Concepts
In natural language a very important class of temporal expressions are
inherently vague. Included in this category are such terms as "soon",
"recently", and "a little while". These require an underlying theory
of vagueness, and in any case are probably not immediately critical
for the Semantic Web. This area will be postponed for a little
while.
This archive was generated by hypermail 2.1.4 : 03/26/02 EST