File Information
File: 05-lr/acl_arc_1_sum/cleansed_text/xml_by_section/metho/99/p99-1025_metho.xml
Size: 17,305 bytes
Last Modified: 2025-10-06 14:15:27
<?xml version="1.0" standalone="yes"?> <Paper uid="P99-1025"> <Title>Construct Algebra: Analytical Dialog Management</Title> <Section position="5" start_page="191" end_page="191" type="metho"> <SectionTitle> 3 The Construct </SectionTitle> <Paragraph position="0"> A construct is the dialog knowledge representation manager's general vehicle. The task 1An understanding of this algorithm is not necessary for the understanding of the work described in this paper.</Paragraph> </Section> <Section position="6" start_page="191" end_page="191" type="metho"> <SectionTitle> DIAL FOR ME :ORWARD NUMBER </SectionTitle> <Paragraph position="0"> knowledge is encoded as a hierarchy of constructs. The construct itself is represented as a tree structure which allows for the building of a containment hierarchy. It consists of two parts, a head and a body. Figure 1 illustrates a construct example for HMIHY.</Paragraph> <Paragraph position="1"> The DIAL_FOR_ME construct is the head and it has two constructs for its body, FORWARD_NUMBER and BILLING. These two constructs represent the two pieces of information necessary to complete a call. If a user calls requesting to place a call it is the DIAL_FOR_ME construct that is created with the generic BILLING construct and the FORWARD_NUMBER construct with its value set to empty. The dialog manager will then ask for the forward number and for the type of billing method. In figure 1 the dialog manager has received a response to the forward number request.</Paragraph> </Section> <Section position="7" start_page="191" end_page="299" type="metho"> <SectionTitle> 4 Construct Algebra </SectionTitle> <Paragraph position="0"> The construct algebra defines a collection of elementary relations and operations on a set of constructs. These relations and operations are then used to build the larger processing units that we call the dialog motivators. The set of dialog motivators defines the application. In this section we formally define these relations and operations.</Paragraph> <Section position="1" start_page="191" end_page="192" type="sub_section"> <SectionTitle> 4.1 The Construct </SectionTitle> <Paragraph position="0"> Definition 1 Head A head is an ordered pair <name, value>, where name belongs to some set of prede- null fined names, N, and value belongs to some set of predefined values, V. A value may be NULL (not assigned a value).</Paragraph> </Section> <Section position="2" start_page="192" end_page="192" type="sub_section"> <SectionTitle> Definition 2 Construct </SectionTitle> <Paragraph position="0"> A construct is defined recursively as an ordered pair <head, body> where body is a (possibly empty) set of constructs.</Paragraph> </Section> <Section position="3" start_page="192" end_page="194" type="sub_section"> <SectionTitle> 4.2 Relations </SectionTitle> <Paragraph position="0"> The Construct Algebra defines six relations in the set of constructs. In each of the definitions, Cl and c2 are constructs. Note that the symbols C and C, introduced here, should not be understood in their usual &quot;subset&quot; and &quot;proper subset&quot; interpretation but will be described in definitions 4 and 5.</Paragraph> <Paragraph position="1"> Definition 3 Equality Two constructs are equal, denoted cl = c2</Paragraph> <Paragraph position="3"> Definition 3 requires that the heads of c1 and c2 be equal. Recall that the head of a construct is an ordered pair <name, value> which means that their names and values must be equal. A value may be empty (NULL) and by definition be equal to any other value. The equality of bodies means that a bijective mapping exists from the body of cl into the body of c2 such that elements associated with this mapping are equal.</Paragraph> <Paragraph position="4"> Definition 4 Restriction Cl is a restriction of c2, denoted cl C c~,</Paragraph> <Paragraph position="6"> Intuitively, cl can be obtained by &quot;pruning&quot; elements of c2. The second part of the definition, (3f : ...) is what differentiates C from =. It is required that a mapping f between the bodies of Cl and c2 exist with the following properties: are &quot;pruned&quot; from c2 to obtain Cl. * f is 1 to 1. In other words, different elements of the body of O, call them hi, are associated with different elements of the body of c2, call them b2 * The elements of the body of c1 are restrictions of the elements of the body of c2. In other words, bl C_ b2, where bl are elements from the body of Cl and b2 are elements from the body of c2.</Paragraph> <Paragraph position="7"> Figure 2 illustrates an example.</Paragraph> <Paragraph position="8"> Definition 5 Containment cl is contained in c2, denoted Cl C c2, when Cl C_ c2 or (3b2 * body(c2))(Cl C 52) We assume that c1 C c2 either if Cl is a restriction of c2 or if Cl is contained in any element of the body of c2. Figure 3 gives an example. The AMBIGUITY construct represents the fact that the system is not sure whether the user has requested a COLLECT call or a CALLING_CARD call.</Paragraph> <Paragraph position="9"> This would trigger a clarifying question from the dialog manager.</Paragraph> <Paragraph position="10"> (fis 1 to 1 A (Vba * body(c2)))(f(b2)~___b2) The generalization of heads means that the name of c2 is on the inheritance path of cl and their values are equal. Intuitively, c2 is an ancestor of Cl or in object-oriented C ~. terms ~C 1 is-a, 2 Note the similarity of this relation to C. Figure 4 illustrates an example. BILLING is a generalization of CALLING_CARD, or in other words CALL- null This definition simply removes the directionality of __C/---~. In other words, either 'tE 1 iS-a C2&quot; ric generalization of b2. An example is illustrated in figure 5. BILLING is contained in DIAL_FOR_ME and is a symmetric generalization of CALLING_CARD.</Paragraph> </Section> <Section position="4" start_page="194" end_page="299" type="sub_section"> <SectionTitle> 4.3 Operations </SectionTitle> <Paragraph position="0"> We will define this operation in several steps. Each step is a progression towards a more general definition.</Paragraph> <Paragraph position="1"> Definition 9.1 Union of values (vl U v2)</Paragraph> <Paragraph position="3"> Recall that by definition, NULL is equal to any other value.</Paragraph> <Paragraph position="4"> Definition 9.2 Union of heads We define head(c1) U head(c2) only in the case c\] C/-~c2, which is all that is needed for a definition of U.</Paragraph> <Paragraph position="6"> In this definition the head of the resulting construct is the union of the heads of the operands. The body of the resulting construct consists of two parts. The first part is a set of unions (denoted f(b2) U b2 in the definition above) where b2 spans the body of the second operand c2 and f is a mapping from Definition 6. Recall that the mapping f associates elements of the body(c1) with elements of the body(c2) such that f(b2)~-+b2 for b2 * body(c2) so the union f(bj U b2 is (recursively) defined in Definition 9.3. The second part of the body of the resulting construct consists of those elements bl of the body(c1) that no element from the body(c2)maps into through the mapping f. In other words, the second part of the body consists of those elements &quot;left</Paragraph> <Paragraph position="8"> behind&quot; in the body(cl) after the mapping f. Figure 6 illustrates an example. The union operations results in a construct with the head CALLING_CARD and a body that contains both CARD_NUMBER and EXPIRATION. The CARD_NUMBER construct from Cl and c2 can be combined because the value of CARD__NUMBER from cl is NULL. The construct EXPIRATION is added because it does not exist on the</Paragraph> <Paragraph position="10"> represent the union of those constructs that do not satisfy any of the aforementioned conditions. By definition REP has a value of NULL and the body consists of the constructs Cl and e2.</Paragraph> <Paragraph position="11"> its body have the value of 6151 for DEPT. In this example, c2 contains the construct LAST_NAME with the value of Smith.</Paragraph> <Paragraph position="12"> There are 2 constructs on the body of Cl that are in the relation b2 C Cl, in other words have value for LAST_NAME of Smith. Therefore the result is an AMBIGUITY construct with two elements on its body, both with the LAST_NAME value of Smith.</Paragraph> </Section> </Section> <Section position="8" start_page="299" end_page="299" type="metho"> <SectionTitle> 5 Dialog Motivators </SectionTitle> <Paragraph position="0"> A dialog motivator determines what action the dialog manager needs to take in conducting its dialog with a user. The dialog manager for HMIHY currently consists of 5 dialog motivators. They are disambiguation , confirmation, error handling (recovery from misrecognition or misunderstanding and silence), missing information and context switching. VPQ uses two additional motivators, they are continuation and co: Construct used for disambiguation, The disambiguation motivator determines when there is ambiguous semantic information, like conflicting billing methods. Confirmation is used when the SLU returns a result with low confidence. Error handling takes on three forms. There is error recovery when the speech recognizer has likely misrecognized what the user has said (low confidence scores associated with the recognition results), when the user falls silent, and when the user says something the SLU does not expect or does not handle. Missing information determines what information to ask about in order to complete a transaction.</Paragraph> <Paragraph position="1"> Context switching is the ability of the system to realize when the user has changed his/her mind or realizes that it has misunderstood and allows the user to correct it. The continuation motivator determines when it is valid to offer the user the choice to query the system for additional information.</Paragraph> <Paragraph position="2"> Database querying decides when the system has acquired enough information to query a database for the requested information.</Paragraph> <Section position="1" start_page="299" end_page="299" type="sub_section"> <SectionTitle> 5.1 Disambiguation Motivator </SectionTitle> <Paragraph position="0"> Figure 9 illustrate how the disambiguation motivator is created using the Construct Algebra. The disambiguation motivator is called with the current construct c and a set of constructs called CID g that represents information that the user does not know (IDK - &quot;I Don't Know&quot;), in other words, the user explicitly responds to a prompt with the phrase &quot;I don't know&quot; or its equivalent s. 2The phrases chosen are based on trials Input: A sequence of semantic input from the SLU module in response to a prompt Output: Complete construct c (no need for further dialog)</Paragraph> </Section> <Section position="2" start_page="299" end_page="299" type="sub_section"> <SectionTitle> Repeat </SectionTitle> <Paragraph position="0"> For all dialog motivators DMI if DMi applies to c The motivator runs through several checks on the construct c. The first is to check to see if in fact the motivator applies, or in other words if c is a restriction of AMBIGUITY. If it is not then the motivator simply return c without changing it. The second step is to check to see if the ERROR construct is a generalization of CA where CA represents the user's response. The ERROR construct represents an error condition like silence or misrecognition. If it is, then it goes on to next motivator because this motivator does not apply to error conditions. If CA equals the IDK construct then this means that the user did not know the answer to our query and we add the construct used for disambiguation, cQ to the set of constructs C/IDK. If however, CA is in the containment generalization relation with c then the projection operation is applied and the result is returned. If CA is not in this relation then this indicates a context switch on the part of the user and the disambiguation motivator returns CA as the result.</Paragraph> <Paragraph position="1"> All other motivators are constructed in a similar fashion. An application can use these motivators or create new ones that are application specific using the operations and relations of the Construct Algebra.</Paragraph> <Paragraph position="2"> System&quot; VPQ. What can I do for you? User: I need the phone number for Klein.</Paragraph> <Paragraph position="3"> System- I have more than 20 listings for Klein. Can you please say the first name? User: William.</Paragraph> <Paragraph position="4"> System&quot; I have 2 listings for William Klein. Can you tell me the person's work location? User: Bedminster System&quot; The phone number for William Klein is 973 345 5432. Would you like more information? User: No.</Paragraph> <Paragraph position="5"> System&quot; Thank you for using VPQ.</Paragraph> </Section> </Section> <Section position="9" start_page="299" end_page="299" type="metho"> <SectionTitle> 6 Dialog Manager </SectionTitle> <Paragraph position="0"> The input to the dialog manager is a collection of semantic input generated by the SLU.</Paragraph> <Paragraph position="1"> Figure 10 illustrates the algorithm used by the dialog manager. The output is the complete construct c which no longer requires further dialog. The algorithm loops through all the dialog motivators determining which one needs to be applied to c. If it finds a motivator that applies then it will perform the necessary action (e.g. play a prompt or do a database lookup). The algorithm repeats itself to obtain CA (the construct answer). In other words, the construct that results from the action is subject to the dialog motivators starting from the beginning. Once CA has been found to be complete it is combined with c using Construct Algebra to produce a new construct. This new construct c also goes through the loop of dialog motivators and the procedure continues until no motivator applies and the algorithm returns the final construct c.</Paragraph> <Section position="1" start_page="299" end_page="299" type="sub_section"> <SectionTitle> 6.1 Example </SectionTitle> <Paragraph position="0"> To illustrate how the dialog manager functions we will use an example from VPQ.</Paragraph> <Paragraph position="1"> Figure 11 illustrates a sample dialog with the system. The sequence of motivators for VPQ is error handling, confirmation, missing information, database querying and disambiguation. The construct that is created as a result of the user's initial utterance is shown in figure 12. All the information needed to do a database lookup is found in the user's utterance, namely the piece of information the user is seeking and the name of the person. Therefore the first motivator that applies is database querying. This motivator creates the database query and based on the result creates the construct CA. The construct CA is then searched by each of the motivators beginning again with error handling. The motivator that applies to CA is the disambiguation motivator because there are more than 20 people in the database whose last name is pronounced Klein, including Klein, Cline and Kline. The disambiguation motivator searches through CA to determine, based on preset parameters, which piece of information is most useful for the disambiguation process as well as which piece of information the user is likely to know, which is selected when the inheritance hierarchy is designed. For VPQ this includes asking about the first name and work location. In this example the dialog manager searches the database entries and determines that the most discriminating piece of information is the first name. Once the user responds with the first name there are still 2 possible candidates and it asks for the next piece of information which is work location.</Paragraph> <Paragraph position="2"> Had the user not known the work location the system would have read out the phone number of both people since the total number of matches is less than 3. If the number of entries after disambiguation remains greater than 3 the system refers the user to a live operator during work hours.</Paragraph> </Section> </Section> <Section position="10" start_page="299" end_page="299" type="metho"> <SectionTitle> 7 Conclusion </SectionTitle> <Paragraph position="0"> In this paper we have described a novel approach to dialog management. The task knowledge representation defined intuitively and without the need to define call flows in the traditional finite-state approach. The Construct Algebra serves as the building blocks from which the dialog motivators that drive the dialog system are comprised.</Paragraph> <Paragraph position="1"> Building a new application will only require the designer to define the objects (e.g. COL- null hierarchy. The Construct Algebra serves as an analytical tool that allows the dialog motivators to be formally defined and analyzed and provides an abstraction hierarchy that hides the low-level details of the implementation and pieces together the dialog motivators. This same dialog manager is currently being used by two very different applications</Paragraph> </Section> class="xml-element"></Paper>