<?xml version="1.0" standalone="yes"?>
<Paper uid="W00-1014">
  <Title>Dialogue and Domain Knowledge Management Systems in Dialogue</Title>
  <Section position="5" start_page="123" end_page="128" type="evalu">
    <SectionTitle>
4 MALIN
</SectionTitle>
    <Paragraph position="0"> In what follows we describe and exemplify a dialogue system with separate modules for dialogue management and domain knowledge management. The presentation will be based on the MALIN dialogue system architecture:, figure 2, which has been used to implement an application for time-table information for local bus traffic in ostergStland.</Paragraph>
    <Paragraph position="1"> One issue in the design of a dialogue system is how to control the various modules and the user interaction. In some systems there is no module responsible for the communication, instead a separate module, called hub (Aberdeen et al., 1999) or facilitator (Martin et al., 1999), is used for co-ordinating the modules and the internal information flow. Alternatively, the Dialogue Manager is the central unit of the system where the overall system behaviour is determined.</Paragraph>
    <Paragraph position="2"> The approach taken in MALIN is a combination where a Dialogue Manager is the central controller of the interaction and the Domain Knowledge Manager is based on an agent architecture. XMALIN (Multi-modal Application of LINLIN) is a refinement of the LINLINsystem (Ahrenberg et al., 1990; JSnsson, 1997) to handle also multi-modal interaction and more advanced applications.</Paragraph>
    <Section position="1" start_page="124" end_page="124" type="sub_section">
      <SectionTitle>
4.1 The Dialogue Manager
</SectionTitle>
      <Paragraph position="0"> In the MALIN dialogue model the dialogue is structured in terms of discourse segments, and a discourse segment in terms of moves and embedded segments. Utterances are analysed as linguistic objects which function as vehicles for atomic move segments. An initiative-response (IR) structure determines the compound discourse segments, where an initiative opens the IR-segment by introducing a new goal and the response closes the IR-segment (Dahlb~ck, 1991). The discourse segments are classified by general speech act categories, such as question (Q) and answer (A) (JSnsson, 1997), rather than specialised (cf. (Hagen, 1999)), or domain related (Alexandersson and Reithinger, 1995). The action to carry out for the Dialogue Manager, as modeled in a dialogue grammar, depends on how domain entities are specified and their relation to other entities in the domain and the dialogue history.</Paragraph>
      <Paragraph position="1"> In the MALIN dialogue system architecture there is only One dialogue history maintained by the Dialogue Manager. Thus, the other modules in the system have no memory of the previous interaction since this could cause conflicts. The dialogue history records focal information, that is, what has been talked about and what is being talked about at the moment. It is used for dialogue control, disambiguation of context dependent utterances, and context sensitive interpretation. The dialogue history is represented as a dialogue tree.</Paragraph>
      <Paragraph position="2"> The nodes in the dialogue tree record information utilising various information structures depending on the application.</Paragraph>
      <Paragraph position="3"> For simple information requests we have identified two important concepts, termed Objects and Properties (JSnsson, 1997) where Objects models the set of objects in the database and Properties denotes a complex predicate ascribed to this set. The parameters Objects and Properties axe application dependent. We also utilise Markers for various purposes (J5nsson and StrSmb~ck, 1998), but they will not be further discussed in this paper. Structures that represent information about objects and properties (and markers) are termed OPMs. Figure 3 shows an example OPM which represents the request Which bus lines passes the North gate ?.</Paragraph>
      <Paragraph position="4"> For complex requests the Dialogue Manager needs an information structure that holds the parameters needed before successful access of the background system can be performed. We call such structures Information Specification Forms (ISFs) (Dahlb~ck and JSnsson, 1999). Just like OPMs the ISFs are application dependent and be- null lines passes the North gate?.</Paragraph>
      <Paragraph position="5"> sides holding information they are also used as system task models, i.e. to inform the Dialogue Manager which parameters that has to be provided by the user. We have identified a number of different user information needs (Qvarfordt, 1998) for which ISFs are needed. The most common, called trip information, occurs when the user needs to know how and when on a particular day, most often the present day, one can travel from one point to another in town by bus. An ISF for such requests model information on departure and arrival destinations and information on arrival and/or departure time, which is required information. The user can also give information about the travel type, but this is optional. Figure 4 shows an emp- null Another common information need, called route information, is when the caller wants information on which busses or trains that go from one point to another. This ISF is similar to the Trip ISF but time information is no longer required.</Paragraph>
      <Paragraph position="6"> For the time-table information application both structures, ISF and OPM, are needed. This is not the case for all types of applications but we believe that if an ISF is needed an OPM can also often be useful.</Paragraph>
    </Section>
    <Section position="2" start_page="124" end_page="125" type="sub_section">
      <SectionTitle>
4.2 The Dom~;~ Knowledge Manager
</SectionTitle>
      <Paragraph position="0"> The domain knowledge sources and application systems in MALIN are implemented as agents and will from now on be called domain agents. Domain agents provide different services, typically to retrieve and reason about some information given some parameters, and can also request services from each other. Communication and cooperation among the agents are achieved by passing messages. null  UI: I want to go to the city cem;er.</Paragraph>
      <Paragraph position="1"> $2: The city center is a big area. Can you point in the map or give more specific information like a landmark or a street? U3: Are there any bus stops near the Garden square? $4: There are several bus stops near the Garden square. &lt; Shows the bus stops in ti~e map &gt; U5: Then I want to go there from the University. $6: When do you want to go? UT: On the 31st of April before lunch.</Paragraph>
      <Paragraph position="2"> $8: The 31st is not a valid date:, there are only 30 days in April. Give a new date please. U9: The 30th of April.</Paragraph>
      <Paragraph position="3"> S10: The alternative trips are shown in the table. &lt; Shows a table of trips &gt;  application. The dialogue is constructed based on a corpus of 43 dialogues collected with users of the current information service in order to illustrate some of the features of the dialogue and domain knowledge managers and our multi-modal system.</Paragraph>
      <Paragraph position="4"> In the application of MALIN &amp;quot;tO time-table information, four different domain agents are used, see figure 2. The Temporal Reasoning Agent contain~ a calendar and reasons about temporal expressions. The Spatial Reasoning Agent utilises a Geographical Information System and reasoning mechanism used to deduce the relations between geographical objects (Flycht-Eriksson and JSnsson, 1998). The Timetable Agent retrieves time-table information for local bus and train traffic from an Internet source. There is also a System Information Agent which provides system information like references to human operators for questions outside the scope of thne-table information. null The processing of a request performed by the Domain Knowledge Manager is based on a knowledge structure called recipe. A recipe is application specific and consists of a series of service calls from different agents, which are executed in order to construct an answer to a specific request, see figure 5 for an example. Domain Knowledge Management in general involves three steps. First the Domain Knowledge Manager has to decide how to treat the request, i.e. to produce one or more recipes. In most cases one recipe is enough, but sometimes the user has provided ambiguous information that cannot be resolved by the interpreter or the Dialogue Manager, in which cases several recipes are needed. The next step is to process the recipe(s). The processing must be carefully monitored and aborted if an error occurs. Finally, alternatives must be inspected and integrated into one answer that can be sent back to the Dialogue Manager. For more details on the Domain Knowledge Manager, see Flycht-Eriksson (2000).</Paragraph>
    </Section>
    <Section position="3" start_page="125" end_page="128" type="sub_section">
      <SectionTitle>
4.3 Communication between DM and
DKM
</SectionTitle>
      <Paragraph position="0"> To illustrate how the Dialogue Manager (DM) and the Domain Knowledge Manager (DKM) cooperates in processing of requests and handling of clarifications, consider the hypothetical dialogue shown in figure 6. The dialogue tree in figure 7 shows the resulting structure of the dialogue.</Paragraph>
      <Paragraph position="1"> The first utterance, U1, initiates a trip ISF. Information about the arrival location provided by the user is inserted in the ISF in the field Art,</Paragraph>
      <Paragraph position="3"> which results in the structure presented in figure 8 included in IR1 in the dialogue tree. The ISF indicates that information about the departure place and time has to be further specified by the user by the marker req in the fields Dep and TTime  However, before continuing the dialogue and asking the user for the information that is missing in the ISF, the DM asks the DKM to validate the provided values. This validation is performed in order to detect vague or erroneous information that might have been given by the user.</Paragraph>
      <Paragraph position="4"> The arrival location in a trip ISF will be used to find suitable bus stops that can be used to search the time-table database. The validation of the arrival location therefore means that the Spatial Reasoning Agent tries to map the location to a small set of bus stops. In this case it discovers that Area: City Centre is a too vague description since it corresponds to too many stops, in our case more than 5 stops. The DM is informed of this and is also given the information that more specific information like a point, a landmark or a street is required, figure 9. Thus, the user will not be asked to provide the value of another parameter since it would be an implicit confirmation that the arrival place is correct, instead a new IR-unit, IR2 in the dialogue tree, is created and a clarification, $2, is initiated based on the information from the DKM that indicates the problematic item, the type of problem, and a possible solution to the problem.</Paragraph>
      <Paragraph position="5">  main validation of the arrival location.</Paragraph>
      <Paragraph position="6"> Instead of answering the system's question the user takes the initiative by requesting new information, U3. This request results in a new m-unit, IR3, to be inserted in the dialogue tree as a clarification of the system's clarification in IR2, as shown in figure 7. The utterance is a simple request and the DM utilises an OPM to model this, figure 10.</Paragraph>
      <Paragraph position="7">  U3.</Paragraph>
      <Paragraph position="8"> To answer this request means reasoning about spatial relations between geographical objects.</Paragraph>
      <Paragraph position="9"> The request is therefore sent to the DKM which asks the Spatial Reasoning Agent for information. The request is successfully processed and some nearby bus stops are found and sent back to the DM utilising the structure in figure 11. The DM can then ask the generator to present them to the user, $4.</Paragraph>
      <Paragraph position="10">  OPM in IR3.</Paragraph>
      <Paragraph position="11"> The user responds to this answer by confirming his departure location, U5, and thereby responds to the request $2 of IR2. He also provides an arrival location. This new information is represented in the OPM of IR2, figure 12.</Paragraph>
      <Paragraph position="12">  U5.</Paragraph>
      <Paragraph position="13"> The DM resumes processing of the ISF in IR1 and updates it with the arrival and departure loca-tion based on the information in the OPM of IR2. Information about the arrival location is added to the previously provided information in the field Art. The new information about the departure location is inserted in the field Dep, yielding the structure in figure 13.</Paragraph>
      <Paragraph position="14">  formation from the subtree in IR2.</Paragraph>
      <Paragraph position="15"> Again the DM asks the DKM for domain validation of the partially specified ISF. Since both locations can be mapped to a limited number of bus stops the ISF is approved by the DKM. The DM now needs to have a time to complete the ISF, and consequently a new IR-unit, IR4 in the dialogue tree, is created and the user is, in utterance $6, asked for this. The answer U7 is a valid response to $6 and produces a new OPM, see figure 14.</Paragraph>
      <Paragraph position="16">  formation from IR4.</Paragraph>
      <Paragraph position="17"> The ISF is again sent to the DKM for validation. When the Temporal Reasoning Agent tries to map the temporal description in TTime to a format suitable for time-table database search it discovers the erroneous date. The DKM then returns a response, figure 16, to the DM informing it of the error. The DM initiates a new clarification IR-unit, IR5, and a clarification is formulated, $8.  domain validation of the time description.</Paragraph>
      <Paragraph position="18"> The user responds to the system's clarification request and provides a new date, ug. The response is modelled in an OPM in IR5, figure 17.  The information in the clarification request IRunit, IR5, is propagated to the ISF of IR1 which is updated. This time the new information replaces the old in -VTime since it was erroneous. The resulting ISF is presented in figure 18.</Paragraph>
      <Paragraph position="19">  the information in IR5.</Paragraph>
      <Paragraph position="20"> Once more a validation of the ISF is performed by the DKM. This time no problems are detected and a search for suitable trips can fmaUy be done. The DKM does this by first asking the Spatial Reasoning Agent to map the departure and arrival locations to two sets of bus stops, then asking the Temporal Reasoning Agent to map the vague temporal description to a precise time interval. Given this information the DKM then searches the time-table database to find one or more trips that fulfill the requirements. The resulting trips are sent back to the DM and displayed to the user, S10.</Paragraph>
    </Section>
    <Section position="4" start_page="128" end_page="128" type="sub_section">
      <SectionTitle>
4.4 Implementation
</SectionTitle>
      <Paragraph position="0"> The MALIN dialogue system customised for the traffic information application is currently under development. The Dialogue Manager from the LINLIN dialogue system architecture has been adapted to allow also ISFs and we are currently specifying the dialogue grammar and how to handle focus tracking utilising ISFs and OPMs at the same time.</Paragraph>
      <Paragraph position="1"> The Domain Knowledge Manager is functional utilising a Spatial Reasoner for one sub-area of OstergStland and a Temporal Reasoner. The Timetable Agent retrieves trip information ~om the current Internet based timetables. Recipes are developed for accessing these modules, but the System and Help Information knowledge source is not yet implemented.</Paragraph>
    </Section>
  </Section>
class="xml-element"></Paper>