next up left folder
Next: Discussion Up: Backward Looking Function Previous: Information-Relations

Antecedents

Typically responses follow directly after the utterances that they are responding to. Sometimes, however, they are further apart and separated by a series of clarification requests, confirmations, and elaborations. Only those responses that still have a close contextual connection to their antecedent should be annotated. Unfortunately, we do not yet have a precise definition of ``close contextual connection.'' For the short term, here are some guidelines for refining intuitions about how close an utterance(s) and its response must be. Assume that utterance X by s is a proposal, a claim, a question or some other act that can be responded to. Then an utterance can be part of an antecedent to X if

In such cases, the antecedent is marked as containing all the utterances from X up to the response. We expect that this definition of allowable antecedents may have to be modified after we have some additional experience coding and have seen where it breaks down.

Consider some examples of common cases that satisfy this definition.

Open-option              utt1: u: We could use that train.
  Info-request, Hold(utt1) utt2: s: The one at Dansville?
  Assert, Answer(utt2)     utt3: u: yes
  Accept(utt1-utt3)        utt4: s: Okay.
  

In this case, the option accepted is to use the train at Dansville, and the content of utt1-utt3 could be paraphrased as ``We could use the train at Dansville''.

Open-option                  utt1: u: We could use the train at Dansville.
  Open-option, Hold(utt1)      utt2: s: Could we use one at Avon instead?
  Assert, Reject(utt2)         utt3: u: No, I want it for something else.
  Open-option, Hold(utt1-utt3) utt4: s: How about the one at Corning then?
  Assert, Accept (utt4)        utt5: u: Okay.
  Accept(utt1-utt5)            utt6: s: Okay.
  

In this example s produces two alternatives before an agreement is reached. The content of the antecedent for utt6 could be paraphrased as ``We could use the train at Corning''.

This example shows the initial speaker adding further elaboration before the question is answered.

Info-request              utt1: u: How long will it take to get to Avon?
  Info-request, Hold(utt1)  utt2: s: With engine E one?
  Assert, Answer(utt2)      utt3: u: yes
  Info-request              utt4:    and going by way of Bath.
  Assert, Answer(utt1-utt4) utt5: s: Six hours.
  

Note that utt4 is classified as an Info-request even though it doesn't look like a question out of context. But it is said to influence u's future action and involves the act of providing information, hence it satisfies the definition of Info-request. This interpretation is further strengthened by considering that utt4 certainly is not making any claim about the world, nor committing u to any future action. The content of segment utt1-utt4 can be paraphrased as ``How long will it take engine E one to get to Avon by way of Bath''.

With keyboard dialogues, we need to generalize the definition of antecedent somewhat as a turn might contain several different interactions, each of which are then addressed in the following turn: in a keyboard dialogue, a turn may be divided into several antecedents, each of which can be responded to in the next turn.

Consider the following keyboard dialogue from the Coconut domain where participants must agree on a set of furniture with which to furnish two rooms. The dialog shows how in keyboard dialogs, several responses (each with its own antecedent) may occur in the same turn. Note, Assert is abbreviated (AS) here.

Open-option,Offer    utt1: M: i do have a lamp-floor, blue.  i have a green
                                 table (200) and four chairs for 75 a piece.
  AS                   utt2:    sorry I am taking so much time.
  AS                   utt3:    I lost a chair. Meghan is finding it
  
  AS,Accept(utt2-utt3) utt4: D: Not a problem with the time
  AS                   utt5:    sorry about the typo, my brain forgets that 
                                 my fingers don't function as quick as it does.
  Accept-part(utt1)    utt6:    the lamp and table sound good
  

We also may want to allow such structures in spoken dialogues, if we start to find cases where the more restrictive rule is a problem. Certainly a model of higher-level segmentation would predict that examples like the one above could occur naturally in spoken dialogue.

If we switch the example around a bit, however, we find a case involving a cross-serial dependency that can occur in keyboard dialogue but is extremely rare and possible disfluent in spoken dialogue:

Open-option,Offer        utt1: M: i do have a lamp-floor, blue.  i have a green
                                     table (200) and four chairs for (75) 
                                     a piece.
  Assert                   utt2:    sorry I am taking so much time.
  Assert                   utt3:    I lost a chair. Meghan is finding it
  
  Accept-part(utt1)        utt4: D: the lamp and table sound good
  Assert,Accept(utt2-utt3) utt5:    Not a problem with the time
  Assert                   utt6:    sorry about the typo ...
  

There may also be cases where you would like to mark more than one response relation for an utterance. We may consider adding this capability if there turns out to be a significant need. For the moment, however, if an utterance appears to realize several different responses, then you should annotate the one you feel is most important and relevant to the dialogue, and note the other interpretations using a Comment tag.



next up left folder
Next: Discussion Up: Backward Looking Function Previous: Information-Relations



Mark Core
Mon Sep 22 20:05:25 EDT 1997