# Re: Planning under Description Logic ?--an obstacle towards WSAC

From: Drew McDermott <drew.mcdermott@yale.edu>
Date: Sun, 12 Dec 2004 17:14:19 +0000 (GMT)

Message-ID: <E1CdXJ6-0002or-TW@frink.w3.org>
```

> [Manshan Lin]

> If we don't consider the characteristic (2), the generated plan would
> probably be: action-1, action-2, action-3, while the proper plan=20
> should be action-1, action-3, action-2. How to take these inference
> rules into consideration when planning is really a problem.

The only real problem is getting the semantics of actions right.  Most
planning research makes some version of the Strips assumption, that it
is possible to enumerate all the effects of an action.  Actions are
simulated by changing the representation of a situation, erasing some
formulas and adding others.  Inference rules (or, more precisely,
axioms) complicate the picture because they make it harder to
enumerate the effects, and more difficult to spell out exactly what
gets erased or added.  The usual solution is to classify predicates as
"primitive" or "derived."  Only the former can be specified as effects
of actions.  Now you can do the usual Strips thing with the primitive
formulas, and recalculate the derived ones for every situation.  Your
example fits this pattern, if we adapt it for the DL context, and
classify classes as primitive or derived.  Classes A and B are
primitive, and class C is derived.

Anyway, you don't treat axioms or inference rules as "operators";
they're part of the inferential ("synchronic") machinery, not the
planning ("diachronic") machinery.

A planning algorithm will have to be sensitive to the following point:
If the goal of making 'd' not belong to class C arises, then one way
to proceed is to achieve the two subgoals 'd:classA' and 'd:classB'.

--

-- Drew McDermott
Yale University
Computer Science Department

An animal-rights activist is someone who believes every fur coat is
either friend or faux.
```
Received on Sunday, 12 December 2004 17:14:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:54:14 UTC