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

On Dec 8, 2004, at 12:50 PM, Manshan Lin wrote:

> Thanks for McDermott and Parsia's instructions!

No problem.

> I'm wondering these days about two questions:
> 1. In planning for WSAC, we have two choices: a) planning from
> the initial state to the goal; b) planning from the goal to the initial
> state.

Well...maybe. This oversimplifies the picture considerably, I think.

> Because it is hard for us to establish a complete initial state

But we don't need to, typically. At least for various values of 
"complete". We need to supply sufficient information to get off the 
ground (and hope that there isn't conflicting, unknown to us, 
information)....

Hmmm. This feels like a bit of a tangent. Perhaps what you mean is that 
in advance of doing the planning, we don't know what specific 
information would be needed to find plans. This pretty clearly isn't 
generally true, as people do in fact construct domains that generate 
plans given certain initial states (and plausibly do so for a wide 
variety of relevantly similar initial states). In this sense, writing a 
planning domain is not unlike writing a program: you anticipate the 
typical inputs and try to construct things so you get the right 
outputs.

In a web services context wherein you expect the domain to be 
constructed piecemeal by disparate authors unaware of each 
other...things get trickier. Of course, it's not clear that people 
*will* construct such domains, that is, it seems highly likely that 
people will publish service descriptions with an eye to 
interoperability. But it is a real problem. Regression doesn't help 
with *that*, of course.

> before planning (the user doesn't know what information he should
> privide in advance. For example, some plans generated to buy a
> book may require the user to provide his address, while some may
> require the user to provide both his address and phone number),

Well, you can do on demand querying, as described in our papers. Or you 
could analyze the domain to get some sense of what information *might* 
be relevant.

We're still making the assumption, in one sense, that the initial state 
is *known*, at least in so far as it's fixed and queriable. And given 
those constraints, I don't see that there is a strong presumption for 
the direction of planning.

> b) seems to be a good choice.

It depends on so many other factors that I think this is very very 
premature. Progression, like forward chaining, has a lot of advantages 
:)

> 2. If we choose b), the following question must be answered:
> how to recognize an input of an operation that can be provided
> by the user?

Actually seems true in either case.

> if the input is the user's private information, we can
> define these kind of information in the initial state;

But we may not want to. For example, the planner might have access, in 
principle, to all the data on my machine (email addresses, contact 
info, bookmarks, schedule), but dumping all that into the initial state 
EVERY time seems, well, bad.

>  however, if the
> information is plan specific, such as "bookname", "ISBN" in bookstore
> example, how can we recognize it?

Construct your description such that one kind of service that could 
supply it is an "ask the user" service. That is, mark it up :) It 
needn't be the *only* way the planner could get that information, and 
you might prioritize it in a number of ways (e.g., make it the last or 
first resort).

> Let's consider this situation:
> an operation "o1" needs "bookname" as input, another operation
> "o2" tranfers the input "isbn" to the corresponding output "bookname".
> How can a planner make a decision on getting the "bookname" of "o1"
> from the user or from the output of "o2"?

See above. I don't see querying information from the user to be 
distinct from general querying. You have to let the system know that 
such queries are possible, and you want to insert some sort of control 
information so that the system uses appropriate query at the 
appropriate time.

Cheers,
Bijan Parsia.

Received on Wednesday, 8 December 2004 05:03:32 UTC