A Representation for Complex and Evolving Data Dependencies 
in Generation 
C Mellish $, R Evans t, L Cahill t, C Doran t, D Paiva t, M Reape $, D Scott t, N Tipper t 
tInformation Technology Research Institute, University of Brighton, Lewes Rd, Brighton, UK 
SDivision of Informatics, University of Edinburgh, 80 South Bridge, Edinburgh, UK 
rags@itri, brighton, ac. uk 
http :/www. itri. brighton, ac. uk/proj ect s/rags 
Abstract 
This paper introduces an approach to represent- 
ing the kinds of information that components 
in a natural  generation (NLG) sys- 
tem will need to communicate to one another. 
This information may be partial, may involve 
more than one level of analysis and may need 
to include information about the history of a 
derivation. We present a general representation 
scheme capable of handling these cases. In ad- 
dition, we make a proposal for organising inter- 
module communication in an NLG system by 
having a central server for this information. We 
have validated the approach by a reanalysis of 
an existing NLG system and through a full im- 
plementation of a runnable specification. 
1 Introduction 
One of the distinctive properties of natural lan- 
guage generation when compared with other 
 engineering applications is that it has 
to take seriously the full range of linguistic rep- 
resentation, from concepts to morphology, or 
even phonetics. Any processing system is only 
as sophisticated as its input allows, so while a 
natural  understanding system might 
be judged primarily by its syntactic prowess, 
even if its attention to semantics, pragmatics 
and underlying conceptual analysis is minimal, 
a generation system is only as good as its deep- 
est linguistic representations. Moreover, any at- 
tempt to abstract away from individual gener- 
ation systems to a more generic architectural 
specification faces an even greater challenge: 
not only are complex linguistic representations 
required, able to support the dynamic evolu- 
tionary development of data during the gener- 
* Now at the MITRE Corporation, Bedford, MA, USA, 
cdoran@mitre, org. 
ation process, but they must do so in a generic 
and flexible fashion. 
This paper describes a representation devel- 
oped to meet these requirements. It offers a 
formally well-defined declarative representation 
, which provides a framework for ex- 
pressing the complex and dynamic data require- 
ments of NLG systems. The approach supports 
different levels of representation, mixed repre- 
sentations that cut across levels, partial and 
shared structures and 'canned' representations, 
as well as dynamic relationships between data 
at different stages in processing. We are using 
the approach to develop a high level data model 
for NLG systems as part of a generic generation 
architecture called RAGS 1. 
The framework has been implemented in the 
form of a database server for modular genera- 
tion systems. As proof of concept of the frame- 
work, we have reimplemented an existing NLG 
system. The system we chose was the Caption 
Generation System (CGS) (Mittal et al., 1995; 
Mittal et al., 1998). The reimplementation in- 
volved defining the interfaces to the modules of 
CGS in terms of the RAGS representations and 
then implementing modules that had the requi- 
site input and output representations. 
Generation systems, especially end-to-end, 
applied generation systems, have, unsurpris- 
ingly, many things in common. Reiter (1994) 
proposed an analysis of such systems in terms 
of a simple three stage pipeline. More recently, 
the RAGS project attempted to repeat the anal- 
1This work is supported by ESPRC grants 
GR/L77041 (Edinburgh) and GR/L77102 (Brighton), 
RAGS: Reference Architecture for Generation Systems. 
We would also like to acknowledge the contribution of 
Jo Calder to the ideas and formalisation described in 
this paper. In particular, parts of this paper are based 
on (Calder et al., 1999). 
119 
ysis (Cahill et al., 1999a), but found that while 
most systems did implement a pipeline, they 
did not implement the same pipeline - different 
functionalities occurred in different places and 
different orders in different systems. In order 
to accommodate this result, we sought to de- 
velop an architecture that is more general than 
a simple pipeline, and thus supports the range 
of pipelines observed, as well as other more com- 
plex control regimes (see (Cahill et al., 1999a; 
Cahill et al., 1999b)). In this paper, we argue 
that supporting such an architecture requires 
careful consideration of the way data represen- 
tations interact and develop. Any formal frame- 
work for expressing the architecture must take 
account of this. 
2 The representational requirements 
of generation systems 
We noted in the introduction that generation 
systems have to deal with a range of linguis- 
tic information. It is natural, especially in the 
context of a generic architecture proposal, to 
model this breadth in terms of discrete layers 
of representation: (1999a) introduce layers such 
as conceptual, semantic, rhetorical, syntactic 
and document structure, but the precise demar- 
cation is not as important here as the princi- 
ple. The different kinds of information are typi- 
cally represented differently, and built up sepa- 
rately. However the layers are far from indepen- 
dent: objects at one layer are directly related to 
those at others, forming chains of dependency 
from conceptual through rhetorical and seman- 
tic structure to final syntactic and document re- 
alisation. This means that data resources, such 
as grammars and lexicons, and processing mod- 
ules in the system, are often defined in terms of 
mixed data: structures that include informa- 
tion in more than one representation layer. So 
the ability to represent such mixed structures 
in a single formal framework is an important 
property of a generic data proposal. 
In addition, it is largely standard in gener- 
ation as elsewhere in  applications, to 
make extensive use of partial representations, 
often using a type system to capture grades of 
underspecification. An immediate corollary of 
providing support for partial structures is the 
notion that they may become further specified 
over time, that data structures evolve. If the 
framework seeks to avoid over-commitment to 
particular processing strategies it needs to pro- 
vide a way of representing such evolution ex- 
plicitly if required, rather than relying on de- 
structive modification of a structure. Related 
to this, it should provide explicit support for 
representing alternative specifications at any 
point. Finally, to fully support efficient pro- 
cessing across the range of applications, from 
the simple to the most complex, the represen- 
tation must allow for compact sharing of infor- 
mation in tangled structures (two structures 
which share components). 
In addition to these direct requirements of the 
generation task itself, additional requirements 
arise from more general methodological consid- 
erations: we desire a representation that is for- 
mally well defined, allows for theoretical rea- 
soning about the data and performance of sys- 
tems, and supports control regimes from simple 
deterministic pipelines to complex parallel ar- 
chitectures. 
3 The Representation Scheme 
In this section, we present our proposal for a 
general representation scheme capable of cover- 
ing the above requirements. Our formulation is 
layered: the foundation is a simple, flexible, rig- 
orously defined graph representation formalism, 
on top of which we introduce notions of com- 
plex types and larger data structures and rela- 
tionships between them. This much is sufficient 
to capture the requirements just discussed. We 
suppose a yet higher level of specification could 
capture a more constraining data model but 
make no specific proposals about this here, how- 
ever the following sections use examples that do 
conform to such a higher level data model. 
The lowest level of the representation scheme 
is: 
• relational: the basic data entity is x -~ y, 
an arrow representing a relation from ob- 
ject x to object y; 
• typed: objects and arrows have an asso- 
ciated type system, so it is possible to de- 
fine classes and subclasses of objects and 
arrows. 
At the most fundamental level, this is more or 
less the whole definition. There is no commit- 
ment to what object or arrow types there are or 
120 
how they relate to each other. So a representa- 
tion allowed by the scheme consists of: 
• a set of objects, organised into types; 
• a set of binary relations, organised into 
types; 
• a set of arrows, each indicating that a rela- 
tion holds between one object and another 
object. 
Sets, sequences and functions 
For the next level, we introduce more struc- 
ture in the type system to support sets, se- 
quences and functions. Objects are always 
atomic (though they can be of type set, se- 
quence or function) - it is not possible to make 
an object which actually is a set of two other 
objects (as you might with data structures in a 
computer program). To create a set, we intro- 
duce a set type for the object, and a set mem- 
bership arrow type (el), that links the set's el- 
ements to the set. Similarly, for a sequence, we 
introduce a sequence type and sequence mem- 
ber arrow types (1-el, 2-el, 3-el, ... ), and for a 
function, we have a complex type which spec- 
ifies the types of the arrows that make up the 
domain and the range of the function. 
SemRep 
~ fun(Role.SemRep) 
7 V show SemRep SemRep 
Figure 1: The partial semantic representation 
of "The second chart shows the number of days 
on the market" 
As an example, consider Figure 1, which 
shows a semantic representation (SemRep) from 
the CGS reimplementation. Here, the tree 
nodes correspond to objects, each labelled with 
its type. The root node is of type SemRep, and 
although it is not an explicit sequence type, we 
can see that it is a triple, as it has three sequence 
member arrows (with types 1-el, 2-el and 3-el). 
Its first arrow's target is an object of type DR 
(Discourse Referent). Its second represents a set 
of SemPred (Semantic Predicate) objects, and in 
this case there's just one, of type show. Its third 
element is a (partial) function, from Role arrow 
types (agent and affected are both subtypes of 
Role) to SemReps. (In this case, the SemReps 
have not yet been fully specified.) 
Local and non-local arrows 
The second extension to the basic representa- 
tion scheme is to distinguish two different ab- 
stract kinds of arrows - local and non-local. 
Fundamentally we are representing just a homo- 
geneous network of objects and relationships. In 
the example above we saw a network of arrows 
that we might want to view as a single data 
structure, and other major data types might 
similarly appear as networks. Additionally, we 
want to be able to express relationships between 
these larger 'structures' - between structures 
of the same type (alternative solutions, or re- 
vised versions) or of different types (semantic 
and syntactic for example). To capture these 
distinctions among arrows, we classify our ar- 
row types as local or non-local (we could do 
this in the type system itself, or leave it as an 
informal distinction). Local arrows are used to 
build up networks that we think of as single 
data structures. Non-local arrows express rela- 
tionships between such data structures. 
All the arrow types we saw above were local. 
Examples of non-local arrows might include: 
realises These arro~vs link something more ab- 
stract to something less abstract that re- 
alises it. Chains of realises arrows might 
lead from the original conceptual input to 
the generator through rhetorical, seman- 
tic and syntactic structures to the actual 
words that express the input. 
revises These arrows link a structure to an- 
other one of the same type, which is con- 
sidered to be a 'better' solution - perhaps 
because it is more instantiated. It is impor- 
tant to note that parts of larger structures 
can be revised without revising the entire 
structure. 
coreference These arrows link structures 
which are somehow "parallel" and which 
perhaps share some substructure, i.e., tan- 
gled structures. For instance, document 
representations may be linked to rhetorical 
representations, either as whole isomorphic 
structures or at the level of individual con- 
stituents. 
121 
Notice that the representation scheme does 
not enforce any kind of well-formedness with 
respect to local and non-local arrows. In fact, 
although it is natural to think of a 'structure' as 
being a maximal network of local arrows with 
a single root object, there's no reason why this 
should be so - networks with multiple roots rep- 
resent tangled structures (structures that share 
content), networks that include non-local links 
might be mixed representations, containing in- 
formation of more than one sort. Such tech- 
niques might be useful for improving generator 
efficiency, or representing canned text or tem- 
plates, cf. (Calder et al., 1999). 
Partial and Opaque structures 
Partial structures are essential when a module 
needs to produce a skeleton of a representa- 
tion that it does not have the competence to 
completely fill out. For instance, lexical choice 
brings with it certain syntactic commitments, 
but in most NLG systems lexical choice occurs 
some time before a grammar is consulted to 
flesh out syntactic structure in detail. 
Figure 2: A partial structure 
By simply leaving out local arrows, we can 
represent a range of partial structures. Con- 
sider Fig. 2, where the triangles represent local 
structure, representing a sentence object and its 
component verb phrase. There is a link to a sub- 
ject noun phrase object, but none of the local 
arrows of the actual noun phrase are present. In 
subsequent processing this local structure might 
be filled in. This is possible as long as the noun 
phrase object has been declared to be of the 
right type. 
An opaque structure is one which has an in- 
complete derivational history - for example part 
of a syntactic structure without any correspond- 
ing semantic structure. Three possible reasons 
for having such structures are (a) to allow struc- 
ture to be introduced that the generator is not 
capable of producing directly, (b) to prevent the 
generator from interfering with the structure 
thus built (for example, by trying to modify an 
idiom in an inappropriate way), or (c) to im- 
prove generator efficiency by hiding detail that 
may lead to wasteful processing. An opaque 
structure is represented simply by the failure 
to include a realises arrow to that structure. 
Such structures provide the basis for a gener- 
alised approach to "canning". 
4 Implementation 
There are many ways that modules in an 
NLG system could communicate information 
using the representation scheme just outlined. 
Here we describe a particularly general model 
of inter-module communication, based around 
modules communicating with a single cen- 
tralised repository of data called the whiteboard 
(Calder et al., 1999). A whiteboard is a cumu- 
lative typed relational blackboard: 
• typed and relational: because it is based 
on using the above representation scheme; 
• a blackboard: a control architec- 
ture and data store shared between 
processing modules; typically, modules 
add/change/remove objects in the data 
store, examine its contents, and/or ask to 
be notified of changes; 
• cumulative: unlike standard blackboards, 
once data is added, it can't be changed or 
removed. So a structure is built incremen- 
tally by making successive copies of it (or of 
constituents of it) linked by revises links 
(although actually, there's no constraint on 
the order in which they are built). 
A whiteboard allows modules to add ar- 
rows (typically forming networks through ar- 
rows sharing source or target objects), to in- 
spect the set of arrows looking for particular 
configurations of types, or to be informed when 
a particular type of arrow (or group of arrows) 
is added. 
The whiteboard is an active database server. 
This means that it runs as an independent pro- 
cess that other modules connect to by appropri- 
ate means. There are essentially three kinds of 
interaction that a module might have with the 
whiteboard server: 
• publish - add an arrow or arrows to the 
whiteboard; 
122 
• query - look for an arrow or arrows in the 
whiteboard; 
• wait - register interest in an arrow or ar- 
rows appearing in the whiteboard. 
In both query and wait, arrows are specified 
by type, and with a hierarchical type system on 
objects and relations, this amounts to a pattern 
that matches arrows of subtypes as well. The 
wait function allows the whiteboard to take the 
initiative in processing - if a module waits on a 
query then the whiteboard waits until the query 
is satisfied, and then tells the module about it. 
So the module does not have to continuously 
scan the whiteboard for work to do, but can 
let the whiteboard tell it as soon as anything 
interesting happens. 
Typically a module will start up and regis- 
ter interest in the kind of arrow that represents 
the module's input data. It will then wait for 
the whiteboard to notify it of instances of that 
data (produced by other modules), and when- 
ever anything turns up, it processes it, adding 
its own results to the whiteboard. All the mod- 
ules do this asynchronously, and processing con- 
tinues until no module has any more work to 
do. This may sound like a recipe for confusion, 
but more standard pipelined behaviour is not 
much different. In fact, pipelining is exactly a 
data-based constraint - the second module in a 
pipeline does not start until the first one pro- 
duces its output. 
However, to be a strict pipeline, the first mod- 
ule must produce all of its output before the sec- 
ond one starts. This can be achieved simply by 
making the first module produce all its output 
at once, but sometimes that is not ideal - for ex- 
ample if the module is recursive and wishes to 
react to its own output. Alternative strategies 
include the use of markers in the whiteboard, 
so that modules can tell each other that they've 
finished processing (by adding a marker), or 
extending the whiteboard architecture itself so 
that modules can tell the whiteboard that they 
have finished processing, and other modules can 
wait for that to occur. 
5 Reconstruction of the Caption 
Generation System 
In order to prove this representation scheme 
in practice, we have implemented the white- 
board in Sicstus Prolog and used it to support 
data communications between modules in a re- 
construction of the Caption Generation System 
(Mittal et al., 1995). CGS is a system developed 
at the University of Pittsburgh, which takes in- 
put from the SAGE graphics presentation sys- 
tem (Roth et al., 1994) and generates captions 
for the graphics SAGE produces. We selected it 
for this effort because it appeared to be a fairly 
simple pipelined system, with modules perform- 
ing clearly defined linguistic tasks. As such, we 
thought it would be a good test case for our 
whiteboard specification. 
Although the CGS is organised as a pipeline, 
shown in Figure 3, the representations commu- 
nicated between the modules do not correspond 
to complete, separate instances of RAGS data- 
type representations. Instead, the representa- 
tions at the various levels accumulate along the 
pipeline or are revised in a way that does not 
correspond exactly to module boundaries. Fig- 
ure 3 gives a simple picture of how the different 
levels of representation build up. The labels for 
the RAGS representations refer to the following: 
• I = conceptual; 
• II -- semantic; 
•III = rhetorical; 
• IV = document; 
• V = syntactic. 
For instance, some semantic (II) information is 
produced by the Text Planning module, and 
more work is done on this by Aggregation, but 
the semantic level of representation is not com- 
plete and final until the Referring Expression 
module has run. Also, for instance, at the 
point where the Ordering module has run, there 
are partially finished versions of three different 
types of representation. It is clear from this that 
the interfaces between the modules are more 
complex than could be accounted for by just re- 
ferring to the individual levels of representation 
of RAGS. The ability to express combinations of 
structures and partial structures was fundamen- 
tal to the reimplementation of CGS. We high- 
light below a few of the interesting places where 
these features were used. 
123 
AbsSemRep 
I-el ~~ .................................... SemRep 
--(~------~_set{KBPredl ~ fun(Role,set(KBId)) I-el ~3-el 
.... /X ........ 
el agent affected .... DR fun(Role,set(SemRep)) ~i/ ~ ..... ~ el?set(SemPredi~t A ~ . • 
nresent set(KSld) 0 ...... v • ~--"- ................. / agen,/ \a\]Jec,ea 
el / \ el ..... " .......... ~ ¢J / "k~ present S~mRep SemRep 
chart1 chart2 
Figure 4: Combined Abstract Semantic Representation and Concrete Semantic Representation for 
the output: "These two charts present information about house sales from data-set ts-1740" 
CG$ arohita,~lu'e RAGS representat/on$ 
II Ill IV ~' SAGE 
-- .......... 
tuning II 
- .......... 
I1 I11 iV --' .......... 
I\[ I11 IV 
.......... I;11@ 
11 III Iv v ......... 
II I11 IV V 
......... III1  
II 111 IV V 
l-- .......... IIIII 
FUF 
Figure 3: A RAGS view of the CGS system 
5.1 Referring Expression Generation 
In many NLG systems, (nominal) referring ex- 
pression generation is an operation that is in- 
voked at a relatively late stage, after the struc- 
ture of individual sentences is fairly well speci- 
fied (at least semantically). However, referring 
expression generation needs to go right back to 
the original world model/knowledge base to se- 
lect appropriate semantic content to realise a 
particular conceptual item as an NP (whereas 
all other content has been determined much ear- 
lier). In fact, there seems to be no place to 
put referring expression generation in a pipeline 
without there being some resulting awkward- 
ness. 
In RAGS, pointers to conceptual items can 
be included inside the first, "abstract", level of 
semantic representation (AbsSemRep), which is 
intended to correspond to an initial bundling of 
conceptual material under semantic predicates. 
On the other hand, the final, "concrete", level 
of semantic representation (SemRep) is more 
like a fully-fledged logical form and it is no 
longer appropriate for conceptual material to 
be included there. In the CGS reimplementa- 
tion, it is necessary for the Aggregation mod- 
ule to reason about the final high-level semantic 
representation of sentences, which means that 
this module must have access to "concrete" se- 
mantic representations. The Referring Expres- 
sion generation module does not run until later, 
which means that these representations cannot 
be complete. 
Our way around this was to ensure that the 
initial computation of concrete semantics from 
abstract semantics (done as part of Aggrega- 
tion here) left a record of the relationship by 
including realises arrows between correspond- 
ing structures. That computation could not be 
completed whenever it reached conceptual ma- 
terial - at that point it left a "hole" (an ob- 
ject with no further specification) in the con- 
crete semantic representation linked back to the 
conceptual material. When referring expression 
was later invoked, by following the arrows in the 
124 
resulting mixed structure, it could tell exactly 
which conceptual entity needed to be referred 
to and where in the semantic structure the re- 
sulting semantic expression should be placed. 
Figure 4 shows the resulting arrangement for 
one example CGS sentence. The dashed lines 
indicate realises, i.e. non-local, arrows. 
5.2 Handling Centering Information 
The CGS Centering module reasons about the 
entities that will be referred to in each sentence 
and produces a representation which records the 
forward and backward-looking centers (Grosz et 
al., 1995). This representation is later used by 
the Referring Expression generation module in 
making pronominalisation decisions. This in- 
formation could potentially also be used in the 
Realisation module. 
Since Centering is not directly producing re- 
ferring expressions, its results have to sit around 
until they can actually be used. This posed 
a possible problem for us, because the RAGS 
framework does not provide a specific level of 
representation for Centering information and 
therefore seems on first sight unable to account 
for this information being communicated be- 
tween modules. The solution to the problem 
came when we realised that Centering informa- 
tion is in fact a kind of abstract syntactic in- 
formation. Although one might not expect ab- 
stract syntactic structure to be determined until 
the Realisation module (or perhaps slightly ear- 
lier), the CGS system starts this computation in 
the Centering module. 
Thus in the reimplementation, the Centering 
module computes (very partial) abstract syn- 
tactic representations for the entities that will 
eventually be realised as NPs. These represen- 
tations basically just indicate the relevant Cen- 
tering statuses using syntactic features. Figure 
5 shows an example of the semantics for a typi- 
cal output sentence and the two partial abstract 
syntactic representations computed by the Cen- 
tering module for what will be the two NPs in 
that sentence 2. As before, dashed lines indicate 
realises arrows. Of course, given the discussion 
of the last section, the semantic representation 
objects that are the source of these arrows are in 
fact themselves linked back to conceptual enti- 
ties by being the destination of realises arrows 
2FVM = Feature Value Matrix. 
from them. 
When the Referring Expression generation 
module runs, it can recover the Centering infor- 
mation by inspecting the partial syntactic rep- 
resentations for the phrases it is supposed to 
generate. These partial representations are then 
further instantiated by, e.g., Lexical Choice at 
later stages of the pipeline. 
6 Conclusion 
The representation scheme we have proposed 
here is designed specifically to support the re- 
quirements of the current state-of-the-art NLG 
systems, and our pilot implementation demon- 
strates the practical applicability of the pro- 
posal. Tangled, partial and mixed structures 
are of obvious utility to any system with a flex- 
ible control strategy and we have shown here 
how the proposed representation scheme sup- 
ports them. By recording the derivational his- 
tory of computations, it also supports decisions 
which partly depend on earlier stages of the 
generation process (e.g., possibly, lexical choice) 
and revision-based architectures which typically 
make use of such information. We have shown 
how the representation scheme might be the ba- 
sis for an inter-module communication model, 
the whiteboard, which supports a wide range of 
processing strategies that require the represen- 
tation of complex and evolving data dependem 
cies. The fact that the whiteboard is cumula- 
tive, or monotonic in a logical sense, means that 
the whiteboard also supports reasoning about 
the behaviour of NLG systems implemented in 
terms of it. This is something that we would 
like to exploit directly in the future. 
The reimplementation of the CGS system 
in the RAGS framework was a challenge to 
the framework because it was a system that 
had already been developed completely inde- 
pendently. Even though we did not always un- 
derstand the detailed motivation for the struc- 
ture of CGS being as it was, within a short time 
we reconstructed a working system with mod- 
ules that corresponded closely to the original 
CGS modules. The representation scheme we 
have proposed here was a key ingredient in giv- 
ing us the flexibility to achieve the particular 
processing scheme used by CGS whilst remain- 
ing faithful to the (relatively simple) RAGS 
data model. 
125 
SemRep 
fun(Role,setlSemRep)) 
sl S "'. 
t t ~. 
2 AbsSynRep "~ AbsSynRep _(:5 
~, 
, , / \ \ 
ckward-looking-cemer ckward.looking-cenler 
+ + 
Figure 5: Arrangement of centering information for the output sentence above 
The representation scheme is useful in situa- 
tions where modules need to be defined and im- 
plemented to work with other modules, possibly 
developed by different people. In such cases, the 
representation scheme we propose permits pre- 
cise definition of the interfaces of the modules, 
even where they are not restricted to a single 
'level' of representation. Even though the con- 
trol structure of CGS is quite simple, we found 
that the use of a centralised whiteboard was use- 
ful in helping us to agree on interfaces and on 
the exact contribution that each module should 
be making. Ultimately, it is hoped that the use 
of a scheme of this type will permit much more 
widespread 'plug-and-play' among members of 
the NLG community. 

References 

Lynne Cahill, Christy Doran, Roger Evans, Chris Mellish, Daniel Paiva, Mike Reape, Donia Scott, and Neil Tipper. 1999a. In Search of a Reference Architecture for NLG Systems. In Proceedings of the 7th European Workshop on Natural Language Generation, pages 77-85, Toulouse. 

Lynne Cahill, Christy Doran, Roger Evans, Chris Mellish, Daniel Paiva, Mike Reape, Donia Scott, and Neil Tipper. 1999b. Towards a Reference Architecture for Natural Language Generation Systems. Technical Report ITRI-99-14, Information Technology Research Institute (ITRI), University of Brighton. 

Jo Calder, Roger Evans, Chris Mellish, and Mike Reape. 1999. "Free choice" and templates: how to get both at the same time. In "May I speak freely?" Between templates and free choice in natural  generation, number D-99-01, pages 19-24. Saarbriicken. 

B.J. Grosz, A.K. Joshi, and S. Weinstein. 1995. Centering: a framework for modelling the local coherence of discourse. Computational Linguistics, 21 (2):203-226. 

V. O. Mittal, S. Roth, J. D. Moore, J. Mattis, and G. Carenini. 1995. Generating explanatory captions for information graphics. In Proceedings of the 15th International Joint Conference on Artificial Intelligence (IJCAI'95), pages 1276-1283, Montreal, Canada, August. 

V. O. Mittal, J. D. Moore, G. Carenini, and S. Roth. 1998. Describing complex charts in natural : A caption generation system. Computational Linguistics, 24(3):431-468. 

Ehud Reiter. 1994. Has a consensus NL generation architecture appeared and is it psycholinguistically plausible? In Proceedings of the Seventh International Workshop on Natural Language Generation, pages 163-170, Kennebunkport, Maine. 

Steven F. Roth, John Kolojejchick, Joe Mattis, and Jade Goldstein. 1994. Interactive graphic design using automatic presentation knowledge. In Proceedings of CHI'94: Human Factors in Computing Systems, Boston, MA.  
