Dialogue Actions for Natural Language Interfaces

1 Introduction

Users of natural language interfaces should conveniently be able to express the commands and queries that the background system can deal with, and the system should react quickly and accurately to all user input. Among other things this means that the interface must be able to cope with connected dialogue. However, it does not mean that the interface must be able to mimic human interaction. On the contrary, it is erroneous to as­ sume that humans would like to interact with comput­ ers the same way as they communicate with humans ( cf. [Dahlback, 1991b; 1991a; Dahlback and Jonsson, 1992; Dahlback et al., 1993; Krause, 1993]). Human computer interactions have their own sub languages ( cf. [Grishman and Kittredge, 1986]) whose characteristics often allow a much simpler dialogue model than models capturing human interaction.

To illustrate some properties of such human computer interaction consider figure 1. In information retrieval systems a common user initiative is a request for do­ main concept information of a specified object, or set of objects. Utterance Ull illustrates this. The requested domain concept information is the value of the property shape and the domain object is the Ford Fiesta costing 26 800 crowns. Unfortunately the system could not an­ swer the question as the property (shape) is not utilized in the domain, instead, in utterance S12, the system pro­ vides information about its capabilities. In U13 a new request for information on another property of the same domain object is presented. This time the pronoun it replaces the rephrasing of the specification of the object, i.e. the Ford Fiesta costing 26 800 crowns. In utter­ ance U15 the user asks for the same concept information but related to another object, while in U17 the object stays the same but the property is altered . In U19 the property remains the same but this time the user uti­ lizes a definite description to specify an object discussed previously, and originally specified in utterance U11.

The dialogue model presented in this paper does not intend to mimic human conversation. It is based on the observation that for information retrieval applications a common user initiative is a request for domain concept information of a specified object , or set of objects ( cf. [Ahrenberg, 1987]). A dialogue manager utilizing this information when deciding which action to perform for user initiatives concerned with accessing the application will provide efficient and robust user-friendly human­ computer natural language interaction.

2 The Dialogue Manager

A dialogue manager directs a natural language interface and holds information needed by the modules in the in­ terface, including the dialogue manager itself. The Di­ alogue Manager considered in this paper was designed from an analysis of a corpus of 21 dialogues, using five different back&round systems [Ahrenberg et al. , 1990; Jonsson, 1991J, collected in Wizard Oz-experiments [Dahlback et al., 1993] . The Dialogue Manager need to be customized to account for the sublanguage car­ ried out in a specific application. Customization al­ lows us to adapt the behaviour of the interface to the requirements of the application (see Jonsson [1993a; 1993b] for details).

The results presented here are based on the customization of the dialogue manager for three applications, other than those utilized in the design, using a set of 30 new di­ alogues . One of the applications, CARS, allows users to retrieve information from a consumers guide on prop­ erties of used cars . In another application, TRAVEL, the application domain was charter trips to the Greek archipelago. The TRAVEL application not only utilized information retrieval but also, in one scenario, allowed users to order a specified charter trip.

Dialogue management information is modeled in dia­ logue objects. These represent the constituents of the dialogue . A dialogue object has two components. One component contains static information describing the properties and relations of the dialogue object. Another is a process description of a prototypical use of the di­ alogue object, an action plan [Jonsson, 1991]. During the course of interaction a dialogue tree is built up from instances of dialogue objects (For more details on the Dialogue Manager see Jonsson [1993a]) .

Two types of static parameters are distinguished: situ­ ation parameters and content parameters. The situation parameters specify the situation in which the dialogue object occurs, such as Initiator, Responder and contex­ tual information. The content parameters are needed for focus structure and dialogue structure. Focus struc­ ture concerns the recording of entities mentioned in the discourse to allow a user to refer to them in the course of the interaction. Dialogue structure involves handling the relationships between the segments in the dialogue.

U27: what hotels are there on Crete

• S28: Wait ... The hotels in Platanias on Crete are: Kronos, Agrimia, Village Suites and Villa Margarita.

U29: which one is the cheapest

S30: Wait ...

Price Villa Margarita:

4/7 11/7

1 week 2725 2725

18/7

2675

25/7

2625

2 weeks 3272 3275 3225 3175

U31: what is next cheapest

S32: Wait ...

Price Village Suites:

4/7 11/7

1 week 3150 3150

2 weeks 4025 4025

18/7

3100

3975

25/7

3050

3925.

U 33: what service can these hotels provide

S34: Wait ...

The basic price at Villa Margarita includes shared apartment.

Cleaning 3 days/week, no dish-washing. No meals. The basic price at Village Suites includes shared apartment.

Cleaning 3 days/week, no dish-washing. No meals.

Figure 2: Example of dialogue using the TRAVEL system.

2.1 Focus structure parameters

As discussed above, users of information retrieval sys­ tems request database information by specifying a database object, or a set of objects, and ask for the value of a property of that object or set of objects. The di­ alogue objects model database objects using a parame­ ter termed Objects and the domain concept information in a parameter termed Properties. The values to these parameters depend on the background system, and the natural language interface needs to be customized to ac­ count for the demands from each application [Jonsson, 1993b]. For the CARS application a relational database is used and the objects are cars described by the sub­ parameters (Manufacturer, Model, Year). The TRAVEL, application utilizes a hierarchically structured database with the Greek archipelago on top, then the resorts and finally the hotels at each resort. However, it turns out that there is no need to explicitly represent the various levels in the hierarchy. Instead one single sub-parameter holding any of these object types is sufficient. To illus­ trate this, consider figure 2. After utterance U27 the value of the Objects parameter is the resort Crete. This will be changed to a set of hotels when the response from the background system is generated, 528.

The value to the Objects parameter can be explicitly provided as, for instance , it is in show saab 900 of 1985 model. However, this is not often the case. Instead , the user provides only partial information , or a new set of objects by specifying properties, e.g. Show all medium size cars with a safety factor larger than 4. It is also possible to describe new objects by way of other objects, as for example in U27 in figure 2. The Objects parame­ ter will achieve values from such intensionally specified object descriptions by the extensional specification pro­ vided from the database access system.

The Properties parameter models the domain concept in a sub-parameter termed Aspect which can be spec­ ified in another sub-parameter termed Value. For in­ stance, utterance U 17 in figure 1 How fast is a Mercedes 200? provides Aspect information on the domain con­ cept, speed which is specified by the database manager to 160, i.e. the Value of the Aspect speed is 160.

For some applications a third focal parameter is needed, termed Secondary Objects. Its purpose is to re­ strict the search in the database to allow the user to in­ vestigate objects from a subset of objects one at a time as exemplified in figure 2. The user picks out the set of hotels at the resort but is only interested in a subset of them. If we apply the principle that hotels are appended to the Objects parameter if the resort remains the same, the Objects parameter will hold the subset requested in U33. However, to restrict the database search in U31 to the set specified in S28, Secondary Objects is needed to hold the subset from which individual objects are inves­ tigated.

The focus parameters are properties of discourse seg­ ments ( cf. [Zancanaro et al. , 1993]), not moves . Focus is maintained using a simple copying principle where each new dialogue object is instantiated with a copy of the focus parameters from the previous dialogue object ( cf. [Seneff, 1992]) . This forms the initial context for the di­ alogue object and is updated with new information from the user initiative and the response from the background system.

The details on how to update the focal parameters vary and need to be considered when customizing the dialogue objects for a specific application. For instance, consider the system response S18 in figure 1. This re­ sponse does not only contain the requested information on the Aspect sub-parameter top speed. It also provides information on the Aspect sub-parameter rust specified in the previous user initiative. If the value to the Objects parameter remains the same (or is a subset of the pre­ vious value), the value to the Properties parameter will be the conjunction of the previous value and the new values provided in the new mcive. This principle is ap­ propriate when information is presented in tables allow­ ing additional information to be presented conveniently [Ahrenberg et al., 1993] .

2.2 Dialogue structure parameters

The dialogue is divided into three main classes on the basis of structural complexity. There is one class corre­ sponding to the size of a dialogue, another class corre­ sponding to the size of a discourse segment and a third class corresponding to the size of a single speech act, or dialogue move. Utterances are not analyzed as dialogue objects, but as linguistic objects which function as vehi­ cles of one or more moves. There are various other pro­ posals as to the number of categories needed. They differ mainly on the modeling of complex units that consist of sequences of discourse segments, but do not comprise the whole dialo~ue. For instance , LOKI [Wachtel, 1986] and SUNDIAL [Bilange , 1991] use four. In LOKI the levels are: conversation, dialogue, exchange and move. SUN­ DIAL uses the categories Transaction level, Exchange level, Intervention level and Dialogue Acts. The feature characterizing the intermediate level (i.e. the Dialogue and Exchange levels respectively in Wachtel's and Hi­ lange's models) is that of having a common topic, i.e. an object whose properties are discussed over a sequence of exchanges . However, as illustrated in figure 1, a se­ quence of segments may hang together in a number of different ways; e.g. by being about one object for which different properties are at issue. But it may also be the other way around, so that the same property is topi­ cal, while different objects are talked about ( cf. [Ahren­ berg et al., 1990]). Thus, only one discourse segment category is distinguished and an Initiative-response (IR) structure is assumed ( cf. adjacency-pairs [Schegloff and Sacks, 1973]) where an initiative opens a segment by in­ troducing a new goal and the response closes the segment [Dahlbii.ck, 1991b] .

To specify the functional role of a move we use the parameters Type and Topic.

Type corresponds to the illocutionary type of the move . For so-called simple service systems 1 two sub­ goals can be identified [Hayes and Reddy, 1983, p. 266]: 1) specifying a parameter to the system and 2) obtaining the specification of a parameter . Initiatives are catego­ rized accordingly as being of two different types: 1) up­ date, U, where users provide information to the system and 2) question, Q, where users obtain information from the system. Responses are categorized as answer, A, for database answers from the system or answers to clari­ fication requests. The Dialogue Manager utilizes other Type categories such as Greeting, Farewell and Discourse Continuation (DC) [Dahlback , 1991b] the latter being used for utterances from the system whose purpose is to keep the conversation going, but they will not be further considered in this paper.

Topic describes which knowledge source to consult . For information retrieval applications three different knowledge sources are utilized : the database for solving a task (T), acquiring information about the database, system-related, (S) or, finally, the ongoing dialogue (D). If the background system allows ordering of a specified item a fourth category is needed to account for such ut­ terances.

The Type/Topic parameters can be used to describe the dialogue structure, i.e. which action to be carried out by the interface. This in turn can be modeled in a dialogue grammar [Jonsson, 1993a].

3 Actions for task-related initiatives

Normally a natural language interface to database in­ formation retrieval applications is user-directed, i.e. the user initiates a request for information from the back­ ground system and the interface responds with the requested information. The interface only takes the initiative to begin a clarification request under three circumstances 2 :

1 Simple service systems "require in essence only that the customer or client identify certain entities to the person pro­ viding the service; these entities are parameters of the ser­ vice, and once they are identified the service can be provided" [Hayes and Reddy, 1983, p. 252].

• a difficulty arises when interpreting an utterance, e.g. unknown words or questions outside the domain of the database.
• a difficulty arises when accessing the database, e.g. when the user needs to provide a parameter for cor­ rect access.
• a difficulty arises in the presentation of the result from the database access, e.g. the answer is too large to print on one screen.

The action to be carried out for task-related questions depends on how the information in the user initiative together with the information copied from the previous IR-unit and context information from the dialogue tree and the answer from the database system specify the values to the focal parameters Objects and Properties. This contrasts with other structural based approaches, such as Sitter and Stein (1992], where the user 's pur­ pose is considered primary when deciding which action to carry out. An object or property description can be either : correct, partly correct, incompatible, ambiguous, erroneous, or not provided. Erroneous means that the user has specified an object which is not in the database. Partly correct means that the description contains at least one correct object or property description, but also one or more erroneous descriptions. Incompatible de­ scriptions utilize elements which do not belong together, e.g. Volvo Camry.

The relation between the values to the Objects and Properties parameters and the resulting action described in terms of Type and Topic is summarized in table 13. Any combination of Objects and Properties in a cell in a row results in the action to the right. From the table we

2 The system also takes the initiative to collect ordering information.

3 When presenting the dialogue actions, Topic type will be indicated with a subscript to the Type, e.g. Ar denotes a task-related answer. IR-units are presented as a TypeTopic­ pair with the Initiative separated from the Response by a slash (/) .

• Ul7: which 10 car models between 60 000 and 70 000 crowns are most spacious
• Sl8: Wait ...

Checking ...

Information on space is either coupe or boot . Please be more specific.

Ul9: best coupe

Figure 3: Example of ambiguous Aspect resulting in a clarification request.

can identify three basic actions to task-related IR-units depending on the values of the parameters Objects and Properties: Ay, As, and QDIAD Ay .

• Ar is the normal action following a Qy . This de­ scribes a successful task-related user initiative fol­ lowed by a successful system answer with informa­ tion taken from the database. This requires correct values for both Objects and Properties. The values for these parameters can be taken either from the preceding dialogue or they could be provided in the user input . What is important is that the initiative in context provides enough information so that it can be used to access the background system and that the answer from the background system is in some sense correct. A special case is when no ex­ plicit Objects description is provided but the Proper­ ties are fully specified and can be used to access the database, e.g. show all medium class cars costing less than 70 000 crowns.

If the parameters Objects or Properties are partly correct, i.e. contain one or more erroneous items, then an answer is presented on the correctly spec­ ified items together with information about what was erroneous, if possible.

• Q DIAD Ar is to be considered as a special case of the normal Ay-action as specified above . This category is concerned with cases where the system initiates a clarification subdialogue to achieve more information from the user in order to get fully and correctly specified values to Objects or Properties. If the user decides not to answer the clarification re­ quest, then the values from the initiating IR-unit are copied to the new IR-unit and interaction proceeds from there. The treatment of multiple sequential clarifications follows the same pattern as that for one clarification subdialogue.

A clarification subdialogue can be initiated when the Objects are correctly specified but the values of the Value slot to the Properties are erroneous or under-specified. For instance, in remove all cars with low operational safety the expression low is too vague. Another case is where no Aspect is provided or the provided Aspect is ambiguous . The latter is illustrated in utterance U17 in figure 3.

Such cases are handled by a system initiated clar­ ification sub dialogue, a Q DIAD , directed from the IR-unit which started the interaction, normally a Qy, with the under-specified or ambiguous property copied from the initiating IR-unit. The Aspect slot is used to hold the parameter for which the sys­ tem wants an answer and the Value slot is used for the user's answer. If the user answers correctly, as in U19 in figure 3, the values for Properties in the initiating IR-unit are updated. A Q D / Av-unit is identified from the type information, i.e. the Type of the response from the user is A. Otherwise the user move is regarded not to be an answer to the systems clarification request. A clarification subdi­ alogue is not initiated unless the system is able to explicitly provide alternatives to the user.

A special case of clarification request occurs when a correct specification of the parameters Objects and Properties is provided, but the answer is too large to print on the screen. In such cases the system ini­ tiates a clarification subdialogue asking the user to restrict the number of items to be printed, for exam­ ple, S2: Wait ... There are 76 car models which sat­ isfy your requirements. CARS normally only shows 25 cars at a time. Do you want to see them all?. The answer can be either a number, a restriction such as U3: remove cars costing less than 40 000 crowns, or Yes or No. It is used to restrict the num­ ber of objects to output on the screen and also in some cases affect the values of the Objects parame­ ter.

• As is used for task-related user initiatives result­ ing in a system answer which provides information about the database system. Information can be pro­ vided on various aspects of what type of information there is in the database and what type of questions that can be used to elicit this information. A typical example is Cars cannot answer questions concern­ ing the shape of car models. An As is utilized for any utterance with erroneous Objects or Aspect . In­ compatible Properties and Objects also result in an As, this means that although both Properties and Objects are correct, they cannot be used together.

To illustrate the action scheme consider utterance U 11 What is the shape of Ford Fiesta costing 26 800 crowns? in figure 1. This will be interpreted as a task-related question, a Qr, with correctly specified Objects parame­ ter. However, the Aspect sub-parameter is erroneous, as there is no information in the database on the concept shape. Furthermore, the system can not provide alter­ natives to the user. Thus, the resulting action is an As, S12. The next user utterance, U13, is a Qr with both correct Objects , as copied from the previous IR-unit, and correct Aspect sub-parameter, rust. Thus, the resulting action is an Ar, S14.

It is not always possible to directly use the values in the Objects and Properties slots, even if correctly spec­ ified. For applications such as TRAVEL, with hierarchi­ cally structured databases the Dialogue Manager some­ times needs to search the domain base or the dialogue tree to find an applicable object or property. For in­ stance, if the user in the dialogue in figure 2 asks for con­ cept information on properties associated with resorts, such as climate, when the hotels are in focus, the domain model is utilized to find the appropriate resort.

There are user initiatives which do not depend on the values of Objects and Properties , such as system-related questions, Qs, i.e. the user requests information about the system. These are recognized on the grounds of lin­ guistic information provided by the syntactic/semantic analyzer [Ahrenberg, 1988] .

If ordering is allowed it is important to know which task is currently being performed, exploring the database or ordering. This problem has been discussed by, for instance, Ramshaw [1991], and Lambert and Car­ berry [1991] . They present models using three different, but interacting, levels of plans to know when users stop exploring different plans and instead commit themselves to one plan. However, a result emerging from the analy­ sis of our dialogues [Jonsson , 1993a] is that the subjects clearly signal when they change plan, using utterances such as I would like to order a trip for two to Lefkada. Thus, retrieval of ordering information from the users can be collected in a formalized fashion controlled by the system, (cf. [Hoeppner et al., 1986]).

4 Results

Dialogue objects has been customized to meet the de­ mands of the three systems discussed above: CARS and TRAVEL with and without ordering. The customized di­ alogue objects for the CARS system has also been inte­ grated with an INGRES database and interpreting mod­ ules using a grammar and a lexicon covering a subset of the utterances found in the corpus. A context free grammar with less than 20 rules can accurately model the dialogue structure utilized in the corpus . The prin­ ciple of copying information from one dialogue object to the other provides the correct context for most referring expressions . For CARS only 5% required a search in the dialogue tree. The corresponding numbers for TRAVEL were 6% for information retrieval and 2% if ordering is utilized (For more details on the results from customiz­ ing the dialogue and focus structures, see Jonsson [1993a] and Ahrenberg et a/. [1993]) .

The action scheme presented in table 1 covers all task­ related user initiatives utilized in the corpus. In the CARS application 85% of the user initiatives are task­ related questions. In the TRAVEL application without or­ dering the number of task-related user initiatives account for 93% of the user utterances and finally when ordering is allowed 90% of the user utterances are task-related. The other user initiatives are system related questions, farewells, greetings, etc which are interpreted from lin­ guistic information . Thus, a majority of the users' ini­ tiatives are task-related and will be handled efficiently and accurately using the action scheme.

5 Discussion

The Dialogue Manager presented in this paper is re­ stricted to written human-computer interaction in nat­ ural language. However, when communicating with a natural language interface, a user should not be limited to typed keyboard input and screen output. The possi­ bilities of using various modalities must be addressed to further improve the interaction. Examples of systerns which use a variety of modalities for both inter­ pretation and generation include AlFresco [Stock, 1991], XTRA [Wahlster, 1991], Voyager [Zue, 1994] and CUBRI­ CON [Neal and Shapiro, 1991].

The main difference between multi-modal interfaces to simple service systems and conventional natural lan­ guage interfaces to such applications is their ability to utilize a combination of input and output modali­ ties such as speech, graphics, pointing and video out­ put. Thus, more advanced interpretation and generation modules are required and principles for determining how to utilize each media are needed [Arens et a/., 1993].

However, the dialogue and focus structures need not necessarily be more complicated. For instance, Voyager [Zue, 1994] successfully utilizes the approach presented here of copying the focus parameters from one segment to the other [Seneff, 1992]. Sitter and Stein [1992] present a model for dialogue management to information-seeking dialogues. The model assumes that conversation is based on possible sequences of dialogue acts which are modeled in a transition network. In Stein and Thiel [1993] the model is extended to handle multi-modal interaction as utilized in the MERIT system [Stein et a/., 1992].

Thus, it seems that for simple service systems, the dia­ logue model presented here will be sufficient not only for natural language interfaces but also interfaces utilizing various other modalities. However, for task-oriented di­ alogues, where the user's task directs the dialogue [Loo and Bego, 1993], a model of this and the user's goals need to be consulted in order to provide user-friendly interaction ( cf. [Burger and Marshall, 1993]). This does not imply the necessity of a sophisticated model based on the user's intentions. Utilizing a hierarchical struc­ ture of plans based on the various tasks possible to carry out in the domain might do just as well ( cf. [Wahlster et a/., 1993]).

6 Summary

Nat ural language interaction will be more robust and habitable if the users can participate in a coherent dia­ logue with the system. For natural language interfaces to information retrieval applications the necessary dialogue actions can be determined using a straightforward solu­ tion. Users specify a database object, or set of objects, and ask for domain concept information of that object or objects. This is modeled in two parameters, one asso­ ciated with the objects and another with the requested properties of that object. The parameters are specified from information in the user initiative, the discourse and the background system and its domain model. The ac­ tion to be carried out by the interface can be determined from the specification of these objects and properties pa­ rameters .

Acknowledgments

This work results from a project on Dynamic Natural­ Language Understanding supported by The Swedish Council of Research in the Humanities and Social Sci­ ences (HSFR) and The Swedish National Board for In­ dustrial and Technical Development (NUTEK) in the joint Research Program for Language Technology. The work has been carried out with the members of the Nat­ ural Language Processing Laboratory at Linkoping Uni­ versity, Sweden, and I am especially indebted to Lars Ahrenberg, Nils Dahlback and Ake Thuree.