Notes on I-Plan

Author: Jeff Dalton

Updated: Tue Feb 22 03:37:36 2005 by Jeff Dalton


1. Using an I-Plan panel

To use I-Plan, use main program class ix.iplan.IPlan.

Although I-Plan looks much like an I-X Process Panel (I-P2),
the functionality is very different.  For instance, the only
significant action you can apply to an activity is to expand it
(if there's a suitable refinement).

In I-Plan, you can set up a planning problem by adding
activities, changing the world-state, and (if you want)
expanding activities by using refinements in the domain
or by using the "details" editor.

The "I-Plan" entry in the "Tools" menu brings up a window
that can be used to run the automatic planner, to replan
(i.e., find an alternative plan), or to run the
plan-checking execution-simulator.

You can use the "Send plan" entry in the "File" menu to send
the plan to another agent.  You can also use that menu entry
in another agent to send a plan to an I-Plan.

By default, I-Plan supports multiple "options", where each
option is a separate plan.  Options are created by replanning
and in other ways.

For more about options, see doc/notes/options.txt.


2. Annotations that affect planning

2.1  Restrictions on condition-satisfaction

There is a simple mechanism that controls whether the planner tries
to "achieve" a condition (by potentially adding an activity).
Without this, it will treat all conditions as achievable.
The mechanism will be replaced once we implement proper
condition types.

There is a domain annotation, achievable-world-state-conditions,
with possible values:

   :all
   :none
   (word ...)

where each word is one that can appear first in a pattern.
This specifies which world-state conditions the planner
will attempt to satisfy by achieving.  The default is :all.

There is also a refinement annotation, use-for-world-state-effects,
with similar values.  It specifies which effects in that refinement
will be considered when trying to achieve conditions.  Again
the default is :all.

(There could be an achievable-world-state-conditions on
refinements as well, but that has not yet been implemented.)

Example:

   (refinement setup (setup)
     (constraints
       ;; The apple starts as ready: it could be eaten as-is.
       (world-state effect (status apple) = ready))
     (annotations
       ;; Keep this refinement from being used to achieve a condition.
       (use-for-world-state-effects = :none)))


2.2  Input and output annotations

Refinements that represent web services, or similar entities,
can specify inputs and outputs as annotations.  (These are
really input and output constraints and will be supported
as constraints in some later versions.)

For example, a refinement that represented a service that
produced book price information when given a description
of a book might be defined like this:

(refinement book-price-service (book-price-service ?book-info to ?book-price)
  (variables ?book-info ?book-price)
  (constraints
    (world-state condition (type ?book-info) = book)
    (world-state effect (type ?book-price) = price))
  (annotations
    (input-objects = ((?book-info book)))
    (output-objects = ((?book-price price)))))

When the planner uses such a refinement to expand an activity,
it will generate a symbol to represent each output object.
The symbol-generation happens at plan-time.  (The objects
that correspond to those symbols would, of course, not be
produced until the plan was executed using a suitable
execution engine.)  In effect, the symbols are used
to represent which outputs are given to which inputs in
the plan.  This makes it possible to recover data-flow.

Note that, for now, this happens only in the automatic planner
Input and output annotations are currently ignored when you are
working manually in I-Plan or I-P2.


3. Advice

I-Plan and I-P2 understand a very simple form of "advice" constraint.

Here's an example in the ".lsp" (LTF) syntax:

   (refinement test2 (test2) ; 2 solutions
     (nodes
       (1 (travel edinburgh london)))
     (constraints
       (advice expansion-refinement
               travel (travel-by-train travel-by-air))))

That says: whenever you're expanding an activity that
has pattern-verb "travel", you must use one of
the listed refinements.  And for now at least, it
applies to every expansion the planner considers
after the constraint has been added.

The example above is potentially misleading, because it can
look like the constraint is just to affect the node introduced
by that refinement; but it's in fact more general.

For example, for suppose that "rescue" activities had,
somewhere in their expansion, activities such as "locate"
and "recover".  Here's an example refinement for testing
in such a domain:

(refinement test1 (test1)
  (nodes
    (1 (rescue UNESCO-Visitors)))
  (constraints
     (advice expansion-refinement locate (locate-air-search))
     (advice expansion-refinement recover
        (recover-unassisted recover-by-civilian-means))))

It is also possible to specify the arity of the verb.
For example, if you wanted the advice to apply to patterns
of the form (travel ?? ??), but not to cases where
"travel" was followed by a different number of arguments,
you could do that as follows:

   (constraints
     (advice expansion-refinement
             travel/2 (travel-by-train travel-by-air)))

This is often useful avoid constraining more activities than
are intended.

Of course, this is just a very simple form of advice.
Even when the aim is just to restrict the choice of
refinement, a pattern, rather than just a verb, could
be used to say which nodes it applied to, and some
kind of "path" spec might also be useful (e.g. to
constrain a "move" activity only when it's a subnode
of a "recover" activity).

Such things are not yet supported, but a more expressive
advice language may be provided in later versions.
