next up previous
Next: Creating the Plan Up: Planning for Asynchronous Requests Previous: Planning for Asynchronous Requests

Receiving a Request

 

Users submit their task requests through one of three different interfaces: the World Wide Web [Simmons et al. 1997], Zephyr [DellaFera et al. 1988, Simmons et al. 1997], or a specially designed graphical user interface (Figure 3) [Haigh & Veloso1996].

 

figure207


Figure 3: User request interface.

The slots in this last interface are automatically filled in with default information available from the user's plan file, and the deadline time defaults to one hour in the future. The interface can be extended with additional tasks at any time.

Each of these three interfaces forwards the request to ROGUE by TCA messages. When each new request comes in, ROGUE adds it to PRODIGY4.0's list of unsolved goals, and updates the task model, as shown in Table 1. The literal (needs-item <user> <item>) indicates that a request, sent by user <user>, is pending. This function is domain-dependent because the literals added relate strictly to this domain; however, the structure would be identical for any other domain with asynchronous goals.

 

table254


Table 1: Integrating new task requests into PRODIGY4.0.

There is currently no explicit mechanism for a user to rescind a request; however PRODIGY4.0 will no longer plan for (or attempt to apply operators for) the associated top-level goal if it is simply removed from G and PG.



next up previous
Next: Creating the Plan Up: Planning for Asynchronous Requests Previous: Planning for Asynchronous Requests

Karen Zita Haigh
Mon Oct 6 14:33:27 EDT 1997