ORGANIZING DIALOGUE FROM AN INCOHERENT STREAM OF GOALS* 
ELISE H. TURNER 
Department of Computer Science 
University of New Hampshire 
Durham, NH, 03824 
USA 
Abstract--Human discourse appears coherent when it re- 
fleets coherent human thought. However, computers do not 
necessarily store or process information in the same way 
that people do a.ud~ therefore, cannot rely on the structure 
of their reuouing for the structure of thehr dialogue,s. In- 
stead, computer-generated conversation must rely on some 
other mechanism for its orgsaiisation. In this paper, we 
discuss one such mechanism. We describe a template that 
provides a guide for conversation. The template is built 
from schemata representing discourse convention. As goals 
arrive from the problem solver they are added to the tem- 
plate. Because accepted discourse structures are used to 
connect a new goal to the existing template, goals are or- 
ganiaed into sub-groups that follow conventional, coherent 
patterns of discourse. We present JUDIS, an interface to a 
distributed problem solver that uses this approach to orga- 
nise dialogues f~om an incoherent stream of goals. 
I INTRODUCTION 
Conversation seems coherent and is easy to follow be- 
cause it reflects the way people think. When the 
speaker thinks coherently, his or her communication 
goals will be properly organised to follow linguistic con- 
vention. So s models of human language generation can 
allow domain goals to directly motivate conversation 
and add clue words only when the occasional utterance 
violates convention \[5; 8\]. 
However~ computer-generated conversation cannot 
rely on problem solving for its organisation. Some prob- 
lem solvers make no attempt to be "cognitively plausi- 
ble" and do not produce goals in sequences that would 
appear coherent to human users. The combined goals 
from a distributed problem solver where several inde- 
pendent reasoners use a single interface to communicate 
with the user are also likely to be incoherent. Even if 
individual problem solvers produce coherent streams of 
goals, the stream of goals from the aggregate is likely 
to switch back and forth between sub-problems that 
are being addressed by the individual systems. We call 
* Some of the work described in this paper was done at the Com- 
puter Science Depaxtment of Georgia Institute of Technology, 
AtlJnts, Georgia, 30332, supported by the NSF under llrmat 
lST-S608362. The &uther wishes to thank the anonymous re- 
viewers for their comments. 
the sequence of goals produced by such systems an in- 
coherent stream of goab because the goals are ordered 
in a way that would not seem reasonable to a human 
listener. Interfaces to such systems, while being re- 
sponsive to the goals of problem solving, must rely on 
something else to give dialogue its organisation. 
In this paper, we describe a template that can provide 
computer-generated conversation with a coherent orga- 
nisation while meeting the needs of the problem solvers. 
This template is built from schemata representing ex- 
pected discourse structure. These schemata include 
general linguistic conventions as well as expected or- 
ganisations for specific situations. Before conversation 
begins the template is very abstract, giving only broad 
descriptions of topics that might be expected in a spe- 
cific domain. These expectations provide a framework 
for organising goals from the problem solvers. New 
goals are associated with the existing template, orga- 
nising them into groups that are related by conven- 
tional discourse structure. Goals are added by finding 
schemata which connect them to the template. Since 
the schemata specify acceptable conversational struc- 
ture, the template represents a coherent conversation. 
The dialogue in Figure 1 was organised using such 
a template. The arrows in the figure show the order 
in which goals arrived at the interface. The tall of the 
arrow shows when a goal arrived at the interface; the 
head, where it is realised in the dialogue. Each time the 
arrows cross, the goal has been delayed to fit more nat- 
urally into the conversation. Goals have been grouped 
by the course that they relate to as well as being fur- 
ther organised by attributes such as ingredients of the 
main-dish of a course (utterances 10a~10d). The dia- 
logue also includes a story to connect two utterances 
(10a and 10b), which adds variety to the structure of 
the conversation. 
This dialogue was generated by JUDIS \[15\], an in- 
terface to Julia, an advisor for meal-planning \[3\]. I Ju- 
t JUDIS is rcsponsihle for the organlsing the conversation mad 
works with conceptl instead of actual English ut ter~c~s. Con- 
cepts are converted to Ensllsh and En~ah trandated into the 
conceptual language by the NLPTool \[2\]. JUDIS ~ worked 
with the NLPTool to participate in Engiish dialogues, hut wu 
not col~ected to the NLPTool for this ¢x~ple. In the fillur~, 
EnsUsb is used to make the dialogue readable. 
The Julla described here is the original version of the system. 
AcrEs DE COLING-92, NANTES, 23-28 AOt3T 1992 3 3 8 PRec. OF COLING-92, NANTES, AUO. 23-28. 1992 
(1) User: i'la planning a dinner and would like 
to ~erve Mexclan food. 
(2) JUDIS:I'm thinking of chili for a ll~ill 
course. D~s everyone llke spicy food? 
(3) User: No, Tom hates splcy food. 
~(4) JUDIS:Would you like enchiladas? 
(5) Uses: What are enchiladas? 
~(6) dODIS:They'ge a Mexlc~ food made of 
tortillas and rmsat. They also contain 
onion and garlic. 
(7) User: OK. 
(8) dOD~S:het'~ have guacarnole for at~ appetizer. ~ 
191 User: OK. 
(IOakTUDIS: I ~ugt r~bered a case where 
q t sonmol3e had a party ~d could ,tot mash 
h tile avocados because they wore ultrib~. (lOb} Later. go--one could not eat the 
enchiladas because he wa~ allergic to 
I cileese. 
(10c) Make sure no one is allergic to cheese 
and that the av~ados at'e rlpe enough. 
(10d) You n~ay w~it to use red onions because 
they are sweet. 
(10o) Shall we g,z~e the appetizer at the 
table or as her d'oeuveres? 
(Ii) User: At the table. ~ 
(12) JUDIS: Would sopapllla or fried ice cre~ 
for dessert.? 
(13) User: SopapJlla. 
(14) JUDIS: | just remembered a meal where 
so¢msone couldn't eat suaca~le because 
he was allergic to tcwnat~s. Are ally of 
your guests allergic to somalis? 
(15) User : No. 
Figure 1: A dialogue with JUDIS. 
lia is a distributed problem solver comprised of a case- 
based reasoner and a planner which uses more tradi- 
tional problem solving techniques. The problem solvers 
and the interface share their world knowledge. When 
a problem solver has a goal to either give or get infor- 
mation, the goal is sent to JUDIS where it is converted 
into an appropriate utterance and attached to the tem- 
plate. We refer to these goal-motivated utterances as 
requests. 
II REPRESENTING DISCOURSE STRUCTURB 
We have chosen conversation MOPS (C-MOPS) \[6; 
16\] as the representation for discourse structure in 
JUDIS. C-MOPS participate in an abstraction hier- 
archy 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. 
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, "Julia" wits ainu 
used to refer only to the problem solvers and the dclign of the 
problem solverl changed. JUDIS receives goal* from • micr¢~ 
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 tlm¢ that 3UDIS wa. implemented, • complete •nd inte- 
grated veralon of the caterer wu not available. 
ceptual, episodic memory. An episode is represented 
by scenes which have bccn performed to achieve some 
goal. Episodes are stored in and retrieved from dy- 
namic memory. This memory changes when ueneral~ed 
episodes are created as individual episodes that share 
features are stored in memory. The generalizations oc- 
cur at many different levels forming a hierarchy of gen- 
eralisations and their specializations, Episodes in dy~ 
narnic memory are linked by predictive indices, selected 
feature-value pairs which mark differences between gen- 
eraliaed episodes and their contributing specialiaations. 
These indices are followed when an episode is retrieved 
from dynamic memory, allowing a system to he Ure- 
minded" of MOPs which match some predictive feature 
of the current situation. We use the term "MOP" to 
describe both a single episode and an episode with its 
indices and npecialisations. In the context of being re- 
trieved from memory or Junta, tinted in the template, 
"MOP" will refer to a single episode. In the context of 
representations stored in memory, "MOP" includes the 
indices and specialisatioas. 
When the events stored are conversations, we refer 
to these structures as conversation MOPs or C~MOPs. 
Kellermann, ei al. \[6\] suggest C-MOPs as the cog- 
nitive structures for representing discourse structure. 
C-MOPs can appear as scenes in other C-MOPs, allow- 
ing 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 con- 
vention captured by generalised episodes. Kenermann 
et al.'s experiments suggested that C-MOPs represent° 
ing discourse structure are divided into scenes by topic. 
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 declara- 
tive representation that explicitly gives the structure 
of the conversation and, so, are suitable for building 
the template. All types of schemata must allow recur- 
stun, so a template built front any type of schemata 
could be expanded. C-MOPs have one characteristic, 
however, that makes them particularly useful for or- 
ganising requests. They participate in a generalisa- 
tion/apecialisation hierarchy. This hierarchy has two 
advantages: it allows the heat prediction for a given sit- 
uation to be returned from memory, and it allows those 
predictions to be tuned as new information is learned 
about the situation. 
B The Generalization/Specialization Hierarchy 
The ability to capture convention in the generalisa- 
tion/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 conver- 
sation with other language users \[7; 14\]. Because 
these conversations follow convention, the generaliza- 
tions of these conversations will represent abstract dis- 
course 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. 
Our C-MOPs are derived from others' research on dis- 
course 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. 
One important characteristic of the generaliza- 
tion/specialisation hierarchy is its ability to capture 
situation specific detail. This ability is especially im- 
portant given that computers do not think like people. 
Specializations can be used to enumerate the accept- 
able ways to discuss a topic. The interface can then 
rely on the appropriate C-MOP to organize the conver- 
sation instead of being dependent on the knowledge or- 
ganization and problem solving methods of the domain 
reasoners. The specialization can also rule out ways 
of organizing the dialogue that follow a standard dis- 
course convention but would not be expected by human 
reasoners. For example, a general problem-solving con- 
vention 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 or- 
der, but a specialization for discussing the dessert first 
is not included, s 
The generalization/specialization hierarchy also al- 
lows the template to be tuned as the situation changes 
or new information is discovered. If the new informa- 
tion is an index of a C-MOP, that O-MOP can be re- 
placed with the indexed specialisation. This idea is im- 
portant for adding new requests to the template. We 
can think of some cases of adding a request as find- 
ing a speciaiization that includes the current request as 
~JUDIS' retrieval algorithm \[15\] orders the features mad pur- 
sues the indices sequentially until a.n index is not found. This 
is s departure from traditional implementatlorm of dynamic 
memory that pttrsue indices "in pared/el" \[c£, 7\]. Our alSo- 
rithm 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*. 
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. 
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 ques- 
tion/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. 
3UDIS also has a CATERER-CMOP which contains 
specialiscd knowledge about conversations for planning 
meals and organizes the overall discussion of the meal. 
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 indepen- 
dent of problem solving knowledge when organizing the 
dialogue. However, not all C-MOPs should be repre- 
sented 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 instanti- 
ated. 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 C- 
MOPs. 
The CATERER-CMOP organizes the discussion of the 
meal. 3UDIS has very little information about the de- 
tails 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 im- 
pose acceptable orderings on the topics. 
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 or- 
gsaise requests in the template. The discussion scene 
can be a TOPIc-CMOP~ an UTTERANCE-CMOP~ or a 
QUESTION/ANSWER-CMOP. The sabjecL of the TOPIC- 
or 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. 
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. 
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. 
The LIST-CMOP converts values found in a slot of 
a frame into -roPlc-CMOPs which become its scenes. 
The LlST-CMOP has speclalisations which include an 
ordering ~ction \[11\]. The predictive feature "info- 
type" indexes these specialisations. For example, if 
constructing a list of ingredients, which are divided 
into main, secondary and spices, a list with the "main- 
first" ordering function is returned. All scenes in LIST- 
CMOPs used to organize requests are optional. Con- 
sequently, only requests from the problem solvers will 
be included in the conversation. However, there are 
specializations, retrieved in the context of question an- 
swering, that contain mandatory scenes. 
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 prob- 
lem solving will suffice. In other domains, or if the 
user were expected to take a more active part in prob- 
lem 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 LIST- 
or 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. 
Some of this effort could be saved by creating only ab- 
stract templates and allowing the reasoning followed 
by the problem solvers to link requests to the template. 
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. 
III ADDING A RI~QUEST TO TH R TEMPLATg 
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 mid- 
dle portion of the dialogue where the meal will be dis- 
cussed. 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 pre- 
dicted 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. 
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. In- 
stead of searching semantic memory to find the po~i- 
ble connections between requests \[cf. I 4\], JUDIS uses 
knowledge from the reasoners' problem solving. The 
problem solvers send the interface two pieces of infor- 
mation with each request. The chain of reasoning from 
the meal being planned to the attributes that the prob- 
lem 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. Oth- 
erwise the request asks for a value for the attribute. In 
this cane, the attribute will be the subject for the pur- 
pose 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 be- 
ing 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 con- 
section between the utterances will be acceptable in the 
context of the current conversation. Also, thin informa- 
tion 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 se- 
mantic memory for all possible connections. 
To rely on information from problem solving, that 
information must be Ucognitively plausible" 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. 
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 rea- 
soning 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 seman- 
tic memory, there must be a way to match knowledge 
structures that should be considered the same. 
B Merging Requests into DiJcussiont 
All requests can he merged into the template for conver- 
sation 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 al- 
ready been dosed, the change-topic scene will mark the 
return to a previous topic \[15\]. Utterance 14 in Fig- 
ure 1 is an example of JUDIS returning to a previous 
topic. 
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. 
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 re- 
quests 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. 
Extend the reasoning to add a new topic. 
Sometimes the subject of a new request is a very specific 
aspect of an expected topic. If the request were sim- 
ply 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. 
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 rea- 
soning and its value are added to the discussion. Fig- 
ure 2a shows a request concerning Uavocado" being 
added to the template by this method. Because it is 
connected to the appetiser TOPIC-CMOP through spe- 
cific attributes, another request, 9, can be easily added 
through the "presentation" attribute. If a specific at- 
tribute will be mentioned, the attributes which connect 
it to the topic can be mentioned first. 
Connect scenes through knowledge struc- 
tures. 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 instan- 
tiate. This is done to make sure that any speciailsa- 
tions appropriate for the current situation are found. 
For example, the LIsT-CMOP is specialised to have a 
main-first ordering when ingredients are connected. 
IV" EXECUTING THE TEMPLATE 
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. 
The template is only used an a guide to organise con- 
versation. When JUDIS is to take its turn in conver- 
sation, it combines information about the priorities of 
the requests and how those requests lit into the tem- 
plate 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. 
Other times a goal is so urgent that the template is 
overridden. 
V ORGANIZING A DIALOGUE WITH JUDIS: AN 
EXAMPLE 
Consider utterances 10a-10d in the example dialogue. 
As the arrows indicate, the goals which motivated these 
requests are rc~organised to make the dialogue coher- 
ent. When the initial template in built, JUDIS pre- 
dicts that the GENERAL-INFO I MAIN-COURSE l APP I~- 
TIZER and DZSSZRT topics will be included in the dia- 
logue. At this point, JUDIS knows only that the ap- 
petiser will be discussed but knows none of the details. 
Then a request to tell the user about a possible fail- 
ure with avocados comes from the case-based reasoner. 
Since the subject of the request is not the appetiser 
but one of the ingredients of the appetiser, a path is 
ACTES DE COLING.92, NANTES, 23-28 AoLrr 1992 3 4 2 PROC. OF COLING-92, NAIXrFES, AUG. 23-28, 1992 
Figure 2: Adding requests to the temlpate. 
formed of values and their attributes from the appe- 
tizer "roPIc-CMOP to the avocados, as shown in Fig- 
ure 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 "onion", is also an ingredient in gua- 
camole. When JUDIS tries to insert the request as a 
value of the ingredient attribute, it must find a struc- 
ture that will incorporate both the avocado-request, al- 
ready associated with the ingredients, and the onion- 
request which is to be added. JUDIS relies on the infor- 
mation about how the two requests are connected, that 
they are both values of the same slot of a frame, to be- 
gin 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. 
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). 
This narrative contains not only the goal-achieving re- 
quests (last part of utterance 10a and utterance 10b), 
but also the mandatory setting (first half of utterance 
10a) and conclusion scenes (utterance 10c). 
The organisation given by the template and the pri- 
orities 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. 
The narrative containing the avocado and enchilada re- 
quest 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. 
VI Discussion 
JUDIS is an implemented system which embodies our 
approach for merging goals into an existing conver- 
sational 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 dis- 
course 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. 
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 dis- 
course to this point. 
One of the most important advantages of our ap- 
proach 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' conven- 
tional 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 proh- 
lena solvers. JUDIS' dialogue is motivated by the 
communication goals that it is sent from the problem 
solvers. The requests which achieve these goals dic- 
tate 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 con- 
versation 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\]. 
Utterances which follow convention are in- 
cluded 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 con- 
nected by a narrative, the setting, conclusion and en- 
abling scenes are added to the template when the narra- 
tive 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. 
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. 
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 of- 
ten expected in natural language interfaces \[15; 16\], 
JUDIS' method of organising dialogue is most success- 
ful 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 fail- 
ure and recover when the template no longer predicts 
the conversation. This is an important area for future 
research. 
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 peo- 
ple, 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 or- 
ganization 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 dia- 
logue. 
JUDIS is also helped because very few of its goals are 
urgent. In a system that very often needs to get addi- 
tional 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. 
JUDIS has begun to address the problem of organiz- 
ing dialogue so that even conversation motivated by an 
incoherent stream of goals can be easy to understand. 
Most important to our method is the ability to form 
partial predictions about the dialogue that can be ex- 
panded as goals arrive from the problem solver. In this 
way, 3UDIS can group utterances together to form a 
coherent whole. 
ACRES DE COLING-92, NANTES, 23-28 AOUT 1992 3 4 4 PROC. Or COLING-92, NhrcrEs, AUG. 23-28, 1992 

REFERENCES 

i\] Sandra Mary Carberry. Pragmatic modeling in 
nformation system interfaces. Technical Report 
86-07, Department of Computer Science, Univer- 
sity of Delaware, 1988. Ph.D. thesis. 

\[2\] Richard E. Cullingford. Natural Language 
Processing: A Knowledge Engineering Approach. 
Rowan and Littlefield, To,own, New Jersey, 1986. 

\[3\] Richard E. Cullingford and Janet L. Kolod- 
her. Interactive advice giving. In Proeesdinys of 
the 1986 IBBE International Conference on Sys- 
tenw, Man and Cybernetics, pages 709-714, At- 
lanta, Georgia, 1986. 

\[4\] Barbara J. Gross. The representation and rose 
of focus in a system for understanding dialogs. In 
Proceedings of the Fifth International Conference 
on Arti\]icial Intelligence, pages 67-76, Los Altos, 
California, 1977. William Kanfmann, Inc. 

\[5\] Barbara J. Gross and Candace L. Sidner. At- 
tention, intention, and the structure of discourse. 
Computational Linguistics, 12(3):175-204, 1986. 

~\] Kathy Kellermann, Scott Broetsmann, Tae- 
sop Lira, and Kenji Kitao. The conversation 
MOP: Scenes in the stream of discourse. Discourse 
Proee#scs~ 12(1):27-61, 1989. 

\[7\] J.L. Kolodner. Retrieral and Organizational 
Strategies in Conceptual Memory. Lawrence Erl- 
bantu Associates, Publishers, Hillsdale, New Jer- 
sey~ 1984. 

\[8\] Diane J. Litman and James F. Allen. A plan 
recognition model for subdialogues in conversa- 
tion. Cognitive Science, 11:163-200, 1987. 

\[9\] William C. Mann. Discourse structures for 
text generation. In Proceedings of the Tenth In- 
ternational Conference on Computational Linguis- 
tics, pages 367-375, 1984. 

\[10\] Kathleen R. McKeown. Tezt Generation: Us- 
ing Discourse Strategies and Focus Con4traintm to 
Generate Natural Languauge Tezt. Cambridge 
University Press, New York, 1985. 

\[11\] L. Polanyi and R. Scha. A syntactic approach 
to discourse semantics. In Proceedings of the Tenth 
International Conference on Computational Lin- 
guiztics, pages 413-419, 1984. 

\[12\] Rachel Reichman. Getting Compatera to Talk 
Like You and Me: Discourse Contezt, Focus, and 
Semantics (An A TN Model). The MIT Pre~, 
Cambridge, Mass, 1985. 

\[13\] David E. Rumelhart. Notes on a schema for 
stories. In Daniel G. Bobrow and Allan Collins, 
editors, Representation and Understanding. Aca- 
demic Press, New York, 1975. 

\[14\] R.C. Schank. Dynamic Memory. Cambridge 
University Press, New York, 1982. 

\[15\] Elias H. Turner. Integrating intention and 
convention to organise problem solving dialogues. 
Technical Report GIT-ICS-9O/02, School of Infor- 
mation and Computer Science, Georgia Institute 
of Technology, 1990. Ph.D. thesis. 

\[16\] Elise H. Turner and Richard E. Cultingford. 
Using conversation MOPs in natural language in- 
terfaces. Discourse Processes, 12(1):63-90, 1989. 
