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

> > hi all,
> > I've just read all the discussion about applying AI planning technique
> > to SWS.
> > I notice that most traditional planning algorithm are based on first
> > order logic, which is based on close-world assumption.
> 
> Er...really? First order....closed-world....BOOM! ;)

Sorry for my expression, what I actually refer to is the traditional
planning algorithm. :)

> 
> > The question is :
> > When using DL to describe world state, what adaptions should
> > traditional AI planning techniques make?
> 
> Let me point you our paper on Planning for Web Services:
>        http://www.mindswap.org/papers/SWS-ISWC04.pdf

Yes, I've read your paper. 
It is trying integrate OWL-DL reasoner(Pellet) with an AI
planner(SHOP2) to solvethe evaluation
of preconditions and applying effects. There are some questions:
(1) In section 2.2, it seems that HTN planner starts its planning from
initial state to the goal
state. Do you assume that the user provides all needed information at
the very beginning? What's
more, it seems that the plan generated by the HTN planner does not
support pallel execution, since
it only generates a sequence of actions. (Since I'm not familiar
withHTN planning, point it out
if I'm wrong. :) ).
(2) In section 3.1 the fouth paragraph, it mentions due to open-world
assumption, "as SWRL does
not allow negated atoms appear in rule bodies, we also restrict the
preconditions to contain only
non-negated SWRL atoms". In my opinion, negation is relative. Don't
you think that "not(?person
rdf:type Registered)" can be easily converted to "(?person rdf:type
complementOf(Registered))"?
(3) In section 3.2, it mentions how to evaluate universally quantified
expressions. The evaluation
however returns to the closed world assumption. To avoid ambiguity,
should it uses another symbol
to express "as far as I know, all ...". 
(4) In section 3.3 fouth paragraph, it mentions "we have the problem
of OK deriving the same assertion
from other facts even after we remove that assertion from the KB
...... This is exactly why planning
systems make the distinctions between primitive and derived predicates
and do not allow derived predicates
in effect". How can we make sure that the effects of an operation must
be primitive? Just like we
can't require others not to inherit a concept. In some KBs, they are
primitive, while in some KBs,
they also can be derived predicates.

> It describes our attempt to use OWL as the world state represenation
> language of the SHOP planner.
> 
> > For example,
> > TBOX: EffectA = intersectionOf(EffectB,EffectC)
> > ABOX: a individual EffectA
> 
> Er...So you're talking owl full here? With the same thing both a class
> and a individual?

Sorry for my expression again, :(. What I mean is that 'a' is an
individual of 'EffectA'.

> 
> > Then we can choose an operation that achieves EffectA or we can choose
> > two operations (one achieves EffectB and the other achieves EffectC).
> 
> I don't udnerstand.
> 
> > It's a little like adding some common rules
> > (in this case EffectB(x) and EffectC(x)->EffectA(x))
> > to traditional planning domain.
> 
> I presume you're talking about secondary effects? yeah, they're a
> problem :)

No, I mean EffectA(x) equals to the conjunction of EffectB(x) and EffectC(x).
Just like we can see the glass as half empty or as half full. The expression 
are different but they have the same meaning.
That is,
TheGlassHalfEmptyEffect(x) -> TheGlassHalfFullEffect(x)
Another example,
GetMyCarRepairedEffect(x) and GetMyCarCleanEffect(x) ->
GetMyCarRepairedAndCleanEffect(x)

The concept "GetMyCarRepairedAndCleanEffect" is the intersection of the concept
"GetMyCarRepairedEffect" and "GetMyCarCleanEffect".

> 
> > When EffectB and EffectC are not
> > atomic concepts, the situation becomes more complex. How to handle
> > this kind of things in planning algorithms?
> 
> Well, I won't repeat our paper, but I will add that the problem is
> *much* trickier when your *domain* may have been gathered from
> disparate sources. It's hard to forbid use of derived literals in that
> case (IMHO).

Best regards!

Manshan Lin
Email: lmshill@hotmail.com;lmshill@gmail.com
Affiliation: School of Computer Science and Engineering, the South
China University of Technology
Phone: (+86)13711287277
2004-12-03

Received on Friday, 3 December 2004 02:35:14 UTC