<?xml version="1.0" standalone="yes"?>
<Paper uid="W00-1015">
  <Title>Flexible Speech Act Based Dialogue Management</Title>
  <Section position="5" start_page="134" end_page="136" type="metho">
    <SectionTitle>
3 Primitives in Use
</SectionTitle>
    <Paragraph position="0"> Conceptually, GEN-primitives are calculated first and then a bag of possible responses (RECprimitives). One dialogue primitive corresponds to one information unit or communicative goal,</Paragraph>
    <Paragraph position="2"> to two GEN-primitives in Dialogue 1.</Paragraph>
    <Paragraph position="3"> e.g., in an information retrieval setting: providing or requesting one piece of infi)rmation. Primitives can be used individually or combined to account for more complex dialogue. Whether and how they are combined depends on the dialogue strategies specified by the service designer. In this and the following section, we will examine several such strategies and show how the primitives are combined to achieve them.</Paragraph>
    <Section position="1" start_page="135" end_page="135" type="sub_section">
      <SectionTitle>
3.1 Question-Answer Dialogue
</SectionTitle>
      <Paragraph position="0"> In the simplest case, the service designer wants a strickt question-answer dialogue: 4  Sys: &amp;quot;Which film do you want to see?&amp;quot; req uest:Value(film) Usr: &amp;quot;The Matrix. At the Ridge.&amp;quot; Int: informValue(film= Matrix) Sys: &amp;quot;Which theatre?&amp;quot; requestValue(theatre) Usr: &amp;quot;Ridge. R I D G E.&amp;quot; Int: &amp;quot;mformValue(theatre=Ridge). ,, Sys: &amp;quot;Did you say The Ridge? requestConfi rm(theatre= Ridge) Usr: ~Yes. R I D G E.&amp;quot; Int: inform Positive(theatre= Ridge.) For this type of dialogue, only the REC-primitives representing direct answers, rejects, and withdraws are calculated. In Table 1, we present those calculated in response to the first and the third system turn. We see that, after requestValue(film), only iinformValue(film) is calculated and the pragmatic', interpreter has no chance to detect &amp;quot;At the Ridge&amp;quot; (even if synsem parsed it correctly) since there is no informExtraValue(theatre) available to map it onto. Similarly, after requescConfirm(theatre=Ridge) only informPositive(theatre=Ridge) and informNegative(theatre=Ridge) are available and &amp;quot;R I D G E&amp;quot; cannot be detected since there is no informValueABC(city) primitive present.</Paragraph>
      <Paragraph position="1"> 41n the sample dialogues, 'Sys' means system turn, 'Usr' means user turn, and 'Int' means primitives recognized and sent back to the dialogue engine from the pragmatic interpreter.</Paragraph>
      <Paragraph position="3"> to two GEN-primitives in Dialogue 2.</Paragraph>
    </Section>
    <Section position="2" start_page="135" end_page="135" type="sub_section">
      <SectionTitle>
3.2 Over-Answering
</SectionTitle>
      <Paragraph position="0"> In our experience, users frequently provide more information than explicitly asked for, thus a more flexible dialogue strategy would be to allow over-answering and Dialogue 1 could have developed as follows:  Sys: &amp;quot;Which film do you want to see?&amp;quot; requestValue(film) Usr: =Matrix. At the Ridge. R I D G E.&amp;quot; Int: informValue(film= Matrix) + informExtraValue(theatre=The Ridge) Sys: &amp;quot;Did you say The Ridge?&amp;quot; req uestConfi rrn (theatre= Ridge) Usr: &amp;quot;Yes, and I want the late show.&amp;quot; Int: informPositive(theatre=Ridge) + informExtraValue(time=9P M) In Table 2, we present the REC-primitives calculated in response to the same system turns as in Dialogue 1. In Dialogue 2, only over-answering of requestValue 0 primitives were allowed, thus &amp;quot;R I D G E&amp;quot; could still not be accounted for.</Paragraph>
    </Section>
    <Section position="3" start_page="135" end_page="136" type="sub_section">
      <SectionTitle>
3.3 Complex Mixed Initiative
</SectionTitle>
      <Paragraph position="0"> Here we consider the most complex dialogue strategy that we can currently offer: The system is able to account for complex mixed initiative dialogue (at least from a dialogue point of view), i.e., the user can requst clarifications, over-answer, change values, repeat values, correct values, spell values, and reject requests as she pleases.</Paragraph>
      <Paragraph position="1">  Sys: &amp;quot;Which ~Irn do you want to see?&amp;quot; requestValue(film) Usr: =Sorry, did you ask for the time?&amp;quot; Int: requestParam(time) Sys: =No. Which film do you want to see?&amp;quot; informNegative(time) + requestValue(film, 2)  In Table 3, we present the REC-primitives calculated in response to two system utterances.</Paragraph>
    </Section>
    <Section position="4" start_page="136" end_page="136" type="sub_section">
      <SectionTitle>
3.4 Multi-Functional Turns
</SectionTitle>
      <Paragraph position="0"> It has been argued that speech act grammars cannot be used to describe dialogue since utterances can be multi-functional or encode more than one speech act; Speech act grammars can typically be in only one state at a time, thus they cannot capture this phenomenon (Levinson, 1981). In an information retrieval setting such situations occur, for example, when users disregard the system utterance and provide unrelated information or when a recogniton mistake occured and the sytem asks for confirmation. Instead of answering yes or no, users frequently answer with the correct value, which implicitly disconfirms the previous value: Dialogue 4: Multi-Functional Utterances Sys: &amp;quot;How many tickets?&amp;quot; req uestVal ue(noOfTickets) Usr: &amp;quot;I want tickets for July 4.&amp;quot; I.ut: reject Request (noOf'l'ickets) + informExtraValue(date-~July 3) Sys: &amp;quot;Did you say July 3?&amp;quot; requestConfirm (date=July 3) Usr: &amp;quot;Tomorrow!&amp;quot; Int: informNegative(date=July 3) -t- correctValue(date=July 4) In the first utterance, the user both ignores the system utterance and provides some information.</Paragraph>
      <Paragraph position="1"> In the second one, she negated and correctd the system suggestion with a single word.</Paragraph>
      <Paragraph position="2">  to two GEN-primitives in Dialogue 3.</Paragraph>
      <Paragraph position="3"> Since we are not using the speech act grammar directly and instead interpret the speech acts into a bag of primitives, we can assign as many primitives to an utterance as necessary and are not bound by the states dictated by a grammar. This aspect of our approach becomes even more interesting when the system combines several primitives in its utterance (Section 4).</Paragraph>
    </Section>
  </Section>
  <Section position="6" start_page="136" end_page="137" type="metho">
    <SectionTitle>
4 Dialogue Strategies
</SectionTitle>
    <Paragraph position="0"> Although, the procedure outlined in Section 2.4, only shows how to calculate one primitive per system turn, the approach is, of course, not limited to this. The service designer can decide to employ mixed initiative dialogue strategies for the system utterances as well, for example, requesting or confirming several values at once or implicitly confirming values. The dialogue strategies for system utterances include choosing nodes in the application description, dealing with speech recognition results, or dealing with ambiguous data from other knowledge sources. Here we present a few examples of how the dialogue manager would combine hypotheses (for more information see (Hagen, 2001)).</Paragraph>
    <Section position="1" start_page="137" end_page="137" type="sub_section">
      <SectionTitle>
4.1 Confirmation Strategies
</SectionTitle>
      <Paragraph position="0"> We illustrate implicit and multiple confirmation, i.e., the system realizes requestValue and requestConfirm or multiple requestConfirm primitives in  For the first two utterances, the system has a recognition result for the parameter film with a low recognition score. Consequently, it calculates requestConfirm(film=Matrix/Buena Vista). Additionally, there are still open parameter nodes in the AD, thus the dialogue engine picks one (either at random or if the service designer has ordered them, the next one) and calculates a requestValue primitive, here requestValue(time).</Paragraph>
      <Paragraph position="1"> If the service designer allows implicit confirmation, the two primitives are combined and uttered together in one turn. If the service de.</Paragraph>
      <Paragraph position="2"> signer does not allow implicit confirmation, the dialogue engine continues the dialogue with the topic that has alread been introduced, i.e., re.</Paragraph>
      <Paragraph position="3"> questConfirm (film= Matrix/Buena Vista). 5 For its last utterance, the system has two recognition results with a low recognition score, thus for each one of them it calculates a requestConfirm primitive. If the service designer, allows multiple confirmations, they are combined and realized as one utterance. If not, the dialogue engine chooses requestConfirm(time=21:00), since this topic was introduces first. If topics are introduced in the same utterance, it pickes one at random.</Paragraph>
    </Section>
    <Section position="2" start_page="137" end_page="137" type="sub_section">
      <SectionTitle>
4.2 AD Based Strategies
</SectionTitle>
      <Paragraph position="0"> When requesting parameter values from the user, the system consults the application description for SThis is a conceptual account. In the implementation, the requestValue primitive would not be calcualted at all, if the service designer does not allow implicit confirmation.</Paragraph>
      <Paragraph position="1"> open nodes. If there are several open nodes, the dialogue manager can decide to keep the initiative and produce several primitives, which can be combined into one turn. If the nodes are joined with an or-relation, the text generator would translate the primitives into an utterance offering alternative ways of entering the same information.</Paragraph>
      <Paragraph position="2"> For example, &amp;quot;Please tell me the show time or early or late show.&amp;quot; (requestValue(time) + requestValue(namedTime)). If the nodes are joined with an and- or a has-a relation, the text generator would translate the primitives into an utterances requesting several different pieces of information. For example, &amp;quot;What is the name of the city and the theatre?&amp;quot; (requestValue(city) + requestValue(theatre)).</Paragraph>
      <Paragraph position="3"> As seen in the application descriptions there may be several ways of acquiring a particular value e.g., date and time in Figure 2. If a parameter value is recognized with a low score, the service designer can decide whether the system shall continue processing the original parameter or whether it shall switch to one of the alternative ones. Thus after a bad recognition of date, the system can switch strategy and request weekDay and week instead. null Which strategies to follow is decided by the service designer through a set of switches in the dialogue strategies specification file (Figure 1).</Paragraph>
    </Section>
  </Section>
  <Section position="7" start_page="137" end_page="138" type="metho">
    <SectionTitle>
5 Pragmatic Interpreter
</SectionTitle>
    <Paragraph position="0"> After synsem interpretation, the user utterance must be mapped onto dialogue primitives. A bag of REC-primitives is calculated for each user utterance and the pragmatic interpreter must assure that the utterance is mapped onto primitives in this bag. There is always a mapping. The reject and withdraw primitives are always part of the bag thus in the worst case, the user utterance would be mapped onto one of these.</Paragraph>
    <Paragraph position="1"> Since primitives in their uninstantiated form are application independent, we can develop generic rules for this mapping. In other words, the rules define how the dialogue strategies presented in Section 3 are mapped onto primitives and how we account for several primitives per utterance.</Paragraph>
    <Paragraph position="2"> A rule has the form: GEN-Primitives A user utterance =~- REC-primitives. In Table 4, we present two rules for implicit confirmation. The first one corresponds to the first sys/usr pair in Dialogue 5.</Paragraph>
    <Paragraph position="3"> The user responds with a new value vs (Buena Vista) for P2 (film) in requestConfirm(p2=v2) and thereby disconfirms v2 (Matrix) and rejects the request for a value for Pl (time) in requestValue(pl). The second rule corresponds to  primitives, p=v means that value v for param p.</Paragraph>
    <Paragraph position="4"> input onto RECthe user provided the second sys/usr pair in Dialogue 5. The user provides value vx (the late show) for Pl (time) in requestValue(pl) and thus confirms v2 (Buena Vista) in requestConfirm(p2=v2). For instantiafion of the primitives, see Dialogue 5. Here, we only presented two examples. Similar rules were developed for all our primitives and dialogue strategies (see (Hagen, 2001)).</Paragraph>
    <Paragraph position="5"> One reviewer asked whether we can modify the approach such that expectations can be overridden if there is sufficently good information from the synsem module. The short answer is that we could (re-)calcnlate the primitives pretending that the service designer allowed mixed initiative regardless of the dialogue strategies actually chosen. W~, however, think it is important to give her the right to decide. For example, if she has decided that over-answering is allowed, informExtraValue0 primitives for all parameters whose status is still open would be calculated and thus there is nothing to override. If, however, the service designer has decided that over-answering is not allowed, we assume that she had good reasons for doing that and the dialogue manager will not try to overrule this decision.</Paragraph>
  </Section>
class="xml-element"></Paper>