<?xml version="1.0" standalone="yes"?>
<Paper uid="W00-1014">
  <Title>Dialogue and Domain Knowledge Management Systems in Dialogue</Title>
  <Section position="3" start_page="0" end_page="121" type="metho">
    <SectionTitle>
2 Types of requests and
clarifications
</SectionTitle>
    <Paragraph position="0"> Users interacting with a dialogue system utilise various communicative acts. Bunt (1989) makes a distinction between factual information acts and dialogue control acts. The latter is used to control the dialogue and the former involves any transfer of factual information. Factual information requests can be further divided into two basic types of requests: * Task related requests. Requests where the response from the dialogue system includes domain and task specific information * System related requests. Requests where the response includes information on what can be done with the system or pointers to other information sources To be able to respond to questions on the system's capabilities and how to interpret the provided information, the dialogue system needs to represent knowledge about itself, here called system information. Also, if an answer can not be found in the application system(s) the dialogue system should give as helpful information as possible, for example suggesting other resources the user can consult. For this purpose knowledge is needed on where such information can be found.</Paragraph>
    <Paragraph position="1"> The requests for task related information can be divided into simple and complex requests. Simple requests are basically requests for information  logue model, domain task model, system task model, and various knowledge modules, are also depicted, but not the grammar and lexicon.</Paragraph>
    <Paragraph position="2"> concerning properties of and relations between simple objects, for which the answers can be values of properties or names of objects. A simple object is typically an entity that can be identified by a name or a set of distinguishing features. Simple requests can be specified by an arbitrary set of parameters. The parameters describe certain properties which constraints the search for an object, or the requested properties of an object or set of objects. A typical example of a simple request is How fast is a Volvo 850?, which can be directly mapped onto a structure specifying that the requested object is 'Volvo 850' and the prop-erty requested is its 'speed', which in turn can be converted to an application system request.</Paragraph>
    <Paragraph position="3"> Complex requests on the other hand are concerned with the specification and construction of compound objects. The specification of such an object requires that the user provides information on a specific set of parameters, which often involves several dialogue turns. The specification is used to construct a matching object by retrieving, and sometimes integrating, knowledge from one or several domain and application knowledge sources. Examples of complex requests are found in timetable information applications, such as the ATIS dialogues. To answer requests on a trip, the system needs to have a number of parameters specified, such as departure and arrival time and place, before it is able to access the timetables. However, for such systems there are also simple requests that can be directly mapped to a request from the background system, for instance, requests regarding meals on a flight that can be identified by a flight number, e.g. Is breakfast served on flight SK2818f.</Paragraph>
    <Paragraph position="4"> Since requests are specified by a set of entities the system needs capabilities to identify entities from descriptions (Hayes and Reddy, 1983). An attempt to map a description to an entity can have three different outcomes, a unique entity is found, the description is ambiguous and corresponds to several objects, or the description is unsatisfiable and no matching object can be found. There exist several strategies to deal with these problems, but all of them include some clarification from the user or domain reasoning. In dealing with ambiguous descriptions the system should be able to provide options or find a distinguishing feature that can be used to ask the user for clarification. Unsatisfiable descriptions can be dealt with in three different ways: inform the user of the problem giving as helpful information as possible, find near misses by relaxing some of the features in thedescription, or find and inform the user of faulty presuppositions. null</Paragraph>
  </Section>
  <Section position="4" start_page="121" end_page="123" type="metho">
    <SectionTitle>
3 Dialogue system architectures
</SectionTitle>
    <Paragraph position="0"> Dialogue systems often have a modular archio tecture with processing modules for interpretation, dialogue management, background system access, and generation, see figure 1. The processing modules utilise a number of knowledge sources, such as, grammar, lexicon, dialogue mod- null el, domain model, and task model (for an overview of some systems, see Flycht-Eriksson (1999)). In this paper focus is on dialogue management and domain knowledge management, which includes background system access.</Paragraph>
    <Section position="1" start_page="122" end_page="122" type="sub_section">
      <SectionTitle>
3.1 Dialogue management
</SectionTitle>
      <Paragraph position="0"> The role of the Dialogue Manager differs slightly between different dialogue system architectures, but it's primary responsibility is to control the flow of the dialogue by deciding how the system should respond to a user utterance. This is done by inspecting and contextually specifying the information structure produced by an interpretation module. If some information is missing or a request is ambiguous, clarification questions are specified by the Dialogue Manager and posed to the user. Should a request be fully specified and unambiguous the background system can be accessed and an answer be produced. As a basis for these tasks the Dialogue Manager can utilise a dialogue model, a task model, and a dialogue history.</Paragraph>
      <Paragraph position="1"> The Dialogue model holds a generic description of how the dialogue is to be constructed, i.e. to decide what action to take in a certain situation.</Paragraph>
      <Paragraph position="2"> It is used to control the interaction, which involves determining: 1) what the system should do next (and what module is responsible for carrying out the task) and 2) deciding what communicative action is appropriate at a given dialogue state. There are various proposals on dialogue models which can be divided in two groups: intention-based and structurally based. They differ in how they model the dialogue, especially if the user's goals and intentions behind the utterance need to be captured or not. Structurally based models are often controlled using a dialogue grammar whereas intention-based utilise plan operators. Furthermore, plan-based systems use plan operators to model not only dialogue knowledge but also task, domain and meta knowledge (c.f. Lambert and Carberry (1991), Ramshaw (1991), Ferguson et al. (1996)). This allows for plan recognition to be the only processing mechanism needed.</Paragraph>
      <Paragraph position="3"> The System Task model represents how the system's tasks are performed, cf. Application Description (Hagen, 1999). However, the terms task and task model can refer to very different phenomena. It is important to make a clear distinction between the system's task(s) and the user's task(s) (van Loo and Bego, 1993; Dahlb~ck and JSnsson, 1999). A user task is non-linguistic and takes place in the real world. Models of such tasks involve the user's goals and how they can be achieved (cf. Wahlster and Kobsa (1989)). Models of system tasks describe how the system's communicative and other tasks, e.g. database access, are carried out.</Paragraph>
      <Paragraph position="4"> A typical example of the difference between the two types of task models can be found in a time-table system where the user states that (s)he needs to be at the train station to catch a certain train and requests information on buses going there. The information that the user is going to the train station is user task model information, indicating that buses arriving after the departure thne of the train are not relevant. The system task model on the other hand models the information required for complex requests, such as date and departure place in a time-table system (cf. Bennacef et al. (1996)). It is used by the Dialogue Manager when collecting user information in order to perform a background system access.</Paragraph>
      <Paragraph position="5"> In plan-based systems the domain models takes a similar role, but wider as they often also involves advanced problem solving. We will in this paper not consider user task models, only system task models.</Paragraph>
      <Paragraph position="6"> The Dialogue history records the focus of attention (Grosz and Sidner, 1986) and contains information about objects, properties, and relations as well as other dialogue information such as speech act information and system task information.</Paragraph>
    </Section>
    <Section position="2" start_page="122" end_page="123" type="sub_section">
      <SectionTitle>
3.2 Domain Knowledge Management
</SectionTitle>
      <Paragraph position="0"> If a request is fully specified it can be used to retrieve the desired information from a background system. This task is seldom discussed in literature on dialogue systems, perhaps because it is considered a rather straight forward task. There are, however, several problems related to this. For example, in cases where the background system is distributed and consists of several domain and application system knowledge sources the dialogue system must know which of them to access, in what order, and how the results should be integrated into one answer. This type of knowledge can be represented in a domain task model.</Paragraph>
      <Paragraph position="1"> Other problems related to domain knowledge reasoning and application access where mentioned in section 2. Although fully specified, requests can contain vague or ambiguous information or even some errors that can not be detected and handied without extensive domain knowledge. This type of domain knowledge is stored in domain knowledge sources, called knowledge modules in figure 1. They contain knowledge of the world that is talked about and can vary much in form and content. Information from a domain knowledge source is primarily used to find the relevant  information. The dialogue model used is a dialogue gr~.mrnar, the dialogue history is modelled as a dialogue tree, and Information Specification Forms correspond to the system task model. The domain and application knowledge modules perform spatial and temporal reasoning, and provide time-table and system information controlled by recipes and integration rules. items and relations that are discussed, to supply default values, etc. The knowledge represented in a domain knowledge source is often coupled to the application system, e.g. a database system.</Paragraph>
      <Paragraph position="2"> In such cases it is often used to map information from a Dialogue Manager to concepts suitable for database search. It is for example common that user's give vague temporal descriptions that has to be mapped to more precise time intervals before the information can be used to access an application system.</Paragraph>
      <Paragraph position="3"> To develop a Dialogue Manager that easily can be cnstomi~ed to new domains and in which different dialogue strategies can be explored, the Dialogue Manager should only be concerned with phenomena related to the dialogue with the user.</Paragraph>
      <Paragraph position="4"> It should not be involved in the process of accessing the background system or performing domain reasoning. These tasks should instead be carried out by a separate module, a Domain Knowledge Manager.</Paragraph>
      <Paragraph position="5"> The Domain Knowledge Manager is responsible for retrieving and coordinating knowledge from the different domain knowledge sources and application systems that constitutes the background system. The Dialogue Manager can deliver a request to the Domain Knowledge Manager and in return expects an answer retrieved from the background system. If a request is under-specified or contains inconsistencies from the Domain Knowledge Manager's point of view, a specification of what clarifying information is needed will instead be returned to the Dialogue Manager.</Paragraph>
    </Section>
  </Section>
class="xml-element"></Paper>