Comments on Pat's comments

From: Drew McDermott (
Date: 04/02/03

  • Next message: pat hayes: "Re: Comments on Pat's comments"
    [[ I'm sending this just to  If that means someone
    obvious is missing, let me know. ]]
    Comments on Pat's comments:
    I tend to agree with his comment that the time-aggregate stuff is much
    too complex.  I've been reviewing RFC 2445, the standard calendar-data
    interchange format, on which the iCal ontology is based.  (I think
    they've changed the name from iCal to something else.)  It has an ad
    hoc notation for temporal aggregates that covers just about every
    possible sort of repeating event.  E.g.:
       Every other week on Monday, Wednesday and Friday until December 24,
       1997, starting on Tuesday, September 2, 1997:
         ==> (1997 9:00 AM EDT)September 2,3,5,15,17,19,29;October
             (1997 9:00 AM EST)October 27,29,31;November 10,12,14,24,26,28;
                               December 8,10,12,22
        (rfc2445, p. 119)
    It seems to me we could shift this into predicate calculus without
    much trouble:
    	 (aggregate weekly
    	    (hrFn 9 (daFn 2 
    			(monFn 9 (yrFn 1997 (common-era est))))))
    	 (daFn 24 (monFn 12 (yrFn 1997 (common-era est))))))
       (byday (list mo we fr)))
    or something like that.  Of course, we can provide axioms that relate
    all these symbols to an underlying world of time intervals.  I'll try
    to work something up in my copious spare time.
    Pat's general comment:
       .... As a 'standard' ontology, this sometimes 
       seems to me to fall between two stools. On the one hand it goes to 
       considerable lengths to support a variety of rather arcane and 
       academic alternatives, eg the two-treatments of infinity and the 
       nonlinear time options; but considered as a general theory it often 
       cuts corners and seems if anything too simple in places. On the other 
       hand, considered as a pragmatically useful ontology it doesn't pay 
       enough attention to existing standards and is probably way too 
       complicated for most purposes, particularly where it gets into axioms 
       with three or four nested quantifiers. I suspect that most users 
       would be happier with a quick-and-dirty version which just took a 
       position on infinity and linearity and density, one way or the other, 
       was aligned with things like ISO and XSD, and allowed people to get 
       simple calendering up and running quickly; and had in the background, 
       as it were, a more 'advanced' version which allowed one to handle 
       leap seconds and make all kinds of subtle distinctions without 
       getting confused. But then the latter had better REALLY be 
       general-purpose, so that it wouldn't break when considering BC dates, 
       or tree-rings, or relativistic corrections for GPS transmissions, or 
    I agree, although I don't think we have to deal with tree rings,
    relativity, or alternative calendars.  (The ontology should not
    prevent others from developing alternative calendars, however.)
    More specific Hayes comments:
       >4.  There is a treatment of temporal aggregates.  Comments solicited.
       On the other hand, this seems too complicated. Maybe Im not seeing 
       the reasons for the complexity, but using set theory seems like 
       overkill right at the start. BTW, the 'clocks and calendars' section 
       4 of my old time-survey memo has a treatment of some of these issues.
    Where might that old memo be?
       BTW, a general point: some of the complexity of parts of this can be 
       eliminated by using CL rather than a conventional FO syntax.
    Or by using a typed lambda-calculus.
       I am not happy with the account here of the relationship between 
       durations and calendars. On the one hand, it repeats a common mistake 
       in treating months as duration measures (Its being a 'standard' 
       doesn't make it right, and repeating an error doesn't make it 
       better.) and in not properly handling leap seconds and other 
       awkward-but-real stuff; on the other hand, it seems overly 
    I agree: MONTHS ARE NOT DURATIONS!  RFC 2445 allows other units as
    durations, but not months.  
       >1.  Temporal arithmetic.
       That ought to just be arithmetic, if durations were done properly.
    Jerry actually said "duration arithmetic."  One thing I miss in
    DAML-Time as it stands is dimensioned quantities, like a term denoting
    "3 minutes."  
       >The basic 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.
       Bad play, IMO. Confuses temporal with other issues, and repeats an old error
    I don't know if it's a bad play, but we certainly are in a muddle
    about what branching time _means_.  As I've said before, this comes
    down to what an instant is.  If an instant is essentially a date, then
    there's no conceivable reason to allow branching time.  One might have
    to maintain multiple data structures to keep track of various possible
    relationships among instants, but, as Pat and I have said before,
    the underlying timeline would still be totally ordered, because dates
    are totally ordered.  If instants differ from dates, what are they?  I
    maintain that they have to be situations, but I sense that others
    If you want to deny the existence of instants, then rephrase the
    paragraph above in terms of intervals and ordered pairs of dates.
    Here's another way to put the point: If (holds e t1) and (not (holds e
    t2)), and t1 and t2 have the same date (or the same date interval),
    then t1 and t2 must each denote a _something_ that associates dates
    with eventualities.  The burden is on anyone who denies that these
    somethings are not in essence situations.  
       >In the basic ontology we have tried to remain neutral with respect to
       >controversial issues, while producing a consistent and useable
       >axiomatization.  In specific applications one may want to have
       >stronger properties and thus take a stand on some of these issues.  In
       >this section, we describe some options, with the axioms that would
       >implement them.  These axioms and any subsequent theorems depending on
       >them are prefaced with a 0-argument proposition that says the option
       >is being exercised.
       Neat trick.
    Yes, but the names should be clearer.  Instead of total-order, use
    totally-ordered-time, and so forth.
    Also, to repeat and amplify previous remarks I've made:
    I don't see any reason to entertain the idea that time intervals might
    not be convex.  
    "Extensional collapse" is too alarmingly named.  Plus, the name
    connotes the wrong thing.  "Collapse" fails if time branches into the
    past as well as the future.  Then two distinct intervals could have
    the same endpoints.  What does this have to do with the "extension" of
       >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.
       Well, that is ambiguous, as Im sure you know. Ie does it mean holding 
       throughout, continuously, or only somewhere inside?
       ><axiom id=3D"2.5-2">
       >         during(e,T) --> interval(T)
       >If an eventuality obtains during an interval, it obtains at every
       >instant inside the interval.
       Ah, OK. So then if I take a trip lasting five days, am I travelling 
       while Im sleeping? (Or if it takes me a couple of years to write a 
       book, am I writing while Im having a shower? Etc.)
       You maybe ought to at least *say* something about this issue.
    There ought to be at least two sorts of eventualities: those that hold
    at an interval if and only if they hold at every instant in the
    interval, and the other kind.  
       >Often the eventualities in the event ontology are best thought of as
       What other kinds of eventualities are there? (Why does one need this 
       2-stage approach? Seems needlessly complicated.)  Whatever they are, 
       by the way, they can be subsumed under the proposition "so-and-so 
       exists" for temporal purposes. That is, temporal entities can be 
       considered to be exemplifications of existential propositions.
    I don't understand.
       >The 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.
       Right. Good move.
       Incidentally, this seems to me to be a useful heuristic: the temporal 
       theory ought to be preserved under all variations on these other 
       theories, eg whether you include times as arguments or relativize 
       truth to them or use them as modal possible-world indices, it ought 
       to come out the same.
    I agree.
       >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.
       Hmmm. Seems to me that we need to distinguish units of duration on 
       the one hand, and calendering devices on the other. What 'three 
       months' means is something like 'starting now, go on until the same 
       calendar date three months in the future'. But that is NOT an 
       interval of time: its a class of intervals with *varying* durations.
    I don't understand the motivation for wanting months as durations.
    The only one I can come up with is that in ordinary speech we often
    say things like "the baby's due in three months."  But ordinary speech
    is an unreliable source of ontology problems, much less solutions to
    them.  (My old polemic on "Natural Stupidity" makes this point.)  Even
    in the real world, when people (or lawyers or insurance companies)
    want to be precise, they say "90 days," not "three months."
       >This treatment of concatenation will work for scalar phenomena in
       >general.  This treatment of Hath will work for measurable quantities
       >in general.
       True, but it is way overly complicated for most of them. Most scalar 
       measuring schemes have been designed to be multiplicative, so that 
       you don't need to get into which particular collection of inches you 
       are concatenating, you can just say one foot =3D 12 inches, and then 
       multiply. Months break this because, basically, months are determined 
       by the moon and all the other units are determined by the sun, and 
       the sun and the moon have got pretty much nothing to do with one 
    Historically months were lunar, but now they're just arbitrary.
       I really think that the only effective way to handle months is in 
       terms of a repeating pattern of units (the 30/31/29) pattern for the 
       months in a year) and being explicit about this. The same machinery 
       also enables you to handle leap years, leap seconds and calendar 
    Except there's no pattern to leap seconds, as far as I know.
       >We leave leap seconds to specialized ontologies.
       Not good enough: a workable uniform treatment of time NEEDS to 
       consider leap seconds, if ignored they do things like breaking GPS 
       All you need to say is that some calendar years are not a year long, 
       but a year plus a second long. And all you need in order to say that 
       is to maintain a clear conceptual distinction between durations 
       (which really are on a scale) and calendaric entities (which are 
       really not). A year-duration is a different thing from a calendar 
    I agree.  I don't think the current DAML-Time notion of calendar day,
    week, etc. is quite correct.  The relevant symbols are 'da', 'daFn',
    and the like.  We have axioms such as
                   ;; Axiom "4.3-2"
                   (iff (wk y n x)
                        (= (wkFn n x) y))
    'x' is any proper interval, but if we want to capture the idea of a
    calendar week, 'x' has to be a proper calendaric entity itself (a
    month or year).  I _think_ that in most places the ontology does
    indeed force the third argument of 'wk' and second argument of 'wkFn'
    to be appropriate intervals, but the term (wkFn n x) denotes something
    even when 'x' is not calendaric, and that something makes (wk
    something n x) true.  Bug opportunities abound.
    Of course, on top of that we have to deal with the fact that RFC 2445
    and other standards say the first week of a year is the first week a
    majority of whose days fall in that year.  
    I tend to agree with Pat's comments.  I also don't see why granularity
    is important at this stage.
    One futher stylistic comment, nothing to do with Pat's remarks:
    Jerry says at one point
        The days of the week have special names in English.  
    and similarly for months.
    Every time I read this sentence I cringe a bit.  The names aren't
    special, _every_ language has names for days and months, and
    predicates aren't names.
    I think it should say something like: 
       We introduce predicates whose names are the same as the standard
       English names for the days of the week.
                                                 -- Drew

    This archive was generated by hypermail 2.1.4 : 04/02/03 EST