Jean Carletta, University of Edinburgh

Amy Isard, University of Edinburgh

Stephen Isard, University of Edinburgh

Jacqueline Kowtko, University of Edinburgh

Alison Newlands, University of Glasgow

Gwnyeth Doherty-Sneddon, University of Glasgow

Anne Anderson, University of Glasgow

Currently, many researchers are using coding of discourse and dialogue phenomena in collected corpora to study the dynamics of dialogue. This manual describes a coding system based on utterance function, game structure, and higher level transaction structure, which has been applied to a corpus of spontaneous task-oriented spoken dialogues.

1. Introduction

2. The Move Coding Scheme

3. The Game Coding Scheme

4. The Transaction Coding Scheme

5. Transaction Coding Instructions

6. Example Dialogue Structure Coding

The current coding schemes have been applied to the HCRC Map Task Corpus (Anderson et al., 1991), which is a collection of 128 task-oriented dialogues involving approximately fifteen hours of speech. In the dialogues, two participants have slightly different versions of a simple map with approximately fifteen landmarks on it. One participant's map has a route printed on it; the task is for the other participant to duplicate the route. An example route giver map is given in figure 1. The trials balance the familiarity of the speakers --- whether they were acquainted before the experiment --- and whether eye contact was possible between the speakers or was blocked by a thin screen. There was also variation in matching between landmarks on the participants' maps, in opportunities for contrastive stress, and in phonological characteristics of landmark names. Some trials were videoed as well as being tape-recorded.

Three levels of dialogue structure have been devised for the Map Task Corpus, similar to the three middle levels in Sinclair and Coulthard's (1975) analysis of classroom discourse. At the highest level, dialogues are divided into transactions, which are subdialogues that accomplish one major step in the participants' plan for achieving the task.The size and shape of transactions is largely dependent on the task. In the map task, route givers typically divide the route into manageable segments. A typical transaction is a subdialogue which gets the route follower to draw one route segment on the map. Transactions are made up of conversational games, which are often also called dialogue games (Carlson, 1983; Levin and Moore, 1977; Power, 1979), interactions (Houghton, 1986), or exchanges (Sinclair and Coulthard, 1975). All forms of conversational games embody the observation that, by and large, questions are followed by answers, statements by acceptance or denial, and so on. Game analysis makes use of this regularity to differentiate between "initiations" which set up an expectation about what will follow, and "responses" which fulfill those expectations. In addition, games are often differentiated by the kind of purpose which they have, for example, getting information from the partner or providing information. A conversational game is a set of utterances starting with an initiation and encompassing all utterances up until the purpose of the game has been either fulfilled (e.g., the requested information has been transferred) or abandoned.

Games can nest within each other if one game is initiated to serve the larger goal of a game which has already been initiated (for instance, if a question is on the floor but the hearer needs to ask a clarificatory question before answering). Games are themselves made up of conversational moves, which are simply different kinds of initiations and responses classified according to their purposes. All 128 map task dialogues have been game and move coded; to date only a small subset of the corpus has been transaction coded. An example of a dialogue coded for all three levels is given in section 6.

[Figure 1 An example route giver's map.]

The move coding analysis is the most substantial of the coding schemes. It was developed by extending the moves which make up Houghton's (1986) interaction frames to fit the kinds of interactions found in the map task dialogues. The distinctions used to classify moves are summarised in figure 2.

The coding scheme distinguishes the following move types, all of which set up the expectation of a response. Initiating moves often occur at the beginning of a game, where they introduce a new discourse purpose into the dialogue.

2.1.1 The instruct Move.

An instruct move commands the partner to carry out any action other than the one implicit in queries (i.e., "tell me the answer to this question"). The instruction can be quite indirect, as in (4) below, as long as it is obvious that there is a specific action which the instructor intends to elicit (in this case, putting the pen down at the start). In the map task, this usually involves the route giver telling the route follower how to navigate part of the route. Participants can also give other instruct moves, such as telling the partner to go through something again but more slowly. In these and later examples, "G" denotes the instruction giver, the participant who knows the route, and "F", the instruction follower, the one who is being told the route. Editorial comments which help to establish the dialogue context are given in square brackets.

[Figure 2 Conversational move categories.]

2.1.2 The Explain Move.

An explain states information which has not been elicited by the partner. (If the information were elicited, the move would be a response, such as a reply to a question.) The information can be some fact about either the domain or the state of the plan or task.

2.1.3 The Check Move.

A check move requests the partner to confirm information that the checker has some reason to believe, but is not entirely sure about. Typically the information to be confirmed is something which the partner has tried to convey explicitly or something which the checker believes was meant to be inferred from what the partner has said. In principle, check moves could cover past dialogue events (e.g., "I told you about the land mine, didn't I?") or any other information that the partner is in a position to confirm. However, check moves are almost always about some information which the checker has been told. One exception in the map task occurs when a participant is explaining a route for the second time to a different route follower, and asks for confirmation that a feature occurs on the partner's map even though it has not yet been mentioned in the current dialogue.

Note that in example 15, the move marked * is not a check because it asks for new information, but the move marked ** is a check because F has inferred the information from G's prior contributions and wishes to have confirmation.

2.1.4 The Align Move.

An align move checks the attention or agreement of the partner, or his readiness for the next move. At most points in task-oriented dialogue, there is some piece of information which one of the participants is trying to transfer to the other participant. The purpose of the most common type of align move is for the transferer to know that the information has been successfully transferred, so that they can close that part of the dialogue and move on. If the transferee has acknowledged the information clearly enough, an align move may not be necessary. If the transferer needs more evidence of success, then alignment can be achieved in two ways. If the transferer is sufficiently confident that the transfer has been successful, a question such as "OK?" suffices. Some participants ask for this kind of confirmation immediately after issuing an instruction, probably in order to force more explicit responses to what they say. Transferers who have less confidence about the transfer can ask for confirmation of some fact which the transferee should be able to infer from the transferred information, since this provides stronger evidence of success. Although align moves usually occur in the context of an unconfirmed information transfer, participants also use them at hiatuses in the dialogue to check that "everything is OK" (i.e., that the partner is ready to move on) without asking about anything in particular.

2.1.5 The Query-yn Move.

A query-yn asks the partner any question which takes a ''yes'' or ''no'' answer and does not count as a check or an align. In the map task, these questions are most often about what the partner has on the map. They are also quite often questions which serve to focus the attention of the partner on a particular part of the map or which ask for domain or task information where the speaker does not think that information can be inferred from the dialogue context.

2.1.6 The Query-w Move.

A query-w is any query which is not covered by the other categories. Although most moves classified as query-w are wh-questions, otherwise unclassifiable queries also go in this category. This includes questions which ask the partner to choose one alternative from a set, as long as the set is not "yes" and "no". Although technically the tree of coding distinctions allows for a check or an align to take the form of a wh-question, this is unusual in English. In both align and check moves, the speaker tends to have an answer in mind, and it is more natural to formulate them as yes-no questions. Therefore in English all wh-questions tend to be categorised as query-w.

The following moves are used within games after an initiation, and serve to fulfill the expectations set up within the game.

2.2.1 The Acknowledge Move.

An acknowledge move is a verbal response which minimally shows that the speaker has heard the move to which it responds, and often also demonstrates that the move was understood and accepted. Verbal acknowledgements do not have to appear even after substantial explanations and instructions, since acknowledgement can be given non-verbally, especially in dialogue modalities with eye contact, and because the partner may not wait for one to occur. Clark and Schaefer (1989) give five kinds of evidence that an utterance has been accepted: continued attention, initiating a relevant utterance, verbally acknowledging the utterance, demonstrating an understanding of the utterance by paraphrasing it, and repeating part or all of the utterance verbatim. Of these kinds of evidence, only the last three count as acknowledge moves in this coding scheme; the first kind leaves no trace in a dialogue transcript to be coded, and the second involves making some other, more substantial dialogue move.

2.2.2 The Reply-y Move.

A reply-y is any reply to any query with a yes-no surface form which means ''yes'', however that is expressed. Since reply-y moves are elicited responses, they normally only appear after query-yn, align, and check moves.

2.2.3 The Reply-n Move.

Similar to reply-y, a reply to a a query with a yes/no surface form which means ''no'' is a reply-n.

One caveat about the meaning of the difference between reply-y and reply-n: there is a rare class of queries which include negation (e.g., "You don't have a swamp?"; "You're not anywhere near the coast?"). As for the other replies, whether the answer is coded as a reply-y or a reply-n depends on the surface form of the answer, even though in this case ''yes'' and ''no'' can mean the same thing.

2.2.4 The Reply-w Move.

A reply-w is any reply to any type of query which doesn't simply mean ''yes'' or ''no''.

2.2.5 The Clarify Move.

A clarify move is a reply to some kind of question in which the speaker tells the partner something over and above what was strictly asked. If the new information is substantial enough, then the utterance is coded as two moves, a reply followed by an explain, but in many cases, the information added is insubstantial enough that it would be inappropriate to code it as a separate move. Route givers tend to make clarify moves when the route follower seems unsure of what to do, but there isn't a specific problem on the agenda (such as a landmark now known not to be shared).

2.2.6 Summary.

All of these response moves move forward towards the goal proposed by the initiating moves which they follow. It is also theoretically possible at any point in the dialogue to refuse to take on the proposed goal, either because the responder feels that there are better ways to serve some shared higher level dialogue goal or because the responder does not share the same goals as the initiator. Often refusal takes the form of ignoring the initiation and simply initiating some other move. However, it is also possible to make such refusals explicit; for instance, a participant could rebuff a question with "No, let's talk about...", an initiation with "What do you mean --- that won't work!", or an explanation about the location of an object with "Is it?", said with an appropriately unbelieving intonation. One might consider these cases akin to acknowledge moves, but with a negative slant. These cases were sufficiently rare in the corpora used to develop the coding scheme that it was impractical to include a category for them. However, it is possible that in other languages or communicative settings this behaviour will be more prevalent. Grice and Savino (1995) found that such a category was necessary when coding Italian map task dialogues where speakers were very familiar with each other and called the category OBJECT.

In addition to the initiation and response moves, the coding scheme identifies ready moves as moves which occur after the close of a dialogue game and prepare the conversation for a new game to be initiated. Speakers often use utterances such as "OK" and "right" to serve this purpose. It is a moot point whether ready moves should form a distinct move class or should be treated as discourse markers attached to the subsequent moves, but the distinction is not a critical one, since either interpretation can be placed on the coding. It is often appropriate to consider ready moves as distinct, complete moves in order to emphasise the comparison with acknowledge moves, which are often just as short and even contain much the same words as ready moves.

Moves are the building blocks for conversational game structure, which reflects the goal structure of the dialogue. In the move coding, a set of initiating moves were differentiated, all of which signal some kind of purpose in the dialogue. For instance, instructions signal that the speaker intends the hearer to follow the command, queries signal that the speaker intends to acquire the information requested, and statements signal that the speaker intends the hearer to acquire the information given. A conversational game is a sequence of moves starting with an initiation and encompassing all moves up until that initiation's purpose is either fulfilled or abandoned.

There are two important components of any game coding scheme. The first is an identification of the game's purpose; in this case, the purpose is identified simply by the name of the game's initiating move. The second is some explanation of how games are related to each other. The simplest, paradigmatic relationships are implemented in computer- computer dialogue simulations, such as those of Power (1979), Houghton (1986), and Guinn (1994). In these simulations, once a game has been opened, the participants work on the goal of the game until they both believe that it has been achieved or that it should be abandoned. This may involve embedding new games with subservient purposes to the top level one being played (for instance, clarification subdialogues about some crucial missing information), but the embedding structure is always clear and mutually understood. Although some natural dialogue is this orderly, much of it is not; participants are free to initiate new games at any time (even while the partner is speaking), and these new games can introduce new purposes rather than serving some purpose which is already present in the dialogue. In addition, natural dialogue participants often fail to make clear to their partners what their goals are. This makes it very difficult to develop a reliable coding scheme for complete game structure.

The game coding scheme simplifies these issues to those aspects of embedded structure which are of the most interest. First, the beginning of new games is coded, naming the game's purpose according to the game's initiating move. Although all games beginning with an initiating move (possibly with a ready move prepended to it), not all initiating moves begin games, since some of the initiating moves serve to continue existing games or remind the partner of the main purpose of the current game again. Second, where games end or are abandoned is marked. Finally, games are marked as either occurring at top level or being embedded (at some unspecified depth) in the game structure, and thus being subservient to some top level purpose. The goal of these definitions is to give enough information to study relationships between game structure and other aspects of dialogue whilst keeping those relationships simple enough to code.

Transaction coding gives the subdialogue structure of complete task-oriented dialogues, with each transaction being built up of several dialogue games and corresponding to one step of the task. In most map task dialogues, the participants break the route into manageable segments and deal with them one by one. Because transaction structure for map task dialogues is so closely linked to what the participants do with the maps, the maps are included in the analysis. The coding system has two components: (1) how route givers divide conveying the route into subtasks and what parts of the dialogue serve each of the subtasks, and (2) what actions the route follower takes and when. The coding system was devised to be usable by naive coders; the written instructions which are given to them are in section 5.

The basic route giver coding identifies the start and end of each segment and the subdialogue which conveys that route segment. However, map task participants do not always proceed along the route in an orderly fashion; as confusions arise, they often have to return to parts of the route which were previously discussed and which one or both of them thought had been successfully completed. In addition, participants occasionally overview an upcoming segment in order to provide a basic context for their partners, without the expectation that their partners will be able to act upon their descriptions, as in the following transaction:

They also sometimes engage in subdialogues which are not relevant to any segment of the route, sometimes about the experimental setup but often nothing at all to do with the task. Other types of subdialogues are possible (such as checking the placement of all map landmarks before describing any of the route, or concluding the dialogue by reviewing the entire route), but were not included in the coding scheme because of their rarity; each behaviour only occurred once or twice in the 128 dialogues of the Map Task Corpus. This gives four transaction types: ‘normal’, ‘review’, ‘overview’, and ‘irrelevant’. Coding involves marking where in the dialogue transcripts a transaction starts and which of the four types it is, and for all but `irrelevant' transactions, indicating the start and end point of the relevant route section using numbered crosses on a copy of the route giver's map. The ends of transactions were not explicitly coded because, generally speaking, transactions do not appear to nest; if a transaction is interrupted to, for instance, review a previous route segment, participants by and large restart the goal of the interrupted transaction afterwards. It is possible that transactions are simply too large for the participants to remember how to pick up where they left off. Note that it is possible for several transactions (even of the same type) to have the same starting point on the route.

The basic route follower coding identifies whether the follower action was drawing a segment of the route or crossing out a previously drawn segment, the start and end points of the relevant segment, indexed using numbered crosses on a copy of the route follower's map.

[Figure 3] Drawing in the naive transaction coder instructions.

The following is an example of the three levels of dialogue structure coding. Transaction coding is represented on lines which begin with the unique identifiers *A and *B. Each *A line marks the beginning of a transaction and gives the coordinates of the start and end points of the route segment which the route giver is trying to convey by that transaction. (The coding scheme does not allow transactions to overlap, so marking the ends of transactions would be redundant.) Each *A line takes one of the following forms, where things which are underlined are literal:

For normal transactions: *A index point-one,point-two

For review transactions: *A index point-one,point-two r

For non-goal-directed segments: *A index irrelevant

Each index is a unique positive integer; the indices start at 1 at the beginning of each dialogue and increment. In this example, the points are represented as indices to points on the maps as given in figures 4 and 5.

*B lines are placed to the nearest turn where the route follower actually begins to draw the line on the map:

For drawing: *B point-one,point-two

For scribbling out: *B point-one,point-two scribble

Note that because often turns overlap and because drawing can begin between turns, placement of *B lines can only be approximate. Drawing *B lines give the points where the route follower started and ended the line, indexed on a hardcopy of the route giver's map. Erasing *B lines give the points describing the line which was scribbled out at that time.

Game coding is represented on *E and *End lines, representing the start and end of games, respectively; "em" stands for "embedded" and "aban" for "abandoned". "IG" and "IF" designate whether the instruction giver or instruction follower initiated the game. Move coding is represented on *M lines, with the name of the type of move given. An equals sign (=) between two move names means that the coder was unwilling to commit to one or the other and so was "hedging"; this was allowed but discouraged. Overlapped speech is notated loosely by placing angle brackets around the affected turns; where the overlap breaks up a single move, the move coding is given only once, attached to the larger half of the move. Any additional commentary from the coders is placed on *C lines.

[Figure 4 Route giver map for the coding example.]

[Figure 5 Route follower map for the coding example.]

Acknowledgments

This work was completed within the Dialogue Group of the Human Communication Research Centre, funded by an Interdisciplinary Research centre Grant from the Economic and Social Research Council (U.K.) to the Universities of Edinburgh and Glasgow and grant number G9111013 of the Joint Councils Initiative.

References

Anderson, Anne H., Miles Bader, Ellen Gurman Bard, Elizabeth Boyle, Gwyneth Doherty, Simon Garrod, Stephen Isard, Jacqueline Kowtko, Jan McAllister, Jim Miller, Catherine Sotillo, Henry Thompson, and Regina Weinert. 1991. The HCRC Map Task Corpus. Language and Speech, 34(4):351--366.

Carlson, Lauri. 1983. Dialogue Games: An Approach to Discourse Analysis. D. Reidel.

Clark, Herbert and Edward Schaefer. 1989. Contributing to discourse. Cognitive Science, 13:259--294.

Grice, Martine and Michelina Savino. 1995. Intonation and communicative function in a regional variety of italian. In Phonus 1, pages 19--32. Institute of Phonetics, University of the Saarland.

Guinn, Curry. 1994. Meta-Dialogue Behaviors: Improving the Efficiency of Human-Machine Dialogue --- A Computational Model of Variable Initiative and Negotiation in Collaborative Problem-Solving. Ph.D. thesis, Duke University.

Houghton, George. 1986. The Production of Language in Dialogue: A Computational Model. Ph.D. thesis, University of Sussex, April.

Levin, James A. and James A. Moore. 1977. Dialogue games: Metacommunication structures for natural language interaction. Cognitive Science, 1(4):395--420.

Power, Richard J. D. 1979. The organisation of purposeful dialogues. Linguistics, 17:107--152.

Sinclair, John M. and R. Malcolm Coulthard. 1975. Towards an Analysis of Discourse: The English used by teachers and pupils. Oxford University Press.