A General, Abstract Model of Incremental Dialogue Processing

Proceedings of the 12th Conference of the European Chapter of the ACL, pages 710–718, Athens, Greece, 30 March – 3 April 2009. c⃝2009 Association for Computational Linguistics A General, Abstract Model of Incremental Dialogue Processing David Schlangen Department of Linguistics University of Potsdam, Germany das@ling.uni-potsdam.de Gabriel Skantze∗ Dept. of Speech, Music and Hearing KTH, Stockholm, Sweden gabriel@speech.kth.se Abstract We present a general model and concep- tual framework for specifying architec- tures for incremental processing in dia- logue systems, in particular with respect to the topology of the network of modules that make up the system, the way informa- tion flows through this network, how in- formation increments are ‘packaged’, and how these increments are processed by the modules. This model enables the precise specification of incremental systems and hence facilitates detailed comparisons be- tween systems, as well as giving guidance on designing new systems. 1 Introduction Dialogue processing is, by its very nature, incre- mental. No dialogue agent (artificial or natural) processes whole dialogues, if only for the simple reason that dialogues are created incrementally, by participants taking turns. At this level, most cur- rent implemented dialogue systems are incremen- tal: they process user utterances as a whole and produce their response utterances as a whole. Incremental processing, as the term is com- monly used, means more than this, however, namely that processing starts before the input is complete (e.g., (Kilger and Finkler, 1995)). Incre- mental systems hence are those where “Each pro- cessing component will be triggered into activity by a minimal amount of its characteristic input” (Levelt, 1989). If we assume that the character- istic input of a dialogue system is the utterance (see (Traum and Heeman, 1997) for an attempt to define this unit), we would expect an incremental system to work on units smaller than utterances. Our aim in the work presented here is to de- scribe and give names to the options available to ∗The work reported here was done while the second au- thor was at the University of Potsdam. designers of incremental systems. We define some abstract data types, some abstract methods that are applicable to them, and a range of possible constraints on processing modules. The notions introduced here allow the (abstract) specification of a wide range of different systems, from non- incremental pipelines to fully incremental, asyn- chronous, parallel, predictive systems, thus mak- ing it possible to be explicit about similarities and differences between systems. We believe that this will be of great use in the future development of such systems, in that it makes clear the choices and trade-offs one can make. While we sketch our work on one such system, our main focus here is on the conceptual framework. What we are not doing here is to argue for one particular ’best architecture’—what this is depends on the particu- lar aims of an implementation/model and on more low-level technical considerations (e.g., availabil- ity of processing modules).1 In the next section, we give some examples of differences in system architectures …

Content truncated to 500 words