Building Knowledge Bases for the Generation of 
Software Documentation * 
C4cile Paristand Keith Vander Linden :I 
ITRI, University of Brighton 
Lewes Road 
Brighton BN2 4AT, UK 
{clp,knvl}~itri.brighton.ac.uk 
Abstract 
Automated text generation requires a 
underlying knowledge base fl'om which 
to generate, which is often difficult to 
produce. Software documentation is one 
domain in which parts of this knowledge 
base may be derived automatically. In 
this paper, we describe DRAFTER, an au- 
thoring support tool for generating user- 
centred software documentation, and in 
particular, we describe how parts of its 
required knowledge base can be obtained 
automatically. 
1 Introduction 
Automated text generation is becoming an attrac- 
tive technology because it, allows for the genera- 
lion of text in different styles and in different lan- 
guages from a single underlying knowledge base. 
The well-known problem with the technology is 
that this knowledge base is often difficult to build. 
In most research generm, ion systems, this knowl- 
edge base is essentially built by hand. No general 
solution to this problem has been proposed be- 
cause each application has its own domain specific 
requirements. 
It is clear, however, that for text generation 
technology to heeome viable, there must be some 
* This work is partially supported by the Engi- 
neering and Physical Sciences Research Council (EP- 
SitC) Grant J19221, by I~C/DAAD aaC Project 293, 
by the Commission of the European Union Grant 
LRE-62009, and by the Office of Naval Research Grant 
N00014-96-1-0465. 
t Starting this Fall, Dr. Paris' address will be 
CSIRO, Division of Information Technology, Syd- 
ney Laboratory, Building E6B, Macquarie University 
Campus, North Ryde, Sydney, NSW 2113, Australia 
* Starting this Fall, Dr. Vander Linden's address 
will be Dept. of Mathematics and Compnter Science, 
Calvin College, Grand Rapids, MI 49546, USA. 
way to obtain at least portions of the knowledge 
base automatically. There could be a progn~m 
which automatically derives the knowledge base or 
perhaps the knowledge base could be built as part 
of manual processes that would have to be per- 
formed anyway. Either way, the marginM cost of 
adding text generation would be greatly reduced. 
In this paper, we show that software documen- 
tation is an attractive application for multilingual 
text generation because it is an area in which 
pre-built knowledge bases are beconfing available. 
This is due in large part to the advancements in 
the user interface design comnmnity which we will 
review first. We then discuss the nature of the 
knowledge base required for the generation of doc- 
umentation and how parts of it might be derived 
automatically. Finally, we illustrate this idea us- 
ing DI{AFTEI{, a support tool for generating nml- 
tilingual sot~ware documentation. 
2 Background 
Researchers in user interface design have started 
to build tools which produce both code and docu- 
mentation. These tools tend 1,o be based on a cei1- 
tral inodel of the interface under developme.nt, the 
interface modal, a formal representation which can 
be used not only for code generation but also fbr 
document generation, e.g., (Puerta and Szekely, 
1994; Moriyon et al., 1994). Moriyon et al (1994), 
for example, haw~ used the interface model in the 
generation of on-line help. Their help messages 
indicate the actions a user can perform in a par- 
titular situation and what would result from these 
actions. They report, however, that task-oriented 
help is beyond the capabilities of their system; 
task-oriented help would indicate why the user 
might want to perform any of the actions that 
are available. 
In general, however, the doculnentation, pro- 
dueed by these systems is limited in two main 
ways: it does not correspond to task-oriented doc- 
umentation, which is, however, what end-users re- 
734 
quire and it is usually based on siint)le template 
generation, which does not allow flexibility with 
regard to the style of the text t)rodueed or the 
language that is used. These limitatioils stem, on 
the one hand, fl'om the fact that interface mod- 
els in general contain systcm-or'icnted informatiem 
(e.g., what hat)pens when a button is pushed) but 
1tot task-oriented inforlnation (e.g., why one might 
want to push the button), and, on the other hand, 
from the focus of the research, that is system and 
interLtce design and not natural langm~ge genera- 
tion. 
In the 1)I{AI,"I'EII. projeel;, we have attcmt~ted I;() 
address these two issues. We address the tirst 
by providing reels that allow technical authors to 
buiht richer interface models. These rMmr mod- 
els integrate task information into the information 
already available in interface models. This task in- 
formation, which is commonly tbund in task mod- 
els, e.g., GeMS (Card et al., 1983), supi)orts the 
production of user-centred doeument;ttion. W'e 
address the second by providing more general text 
generation facilities whic.h supt)ort multiple styles 
and multiple languages. 
3 Representing the users' tasks 
Early in the I)I{,AFTEI{ projee:t, we conducted in- 
terviews with technical authors (me)stly soft;ware 
clocmnentation sl)ecialists) in order I;t) understand 
the docmnentation process as it, currently exists, 
to see', if an authoring tool wouht be hell}tiff , and if 
so how it inight be used. We found that technical 
authors stm't the documentation process by le;~rn- 
ing how 1;o use the interface in question, construct- 
ing a user-oriented mental model of the product. 
They Kequently have no input or, her than the soft- 
ware itself. The authors indicated that they wouhl 
weleollle tools to hell) them collect the apl)ropriate 
information and create a formal representation of 
the resulting model. Such a representation wouhl 
supt)ort iterative construction of the doe,lmetlta- 
tion and intbrmat:ion reuse. 
Building our draft;lag tool, therefore, required 
us first, to determine how to represent the model 
of a task, and then to build tools for creating and 
manipulating this model. Given that the gem- 
eral structure of instructional texts is hierarchi- 
cal, we chose a representation that e.xpresses a 
hierart:hy of goals and sub-goals. The reI)resen- 
tation is thus similar to the (;raditi(mal structures 
found in AI plalming, e.g., (Sacerdoti, 1977), and 
also to task models used in interface design, e.g., 
(Card et al., 1983). Because user documentation 
frequently inchldes information other than the raw 
actions to be performed, our representation allows 
authors to include information not typically foulld 
in traditional plan rel)resentations such as: /1ser- 
oriented motiw~tional goals, helpflfl si(le-efl'e(;ts, 
and general COlllliletltS. 
As an example, consider the rei)resentatitm of 
a sub-set of the procedure for retying a new file in 
a Microsoft; WoM-like editor shown in Figm:e 1. 
The owl,1 boxes in the figure ret)resent actions anti 
the rectangh',s represent plans. Ea('h of the action 
nodes in this sl;rueture rel)resent inter(:omw,(:i;e(t 
complexes of procedural and descriptive instances. 
For examl)le , the main us(;r goat of saving a do(;u.- 
meat, represented in the figure by the action node 
"Save ;L Document", is implemented in the knowl- 
edge base as a comple, x of instances repres(mting 
the act;ion being tmrformed (in this case saving), 
tim agent who performs action (the reader), the 
t)atient on whom the aetioll is performed (the cur- 
rent doeunmnt), etc. All of this itlforination is re- 
quired to generate expressions of the action, but 
1)resenting it would overly complicate the graph. 
The links actually shown in tilt; figure are based 
on the, procedural relations in the domain model. 
For exalnple, the I)lan for saving a document 
(Save-l)ocument-Plan) is linked to its goal (Save 
A Do(:umelfl;), to its precondition (()t)e,n-Savc- 
As), and to its sul)-at:tions of typing a name for the 
(;llrrellt document (Tyl)e-Document-Name), open- 
ing l;he fohler in which it is to t)e saved (Ot)ei> 
l,'ohler), and clicking the Save tmtton (Choose- 
Save-Ilutton). The precondition (Open-Save-As) 
must be tmrformed before the sub-steps may t)e at- 
tempted and is in turn linke(t to fllrther sub-plans 
(Choosing-Plan and Clicking-Plan). This indi- 
cates that the Save-As dialog box may be ope, ned 
by either choosing the Save option from the file, 
melm (Choose-Save-()t)tion) or (',licking the Save 
butttm on the tool bar (Click-Save-h:on). 
'Fhis task model represents the procedures that 
a user might perform when using an at)t)li(;ation 
and is tim basis for generating user-(x;ntrt:(1 (lt)cu- 
meal;aLien, slt(;h as olle of I)I{AFTEI\['s texts shOWll 
in Figm'e 4. It includes the users' high-level goals 
(e.g., "save a document") as well as their low- 
le, vel interf;tce manipulations ("choose the save 
lmtton"). 
4 Input from the Design Process 
In our earlier work, we provided tools that sup- 
l)orted 1;t1(; construction of the task nlodel t)y hand 
(Paris et al., 1995). This went some way to ad- 
dressing the, technical aut;hors' desire for a formal 
model and tools to lmild it.. Building the model 
Dora scratch, howe, ver, even with the, help of our 
menu lmsed interface, was a tedious and lengthy 
735 
Precond/tion \[ 
...~Open Method 11 -- ( Cho%se_gave Opton )l 
Dialog )< " I 
-- ~'-topen Method 21E~,,~ IdSn~ J 
( Save A Document )~-~S'ave Docume'nt Methodl~D~(-~ame ) 
\~ii-on ) 
l(~aT~a~E-~i~)----~ancel Save As Meth0dl-----# ~h~'e C~TEa ~utton ) 
Figure 1: The Saving Procedure Graph 
process which could potentially have rendered tile 
I)I{AFTEI{ system impractical. There was a clear 
need for facilities to ease the input task. In line 
with this, we noticed that certain elements of the 
model were also present in the specifications de- 
veloped in user interface design environments. In- 
deed, we found that a number of the actions and 
objects in the model could be automatically ac- 
quired from a design tool, thus providing basic 
building blocks from which the flfll model could 
be constructed. 
3b illustrate this idea, we have built our exam- 
ple document editor application in VisualWorks, 
a widely available interface design environment 
(Vis, 1994). This tool allows one to define the 
windows, dialog boxes, and other widgets relevant 
for the application under develot)ment, and pro- 
duces a prototype of the interface thus specified. 
Its output also includes declarative specifications 
of all the widgets. These specifications are thus 
available to be exploited by other systems. In par- 
tieular, we found that these specifications could be 
readily transformed into a form appropriate for 
the knowledge base required by a text; generation 
system such as DRAFTEI/.. In our examt)le then, we 
build a VisualWorks mock-up of our word process- 
ing application, and I)RAI,'TEK derives task model 
instmmes for all the windows and widgets in (;he 
application (e.g., the Save-As dialog box and all its 
widget, s) directly fl'om tile SmallTalk source code. 
DItAFTEI{ is also able to infer the basic interface 
actions that can be performed on the various in- 
terface widgets and creates task model instances 
for them as well. For example, the system auto- 
matically defines a clicking action instance for any 
"button" on the interface. Similarly, it c.reates 
opening and (:losing actions for all "windows". 
Although this set of instances does not ret)re- 
sent all tile information that could, in principle, 
be derived from the SmallTalk specitications of 
the editor application, it nevertheless simplifies 
greatly the technical author's task of knowledge 
specification by providing the huilding blocks from 
which higher-level procedures can be defined. In 
tile case of out' admittedly simple example, seven 
of the nine actions in the procedural structure are 
automatically specified. The author is required 
to specify only the main user goal action and the 
three plan nodes. This is, t, hercfore, a step to- 
wards aut;omatically building the knowledge base 
required for the generation system. It is also a step 
towards integrating the (lesign and documentation 
processes, which is now widely recognised as be- 
ing desirable. In our current work, we are investi- 
gating how more of the design knowledge call be 
made accessible ~md uiMel'standable to the tech- 
nical authors, and what other tools would further 
facilitate tile authors' task. We are also looking 
at a tighter integration of the design and docu- 
mentation processes, one in which tile individuals 
involved work together during design. 
5 DRAFTER 
We. now describe I)I\].AFTEI{> a technical authoring 
tool which supports the construction of tile task 
model discussed above and the drafting of multi- 
lingual instructions from that inodel. We will fo- 
cus on how it supports the author in augmenting 
the information automatically acquired Dora the 
interface design tool. I)RAFTEI/,'S general archi- 
tecture, shown in Figure 2, is based on two inain 
processing modules: 
Tile Author Interface (shown oil the fitr 
left of the diagram) allows authors to 
build a task model and to control the 
drafting process. 
The Drafting rlbol (shown on tile far 
right of the diagram) comI)rises two ma- 
jor components: the Text Planner and 
the Tactical Generator. The Te.xt Plan- 
ner determines tile (:o,~t,e.nt and structure. 
736 
Figm'e 2: \])a(;attow in DI{AI,"\['E\[{. 
of the t, ext as well as the detailed slxu<:: 
l;ure of the scnl;en(;(;s (;hcr(;in.. The Tacl;i- 
cal Cen(:ral;or t)(~rforlt'ls (;h(: SllFfacc re&l- 
isation <)f (;tie Selll;ellCCS. 
The. knowle<lge base (in the middl<: of (;}m figure) 
mMerlies the task model built by the (;<x:hni<:al au= 
Lhor. The DrafLing Tool takes this reprcscni;at, ioil 
as input, and produces English an<l f,¥ench draf'ts 
of t, he appropriaW, tul;orial inslxu<:tions. In this 
s<:ction we de(;ail ea<',h of (;hese (:omponenl;s in (;he 
<'.on(,ext of an exampl<,, 
5.1 The Knowledge Base 
The knowl(,<tge base sut)porl;s (;he (:oilst;ru(;l;ion of 
(;he (;ask mo<M discussed above. \[(; is an hierarchi- 
cal stru(:t, ur<: imph:menl;e<l in I,OOM (MacGr(:gor, 
1988). Th(; root is l,h(; l)(mman M(:rg<:(l Upl)er 
Model (Bal;eman, 1995), an ontology <)f <listinc- 
tions relevalfl; in (;xpressing actions, (>t)j(x;l;s, and 
qualities in na.l;urat language. The know\](;dge base 
<:onl;ains t'urther layers corr<:st)ouding 1;o: (1) (;h(: 
conc(;t)l;s and relal;ions general to all insLru(:l;ions; 
(2) those g<;ncral only Ix) software im;erfa(:cs; an<t 
(3) l;hose Sl)(:<:iti<" t;o the chos(,qi soft;wa.r(~ apt)li(:a- 
l;ion d<)mains (in ore' case text i)ro(:(:ssing (;<)<)Is). 
Using (;lle I)I/AF'I'EI/. inl;erfa(:e, (,e(:hnical aul;htns 
specify hi(!)'archi<:al (;ask m(>(Ms, su(:h as (;he one 
shown in Figur(! 1, 1)y building nodes and <'.<m- 
ne(:l;ing l;hem wil;h l;h(,, appropriate I))'o(:edm'al I'C,- 
lal;ions. The low-le.vel buihling blocks of l;he (;ask 
model are derived automal;i(:atly, and I)I{AI,'TI.;II. 
alh)ws (;he (x'~chnical alll;hor 1;o (:Olltl(l(:(; \[,h(}ill and 
a<ld higherqevel (;ask inforula(;ion as ai)prot)riat(: , 
using an inl;(:rfa(:e bas(:<l on (:onlxolled language 
and (;he use. of meims (x) guid(', l;he aul;hor. 
5.2 The Interface 
I)IIAI"TI';I~,S illL(~,rface is imph;ment>e<l in C,,IM mM 
iIMudes l;he following modules: 
* The Knowh'.dgc £'dil.or alh>ws l;h(! aul,hor 
1;() <:Oll,ql;rtl(:l; all<t ltlailli;aill t,h(: t)ro(:t!tltll~/1 
l'(:l)r(~st:nl;aI;iOll; 
e '.Phe Knowh,dg<~ (,'raph, cr allows l;he au- 
(;hot 1;o visualise (;he hierar<:hical sl;ru(:- 
l;m:e of the procedural represenl;at,ion; 
. The Draft Tczt Viewer allows the aul;hor 
1;o view and edil; (;h<'. aul;omal;i<:ally gen- 
eral;ed English an<l Fren<:h drafl;s. 
These fllllCl;ioils Call bc invoked from menus or 
from mous(>s(;nsil;ivc ot)jtx:l;s in a sl;yle (:<)mmon 
1;(> sysi;ems such as Moi:if. 
5.2.1 The Knowledge Editor 
This 1;ool Inak<'.s the st;ru(:tm'e of t;hc knowledge 
base on whi<:h l;h<: \[;ask model is lmill; mot(: ac 
cessiblc 1;<> l;he aul;hor. I(; allows the aul;hor (;o 
perform t,wo basic tasks: (1) sp<'.<:ii~ying (;he ac. 
t, ion nodt:s at)pearing in l;hc Sl;l'tlt;l;llrc all(\[ Ho\[; yel; 
<t<:rivcd fl'OlIl 1;11(: inl;erfact: designed tool; and (2) 
linking existing nodes (,ogt:l;ht:r wit, h (;he al)propri- 
a.(;(; plan insi;anc(;s and relal,ions. The. tirs(; of (;hese 
(;asks is lmrfornmd using a. <:ontrolle<t nalalra.1 bm 
guage inl;erfa<> wlfile the s<'.<:<md is done wit;h a 
<lialog box lllc(:haltisill. 
Specifying (;tie 11(}(l(;s at)l)eal.illg ill t;he t;ask 
model involves stmcit'ying a flfll complex of till 
guist, ic cntil;ics and roh;-filh;rs (<;.g., a<:l.<)rs, acl;(~es, 
desl;inai;ions). Be.<:ause. l;his stru<:tm'c may in<:hah,. 
lIially instances inl,ercomlecl, cd lit pot;cnt, ially mt 
inlalil;ivc ways, w(: have 1)r(>vi<l<:(1 a C(>nlx<>lle(1 Na(> 
m'al l,anguag<, (CNI,) inlx:r\['ac(: for I;|m mlI;h()r. 
7 ;3 7 
Tile interface is shown in Figure 3. This interface 
allows the author to work in terms of sentences 
rather than in terms of interconnected graphs. 
Tile figure, for example, shows the author in the 
process of specifying tile node Save A Document. 
The top line of text (reader save \[information\]) 
shows the current state of the CNL specification. 
Words in brackets must be further specified. This 
is done by clicking on the word and selecting the 
appropriate pattern from a list of possible expan- 
sions. In tile figure, the author has clicked on 
\[information\] and is presented with a list of the 
types of information from which \[document\] can 
be selected. This process is driven by a controlled 
natural language grammar which specifies possible 
expansions at each point of tile derivation. The 
bottom line of text presents a flllly expanded de- 
fault at each point in the derivation. In the figure, 
this CNL text is "reader save current document" 
which could be expressed in English in a mnnber 
of ways including "Save the current document" 
and "To save tile document". 
Once the action nodes of the graph have been 
created, or perhaps while they are being created, 
the author has the ability to link them together us- 
ing a set of predefined procedural relations: goal, 
precondition, sub-action, side-effect, warning, and 
cancellation. This is done with a graphical outlin- 
ing mechanism. This mechanism allows authors to 
drag actions from the ACTIONS pane and drop 
them on the various procedural relation slots in 
the workspace pane, or, alternatively, to create 
new actions to fill the slots. The result is a proce- 
dural hierarchy such as the one shown in Figure 1. 
This interface allows the author to specify the 
procedure in several ways. They may start from 
the main goal and work down tile structure, or 
they may start by specifying all the low-level ac- 
tions and object and work up the structure. 
5.2.2 The Knowledge Grapher 
The Knowledge Grapher prevents tile author 
from losing orientation by maintaining the cur- 
rent state of the procedural structure in graphical 
form. This form is like that shown in Figure 1. Be- 
cause the nodes are mouse-sensitive, it allows the 
author to iifitiate construction and maintenance 
functions by clicking on the appropriate nodes in 
tile graph. Authors can also invoke tile drafting 
tool from the graph. 
5.2.a The Draft Text Viewer 
The author may draft multilingual instructions 
oil any portion of tile procedural structure at any 
point in the specification process. This task is 
performed by the Drafting Tool which is briefly 
described in tile next section. This tool pro- 
duces a draft of the instructions in English and 
French. These are presented to the author by tile 
Draft Text Viewer. The presented text is mouse- 
sensitive, allowing the author to access the knowl- 
edge base entry for selected part of tile text. In 
this way, the author can modify the underlying 
knowledge base while working from the text. In 
some cases the writer will decide to modify the 
generated text rather than tile underlying knowl- 
edge. For this purpose, a text editor is currently 
provided. 
5.3 The Drafting Tool 
When the author initiates the Drafl;ing Tool (see 
Figure 2), m~.AF'rl~t calls the Text Planner with 
the discourse goal: make the user colnpetent to 
perform tile action specified by the author. The 
Text Planner selects the content appropriate for 
the instructions and builds a deep representation 
of the text to be generated. This portion of the 
text plalming task is done by tile text planner de- 
veloped by Moore and Paris (1993). Tile Text 
Planner then specifies the detailed elements of the. 
sentence structure. This portion of the task is 
done by a descendent of IMAGENE (Vander Lin- 
den and Martin, 1995). 
Once complete, the text plans are passed to 
the Tactical Generator which generates t, he actual 
text in English and French. This task is performed 
by tile English and French resources of tile Komet- 
Penman Multi-Lingual development environment 
(KPML) (Bateman, 1995), The drafts generated 
for the example procedure are shown in Figm'e 4. 
In these texts, we see. that the main nser goal, 
that of saving a document, is given as a title to the 
series of steps. Then, the steps to be perfi)rmed 
to achieve this goal are given. More detail on the, 
drafting process can be found elsewhere. 
6 Summary 
In this paper, we have shown that the knowl- 
edge base required to produce user-oriented docu- 
Inentation automatically can be partially obtained 
from user interface tools and then augmented ap- 
propriately by technical authors. We presented a 
multilingual drafting tool which exploits output 
fi'om an interface design tool and provides flexible 
support to technical authors for augmenting the 
interface model thus obtained in order to build the 
task model required to generate documentation. 
We argued that software docuinentation is thus 
an attractive and realistic application for natural 
language generation. In our current work, we are 
extending the percentage of the model that can be 
738 
~\[~ Define ~ctlan 
"eader save \[inf°rmai\[c\] ........ t, 'i 
/ \[&pp°intment \] I 
/,,ame of \[document\] I 
.ldescrJ.ptJon of \[appointment}\[ "eadersavecurlentldate 
of \[<~ppoJnt ..... t, / 
/.~t~t t,,,,~ of \[~ppo±nt ...... tl / 
\[stop time of \[appointment\] \] 
Figure 3: The Controlled Natural Language Interface 
To Save a Document 
1. Choose Save ti'om tlm file menu. 
-OR- 
Click on the Saw~' icon. 
Word displays the Save As dialog box. 
2. Type the document name in the Save Cur- 
rent Document As tield. 
3. ()pen the fohter of the document. 
4. Choose the Save button. 
You can quit the Save As dialog box by choos- 
ing the Cancel button. 
Enregistrement d'un document 
1. Choisir Enregistrer dans le menu Fichier. 
OU BIEN 
Cliquer sur l'icone Enregistrer. 
Word atlichera la zone de dialogue Enregistrer Sous. 
2. Introduire lc titre du document dans la zone de 
texte Enregistrer le Document. 
3. Ouvrir le fichier du docmnent. 
4. Choisir le bouton Enregistrer. 
Vous pouvez quitter la zone de dialogue Enregistrer 
Sous en choisissant le bouton Annuler. 
Figure 4: Generated English and French Drafts 
built automatically, so as to increase the use.tiff- 
ness of the sysl;em and its potential marketability. 
We are also planning to evaluate the systeln with 
technical au/;hors. 
References 
John A. BateInan. 1995. KPML: The KOME'r- 
Penman (Multilingual) Development Environ- 
ment. ~Ik;ehnical report, Institut fiir Integrierte 
Publikations- und Informationssysteme (IPSI), 
GMD, Darmstadt, July. Release 0.8. 
S. K. Card, T. P. Moran, and A. Newell. 1983. 
The Psychology of Human-Computer l'ntcrac- 
tion. Lawrence Earlbaum Associates, Ilillsdale, 
NJ. 
Robert MacGregor. 1988. A Deductive Pattern 
Matcher. In Proceedings of the 1988 Conferertce 
on Artificial Intelli.qence, St Paul, MN, August. 
American Association of Artiticial Intelligence. 
Johmma D. Moore and Cdcile L. Paris. 11993. 
Planning text for advisory dialogues: Capturing 
intentional and rhetorical information. Compu- 
tational Linguistics, 1.9(4):651 694. 
Rot)erto Moriyon, Pedro Szekely, and Robert 
Neches. 1994. Automatic generation of hel l) 
fi'om interface design models. In CHI'9d PTv- 
cecdings, Boston, Mass. Computer \[Illnlan \[ii- 
lea'actions. 
Cdcile Paris, Kcith Vander Linden, Markus 
Fischer, Anthony Hartley, Lyn Pemberton, 
Richard Power, and Donia Scott,. 1995. A sup- 
port tool for writing mnltilingual instructions. 
In IJCAI-95, pages 1.398 1404. 
Angel R. Puerta and l'edro Szekely. 1994. Model- 
based interface development. CHI-94 Tutorial 
Notes. 
Em'l l). Sacerdoti. 1977. A Structurc for Plans 
and Behavior. Elsevier, New York. 
Keith Vander Linden and James It. Martin. 119!)5. 
Expressing local rhetorical relations in instruc- 
tional text;: A case-study of the purpose rela- 
tion. Co'mputational Linguistics, 21(1):29 57, 
March. 
ParcPlace Systelns, hn:., 999 E. Arques Avenue, 
Sunnyvale, CA 94086-4593, 11994. The Visual- 
Works Docurner~,tation. 
739 
