The Ravenclaw dialog manager structures a dialog application as a task or set of tasks in a target domain that the system helps a user perform. Tasks can be hierarchical. For example in a travel arrangements task, asking for an airplane schedule or reserving a hotel room would be two included but separate tasks. To complete a task Ravenclaw will need certain pieces of information, for example a date or a city name in the travel domain. Dialog consists of acquiring, modifying or validating this information. You might want to think of tasks as being plans. The task organization supports mixed-initiative interaction which supports easy shifts between tasks (you can think of tasks as topics) and allows the user to specify what the system does next. This is in contrast to so-called directed dialog systems that require users to follow a prescribed sequence of exchanges in order to complete a task. Of course if the user is not familiar with the task or domain, the dialog will appear directed, as the system pursues the goal of completing the task at hand.
More detailed information can be obtained from the papers listed in the References section.
The development process
The following is a very simple account of the development process. The tutorials below will guide you through the details. You may also want to examine one of the example systems to get an idea of what needs to be done.
- Define the task(s) that the system will carry out. Some tasks may not require data but other will; specify these data.
- Create an initial language specification. This will be the grammar and will contain entries that correspond to how users will refer to tasks and to the language they will use to specify input data and control the system.
- Using the language as a guide, create a task-tree for the dialog manager.
- Create a "back-end" that will process queries form the dialog manager and will return information that can then be spoken to the user.
- Populate the language generator module with language used to speak system output to the user.
The above is an outline of a simple speech-only application that might, for example, retrieve information from a database. Olympus can also be used to build more complex multi-modal systems as well as action-oriented systems (such as robot interfaces).
- Tutorials Overview
- Tutorial 1: A simple bus schedule information system
- Tutorial 2: A little mixed initiative...
- Tutorial 3: Speechifying a system
- Tutorial 4: Sorry, I didn't catch that... Strategies for preventing and handling ASR errors
- Manual CMake Build Configuration (Olympus 2.5+)
- Agent Runtime Configuration Overview
- System Runtime requirements
- List of Olympus Components
- Galaxy Services and Service Providers defined by Olympus
- Ports commonly used in Olympus
Here's is a collection of reference material relating to the most important Olympus components, especially with regard to their configuration. For a more complete reference, see the File Structure.
- Logging (log structure)
- LogParsers Reference (log summarization and analysis programs)
- WebDialogueBrowser Reference
- CorpusTools Reference
- RCTaskViz Reference
- Logios Reference (compiling language knowledge bases)
- Speaker Adaptation
- Desktop Transcriber
- Web Transcriber
Plugging in your own modules into Olympus
- BE: Plugging a backend module in Olympus
- ASR: Plugging a speech recognition engine in Olympus
- NLU: Plugging a parser in Olympus
- NLG: Plugging a natural language generation system in Olympus
- TTS: Plugging a speech synthesizer in Olympus
- DM: Grounding in RavenClaw
- HE: Training a Helios confidence annotation model
- DM: Dynamic task tree generation in RavenClaw
- IM: Turn-taking models in Apollo
Questions and Problems
For additional information, as well as specific questions, email the developers mailing list (email@example.com).