\documentclass[11pt]{article}
\usepackage{jair,float,alltt,theapa}

\newcommand{\prob}{{\cal P}}
\newcommand{\asgnset}{{\cal A}}
\newcommand{\asgn}{\mbox{\it asgns}}
\newcommand{\prune}{\mbox{\it Pruned\/}}
\newcommand{\curdom}{\mbox{\it CurDom\/}}
\newcommand{\dom}{\mbox{\it Dom\/}}
\newcommand{\Fvars}{\mbox{\it FutureVars\/}}
\newcommand{\aval}{\mbox{\it asgnVal\/}}
\newcommand{\lvar}{\mbox{\it varAtLevel\/}}
\newcommand{\cflevel}{\mbox{\it CfAtLevel\/}}
\newcommand{\curasgn}{\mbox{\it CurAsgns\/}}
\newcommand{\levelasgn}{\mbox{\it AsgnsToLevel\/}}

\newcommand{\level}{\mbox{\it level\/}}
\newcommand{\prunedvals}{\mbox{\it Prunedvals\/}}
\newcommand{\consisvals}{\mbox{\it Consistentvals\/}}
\newcommand{\nogoodvars}{\mbox{\it VarsNoGoodAtLevel\/}}
\newcommand{\maxnogoodvals}{\mbox{\it MaxNoGoodvals\/}}
\newcommand{\maxnogoodvars}{\mbox{\it MaxNoGoodVars\/}}
\newcommand{\compat}{\mbox{\it compat\/}}
\newcommand{\varsof}{\mbox{\it VarsOf\/}}
\newcommand{\node}{\mbox{\it node\/}}
\newcommand{\nil}{\mbox{\tt NIL}}

\newcommand{\consof}{\mbox{\it ConsOf\/}}
\newcommand{\curarity}{\mbox{\it CurArity\/}}
\newcommand{\deepestAsgn}{\mbox{\it DeepestAsgn\/}}

\newcommand{\consistent}{\mbox{\it consistent\/}}
\newcommand{\ttgets}[2]{{\progfont{#1} \gets \progfont{#2}}}
\newcommand{\var}{{\it Var}}
\newcommand{\val}{{\it val}}
\newcommand{\maxnogood}{{\it MaxNoGood}}
\newcommand{\cklevel}{{\it cklevel}}
\newcommand{\nogood}{{\it NoGood}}
\newcommand{\maxconsis}{{\it MaxConsis}}
\newcommand{\progfont}[1]{\mbox{\tt #1}}

\newcommand{\xwhile}{{\rm\bf\em while}}
\newcommand{\xif}{{\rm\bf\em if}}
\newcommand{\xreturn}{{\rm\bf\em return}}
\newcommand{\xelseif}{{\rm\bf\em elseif}}
\newcommand{\xelse}{{\rm\bf\em else}}
\newcommand{\xfor}{{\rm\bf\em for}}
\newcommand{\xforeach}{{\rm\bf\em foreach}}
\newcommand{\xto}{{\rm\bf\em to}}
\newcommand{\true}{\mbox{\sc true}}
\newcommand{\false}{\mbox{\sc false}}

\newcommand{\tsearch}{{\bf Tsearch}}
\newcommand{\BT}{{\bf BT}}
\newcommand{\assign}{{\small\tt assign}}
\newcommand{\unassign}{{\small\tt unassignlevels}}
\newcommand{\pruneval}{{\small\tt Pruneval}}
\newcommand{\pickvarval}{{\small\tt PickVarVal}}
\newcommand{\set}[1]{\{#1\}}
\newcommand{\implies}{\Rightarrow}
\newcommand{\dimplies}{\Leftrightarrow}

\newcommand{\tlplan}{\textsc{Tlplan}}
\newcommand{\pddl}{\textsc{pddl2.1}}
\newcommand{\oldpddl}{\textsc{pddl}}
\newcommand{\strips}{\textsc{strip}}
\newcommand{\adl}{\textsc{adl}}

\newcommand{\atend}{\texttt{(at end)}}
\newcommand{\atstart}{\texttt{(at start)}}
\newcommand{\overall}{\texttt{(over all)}}
\newcommand{\condition}{\texttt{:condition}}
\newcommand{\ldtruck}{\texttt{load-truck}}
\newcommand{\loading}{\texttt{loading}}
\newcommand{\move}{\texttt{move-truck}}

\newcommand{\fly}{\texttt{fly}}

\newenvironment{program}{\fontsize{9pt}{9.5pt}\begin{alltt}}%
  {\end{alltt}}

% \def\resetlno{\setcounter{lineno}{1}}
% \def\bump{\hspace{3ex}}
% \def\smallbump{\hspace{1.5ex}}
%\floatstyle{ruled}
%\restylefloat{figure}

\title{The Power of Modeling---a Response to {\sc pddl2.1}}
\author{\name Fahiem Bacchus
  \email fbacchus@cs.toronto.edu\\
  \addr Department. of Computer Science\\
  6 King's College Road\\
  University Of Toronto\\
  Toronto, Ontario\\
  Canada, M5S 3H5.
}

\firstpageno{125}
\jairheading{20}{2003}{125--132}{09/03}{12/03}
\ShortHeadings{A Response to \pddl}{Bacchus}


\begin{document}
\commentary
\maketitle
\begin{abstract}
  In this commentary I argue that although \pddl{} is a very useful
  standard for the planning competition, its design does not properly
  consider the issue of domain modeling. Hence, I would not advocate
  its use in specifying planning domains outside of the context of the
  planning competition. Rather, the field needs to explore different
  approaches and grapple more directly with the problem of effectively
  modeling and utilizing \emph{all} of the diverse pieces of knowledge
  we typically have about planning domains.
\end{abstract}

\section{Introduction}
Fox and Long did a terrific job of organizing the 2002 Planning
Competition. A non-trivial component of that work was specifying an
extension of \textsc{pddl} so that a much more interesting range of
problems could be addressed in the competition. Although the extension
represents a very useful standard for the competition, its design
ignores both the power and reality of domain modeling. I will argue
that some of the new features of \pddl{} are unnecessary: similar
effects can just as easily be captured by more robust modeling of the
planning domain.

My own \tlplan{} planning system competed in the 2002 planning
competition.  Despite the fact that \tlplan{}'s specification language
had no direct support for some features of \pddl{}, we were still able
to encode all of the competition domains. \tlplan{} utilizes a
language that is designed to be suitable for robustly modeling
planning domains.\footnote{\tlplan{} also includes constructs for
  expressing domain specific control information, but I am not
  referring here to that component of the language.} We found that
many of the new features of \pddl{} used in the competition were in
fact easy to capture simply by more robust modeling of the planning
domain.

That \pddl{} takes the approach of adding new features to the
language, rather than requiring that the domain be more robustly
modeled, is perhaps not surprising given the dichotomy that still
persists in the AI planning field. That dichotomy is between work on
``domain-independent'' planning and ``control-intensive'' planning.
Just as work on control-intensive planning tends to ignore the
applicability and power of state-of-the-art search algorithms for
planning, work on domain-independent planning tends to ignore the
power to be gained, and the requirements imposed, by domain modeling.
Most planning researchers freely acknowledge the importance of both
components, however, one rarely finds work at the interface of these
two issues, nor are there many researchers who work on both of these
issues.\footnote{I am just as guilty of this as most of my
  colleagues.}

In the rest of this commentary I will elaborate on my argument by
presenting examples of features and approaches appearing in \pddl{}
that demonstrate its insensitivity to domain modeling.

\section{Coordinating Concurrent Actions}
In Section~5 of the \pddl{} document various constructs are presented
to support durative actions. These are actions whose effects can
either be immediate (like ordinary non-durative actions) or can occur
at the end of some fixed duration. The duration can be either a
constant or specified by some functional term. The obvious extension,
used, e.g., by Bacchus \& Ady \citeyear{Bacchus:IJCAI01}, where an
action could have a range of effects each at a different future
timepoint, was not included in \pddl{}.\footnote{Instead one must
  ascend to the much more complex specification of continuous effects
  (presented in Section~5.3 of the \pddl{} document) to achieve this
  degree of flexibility.} Without this extension the \atstart{} and
\atend{} specifiers are reasonable ways of specifying delayed effects.

\begin{figure}[t]
  \centering\vspace*{6pt}
  \begin{program}
(:durative-action load-truck
   :parameters (?t - truck)
               (?l - location)
               (?o - cargo)
               (?c - crane)
   :duration (= ?duration 5)
   :precondition (and (at ?t ?l)
                      (at ?o ?l)
                      (empty ?c))
   :effect       (and (loading ?t)
                      (at end (not loading ?t))
                      ...
)

(:action move-truck
   :parameters (?t - truck)
               ...
   :precondition (and (not (loading ?t))
                  ...)
)
\end{program}
  \caption{Converting \overall{} conditions}
  \label{fig:overall}
\end{figure}


With non-instantaneous actions concurrency control becomes an issue.
To achieve this kind of control \pddl{} provides the \condition{}
constructs \atstart{}, \atend{}, and \overall{}. \tlplan{} does not
provide the \atend{} and \overall{} constructs (\atstart{} is simply
an ordinary precondition). Yet we were still able to model all of the
planning domains without them. I would argue that in general these
constructs are not necessary.

\subsection{\overall:} Consider the \ldtruck{} action given in Figure~6
of the \pddl{} article. It contains the condition \texttt{(over all
  (at ?t ?l))}: i.e., the truck must stay at the same location through
out the load. Why must it not be moved? Because we are not allowed to
move a vehicle while it is being loaded. Similarly, we should not
drive a car while it is being refueled, we should not turn off the
oven while it is being used to bake a cake, we should not attempt to
tie our shoelaces while running, etc. Our knowledge abounds with such
common sense conditions. In natural language we use progressive tenses
to refer to ongoing activities. Similarly, the most natural way to
model an \overall{} condition is simply to have the action assert that
an activity is ongoing, and use the negation of that activity as a
precondition for actions that could interfere. The resulting
transformation of the \ldtruck{} action is given in
Figure~\ref{fig:overall}.

In Figure~\ref{fig:overall} the \ldtruck{} action advertises that it
has initiated an on-going loading of the truck by adding a \loading{}
predicate to the state. At the end of the action this predicate is
deleted. Actions like \move{} that could interfere with \loading{} are
blocked by adding \texttt{(not loading)} to their preconditions. Using
this technique we were able to replace all \overall{} conditions used
in the competition domains. Interestingly the replacements made the
domain more sensible and more readable.

Consider in brief the advantages of modeling \overall{} effects by
adding ``progressive predicates'' to the state.
\begin{enumerate}
\item The method can be realized without extending the standard
  \strips/\adl{} semantics.
\item An action's preconditions still encapsulates all of its
  interactions with the other actions. In the presence of \overall{}
  conditions, one would have to examine every other action to see if
  any of its \overall{} conditions are interfered with by one of the
  action's effects. Put another way, the action's activation condition
  continues to be Markovian, i.e., dependent only on the current
  state. The current state continues to carry all of the information
  needed to determine if an action can be applied; with \overall{}
  conditions, one also needs to examine all currently active
  actions---the state no longer encapsulates all of the necessary
  information.
\item Finally, it seems to me that the resulting domain models are
  more natural and easier to understand.
\end{enumerate}

\subsubsection{Modularity}
One concern with the above approach to avoiding \overall{} conditions,
is that it appears to make adding new actions to the domain
non-modular.\footnote{Thanks to David Smith and Martha Pollock for
  pointing out that I needed to address the issue of modularity.}
Non-modularity potentially arises both from adding new actions that
could be interfered with by previous actions, and from adding new
actions that could interfere with previous actions.

The first case arises when we add new actions like \texttt{refuel},
\texttt{repair}, \texttt{change-tire}, etc., all of which can be
interfered with by the existing action \texttt{move-truck}. Our
solution of adding non-interference preconditions would seem to
require modifying the description of \texttt{move-truck} to add
\texttt{(not (refueling))}, \texttt{(not (repairing))}, \texttt{(not
  (changing-tire))}, etc., preconditions---a new precondition for
every new action added.

The second case arises when we add a new action like
\texttt{tow-truck} that also changes the location of the truck. We
would then have to ensure that we add to its preconditions all
progressives required to block it from interfering with previously
defined actions. This second case is perhaps not as problematic, since
it does not require modifying any of the old actions. However, the
first case is an issue since one might not want to modify the
definition of previous actions that had already been debugged.

When using \overall{} conditions we need not make any changes to old
actions nor worry about the effects of the new actions on the old.
However, I would argue that this modularity exists only at the
syntactic level---it is syntactically easy to modify the domain
description to accommodate new actions. There is no corresponding
modularity at the semantic level: the interferences between the new
action and the old still exists. In most cases we cannot simply ignore
these interactions, leaving it up to the planner and the \overall{}
conditions to resolve. As we have found when developing domains, in
many cases when a new action is added to the domain a bug in the
domain specification appears. For example, plans one would expect to
find are no longer found by the planner. Often the bug lies in the new
action, but just as often a bug is found in the specification of the
old actions. If the domain no longer operates as expected, one is
still left with the task of unraveling the interactions of the
specification. In general, specifying a rich domain requires
understanding the possible interactions in the domain, and in that
task the \overall{} conditions do not help.

It could be argued that it is the job of the planner to unravel the
interactions in the domain. But this argument, I believe, trivializes
the job of specifying a planning domain. The planner's job is to compute
the interactions between actions in a sequence (or more complex
composition) of actions. Getting the domain correctly specified is a
difficult task, and requires at least understanding how actions
interact \emph{statically}, even if one can leave the dynamic
interactions up to the planner. 

Fortunately, in most systems the interactions between actions are
relatively local: there is typically a relatively structured way in
which actions can interfere with each other. This is what makes
specifying planning domains feasible.

One can take advantage of this structure to build robust domain models
that provide the advantages of semantic as well as syntactic
modularity. A critical component of building good domain models is the
ability to use definitions (axioms), a feature that is not provided by
\pddl{}. In \tlplan{}, e.g., one can define a new predicate symbol
using a first-order formula over previous defined symbols. By defining
the right high level constructs one can typically provide a more
explicit representation of the structure of interactions in the
domain.  The advantage of doing this is that one also obtains a
declarative representation of this structure, thus achieving a more
natural and easier to understand domain specification.

In the example above, one could define a new predicate
\texttt{(must-be-stationary ?t)} to be the disjunction
\[\texttt{(or (loading ?t) (changing-tire ?t) (repairing ?t) (refueling ?t))}.\]
Now the \texttt{(move-truck ?t ?l1 ?l2)} action need only have a
single precondition \texttt{(not (must-be-stationary ?t))}, and any
new action that requires that the truck be stationary can be
accommodated by simply adding a new disjunct to the definition of
\texttt{must}-\texttt{be}-\texttt{stationary}.  This approach has the
advantage of explicitly introducing a new concept
\texttt{must-be-stationary}, which helps in understanding and
structuring the domain. In contrast, with \overall{} conditions one
only has the concept of ``not changing \texttt{at}''. In this simple
example the difference appears to be trivial, but the key idea is that
once we have a new concept like \texttt{must-be-stationary} in the
domain, we can use it to build up more complicated concepts.

Using explicit progressive preconditions also allows for the
coordination of far more complex shared uses of a resource.  For
example, we can specify that both refueling and driving require
exclusive use of the truck, and that changing a tire can be done
concurrently with repairing the truck but not concurrently with
loading. These conditions can be accommodated by having each action
explicitly mention the excluded activities in its precondition, or
through axioms grouping and structuring these activities into more
complex conditions and then using those conditions in the action
preconditions. In either case the result is a more explicit
description of the domain that is easier to understand, debug and
modify.

\begin{figure}[t]
  \centering\vspace*{6pt}
  \begin{program}
(:durative-action load-truck
   :parameters (?t - truck)
               (?l - location)
               (?o - cargo)
               (?c - crane)
   :duration (= ?duration 5)
   :precondition (and (at ?t ?l)
                      (at ?o ?l)
                      (empty ?c))
   :effect       (and (loading ?t)
                      (at end (not loading ?t))
                      (holding ?c ?o)
                      (not (at ?o ?l))
                      (at end (when (holding ?c ?o) (in ?o ?t)))
                      (at end (when (holding ?c ?o) (not (holding ?c ?o))))
                      (at end (when (not (holding ?c ?o)) (load-failed))))
)

\end{program}
  \caption{Converting \atend{} conditions}
  \label{fig:atend}
\end{figure}

\subsection{\atend{}:} \atend{} is a very strange condition. In fact,
it did not appear in any of the competition domains. I would argue
that it also is not needed; not because it is easily captured by other
constructs, but rather because it is unnatural and would never appear
in a reasonable domain model. \atend{} is intended to support the
flexibility whereby an action can ``release'' a condition so that
other actions might delete that condition, as long as the condition is
subsequently restored on time. Like the \overall{} condition it has
the effect of breaking the Markovian nature of normal action
specifications. A more natural way to model such a situation, I would
claim, is simply to use conditional \atend{} effects: if the required
condition holds at the end, the desired effect will be created,
otherwise some bad effect will occur. The so modified \ldtruck{}
action is given in Figure~\ref{fig:atend}.

In this modification, instead of a \texttt{(at end (holding ?c ?o))}
condition, we have simply changed the effects of the action. If
\texttt{(holding ?c ?o)} holds at the end of the action, the action
has its normal effects. Otherwise, it adds to the state a marker
indicating that a load has failed. If we add \texttt{(not
  (load-failed))} to the goal, then the planner would search for ways
of falsifying the antecedent of the effect (assuming that
\texttt{(load-failed)} cannot be undone), i.e., the planner would
search for ways of ensuring that \texttt{(holding ?c ?o)} is true at
the end of the action. Note that this is exactly what the planner
would do to ensure that an ordinary precondition holds. That is, again
we can reduce the construct down to standard features. 

\section{Unspecified Durations}
Another feature of \pddl{} is the ability to specify ranges of
durations for actions. The intent here is that the actual duration of
the action might be affected by other actions. The \texttt{burnMatch}
and \texttt{heat-water} actions (Figures~10 and 12 of the \pddl{}
document) are examples where a range is utilized as the duration.

I find flexible durations to be strange, they again make the action
dependent on future actions. Furthermore, I am not convinced that they
are necessary. Rather I think that a more natural way to model such
situations would be to introduce two actions, one to start the action
(light the match, or start heating the liquid), and one to end the
action (blow out the match, or take the liquid off the heat).
Figures~\ref{fig:match} and \ref{fig:heat} present these alternate
models.

\begin{figure}[t]
  \centering\vspace*{6pt}
  \begin{program}
(:durative-action burnMatch
   :parameters (?m - match ?l - location)
   :duration (= ?duration 5)
   :precondition (and (have ?m)
                      (at ?l))
   :effect       (and (when (no-other-light-source ?l) 
                            (and (not (dark ?l)) (light ?l)))
                      (not (have ?m))
                      (burning ?m)
                      (at end (when (burning ?m) (not (burning ?m))))
                      (at end (when (and (no-other-light-source ?l)
                                         (burning ?m))
                                    (and (not (light ?l))
                                         (dark ?l))))))
)

(:action blowOutMatch
   :parameters (?m - match ?l - location)
   :precondition (and (at ?l)
                      (burning ?m))
   :effect       (and (not (burning ?m))
                      (when (no-other-light-source ?l)
                            (and (not (light ?l))
                                 (dark ?l)))))
)
\end{program}
  \caption{Alternate model of \texttt{burn-match}}
  \label{fig:match}
\end{figure}

The \texttt{burnMatch} starts the match burning (toggling the lighting
status of the location if there was no other light at that location).
It also posts a ``default'' completion of the match burning at the
maximum duration. If the match is still burning at the end of this
maximum duration it is extinguished and the lighting status is toggled
(if the match was the only source of light). On the other hand, the
match can be extinguished earlier by a \texttt{blowOutMatch} action.

\begin{figure}[t]
  \centering\vspace*{6pt}
  \begin{program}
(:durative-action heat-water
   :parameters (?p - pan)
   :duration (= ?duration (/ (- 100 (temperature ?p)) (heat-rate)))
   :precondition (and (full ?p)
                      (onHeatSource ?p)
                      (byPan))
   :effect (and (heating ?p)
                (heating-start ?p (current-time))
                (at end (when (and (byPan) (heating ?p)) (not (heating ?p))))
                (at end (when (heating ?p)) (assign (temperature ?p) 100))
                (at end (when (and (not (byPan)) (heating ?p)) (burn-pot ?p)))))

(:action take-off-heat
   :parameters (?p - pan)   
               (?startt - time)
   :precondition (and (heating ?p)
                      (heating-start ?p ?startt)
                      (byPan))

   :effect (and (not (heating ?p))
                (when (not (burn-pot ?p))
                      (increase (temperature ?p)
                                (* (- (current-time) ?startt) (heat-rate))))))
\end{program}
  \caption{Alternate model of \texttt{heat-water}}
  \label{fig:heat}
\end{figure}

The \texttt{heat-water} action starts the water heating, and like
\texttt{burn-match} has a default maximum duration. If the pan is
still being heated at the end of that time it raises the temperature
of the pan to 100 degrees, and, if the agent is by the pan, it takes
the pan off the heat, otherwise pan continues to be heated causing it
to become burnt (this is in keeping with our previous discussion about
not wanting \atend{} preconditions). Note the pan's temperature never
rises above 100 (we are assuming that the water keeps on boiling). It
also marks the time that heating started (\texttt{(current-time)} is
the time that the action was executed).  \texttt{take-off-heat} is an
action that can take the pan off the heat at any time. It uses the
start time of the heating to calculate the temperature of the water
(if the pot is burnt, its temperature remains at 100, as set by
\texttt{heat-water}).

I am not suggesting that these alternate action specifications are the
``right'' models (e.g., the \texttt{heat-water} cannot account for
putting the pot back on the heat after taking it off). What I am
suggesting is that the case for variable durations has not been made.
Is it really necessary or even natural for domain modeling?

\section{Conclusions}
I could list a few other components of \pddl{} that seem to me to be
unnecessary, but I believe that the point has been made. \pddl{} is
essential for the planning competition, and I am certainly a strong
supporter of the usefulness of the competition for furthering planning
research. However, I would suggest that outside of the context of the
competition, the issue of which features should be included in a
planning domain specification language needs to be more grounded in
the application of these languages. Planning domains, even simplified
ones designed for research, can be modeled in many different ways, and
I believe that it is better to produce more robust models with simpler
languages than to develop languages with features that are not really
needed.

I do think that many of the ideas contained in \pddl{} are useful,
e.g., the way in which continuous change is treated. Nevertheless, I
would not encourage anyone to try to construct planning algorithms for
dealing with these features. Rather I would encourage the development
of planning algorithms inspired by the issues that arise from
interesting domains. That is, I think that the incorporation of new
features into planning languages needs to be motivated by compelling
examples.

%\bibliographystyle{theapa}
%\bibliography{planning}
\begin{thebibliography}{}

\bibitem[\protect\BCAY{Bacchus\ \BBA\ Ady}{Bacchus\ \BBA\
  Ady}{2001}]{Bacchus:IJCAI01}
Bacchus, F.\BBACOMMA\  \BBA\ Ady, M. \BBOP2001\BBCP.
\newblock \BBOQ Planning with resources and concurrency, a forward chaining
  approach\BBCQ\
\newblock In {\Bem Proceedings of the International Joint Conference on
  Artificial Intelligence (IJCAI)}, \BPGS\ 417--424.

\end{thebibliography}


\end{document}
