<?xml version="1.0" standalone="yes"?>
<Paper uid="W04-2325">
  <Title>Causes and Strategies for Requesting Clarification in Dialogue</Title>
  <Section position="2" start_page="0" end_page="0" type="intro">
    <SectionTitle>
1 Introduction
</SectionTitle>
    <Paragraph position="0"> It is widely accepted that it would be desirable for dialogue systems to be able to produce and understand the whole range of Clarification Requests (CRs) that can be found in human-human dialogue, as exemplified in the following:  (1) a. A: I talked to Mary-Ann Parker-Tomlison. B: Parker-WHO? b. A: Well, I've seen him.</Paragraph>
    <Paragraph position="1"> B: Sorry, you have or you haven't? c. A: Did you talk to Peter? B: Peter Miller? d. A: Did you bring a 3-5 torx?  B: What's that? A precondition for fulfilling this desideratum is a detailed analysis of the communication problems that lead to the need for clarification. As we show in this paper, extant approaches to CR do not satisfy this precondition. We propose that a good starting-point for developing a more general analysis is a multi-levelled model of communication along the lines of (Clark, 1996) and (Allwood, 1995), distinguishing (among other things) between acoustic understanding and semantic understanding.1 We explore such a model from the perspective of generating and interpreting CRs, making the central concepts of the model precise by relating it to an independently motivated model of discourse semantics called SDRT (Asher and Lascarides, 2003).</Paragraph>
    <Paragraph position="2"> Deciding on whether to produce CRs is part of the Confirmation Strategy (CS) of a dialogue system (cf. (San-Segundo et al., 2001), inter alia). An explicit confirmation of an understanding can be sought via a CR, whereas implicit confirmation can be sought by displaying the system's understanding: (2) a. Explicit confirmation: &amp;quot;Did you say you want to leave from Potsdam?&amp;quot; b. Implicit confirmation: &amp;quot;From Potsdam. To where?&amp;quot; Current dialogue systems base their decision on the CS to follow only on their confidence in the speech recognition results. It would be desirable, however, if they could clarify or confirm other hypotheses as well, for example about reference resolution, depending on their confidence 1Several recent papers (Gabsdil, 2003; Larsson, 2003) have followed a similar approach, but with a somewhat narrower focus. (Gabsdil, 2003) is mostly concerned with CRs reacting to speech recognition, while (Larsson, 2003) offers a similar, but less fine-grained classification and deals more with integrating CRs into a specific kind of dialogue management strategy. in that resolution:  (3) User: Send the file to Peter.</Paragraph>
    <Paragraph position="3"> System a: Do you mean Peter Miller? System b: Will send the file to Peter Miller. Any null thing else? Moreover, confidences on different levels of processing should be allowed to interact. In a situation where the speech recogniser cannot decide between the hypotheses &amp;quot;Sandy&amp;quot; and &amp;quot;Andy&amp;quot; for a certain input, but where the former proper name can be resolved to a more salient discourse referent than the latter, a dialogue system should ideally prefer the former hypothesis and choose implicit confirmation (variant A below), rather than explicitly clarifying which alternative to choose (variant B):  (4) User: Send the file to {Sandy  |Andy}.</Paragraph>
    <Paragraph position="4"> Sys a: To Sandy, OK.</Paragraph>
    <Paragraph position="5"> Sys b: Did you say Sandy or Andy?  The remainder of the paper is organised as follows. After presenting an initial classification of CRs and discussing extant approaches in the next section, we propose in Section 3 a model of causes for requesting clarification. Building on this theoretical model we turn in Section 4 to extending the concept of confidence in a hypothesis in order to produce the CS behaviour sketched above. We also discuss initial findings from an experimental implementation of this idea.</Paragraph>
  </Section>
class="xml-element"></Paper>