Home | People | Projects | Publications | Resources
TRIPS Architecture | TRIPS Movies | TRIPS Domains | TRAINS vs. TRIPS
|
The Task Manager houses the domain specific task knowledge, which it abstracts away from the system. Using this knowledge, it provides several services to the domain independent components including the following.
Task RepresentationThe Task Manager represents domain specific tasks as hierarchical plan skeletons. These plan skeletons have information of typical domain objectives, breakdowns of these objectives as subobjectives, typical sets of actions used as solutions to objectives, and so on.As a user and a system plan together, the details of this hierarchy get fleshed out. As opposed to just regular planning where it is only important to save the steps on the plan, in mixed-initiative planning between the user and the system, more information is necessary. It is necessary for the system to keep track of not only the overall solution (plan) but also the structure of objectives and subobjectives. This is because it must allow the user to shift the focus to different objectives at any time. Also, in mixed-initiative planning, the user may want to suggest and compare alternative solutions for a single objective. The system must also be able to allow the user to undo actions and revert to old solutions. Intention RecognitionIntention recognition is probably one of the most difficult functions of the Task Manager. In this context, intention recognition is the process of mapping a speech act onto a problem solving act. This is where the true "understanding" of the system actually happens. Given an utterance (in the form of a speech act) the Task Manager must determine what the underlying intention of the utterance was.Intention recognition requests are sent to the Task Manager by the Interpretation Manager. Intention recognition must be done by the Task Manager since it has knowledge of the current problem solving context. Depending on which subobjective the user is focused on and what parts of the solution are already fleshed out, similar utterances can have very different meanings. The Task Manager then interprets the speech act within a problem solving context and returns the answer to the Interpretation Manager along with two different scores: the recognition score and the answer score. The recognition score indicates whether or not the problem solving act is something that "makes sense" based on the given problem solving context. This is basically a confidence score (given that we assume that the human will say things that make sense within a context). The answer score indicates whether or not the requested action is possible given the problem solving context. This score is important because it may be possible that the user tries to do something that is reasonable, but, because they don't have knowledge of the whole situation, is infeasible. A typical response to a bad recognition score might be a clarification question to the human. A response to a bad answer score might be informing the user why the requested action cannot be performed (a bridge is out, the ambulance they want to use is assigned to another task during that time, etc.) Mapping between problem solving acts and domain specific actionsThis interaction occurs between the Task Manager and the Behavioral Agent. As shown on the architecture page the Behavioral Agent does not communicate directly with the domain specific agents (shown as the planner and scheduler in this example). This is because the Behavioral Agent does not have domain specific knowledge. It only deals in generic problem solving acts. Therefore, it is important that it be able to send those act requests (things like actually inserting a step into a solution, moving the user focus, executing a plan, etc.) to the Task Manager, which maps them onto domain specific actions and can invoke the necessary back-end agents to do the action.Answering queries about objects in the domainThe reference component has the job of matching referring expressions to actual entities on the real world. Sometimes this can be done using purely linguistic knowledge, (as in knowing that "the truck" probably refers to the truck we just mentioned) but other times, it requires knowledge of the domain and/or the current problem solving state (as in knowing that "the truck we sent to Pennfield" refers to the truck used in a "send" action in one of our solutions). This service allows components to query about certain objects and their use in our tasks.Message TrafficCurrent ResearchersRelevant Papers
|