W3C home > Mailing lists > Public > public-sws-ig@w3.org > December 2004

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

From: Bijan Parsia <bparsia@isr.umd.edu>
Date: Thu, 2 Dec 2004 20:19:54 +0900
Message-Id: <1762D732-4454-11D9-8B14-000D93C1F7A6@isr.umd.edu>
Cc: public-sws-ig@w3.org
To: Manshan Lin <lmshill@gmail.com>

On Dec 2, 2004, at 10:39 AM, Manshan Lin wrote:

> 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! ;)

> And I also
> notice that in order
> to achieve true automatic composition of web service, we must tackle
> the problem of planning under description logic,

OWL DL is just a fragment for first order logic.

>  which is based on
> open-world assumption.

Now that is true.

> 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:	

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?

> 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 :)

> 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).

Bijan Parsia.
Received on Thursday, 2 December 2004 11:20:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:32:47 UTC