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

On Dec 6, 2004, at 7:28 PM, Manshan Lin wrote:

> After getting more information from [1][2][3][4] about applying HTN 
> planning to
> WSAC,
> I'm wondering its applicability based on the following reasons(Due to 
> my
> knowledge limitation, there must be something wrong, pls point it out):
> 1) SHOP2 approach seems to use a partially ordered set of tasks to 
> describe the
> user's requirements.

The initial task list, yes.

>  I don't think it's a feasible way comparing with
> goal formula.

Eh. It works. Many people find it natural.

> Actually, the underlying intention of the abstract tasks are their 
> outputs and
> effects, which are goal formulas.

No, it isn't the underlying intention.

> However, these goal formulas may be
> achieved by
> different abstract tasks.

Consider that different decompositions might, and almost certainly 
will, have different end states. Even contradictory end states. Thus, 
the only possible goal formula the could all underlyingly "intend" is 
the disjunction, which, in normal SHOP, isn't even experssible as an 
effect.

> 2) The HTN planning domain includes a set of operators (that is,
> atomic service)
> and a set of methods (that is, composite service). I don't know 
> whether the
> process model of OWL-S intents to be shared among agents. But from the
> viewpoint of security, I thow doubt on the agents' willing to expose
> their process
> model, which may reflect their business logic.

Often, to interoperate, you must expose at least some. See 
WS-Choreography.

However, in HTN planning, it's not most natural to see methods as 
descriptions of the internal process model of a service, but rather as 
templetes or recipes for how to accomplish a task. So they are very 
naturally thought of as public.

> 3) In [3], it extends HTN planning algorithm to handle 
> incomplete-information
> planning problem. While some information can be provided by web 
> services, some
> must be provided by the user himself since we can't require the user
> to provide all
> the needed information to accomplish the plan.

Not quite following. Your "since" doesn't seem to quite follow the 
intent of the previous clause.

Plus, we should distinguish between information necessary to *find* the 
plan, and to *accomplish* the plan.

In any case, there really is no fundemental distinction here. Have a 
web service solicit humans for information. We did it. The rest of the 
initial state is typically supplied by a person.

> The question is, how to
> distinguish
> what information should be provided by other web services and what 
> should be
> provided by the user?

"Should be"? I tend to think that this is a matter for the domain 
writer. Often, it depends on how much intervention you want to set up.

> As discussed in the mailing list before, since we can't
> control other services,

Surely we can :)

> the information gathered during planning may
> be different
> when executing.

This isn't really following for me either. It's because the *world* 
might be different. (Take, for example, a step in a plan that's 
dependent on the ambient temperature. Nothing about controlling the 
*service* reporting the temp. is at issue here.)

>  As mention at the end of the paper, I agree that
> inserting queries
> to the plan (leading conditional plans) is more proper.

Eh. Drew deal with this a bit. In fact, while we tend to say, "oh yes, 
we'll have to deal with conditional plans at some point", I tend, in 
general, to hold off. There are a variety of ways to deal with plan 
failure (contingencies, online planning, or replanning) and they are 
all worth exploring in various contexts.

One thing we've done in our work is to try to lift normal planning 
restrictions as minimally as possible. So, for example, the Enquirer 
algorithm should return the same results (in principle) if you did all 
possible queries up front. (It won't actually, since information may 
have in fact from the start of planning and the time of query, *but* we 
don't make any theoretical use of that fact.)

So, in essence, instead of reinventing planning, we've mostly tried to 
be clever in our use of planning. At some point, this will probably 
break down, but it's interesting to see how far it can go.

> [1] SHOP2: An HTN Planning System;
> http://www.cs.cmu.edu/afs/cs/project/jair/pub/volume20/nau03a.pdf
> [2] Automatic Web Services Composition Using SHOP2;
> http://www.mindswap.org/papers/ICAPS03-SHOP2.pdf
> [3] http://www.mindswap.org/papers/ISWC04-Enquirer.pdf
> [4] http://www.mindswap.org/papers/SWS-ISWC04.pdf

Whoa. Lotta reading there.

Cheers,
Bijan Parsia.

Received on Tuesday, 7 December 2004 02:28:00 UTC