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.