Today: Ray Reiter and John McCarthy join the debate about the ontology of time.

Ray Reiter:

During all the years that the debate has raged about time points vs intervals, we devotees of the sitcalc have never seen it as an issue. Here's why I think this is so.

In the sitcalc, a fluent ( LightOn ) has a truth value only with respect to a situation (= sequence of action occurrences). So, we might have

LightOn(do(switchOn, do(switchOff, S0)))

and

¬ LightOn(do(switchOff, do(switchOn, S0)))

In the sitcalc with explicit time, the first might become

LightOn(do(switchOn(3.14), do(switchOff(1.41), S0)))

meaning that as a result of the action history consisting of first switching off the light at time 1.41, then switching on the light at time 3.14, the light will be on. Notice that there is no way of expressing the claim that the light is, or is not on at time 3.14 (or 3.5), independently of the situation leading up to this time. On the other hand, time based formalisms do allow one to write  LightOn(3.14) , without expicitly referencing, in their notation, the history leading up to the time 3.14 at which the fluent's truth value is to be determined. This seems to be the source of all the problems about open vs closed vs semi-open intervals and predicate truth values over these, and also why these seem to be non-issues for the sitcalc.

Now, one could rightly object to the above account because it provides only for fluent truth values at discrete time points, namely at the action occurrence times. So we are tempted to understand

LightOn(do(switchOn(3.14), do(switchOff(1.41), S0)))

to mean that the light is on at time 3.14, but it tells us nothing about time 3.5 say. This is particularly bad for (functional) fluents that vary continuously with time, for example, the location of a falling object. To handle this, introduce a time argument for fluents, in addition to their situation argument. For the light, one can write:

LightOnT(t, s) <-> LightOn(s) ^ t > start(s).

Here,  start  is defined by  start(do(a, s)) = time(a) , where  time(a)  is the time at which the action  a  occurs in the history  do(a, s) .

An instance of this would be

LightOnT(t, do(switchOn(3.14), do(switchOff(1.41), S0))) <-> t > 3.14

Here we have committed to the light being on at exactly the time of the switchOn action, and forever thereafter, relative to the history  do(switchOn(3.14), do(switchOff(1.41), S0)) . In other words, provided  switchOff(1.41)  and  switchOn(3.14)  are the only actions to have occurred, then the light will come on at time 3.14, and remain on forever. Notice especially that we would have both

LightOnT(3.14, do(switchOn(3.14), do(switchOff(1.41), S0)))

and

¬ LightOnT(3.14, do(switchOff(1.41), S0))

without contradiction. This seems to be precisely the point at which purely time-based formalisms run into difficulties, and the sitcalc version of this problem illustrates the role that explicit situation arguments play in resolving these difficulties.

Now, we can axiomatize falling objects:

positionT(t, s) = position(s)+velocity(s)*(t-start(s))+0.5*g*(t-start(s))2

John McCarthy:

When my car accelerates, there is a time point at which it passes 65 miles per hour. It is awkward to describe this point in a language not providing for time points.