Latest version

From: Jerry Hobbs (hobbs@ai.sri.com)
Date: 05/02/02

  • Next message: Jerry Hobbs: "Temporal Granularity"
    Principal changes over previous version:
    
    I added instants at plus and minus infinity, as in SUMO.
    
    I rearranged things in the section on "before" (2.2) and made the
    property
    of Convexity explicit.
    
    I augmented the treatment of the interval calculus in ways suggested
    by George Ferguson, and added an esoteric note comparing Convexity,
    Total Ordering, and "Extensional Collapse".
    
    I redid the treatment of Hath (3.2), breaking it up into treatments of
    concatenation and Hath.  I eliminated the attempt to build granularity
    into the treatment of Hath.
    
    I've clarified the section on time zones along the lines of my
    response to Pat Hayes.
    
    
    
    
    
    		       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 -- *PosInf* and *NegInf* --
    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)
    
    time-between is a relation among a temporal entity and two
    instants.
    
    	time-between(T,t1,t2)
    	    --> temporal-entity(T) & instant(t1) & instant(t2)
    
    The two instants are the start and end points of the temporal entity.
    
    	time-between(T,t1,t2)
    	    <--> start-of(T) = t1 & end-of(T) = t2
    
    The ontology is silent about whether the time 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 before relation is anti-reflexive, anti-symmetric and transitive.
    
    	before(T1,T2) --> T1 =/= T2
    	before(T1,T2) --> ~before(T2,T1)
    	before(T1,T2) & before(T2,T3) --> before(T1,T3)
    
    Negative infinity is before every other instant and positive infinity
    is after every other instant.
    
    	t =/= *NegInf* --> before(*NegInf*,t)
    	t =/= *PosInf* --> before(t,*PosInf*)
    
    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))
    
    The converse of this is a theorem.
    
    If one instant is before another, there is a time between them.
    
    	instant(t1) & instant(t2) & before(t1,t2) 
    	    --> (E T) time-between(T,t1,t2)
    
    The ontology is silent about whether there is a time 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.  This is the principal property of "inside".
    
    	inside(t,T) --> before(start-of(T),t) & before(t,end-of(T))
    
    The converse of this condition is called Convexity and may be stronger
    than some users will want if they are modeling time as a partial
    ordering.  (See Esoteric Note in Section 2.3.)
    
    	before(start-of(T),t) & before(t,end-of(T)) --> inside(t,T)
    
    In the rest of this development we will point it out whenever any
    concept or property depends on Convexity.
    
    Convexity implies that intervals are contiguous with respect to the
    before relation, in that an instant between two other instants inside
    an interval is also inside the interval.
    
    	before(t1,t2) & before(t2,t3) & inside(t1,T) & inside(t3,T)
    	    --> inside(t2,T)
    
    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.  Thus
    it supports theories of time, such as the branching futures theory,
    which conflate time and possibility or knowledge.
    
    The ontology is silent about whether time is dense, that is, whether
    between any two instants there is a third instant.  Thus it supports
    theories in which time consists of discrete instants.
    
    2.3.  Interval Relations:
    
    The relations between intervals defined in Allen's temporal interval
    calculus (Allen, 1984; Allen and Kautz, 1985; Allen and Hayes, 1989;
    Allen and Ferguson, 1997) can be defined in a straightforward fashion
    in terms of before and identity on the start and end points.  The
    standard interval calculus assumes all intervals are proper, and we
    will do that here.
    
    	proper-interval(T1) & proper-interval(T2)
    	    --> [int-equals(T1,T2) 
    		<--> start-of(T1) = start-of(T2) & end-of(T1) = end-of(T2)]
    
    	proper-interval(T1) & proper-interval(T2)
    	    --> [int-before(T1,T2) <--> before(T1,T2)
    
    	proper-interval(T1) & proper-interval(T2)
    	    --> [int-after(T1,T2) <--> after(T1,T2)
    
    	proper-interval(T1) & proper-interval(T2)
    	    --> [int-meets(T1,T2) <--> end-of(T1) = start-of(T2)
    
    	proper-interval(T1) & proper-interval(T2)
    	    --> [int-met-by(T1,T2) <--> int-meets(T2,T1)]
    
    	proper-interval(T1) & proper-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))]
    
    	proper-interval(T1) & proper-interval(T2)
    	    --> [int-overlapped-by(T1,T2) <--> int-overlaps(T2,T1)]
    
    	proper-interval(T1) & proper-interval(T2)
    	    --> [int-starts(T1,T2) 
    		<--> start-of(T1) = start-of(T2) & before(end-of(T1),end-of(T2)]
    
    	proper-interval(T1) & proper-interval(T2)
    	    --> [int-started-by(T1,T2) <--> int-starts(T2,T1)]
    
    	proper-interval(T1) & proper-interval(T2)
    	    --> [int-during(T1,T2) 
    		<--> (before(start-of(T2),start-of(T1)) 
    			& before(end-of(T1),end-of(T2))]
    
    	proper-interval(T1) & proper-interval(T2)
    	    --> [int-contains(T1,T2) <--> int-during(T2,T1)]
    
    	proper-interval(T1) & proper-interval(T2)
    	    --> [int-finishes(T1,T2) 
    		<--> before(start-of(T2),start-of(T1)) 
                         & end-of(T1) = end-of(T2)]
    
    	proper-interval(T1) & proper-interval(T2)
    	    --> [int-finished-by(T1,T2) <--> int-finishes(T2,T1)]
    
    The constraints on the arguments of these relations is that they be
    proper intervals.  We only need to state these for half the relations,
    as the other half follow from the definitions.
    
    	int-equals(T1,T2) --> proper-interval(T1) & proper-interval(T2)
    	int-before(T1,T2) --> proper-interval(T1) & proper-interval(T2)
    	int-meets(T1,T2) --> proper-interval(T1) & proper-interval(T2)
    	int-overlaps(T1,T2) --> proper-interval(T1) & proper-interval(T2)
    	int-starts(T1,T2) --> proper-interval(T1) & proper-interval(T2)
    	int-during(T1,T2) --> proper-interval(T1) & proper-interval(T2)
    	int-finishes(T1,T2) --> proper-interval(T1) & proper-interval(T2)
    
    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.
    
    In the standard development of interval calculus, it is assumed that
    any intervals that are int-equals are identical.  That is, intervals
    are uniquely determined by their start and end points.  We can call
    this the property of Extensional Collapse.
    
    	int-equals(T1,T2) --> T1 = T2
    
    If we think of different intervals between the end points as being
    different ways the start can lead to the end, then Extensional
    Collapse can be seen as collapsing all these into a single "before"
    relation.
    
    In the rest of this development we will point it out whenever any
    concept or property depends on Extensional Collapse.
    
    Esoteric Note: Convexity, Extensional Collapse, and Total Ordering are
    independent properties.  This can be seen by considering the following
    four models based on directed graphs, where the arcs define the before 
    relation:
    
        1.  An interval is any subset of the paths between two nodes.
    	(For example, time is partially ordered and an interval is
    	any path from one node to another.)
    
        2.  An interval is the complete set of paths between two nodes.
    
        3.  An interval consists of the start and end nodes and all the
    	arcs between the start and end nodes but no intermediate 
    	nodes.  So inside(t,T) is never true.  (This is a hard model
    	to motivate.)
    
        4.  The instants are a set of discrete, linearly ordered nodes.
    	There are multiple arcs between the nodes.  The intervals are
    	paths from one node to another, including the nodes.  (For
    	example, the instants may be the successive states in the
    	situation calculus and the intervals sequences of actions
    	mapping one state into the next.  Different actions can have 
    	the same start and end states.)
    
    Model 1 has none of the three properties.  Model 2 has Convexity and
    Extensional Collapse, but is not Totally Ordered.  Model 3 is Totally
    Ordered and has Extensional Collapse but not Convexity.  Model 4 is
    Totally Ordered and Convex, but lacks Extensional Collapse.
    
    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) --> 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) --> 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) 
    	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 constraints on the arguments of duration are as follows:
    
    	duration(T,u) --> proper-interval(T) & temporal-unit(u)
    
    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.  Concatenation and 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.  A larger temporal unit is a concatenation of
    smaller temporal units.  We will first define a general relation of
    concatenation between an interval and a set of smaller intervals.
    Then we will introduce a predicate "Hath" that specifies the number of
    smaller unit intervals that concatenate to a larger interval.
    
    Concatenation: A proper interval x is a concatenation of a set S of
    proper intervals if and only if S covers all of x, and all members of
    S are subintervals of x and are mutually disjoint.  (The third
    conjunct on the right side of <--> is because in-interval covers only
    start-of and inside.)
    
        concatenation(x,S) 
    	<--> proper-interval(x)
    	     & (A z)[in-interval(z,x) 
    			--> (E y)[member(y,S) & in-interval(z,y)]]
    	     & (A z)[end-of(x) = z 
    			--> (E y)[member(y,S) & end-of(y) = z]
    	     & (A y)[member(y,S) 
    			--> [int-starts(y,x) v int-during(y,x) 
    					     v int-finishes(y,x)]]
    	     & (A y1,y2)[member(y1,S) & member(y2,S) 
    			--> [y1=y2 v int-disjoint(y1,y2)]]
    
    The following properties of "concatenation" can be proved as theorems:
    
    There are elements in S that start and finish x:
    
    	concatenation(x,S) --> (E! y1)[member(y1,S) & int-starts(y1,x)]
    
    	concatenation(x,S) --> (E! y2)[member(y2,S) & int-finishes(y2,x)]
    
    Except for the first and last elements of S, every element of S has
    elements that precede and follow it.  These theorems depend on the
    property of Convexity.
    
    	concatenation(x,S) 
    	    --> (A y1)[member(y1,S) 
    			--> [int-finishes(y1,x) 
    				v (E! y2)[member(y2,S) & int-meets(y1,y2)]]]
    
    	concatenation(x,S) 
    	    --> (A y2)[member(y2,S) 
    			--> [int-starts(y2,x) 
    				v (E! y1)[member(y1,S) & int-meets(y1,y2)]]]
    
    The uniqueness (E!) follows from int-disjoint.
    
    Hath: The basic predicate used here for expressing the composition of
    larger intervals out of smaller temporal intervals of unit length is
    "Hath", from statements like "30 days hath September" and "60 minutes
    hath an hour."  Its structure is
    
    	Hath(N,u,x)
    
    meaning "N proper intervals of duration one unit u hath the proper
    interval x."  That is, if Hath(N,u,x) holds, then x is the
    concatenation of N unit intervals where the unit is u.  For example,
    if x is some month of September then "Hath(30,*Day*,x)" would be true.
    
    "Hath" is defined as follows:
    
    	Hath(N,u,x) 
    	    <--> (E S)[card(S) = N
    		       & (A z)[member(z,S) --> duration(z,u) = 1]
    		       & concatenation(x,S)]
    
    That is, x is the concatenation of a set S of N proper intervals of
    duration one unit u.
    
    The type constraints on its arguments can be proved as a theorem: N is
    an integer (assuming that is the constraint on the value of card), u
    is a temporal unit, and x is a proper interval:
    
    	Hath(N,u,x) --> integer(N) & temporal-unit(u) & proper-interval(x)
    
    ****
    
    Due to popular demand, I'm giving up trying to build in granularity at
    this point.  If you want an interval to be at the finest granularity
    you are dealing with, you will not specify that it is concatenated out
    of smaller intervals.
    
    ****
    
    This treatment of concatenation will work for scalar phenomena in
    general.  This treatment of Hath will work for 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) --> Hath(60,*Second*,T)
    	hour(T) --> Hath(60,*Minute*,T)
    	day(T) --> Hath(24,*Hour*,T)
    	week(T) --> Hath(7,*Day*,T)
    	year(T) --> Hath(12,*Month*,T)
    
    The relations between months and days are dealt with in Section 4.4.
    
    *****
    
    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 (or "time standards", see below) 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.
    
    Esoteric Aside: Strictly speaking the use of CE as a function depends
    on Extensional Collapse.  If we don't want to assume that, then we can
    use a corresponding predicate -- CEPred(e,z) -- to mean era e is the
    Common Era in time zone z.
    
    We have been refering to time _zones_, but in fact it is more
    convenient to work in terms of what we might call the "time standard"
    that is used in a time zone.  That is, it is better to work with *PST*
    as a legal entity than with the *PST* zone as a geographical region.
    A time standard is a way of computing the time, relative to a
    world-wide system of computing time.  For each time standard, there is
    a zone, or geographical region, and a time of the year in which it is
    used for describing local times.  Where and when a time standard is
    used have to be axiomatized, and this involves interrelating a time
    ontology and a geographical ontology.  These relations can be quite
    complex.  Only the entities like *PST* and *EDT*, the time standards,
    are part of the _time_ ontology.
    
    If we were to conflate time zones (i.e., geographical regions) and
    time standards, it would likely result in problems in several
    situations.  For example, the Eastern Standard zone and the Eastern
    Daylight zone are not identical, since most of Indiana is on Eastern
    Standard time all year.  The state of Arizona and the Navajo Indian
    Reservation, two overlapping geopolitical regions, have different time
    standards -- one is Pacific and one is Mountain.
    
    Time standards 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, it
    would be false to say those parts of Indiana shift in April from
    Eastern Standard to Central Daylight time.
    
    In this treatment it will be assumed there is a set of entities called
    time standards.  Some relations among time standards 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.
    
    Including the start but not the end of a calendar interval in the
    interval may strike some as arbitrary.  But we get a cleaner treatment
    if, for example, all times of the form 12:xx a.m., including 12:00
    a.m. are part of the same hour and day, and all times of the form
    10:15:xx, including 10:15:00, are part of the same minute.
    
    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 x.  This can be expressed as follows for minutes:
    
    	min(y,n,x)
    
    If the property of Extensional Collapse holds, then 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 can be 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 can be 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) 
    
    The temporal units are as follows:
    
    	temporal-unit(*sec*), temporal-unit(*min*), temporal-unit(*hr*), 
    	temporal-unit(*da*), temporal-unit(*mon*), temporal-unit(*yr*)
    
    In addition, from below,
    
    	temporal-unit(*dayofweek*), temporal-unit(*wk*)
    
    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(N,u,x)  --> 0 < n <= N
    
    There is a 1st small interval, and it starts the large interval.
    
    	Hath(N,u,x) --> (E! y) 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(N,u,x) --> (E! y) cal-int(y,N,u,x)
    
    	Hath(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(N,u,x) & 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(N,u,x) & 1 < n
    	    --> (E! y1)[cal-int(y1,n-1,u,x) & int-meets(y1,y2)]
    
    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,*wk*,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)]
    
    As before, the use of the functions wkFn and dayofweekFn depend on
    Extensional Collapse.
    	
    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) --> Hath(31,*Day*,m)
    	March(m,y) --> Hath(31,*Day*,m)
    	April(m,y) --> Hath(30,*Day*,m)
    	May(m,y) --> Hath(31,*Day*,m)
    	June(m,y) --> Hath(30,*Day*,m)
    	July(m,y) --> Hath(31,*Day*,m)
    	August(m,y) --> Hath(31,*Day*,m)
    	September(m,y) --> Hath(30,*Day*,m)
    	October(m,y) --> Hath(31,*Day*,m)
    	November(m,y) --> Hath(30,*Day*,m)
    	December(m,y) --> Hath(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) --> Hath(29,*Day*,m)
    	February(m,y) & ~leap-year(y) --> Hath(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.  The following rather ugly axiom
    captures this.
    
    	month(T) 
    	    <--> (E d1,d2,n,m1,m2,n1,y1,y2,n2,e)
    		     [in-interval(start-of(T),d1) 
    		     & in-interval(end-of(T),d2)
    		     & da(d1,n,m1) & mon(m1,n1,y1) & yr(y1,n2,e)
    		     & da(d2,n,m2) 
    		     & [mon(m2,n1+1,y1) 
    		         v (E y2)[n1=12 & mon(m2,1,y2) & yr(y2,n2+1,e)]]]
    
    The last disjunct takes 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.  It is
    possible to prove that months are between 28 and 31 days.
    
    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))))))))
    
    Alternatively (and not assuming Extensional Collapse), 
    
    	time-of(t,y,m,d,h,n,s,z)
    	    <--> (E s1,n1,h1,d1,m1,y1,e)
    		     [in-interval(t,s1) & sec(s1,s,n1) & min(n1,n,h1) 
    		     & hr(h1,h,d1) & da(d1,d,m1) & mon(m1,m,y1) 
    		     & yr(y1,y,e) & CEPred(e,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*)
    
    The time-of predicate will be convenient for doing temporal
    arithmetic.
    
    MAPPINGS:
    
    Teknowledge's SUMO distinguishes between durations (e.g., HourFn) and
    clock and calendar intervals (e.g., Hour).  Time zones are treated as
    geographical regions.
    
    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 or interval 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.  Aggregates 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.
    
    A reasonable development of this area would be in terms of the
    following subsections.
    
    6.1.  Describing Aggregates of Temporal Entities
    
    6.2.  Durations as Entities
    
    6.3.  Duration Arithmetic
    
    6.4.  Rates
    
    		     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.
    
    			      References
    
    Allen, J.F. (1984). Towards a general theory of action and time.
    Artificial Intelligence 23, pp. 123-154.
    
    Allen, James F., and Henry A. Kautz. 1985. ``A Model of Naive Temporal
    Reasoning'', {\it Formal Theories of the Commonsense World}, ed. by
    Jerry R. Hobbs and Robert C. Moore, Ablex Publishing Corp., pp. 251-268.
    
    Allen, J.F. and P.J. Hayes (1989). Moments and points in an
    interval-based temporal logic. Computational Intelligence 5, pp.
    225-238.
    
    Allen, J.F. and G. Ferguson (1997). Actions and events in interval
    temporal logic. In Oliveiro Stock (ed.), Spatial and Temporal
    Reasoning, Kluwer Academic Publishers, pp. 205-245.
    


    This archive was generated by hypermail 2.1.4 : 05/02/02 EDT