Browse Prior Art Database

A Method of Communicating With a Backend Server From a Dialog System

IP.com Disclosure Number: IPCOM000012950D
Original Publication Date: 2001-Nov-10
Included in the Prior Art Database: 2003-Jun-11
Document File: 2 page(s) / 65K

Publishing Venue

IBM

Abstract

A common paradigm for controlling mixed-initiative conversational dialogs is the object-oriented notion of a form. A form contains a list of required and optional parameters called slots. The form system interacts with a backend server as slots become filled to validate the values, and eventually to instruct the backend system to implement the completely specified transaction. Forms have been used in the aritificial intelligence community for years [1] [2]. Usually the architecture of form-based conversational systems takes a back seat in comparison to the more elegant issues involved in the goal planning and dialog components. But in real systems, the backend is usually a server for which there is an existing application programming interface (API). The form system must communicate with the backend through the API. Thus it is important to have a mechanism in the form system to communicate with the backend at any point the form system needs to. Here we introduce the notion of a Coherency Message for this purpose: CoherencyMsg : [required] [inhibitedby] [freshness] The semantics of the coherency message are as follows: The contains the name of the coherency message, and is used only for debugging purposes. The is required, and contains the text of the message sent to the backend server. This message can include slot variables from the form. All slots mentioned in the message are required to be filled unambiguously for the coherency message to be constructed and sent to the backend. However, the required= can be used to make certain slots optional. In this case, the uses NULL for the interpolated slot value. The required argument is optional. If present, it lists combinations of slots that are required to be unambiguously filled in order for the message to be constructible. For example, if the required argument contained "required='$A,$B;$C,$D'", this would mean that if either slots A and B are unambiguously filled, or slots C and D are unambiguously filled, then the coherency message will be constructed and sent to the backend. If the uses slots that do not have values, then NULL is used instead of the actual value. The inhibitedby argument is optional, and is the opposite of required. The inhibitedby blocks the sending of this message should certain combinations of slots be filled. The freshness argument is optional, and controls how often the coherency message is constructed and sent. If the freshness is set to 0, this means the the coherency message will be sent each turn with the user, provided the conditions mentioned in the required and inhibitedby arguments are satisfied. If the freshness is set to a number n>0, then this means that the message is only sent for n turns after the required and inhibitedby conditions are met. The counter is reset should a slot be refilled with data from the user's query. The most common situation is freshness=1, which means to send the coherency message each time a slot gets refilled with a value (whether new or old) Coherency messages are similar to the VoiceXML filled messages [3]. The latter do not include the [inhibitedby], the [freshness], and also require at least one slot to be required in the . We have found that allowing coherency messages that use no slots is a valuable enhancement. This allows, for example, introductory messages to be played to the user when the form gets focus from the dialog manager or to fill in slots with default values.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 50% of the total text.

Page 1 of 2

A Method of Communicating With a Backend Server From a Dialog System

   A common paradigm for controlling mixed-initiative conversational dialogs is the object-oriented notion of a form. A form contains a list of required and optional parameters called slots. The form system interacts with a backend server as slots become filled to validate the values, and eventually to instruct the backend system to implement the completely specified transaction. Forms have been used in the aritificial intelligence community for years [1] [2]. Usually the architecture of form-based conversational systems takes a back seat in comparison to the more elegant issues involved in the goal planning and dialog components. But in real systems, the backend is usually a server for which there is an existing application programming interface (API). The form system must communicate with the backend through the API. Thus it is important to have a mechanism in the form system to communicate with the backend at any point the form system needs to. Here we introduce the notion of a Coherency Message for this purpose:

CoherencyMsg <name> : [required] [inhibitedby] [freshness] <messagebody> The semantics of the coherency message are as follows:

The <name> contains the name of the coherency message, and is used only for debugging purposes. The <messagebody> is required, and contains the text of the message sent to the backend server. This message can include slot variables from the form. All slots mentioned in the message are required to be filled unambiguously for the coherency message to be constructed and sent to the backend. However, the required= can be used to make certain slots optional. In this case, the <messagebody> uses NULL for the interpolated slot value. The required argument is optional. If present, it lists combinations of slots that are required to be unambiguously filled in order for the message to be constructible. For example, if the required argument contained "required='$A,$B;$C,$D'", this would mean that if either slots A and B are unambiguously filled, or slots C and D are unambiguously filled, then the coherency message will be constructed and sent to the backend. If the <messagebody> uses slots that do not have values, then NULL is used instead of the actual value. The inhibitedby argument is optional, and is the opposite of required. The inhibitedby blocks the sending of this message should certain combinations of slots be filled. The freshness argument is optional, and controls how often the coherency message is constructed and sent. If the freshness is set to 0, this means the the coherency message will be sent each turn with the user, provided the conditions mentioned in the required and inhibitedby arguments are satisfied. If the freshness is set to a number n>0, then this means that the message is only sent for n turns after the required and inhibitedby conditions are met. The counter is reset should a slot be refilled with data from the...