: The Try-execute action.
Since problem-solving plans must be general enough to control all various activities, they cannot refer directly to any linguistic or domain action; they just state how other knowledge can be used to solve problems. So, problem solving plans do not contain any reference to linguistic actions, but only to the ``structure" of plans; in other words, they talk about preconditions, constraints, effects, decompositions. It must be stated elsewhere that for going to a place one must know the location of that place, or that if one has the goal of knowing something, it is possible to ask somebody else about what must be known (many other possibilities exist, of course). So, we maintain a tripartite plan library (domain, linguistic, and problem solving), but with a more clear-cut separation with respect to the approach by Carberry et al. The problem-solving library is nothing else than a declarative representation of a (very simple) problem solving procedure. Being it declarative (and expressed in terms of a plan-based formalism) it can be used not only for building new plans (and in fact we have not used it in this way until now) but also for recognizing the activity of another agent who is reasoning on plans under development, or is executing a plan.
The problem-solving library is organized around two main actions: Satisfy
and Try-execute. We suppose that the problem solving activity starts with
a certain goal that has to be satisfied. In order to satisfy a goal, the action
Satisfy specifies that you must first find a suitable action (which is
done in two steps: first find all the actions that can produce, as effect, that
goal and then choose one among them) and then you must carry out that action.
As regards the chosen action, there are three possibilities: either no action
was found (so you must give up), or the action found has to be done by somebody
else, or it is an action that you can execute by yourself. In the second case
you must issue a request to another agent to do something, while in the third
case you can try to start the execution of the action, which is encoded in the
Try-execute action. All of this has been suitably encoded in a plan based
formalism. In order to show the basics of the representation, we report in
Figure 1 the fragment of the library concerned with
Try-execute.
Try-execute is decomposed into four steps: Check-reply-constr,
Verify-prec, Examine-action, and Check-done. In the first
step the agent checks whether all constraints of the chosen action hold (the
triple vertical bar is a graphical representation of an iteration over the set
of constraints). Note that, in order to check a constraint c, the agent a
must satisfy the goal ``Knowif (a,c)", which is a recursive call to the
Satisfy plan. If some constraint does not hold and the agent is acting
upon request of somebody else, then the agent must notify her inability to do
what requested.
In the Verify-prec …step the same controls are
carried out for preconditions, with the difference that, in case some
precondition does not hold, the agent can try to plan an action that makes it
become true (another recursive call to Satisfy). The third step
( Examine-action) involves the actual execution: if the action is
elementary (i.e. not further decomposed into substeps) it can be executed
directly ( Do); if it is complex the whole process has to be repeated on
the substeps (a recursive call to Try-execute itself); if the action has
some specializations, then one of them has to be selected and
executed.
Finally, when all has been completed, the agent must check whether the execution of the action actually led to the desired goal ( Check-done).
The idea of asking other agents to satisfy one's own goals is based on an
assumption of cooperativity in dialogue: an agent is supposed to recognize the
intentions of a speaker, and to adopt them as her own intentions, unless
they go against her interests. After the intentions are adopted by the
interlocutors, they become Joint Intentions ([Cohen & Levesque1991]) and are
the basis of the cooperation in dialogue (e.g. consider a positive
acknowledgement after having executed successfully an action, or the
notification that an action can not be
executed).
