next up left folder
Next: Understanding Up: Backward Looking Function Previous: Backward Looking Function


The agreement aspect codes how the current utterance unit affects what the participants believe they have agreed to, typically at the task level. These relations occur in contexts where one agent has made some kind of proposal such as a request that the hearer do something, an offer that the speaker do something, or a claim about the world. The current utterance then indicates the other participant's view of the proposal. In general, the agent may explicitly accept or reject all or part of the proposal, or may simply be noncommittal on the proposal, or may leave the proposal open by requesting additional information or exploring the consequences.

Assuming the current speaker directly addresses another speaker's proposal, they could respond in one of the five ways shown in figure 5. Note, the label of Maybe applies to cases like the one in the figure where the speaker explicitly states that they cannot give a definite answer at that moment.

Figure 5: Various responses to an offer

Note that the Accept-part utterance implicitly rejects part of utt1 however this aspect only codes what is explicitly (accepted/rejected) addressed by the response. A response like ``I'll take the book but not the review'' will be segmented into two utterance units; one marked as Accept-part and the other as Reject-part.

Agreement can apply to cases other than proposals, as shown in the two examples below. In the first example, utt1 is an Open-option as it simply presents a possible option for solving a problem. Utt2 is still considered an accept though. Note, accepts are often words such as ``alright'', ``yes'', and ``okay'' as well as repetitions.

Open-option  utt1: s: we can unload them and then reuse the boxcars 
                         on the way to Corning
  Accept(utt1) utt2: u: alright

Accepts also can occur in response to Asserts, indicating that the information conveyed is accepted.

Assert       utt1: s: boxcars don't travel by themselves
  Accept(utt1) utt2: u: okay

Accepts can also be used as a response to an information request, as in the example below. Note, utt3 is marked as an answer as discussed later.

Info-Request utt1: u: can you tell me the time?
  Accept(utt1) utt2: s: yes
  Answer(utt1) utt3:     it's 5 o'clock

The Hold tag applies to the case where the participant does not address the proposal but performs an act that leaves the decision open pending further discussion. This includes cases such as counter-proposals and questions that request additional information in order to help the participant make a decision (i.e., one sense of clarification request). This tag does not apply to cases where the speaker explicitly expresses uncertainty such as uttering ``maybe''.

In the dialog below, u's request is vague since there are two possible paths so s makes a clarification request by asking a question.

Action-directive         utt1: u: take the train to Corning
  Info-request, Hold(utt1) utt2: s: should we go through Dansville or Bath
  Assert, Answer(utt2)     utt3: u: Dansville

Instead of asking a question, a responder may make a clarification statement as shown below. This is also marked as a hold.

Info-Request utt1: u: how long will that take
  Hold(utt1)   utt2: s: you want to go from Avon to Dansville
  Answer(utt1) utt3: s: that's 5 hours

In the examples below, s's suggestion of an alternative route should be as marked as a Hold if you think that s is leaving the original option open, but as a Reject-part if not.

Action-directive        utt1: u: take the train to Avon via Bath
  Open-option, Hold(utt1) utt2: s: How about we go via Corning instead

Action-directive                    utt1: u: take the train to Avon via Bath
  Action-directive, Reject-part(utt1) utt2: s: Go via Corning instead

Figure 6: Decision Tree for Agreement Aspect

next up left folder
Next: Understanding Up: Backward Looking Function Previous: Backward Looking Function

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