Information about the task or activity for which the dialogue is intended to be instrumental, or about the domain of discourse of this task/activity, for instance when asking or providing task-related information. Functions here are expressible either by means of performative verbs denoting (partly) communicative actions for performing tasks in a specific domain, or by means of graphical actions such as highlighting, or pointing to something in a picture.

Auto-Feedback acts are about the speaker's own attention and processing of an utterance in the addressee's last turn. Dimension-specific Auto-Feedback functions are intended to signal that the processing of the utterance in question failed at a certain level or was successful up to a certain level. More articulate feedback acts, signalling or requesting help for a specific processing problem, are constructed with general-purpose functions and a specific processing-related semantic content.

The annotation of feedback functions.

Negative feedback, where the speaker wants to indicate that there was a problem in his own or his dialogue partner's processing of a dialogue utterance, is always explicit and as such mostly easy to annotate. Dimension-specific negative feedback acts are for instance expressed in English by I beg you pardon? or Sorry?, which are not expressions of regret but standard ways of saying that something was not understood (or hard to believe). Negative feedback may also be expressed my menas of general-purpose functions, as in I don't understand what you said and in Did you say Thursday?, where an /inform/ act and a /checkQuestion/ are used, respectively, in the auto-feedback dimension).

Positive feedback is sometimes given explicitly, either verbally or nonverbally (for instance by nodding) 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 Task dimension, also a the function /positiveAutoFeedback/ in the Auto-Feedback dimension (see below).

By contrast, the short answer: At 08.50 would carry only implicit feedback information, and should therefore not be coded in the Auto-Feedback dimension.

It may be noted that feedback elicitation often occur together with auto-feedback acts, since a feedback elicitation act is intended to obtain information about the addressee's processing, and when the addressee provides such information he is performing a dialogue act in the auto-feedback dimension.

It is also worth noting that the LIRICS data categories for feedback do not distinguish different levels of processing at which feedback may be given or elicited, as some other approaches do. (In particular the DIT++ annotation scheme, which distinguishes five levels of feedback: attention, perception, understanding, evaluation, and execution.) The only thing to be annotated is whether a speaker signals a processing problem p(negative feedback) or signals the absence of a processing problem (positive feedback) in his own processing (auto-feedback) or in the addressee's processing (allo-feedback).

Allo-Feedback acts are about the speaker's beliefs about the addressee's attention and processing of an utterance in the speaker's last turn.

The annotation of feedback functions.

Negative feedback, where the speaker wants to indicate that there was a problem in his own or his dialogue partner's processing of a dialogue utterance, is always explicit and as such mostly easy to annotate. Dimension-specific negative feedback acts are for instance expressed in English by I beg you pardon? or Sorry?, which are not expressions of regret but standard ways of saying that something was not understood (or hard to believe). Negative feedback may also be expressed my menas of general-purpose functions, as in I don't understand what you said and in Did you say Thursday?, where an /inform/ act and a /checkQuestion/ are used, respectively, in the auto-feedback dimension).

Positive feedback is sometimes given explicitly, either verbally or nonverbally (for instance by nodding) 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 Task dimension, also a the function /positiveAutoFeedback/ in the Auto-Feedback dimension (see below).

By contrast, the short answer: At 08.50 would carry only implicit feedback information, and should therefore not be coded in the Auto-Feedback dimension.

It may be noted that feedback elicitation often occur together with auto-feedback acts, since a feedback elicitation act is intended to obtain information about the addressee's processing, and when the addressee provides such information he is performing a dialogue act in the auto-feedback dimension.

It is also worth noting that the LIRICS data categories for feedback do not distinguish different levels of processing at which feedback may be given or elicited, as some other approaches do. (In particular the DIT++ annotation scheme, which distinguishes five levels of feedback: attention, perception, understanding, evaluation, and execution.) The only thing to be annotated is whether a speaker signals a processing problem p(negative feedback) or signals the absence of a processing problem (positive feedback) in his own processing (auto-feedback) or in the addressee's processing (allo-feedback).

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, often consists of smaller parts that have a meaning as a dialogue act: functional segments (FSs). Turn Management acts are the actions that participants perform in order to manage this aspect of the interaction. These acts are subdivided into acts for taking the turn (turn-initial acts) and those for keeping the turn or giving it away (turn-final acts). Only the first FS in a turn may have a turn-initial function, and often only the last has a turn-final one. Non-final FSs in a turn only have a turn-final function when the speaker signals (typically in the form of a rising intonation at the end of the FS) that the this FS is not going to be the last one in the present turn, that he wants to continue. In that case the segment has a turn keeping function (/turnKeep/). Except for the first one, the FSs in the turn do not have a turn-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 /turnGive/ act, the utterance should be annotated as having the turn-initial function /turnAccept/ only when the speaker performs a separate act for the purpose of accepting the turn (for instance by saying yes or okay, so don't code this when the turn is accepted implicitly by simply starting to speak.

Similarly, an FS should be annotated as having the turn-initial function /turnTake/ 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 a turn-initial Turn Management function.

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

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; in particular, it may be that the speaker has trouble completing his current utterance, 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. However, don't speculate; only code additional functions for which you have evidence.

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. A Discourse Structure Management function should be assigned only if the speaker explicitly introduces or closes a topic, or signals his intention to do so, or otherwise indicates his plans for the continuation of the dialogue (such as when he says: Question to indicate that he's going to ask a question.

Across the board, the following guideline applies to the encoding of Interaction Management functions: Guideline 6 of the general introduction: "Code only explicit Interaction Management functions." -->

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 Time Management.

Partner Communication Management (PCM) functions should be coded whenever a speaker assists the addressee in formulating an utterance, or 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.

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). also be used to give positive feedback. If that occurs, the utterance should be coded with the appropriate function in that dimension.

In general, when coding an utterance as having a SOM function, look out for additional functions in other dimensions.

Definition: Dimension of those dialogue acts whose...

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.

Example: "What about you?"

A set question corresponds to what is commonly termed a WH-question in the literature. The term set is preferred because: (a) it clearly separates form from function by removing any oblique reference in the label to syntactic criteria for the identification of such acts; and (b) it is not a language specific term (it may be further noted that even in English, not all questioning words begin with 'wh', e.g. "How?").

For example: "What time does the meeting finish?"

A propositional question corresponds to what is commonly termed a YN-question or polarity question in the literature. The term 'propositional' is preferred because: (a) it clearly separates form from function by removing any oblique reference in the label to syntactic criteria for the identification of such acts; and (b) it is not a language specific term.

SWBD-DAMSL for example conflates form and function by distinguishing between propositional questions that are marked explicitly by subject inversion (yes-no questions) and those that are marked by intonation alone (declarative questions). However, though they may have different realisations, these are in fact performing the same function.

For example: "Have you got a haystack on your map?"

For example: "John is coming to the party, isn't he?"

It is less common in annotation schemes to specifically distinguish the concept of choiceQuestions from setQuestions (although it is much more common in more general literature on interrogatives, see for instance: Tsui 1994). However, whereas it is common for the concept setQuestion to carry the expectation that all members of the set with a given property should be returned by the addressee, for an alternativesQuestion the expectation is that there will be exactly one. The different preconditions and effects indicate that these are semantically differing concepts, and they have been treated as such here.

For example: "Are you taking the train to Amsterdam or to Rotterdam?"

For example: "The 6.34 to Breda leaves from platform 2."

For example: (1) "Exactly"(2) "That would be perfect"

For example: "No, that's not right."

For example: "To Montreal, not to Ottawa."

For example: "On Mondays and Thursdays" (in response to the question "On what days does John teach Mathematics?")

For example: "Indeed"

For example: "It's not"

For example: "I will wash the car for you tonight"

For example: "Shall I open the door for you?", "Would you like to have coffee?"

The addressRequest function covers a range of possible responses to a request. If no cidition is attached, then the speaker commits himself unconditionally to perform the requested action; this is the special case of /acceptRequest/. If the condition is attached that the action be performed zero times, then the speaker in fact declines to perform the requested action. See also the data categories for the qualifiers /conditional/ and /partial/.

For example: "Sure"

For example: "Sure"

For example: "No, I can't"

For example: "Let’s do that"

For example: "I don’t think so"

For example: "Please take the rubbish out for me" or "Please turn to page five"

For example: "Go right round, ehm, until you get to just above them."

For example: "Let's wait for the meeting to finish."

For example: "Yes please"

For example: "No thanks"

Related terminology in other schemes: Signal-Understanding (DAMSL), Acknowledge (HCRC MapTask, SWBDDAMSL) Ack (TRAINS) and Feedback_Positive (Verbmobil).This type of feedback could be further broken down into more specific areas (dealing with the sender’s attention, perception, interpretation, evaluation and execution), as exemplified in the DIT schema. Such fine distinctions have hitherto not been made in other annotation schemes however, so a simplified top level data category is defined here.

For example: "Uh-huh"

Related terminology in other schemes: Signal-Non-Understanding (DAMSL) and Feedback _Negative (Verbmobil). This type of feedback could be further broken down into more specific areas (dealing with the sender’s attention, perception, interpretation, evaluation and execution), as is exemplified in the DIT schema. Such fine distinctions have hitherto not been made in other annotation schemes however, so a simplified top level data category is defined here.

For example: "Sorry?"; "What?"; Spanish: "Que?"; Italian: "Como?"

The distinction between whether feedback is about S’s (auto) understanding or A’s (allo) is only made within the DIT scheme. This type of feedback could be further broken down into more specific areas (dealing with the addressee’s attention, perception, interpretation, evaluation and execution).

For example: "You've got it!"

The distinction between whether feedback is about S’s (auto) understanding or A’s (allo) is only made within the DIT scheme. This type of feedback could be further broken down into more specific areas (dealing with the addressee’s attention, perception, interpretation, evaluation and execution).

For example: "No, no, no, no, no"

Feedback elicitation could be further broken down into more specific areas dealing with the addressee’s attention, perception, interpretation, evaluation and execution.

For example: "Okay?"; Italian: "Capisce?"

For example: A: "Would you like to say something at this point?" B: "Certainly."

For example: "Hold on a minute, what about the party?"

For example: "Ehm..." as a turn-initial segment

For example: "You tell the story" or "Adam?", characteristically accompanied by the speaker directing his gaze to Adam, possibly also nodding or pointing in his direction and raising the eyebrows.

For example: "Erm"

For example: Speaker uses declining intonation towards the end of a contribution and subsequently pauses.

For example: "Let me see…", "Erm"

Pausing occurs either in preparation of continuing the dialogue, or because something else came up which is more urgent for the sender to attend to.

For example: "Just a moment"

For example: "Yes?"

For example: "Hey!"

Interaction structuring covers such phenomena as topic introduction, dialogue act announcement and topic closing.

For example: "A question…"

For example: We're going out on Tues- no, er, not Tuesday

For example: "We're going out on Tues- no, er, not Tuesday, Thursday"

For example: S: "which should leave us plenty of time to uhhh", A: "get to city H"

For example: S: "second engine E3 is going to uhh city H to pick up the bananas, back to A, dro…", A: "… H to pick up the oranges", S: "sorry, pick up the oranges"

Greetings usually come in initiative-response pairs within a dialogue; this data category corresponds to the first element of such a pair.

For example: "Hello!"

Greetings usually come in initiative-response pairs within a dialogue; this data category corresponds to the second element of such a pair.

For example: "Hello!"

Introductions usually come in initiative-response pairs within a dialogue; this data category corresponds to the first element of such a pair.

For example: "I'm Jack"

Introductions usually come in initiative-response pairs within a dialogue; this data category corresponds to the second element of such a pair.

For example: "Nice to meet you Jack, I'm Jill"

For example: "Sorry about that."

For example: "No problem"

Utterances used for thanking often also indicate that the sender wants to end the dialogue.

For example: "Thanks a lot."

For example: "Don’t mention it"; Spanish: "De nada".

Goodbyes usually come in initiative-response pairs within a dialogue; this data category corresponds to the first element of such a pair.

For example: "Bye, see you later"

Goodbyes usually come in initiative-response pairs within a dialogue; this data category corresponds to the second element of such a pair.

For example: "Bye, see you later"

For example: "Yes?"

For example: "Hey!"

For example: "That might be a good idea"

For example: "I definitely don’t support that."

For example: "If you’re ready maybe you can start the presentation"

A: "Can we just go over that again"

B: "We have no time, unless you do it very quickly"

For example: "I’ll come no matter what."

For example:A: "I don’t think that would be practical, and it’s expensive too."

B: "It’s certainly expensive."