«up»

Finite State Technologies for Dialogue Processing

Abstract:
To finally close the topic of finite state techniques in Computational Linguistics, we will have a look at another area were they are applied with great success (in addition to morphological processing, see » An Application: Morphology). This is the area of dialogue processing. Again we will see that finite state technology provides simple and efficient tools, but that these tools also have obvious limitations. But then, for a lot of applications simplicity and efficiency clearly make up for many limitations.To give you some background on the topic, we will first discuss a set of general characteristics that a dialogue system should exhibit and give some example dialogues that illustrate why those characteristics are important. In the second part we will have a closer look at how to base dialogue systems on finite state automata (FSA). We will look at a dialogue system for a voice-operated elevator as an example.

Table of Contents

Dialogue Processing
Introduction and motivation of dialogue processing.

FSA-based dialogue systems
A common technique in dialogue processing is the use of a kind of FSA to specify the dialogues that a sysem can handle. The Saarbrücken Computational Linguistics department has a speaking elevator, whose dialogue engine is based on such a FSA. The elevator is the standard elevator in building 17.2. Should you ever come to Saarbrücken, it is a must to have a ride with it. Try to imagine what kind of thing you would expect it to do and see if you can get it to do it. For example, change your mind about the floor you have asked it to take you to and request another floor at different points in the dialogue. Since we don't have the elevator here, here's an example of the kind of dialogue it handles (of course the original Saarbrücken elevator speaks German):
User: Elevator.
System: Which floor do you want?
User: Professor Bill Barry.
System: I'm taking you to the Fifth floor.
User: Thank you.
(Mechanical command execution follows).

An in-depth look at the speaking elevator
This section is about the dialogue engine of the Saarbrücken CL department's speaking elevator.

Examples of required behaviour
The following examples depict dialogue behaviour of the kind that we would like the elevator to simulate. Below each example you find a link to a "solution" -paragraph ("Current state and possibility of extension" ) that discusses whether the speaking elevator at present displays the described behaviour, and if not how complicated it would be to extend its dialogue module accordingly ("description of elevator" ). You also find links to the paragraphs that describe the respective part of the dialogue model.We suggest that you read the examples without immediately clicking on the link to the solution. Try to figure it out from the diagram in » An in-depth look at the speaking elevator and the respective part of the description of the dialogue model first. After you have done this, you can check your conclusions by clicking on the "solution" -link following the examples.

Dialogue characteristic and extension of the elevator
An evaluation of the elevator system.

Summary and Outlook
So what can we say in general about the pros and cons of finite state techniques for dialogue processing? Let's sum up the conclusions we can draw from our case study of the speaking elevator, its capabilities and the perspectives of extending them. After that, we will have a brief look at a two much more ambitious dialogue systems, namely TRAINS and TRIPS. Their behaviour goes far beyond what can be realized with finite state techniques alone.


Exercise

  1. Watch the TRIPS/TRAINS-demo videos referenced in » Beyond finite state techniques. Use the criteria given in » General Dialogue characteristics to evaluate the systems based on these videos and the example dialogue in the same section.
  2. The Philips train information system is a system that gives information on train travels. In this exercise you're asked to experiment with this system.
    1. Dial the following phone number to be connected with the system: 
      0241 604020
      We suggest you do that in groups! Protocol your dialogues.
    2. Try to systematically evaluate the system with regard to the characteristics discussed in » General Dialogue characteristics and the desired behaviour you would like it to depict. Take notes of your results.
    3. Which of the dialogue systems that we have looked into is it closer to; the speaking elevator or the TRAINS system? Justify your opinion by specific examples, where possible.
    4. Try if you can draw an automaton that handles some or even all of your protocoled dialogues.
  3. Give a Prolog-specification of the simple dialogue automaton shown in » A simple FSA example, using the following extensions to our ususal representation scheme:
    • Use write('blabla blubb') as label for edges meant to produce the output "blabla blubb" .
    • Use read('blabla blubb') as label for edges meant to (possibly) ask for input and then to be traversed if the input was "blabla blubb" .
    • Use call(trip(FloorNumber)) as label for edges meant to trigger an action named trip(FloorNumber).
    For this exercise you can assume that the edge labeled "Input understood" in the picture somehow sets a global variable named FloorNumber that can then be accessed by all edges traversed later on.
    How would you describe the language accepted by the FSA you've specified? (Just look at it as if it was one of the usual FSAs that you know from the previous lectures. Can you give a regular expression for it?).
    Describe what extensions to the predicates in recognize.pl become neccessary in order to use them for produce a dialogue based on the automaton you've specified.
  4. [Mid-term project]
    Adapt the predicates in recognize.pl so that they can process specifications of dialogue automata as described above in » Beispiel: EX DIALOGUE.EX.SPECIFYEX_DIALOGUE.EX.SPECIFY. You can use the predicate readAtom/1 from the file readAtom.pl to read input from the keyboard into an atom.
    readAtom.pl: View_DownloadPredicate readAtom/1 for reading keyboard input into an atom.
    Here's an example of what this predicate does: 
    
2 ?- readAtom(A).


|: hallo spencer.

A = 'hallo spencer.' 
Yes
3 ?-
    Include the following code before your program to be able to use the predicate: 
    
:- use_module(readAtom,[readAtom/1]).
    Please let us know if you would like to do this exercise as your mid-term project.
«up»