Dialogue Management

dialogue into account and interpret the sentence in the context of the plan.

Those models are more powerful than dialogue grammars but goal inference and decision making in the context of plan-based dialogue are sometimes very complex [Bylander, 1991]. Nevertheless, plan-based dialogue models are used in SDSs [Freedman, 2000].

2.4.1.3. Conversational Game Theory

er, 1979] is an attempt to grammars in the

el

ered a dialogue as a product of the e user) and a plan recogniser (the SDS)

e Management

cribed earlier can be used in SDSs in internal state, etc, the dialogue The Conversational Game Theory (CGT) [Pow

include the ideas from both plan-based models and dialogue

same framework. From this point of view, dialogues consist of exchanges called games. Each game is composed with a sequence of moves that are valid according to a set of rules (similar to grammars) and the overall game has a goal planned by participant agents (similar to plan-based models).

Thus, agents share knowledge (beliefs and goals) during the dialogue and games can be nested (sub-dialogues are possible) to achieve sub-goals. In this framework, moves are often assimilated to Speech Acts [Houghton &

Isard, 1987]. The CGT defines quite formally the moves allowed for each of the participants at a given instant in the game (according to the rules and the goal) and thus, allows simulation of dialogues too [Power, 1979].

Computational versions of CGT have also been developed and implemented in working SDSs [Lewin, 2000].

2.4.1.4. Joint Action Mod

The previous approaches consid interaction of a plan generator (th

working in harmony, but it does not explain why participants ask clarification questions, why they confirm etc. Another dialogue model is emerging in which dialogue is regarded as a joint activity, something that agents do together. Participating in a dialogue requires the participants to have at least a joint agreement to understand each other, and this motivates the clarifications and confirmations so frequent in dialogues. This family of dialogue models are of a great interest and have been used in some systems [Edmonds 1993].

2.4.2. Dialogu

Although any of the dialogue models des order to interpret semantics, build

management can be of several kinds. This section will describe some of possible dialogue management methods found in the literature.

2.4.2.1. Theorem Proving

This approach to dialogue management has been developed in [Smith &

f a problem-solving SDS aiming at some lying this method is that the system tries to

In the case of finite-state methods, the dialogue is represented like a state-etween dialogue states specify all legal Hipp, 1994] in the framework o

equipment fixing. The idea under

demonstrate that the problem is solved (theorem). As in mathematical demonstration, there are several steps to follow and at each step, the system can use axioms (things known for sure) or deduction to move on. If in a given step, the WK is not able to provide an axiom to the DM allowing it to go on or if the DM can not deduce it from other axioms, the axiom is considered as missing (missing axiom theory) and the system prompts the user for more information. If the user is not able to provide information, a new theorem has to be solved: ‘the user is able to provide relevant information’. A tutoring sub-dialogue then starts. This technique has been implemented in Prolog as this rule-based method is suitable for Logic Programming. The major drawback of theorem proving management is that the strategy is fixed as the demonstration steps are written in advance.

2.4.2.2. Finite-State Machine

transition network where transitions b paths through the network.

: :

:

;

; :

;

;

Fig. 14: A four-state SDS

In each state an action is chosen according to the dialogue strategy and the result of the action leads to a new transition betw

• None of the values is known.

een states.

For example, let’s imagine a simple SDS that aims at retrieving the first name and last name of the user. Four states are possible like shown on Fig. 14:

• The first name is known and the last name is unknown.

• The last name is known and the first name is unknown.

• Both values are known.

On th f le transitions

betw n le, there are

two s a n values indicating whether or not a value is know ( per square and the last name for the lower

s, for the first name or for the last name or closing

sed in dialogue systems but above all in various toolkits and

-friendly’.

• guages can be very easily used to represent

state-• illing,

e igure, each circle represents a possible state and possib ee states are represented by directed edges. In each circ

qu res representing Boolea n the first name for the up

square). The sign 8 means that the value is unknown and the sign 9 means that the value is known.

The starting state is the one where none of the values is known (the upper state) and the goal is to reach the state where both values are known (the lower state). In each state the DM has the choice between several actions like prompting for both value

the dialogue.

The main drawback of these methods is that all possible dialogues have to be known and described and the structure is quite fixed resulting in inflexible and often system-led behaviours. Nevertheless, state-transition methods have been widely u

authoring environments [McTear, 1998] for several reasons.

• It is an easy manner for modelling dialogues that concern well-structured tasks that can be mapped directly on to a dialogue structure.

• Finite-state method is easier to understand and more intuitive for the designer as a visual, global and ergonomic representation of other management techniques would be difficult to realise. In short, it is more ‘user

• It is much more straightforward to give a visual representation of finite-state as a dialogue is described as a set of states linked by transitions.

• Only user-led systems can’t be described by a finite-state model.

Most of dialogues are generally system-led or mixed-initiative.

Scripting lan

transition networks.

As discussed in [McTear, 1998], lots of applications like form-f database querying or directory interrogation are more successfully processed this way. Those applications are the most popular.

• System-led behaviour is very easy to describe as a state-transition network.

Even if other methods (like self-organised methods) are defin

• itively

-state methods.

2.4.2

Form fil ame-driven, frame-based or slot-based

methods, are mainly used when the application consists in a transfer of to the SDS and when the information can be

chniques, the self-organised management family does not require all the dialogue paths to be specified in

ystem and reaction of the user contributes to

in issues in designing a dialogue strategy is the degree of gue state. Indeed, it seems obvious that the system controls completely the more compliant, nested sub-dialogues may help to gain in flexibility in the finite

.3. Form Filling

ling methods, also called fr information from the user

represented as a set of attribute-value pairs. The attribute-value structure can be seen as a form and the user should provide values for each field (attribute, slot, frame) of the form. Each empty field is then eligible for a prompt from the system to the user. The dialogue strategy aims at filling completely the form and to retrieve values for all the fields. Each field is given a priority defining the sequence in which the user is prompted [Goddeau et al, 1996]. Each of the user’s utterances has then to be processed in order to provide an attribute-value representation of its meaning.

2.4.2.4. Self-Organised

Unlike previous dialogue management te advance. Each action of the s

build a new configuration to which is associated a particular behaviour. There is no need to know how the configuration occurred. This is generally referred to as event-driven dialogue management. One of the more famous attempts to use this kind of dialogue management was the Philips Speechmania software based on the HDDL language (Harald’s Dialogue Description Language, from the first name of its creator) [Aust & Shroer, 1998]. Other attempts were made to use event-driven dialogue management [Baekgaard, 1996] but the complexity of development of such systems overcame their potentialities.