An Object-Oriented Approach to the Design of Dialogue Management Functionality

Proceedings of EACL '99 An Object-Oriented Approach to the Design of Dialogue Management Functionality Ian M. O'Neill and Michael F. McTear Faculty of Informatics University of Ulster Newtownabbey Co. Antrim BT37 0QB N. IRELAND mf.mctear@ulscac.uk Abstract Dialogues may be seen as comprising commonplace routines on the one hand and specialized, task-specific interactions on the other. Object-orientation is an established means of separating the generic from the specialized. The system under discussion combines this object- oriented approach with a self-organizing, mixed-initiative dialogue strategy, raising the possibility of dialogue systems that can be assembled from ready-made components and tailored, specialized components. 1 Introduction For the purpose of developing automated systems, dialogues may be seen as comprising commonplace routines on the one hand and specialized, task-specific interactions on the other. In software engineering, object-orientation has proved to be an effective means of separating the generic from the specialized, and more particularly, of letting the specialized inherit the generic (Rumbaugh et al., 1991). Identifying inheritable generic functionality (for confirmation, repair of misunderstanding, personalization of utterances, etc.) and specialized or highly domain- specific functionality, opens the way to dialogue systems that can be assembled largely from ready- made components and extended with the addition of more specialized components. The prototype system that we have been developing in Prolog++ for the last year combines this familiar object- oriented approach with a self-organizing, mixed- initiative dialogue strategy. Pseudocode is used here to represent the Prolog processing. 2 Identifying the generic and the specialized In the course of developing the prototype system a number of important generic elements have been identified that can be ported with a minimum of alteration between domains. These generic elements are now introduced. 2.1 Dialogue Manager In any system that is concerned with conducting a dialogue with a user, a mechanism is required for receiving, forwarding for processing, and outputting semantic contents of utterances. This responsibility falls to a Dialogue Manager. 2.2 Domain Spotter Any system that is intended to handle processing across a number of real-world areas of expertise requires a means of associating key semantic content of the user's utterances with one or more of the available domains. This responsibility falls to the Domain Spotter. 2.3 Discourse Stack Any system dealing with a transaction that involves multiple dialogue turns must have a means of logging a) what it believes the user has said, b) the degree of 'confirmedness' of what has been said, and c) how the system has decided to respond. Maintaining a record of the evolving discourse, and providing the means of creating and retrieving entries for individual utterances, are the responsibilities of the Discourse Stack. 23 Proceedings of EACL '99 2.4 Enquiry Processor Given the current difficulties of speech recognition, and the possibility that a user will misunderstand or change his or her mind, any system conducting a complex transaction must have a strategy for confirming the semantic contents of the user's utterances and for proceeding with the transaction only when details have been adequately confirmed. The current …

Content truncated to 500 words