TRIPS Architecture

Home | People | Projects | Publications | Resources

TRIPS Architecture | TRIPS Movies | TRIPS Domains | TRAINS vs. TRIPS


Physical Architecture

The physical architecture of TRIPS is a hub and spoke message passing system. The hub (called the Facilitator) receives/passes messages from/to any of the other components. It also performs system start-up and shut-down coordination among components.

Logical Architecture

TRIPS' logical architecture is comprised of a complex network of agents (as shown in the image below). Each agent has a well-defined linguistic or planning role in the overall dialog interaction. (Click on the image below for specific information about a TRIPS component, or keep reading below for more general information)

Speech Recognition | GUI Input | Parser | Reference | Discourse_Context | Interpretation Manager | Generation Manager | Surface Generation | Speech Synthesis | GUI Output | Behavioral Agent | Task Manager | Planner | Scheduler | Monitors | Events

The image above shows the logical flow of information among TRIPS components. KQML messages are used for communication.

TRIPS components can be divided into three areas of functionality: interpretation, generation, and behavior, which are directed by the Interpretation Manager, Generation Manager, and Behavioral Agent, respectively. These three agents comprise the triangular 'backbone' of the system. Each runs independently and asynchronously, which means the system can potentially be interpreting input from the user, interacting with the world, and planning a response based on previous input/actions, all at the same time. This division of labor allows the system to engage in mixed-initiative planning, where both the user and the system are active participants in the conversation.

When the user wishes to communicate with the system (either by speech, keyboard, or mouse), their input is parsed and sent to the Interpretation Manager, which interprets the parsed input as a problem solving act (i.e. it decides what the user really meant by his utterance). It passes the problem solving act to the Behavioral Agent, which decides how to respond to this problem solving act (e.g., use domain specific agents to accomplish the act, ignore it and work on something more pressing, etc.) The Behavioral Agent then reports its status to the Generation Manager, which then plans a linguistic act to communicate the Behavioral Agent's intentions to the user.

If you wish to see more details about the architecture of the system, please click on individual components in the image above or reference one of our papers shown below.

Papers Dealing with TRIPS Architecture

  • James Allen, Donna Byron, Myroslava Dzikovska, George Ferguson, Lucian Galescu, and Amanda Stent, "Towards Conversational Human-Computer Interaction," AI Magazine, 2001. [PDF]

  • James Allen, George Ferguson, and Amanda Stent, "An architecture for more realistic conversational systems," in Proceedings of Intelligent User Interfaces 2001 (IUI-01), Santa Fe, NM, January 14-17, 2001. [PDF]

  • James Allen, Donna Byron, Myroslava Dzikovska, George Ferguson, Lucian Galescu, and Amanda Stent, "An Architecture for a Generic Dialogue Shell," Journal of Natural Language Engineering, special issue on Best Practices in Spoken Language Dialogue Systems Engineering, 6(3), December, 2000, pp. 1-16. [PDF]

  • George Ferguson and James Allen, "TRIPS: An Intelligent Integrated Problem-Solving Assistant," in Proceedings of the Fifteenth National Conference on Artificial Intelligence (AAAI-98), Madison, WI, 26-30 July 1998, pp. 567-573. [PDF]

Last change 07 Nov 2000 by blaylock