Computer Science
ComputerScience,1970-2008-Computer Science-2001.jsonl.gz.gz
Computer Science
4aea147cc568f6520004d8123740c24e452d2c8e
From RAGS to RICHES: Exploiting the Potential of a Flexible Generation Architecture

The RAGS proposals for generic specification of NLG systems includes a detailed account of data representation, but only an outline view of processing aspects. In this paper we introduce a modular processing architecture with a concrete implementation which aims to meet the RAGS goals of transparency and reusability. We illustrate the model with the RICHES system -- a generation system built from simple linguistically-motivated modules.


Introduction
As part of the RAGS (Reference Architecture for Generation Systems) project,  introduces a framework for the representation of data in NLG systems, the RAGS 'data model'. This model offers a formally well-defined declarative representation language, which supports the complex and dynamic data requirements of generation systems, e.g. different levels of representation (conceptual to syntax), mixed representations that cut across levels, partial and shared structures and 'canned' representations. However £ We would like to acknowledge the financial support of the EPSRC (RAGS -Reference Architecture for Generation Systems: grant GR/L77102 to Donia Scott), as well as the intellectual contribution of our partners at Edinburgh (Chris Mellish and Mike Reape: grant GR/L77041 to Mellish) and other colleagues at the ITRI, especially Nedjet Bouayad-Agha. We would also like to acknowledge the contribution of colleagues who worked on the RICHES system previously: Neil Tipper and Rodger Kibble. We are grateful to our anonymous referees for their helpful comments. RAGS, as described in that paper, says very little about the functional structure of an NLG system, or the issues arising from more complex processing regimes (see for example Robin (1994), Inuie et al., (1992) for further discussion).
NLG systems, especially end-to-end, applied NLG systems, have many functionalities in common. Reiter (1994) proposed an analysis of such systems in terms of a simple three stage pipeline. More recently Cahill et al (1999) attempted to repeat the analysis, but found that while most systems did implement a pipeline, they did not implement the same pipeline -different functionalities occurred in different ways and different orders in different systems. But this survey did identify a number of core functionalities which seem to occur during the execution of most systems. In order to accommodate this result, a 'process model' was sketched which aimed to support both pipelines and more complex control regimes in a flexible but structured way (see (Cahill et al., 1999), (RAGS, 2000)). In this paper, we describe our attempts to test these ideas in a simple NLG application that is based on a concrete realisation of such an architecture 1 . The RAGS data model aims to promote comparability and re-usability in the NLG research community, as well as insight into the organisation and processing of linguistic data in NLG. The present work has similar goals for the processing aspects: to propose a general approach to organising whole NLG systems in a way which promotes the same ideals. In addition, we aim to test the claims that the RAGS data model approach supports the flexible processing of information in an NLG setting.

The RAGS data model
The starting point for our work here is the RAGS data model as presented in . This model distinguishes the following five levels of data representation that underpin the generation process: The representations aim to cover the core common requirements of NLG systems, while avoiding over-commitment on less clearly agreed issues relating to conceptual representation on the one hand and concrete syntax and document rendering on the other. When one considers processing aspects, however, the picture tends to be a lot less tidy: typical modules in real NLG systems often manipulate data at several levels at once, building structures incrementally, and often working with 'mixed' structures, which include information from more than one level. Furthermore this characteristic remains even when one considers more purely functionally-motivated 'abstract' NLG modules. For example, Referring Expression Generation, commonly viewed as a single task, needs to have access to at least rhetorical and document information as well as referencing and adding to the syntactic information.
To accommodate this, the RAGS data model includes a more concrete representational proposal, called the 'whiteboard' (Calder et al., 1999), in which all the data levels can be represented in a common framework consisting of networks of typed 'objects' connected by typed 'arrows'. This lingua franca allows NLG modules to manipulate data flexibly and consistently. It also facilitates modular design of NLG systems, and reusability of modules and data sets. However, it does not in itself say anything about how modules in such a system might interact.
This paper describes a concrete realisation of the RAGS object and arrows model, OASYS, as applied to a simple but flexible NLG system called RICHES. This is not the first such realisation:  describes a partial re-implementation of the 'Caption Generation System' (Mittal et al., 1999) which includes an objects and arrows 'whiteboard'. The OASYS system includes more specific proposals for processing and inter-module communication, and RICHES demonstrates how this can be used to support a modular architecture based on small scale functionally-motivated units. Together these components provide a central core for RAGS-style NLG applications, allowing separate parts of NLG functionality to be specified in independent modules, which communicate exclusively via the OASYS server.

OASYS (Objects and Arrows
The O/A data representation is a simple typed network representation language. An O/A database consists of a collection of objects, each of which has a unique identifier and a type, and arrows, each of which has a unique identifier, a type, and source and target objects. Such a database can be viewed as a (possibly disconnected) directed network representation: the figures in section 5 give examples of such networks.
OASYS pre-defines object and arrow types required to support the RAGS data model. Two arrow types, el (element) and el(<integer>), are used to build up basic network structuresel identifies its target as a member of the set represented by its source, el (3), identifies its target as the third element of the tuple represented by its source. Arrow type realised by relates structures at different levels of representation. for example, indicating that this SemRep object is realised by this SynRep object. Arrow type revised to provides for support for nondestructive modification of a structure, mapping from an object to another of the same type that can be viewed as a revision of it. Arrow type refers to allows an object at one level to indirectly refer to an object at a different level. Object types correspond to the types of the RAGS data model, and are either atomic, tuples, sets or sequences. For example, document structures are built out of DocRep (a 2-tuple), DocAttr (a set of DocFeatAtoms -feature-value pairs), DocRe-pSeq (a sequence of DocReps or DocLeafs) and DocLeafs.
The active database server supports multiple independent O/A databases. Individual modules of an application publish and retrieve objects and arrows on databases, incrementally building the 'higher level', data structures. Modules communicate by accessing a shared database. Flow of control in the application is event-based: the OASYS module has the central thread of execution, calls to OASYS generate 'events', and modules are implemented as event handlers. A module registers interest in particular kinds of events, and when those events occur, the module's hander is called to deal with them, which typically will involve inspecting the database and adding more structure (which generates further events).
OASYS supports three kinds of events: publish events occur whenever an object or arrow is published in a database, module lifecycle events occur whenever a new module starts up or terminates, and synthetic events -arbitrary messages passed between the modules, but not interpreted by OASYS itself -may be generated by modules at any time. An application starts up by initialising all its modules. This generates initialise events, which at least one module must respond to, generating further events which other modules may respond to, and so on, until no new events are generated, at which point OASYS generates finalise events for all the modules and terminates them.
This framework supports a wide range of architectural possibilities. Publish events can be used to make a module wake up whenever data of a particular sort becomes available for processing. Lifecycle events provide, among other things, an easy way to do pipelining: the second module in a pipeline waits for the finalise event of the first and then starts processing, the third waits similarly for the second to finalise etc. Synthetic events allow modules to tell each other more explicitly that some data is ready for processing, in situation where simple publication of an object is not enough.
RICHES includes examples of all three regimes: the first three modules are pipelined using lifecycle events; LC and RE, FLO and REND interact using synthetic events; while SF watches the database specifically for publication events.

RICHES
The RICHES system is a simple generation system that takes as input rhetorical plans and produces patient advice texts. The texts are intended to resemble those found at the PharmWeb site (http://www.pharmweb.net). These are simple instructional texts telling patients how to use certain types of medicines, such as nosedrops, eye drops, suppositories etc.. An example text from PharmWeb is shown in figure 1, alongside the corresponding text produced by RICHES.
The main aim of RICHES is to demonstrate the feasibility of a system based on both the RAGS data model and the OASYS server model. The modules collectively construct and access the data representations in a shared blackboard space and this allows the modules to be defined in terms of their functional role, rather than say, the kind of data they manipulate or their position in a processing pipeline. Each of the modules in the sys-How to Use Nose Drops 1. Blow your nose gently, so that it is clear.

Wash your hands.
3. Unscrew the top of the bottle and draw some liquid into the dropper.

Tilt your head back.
5. Hold the dropper just above your nose and put the correct number of drops into your nostril.
6. DO NOT let the dropper touch the inside of your nose. 7. Keep your head tilted back for two to three minutes to help the drops run to the back of your nose.
8. Replace the top on the bottle.

PharmWeb -Copyright©1994-2001. All rights reserved
Blow your nose so that it is clear.

Wash your hands
Unscrew the top. Then draw the liquid into the dropper.
Tilt your head back Hold the dropper above your nose. Then put the drops into your nostril.
The dropper must not touch the inside.
Keep your head tilted back for two to three minutes so that the drops run to the back. tem is in itself very simple -our primary interest here is in the way they interact. Figure 2 shows the structure of the system 2 . The functionality of the individual modules is briefly described below.

Rhetorical Oracle (RO)
The input to the system is a RhetRep of the document to be generated: a tree with internal nodes labelled with (RST-style) rhetorical relations and RhetLeaves referring to semantic proposition representations (SemReps). RO simply accesses such a representation from a data file and initialises the OASYS database. tures, annotated with their SemReps, are part of the picture library, and Media Selection builds small pieces of DocRep referencing the pictures.

Document Planner (DP)
The Document Planner, based on the ICONOCLAST text planner (Power, 2000) takes the input RhetRep and produces a document structure (DocRep). This specifies aspects such as the text-level (e.g., paragraph, sentence) and the relative ordering of propositions in the DocRep.
Its leaves refer to SynReps corresponding to syntactic phrases. This module is pipelined after MS, to make sure that it takes account of any pictures that have been included in the document.
Lexical Choice (LC) Lexical choice happens in two stages. In the first stage, LC chooses the lexical items for the predicate of each SynRep. This fixes the basic syntactic structure of the proposition, and the valency mapping between semantic and syntactic arguments. At this point the basic document structure is complete, and the LC advises REND and SF that they can start processing. LC then goes into a second phase, in- terleaved with RE and FLO: for each sentence, RE determines the referring expressions for each noun phrase, LC then lexicalises them, and when the sentence is complete FLO invokes LinGO to realise them.

Referring Expressions (RE) The Referring
Expression module adapts the SynReps to add information about the form of a noun phrase. It decides whether it should be a pronoun, a definite noun phrase or an indefinite noun phrase.

Sentence Finaliser (SF)
The Sentence Finaliser carries out high level sentential organisation. LC and RE together build individual syntactic phrases, but do not combine them into whole sentences. SF uses rhetorical and document structure information to decide how to complete the syntactic representations, for example, combining main and subordinate clauses. In addition, SF decides whether a sentence should be imperative, depending on who the reader of the document is (an input parameter to the system).
Finalise Lexical Output (FLO) RICHES uses an external sentence realiser component with its own non-RAGS input specification. FLO provides the interface to this realiser, extracting (mostly syntactic) information from OASYS and converting it to the appropriate form for the realiser. Currently, FLO supports the LinGO realiser (Carroll et al., 1999), but we are also looking at FLO modules for RealPro (Lavoie and Rambow, 1997) and FUF/SURGE (Elhadad et al., 1997).

Renderer (REND)
The Renderer is the module that puts the concrete document together. Guided by the document structure, it produces HTML formatting for the text and positions and references the pictures. Individual sentences are produced for it by LinGO, via the FLO interface. FLO actually processes sentences independently of REND, so when REND makes a request, either the sentence is there already, or the request is queued, and serviced when it becomes available.

LinGO
The LinGO realiser uses a widecoverage grammar of English in the LKB HPSG framework, (Copestake and Flickinger, 2000). The tactical generation component accepts input in the Minimal Recursion Semantics formalism and produces the target text using a chartdriven algorithm with an optimised treatment of modification (Carroll et al., 1999). No domainspecific tuning of the grammar was required for the RICHES system, only a few additions to the lexicon were necessary.

An example: generation in RICHES
In this section we show how RICHES generates the first sentence of the example text, Blow your nose so that it is clear and the picture that accompanies the text.
The system starts with a rhetorical representation (RhetRep) provided by the RO (see Figure 3) 3 . The first active module to run is MS which traverses the RhetRep looking at the semantic propositions labelling the RhetRep leaves, to see if any can be illustrated by pictures in the picture library. Each picture in the library is encoded with a semantic representation. Matching between propositions and pictures is based on the algorithm presented in Van Deemter (1999) which selects the most informative picture whose representation contains nothing that is not contained in the proposition. For each picture that will be included, a leaf node of document representation is created and a realised by arrow is added to it from the semantic proposition object (see Figure  4).  the sentence is an imperative one). SF waits for the syntactic structure of indvidual clauses to be complete, and then inspects the syntactic, rhetorical and document structure to decide how to combine clauses. In the example, it decides to represent the rhetorical 'motivation' relation within a single text sentence by using the subordinator 'so that'. It also makes the main clause an imperative, and the subordinate clause indicative.
As soon as SF completes a whole syntactic sentence, FLO notices, and extracts the information required to interface to LinGO with an MRS structure. The string of words returned by LinGO, is stored internally by FLO until REND requests it.
Finally, REND draws together all the information from the document and syntactic structures, and the realiser outputs provided by FLO, and produces HTML. The entire resultant text can be seen on the right hand side of figure 1.