<?xml version="1.0" standalone="yes"?>
<Paper uid="W97-0604">
  <Title>An Object-Oriented Model for the Design of Cross-Domain Dialogue Systems</Title>
  <Section position="3" start_page="25" end_page="25" type="metho">
    <SectionTitle>
2 Dialogue Manager
* The Dialogue Manager is responsible for the
</SectionTitle>
    <Paragraph position="0"> overall control of interaction between the system and the user, and between the main system subcomponents - which in broad terms include Corns facilities, Generate Speech facilities, the enquiry processing objects, and the system Database.</Paragraph>
    <Paragraph position="1"> * The Dialogue Manager is responsible for selecting the current Dialogue Intention, of which there are several subclasses. By default the Dialogue Manager pursues a sequence of dialogue intentions that is typical of the majority of dialogue domains: the system greets the user; determines the nature of the user's enquiry; gathers the data necessary for the successful answering of the enquiry; handles any (database) transactions associated with the enquiry; checks if the user has any further enquiries; and concludes the dialogue.</Paragraph>
    <Paragraph position="2"> * It uses system resources to identify and respond appropriately to user interruptions.</Paragraph>
    <Section position="1" start_page="25" end_page="25" type="sub_section">
      <SectionTitle>
Dialogue Intention
</SectionTitle>
      <Paragraph position="0"> Dialogue Intention embodies generic functionality for the furtherance of a dialogue.</Paragraph>
      <Paragraph position="1"> * Dialogue Flow. The Dialogue Intention class encapsulates a variety of approaches to phrasing, rephrasing and personalising system utterances, with the aim of handling (in as natural a manner as possible) communication errors and processing delays.</Paragraph>
      <Paragraph position="2"> * Use of Expertise/Skills. Dialogue Intentions may themselves encapsulate heuristics that allow them to instantiate a Dialogue Model (and by extension the associated Dialogue Objects, Discourse States and Request Templates) for relatively high-level processing tasks (Greet, Find Enquiry Type, for example). However, most Dialogue Intentions make use of the Skill and Domain Expert classes, whose heuristics permit rather more specialised enquiries involving either generic but complex skillsets (working with colours or gathering address information, for example) or specialised application domains  (organising travel itineraries, or booking theatre tickets, for example). Again these skills and expertise subclasses provide the Dialogue Intention subclass with the necessary heuristics to instantiate a Dialogue Model.</Paragraph>
      <Paragraph position="3"> Find Enquiry Type The Find Enquiry Type class (a subclass of Dialogue Intention) allows the Dialogue Manager, both to prompt the user into specifying the nature of his/her inquiry, and to interpret the nature of a user's utterance when it receives an indication that the user has spoken unprompted. null The Find Enquiry Type class uses a Domain Spotter class to identify the Domain Expert that is best suited to handling the enquiry.</Paragraph>
      <Paragraph position="4"> An appropriate Domain Expert is confirmed through the elaboration of an appropriate Dialogue Model. The Dialogue Manager supplies the Handle Enquiry dialogue intention with details of the selected Domain Expert.</Paragraph>
    </Section>
  </Section>
  <Section position="4" start_page="25" end_page="25" type="metho">
    <SectionTitle>
Domain Expert
* Each Domain Expert class, regardless of the
</SectionTitle>
    <Paragraph position="0"> specific domain its subclass addresses, typically provides the following functionality:  1. Request template structure for the domain; 2. Enquiry processing algorithms for the do- null main (typically IF...THEN...ELSE constructs), including recommended use of any Skills Expert, for specialised but non-domain-specific processing (e.g. handling colours, times, etc.) 3. Word combinations (bigrams or trigrams) from the domain to extend the generic capabilities of the Recogniser Grammar.  terpretations of user utterances in the light of specialist knowledge brought to bear by the appropriate Domain Expert); the Discourse State (which records the current status - confirmed, assumed, etc. - of the parameters that apply to the Dialogue Objects) and the Request Template (which when fully populated is used by the Handle Transaction class - a database driver to make a database access).</Paragraph>
    <Paragraph position="1"> The Dialogue Model evolves in a manner similar to that outlined by (McGlashan, 1996). Confirmation strategies are tailored to the particular operating environment and the specialised domain. They are recorded in the Dialogue Intention class, or in the relevant Domain Expert subclass.</Paragraph>
  </Section>
class="xml-element"></Paper>