Re: OWL-S preconditions - practical issues

> [Donal Murtagh]
> 
> The problem with planners is that compatibility of preconditions and
> effects is based on (lexical) name matching. Although SHOP2 can evaluate
> simple expressions such as ((eval (< ?n1 5)) in the precondition of an
> operator, AFAIK, it is not possible to assert an effect which is a
> conditional expression, e.g. to state that "the effect of this
> process/operator is that (< ?n1 5) is true".

As far as I know, there are no general-purpose planners that can
manage effects like this.  They require effects to be fully
specified.  Another thing you can't do is have an existentially
quantified effect, such as "If you toss a water balloon into a crowded
room, someone in the room will get wet."

There have been motion-planning systems for robots that can accumulate
fairly weak constraints on the location of objects after the robot's
not-so-competent manipulations and find a plan that is guaranteed to
work in spite of the nondeterminism.  The goals the planner can handle
are of the form "Object X is somewhere in volume V of configuration
space."  (E.g., "Get widget X into bin B, in any orientation.")  For
each action A in its repertoire the planner computes a "preimage" of V
before A, that is, the largest subset V' of configuration space such
that if X is in V' and A is executed, then X will be in V.  It then
recurses, until it gets back to a piece of configuration space
included in the initial condition.

Good luck trying to generalize this idea.

                                             -- Drew

-- 
                                   -- Drew McDermott
                                      Yale Computer Science Department

Received on Saturday, 26 June 2004 09:42:01 UTC