Annotation guidelines for applying DIT dialogue act tags

Dialogue act annotation is about indicating the kind of intention that the speaker had; what kind of thing was he trying to achieve? When participating in a dialogue, this is what agents are trying to establish. The first and most important two guidelines follow from this.

1. First and most important guideline: "Do as the Addressee would do!"
When assigning annotation tags to a dialogue utterance, put yourself in the position of the participant at whom the utterance was addressed, and imagine that you try to understand what the speaker is trying to do. Why does (s)he say what (s)he says? What are the purposes of the utterance? What assumptions does the speaker express about the addressee? Answering such questions should guide you in deciding which annotation tags to assign, regardless of how exactly the speaker has expressed himself. Use all the information that you could have if you were the actual addressee, and like the addressee, try to interpret the speaker's communicative behaviour as best as you can.


2. Second and equally important guideline: "Think functionally, not formally!"
The linguistic form of an utterance often provides vital clues for choosing an annotation, but such clues may also be misleading; in making your choice of annotation tags you should of course use the linguistic clues to your advantage, but don't let them fool you - the true question is not what the speaker says but what he means.
For example, SetQuestions are questions where the speaker wants to know which elements of a certain domain have a certain property. In English, such questions often contain a word beginning with "wh", such as which as in Which books did you read on your holidays? or where in Where do your parents live?. But in other languages this is not the case; moreover, even in English not all sentences of this form express a SetQuestion: Why don't you go ahead is for instance typically a Suggestion rather than a question.
Similarly, PropositionalQuestions are questions where the speaker wants to know whether a certain statement is true or false. Such sentences typically have the form of an interrogative statement, such as Is The Hague the capital of the Netherlands? or Do you like peanut butter? But not all sentences of this form express a PropositionalQuestion; for example, Do you know what time it is? functions most often as in IndirectSetQuestion (What time is it?), and Would you like some coffee? is an Offer; Shall we go? is a Suggestion.

3. Another important general guideline is: "Be specific!"
Among the communicative functions that you can choose from, there are differences in specificity, corresponding with their relative positions in hierarchical subsystems. For instance, a CheckQuestion is more specific than a PropositionalQuestion, in that it additionally carries the expectation that the answer will be positive. Similarly, a Confirm is more specific than a PropositionalAnswer, in that it carries the additional speaker that the addressee expects the answer to be positive.
In general, try all the time to be as specific as you can. But if you're in serious doubt about specific functions that you could choose between, then simply use a less specific function tag that subsumes the more specific tags.


4. On indirect speech acts: "Code indirect speech acts just like direct ones."
Standard speech act theory regards indirect speech acts, such as indirect questions, as just an indirect form of the same illocutionary acts. By contrast, the DIT++ taxonomy incorporates the idea that indirect dialogue acts signal subtly different packages of beliefs and intentions than direct ones. For example, the direct question What time is it? carries the assumption that the addressee knows what time it is, whereas the indirect question Do you know what time it is? does not carry that assumption (it does at least not express that assumption; in fact it questions it).

5. On implicit functions: "Do not code implicit communicative functions, that can be deduced from functions that you have already assigned."
Implicit communicative functions occur in particular for positive feedback. For example, someone answering a question may be assumed to (believe to) have understood the question. So any time you annotate an utterance as an answer (of some sort), you might consider annotating it also as providing positive feedback on the interpretation of the question that is answered. Don't! It would be redundant.
Notice also that the definition of a positive (auto-) feedback act concerning interpretation stipulates that the speaker wants the addressee to know that he (speaker) has understood the question. A speaker who answers a question does not so much want to tell the addressee that his question was understood -- that's just a side-effect of giving an answer, that no speaker can avoid.
Similarly for reacting to an offer, a request, a suggestion, etc.


6. Guidelines for the annotation of feedback functions.
Negative feedback, where the speaker wants to indicate that there was a problem in processing a dialogue utterance, is always explicit and as such mostly easy to annotate.

6.1 Implicit and explicit positive feedback.
Positive feedback is sometimes given explicitly, and very often implicitly.
Examples of explicit positive auto-feedback are the following utterances by B, where he repeats part of the question by A:

A: What time does the KLM flight from Jakarta on Friday, October 13 arrive?
B: The KLM flight from Jakarta on Friday, October 13 has scheduled arrival time 08.50
B: The flight from Jakarta on Friday has scheduled arrival time 08.50
B: The KLM flight from Jakarta on October 13 has scheduled arrival time 08.50
B: The flight from on October 13 has scheduled arrival time 08.50

In such cases, the utterance by B should be annotated as having, besides the general-purpose function SetAnswer in the Activity dimension, also a function in the Auto-Feedback dimension (see below).
By contrast, the short answer: At 08.50 would carry only implicit feedback information, and should therefore, following Guideline 5, not be coded in the Auto-Feedback dimension.

6.2 Levels of feedback.
The DIT++ taxonomy distinguishes 5 levels of feedback:
1. participant A pays attention to participant B's utterance.
2. A perceives B's utterance, i.e. A recognizes the words and nonverbal elements in B's contribution.
3. A understands B's utterance, i.e. A assigns an interpretation to B's utterance, including what A believes B is trying to achieve with this utterance (what are his goals and associated beliefs about the task/domain and about A).
4. A evaluates B's utterance, i.e. A decides whether the beliefs about B that characterize his understanding of B's utterance, can be added to A's model of the dialogue context, updating his context model without arriving at inconsistencies.
5. A 'executes' B's utterance, i.e. A performs actions which are appropriate for achieving a goal that he had identified and added to his context model. (For instance, executing a request is to perform the requested action; executing an answer is to add the content of the answer to one's information; executing a question is to look for the information that was asked for.)

There are certain relations between these levels: in order to execute a dialogue act one must have evaluated it positively ("accepted" it); which is only possible if one (believes to) have understood the corresponding utterance; which presupposes that one perceived the utterance in the first place, which, finally, requires paying attention to what is said. So for instance positive auto-feedback about the acceptance of the addressee's previous utterance implies positive feedback at the "lower" levels of understanding, perception, and attention. For positive feedback functions a higher-level function is more specific than the lower-level functions. (Remember that a function is more specific if it implies other functions.)
For negative feedback the reverse holds: when a speaker signals the impossibility to perceive an utterance, he implies the impossibility to interpret, evaluate and execute it. So negative feedback at a lower level implies negative feedback at higher levels..
Since, following Guideline 3, you should always be as specific as possible, you should observe the following guideline for annotating feedback functions:

Guideline 6: When assigning a feedback function, choose the most specific level of feedback in the case of positive feedback that you feel to be appropriate, and choose the least specific level in the case of negative feedback.

While this guideline instructs you to be as specific as possible, sometimes you'll be in serious doubt. You may for instance find yourself in a situation where you have no clue whether a feedback signal (such as OK) should be interpreted at the level of interpretation or that of evaluation. In such a case you should use the less specific of the two, since the more specific level would mean that you "read" more into this utterance than you can justify.
In practice, it is often difficult to decide the level of feedback that should be chosen. One of the reasons for this is that the same verbal and nonverbal expressions may be used at most of the levels (with a tendency to signal feedback (positively or negatively) with more emphasis as higher levels of processing are involved). It may happen that you encounter a feedback signal and you have no clue at all at which level you should interpret that signal. In this situation the annotation scheme allows you to use the labels `Positive' and `Negative', which leave the level of feedback unspecified.

7. Guidelines for the annotation of Interaction Management functions.
7.1 Turn Management.
General guideline: "Code Turn Management functions only when these are not just implied."
In a spoken dialogue, the participants take turns to speak. (Their nonverbal behaviour is not organised in turns; both participants use facial expressions and gestures more or less all the time.) A turn, that is a stretch of speech by one of the participants, in general consists of smaller parts that have a meaning as a dialogue act; these parts we call "utterances". Turn Management acts are the actions that participants perform in order to manage the allocation of the speaker role. These acts are subdivided into acts for taking the turn (utterance-initial acts) and those for keeping the turn or giving it away (utterance-final acts). Usually only the first utterance in a turn has an utterance-initial function and only the last an utterance-final one. The non-final utterances in a turn do not have an utterance-final function, except when the speaker signals (for example by using a rising utterance-final intonation) that the utterance is not going to be the last one in the turn, that he wants to continue. In that case the utterance has a Turn Keeping function. Except for the first one, the utterances in the turn do not have an utterance-initial function; the speaker does not have to perform a separate act in order to continue; all he has to do is to continue speaking.

When a speaker accepts a turn that the addressee has assigned to him through a Turn Assign act, the utterance should be annotated as having the utterance-initial function Turn Accept only when the speaker performs a separate act for the purpose of accepting the turn, so don't code this when the turn is accepted implicitly by simply starting to speak.

Similarly, an utterance should be annotated as having the utterance-initial function Turn Take only if the speaker performs a separate act to that effect. If he just goes ahead and makes a contribution to the dialogue, without first signalling his intention to do so, then the utterance should not be marked with an utterance-initial Turn Management function.

The verbal as well as nonverbal activities that a speaker performs to seize the turn should be marked as Turn Grabbing, but the utterance that follows after he has seized the turn should not be marked as having an utterance-initial Turn Management function.


7.2 Time Management.
When a speaker is buying time, using fillers such as Well,..; Let's see,... , then the utterance should be annotated as having the Stalling function in the Time Management dimension. There may be several reasons why a speaker wants to have more time; it may be that the speaker has trouble completing his current utterance, or that he is interrupted by some urgent event that requires his attention before he can continue the dialogue. but it may also be that he needs some time to find some information (for instance, for answering a question). So when you encounter a Stalling act, you may well pay attention to the reason why the speaker is stalling. (For instance, Stalling often goes hand in hand with turn acceptance or turn keeping.) However, don't speculate; only code additional functions for which you have evidence.

7.3 Topic Management.
During a dialogue, the topic is often changed implicitly, simply by talking about a new topic. This happens especially if the new topic is closely related to the previous one, for instance by being a subtopic of the previous topic, or by both being a subtopic of a more general topic. Implicit topic management should not be encoded; it would be redundant. Topic Management functions should be annotated only if the speaker explicitly introduces or closes a topic, or signals his intention to do so.

7.4 Contact Management.
The management of contact in the sense of both partners being ready to send and receive messages to and from each other, is important especially in other than face-to-face situations, such as telephone conversations, video-conferencing, and internet chatting.
Note that in many languages expressions used for establishing contact can often be used for other purposes as well, for example for greeting (Hello!). When annotating a dialogue where this happens, the utterance in question should be marked as having both a Contact Management function and a Social Obligation Management function.

7.5 Own Communication Management.
Own Communication Management (OCM) functions should be coded whenever a speaker signals that he made a speech error and/or wants to edit what he is saying. Since this typically requires some extra effort and time, OCM acts often go hand in hand with acts whose function is to win time, such as hesitations (Ehm...), which have a Stalling function. See also 7.2.

7.6 Partner Communication Management.
Partner Communication Management (PCM) functions should be coded whenever a speaker signals that he believes the addressee made a speech error or has difficulty in completing an utterance, for instance being unable to recall a name or to find the right words to express something. The use of dimension-specific PCM functions for this purpose is typically only possible by interrupting the dialogue partner or in immediate response to a partner utterance.

7.7 Dialogue Structuring.
These functions should be coded only when the speaker explicitly signals something about his intention to open or close the dialogue, or to continue in a particular way.

Across the board, the following guideline applies to the encoding of Interaction Management functions:
Guideline 7: "Code only explicit Interaction Management functions."

8. Guidelines for annotating Social Obligation Management (SOM) functions.
Utterances that serve a 'social' purpose such as greetings, thanks, and apologies can often be used for other purposes as well. Greetings like Hello!, for example, can be used also for establishing contact (Contact Management function) and/or for opening a dialogue (a Dialogue Structuring function). Also, an expression of thanks can be used to signal that the speaker wants to soon end the dialogue (Dialogue Structuring function PRE-CLOSING), and can also be used for overall positive feedback. In such cases, the utterances should be coded with the appropriate functions in all these dimensions.

Guideline 8: "When coding an utterance as having a SOM function, look out for additional functions in other dimensions."

Note on segmentation.

The segmentation of a dialogue into utterances may present several difficulties.


First, if you're working form a transcription of a spoken dialogue, the segmentation in the transcription is not necessarily perfect. You may run into cases where you would prefer the utterance to be segmented as a sequence of parts that each have a functional interpretation. In such a case it is best to assign the various tags that you would prefer to assign to the parts to the utterance as a whole. Or conversely, it may also happen that a turn has been segmented into certain parts, where you would want to annotate the longer utterance formed by these parts together. In such a case it is recommended to annotate all these parts with the same tags.

Second, an utterance may be self-interrupted by a part that has a different communicative function, as in the following example: When, I mean what time, does the train to ehm,... Viareggio leave? Here the utterance as a whole is a SetQuestion; it includes a Self-Correction (I mean what time) and a Stalling utterance (ehm). In such cases, again, it is best to assign the tags for the intervening parts of the utterance to the utterance as a whole.

Third, it may happen that a dialogue act corresponds to (parts of) more than one turn, as in the following example, where the utterances in turns 1 and 3 together form a SetAnswer::

1. A: There are two flights early in the morning, at 7.45 and at 8.15,..
2. B: Yes
3. A: and two more in the evening, at 7.15 and at 8.30.


In such a case it is best to give each of these parts the same tag (WH-ANSWER, in this example).