<?xml version="1.0" standalone="yes"?>
<Paper uid="C92-1053">
  <Title>ORGANIZING DIALOGUE FROM AN INCOHERENT STREAM OF GOALS*</Title>
  <Section position="4" start_page="0" end_page="0" type="metho">
    <SectionTitle>
II REPRESENTING DISCOURSE STRUCTURB
</SectionTitle>
    <Paragraph position="0"> We have chosen conversation MOPS (C-MOPS) \[6; 16\] as the representation for discourse structure in JUDIS. C-MOPS participate in an abstraction hierarchy which allows generalised conventions as well as situation-specific expectations to he represented. A d~namic memory \[7; 14\] can retrieve the most predictive MOP for the current situation.</Paragraph>
    <Paragraph position="1"> A MOPs and C-MOPs A memor~ orgsnization packet (MOP) \[14\] is a schematic structure used to organise long-term, con-Aa research on problem solving continued, &amp;quot;Julia&amp;quot; wits ainu used to refer only to the problem solvers and the dclign of the problem solverl changed. JUDIS receives goal* from * micrC/~ version of the caterer and am input from the keyboard. The goads in the example came as input and reflect the problem solving of systen~ sugge.ted for the catererer architecture, At the tlmC/ that 3UDIS wa. implemented, * complete *nd integrated veralon of the caterer wu not available.</Paragraph>
    <Paragraph position="2"> ceptual, episodic memory. An episode is represented by scenes which have bccn performed to achieve some goal. Episodes are stored in and retrieved from dynamic memory. This memory changes when ueneral~ed episodes are created as individual episodes that share features are stored in memory. The generalizations occur at many different levels forming a hierarchy of generalisations and their specializations, Episodes in dy~ narnic memory are linked by predictive indices, selected feature-value pairs which mark differences between generaliaed episodes and their contributing specialiaations. These indices are followed when an episode is retrieved from dynamic memory, allowing a system to he Ureminded&amp;quot; of MOPs which match some predictive feature of the current situation. We use the term &amp;quot;MOP&amp;quot; to describe both a single episode and an episode with its indices and npecialisations. In the context of being retrieved from memory or Junta, tinted in the template, &amp;quot;MOP&amp;quot; will refer to a single episode. In the context of representations stored in memory, &amp;quot;MOP&amp;quot; includes the indices and specialisatioas.</Paragraph>
    <Paragraph position="3"> When the events stored are conversations, we refer to these structures as conversation MOPs or C~MOPs.</Paragraph>
    <Paragraph position="4"> Kellermann, ei al. \[6\] suggest C-MOPs as the cognitive structures for representing discourse structure.</Paragraph>
    <Paragraph position="5"> C-MOPs can appear as scenes in other C-MOPs, allowing for the recursion necessary in any representation of discourse structure. The scenes of a C-MOP can he given n total or partial ordering to capture the proper sequencing of a conversation. Also, C-MOPs combine intention, in the form of an associated goal, with convention captured by generalised episodes. Kenermann et al.'s experiments suggested that C-MOPs representdeg ing discourse structure are divided into scenes by topic.</Paragraph>
    <Paragraph position="6"> In many ways C-MOPs are like other schemata that capture discourse structure leg., 0; 10\]. Their scenes specify conventional patterns ofdiscourse. These scenes can be either mandatorll or optional. Many types of schemata can be easily tralmlated into a declarative representation that explicitly gives the structure of the conversation and, so, are suitable for building the template. All types of schemata must allow recurstun, so a template built front any type of schemata could be expanded. C-MOPs have one characteristic, however, that makes them particularly useful for organising requests. They participate in a generalisation/apecialisation hierarchy. This hierarchy has two advantages: it allows the heat prediction for a given situation to be returned from memory, and it allows those predictions to be tuned as new information is learned about the situation.</Paragraph>
    <Paragraph position="7"> B The Generalization/Specialization Hierarchy The ability to capture convention in the generalisation/apecialisation hierarchy is important for our work in organising dialogues. In principle, generalisations AcrEs DE COLING-92, NANTES, 23-28 AO6T 1992 3 3 9 PROC. OF COLING-92, NANTES, AUG. 23-28, 1992 are formed as a language user participates in conversation with other language users \[7; 14\]. Because these conversations follow convention, the generalizations of these conversations will represent abstract discourse convention \[6\]. When specific circumstances constrain these conventions, specialhsations are formed and indexed by these circumstances. Consequently, the C-MOP retrieved for a given situation will he the one that is most predictive. 2 The expectations it represents will be shared by other language users, including the other conversant, and will contain ell the information available for the specific situation. Since our research is currently focused on how knowledge of discourse structure can be used to organize goals, instead of on elucidating those structures, JUDIS' C-MOPs and the generaiisation/speciaiisation hierarchy arc hand-coded.</Paragraph>
    <Paragraph position="8"> Our C-MOPs are derived from others' research on discourse structure, where possible. Although JUDIS does not generalize C-MOPs from experience, we have been careful to use a generalization/specialization hierarchy which we believe could have been built from experience.</Paragraph>
    <Paragraph position="9"> One important characteristic of the generalization/specialisation hierarchy is its ability to capture situation specific detail. This ability is especially important given that computers do not think like people.</Paragraph>
    <Paragraph position="10"> Specializations can be used to enumerate the acceptable ways to discuss a topic. The interface can then rely on the appropriate C-MOP to organize the conversation instead of being dependent on the knowledge organization and problem solving methods of the domain reasoners. The specialization can also rule out ways of organizing the dialogue that follow a standard discourse convention but would not be expected by human reasoners. For example, a general problem-solving convention allows for a goal-subgoal ordering \[5\]. However, in meal-planning some orderings seem more acceptable than others. In JUDIS, specialisations for discussing a meal include talking about the main course before the other courses or discussing the meal in chronological order, but a specialization for discussing the dessert first is not included, s The generalization/specialization hierarchy also allows the template to be tuned as the situation changes or new information is discovered. If the new information is an index of a C-MOP, that O-MOP can be replaced with the indexed specialisation. This idea is important for adding new requests to the template. We can think of some cases of adding a request as finding a speciaiization that includes the current request as ~JUDIS' retrieval algorithm \[15\] orders the features mad pursues the indices sequentially until a.n index is not found. This is s departure from traditional implementatlorm of dynamic memory that pttrsue indices &amp;quot;in pared/el&amp;quot; \[cPS, 7\]. Our alSorithm allows JUDIS' memory to return the Jingle C-MOP that, accordlnJ to the ordering, best matches the current situation. l~e~re could be fm-'ther speclallsatlona to allow the dessert to he mentioned first, but we would expect these to arise, and be returned, only under special clrcmnmtance*.</Paragraph>
    <Paragraph position="11"> well an the request that has just arrived. For example, request 6, about avocados, is added to the template as a discussion of the ingredients in guacexnole. When request 7, concerning onions, arrives, the dlecu~ion of the ingredients is specialized to a list that includes both avocados and onions.</Paragraph>
    <Paragraph position="12"> C Conversation MOPs in JUDIS JUDIS relies on C-MOPs to represent all parts of the conversation. This includes C-MOPs for the entire conversation, individual topics, utterances, and question/aaswer sequences. The C-MOPs that are moat important for organizing conversation in JUDIS are the LXST-CMOP and NARRATIVE-CMOP which can be used to organize topics and the TOPIc-CMOP itself.</Paragraph>
    <Paragraph position="13">  specialiscd knowledge about conversations for planning meals and organizes the overall discussion of the meal.</Paragraph>
    <Paragraph position="14"> Some C-MOPs, such as the CXTERER-CMOP, are represented declaratively in memory with topics sad their ordering given explicitly. This makes instsatiating the C-MOP easy and allows the interface to be independent of problem solving knowledge when organizing the dialogue. However, not all C-MOPs should be represented this way. JUDIS also represents some C-MOPs, such as the LIsT-CMOP and the NARRATIV*e-CMOP, procedurally. Explicit representations are created from other knowledge only when such a C-MOP is instantiated. Thin allows JUDIS to create conversations that have not yet been experienced but foilow conventions that have been generalised from experience. It also saves space because JUDIS builds these C-MOPs from world knowledge that is shared with the problem solvers and does not have to explicitly represent all possible CMOPs. null The CATERER-CMOP organizes the discussion of the meal. 3UDIS has very little information about the details of the conversation, but is able to identify the broad topics that are likely to be discussed: OENEaXL-INFOj APPETIZER, MAIN-COURSE and DESSERT. The specialisations are indexed by specific problem solving strategies, main-first and chronological-order, that impose acceptable orderings on the topics.</Paragraph>
    <Paragraph position="15"> The ToPIc-CMOP has three scenes: CHANGE-TOPIC, DISCUSSION, and CLOSE-TOPIC. The change-topic and close-topic are used to mark unexpected moves in the conversation and do not affect how we orgsaise requests in the template. The discussion scene can be a TOPIc-CMOP~ an UTTERANCE-CMOP~ or a QUESTION/ANSWER-CMOP. The sabjecL of the TOPICor DISCUSSION-CMOP tells what the C-MOP will be about. We use this term to avoid confusing the topic of a C-MOP with the Tovlc-CMOP.</Paragraph>
    <Paragraph position="16"> The NARRATIVE-CMOP is a simplified version of Rumelhart's \[13\] story grammar and specifies how to build C-MOPs directly from MOPs in episodic memory.</Paragraph>
    <Paragraph position="17"> ACRES DE COL1NG-92. NAMES, 23-28 AOI~r 1992 3 4 0 PROC. OF COLING-92, NAr,'rES, AUG. 23-28, 1992 To a large extent, the narrative-CMOP is a great deal like the episode in memory which it will relate. All of the scenes in the episode become scenes in the C-MOP and keep their ordering. A setting and a conclusion are added as mandatory scenes. Scenes that satisfy some request of the problem solver are also marked an mandatory, as are unusual scenes which enable them.</Paragraph>
    <Paragraph position="18"> The LIST-CMOP converts values found in a slot of a frame into -roPlc-CMOPs which become its scenes.</Paragraph>
    <Paragraph position="19"> The LlST-CMOP has speclalisations which include an ordering ~ction \[11\]. The predictive feature &amp;quot;infotype&amp;quot; indexes these specialisations. For example, if constructing a list of ingredients, which are divided into main, secondary and spices, a list with the &amp;quot;mainfirst&amp;quot; ordering function is returned. All scenes in LIST-CMOPs used to organize requests are optional. Consequently, only requests from the problem solvers will be included in the conversation. However, there are specializations, retrieved in the context of question answering, that contain mandatory scenes.</Paragraph>
    <Paragraph position="20"> Clearly, JUDIS is limited in the types of dialogues that it can organise by the small number of C~MOPs that are implemented. Most noticeably absent from our list is a general problem-solving C-MOP. We were able to avoid implementing this C-MOP because planning a meal can be seen as filling in values for attributes in a frame and captured in the LIsT-CMOP. In addition, we expect the interface to have enough control over the conversation to ensure that this limited type of problem solving will suffice. In other domains, or if the user were expected to take a more active part in problem solving, a general problem-solving C-MOP would be needed. A problem-solving C-MOP would be more difficult to inatantinte from a procedure than the LISTor NARRATIVE-CMOP. The interface would have to do a great deal of domain planning to make predictions about topics that would be included in the dialogue.</Paragraph>
    <Paragraph position="21"> Some of this effort could be saved by creating only abstract templates and allowing the reasoning followed by the problem solvers to link requests to the template.</Paragraph>
    <Paragraph position="22"> Finding a procedure to create problem-solving C-MOPs without re-creating all of the reasoning needed to solve the problem is an important area of future research.</Paragraph>
  </Section>
  <Section position="5" start_page="0" end_page="0" type="metho">
    <SectionTitle>
III ADDING A RI~QUEST TO TH R TEMPLATg
</SectionTitle>
    <Paragraph position="0"> At the beginning of a meal-planning session, 3UDIS retrieves n C-MOP that is instantiated to become the template. This guides the conversation from beginning to end. The opening and dosing follow well-established sequences, so we are only concerned here with the middle portion of the dialogue where the meal will be discussed. One of the specializations of the CATgRgR-CMOP will be included to predict the middle of the conversation. The template for the example dialogue includes the MAIN-FIRST-CMOP. Requests from the problem solvers are organized into a coherent dialogue by adding them to the template. A new request is added to the template by becoming a scene in a predicted C-MOP. JUDIS first checks to see if the new request matches a request already in the template. If not, the new request is added by merging it into a DISCUSSloN-CMOP already in the template.</Paragraph>
    <Paragraph position="1"> A Finding Potential Topics The first step of adding a new request to a DISGUS$ION-CMOP is finding a C-MOP where the request can be added. A request can be added to a diectmaion when their ,ubjeetl match, when the subject of the refttest is an attribute or value of the subject in the template, or when the new request is associated Ioith the same knowledge structure as the request in the template. Instead of searching semantic memory to find the po~ible connections between requests \[cf. I 4\], JUDIS uses knowledge from the reasoners' problem solving. The problem solvers send the interface two pieces of information with each request. The chain of reasoning from the meal being planned to the attributes that the problem solver wan considering when this goal was created is used to find the subject of the request. If a value appears at the end of the path it is the subject. Otherwise the request asks for a value for the attribute. In this cane, the attribute will be the subject for the purpose of adding the request to the template. The chain of reasoning also allows a request to be linked with any attribute on the chain. The problem solvers also send information about the knowledge structure that was being examined when the goal was created. If the request is associated with a frame, a slot can also be sent. If the request is associated with an episode, the episode and any episodes that contain it, if the problem solver has examined them in association with thin request, are sent to the interface. For example, when a reasoner sends a goal to find out if guacnmole would be appropriate for the appetiser, it also sends guacamole0, the frame representing guacamole in semantic memory, and (meal appetizer main-dich) an the chain of reasoning. 4 We use information from the problem solvers for two reasons. Most importantly, this assures that the consection between the utterances will be acceptable in the context of the current conversation. Also, thin information reduces JUDIS' processing effort and can be easily collected as the problem solvers perform the domain task. Using it, JUDIS can simply match information from the problem solvers instead of searching the semantic memory for all possible connections.</Paragraph>
    <Paragraph position="2"> To rely on information from problem solving, that information must be Ucognitively plausible&amp;quot; in some sense. Information from the same data structures must 4 Guaceanole is placed in the represent Jttlon of the meal as soon as it is cot~sidered by a problem solver and would be the subject of this requeat.</Paragraph>
    <Paragraph position="3"> AcrEs DE COLING-92, NANTES, 23-28 ^o~t' 1992 3 4 1 PROC. O~: COLING-92, N^NrEs, AO(;. 23-28, 1992 appear to human users to be linked. Chains of reasoning followed by the problem solvers must appear to be coherent. If this is not the case for problem solvers used by an interface, it must rely on other knowledge structures to provide it with acceptable links between topics. Also, if the problem solvers do not share semantic memory, there must be a way to match knowledge structures that should be considered the same.</Paragraph>
    <Paragraph position="4"> B Merging Requests into DiJcussiont All requests can he merged into the template for conversation at some level. If no predicted topic could include the request, it can be added to the maintenance phase where it will be handled as a true interruption \[5\]. If a topic which could have included this request has already been dosed, the change-topic scene will mark the return to a previous topic \[15\]. Utterance 14 in Figure 1 is an example of JUDIS returning to a previous topic.</Paragraph>
    <Paragraph position="5"> If problem solver goals on the same subject arrive at the interface sufficiently near each other, they will be grouped together in the template. If not, the topic will be closed before all of the requests that should be associated with it have arrived. JUDIS can return to such topics, so, in the worse case, the conversation is no worse than conversation without the template. If there are not long delays between requests on the same topic, most requests will be merged into the dialogue through a DISCUSSIOH-CMOP.</Paragraph>
    <Paragraph position="6"> JUDIS examines each DISCUSSlON-CMOP in the template until it finds one that can be merged with the new request. It looks at the most specific subjects first so that subjects that are most closely connected will be joined. New requests can be merged with DISCUSSION-CMOPs in several ways: Replace a discussion scene that has no requests as scenes. The simplest form of a DISCUSSION-CMOP is an UTTERANCE or QUESTION/ANSWER-CMOP. These are the forms of a request. If no other requests have been associated with a subject, the discussion-CMOP can be replaced by the new request.</Paragraph>
    <Paragraph position="7"> Extend the reasoning to add a new topic.</Paragraph>
    <Paragraph position="8"> Sometimes the subject of a new request is a very specific aspect of an expected topic. If the request were simply added, the connection between it and the expected topic could be lost. This would cause the dialogue to appear incoherent. It is also difficult for JUDIS to add other requests to a topic which has been filled by a too-specific subject.</Paragraph>
    <Paragraph position="9"> We avoid these problems by adding C-MOPs to the template that extend a discussion from a general sub-ject to a more specific one. We have added a ATTR-VAL-CMOP that links the predicted topic to the more specific request. Each attribute in the chain of reasoning and its value are added to the discussion. Figure 2a shows a request concerning Uavocado&amp;quot; being added to the template by this method. Because it is connected to the appetiser TOPIC-CMOP through specific attributes, another request, 9, can be easily added through the &amp;quot;presentation&amp;quot; attribute. If a specific attribute will be mentioned, the attributes which connect it to the topic can be mentioned first.</Paragraph>
    <Paragraph position="10"> Connect scenes through knowledge structures. Two requests can also be connected because they are part of the same knowledge structure. If both are values in the aarne slot of a frame or are values of the same attribute of the meal being plannedj a LIST-CMOP is used to connect them. If both are scenes in the same episode, a NARRATIVE-CMOP connects them. Here the requests do not have to have the same subject, but are linked to a discussion through one of its scenes. When the type of connection is found, JUDIS searches memory to find the best C-MOP to instantiate. This is done to make sure that any speciailsations appropriate for the current situation are found. For example, the LIsT-CMOP is specialised to have a main-first ordering when ingredients are connected.</Paragraph>
  </Section>
  <Section position="6" start_page="0" end_page="0" type="metho">
    <SectionTitle>
IV&amp;quot; EXECUTING THE TEMPLATE
</SectionTitle>
    <Paragraph position="0"> In conversation new problem solving goals arise as the conversation is being conducted. It is impossible to know all of the goals in advance and then arrange them into the best conversation. Instead, the template must be built and executed simulatneously. This means that the template must reflect a coherent conversation at all times. JUDIS achieves this because each goal is added to the template through C-MOPs.</Paragraph>
    <Paragraph position="1"> The template is only used an a guide to organise conversation. When JUDIS is to take its turn in conversation, it combines information about the priorities of the requests and how those requests lit into the template to choose its next utterance (see \[15\] for details). Sometimes the priorities help determine decisions that are not specified by the template, such ms chosing the scene to execute first in a partially ordered C-MOP.</Paragraph>
    <Paragraph position="2"> Other times a goal is so urgent that the template is overridden.</Paragraph>
  </Section>
  <Section position="7" start_page="0" end_page="0" type="metho">
    <SectionTitle>
V ORGANIZING A DIALOGUE WITH JUDIS: AN
EXAMPLE
</SectionTitle>
    <Paragraph position="0"> Consider utterances 10a-10d in the example dialogue.</Paragraph>
    <Paragraph position="1"> As the arrows indicate, the goals which motivated these requests are rc~organised to make the dialogue coherent. When the initial template in built, JUDIS predicts that the GENERAL-INFO I MAIN-COURSE l APP I~-TIZER and DZSSZRT topics will be included in the dialogue. At this point, JUDIS knows only that the appetiser will be discussed but knows none of the details.</Paragraph>
    <Paragraph position="2"> Then a request to tell the user about a possible failure with avocados comes from the case-based reasoner.</Paragraph>
    <Paragraph position="3"> Since the subject of the request is not the appetiser but one of the ingredients of the appetiser, a path is</Paragraph>
  </Section>
  <Section position="8" start_page="0" end_page="0" type="metho">
    <SectionTitle>
ACTES DE COLING.92, NANTES, 23-28 AoLrr 1992 3 4 2 PROC. OF COLING-92, NAIXrFES, AUG. 23-28, 1992
</SectionTitle>
    <Paragraph position="0"> formed of values and their attributes from the appetizer &amp;quot;roPIc-CMOP to the avocados, as shown in Figure 2a. Next, the from-scratch reasoner discovers that red onions can make guacamole sweeter and decides to send a goal to $UDIS to inform the user. The subject of this reques L &amp;quot;onion&amp;quot;, is also an ingredient in guacamole. When JUDIS tries to insert the request as a value of the ingredient attribute, it must find a structure that will incorporate both the avocado-request, already associated with the ingredients, and the onionrequest which is to be added. JUDIS relies on the information about how the two requests are connected, that they are both values of the same slot of a frame, to begin its search of memory for a C-MOP that can contain both requests. It finds the LIST-CMOP for ingredients and adds a list of all of the ingredients of guacamole to the template (see Figure 2b). The onion and avo~ cado request become the discussions of the onion and avocado ToPIc-CMOPs that are scenes of the new list.</Paragraph>
    <Paragraph position="1"> Next, the request about enchiladas comes from the case-based reasoner. Because this request is associated with the same episode as the avocado request, 3UDIS makes these requests into a narrative (see Figure 2c).</Paragraph>
    <Paragraph position="2"> This narrative contains not only the goal-achieving requests (last part of utterance 10a and utterance 10b), but also the mandatory setting (first half of utterance 10a) and conclusion scenes (utterance 10c).</Paragraph>
    <Paragraph position="3"> The organisation given by the template and the priorities of the requests determine how this portion of the template will be executed. Though not requested by a problem solver, utterance 8 is included in the dialogue to link the ingredients to the expected appetiser topic.</Paragraph>
    <Paragraph position="4"> The narrative containing the avocado and enchilada request has a higher goal priority than the onion request, so it is said first. After the narrative, the onion request is executed to finish the list.</Paragraph>
  </Section>
  <Section position="9" start_page="0" end_page="0" type="metho">
    <SectionTitle>
VI Discussion
</SectionTitle>
    <Paragraph position="0"> JUDIS is an implemented system which embodies our approach for merging goals into an existing conversational structure. JUDIS relies on its knowledge of conventional discourse structure as a tool for achieving the goals of the system. JUDIS' selection of discourse structures to guide the conversation and options taken within those structures are motivated by the goals of the system. This in in contrast to McKeown's TEXT system \[10\] which relies on heuristics based on features of the lmxguage to select options to pursue within a discourse structure. JUDIS is able to re-organise its goals to fit into the global organisation of the conversation because it relies on predictions and commitments for the whole conversation, an represented in the template.</Paragraph>
    <Paragraph position="1"> Other methods of generating language from discourse structure \[e.g., 10; 12\] do not use expectations about the dialogue but rely only on information about the current state of the world and the structure of the discourse to this point.</Paragraph>
    <Paragraph position="2"> One of the most important advantages of our approach is that it allows an incoherent stream of goals to be organised to produce a coherent dialogue. There may be cases where ma occasional utterance still must be marked with a clue word, but s by forcing the goals to hc moderated by the template, we give them a deep structure that provides coherence just as the underlying processing in humans supports their dialogueg' conventional structure. Our approach also has two important advantages that are side-effects of using the template to guide the generation of conversation: The dialogue addresses the needs of the prohlena solvers. JUDIS' dialogue is motivated by the communication goals that it is sent from the problem solvers. The requests which achieve these goals dictate the details of the template. Only requests and the mandatory scenes of the C-MOPs that connect them are included in the dialogue. This assures that the conversation will be coherent without including optional scenes of a schema that are chosen by language-based heuristics which may have little to do with the current domain task \[cf, 10\].</Paragraph>
    <Paragraph position="3"> Utterances which follow convention are included in the dialogue without being motivated by an explicit goal. When mandatory scenes are needed to connect two requests in a coherent dialogue they are included when a new request is merged into the tamp|ate. For example, when two requests are connected by a narrative, the setting, conclusion and enabling scenes are added to the template when the narrative is created. In speech act based approaches \[e.g., 1; 5; 8\], such conventional utterances would be motivated by a speaker's intention. By including these utterances as part of the discourse structure which will achieve the problem solving goals, JUDIS avoids the cost of generating discourse goals and trying to achieve them, Acids DE COLING-92, NANTES. 23-28 AOI~q' 1992 3 4 3 Paoc. OF COLING-92. NANTES, AUG. 23-28, 1992 and it can easily distinguish between utterances that are motivated by goals and those that are mandated by convention.</Paragraph>
    <Paragraph position="4"> The technique for organisation described above was used successfully to organise the dialogue shown in the example and several others from similar goals. JUDIS was also able to interrupt the organization prescribed by the template to handle urgent goals and was able to add requests to the dialogue that did not correspond to topics that were given by the caterer's-CMOP.</Paragraph>
    <Paragraph position="5"> The success of JUDIS depends, in part, on several characteristics of the problem solving domain and the reasoners. Most importantly, JUDIS is an interface to an advisory system. Although JUDIS was designed to allow the user to take more initiative than is often expected in natural language interfaces \[15; 16\], JUDIS' method of organising dialogue is most successful if JUDIS controls the conversation to a large extent. To allow more user involvemen L more C-MOPs would be needed so that JUDIS could build a template for any organization known to the user. JUDIS would also need to handle failure of the template - to identify failure and recover when the template no longer predicts the conversation. This is an important area for future research.</Paragraph>
    <Paragraph position="6"> Another assumption in our implementation of JUDIS is that the problem solvers will use problem solving strategies and knowledge structures which correspond to those used by humans. Although the combined stream of goals from the problem solvers may not be organized in a way that would seem coherent to people, JUDIS can rely on information from the problem solvers to help it build the connections that lead to a coherent conversation. We feel that the method of organization described here could also benefit individual problem solvers that do not produce a coherent stream of communication goals and problem solvers that do not have such well-organised knowledge. In these cases, the interface must keep a separate knowledge base or rely on declaratively represented C-MOPs. This also means that we would loose the advantages of using problem solving information as a basis for organizing the dialogue. null JUDIS is also helped because very few of its goals are urgent. In a system that very often needs to get additional information from the user in order to continue, it may be difficult to make full use of the template. It would be overridden often or it would delay problem solving.</Paragraph>
    <Paragraph position="7"> JUDIS has begun to address the problem of organizing dialogue so that even conversation motivated by an incoherent stream of goals can be easy to understand.</Paragraph>
    <Paragraph position="8"> Most important to our method is the ability to form partial predictions about the dialogue that can be expanded as goals arrive from the problem solver. In this way, 3UDIS can group utterances together to form a coherent whole.</Paragraph>
  </Section>
class="xml-element"></Paper>