<?xml version="1.0" standalone="yes"?>
<Paper uid="A00-2001">
  <Title>and Discourse Obligations Using Update Rules</Title>
  <Section position="4" start_page="0" end_page="0" type="metho">
    <SectionTitle>
2 Theoretical Background
</SectionTitle>
    <Paragraph position="0"> One basic assumption underlying this work is that it is useful to analyse dialogues by describing the relevant 'information' that is available to each participant. The notion of INFORMATION STATE (IS) is therefore employed in deciding what the next action should be, and the effects of utterances are described in terms of the changes they bring about in ISs. A particular instantiation of a dialogue manager, from this point of view, consists of a definition of the contents of ISs plus a description of the update processes which map from IS to IS. Updates are typically triggered by 'full' dialogue acts such as assertions or directives, 1 of course, but the theory allows parts of utterances, including individual words and even sub-parts of words, to be the trigger. The update rules for dialogue acts that we assume here are a simplified version of the formalisations proposed in (Poesio and Traum, 1998; Traum et al., 1999) (henceforth, PTT).</Paragraph>
    <Paragraph position="1"> The main aspects of PTT which have been implemented concern the way discourse obligations are handled and the manner in which dialogue participants interact to add information to the common ground. Obligations are essentially social in nature, and directly characterise spoken dialogue; a typical example of a discourse obligation concerns the relationship between questions and answers. Poesio and Traum follow (Traum and Allen, 1994) in suggesting that the utterance of a question imposes an obligation on the hearer to address the question (e.g., by providing an answer), irrespective of intentions.</Paragraph>
    <Paragraph position="2"> As for the process by which common ground is established, or GROUNDING (Clark and Schaefer, 1989; Traum, 1994), the assumption in PTT is that classical speech act theory is inherently too simplistic in that it ignores the fact that co-operative interaction is essential in discourse; thus, for instance, simply asserting something does not make it become mutually 'known' (part of the common ground). It is actually necessary for the hearer to provide some kind of acknowledgement that the assertion has been received, understood or not understood, accepted or rejected, and so on. Poesio and Traum view the public information state as including both material that has already been grounded, indicated by GND here, and material that hasn't been grounded yet. These components of the information state are updated when GROUNDING ACTS such as acknowledgement are performed. Each new contribution results in a new DISCOURSE UNIT (DU) being added to the information state (Traum, 1994) and recorded in a list of 'ungrounded discourse units' (UDUS); these DUs can then be subsequently grounded as the result, e.g., of (implicit or explicit) acknowledgements.</Paragraph>
  </Section>
  <Section position="5" start_page="0" end_page="2" type="metho">
    <SectionTitle>
3 Implementing PTT
</SectionTitle>
    <Paragraph position="0"> In this section, we describe the details of the implementation. First, in Section 3.1, we describe the TrindiKit tool for building dialogue managers that we used to build our system. In Section 3.2, we describe the information states used in the implementation, an extension and simplification of the ideas from PTT discussed in the previous section. Then, in Section 3.3, we discuss how the information state is updated when dialogue acts are observed. Finally,  in Section 3.4, we describe the rules used by the system to adopt intentions and perform its own actions. An extended example of how these mechanisms are used to track and participate in a dialogue is presented in Section 4.</Paragraph>
    <Section position="1" start_page="0" end_page="2" type="sub_section">
      <SectionTitle>
3.1 TrindiKit
</SectionTitle>
      <Paragraph position="0"> The basis for our implementation is the TrindiKit dialogue move engine toolkit implemented as part of the TRINDI project (Larsson et al., 1999). The toolkit provides support for developing dialogue systems, focusing on the central dialogue management components.</Paragraph>
      <Paragraph position="1"> The system architecture assumed by the TrindiKit is shown in Figure 1. A prominent feature of this architecture is the information state, which serves as a central 'blackboard' that processing modules can examine (by means of defined CONDITIONS) or change (by means of defined OPERATIONS). The structure of the IS for a particular dialogue system is defined' by the developer who uses the TrindiKit to build that system, on the basis of his/her own theory of dialogue processing; no predefined notion of information state is provided. 2. The toolkit provides a number of abstract data-types such as lists, stacks, and records, along with associated conditions and operations, that can be used to implement the user's theory of information states; other abstract types can also be defined. In addition to this customisable notion of information state, TrindiKit provides a few system variables that can also used for inter-module communication. These include input for the raw observed (language) input, latest_moves which 2In TRINDI we are experimenting with multiple instantiations of three different theories of information state (Traum et al., 1999).</Paragraph>
      <Paragraph position="2">  contains the dialogue moves observed in the most recent turn, latest_speaker, and next_moves, containing the dialogue moves to be performed by the system in the next turn.</Paragraph>
      <Paragraph position="3"> A complete system is assumed to consist of several modules interacting via the IS. (See Figure 1 again.) The central component is called the DIALOGUE MOVE ENGINE (DME). The DME performs the processing needed to integrate the observed dialogue moves with the IS, and to select new moves for the system to perform. These two functions are encapsulated in the UPDATE and SELECTION sub-modules of the DME. The update and select modules are specified by means of typed rules, as well as sequencing procedures to determine when to apply the rules. We are here mainly concerned with UPDATE RULES (urules), which consist of four parts: a name, a type, a list of conditions to check in the information state, and a list of operations to perform on the information state, urules are described in more detail below, in Section 3.3. There are also two modules outside the DME proper, but still crucial to a complete system: INTERPRETATION, which consumes the input and produces a list of dialogue acts in the latest_moves variable (potentially making reference to the current information state), and GENERATION, which produces NL output from the dialogue acts in the next_moves variable. Finally, there is a CONTROL module, that governs the sequencing (or parallel invocation) of the other modules. In this paper we focus on the IS and the DME; our current implementation only uses very simple interpretation and generation components.</Paragraph>
    </Section>
    <Section position="2" start_page="2" end_page="2" type="sub_section">
      <SectionTitle>
3.2 Information States in PTT
</SectionTitle>
      <Paragraph position="0"> In this section we discuss the information state used in the current implementation. The main difference between the implemented IS and the theoretical proposal in (Poesio and Traum, 1998) is that in the implementation the information state is partitioned in fields, each containing information of different types, whereas in the theoretical version the information state is a single repository of facts (a DISCOURSE</Paragraph>
    </Section>
  </Section>
  <Section position="6" start_page="2" end_page="5" type="metho">
    <SectionTitle>
REPRESENTATION STRUCTURE). Other differences
</SectionTitle>
    <Paragraph position="0"> are discussed below. An example IS with some fields filled is shown in Figure 2; this is the IS which results from the second utterance in the example dialogue discussed in Section 4, A route please. 3 The IS in Figure 2 is a record with two main parts, W and C. The first of these represents the system's (Wizard) view of his own mental state and of the (semi-)public information discussed in the dialogue; the second, his view of the user's (Caller) information state. This second part is needed to 3All diagrams in this paper are automatically generated from TrindiKit system internal representations and displayed using the Thistle dialogue editor (Calder, 1998). Some have been subsequently edited for brevity and clarity.</Paragraph>
    <Paragraph position="1">  r \] understandingAct( W,DU3 )\ 1 ~1 \[OBL: ~lddre~(C,CA2 ) \] / // ~.. /.. /CAS:C2 ,~..,~g.(C.DU2) \/ II ..... / .... \c^:: '// II / sc : &lt; &amp;quot; ! H \[COND: &lt; &gt; J H UDUS: &lt;DU3&gt; H \[ \[OBL: &lt;,ddri~z(C.CA2 ) &gt; \]\] H DH: &lt;CA2: C2. into requi~t( W.?help fore1 ) :&gt;</Paragraph>
    <Paragraph position="3"> model misunderstandings arising from the dialogue participants having differing views on what has been grounded; as we are not concerned with this problem here, we will ignore C in what follows.</Paragraph>
    <Paragraph position="4"> w contains information on the grounded material (GND), on the ungrounded information (UDUS, PDU and CDU), and on W's intentions (INT). GND contains the information that has already been grounded; the other fields contain information about the contributions still to be grounded. As noticed above, in PTT it is assumed that for each new utterance, a new DU is created and added to the IS.</Paragraph>
    <Paragraph position="5"> The current implementation differs from the full theory in that only two DUs are retained at each point; the current DU (CDU) and the previous DU (PDU).</Paragraph>
    <Paragraph position="6"> The CDU contains the information in the latest contribution, while the PDU contains information from the penultimate contribution. Information is moved from PDU to GND as a result of an ack (acknowledgement) dialogue act (see below.) The DUs and the GND field contain four fields, representing obligations (OBL), the dialogue history (DH), propositions to which agents are socially committed (scP), and conditional updates (COND). The value of OBL is a list of action types: actions that agents are obliged to perform. An action type is specified by a PREDICATE, a DIALOGUE PARTICI-PANT, and a list of ARGUMENTS. The value of see is a list of a particular type of mental states, social commitments of agents to propositions. 4 These are specified by a DIALOGUE PARTICIPANT, and a PROPOSITION. Finally, the elements in DH are dia- null logue actions, which are instances of dialogue action types. A dialogue action is specified by an action type, a dialogue act id, and a confidence level CONF (the confidence that an agent has that that dialogue act has been observed).</Paragraph>
    <Paragraph position="7"> The situation in Figure 2 is the result of updates to the IS caused by utterance \[2\] in the dialogue in (6), which is assumed to generate a direct act as well as an assert act and an answer act. 5 That utterance is also assumed to contain an implicit acknowledgement of the original question; this understanding act has resulted in the contents of DU2 being grounded (and subsequently merged with GND), as discussed below.</Paragraph>
    <Paragraph position="8"> GND.OBL in Figure 2 includes two obligations.</Paragraph>
    <Paragraph position="9"> The first is an obligation on W to perform an understanding act (the predicate is understandingAct, the participant is W, and there is just one argument, DU3, which identifies the DU in CDU by referring to its ID). The second obligation is an obligation on C to address conversational act CA2; this ID points to the appropriate info_request in the DH list by means of the ID number. Obligations are specified in CDU and PDU, as well. Those in PDU are simply a subset of those in GND, since at point in the update process shown in Figure 2 this field contains information that has already been grounded (note that DU2 is not in UDUS anymore); but CDU contains obligations that have not been grounded yet in particular, the obligation on W to address CA6.</Paragraph>
    <Paragraph position="10"> GND.DH in this IS contains a list of dialogue actions whose occurrence has already been grounded: the info_request performed by utterance 1, with argument a question, 6 and the implicit acknowledge performed by utterance 2. 7 The DH field in CDU contains dialogue acts performed by utterance 2 that do need to be grounded: a directive by C to W to perform an action of type giveroute, and an assert by C of the proposition want(C, route), by which C provides an answer to the previous info_request CA2.</Paragraph>
    <Paragraph position="11"> The COND field in CDU contains a conditional update resulting from the directive performed by that utterance. The idea is that directives do not immediately lead to obligations to perform the mentioned action: instead (in addition to an obligation to address the action with some sort of response), their effect is to add to the common ground the information that if the directive is accepted by the addressee, SThe fact that the utterance of a route please constitutes an answer is explicitly assumed; however, it should be possible to derive this information automatically (perhaps along the lines suggested by Kreutel (Kreutel, 1998)).</Paragraph>
    <Paragraph position="12">  Traum, 1998), that understanding acts do not have to be grounded themselves, which would result in a infinite regress. then he or she has the obligation to perform the action type requested. (In this case, to give a route to</Paragraph>
    <Section position="1" start_page="3" end_page="3" type="sub_section">
      <SectionTitle>
C.)
3.3 Update Rules in PTT
</SectionTitle>
      <Paragraph position="0"> We are now in a position to examine the update mechanisms which are performed when new dialogue acts are recognised. When a dialogue participant takes a turn and produces an utterance, the interpretation module sets the system variable latest_moves to contain a representation of the dialogue acts performed with the utterance. The updating procedure then uses update rules to modify the IS on the basis of the contents of latest_moves and of the previous IS. The basic procedure is described in (1) below, s  (1) 1. Create a new DU and push it on top of UDUs.</Paragraph>
      <Paragraph position="1"> 2. Perform updates on the basis of backwards grounding acts.</Paragraph>
      <Paragraph position="2"> . If any other type of act is observed, record  it in the dialogue history in CDU and apply the update rules for this kind of act 4. Apply update rules to all parts of the IS which contain newly added acts.</Paragraph>
      <Paragraph position="3"> The first step involves moving the contents of CDU to PDU (losing direct access to the former PDU contents) and putting in CDU a new empty DU with a new identifier. The second and third steps deal explicitly with the contents of latest.moves, applying one urule (of possibly a larger set) for each act in latest_moves. The relevant effects for each act are summarised in (2), where the variables have the following types:</Paragraph>
    </Section>
    <Section position="2" start_page="3" end_page="4" type="sub_section">
      <SectionTitle>
An Action
</SectionTitle>
      <Paragraph position="0"> The other dialogue participant The content of the ID, a proposition The content of the ID, a question SSee (Poesio et al., 1999; Traum et al., 1999) for different versions of this update procedure used for slightly different versions of the theory.</Paragraph>
      <Paragraph position="1">  (2) act ID:2, accept (DP, ID2) effect accomplished via rule resolution</Paragraph>
      <Paragraph position="3"> The ack act is the only backward grounding act implemented at the moment. The main effect of an ack is to merge the information in the acknowledged DU (assumed to be PDU) into GND, also removing this DU from UDUS. Unlike the other acts described below, ack acts are recorded directly into GND.DH, rather than into CDU.TOGND.DH.</Paragraph>
      <Paragraph position="4"> All of the other updates are performed in the third step of the procedure in (1). The only effect of accept acts is to enable the conditional rules which are part of the effect of assert and direct, leading to social commitments and obligations, respectively.</Paragraph>
      <Paragraph position="5"> agree acts also trigger conditional rules introduced by check; in addition, they result in the agent being socially committed to the proposition introduced by the act with which the agent agrees. Performing an answer to question ID2 by asserting proposition P(ID3) commits the dialogue participant to the proposition that P(ID3) is indeed an answer to Q(ID2).</Paragraph>
      <Paragraph position="6"> The two rules for assert are where the confidence levels are actually used, to implement a simple verification strategy. The idea is that the system only assumes that the user is committed to the asserted proposition when a confidence level of 2 is observed, while some asserts are assumed not to have been sufficiently well understood, and are only assigned a confidence level 1. This leads the system to perform a check, as we will see shortly.</Paragraph>
      <Paragraph position="7"> The next three update rules, for check, direct, and info_req, all impose an obligation on the other dialogue participant to address the dialogue act. In addition, the direct rule introduces a conditional act: acceptance of the directive will impose an obligation on the hearer to act on its contents.</Paragraph>
      <Paragraph position="8"> In addition, all FORWARD ACTS 9 in the DRI scheme (Discourse Resource Initiative, 1997) impose an obligation to perform an understanding act (e.g., an acknowledgement): (3) 1 act effect ID:c, forward-looking-act (DP) push(OBL,u-act (o(DP),CDU.id)) I The internal urules implementing the updates in (2) have the format shown in (4), which is the urule for info_request.</Paragraph>
      <Paragraph position="9">  As noted above, these rules have four parts; a name, a type, a list of conditions, and a list of effects. The conditions in (4) state that there must be a move in latest_moves whose predicate is inforeq.</Paragraph>
      <Paragraph position="10"> The effects ldeg state that the move should be recorded in the dialogue history in CDU, that an obligation to address the request should be pushed into OBL in CDU, and that the requirement for an understanding act by W should be pushed directly into the list in W.GND.</Paragraph>
      <Paragraph position="11"> The fourth and final step of the algorithm cycles through the updating process in case recently added facts have further implications. For instance, when an action has been performed that matches the antecedent of a rule in COND, the consequent is established. Likewise, when an action is performed it releases any obligations to perform that action.</Paragraph>
      <Paragraph position="12"> Thus, accept, answer, and agree are all ways of releasing an obligation to address, since these are all appropriate backward looking actions. Similarly, an agent will drop intentions to perform actions it has already (successfully) performed.</Paragraph>
    </Section>
    <Section position="3" start_page="4" end_page="5" type="sub_section">
      <SectionTitle>
3.4 Deliberation
</SectionTitle>
      <Paragraph position="0"> are the primary mental attitude leading to an agent's actions. The main issues to explain then become how such intentions are adopted given the rest of the information state, and how an agent gets from intentions to actual performance.</Paragraph>
      <Paragraph position="1"> For the latter question, we take a fairly simplistic approach here: all the intentions to perform dialogue acts are simply transferred to the next_moves system variable, with the assumption that the generation module can realise all of them as a single utterance. A more sophisticated approach would be to weight the importance of (immediate) realisation of sets of intentions and compare this to the likelihood that particular utterances will achieve these effects at minimal cost, and choose accordingly. We leave this for future work (see (Traum and Dillenbourg, 1998) for some preliminary ideas along these lines), concentrating here on the first issue - how the system adopts intentions to perform dialogue acts from other aspects of the mental state.</Paragraph>
      <Paragraph position="2"> The current system takes the following factors into account: * obligations (to perform understanding acts, to address previous dialogue acts, to perform other actions) * potential obligations (that would result if another act were performed, as represented in the  * intentions to perform complex acts The current deliberation process assumes maximal cooperativity, in that the system always chooses to meet its obligations whenever possible, and also chooses to provide a maximally helpful response when possible. Thus, when obliged to address a previous dialogue act such as a question or directive, it will choose to actually return the answer or perform the action, if possible, rather than reject or negotiate such a performance, which would also be acting in accordance with the obligations (see (Kreutel, 1998) on how acts might be rejected).</Paragraph>
      <Paragraph position="3"> In the current implementation, the following rules are used to adopt new intentions (i.e., to update the  INT field): (5) 1. add an intention to acknowledge(W,CDU), given an obligation to perform a u-act, if everything in CDU is sufficiently understood (i.e., to level 2); 2. add an intention to accept a directive or answer a question as the result of an obligation to address a dialogue act; 3. add an intention to perform an action if COND contains a conditional that will estab null lish an obligation to perform the action, and the antecedent of this conditional is another action that is already intended. (This anticipatory planning allows the obligation to be discharged at the same time it is invoked, e.g., without giving an intermediate acceptance of an directive.) 4. add an intention to perform a (dialogue) action motivated by the intention to perform the current task. In the case of the Autoroute domain, we have two cases: the system may decide (a) to check any dialogue acts in CDU at confidence level 1, which contain information needed to discharge the intention to give a route; or (b) to perform a question asking about a new piece of information that has not been established (this is decided by inspecting GND.SCP and CDU.SCP). For example, it may decide to ask about the starting point, the time of departure, etc.</Paragraph>
    </Section>
  </Section>
  <Section position="7" start_page="5" end_page="6" type="metho">
    <SectionTitle>
4 Extended Example
</SectionTitle>
    <Paragraph position="0"> In this section, we discuss more examples of how the information state changes as a result of processing and performing dialogue acts. It is useful to do this by looking briefly at a typical Autoroute dialogue, shown in (6). 11 Our implementation can process this sort of dialogue using very simple interpretation and generation routines that provide the dialogue acts in latest_moves from the text strings, and produce W's output text from the dialogue acts which the  culated.</Paragraph>
    <Paragraph position="1"> We assume that before the dialogue starts, W has the intention to ask C what kind of help is required, liThe interchanges have been cleaned up to some extent here, mainly by removing pauses and hesitations.</Paragraph>
    <Paragraph position="2">  and that C has the intention to find a route. We also assume that W has the turn, and that the presence of the how can I help intention triggers an utterance directly. Figure 2, presented above, shows the information state after utterance \[2\]. The intentions in that figure lead directly to the system producing utterance \[3\].</Paragraph>
    <Paragraph position="3"> Looking a little further ahead in the dialogue, Figure 3 shows the information state after utterance \[4\]. 12 Here we can see in CDU.TOGND.DH (along with the ack act CA10, in GND.DH) the dialogue moves that this utterance has generated. Note that the assert, CAll, is only at confidence level 1, indicating lack of sufficient certainty in this interpretation as the town 'Great Malvern'. This lack of certainty and the resulting lack of a relevant SCP in CDU.TOGND lead the deliberation routines to produce an intention to check this proposition rather than to move directly on to another information request. This intention leads to utterance \[5\], which, after interpretation and updating on the new dialogue acts, leads to the information state in Figure 4. The interesting thing here is the condition which appears in CDU.TOGND.COND as a result of the check; the interpretation of this is that, if C agrees with the check, then W will be committed to the proposition that the starting place is Malvern (C would also be committed to this by way of the direct effects of an agree act).</Paragraph>
    <Paragraph position="4"> 12The actual information state contains all the previously established dialogue acts, SCPs and Obligations in GND~ from Figure 2 and intermediate utterances. Here we have deleted these aspects from the figures for brevity and clarity.  After C's agreement in \[6\], the deliberation routine is able to move past discussion of the starting point, and add an intention to ask about the next piece of information, the destination. This leads to producing utterance \[7\], which also implicitly acknowledges \[6\], after which C's agreement is grounded, leading to the IS shown in Figure 5. Note that the list in W.GND.SCP in Figure 5 indicates that both C and W are committed to the proposition that the starting place is Malvern.</Paragraph>
  </Section>
class="xml-element"></Paper>