<?xml version="1.0" standalone="yes"?>
<Paper uid="E99-1004">
  <Title>An Object-Oriented Approach to the Design of Dialogue Management Functionality</Title>
  <Section position="2" start_page="0" end_page="23" type="intro">
    <SectionTitle>
1 Introduction
</SectionTitle>
    <Paragraph position="0"> For the purpose of developing automated systems, dialogues may be seen as comprising commonplace routines on the one hand and specialized, task-specific interactions on the other. In software engineering, object-orientation has proved to be an effective means of separating the generic from the specialized, and more particularly, of letting the specialized inherit the generic (Rumbaugh et al., 1991). Identifying inheritable generic functionality (for confirmation, repair of misunderstanding, personalization of utterances, etc.) and specialized or highly domain-specific functionality, opens the way to dialogue systems that can be assembled largely from ready-made components and extended with the addition of more specialized components. The prototype system that we have been developing in Prolog++ for the last year combines this familiar object-oriented approach with a self-organizing, mixed-initiative dialogue strategy. Pseudocode is used here to represent the Prolog processing.</Paragraph>
    <Paragraph position="1"> 2 Identifying the generic and the specialized In the course of developing the prototype system a number of important generic elements have been identified that can be ported with a minimum of alteration between domains. These generic elements are now introduced.</Paragraph>
    <Section position="1" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
2.1 Dialogue Manager
</SectionTitle>
      <Paragraph position="0"> In any system that is concerned with conducting a dialogue with a user, a mechanism is required for receiving, forwarding for processing, and outputting semantic contents of utterances. This responsibility falls to a Dialogue Manager.</Paragraph>
    </Section>
    <Section position="2" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
2.2 Domain Spotter
</SectionTitle>
      <Paragraph position="0"> Any system that is intended to handle processing across a number of real-world areas of expertise requires a means of associating key semantic content of the user's utterances with one or more of the available domains. This responsibility falls to the Domain Spotter.</Paragraph>
    </Section>
    <Section position="3" start_page="0" end_page="23" type="sub_section">
      <SectionTitle>
2.3 Discourse Stack
</SectionTitle>
      <Paragraph position="0"> Any system dealing with a transaction that involves multiple dialogue turns must have a means of logging a) what it believes the user has said, b) the degree of 'confirmedness' of what has been said, and c) how the system has decided to respond. Maintaining a record of the evolving discourse, and providing the means of creating and retrieving entries for individual utterances, are the responsibilities of the Discourse Stack.</Paragraph>
    </Section>
    <Section position="4" start_page="23" end_page="23" type="sub_section">
      <SectionTitle>
2.4 Enquiry Processor
</SectionTitle>
      <Paragraph position="0"> Given the current difficulties of speech recognition, and the possibility that a user will misunderstand or change his or her mind, any system conducting a complex transaction must have a strategy for confirming the semantic contents of the user's utterances and for proceeding with the transaction only when details have been adequately confirmed. The current system increments or decrements levels of 'confirmedness' depending on whether the user repeats or confirms, alters or negates values. If necessary, the system queries the user explicitly about values that are new, altered or negated. The responsibility for these purely generic, mechanistic confirmation routines falls to the Enquiry Processor, whose strategies are inherited, via a generic agent or Expert, by subclasses that have their own domain-specific processing heuristics.</Paragraph>
    </Section>
    <Section position="5" start_page="23" end_page="23" type="sub_section">
      <SectionTitle>
2.5 Expert
</SectionTitle>
      <Paragraph position="0"> Each of the more specialized agents within the system must have access to wider system resources and have ways of providing the wider system with high level information about its processing abilities. Supporting these common behaviours and characteristics is the responsibility of the generic Expert class.</Paragraph>
      <Paragraph position="1"> Other parts of the system must be tailored to represent the specialized knowledge and processing abilities of real-world human specialists. These are introduced next.</Paragraph>
    </Section>
    <Section position="6" start_page="23" end_page="23" type="sub_section">
      <SectionTitle>
2.6 Expert Subclasses
</SectionTitle>
      <Paragraph position="0"> For each business area within the system there must be functionality a) to decide what information to elicit next, or what information to infer, given that certain information may already  have been provided, b) to check the validity of the combinations of information provided, c) to give the most helpful guidance when the user is having difficulty completing the enquiry, and d) to decide when sufficient, confirmed information has been provided to conclude the transaction. Such functionality is specific to the Expert subclasses within the system, and recreates in sometimes quite extensive sets of domain-specific heuristics, the kind of behaviour (e.g. 'if details for an outward journey are received, check if a return is needed'; 'if a venue has been confirmed but not a day, ask for the day') that would characterize any human expert in a particular business domain - a travel agent or a theatre booking clerk, for instance. The current subclasses are Travel Expert, Event Expert and Place Expert.</Paragraph>
    </Section>
    <Section position="7" start_page="23" end_page="23" type="sub_section">
      <SectionTitle>
2.7 Expert Instances
</SectionTitle>
      <Paragraph position="0"> The system must contain detailed service information of the kind that in the real world is associated with individual businesses. Businesses are represented by instances of Expert subclasses.</Paragraph>
      <Paragraph position="1"> The instances represent particular airlines, railways, theatres, cinemas and so on; they have access to the data - concrete schedules and timetables - that must be consulted if a transaction is to be meaningful.</Paragraph>
    </Section>
  </Section>
class="xml-element"></Paper>