<?xml version="1.0" standalone="yes"?>
<Paper uid="W02-0209">
  <Title>A Flexible Framework for Developing Mixed-Initiative Dialog Systems</Title>
  <Section position="2" start_page="0" end_page="0" type="intro">
    <SectionTitle>
1 Introduction
</SectionTitle>
    <Paragraph position="0"> Developing a mixed-initiative dialog system is a complex task. The developer must model the user's goals, the &amp;quot;results&amp;quot; (domain objects) retrieved, and the state of the dialog, and generate the system response at each turn of the dialog. In mixed-initiative systems, as opposed to directed dialog systems, users can influence the dialog flow, and are not restricted to answering system questions in a prescribed format (e.g. Walker 1990, Chu-Carroll 2000).</Paragraph>
    <Paragraph position="1"> Compounding these challenges, dialog applications have evolved from simple look-up tasks to complex transactional systems like telephony banking and stock trading (Zadrozny et al. 1998), and air travel information systems.</Paragraph>
    <Paragraph position="2"> These systems increasingly cater to multiple channels of user interaction (telephone, PDA, web, etc.), each with its own set of modalities.</Paragraph>
    <Paragraph position="3"> To simplify the development of such systems, researchers have created frameworks that embody core dialog functionalities.</Paragraph>
    <Paragraph position="4"> In MIT's framework, a developer creates a dialog system by specifying a dialog control table comprising actions and their triggering events. The developer has great freedom in designing this table, but must specify basic actions such as prompting for missing information. As a result, these tables can become quite complex - the travel system control table contains over 200 ordered rules.</Paragraph>
    <Paragraph position="5"> MIT has applied this framework to both weather and travel (Zue et al. 2000, Seneff and Polifroni 2000).</Paragraph>
    <Paragraph position="6"> In IBM's form-based dialog manager, or FDM (Papineni et al. 1998), a developer defines a set of forms that correspond to separate tasks in the application, such as finding a flight leg. The forms have powerful built-in capabilities, including mechanisms that trigger various types of prompts, and allow the user to specify inheritance and other relationships between tasks. Just as in the MIT framework, domain-specific modules perform database queries and other backend processes; the forms call additional developer-defined modules that affect the dialog state and flow. FDM has supported dialog systems for air travel (Papineni et al.</Paragraph>
    <Paragraph position="7"> 1999, Axelrod 2000) and financial services (IBM 2001, IBM 2002). The University of Colorado framework also has a form-based architecture (Pellom et al. 2001), while CMU and Bell Labs' frameworks allow the specification of deep task hierarchies (Wei and Rudnicky 2000, Potamianos et al. 2000).</Paragraph>
    <Paragraph position="8"> Our goal is to design a framework that is both powerful, embodying much dialog functionality, and flexible, accommodating a variety of dialog domains, modalities, and styles. Our new framework goes beyond FDM in building more core functionality into its task model, yet provides a variety of software tools, such as API calls and overwritable functions, for customizing tasks. The framework allows developers to specify a wide range of relationships among tasks, and provides a focus model that respects these relationships. To support the task framework we introduce a Philadelphia, July 2002, pp. 60-63. Association for Computational Linguistics. Proceedings of the Third SIGdial Workshop on Discourse and Dialogue, dialog history component that remembers input, output, and cumulative task results. Section 2 of this paper describes the framework, and section 3 some applications. In section 4 we discuss future plans and implications.</Paragraph>
  </Section>
class="xml-element"></Paper>