A DIALOGUE MANAGER USING INITIATIVE-RESPONSE UNITS AND 
DISTRIBUTED CONTROL 
Arne J0nsson 
Department of Computer and Information Science 
Linktiping University 
S- 581 83 LINKOPING, SWEDEN 
Phone: +46 13281717 
Email: ARJ@IDA.LIU.SE 
Abstract 
This paper describes a system for managing: dialogue 
in a natural language interface. The proposed approach 
uses a dialogue manager as the overall control mecha- 
nism. The dialogue manager accesses domain independ- 
ent resources for interpretation, generation and back- 
ground system access. It also uses information from do- 
main dependent knowledge sources, which are custom- 
ized for various applications. 
Instead of using complex plan-based reasoning, the 
dialogue manager uses information about possible inter- 
action structures and information from the specific dia- 
logue situation to manage the dialogue. This is 
motivated from the analysis of a series of experiments 
where users interacted with a simulated natural language 
interface. The dialogue manager integrates information 
about segment types and moves into a hierarchical dia- 
logue tree. The dialogue tree is accessed through a score- 
board which uses exchangeable access functions. The 
control is distributed and the dialogue is directed from 
action plans in the nodes in the dialogue tree. 
1 Introduction 
To achieve true cooperation a natural language inter- 
face must be able to participate in a coherent dialogue 
with the user. A common, generally applicable'approach 
is to use plan-inference as a basis for reasoning:about in- 
tentions of the user as proposed by, for instance, Allen & 
Perrault (1980), Litman (1986), Carberry (1989) and 
Pollack (1986). However, computationally these ap- 
proaches are not so efficient. 
Reichman (1985) describes a discourse grammar 
based on the assumption that a conversation can be de- 
scribed using conventionalized discourse rules. Gilbert, 
Buckland, Frolich, Jirotka & Luff (1990) uses interac- 
tion rules in their menu-based advisory system. Our ap- 
proach is similar to Reichman and Gilbert el al. In a 
series of experiments (Dahlb~lck & JOnsson, 1989, J0ns- 
son & Dahib/tck, 1988) we studied dialogue behaviour in 
an information-seeking interaction between a human and 
a computer using a simulated natural language interface 
(NLI). One important result was that the users followed 
a rather straightforward information searching strategy 
which could be well described using conventionalized 
rules. 
Reichman uses surface linguistic phenomena for rec- 
ognizing how the speaker's structure the discourse. We 
found, however, very little use of surface linguistic cues 
in our dialogues. In our corpus users normally initiate a 
request for information, which is followed by an answer 
from the system. Sometimes the request needs clarifica, 
tion before the answer can be given as a response to the 
initial question (this is illustrated in section 4 and 5). Op. 
tionally the user can interrupt the original question and 
start a new initiative-response unit, but this also follows 
the goals of information-seeking. Thus, we adopt a strat, 
egy in which we employ the notion of adjacency pairs 
(Schegloff & Sacks, 1973, see also Levinson, 1983: 
3030. In our approach the dialogue is planned and utter- 
ances are interpreted in terms of speech acts. The speech 
acts are determined on the basis of structural information 
in the utterance and in the immediate context. 
Further, we found, in our experiments, that different 
configurations of the background system (e.g. data base, 
consultation) and task to solve (e.g. information retriev- 
al, configuration) require different mechanisms for han- 
dling dialogue in an NLI (JOnsson, 1990). Therefore, one 
major design criterion is that the system should be easy 
to adapt (customiZe) to a new application. 
The natural language interface described in this paper 
is constructed on the assumption that different applica- 
tions have different sublanguages (Grishman & Kit- 
tredge, 1987), i.e. subsets of a natural language. A sub- 
language is not only defined by a grammar and lexicon, 
but also by interaction behaviour, i.e factors such as how 
the user and system handle clarifications, who takes the 
initiative, what is cooperative in a certain application, 
what are the user categories and so on. 
The dialogue manager operates as the central control. 
ler in the NLI (Ahrenberg, Dahlb/tck & J6nsson, 1990). 
It passes information encoded in directed acyclic graphs 
(dags) between different modules for parsing, genera- 
tion, etc. This paper, however, only describes the dia- 
logue manager's role in the control of the dialogue. I 
assume that the dag's correctly describe the full meaning 
of the user's input. For a discussion of interpretation of 
user input in this system see Ahrenberg (1988). The dia- 
logue manager is implemented in CommonLisp but is 
currently not completely integrated with the other mod- 
ules of the system. 
- 233 - 
) 
Figure 1. Overview of the architecture 
2 The dialogue manager 
The dialogue manager (DM) is the kernel in the natu- 
ral language interface, see figure 1. It directs the dia- 
logue, assists the instantiator and deep generator and 
communicates with the background system. DM can be 
viewed as a controller of resources and knowledge 
sources. 
The resources in our system are a chart parser 
(Wir6n, 1988), an instantiator which links the linguistic 
object descriptions to objects in the universe of discourse 
(Ahrenberg, 1989), a translator which translates the in- 
stantiated structures in|o a form suitable for accessing 
the background system" and finally a deep and a surface 
generator for generating a system utterance. These re- 
sources are domain independent processes accessing 
various knowledge sources. 
The knowledge sources are domain dependent and 
implemented in the same knowledge base system and 
can be modified for each new application. We use a lexi- 
con for general and domain-specific" vocabulary and a 
grammar with knowledge of syntactic constructions and 
their semantic impact. Furthermore, we use descriptions 
of dialogue objects, i.e. segments and moves and their 
associated information (section 3) and domain object de- 
scriptions which contain relations between the concepts 
used to describe objects in the background system and 
constraints on them. 
The need for domain object information in a natural 
language database interface has been argued for by for 
instance Copestake & Sparck Jones (1990) and McCoy 
& Cheng (1988). The domain objects are primarily used 
by the instantiator and deep generator, but the translator, 
parser and surface generator can also use this informa- 
tion. For a discussion on domain objects in this system 
see Ahrenberg, J6nsson & Dahlb~ick (1990). 
Each input or output from the resources passes via 
the dialogue manager (DM). A typical segment begins 
with an input from the user that is sent to the DM which 
l. Initially we use only a relational database system. 
passes it to the parser. The parser sends its result to the 
DM which passes it to the instantiator where it is en- 
hanced with referential information. This is sent to the 
translator which accesses the background system and if 
the access succeeds, informs the DM. The DM forwards 
the information to the deep generator where an enhanced 
description is created which is sent to the surface genera- 
tor and finally a. response is given from the DM to the 
user. This has the advantage that the DM always has 
control over what happens in the system. Thus, if one 
module does not succeed with its task, the DM directs 
the recovery. For instance, if the translator cannot access 
the data base due to lack of information from the user, 
the DM receives information from the translator that 
there is information missing and then in turn calls the 
deep and surfac.~ generators to produce a suitable mes- 
sage to the user. The DM then waits for input to provide 
to the parser and: instantiator. Finally, the DM tries to in- 
tegrate the new information with the previous informa- 
tion. 
Internally the dialogue manager maintains three dy- 
namic structures for monitoring the dialogue: the dia- 
logue tree (section 4) where the dialogue history is kept, 
action plans (section 5) for controlling the dialogue and 
finally a scoreboard (section 6) which constitutes the in- 
terface between the dialogue tree and other modules of 
the system. 
3 Dialogue objects 
Dialogue objects play a central role in this architec- 
ture. The dialogue objects consist of two components, 
one is a process :description of a prototypicaf use of the 
dialogue object. This is described below. The other con- 
rains static reformation about speaker, hearer, type, top- 
ic, context and different types of descriptors to describe 
salient objects, e.g. the focused object, potential focused 
objects and optionally the current set. The current set 
records which subset of the data base that is currently 
used. We found in our data base dialogues that the user 
often restricts the possible candidates in a database 
- 234 - 
search. For ~ln example consider the dialogue fragment 
in example 1L 
$7> 
be more specific 
U8> 0.7 litre/10km 
"$9> Daihatsu Charade Fiat Uno 
Ford Fiesta Honda Civic 
Lancia Y10/A112 Mazda 323 
Mitsubishi Colt Nissan Micra 
Nissan Cherry Opel Corsa 
Peugeot 205 Opel Kadett 
Renault 5 Toyota Starlet 
Most of the cars consume iless than 1 litre/10km, 
Toyota Corolla Volkswagen Polo 
Ul0>Which five consume least? Rank them 
S 1 l>Daihatsu Charade 
Fiat Uno 
Nissan Micra 
Toyota Starlet 
Honda Civic 
Ul2>Which of these is safest 
Sl3>They are all equal except Nissan Micra which is 
the worst 
Ul4>Which one is easiest to handle? 
S 15>No information 
Example 1 
First the user specifies a set of cars in utterance U8>, 
presented by the system in $9>. This set is however, too 
large, therefore in utterance U10> it is reduced. In the se- 
quence of utterances U12> to S15>, Current set consists 
of the cars presented in U11>. Current set does not have 
to be explicit as in example 1, instead it can be described 
by constraints. For instance, in a travel data base the user 
may be interested in a trip to Greek islands which re- 
stricts the search in the database to Greek islands for a 
large part of the ensuing dialogue. 
The communication is hierarchically structured using 
three different categories of dialogue objects. There are 
various proposals as to the number of levels needed. The 
system developed by Polanyi & Scha (1984) uses five 
different levels to hierarchically structure a dialogue and 
LOKI (Wachtel, 1986) uses four. In LOKI the levels are: 
conversation, dialogue, exchange and move. When ana- 
lysing our dialogues we found no certain criteria con- 
cerning how to divide a dialogue into'a set of exchanges. 
Therefore we only use three different dialogue object 
types: dialogue, initiative-response-unit (IR) and move. 
Dialogue, in our notation, is similar to conversation in 
LOKI, while IR-units resemble exchanges. IR-units are 
recursive and, unlike LOKI, we allow arbitrary embed- 
ding of IR-units. 
The smallest unit handled by our dialogue manager is 
the move. An utterance can consist of more than one 
move and is thus regarded as a sequence of moves. A 
move object is used for describing information about a 
move. Moves are categorized according to the type of il- 
Iocutionary act and topic. Some typical move types are: 
Question (Q), Assertion (AS), Answer (A) and Directive 
(DI). Topic describes which knowledge source to con- 
suit: the background system, i.e. solving a task (T), the 
ongoing dialogue (D) or the organisation of the back- 
I. The dialogue is an English translation of a dialogue from 
our corpus of Swedish dialogues collected in Wizard-of-Oz simulations. It is continued in section 4. 
ground system (S). For brevity when we refer to a move 
with its associated topic, the move type is subscribed 
with topic, e.g. Qr. 
• Normally an exchange of information begins with an 
initiative followed by a response (IR). The initiative can 
come from the system or the user. A typical IR-unit in a 
question-answer database application is a task-related 
question followed by a successful answer Qr/A-r. Other 
typical IR-units are: Qs/As for a clarification request 
from the user, Qr/ASs when the requested information is 
not in the database, Q~/A o for questions about the ongo- 
ing dialogue. 
• The dialogue:manager uses a dialogue tree (section 4) 
as: control structure. The root node is of type Dialogue 
(the D-node) and controls the overall interaction. When 
an IR-unit is finished it returns control to the D-node. 
The D-node creates an instance of a new IR-unit with in- 
formation about initiator and responder. It also copies 
relevant information about salient objects and attributes 
from the previous IR-unit to the new one. Our simula. 
ti0ns show that users prefer coherence in the dialogue. 
Thus, we use the heuristic that no information explicitly 
changed is duplicated from one IR-unit to the next. 
As stated above, an instance of a dialogue object has 
one component describing static information about initi- 
ator, responder, salient objects etc., and another describ- 
ing the process, i.e. the actions performed when 
executing the object. We call this a plan, although if we 
were to follow Pollack (1990) we could call it recipe-for- 
actions. Figure 2 shows a template description for an IR- 
unit used in a database information-seeking application. 
"Class: IR 
Topic: Tv D v S 
Context: link to father 
Initiator: System v User 
Responder: System v User Type: 
type of/R-unit e.g. Q/A 
Initiative type: e.g. O 
Response type: e.g. A 
Turns: list of daughter nodes 
CurrentObject: 
CurrentAttribute: 
CurrentSet: 
CurrentRequest: 
I\[nitiator = User~ ---> ll~ocess: ((create-move user) "7 
| (access) | 
/ (create-move system) I 
L_ (up)) 
Enitiator = System~-> P~ocess: ((create-move system)i | 
(create-move user) L (up)) 
-- ,-= 
Figure 2. A template description for IR-units 
The static component forms the context in which the 
processes are executed. The attributes are updated with 
new values during the execution of the action plan. For 
instance, a user IR-unit, i.e. an IR-unit which waits for a 
user initiative to be interpreted, has no value for the Initi- 
ative and Response slots until the initiative has been in- 
terpreted. This is discussed further in section 4. 
The process component of the IR-unit is divided into 
two different plan descriptions, one if the system initiat- 
e d the segment and another for a user-initiated segment. 
- 235 - 
However, as can be seen in figure 2, they use the same 
general actions for creating moves, acting and traversing 
the tree (up). The actions behave differently depending 
on the static description, for instance the action (access) 
uses the value of the slot Topic to determine which 
knowledge source to consult. Information about values 
of attributes describing the request for information is 
found in the dag structure delivered by the instantiator 
which is passed to the translator by the dialogue manag- 
er. The slot CurrontRequost contains the request formed 
by the translator and is used for clarifications. 
In database applications the system behaves as a user- 
directed interface. It initiates an IR-unit only for clarifi- 
cation requests, either because 1) difficulties arise when 
interpreting the utterance, or 2) difficulties arise when 
accessing the data base, e.g. when the user needs to pro- 
vide a parameter for correct access, see S17> in example 
2 below, or finally 3) if difficulties arise in the presenta- 
tion of the result from the data base access. The action to 
take after a clarification request is first to check the va- 
lidity of the response and then to propagate the informa- 
tion to the node which initiated the clarification. 
In other applications, e.g. tutoring or consultation 
systems, the behaviour need not be user-directed. Instead 
it may be system-directed or mixed initiative. In our ap- 
proach this is achieved by customizing the dialogue ob- 
jects, section 7. 
For move-units there are two different process de- 
scriptions, one for user moves and one for system 
moves. The user move has the plan ((parse) (instantiate) 
(up)) and the system move has the plan ((deep-generate) (surface-generate) (up)). 
4 The dialogue tree 
The dialogue tree represents the dialogue as it devel- 
ops in the interaction. Information about salient objects 
is represented in the dialogue tree and is used by the in- 
stantiator and deep generator. The dialogue manager up- 
dates the dialogue tree for each new move. 
An important feature of the dialogue manager is dis- 
tributed control. Every node in the tree is responsible for 
its own correctness. For instance, the plan for a task re- 
lated question-answer, Or/AT, contains no reparation 
strategies for missing information to the background sys- 
tem. If the interpreter fails to access the data base due to 
lack of information, the translator signals this to the DM 
which creates an instance of an IR-unit for a clarification 
request and inserts it into the Or/AT. The plan for clarifi- 
cauon request then generates a move explaining the 
missing information and creates a user move waiting for 
the user input. This has the advantage that theplans are 
very simple, as they only have local scope, cf. sections 3 
and 6. Furthermore, the plans are more generally appli- 
cable. 
UI6> 
S17> 
U18> 
S19> 
U20> 
$21> 
I would like a car with a large boot 
How big (litres)? 
I don't know 
They vary in size from about 200-350 litres 
I want at least 300 litres. 
BMW 318/320 
Example 2 
The tree is built bottom up but with a top down pre- 
diction from the context. This is illustrated in the dia- 
logue in example 2, which will generate a dialogue tree 
with clarifications on two levels. Initially the D-node 
creates an instance of an IR-node and inserts it into the 
tree, i.e. creates links between the IR-node and the D- 
node. The IR-node creates an instance of a user move. 
The move node parses and instantiates U16> successful- 
ly as an ASa- and then integrates it into the tree. Informa- 
tion from the move-node is then available also at the IR- 
node whose type can be determined as AST/AT. When 
the database is accessed from this node, the translator 
finds that there is a need for clarification, in this case 
concerning the use of the word large in connection with 
a boot. This creates a plan which first prompts the user 
with a question, S17>, and then waits for the user to give 
an answer. Here the user does not answer but instead ex- 
presses a request for clarification, U18>. This is shown 
in part 1) of figure 3 as the clarification IR-unit, QSs/As. 
The fact that U18> constitutes a clarification request and 
not an answer to S 17> is decided after the creation of the 
user move from U18>. When the DM receives the inter- 
pretation from the instantiator, it does not satisfy the ex- 
pectation for an answer, and so it has to instantiate a new 
IR-unit for clarification request which is connected to the 
previously created IR-clarification request (Qr/AT). 
1) D 2) D / / 
AST/AT AST/Ar 
AST Or/Ar AS-r QT/Ar Ar U16~ U16//~ $21 
QT QsYAs QT Qs~As AT S17/ S17 ~ U20 
Qs Qs As UI8 U18 S19 
Figure 3. A dialogue tree 
Utterance UI8> in the context of the Qr/Ar IR-unit 
indicates that the user needs some information about the 
background system and it is thus interpreted as Qs. This 
information is supplied in S19>. For the next utterance, 
U20>, a new user move is created which is integrated 
into the tree as an answer to the original clarification re- 
quest. This information is propagated up to the first node 
AST/Ar which now can form an answer to the first ques- 
tion $21>, part 2) in figure 3. The next step (not shown 
in figure 3) is to generate a new IR-unit under D which 
will generate a new user move and the system is ready 
for further user input. 
5 The action plan 
The plan describing a prototypical use of an object is 
pushed onto a slack called the action plan. In accordance 
with our distributed design, each node maintains its own 
stack, see figure 5. The overall control strategy is that the 
stack top is popped and executed. Complex plans, as 
when the query to the data base needs clarification, are 
handled with the same control mechanism. The dialogue 
manager then updates the action plan of the current node 
with an action for creating an instance of a,clarification 
request dialogue object and another action'to integrate 
- 236 - 
new information. The DM pops the stack of the current 
node and executes that action. When this new exchange 
is completed the result is integrated into the node which 
initiated the clarification. 
Again, consider the dialogue tree in figure 3. Part 1) 
in figure 4 shows the stack for the node AST/Ar before 
processing U16>, i.e. before the move node is created 
which parses and instantiates the move. At this time the 
node type is not known. 
l) (create-move user) (access) 
(create-move system) (up) 
2) (create-IR QT/AT) (integrate-new-info) 
(access) 
(create-move system) (up) 
Figure 4. The action plan for an IR-node 
Popping the action (create-move user) results in the 
creation of a move node which is ready to interpret a 
user input. The move node has a plan of its own: ((parse) 
(instantiate) (up)). When UI6> is interpreted in the move 
node, AS T in figure 3, the move node ends with the ac- 
tion (up) which tries to find a corresponding father. In 
this case it succeeds with the IR-unit from which the 
move node was created and the dialogue is controlled 
from this node, now AST/AT. The slack top is now (ac- 
cess) which in this case uses the topic T, i.e. a data base 
access. However, the data base access does not succeed. 
Therefore a call for clarification, an action for later inte- 
grating the new information into the old request and a 
new call to (access) is placed on the slack. This is seen 
in part 2) of figure 4. The action (access) has different 
repair strategies for the different clarification request 
types described above. Similar repair strategies apply to 
all actions. 
The slack top is an action which creates a known IR- 
unit asking for a data base access parfimeter. This action 
then creates the Qr/Ar-node in figure 3. Now this node 
will have its own action plan stack from which process- 
ing is controlled. This node is also responsible for the 
correctness of the answer given from the user, which in 
this case results in a new clarification request. This does 
not affect the node AST/AT instead the clarifications are 
processed and eventually control is returned to the node 
AST/Ar and the new information:is integrated into its old 
request, stored in CurrentRequost. 
The two clarification nodes, QT/A r, Qs/As, in figure 3 
behave in a similar fashion. 
6 Scoreboard 
Controlling the dialogue is only one of the responsi- 
bilities of the dialogue manager. It is also responsible for 
monitoring the dialogue. Information about salient ob- 
jects is represented in the dialogue tree and is accessed 
through a scoreboard, figure 5. The scoreboard is the in- 
terface between the dialogue manager and the other 
modules in the NLI. 
' Scoreboardl 
S~aker; 
Hearer; 
CurrentRequ~t: 
Current Segment:-" Current Move: ----. 
CurrentObiect: CurrentSe/: : 
C rr t Ai/ri  e; 
ue tree 
Action 
Action i - 
Action i - 2 
Act/on I 
Action Plan 
1 
Figure 5. The intemal structures used by DM 
The attributes of the scoreboard take their values 
from the tree via pointers or via retrieve functions which 
search the dialogue tree. The lexicon and grammar are 
written with references to the attributes on the score- 
board and therefore are not involved in traversing the di- 
alogue tree. 
:Furthermore, the retrieve functions can be altered, al- 
lowing the search for a referent to an anaphoric expres- 
sion to be application dependent. This means that we 
need only update the retrieve function connected to an 
element on the ~oreboard, not the grammar or lexicon, 
when an application requires a change in dialogue style. 
7 Customization 
One objective of this project is to develop a natural 
language interface that can be customized to different 
applications, i.e. a natural language interface shell to be 
used by a language engineer when creating an NLI for a 
specific application. 
Customization is achieved by using different ex- 
changeable/modifiable knowledge sources. Our inten- 
tion is to build a library of prototypical knowledge 
sources and re-uSe much of the knowledge between dif- 
ferent applications. For instance the lexicon for an SQL 
data base interface needs to be updated with data base 
content-specific terms but large parts of it are re-usable. 
Furthermore, we believe this to be possible not only for 
the lexicon and grammar, but also for the dialogue ob- 
jects. The plans for a data base system will be much the 
same regardless of the domain. Customization, however, 
is not the topic of this paper. For more on this see Jrns- 
son (1991). 
8 Summary 
I have presented an architecture for dialogue manage- 
me~t for naturallanguage interfaces to various applica- 
tions. The dialogue manager operates as a controller of 
resources for parsing, instantiation, generation and data- 
base access. 
:The design of the dialogue manager is based on the 
analysis of a corpus of simulated human-computer inter- 
actions. Unlike plan-based proposals which employ user 
intentions to guide the interaction, the dialogue manager 
described here uses plans with information about proto- 
typical interaction patterns. The plans are modelled in 
- 237 - 
dialogue objects which also contain static information 
for representing the dialogue. 
The dialogue objects are hierarchically structured in 
three categones: dialogue, initiative-response and move. 
The initiative-response category is recursive. Use of an 
initiative-response structure can be criticised in the same 
way as adjacency pairs for not adequately describing a 
naturally occurring discourse. However, for a restricted 
sublanguage, such as natural language communication 
with computers, we believe that this is a very efficient 
way of managing the dialogue (cf. Levinson 1981:114). 
The dialogue history is represented in a dialogue tree 
consisting of instantiated dialogue objects. The resourc- 
es access the dialogue tree through a scoreboard and thus 
need no mechanisms for traversing the tree. 
We have conducted experiments which show that in 
an information-seeking human-computer dialogue the 
proposed mechanisms can correctly handle the dialogue. 
Empirical tests will show how many different interaction 
settings we can handle. 
Acknowledgements 
This work is much inspired by the work that I have 
done with Nils Dahlb~ick and Lars Ahrenberg. Ake 
Thurte did most of the coding for the DM in Xerox 
Common Lisp on a Sun Spare Station and many ideas 
were formed during discussions with him. Lars Ahren- 
berg, Ivan Rankin, Mats Wirtn and Richard Hitsch have 
read previous versions of the paper and provided many 
valuable comments. 
References 
Ahrenberg, Lars (1988) An Object-Oriented Dia- 
logue System for Swedish, Nordic Journal of Linguistics, 
Vol. 11, Nos 1-2, pp 3-16 
Ahrenberg, Lars (1989) A Constraint-Based Model 
for Natural-Language Understanding and a Pilot Imple- 
mentation. Research Report LiTH-IDA-R-89-22, Depart- 
ment of Computer and Information Science, Link6ping 
University. 
Ahrenberg, Lars, Arne J6nsson & Nils Dahib~lck 
(1990) Discourse Representation and Discourse Manage- 
ment for Natural Language Interfaces, To appei~r in Pro- 
ceedings of the Second Nordic Conference on Text 
Comprehension in Man and Machine, T~lby, Stockholm. 
Allen, James. F. & C. Raymond Perrault (1980) Ana- 
lysing Intention in Utterances, Artificiallnteiligence, 15, 
pp 143-178. 
Carberry, Sandra (1989) A Pragmatics-Based Ap- 
proach to Ellipsis Resolution, ComputationalLinguistics, 
Vol. 15, No 2. pp 75-96. 
Copestake, Ann & Karen Sparck Jones (1990) Natu- 
ral Language Interfaces to Databases, Technical Report 
No. 187, University of Cambridge, UK 
Dahlb~lck, Nils & Ame J6nsson (1989) Empirical 
Studies of Discourse Representations for Natural Lan- 
guage Interfaces, Proceedings of the Fourth Conference 
of the European Chapter of the ACL, Manchester. 1989. 
Gilbert, Nigel, Sarah Buckland, David Frolich, Mari- 
na Jirotka & Paul Luff, Providing Advice Through Dia- 
logue, (1990) Proceedings of ECAI-90, Stockholm. 
Grishman, R.:& Kittredge, R. (Eds.) 1986. Analysing 
language in restricted domains. Lawrence Edbaum. 
JOnsson, Arne (1990) Application-Dependent Dis- 
course Management for Natural Language Interfaces: An 
Empirical Investigation, Papers from the Seventh Scandi. 
navian Conferen'ce of Computational Linguistics, Rey- 
kjavik, Iceland. : 
JOnsson, Arne (1991) A Natural Language Shell and 
Tools for Customizing the Dialogue in Natural Language 
Interfaces. Internal Report, LiTH-IDA-R-91-10. 
JOnsson, Arne & Nils Dahlbitck (1988) Talking to a 
Computer is not Like Talking to Your Best Friend. Pro- 
ceedings of The first Scandinivian Conference on Artifi- 
cial Intelligence, Troms¢, Norway. 
Levinson, Stephen C. (1981) Some Pre-Observations 
on the Modelling of Dialogue, Discourse Processes, No 
4, pp 93-116. 
Levinson, Stephen C. (1983) Pragmatics. Cambridge 
University Press. 
LineU, Per, Lennart Gustavsson & P~vi Juvonen 
(1988) Interactional Dominance in Dyadic Communica- 
tion. A presentation of the Initiative-Response Analysis. 
Linguistics, 26(3). 
Litman, Diane J. (1986) Understanding Plan Ellipsis, 
Proceedings of AAAI-86. 
McCoy, Kathleen F. & Jeannette Cheng (1988) Focus 
of Attention: Constraining What Can Be Said Next, Pre- 
sented at the 4th International Workshop on Natural Lan, 
guage Generation.Buffalo. 
Polanyi, Livia & Remko Scha (1984) A Syntactic Ap- 
proach to Discourse Semantics, Proceedings of COL- 
ING' 84 , Stanford. 
Pollack, Mariha E. (1986) A Model of Plan Inference 
that Distinguishes between the Beliefs of Actors and Ob, 
servers, Proceedings of the 24th Annual Meeting of the 
ACL, New York. 
Pollack, Martha E. (1990) Plans as Complex Mental 
Attitudes, Intentions in Communication, MITPress, 
1990. 
Reichman, Rachel (1985) Getting Computers to Talk 
Like You and Me, MIT Press, Cambridge, MA. 
Schegloff, Emanuel, A. & Harvey Sacks (1973) 
Opening up clos!ngs, Semiotica, 7, pp 289-327. 
Wachtel, Tom (1986) Pragmatic sensitivity in NL in, 
terfaces and the Structure of conversations, Proceedings 
of COLING'86. Bonn. 
Wirtn, Mats :(1988) On Control Strategies and Incre- 
mentality in Unification-Based Chart Parsing, Licentiate 
thesis, Thesis No 140, Department of Computer and In- 
formation Science, Linktping University 
- 238 - 
