From: Jerry Hobbs (email@example.com)
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