Pragmatically based dialogue management requires flexible and efficient representation of contextual information. The approach described in this paper uses logical knowledge bases to represent contextual information and special abductive reasoning tools to manage these knowledge bases. One of the advantages of such a reasoning based approach to computational dialogue pragmatics is that the same rules, stated declaratively, can be used both in analysis and generation.

In the PLUS system, contextual information is stored in a set of knowledge bases, represented as logic programs. The most important of these knowledge bases is the Discourse Model, which contains the information derived from the ongoing dialogue. The process of dialogue management, i. e. of interpreting the user’s contributions, planning the system’s actions, and generating appropriate responses, is then conceived as the process of maintaining the contextual knowledge bases (in particular, the Discourse Model) through such knowledge base operations as querying, updating, checking (and restoring) consistency, etc. From a computational point of view, then, the management of dialogue can be seen as a side effect of the process of maintaining the contextual knowledge bases (cf. Gallagher et al 1992). In short, dialogue management is reduced to context management.

In what follows, I will attempt to illustrate the PLUS approach to dialogue management by means of a few simple examples. I will begin by giving a brief overview of the PLUS system (section 2). After that, I will present an extremely simplified version of the Discourse Model, containing only the features that are absolutely necessary to illustrate the basic process of dialogue management (section 3). Finally, in section 4, I will try to show how the process of dialogue management can be implemented through the management of contextual knowledge bases using a set of special abductive update procedures.

Needless to say, the work presented here draws extensively on collaborative work within the PLUS project. Most of these debts are acknowledged through references cited throughout the text. In addition, the paper is based on (so far unpublished) work carried out together with Jens Allwood and Björn Beskow after the completion of the PLUS project. It is also worth mentioning that the discussion of PLUS work contains many simplifications and omissions, mainly due to limitations of space. For a more complete account of the PLUS approach to pragmatics and dialogue management, the reader is referred to Bunt and Allwood (1992), Nivre et al (1992), Bunt et al (1992) and Bego et al (1992).

The PLUS system is meant to be a prototype for an information dialogue system using typed terminal input. It consists of three main components:

The Dialogue Manager is the heart of the system. It receives parsed user input from the NLE, it queries the application database and it generates system responses which are converted into output strings by the surface generator. The Dialogue Manager itself can be broken down into three components:

The World and Application Model is a static knowledge base containing general world knowledge as well as information about the application database. The Discourse Model is a dynamic knowledge base which is built up and modified during the course of a dialogue. The KBMS, finally, is a set of procedures for managing the knowledge bases (querying, updating, consistency checking, etc.).

The tasks of the Dialogue Manager include interpretation of user contributions (given the output of the parser), planning of system actions (such as querying the database), and generation of system responses (which are fed to the surface generator). These tasks are referred to collectively as dialogue management.

The pragmatics-based approach of PLUS entails that dialogue management be based heavily on contextual information. The contextual information includes information in the World and Application Model (static context) as well as information in the Discourse Model (dynamic context). In this paper, I will concentrate exclusively on the use of information in the Discourse Model.

The contextual knowledge bases in the PLUS system are implemented as logic programs. In this section, I will outline a very simple Discourse Model to illustrate the basic principles of this approach. (For the specification of the actual PLUS Discourse Model, see Bunt et al 1992.)

In order to keep track of the dialogue history, we need to record (at least) the following aspects of each contribution (or "utterance") in the dialogue:

These aspects can be specified by simple facts of the following form:

interlocutor(A,B).

The joint effect of these constraints is that every contribution is required to have a verbatim form, a grammatical structure, a propositional content as well as a communicative function in order for the Discourse Model to be consistent.

The Discourse Model (and the other contextual knowledge bases) in the PLUS system are implemented as logic programs. The KBMS tools developed for the management of these knowledge bases support standard operations of asserting and retracting facts from a knowledge base, querying the knowledge base (to find out if a goal is a consequence of the knowledge base) and checking that the knowledge base is consistent.

By means of a few simple examples, I will now try to outline how the process of dialogue management can be implemented through the use of abductive update procedures to maintain a contextual knowledge base of the kind described in the preceding section. I will subdivide the process of dialogue management into three subprocesses:

It is important to note, however, that this is an analytic division which is made primarily for purposes of exposition and which does not correspond in any straightforward way to "system modules". The basic computational process is the same in all three cases, and many of the rules and constraints involved apply across several subprocesses.

Since there are no rules in the Discourse Model which allows the system to prove such facts, they will simply be asserted into the Discourse Model. (In other words, user contributions and their verbatim form can only be observed, they can never be inferred, neither deductively nor abductively.)

Asserting these facts into the Discourse Model will make the knowledge base inconsistent, because of the following constraints (cf. section 3.3):

The important point about these rules is that the attitude goals cannot be proven deductively in the Discourse Model but have to be abduced (if they are compatible with the rest of the system’s knowledge). For example, when the system tries to insert that a certain user contribution is a statement, the update procedures will propose as a possible transaction to assert (i. e. to abduce) that the user believes the propositional content and wants the system to believe the same thing.

If there is no conflict with the rest of the information in the Discourse Model, these attitude facts can be assumed, representing an interpretation of the communicative function of the user’s contribution. If there is conflicting information (the system may know on other grounds that the user does not believe the propositional content), then the abduction is blocked and the system will continue to search for another interpretation. If all interpretations are blocked in this way, the system will be forced to initiate a repair (asking the user what she meant, whether she has changed her mind, etc.).

As we have seen above, the interpretation of a user contribution will typically result in the abduction of a set of user attitudes (beliefs, goals, etc.) in order to restore the consistency of the Discourse Model. However, the addition of these user attitudes will normally generate new inconsistencies, because of constraints relating user attitudes to system attitudes. For example, if the system is meant to be ideally cooperative, then it seems reasonable to require that any goal of the user is also a goal of the system (with certain restrictions that I will not go into here). A cooperativity constraint of this kind would have the following form:

¬want(system,P).

The presence of this constraint in the Discourse Model will guarantee that as soon as the system has inferred that the user has a certain goal, the system will try to insert that it has the same goal. This insertion will generate further system goals, such as the goal to find a certain piece of information in the database and give it to the user, etc. In this way, planning of system actions can be carried out by the same basic process of maintaining the Discourse Model through abductive updates that was used for the interpretation of user contributions.

A very basic requirement on a cooperative dialogue system, is that it should generate a response to every contribution from the user. This requirement can be implemented by adding the following constraint to the Discourse Model:

This constraint will ensure that the addition of a user contribution to the Discourse Model is always followed by the addition of a system contribution. Moreover, once the new contribution has been added, the constraints in (5–8) will come into play again and will drive the generation process further until a fully specified system contribution has been generated. In this way, the same constraints are used to drive both interpretation and generation.

We can then prove the following facts in the Discourse Model:

Now, given the constraint in (11), the system will sooner or later be forced to add a new system contribution to the Discourse Model:

In the present paper, I have tried to illustrate a certain approach to dialogue management based on knowledge base representations of contextual information and reasoning tools incorporating abductive updates. There are still many open problems in relation to the use of abductive reasoning, but I nevertheless think that the approach presented here is interesting enough to merit further attention. Hopefully, I am not alone in thinking this.