<?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="2" start_page="0" end_page="25" type="intro">
    <SectionTitle>
1 Introduction
</SectionTitle>
    <Paragraph position="0"> The system we propose addresses two key issues that face developers of speech-based natural language dialogue systems. Firstly, how can developers exploit the commonality that exists between different application domains - to make the development task easier on the one hand, and on the other hand to make systems as computationally efficient and as functionally wide-ranging as possible? Secondly, given the current inaccuracies of speech recognition, how can developers implement domain independent strategies for limiting the damage caused by misrecognition, while at the same time mainraining an apparently natural conversational flow between system and user? An object-oriented development paradigm offers valuable insights into how these challenges might be addressed. In this respect the current approach builds on previous work involving an object-oriented approach to dialogue management (Sparks, Meiskey &amp; Brunner, 1994), in which the main system components might be regarded as forming a developer's toolkit. We envisage system components that draw on the strength of an object-oriented architecture. Inheritance and association relationships will be used to ensure that generic functionality which can be shared by more specialised system components need be defined only once and can be introduced into the dialogue flow, in real time, as and when required.</Paragraph>
    <Paragraph position="1"> Based on the notion of an evolving, multi-layered dialogue model (McGlashan, 1996), our system design includes a number of dialogue model classes (collectively the Dialogue Model) whose role it is to record each concept (a booking request, for example) as it is identified; to monitor and guide the process by which concept's attributes (destination, departure time, etc.) are confirmed or assumed; and to populate a request template that will ultimately be used in database accesses.</Paragraph>
    <Paragraph position="2"> Central to our project is a notion of discrete, re-usable system components, some of which are intended to work collaboratively in software mechanisms, some to provide generic functionality that can be tailored or augmented to suit particular applications. Identifying and exploiting areas of commonality and specialisation between different processing  domains promises rich rewards. We have been inspired to some extent by the premise that everyday, person-to-person dialogues (whether it is a booking clerk at a theatre responding to a customer's enquiries, or a teacher helping a pupil with a mathematics problem) are in some sense 'scripted'. Previous experience of a situation, or explicit tutoring in a particular task, means that real-life dialogues often consist of elements that have been rehearsed, and are therefore predictable. However, as in natural human speech, the system must recognise and accommodate spontaneous shifts from one script to another, and be able to cope with changes in the detailed content and structure of a script in different circumstances.</Paragraph>
    <Paragraph position="3"> To make three broad distinctions, one may view these 'set pieces' as occurring at a meta-level, a domain level and a skill level - and these levels are reflected in the system architecture we are evolving.</Paragraph>
    <Paragraph position="4"> At a meta-level, for example, people tend to recognise cues for taking, relinquishing or continuing a dialogue turn; at a domain level, someone wanting to reserve a ticket for a show broadly knows the sorts of questions they can ask at the theatre booking office and the sorts of answer they are likely to receive; at a skill level, people generally know how to do conversions between dates on the one hand and days of the week or duration on the other. We have endeavoured to identify some of these set pieces at their different dialogue levels, with a view to creating classes that encapsulate the meta-dialogue behaviour that is common to the great majority of interactions (and which is represented in our generic Dialogue Intention class), the business domain expertise that in human terms distinguishes professionals in one field from those in another (our Business Expert classes), and the individual skills like handling dates and numbers, that are used in many different business domains (our Skill Expert classes). In general terms, adherence to best practice in object-oriented development offers the prospect of systems that can be readily extended and customised, in building block fashion. More significantly, though, it is our intention to use our suite of classes in implementations that support highly complex interactions with the user: a single dialogue may range over several business domains, each of which may use several distinct skill sets. The system has the intelligence to decide, in real time, which business expertise and which skillsets are required to pursue the user's enquiries, and calls upon the services of the appropriate coded objects.</Paragraph>
    <Paragraph position="5"> To give a flavour of our system's architecture, we include outline descriptions of some of its most important classes: Dialogue Manager; Dialogue Intention; Find Enquiry Type; and Domain Expert. The preliminary class relationship model (see Figure 1) further sets these classes in context - the model uses a simplified version of the Booch notation (Booch, 1994).</Paragraph>
  </Section>
class="xml-element"></Paper>