<?xml version="1.0" standalone="yes"?>
<Paper uid="W02-0209">
  <Title>A Flexible Framework for Developing Mixed-Initiative Dialog Systems</Title>
  <Section position="3" start_page="0" end_page="0" type="metho">
    <SectionTitle>
2 The HOT framework
</SectionTitle>
    <Paragraph position="0"> Our framework' s moniker is HOT, which stands for its three components: dialog History, domain Objects, and Task hierarchy. It is implemented as a Java library. In this section, we describe the HOT framework. We assume the existence of an application specific natural language parser that brackets and labels chunks of text corresponding to domain specific attributes, and a natural language generation module for generating prompts from abstract specifications.</Paragraph>
    <Section position="1" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
2.1 Task hierarchy
</SectionTitle>
      <Paragraph position="0"> A task defines a unit of work for a dialog system. The HOT framework enables the specification of tasks that are organized as a hierarchy (e.g. Fig. 1). The terminal tasks in the hierarchy (UserID, Fund, and Shares) derive canonical values of domain attributes (such as fund symbol) from parsed portions of user input.</Paragraph>
      <Paragraph position="1"> The RootTask specifies methods for managing the dialog, e.g. for disambiguating among different sub-tasks in case of ambiguous user input. All other tasks perform scripted actions using the output produced by other non-terminal or terminal tasks: generate a user profile, a share transaction, or a price quote.</Paragraph>
      <Paragraph position="2"> The task hierarchy constitutes a plan for the dialog. It remains to be seen whether it can also be used for planning domains in which task input can come either from a user or from an external process such as an environmental monitor, as in [Allen at al. 2001].</Paragraph>
      <Paragraph position="3"> The framework allows developers to easily specify five different relationships among tasks in a hierarchy. Many of these will be exemplified in Section 3.</Paragraph>
      <Paragraph position="4">  1. Subtasking: UserID is a subtask of Login because Login needs the user' s ID to log the user in.</Paragraph>
      <Paragraph position="5"> 2. Ordering: Login precedes all other tasks, but Buy, Sell, and Price are unordered.</Paragraph>
      <Paragraph position="6"> 3. Cardinality: Login is executed only once per session, and UserId, Fund, and Shares are executed only once per parent task.</Paragraph>
      <Paragraph position="7"> However, Buy, Sell, and Price can be executed multiple times.</Paragraph>
      <Paragraph position="8"> 4. Inheritance: Buy and Sell can potentially inherit a fund name from Price and vice versa.</Paragraph>
      <Paragraph position="9"> 5. Subdialog: The user can carry out certain  subdialogs, such as a Price query within a Buy task.</Paragraph>
    </Section>
    <Section position="2" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
2.2 Focus model
</SectionTitle>
      <Paragraph position="0"> At each turn of the dialog, we automatically score the user' s input to infer the task that the user wants to work on. Only a non-terminal task can receive focus. As in FDM, scoring is primarily based on the number of matches between attributes in the parsed user input, different task attributes, and the last system prompt. The developer can specify the appropriate system behavior if the inferred user focus conflicts with task relationships, e.g. if a user wants to Buy but has not yet Logged in. In the absence of such conflicts, the framework triggers execution of the inferred task. If the task completes without ending a turn, the focus model returns focus to a previously started task if possible, or else defaults to the developer' s preference for what to do next.</Paragraph>
    </Section>
    <Section position="3" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
2.3 Task functionality
</SectionTitle>
      <Paragraph position="0"> Within RootTask, a developer can specify the modalities of interaction and the specific backends used, create an initial task layout, and set some dialog parameters. Developers must specify how they want RootTask to respond to various focus situations. For example, if no tasks are eligible for focus, this may represent an error condition in one application, but the expected end of a dialog in another application.</Paragraph>
      <Paragraph position="1"> For all other tasks, task functionality can be divided into operations that happen before and after the task calls its backend process  mutual fund application.</Paragraph>
      <Paragraph position="2"> (accessing a database, the Internet, or other information channel) to create a result. Prebackend functionality involves assessing, and possibly confirming with the user, the parameters to be sent to the backend. Postbackend functionality acts on different backend outcomes: for example, informing the user of a result, confirming a result, or requesting further constraints. Because the framework already defines these functionalites, the developer' s role is to define the backend and its result, and to choose the pre-defined functionalities that apply. As tasks execute, they post communicative intentions - dialog acts (e.g., &amp;quot;Inform&amp;quot;, &amp;quot;Confirm&amp;quot;) and the domain objects they concern (e.g., flights) - to the dialog history. A separate NLG module generates the text of the system response based on these communicative intentions and the specific modalities in use.</Paragraph>
    </Section>
    <Section position="4" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
2.4 Dialog History
</SectionTitle>
      <Paragraph position="0"> The dialog history provides developers with an organized way to store system data regardless of the application domain. We store the user input (attribute-value pairs), the system response (communicative intentions), and the cumulative results for each dialog turn. The developer can additionally store the user input at various stages of processing. Results can be generic objects (e.g., a String representing a fund name) or complex, domain-specific objects. The results are tagged with a core set of status indicators that developers can add to. The dialog history also serves as a task stack, since the current result from each task indicates the task' s status.</Paragraph>
      <Paragraph position="1"> The dialog history is reminiscent of BBN' s state manager (Stallard 2000), but the latter also includes many dialog management responsibilities that we reserve to tasks.</Paragraph>
    </Section>
  </Section>
  <Section position="4" start_page="0" end_page="0" type="metho">
    <SectionTitle>
3 Applications
</SectionTitle>
    <Paragraph position="0"> We are currently implementing the HOT framework described above. In this section, we describe two sample applications built using this framework as implemented so far.</Paragraph>
    <Section position="1" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
3.1 Mutual Funds
</SectionTitle>
      <Paragraph position="0"> We built a mutual funds application, using the framework to create a task hierarchy and to add task relationships such as ordering and inheritance, as described in section 2.1. We customized the tasks by writing backend methods and specifying confirmation strategies, the domain attributes of interest to each task, and domain-specific result objects (UserProfile and ShareTransaction). Figure 2 shows an actual dialog with this application.</Paragraph>
      <Paragraph position="1"> The dialog flows through a combination of developer specifications and the HOT framework, with the framework doing most of the work. In turn 1, only Login is specified as active, so the framework generates an initial prompt for it. In turn 2, the framework scores the input and executes both UserID and Signin.</Paragraph>
      <Paragraph position="2"> It informs the user of Login' s success (as specified), then issues a general prompt because Login enabled all other tasks when it finished (as specified). In turn 3, the framework issues an error message because of the conflict between Login' s cardinality of 1 and the user' s input. In turn 4, the fund name lookup finds an ambiguous result; the framework looks to the developer to specify what type of prompt to issue in response. In turn 5, the framework correctly interprets the user' s selection, and requests fund name confirmation (as specified).</Paragraph>
      <Paragraph position="3"> In turn 6, Sell runs its Number of Shares subtask. In turn 7, the user performs an authorized Price subdialog from within Sell.</Paragraph>
      <Paragraph position="4"> Price inherits the fund name from Sell, executes the task, and returns focus to Sell. In turn 8, the framework requests confirmation prior to</Paragraph>
    </Section>
    <Section position="2" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
User System
</SectionTitle>
      <Paragraph position="0"> built using the HOT framework.</Paragraph>
      <Paragraph position="1"> executing the sale (as specified). In turn 9, note that the Sell backend accesses the dialog history to determine the correct transaction number.</Paragraph>
    </Section>
    <Section position="3" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
3.2 Travel
</SectionTitle>
      <Paragraph position="0"> We have developed a travel information dialog system using the HOT framework. For this application, we reused several components of the IBM DARPA Communicator system. The system accepts either standard text input or text from instant messaging from a mobile platform.</Paragraph>
      <Paragraph position="1"> Figure 3 shows a screen shot of a dialog on a &amp;quot; Palm&amp;quot; (PDA) interface to the travel system.</Paragraph>
    </Section>
  </Section>
class="xml-element"></Paper>