We present the rags (Reference Architecture for Generation Systems) framework: a specification of an abstract Natural Language Generation (NLG) system architecture to support sharing, re-use, comparison and evaluation of NLG technologies. We argue that the evidence from a survey of actual NLG systems calls for a different emphasis in a reference proposal from that seen in similar initiatives in information extraction and multimedia interfaces. We introduce the framework itself, in particular the two-level data model that allows us to support the complex data requirements of NLG systems in a flexible and coherent fashion, and describe our efforts to validate the framework through a range of implementations. This paper describes an attempt to specify a reference architecture for natural language generation systems. The field of Natural Language Generation (NLG) is characterised by a variety of theoretical approaches, which has the effect of fragmenting the community and reducing the bandwidth of communication. The technology is mature enough for commercial applications to be close, and yet it is relatively rare for NLG software and data to be reused between different researchers. The rags (Reference Architecture for Generation Systems) project set out to exploit the implicit agreement that does exist in the field and focus discussion on the genuine points of theoretical disagreement with the aid of a "standard" vocabulary and reference point. Thus rags aimed to make it easier to: • create reusable data resources (e.g., representative inputs to algorithms, corpora of generated texts together with their underlying representations); • communicate data between NLG program modules written at different times and with different assumptions, and hence allow reuse of such modules; • allow modules (or at least their inputs and outputs) to be defined in a relatively formal way, so that their scope and limitations may be better understood. In this way, applications-oriented systems development should be facilitated, standard interfaces and datasets can emerge, ideas and software can be more easily reused, researchers can realistically specialise in particular areas and comparative evaluation of systems and components may become possible. For natural language understanding, there has been considerable progress in the development of "architectures" and "infrastructures" to support application development, standardisation and evaluation. For instance, the gate architecture [Cunningham et al., 1996 , Bontcheva et al., 2004 provides a suite of usable software modules, facilities to interface new modules whose input and output fit the underlying model and services to aid corpus management, statistical analysis and visualisation of results. rags attempts to start the process for natural language generation by defining an "architecture" for generation systems. We see below that there are interesting reasons why this has turned out to be rather different from gate. However, we do not believe that the current state of the art puts anyone in the position to say what the "right" NLG architecture is: there is simply too little knowledge of the NLG process and too much variation in the goals of creating NLG systems. Premature standardisation would be damaging to the field and stifle theoretical diversity. And yet rags does define an architecture. We resolve this apparent contradiction in the following ways: • We target specifically application-oriented end-to-end generation systems, primarily because systems like these must address all aspects of the generation process. Additionally, a study by Reiter [Reiter, 1994] , discussed further below, suggested that there is some commonality to be found in such systems. We make no claims about other types of system, although it seems likely that many aspects of the discussion here would be relevant to a wider range of systems. • We define the architecture in a particularly flexible way (as described in section 3 below). This means that people can "buy into" rags to varying extents. Naturally the prospect of sharing is increased as one buys more, but it is not an "all or nothing" decision (see section 5). • We use the term reference architecture to refer to rags in order to emphasise the fact that it is not a proposed standard. The existence of a considered, well-specified reference point may be valuable not only to designers of new systems, but also as a point of comparison for existing systems, and even as a focus of discussion of its own deficiencies. In the next section we discuss existing ideas about architectures for NLG and how our proposed framework compares with similar initiatives in other areas. We then proceed to discuss the key features of the framework itself, followed by some of the concrete implementations that have been developed within it. We summarise by discussing how one can use rags as it is now. Finally, we discuss the key contributions that this work has made, look at some of the areas it does not yet address and indicate possible future directions for the rags initiative. Further details of the rags specification, and the software that we distribute, can be obtained from our web site at http://crc.open.ac.uk/projects/rags. Generic architectures for NLG Many different overall architectures have been proposed for NLG systems [De Smedt et al., 1996] , reflecting the range of different applications and the different motivations for constructing systems. Hope that there could be a single, well-specified architecture that would be adequate for many systems was raised when Reiter [Reiter, 1994] suggested that many end-to-end applications-oriented NLG systems followed the same architectural model: a simple three-stage pipeline which could therefore be viewed as a de facto standard or "consensus" architecture. Reiter and Dale [Reiter and Dale, 2000] updated and added further detail to this proposal in their NLG textbook. The overall structure of their model is shown in Figure 1 . The first major task for the rags project, undertaken in 1998, was a comprehensive survey of applied NLG systems in order to validate this "consensus" architecture proposal 1 . We identified 19 systems 2 which met the criteria of being end-to-end application-oriented NLG systems, and sought to correlate their published descriptions with the proposed consensus model. Initial conclusions were encouraging: although these systems had anything from two to seven named modules, virtually all the system could be viewed as a pipeline architecture in which all of the modules corresponded to one, part of one or more than one of the three "consensus" modules (the principal exception to this model was Komet -for more details, see Cahill and Reape [Cahill and Reape, 1998] (2000) formulation uses slightly different terminology, which we also use here, but for our purposes is otherwise not significantly different. 2 The systems surveyed were: Alethgen [Coch and David, 1994] ; Ana [Kukich, 1988] ; Caption Generation System [Mittal et al., 1998 ]; Drafter [Paris et al., 1995] ; Drafter2 [Scott et al., 1998 ]; Exclass [Caldwell and Korelsky, 1994] ; FoG [Goldberg et al., 1994] ; GhostWriter [Marchant et al., 1996] ; GIST [Power and Cavallotto, 1996] ; Gossip [Kittredge and Polguére, 1991] ; HealthDoc [Hirst et al., 1997] ; Joyce [Rambow, 1990] ; Komet [Teich and Bateman, 1994] ; LFS [Iordanskaja et al., 1992] ; ModelExplainer [Lavoie et al., 1996] ; Patent Claim Expert [Sheremetyeva et al., 1996] ; PlanDoc [McKeown et al., 1994] ; PostGraphe [Fasciano and Lapalme, 1996] ; Proverb [Huang, 1994] . Full details and discussion of the survey and results obtained can be found in Paiva [Paiva, 1998] and Cahill and Reape [Cahill and Reape, 1998 ]. 3 they are exemplified in some detail, and effectively prescribed to be complete and of specific types (although some variation is allowed in the contents of a Text Specification). This means that there is almost no flexibility over the assignment of lower level generation tasks (e.g., rhetorical structuring, lexical choice) to modules -if this is proposed as a "consensus" architecture, then one would expect to see all systems undertaking each of these tasks within the same module. The second step of the rags survey attempted to validate this aspect of the model also, a more difficult task because not all systems are described in sufficient detial to make clear judgements. The low level generation tasks considered for this analysis were: Lexicalisation: The choice of content words to appear in the final output text. The combination of several structures (e.g., sentences) into a single, more complex, structure. Rhetorical structuring: The determination of rhetorical relations and their scope. The planning of the material to be incorporate within referring expressions (including the pronominalisation decision). The choice of linear ordering of the elements of the text. The dividing up of information into sentences and paragraphs. Centering/salience/theme: The tracking of salience-related properties of the text within a discourse. This set does not constitute an exhaustive breakdown of NLG into components, but represents the tasks most commonly identified as independent functions within NLG systems. In order to validate the "consensus model" at this level, we assigned each of these tasks to the module of the consensus model in which it occurred. Figure 2 is a graphical representation of the results of this exercise 3 . For each system and task, there are three positions that can be shaded, indicating that the task is (partly or completely) performed within the corresponding module (with the ordering Document Planner, Microplanner and Surface Realiser). For instance, in GhostWriter, aggregation is performed in the Microplanner and salience is considered in both the Document Planner and the Microplanner. For reference, we have included the Reiter and Dale model as the last line of the table, even although it was not specified in detail at the time of the survey. In order for the model to be validated at this level of granularity, we would expect most of the systems to follow the same pattern as this last line. It is quite clear from the diagram that they do not. There is good agreement that Rhetorical Structuring occurs in the Document Planner, but almost as strong disagreement that Segmentation occurs in the Microplanner -most systems do it in the Document Planner. Most tasks seem capable of appearing in any module, or across two modules, and Lexicalisation seems to occur quite often in two disjoint phases. Although such an exercise is always only an approximation, the message of Figure 2 is not in the particular details but in the significant amount of diversity that is indicated. This diversity suggests that while the Reiter and Dale model may have captured some high level intuitions about the organisation of NLG systems, it is too constrained to act as the basis for a formally defined functional architecture reflecting the full range of applied NLG systems. In summary, our conclusions about the validity of the consensus model were: 3 This figure is a re-presentation of the two tables in Cahill and Reape [Cahill and Reape, 1998 ]. Where a task was performed by user intervention, not performed at all or where its placement was unclear, we have omitted it; however we have included placements marked as uncertain in the original tables. Many of the systems surveyed claimed or appeared to follow the three-stage model, however, it was not possible to assign detailed functional descriptions to the three modules that were compatible with all, or even most, systems. 2. Many of the systems had functional submodules in common (such as 'referring expression generation'), but the order of execution of those submodules, and their assignment to the three stages did not form a single overall consistent pattern. 3. There was no simple definition of the data interfaces between the proposed consensus modules, or even the lower level functional modules, in the systems surveyed -most systems manipulated data at several linguistic levels in fairly complicated ways, and 'snapshots' of the data at the putative interfaces did not reveal any strong patterns of what was and what was not instantiated in different systems. Thus, while their proposed "consensus" model represents an important observation about the field, Reiter and Dale's particular position about the definition and timing of modules, as well as their assumptions about how the types of data come together in the interfaces, although examples of good NLG system design, are too restrictive for the general case. To be useful, the rags architecture would need to take a more flexible position on these issues. On reflection, perhaps the conclusions of our survey were not so surprising. Fundamentally, the NLG task can be thought of as a simultaneous constraint satisfaction problem involving knowledge at several linguistic levels [De Smedt et al., 1996] . Researchers proposing novel architectures and search methods for NLG have maintained that efficient generation of optimal texts cannot be achieved by making choices in a predetermined order (for instance, Danlos [Danlos, 1984] ; Wanner and Hovy [Wanner and Hovy, 1996] ; Mellish et al. [Mellish et al., 1998] ). This argues against there being an optimal pipeline or layered approach as found in much current NL understanding work. Greater complexity in data interaction and more variation in order of processing might be expected, making the task of developing a reference architecture more challenging. Nevertheless the survey did reveal enough commonality to justify a search for common principles, as long as the requirement for a precise architecture specification was replaced by the pursuit of a more general framework for developing NLG systems. Such a framework could still provide a basis for interaction between researchers who agree on basic assumptions about their system architectures and data structures -it would not force a particular view (as a full reference architecture would have), but it would provide a common language for expressing and exploring an agreed perspective. The resulting rags framework relaxes the 'architectural' requirement to a point where it is sufficiently inclusive of actual systems to be relevant, yet still sufficiently restrictive to be useful. We achieved this by characterising at a quite abstract level the data types, functional modules and protocols for manipulating and communicating data that most modular NLG systems seem to embody. Thus the main components of the rags proposal are: • a high-level specification of the key (linguistic) data types that NLG systems manipulate internally. This uses abstract type definitions to give a formal characterisation independent of any particular implementation strategy; • a low-level reference implementation specifying the details of a data model flexible enough to support NLG systems. This implementation (the "Objects and Arrows Model") formally characterises the set of legal data representations as a set of typed directed graphs; • a precise XML specification for the data types, providing a standard 'off-line' representation for storage and communication of data between components; • a generic view of how processing modules can interact and combine to make a complete NLG system, using data formats "native" to their particular programming languages which are faithful to the high-and low-level models and exploiting agreed instantiations of the high-level data types; • several sample implementations to show how the development of a range of concrete architectures can be achieved. Figure 3 summarises the structure of the rags model and how it is intended to be used. Different processing modules manipulate rags data using formats native to their particular programming languages (they can, of course, manipulate other kinds of data, but rags says nothing about how that might be communicated between them). These formats provide implementations of the abstract type definitions and are also in correspondance with the "objects and arrows" model, through which they inherit a standard XML serialisation. Two communicating modules need to agree on an instantiation of the abstract data types and can then define their interfaces and exchange data either in an agreed native format or via the XML offline representation. The decoupling of the abstract from the more concrete aspects of the reference architecture results in a 'framework' for developing NLG systems which allows many possible concrete architectures -in order to construct an actual NLG architecture, additional decisions about process and data flow have to be taken. This is one of the ways that the rags architecture is unusually flexible. The resulting model is similar in some ways to the gate architecture for information extraction systems [Cunningham et al., 1996 , Bontcheva et al., 2004 . Both provide assistance in building an application out of modular components provided from elsewhere, and are quite uncommitted to actual processing strategies employed 1. In gate, data communication is achieved through incremental annotation of the texts being analysed, so the implicit data types are strongly grounded in textual elements; since of course NLG does not start off with a text, rags needs a more abstract NLG-oriented repertoire of data types and representations, with less dependence on a single common reference point. rags thus entails taking a stronger theoretical stance, attempting to make a substantive statement but not alienate alternative approaches. 2. gate is a concrete generic implementation platform, with specific libraries and interfaces for application development, concentrating on high-quality support for low-level operations. rags is a framework for specifying implementations (plus some sample implementations), more committed functionally, but less committed implementationally. Both rags and gate support the building of modular systems and the comparative evaluation of system components, but their scope is different. rags supports the specification of a component task and the standardised representation of desired inputs and outputs. gate does this too (with a simpler model of data), but also provides much more direct implementation support. gate has been very successful. In a recent user survey 4 , around half of those who replied were using the system actively in research, applications development or teaching, suggesting a continuing substantial and healthy user base. This success encourages us to hope that something similar will be possible for NLG. However, the success of gate relies on an existing underlying data model, the tipster architecture. Such a model does not yet exist for NLG, so a key contribution of rags is the attempt to specify one. A second useful point of comparison is the 'standard reference model' for intelligent multimedia presentation systems We conclude that all these reference proposals, while similar in intent and structure, have subtly different balances of emphasis. We can distinguish architectures according to a number of dimensions. An architecture can be abstract (supporting design and specification) or concrete (supporting actual implementation mechanisms). It can be prescriptive (narrowly specifying what is possible) or flexible (allowing a range of types of implementation). It can be oriented towards functional specification (specifying the modules and their interactions) or data specification (specifying the data exchanged between or held by modules). Finally, it can be task-oriented (focused on a narrow range of systems with a well-defined task) or generic (open-ended, in terms of what the systems are for). Figure 4 shows informally how rags, gate and the immps model relate to these dimensions. The core of the rags framework is an account of the data that NLG systems manipulate: the rags 'data model'. This model is a two-level description of NLG data structures: the high level model divides NLG data into six basic types with different linguistic roles, and specifies how they relate to each other; the low level model specifies formally what data states can be communicated between NLG modules in the context of the evolving specification of a text. The low level model also provides the basis for uniform off-line representation and communication of data between modules. A user of the rags framework can "buy into" the framework (and existing work using it) to varying degrees. They can, for instance, choose whether or not to: • represent (some of) their data in ways compatible with the rags data model; • use particular instantiations of the abstract types that are already in use; • implement modules with functionality as specified in the set of example rags modules, or compatible with other existing work; • organise their modules in standard ways that emerge from previous work, possily using rags application components. The basic rags framework focuses primarily on the first of these, providing a firm basis for the establishment of agreed approaches to the other aspects as the framework gets used. The rags framework supports six basic data types: Conceptual, Rhetorical, Document, Semantic, Syntactic and Quote. Of these, Syntactic and Quote are dependent on the target language and Conceptual will often be independent of it. For the other three, we take no position on language-dependence, although we suspect that only (parts of) the Semantic level could be language-independent. NLG systems are built assuming many different theories of syntax, semantics, discourse, etc. It would be impossible for rags to produce a generally-acceptable complete definition of representations at any of these levels as there is so much theoretical diversity. Instead, rags defines the different levels of representation primarily in terms of abstract type definitions which specify the components out of which these representations are expected to be made. Here we use standard notation from set theory to characterise the essential structure of the data, independent of any particular implementation (a common approach in theoretical Computer Science, although not used extensively in Computational Linguistics). The notation used in our definitions is fully explained in the rags Reference Manual [Cahill et al., 2001b] , and briefly introduced here. Thus, for instance: (from section 3.1.2, below) defines a Rhetorical Representation (RhetRep) as consisting of a RhetRel (rhetorical relation) and a RhetRepSeq (sequence of RhetReps) for the children. The latter is itself defined in terms of a sequence of one or more elements, each of which is a RhetLeaf or a RhetRep. The abstract type definitions "bottom out" in primitive types, which are indicated as follows: RhetRel ∈ P rimitives rags has nothing further to say about the type RhetRel, which is the set of rhetorical relations. Researchers are invited to instantiate this set as they see fit according to any theoretical position they wish to adopt. That is, rags does not specify the subtypes of primitive types, apart from acknowledging that they may exist. Different implementations may make different assumptions about the subtypes of primitive types, although most effective reusability of code or data will be possible between researchers that do agree. All the definitions of rags datatypes are thus parameterised via these primitive types -they define the overall format of a set of structures but do not stipulate the exact set of values that can appear at the leaves of these structures. Users of rags datasets or modules need to indicate how the primitive types are instantiated as well as how they are using the abstract types. In addition to the abstract type definitions, we also give informal examples of the representations in notations which suggest actual implementation possibilities 5 . 5 rags endorses no specific notations apart from the XML interchange format described in section 3.4. It is important to realise that in a sense there is nothing very novel in the following proposals. They are intentionally anchored in existing practice, and based on detailed study of existing theories. The significance of the rags model comes from the explicit articulation of the distinct levels of representation and their form. We do not believe that NLG systems are always explicit about the nature of their representations (e.g., whether something is semantic or syntactic), and problems arise if this is done badly . Conceptual representations encapsulate references to data 'outside' the NLG system -typically information provided as the generator's input. These are not semantic representations: they may have no simple relation to linguistic decisions and they are assumed not to be created or altereded by the NLG system. For conceptual representations, there is a single primitive type KBId ("knowledge base identifier"). rags specifies how an NLG system can interrogate such data to find out about the outside world, using functions such as: Although conceptual entities may have no simple linguistic interpretation, they nevertheless have to be related to linguistic concepts in order that an NLG system can handle them. This is why the above functions are expressed in terms of semantic predicates, roles, etc., rather than a separate conceptual vocabulary. The rags API for KBIds is very close to the abstract interface between the penman system [Mann, 1983] and its knowledge base, and it could be implemented via an Upper Model [Bateman, 1990] . The specification of this API is also compatible with the view that an NLG system's interaction with an external knowledge source should be through a controlled interface that provides some protection from deficiencies and irregularities in the underlying data [Reiter and Robertson, 1999] . Reiter and Dale [Reiter and Dale, 2000] discuss the elements of a domain model in terms of entities, attributes, relationships and classes (in a hierarchical taxonomy). The above API permits easy querying of such a domain (assuming that relationships are reified). However, Reiter and Dale differ from rags in asserting that the predicates, roles etc. are actually part of the domain, rather than part of a language-oriented view of the domain. In general, principles of content determination in NLG may be very domaindependent, and so a framework like rags can say little about them. Some aspects of content determination are, however, involved in the implementation of KBId s. Rhetorical representations define how propositions (in rags, SemReps -see sections 3.1.4) within a text are related. For example, the first sentence of the text in Figure 5 , "Blow your nose, so that it is clear", generated by the riches system [Cahill et al., 2001a] , can be considered to consist of two propositions: blow your nose and your nose is clear, connected by a relation like MOTIVATION.  Thus a rhetorical representation (RhetRep) is a tree whose internal nodes are labelled with relations (RhetRel), and whose leaves are atomic rhetorical nodes (RhetLeaf, which, as we will see in section 3.2, can, for instance, be thought of as pointers to conceptual or semantic content). An example of a simple rhetorical representation is shown informally in Figure 6 . Here there is a single RhetRep containing a sequence of two RhetLeaf s (associated with semantic content, which is not strictly part of the RhetRep itself). The RhetRel for the RhetRep has the subtype MOTIVATION, a theory-specific relation. The significance of the positions of the subtrees is not specified for the rags representation in general, because it is theory-specific. Theory-specific definitions of relations therefore specify the role of their daughters. For example, an implementation of Rhetorical Structure Theory [Mann and Thompson, 1988] would need to specify that, for example, the first daughter of the MOTIVATION relation is the "nucleus" and the second the "satellite"; were the relation instead CONTRAST, it would specify that the second was another "nucleus". Similarly, an implementation based on the discourse theory of Moser and Moore [Moser and Moore, 1996] would need to specify that, for example, the first daughter of MOTIVATION is the "core" and the second the "contributor", but that the daughters of a CAUSE relation carried no such designation. 11 MOTIVATION
There is also a corresponding work REF that challenges this decomposition.
A Reference Architecture for Natural Language Generation Systems
NATURAL LANGUAGE ENGINEERING
Computer Science