<?xml version="1.0" standalone="yes"?>
<Paper uid="W00-0302">
  <Title>GoDiS - An Accommodating Dialogue System</Title>
  <Section position="4" start_page="0" end_page="8" type="metho">
    <SectionTitle>
2 System Description
</SectionTitle>
    <Paragraph position="0"> The overall structure of the GoDiS system is  ules, an information state, and a number of resources hooked up to the information state.</Paragraph>
    <Paragraph position="1"> In addition to the control module, which wires together the other modules, there are six modules in * GoDiS: input, which receives input3from the user; interpret, which interprets utterances as dialogue moves with some content; generate, which generates natural language from dialogue moves; output, which produces output to the user; update, which updates the information state based on interpreted moves; and select, which selects the next move(s) to perform 4. The last two are DME roodules, which means that they together make up the  DME in GoDiS. DME modules consist of a set of update rules and (optionally) an update algorithm governing the order in which rules are applied. Update rules are rules for updating the information state. They consist of a rule name, a precondition list, and an effect list. The preconditions are conditions on the information state, and the effects are operations on the information state. If the preconditions of a rule are true for the information state, then the effects of that rule can be applied to the information state.</Paragraph>
    <Paragraph position="2"> There are three resources in GoDiS: a lexicon, a database and a domain resource containing (among other things) domain-specific dialogue plans. Currently, there are GoDiS resources for a travel agency domain andS-the autoroute domain. Also, for each of these domains there are lexicons in both English and Swedish.</Paragraph>
    <Paragraph position="3"> The question about what should be included in the information state is central to any theory of dialogue management. The notion of information state we are putting forward here is basically a simplified version of the dialogue game board which has been proposed by Ginzburg. We are attempting to use as simple a version as possible in order to have a more or less practical system to experiment with.</Paragraph>
    <Paragraph position="4"> The main division in the information state is between information which is private to the agent and that which is (assumed to be) shared between the dialogue participants. What we mean by shared information here is that which has been established (i.e. grounded) during the conversation, akin to what Lewis in (Lewis, 1979) called the &amp;quot;conversational scoreboard&amp;quot;. We represent information states of a dialogue participant as a record of the type shown in figure 1.</Paragraph>
    <Paragraph position="5"> The private part of the information state includes a set of beliefs and a dialogue plan, i.e. is a list of dialogue actions that the agent wishes to carry out. The plan can be changed during the course of the conversation. For example, if a travel agent discovers that his customer wishes to get information about a flight he will adopt a plan to ask her where she wants to go, when she wants to go, what price class she wants and so on. The agenda, on the other hand, contains the short term goals or obligations that the agent has, i.e. what the agent is going to do next. For example, if the other dialogue participant raises a question, then the agent will normally put an action on the agenda to respond to the question.</Paragraph>
    <Paragraph position="6"> This action may or may not be in the agent's plan.</Paragraph>
    <Paragraph position="7"> The private part of the IS also includes &amp;quot;temporary&amp;quot; shared information that saves the previously shared information until the latest utterance is grounded, i.e. confirmed as having been understood  by the other dialogue participant 5. In this way it is easy to retract the &amp;quot;optimistic&amp;quot; assumption that the information was understood if it should turn out that the other dialogue participant does not understand or accept it. If the agent pursues a cautious rather than an optimistic strategy then information will at first only be placed in the &amp;quot;temporary&amp;quot; slot until it has been acknowledged by the other dialogue participant whereupon it can be moved to the appropriate shared field.</Paragraph>
    <Paragraph position="8"> The (supposedly) shared part of the IS consists of three subparts. One is a set of propositions which the agent assumes for the sake of the conversation and which are established during the dialogue. The second is a stack of questions under discussion (QUD). These are questions that have been raised and are currently under discussion in the dialogue.</Paragraph>
    <Paragraph position="9"> The third contains information about the latest utterance (speaker, moves and integration status).</Paragraph>
  </Section>
  <Section position="5" start_page="8" end_page="8" type="metho">
    <SectionTitle>
3 Accommodation in GoDiS
</SectionTitle>
    <Paragraph position="0"> Dialogue participants can address questions that have not been explicitly raised in the dialogue. However, it is important that a question be available to the agent who is to interpret it because the utterance may be elliptical. Here is an example from a travel agency dialogue6: $J: what month do you want to go SP: well around 3rd 4th april / some time there SP: as cheap as possible The strategy we adopt for interpreting elliptical utterances is to think of them as short answers (in the sense of Ginzburg (Ginzburg, 1998)) to questions on QUD. A suitable question here is What kind of price does P want for the ticket?. This question is not under discussion at the point when P says &amp;quot;as cheap as possible&amp;quot;. But it can be figured out since J knows that this is a relevant question. In fact it will be a question which J has as an action in his plan to raise. On our analysis it is this fact which enables A to interpret the ellipsis. He finds the matching question on his plan, accommodates by placing it on QUD and then continues with the integration of the information expressed by as cheap as possible as normal. Note that if such a question is * not available then the ellipsis cannot be interpreted as in the dialogue below.</Paragraph>
    <Paragraph position="1"> A. What time are you coming to pick up Maria? B. Around 6 p.m. As cheap as possible.</Paragraph>
    <Paragraph position="3"> This dialogue is incoherent if what is being discussed is when the child Maria is going to be picked up from her friend's house (at least under standard dialogue plans-that we might have for such a conversation). null Question accommodation has been implemented in GoDiS using a single information state update rule accommodateQuestion, seen below. When interpreting the latest utterance by the other participant, the system makes the assumption that it was a reply move with content A. This assumption requires accommodating some question Q such that A is a relevant answer to Q. The check operator &amp;quot;answer-to(A, Q)&amp;quot; is true if A is a relevant answer to Q given the current information state, according to a (domain-dependent) definition of question-answer relevance.</Paragraph>
    <Paragraph position="4"> RULE: accommodateQuestion CLASS: accommodate val(</Paragraph>
    <Paragraph position="6"> After an initial exchange for establishing contact the first thing that P says to the travel agent in our dialogue is &amp;quot;flights to paris&amp;quot;. This is again an ellipsis which on our analysis has to be interpreted as the answer to a question (two questions, actually) in order to be understandable and relevant. As no questions have been raised yet in the dialogue (apart from whether the participants have each other's attention) the travel agent cannot find the appropriate question on his plan. Furthermore, as this is the first indication of what the customer wants, the travel agent cannot have a plan with detailed questions.</Paragraph>
    <Paragraph position="7"> We assume that the travel agent has various plan types in his domain knowledge determining what kind of conversations he is able to have. Each plan is associated with a task. E.g. he is able to book trips by various modes of travel, he is able to handle complaints, book hotels, rental cars etc. What he needs to do is take the customer's utterance and try to match it against questions in his plan types in his domain knowledge. When he finds a suitable match he will accommodate the corresponding task, thereby providing a plan to ask relevant question for flights, e.g. when to travel?, what date? etc.</Paragraph>
    <Paragraph position="8"> Once he has accommodated this task and retrieved the plan he can proceed as in the previous example.</Paragraph>
    <Paragraph position="9"> That is, he can accommodate the; QUD with the relevant question and proceed with the interpretation of ellipsis in the normal fashion.</Paragraph>
    <Paragraph position="10"> This example is interesting for a couple of reasons.</Paragraph>
    <Paragraph position="11"> It provides us with an example of &amp;quot;recursive&amp;quot; accommodation. The QUD needs to be accommodated, but in order to do this the dialogue task needs to be accommodated and the plan retrieved. The other interesting aspect of this is that accommodating the dialogue task in this way actually serves to drive the dialogue forward. That is, the mechanism by which the agent interprets this ellipsis, gives him a plan for a substantial part of the rest of the dialogue. This is a way of capturing the intuition that saying flights to Paris to a travel agent immediately makes a number of questions become relevant.</Paragraph>
    <Paragraph position="12"> Task accommodation and retrieval of the relevant plan has been implemented in GoDiS by two information state update rules.</Paragraph>
  </Section>
  <Section position="6" start_page="8" end_page="8" type="metho">
    <SectionTitle>
4 Sample dialogues
</SectionTitle>
    <Paragraph position="0"> We will give some examples of CoDiS dialogues in the English travel agency domain. One of the features of the TRINDIKIT is that it provides methods for inspecting the information state at any stage of a dialogue, and also to see which rules are applied.</Paragraph>
    <Paragraph position="1"> Unfortunately, because of space limitations, we are not able to include examples of this in this paper; however, it is an integral part of our demo.</Paragraph>
    <Paragraph position="2"> The first dialogue shows the typical behaviour of dialogue systems for information-seeking: each question is answered in turn, and the user always gives exactly the information requested.</Paragraph>
    <Paragraph position="3"> $S&gt; Welcome to the travel agency!  SU&gt; thanks-, bye! $S&gt; Thank you for your visit! In contrast, the second dialogue (below) shows how GoDiS is able to accommodate the task and integrate information in the order that the user gives it.</Paragraph>
    <Paragraph position="4"> $S&gt; Welcome to the travel agency! $U&gt; flights to paris $S&gt; What city do you want to go from? $U&gt; gothenburg, in april, as cheap as</Paragraph>
  </Section>
class="xml-element"></Paper>