- From: Bijan Parsia <bparsia@isr.umd.edu>
- Date: Wed, 8 Dec 2004 14:03:20 +0900
- To: Manshan Lin <lmshill@gmail.com>
- Cc: public-sws-ig@w3.org
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