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