One of the most important tasks of the DM is to categorize each user utterance as a move of a certain type. The move categories were again determined based on an analysis of our Wizard-of-Oz data. Figure 3 shows an annotated dialogue fragment including most of the important move categories.
Figure 3: A dialogue fragment annotated with move labels.
For example, in the user:constraint move, the user delimits the
range of possible trips he is interested in. By contrast, in the
user:ask-for-info move the user asks for information about possible
trips, but the queried information does not count as content to be added
to the current constraints on possible trips. The query is a ``side
question'' not contributing directly to the current set of mutually
understood constraints (but may, depending on the answer, lead to a new
constraint). In the user:ask-for-suggestion move, the user asks
for an alternative suggestion without rejecting the previous suggestions
from the system (the user might very well go back and accept a previous
suggestion).
We distinguish between twelve different user moves and roughly the
same number of system moves. The DM catgorizes an utterance as a
certain move by computing a heuristic likelihood score for each move
type, based on the following factors:
The DM has a set of game rules [Power1979] that
constrains the set of possible response moves, given a particular user
move. For instance, currently a user:ask-for-suggestion is always
followed by a system:suggestion or a
system:no-suggestion. The game rules can also easily be changed to
redesign the dialogue structure.
We conjecture that this set of move labels is reusable for a large set
of applications; basically any application where the user gradually
specifies what she wants, the system presents the user with alternative
suggestions, and the user accepts some suggestions and rejects
others. The implementation of the Dialogue Manager is divided into
domain-independent code and domain-dependent code (i.e. code that
directly refers to flights, trains, etc.), and is thus largely
reusable. However, we do not have a separate domain description
language; to modify the Dialogue Manager to work with a new domain, one
has to rewrite the domain-dependent Prolog code.
User: I want to go from Gothenburg to Stockholm on Friday.
user:constraint
System: At what time do you want to leave?
system:ask-for-constraint
U: In the morning. user:constraint
S: There is a train at 5.30 am arriving at 9.45 am.
system:suggestion
U: Is that a direct train? user:ask-for-info
S: Yes. system:answer-with-info
U: Is there a later train? user:ask-for-suggestion
S: There is a train at 6.06 arriving at 9.15.
system:suggestion
U: Fine, I'll take that one. user:accept
Next: The Dialogue Management
Up: Dialogue Management
Previous: Dialogue Management