1.2 The form of the model

There is a great deal of diversity in the theory and practice of NLG, and our surveys [Cahill and Reape 1998,Paiva 1998] have shown that there is no simple model that describes well all existing work on applied NLG. We take it as self-evident that the complexity of NLG is such that nobody is currently able to define the ``perfect'' NLG architecture, even if such an idea makes sense. As a result, the RAGS architecture is defined in a set of stages in such a way that researchers can ``buy into'' parts of the model without having to embrace the whole thing. This is permitted through the architecture having three separate parts:

1.

An abstract data model which specifies the types of data manipulated by an NLG system, how they can be represented in concrete terms and what operations are possible on them.

2.

Suggested instantiations of the types in the abstract data model which tie the representations to particular theories or sets of theories.

3.

A pipeline architecture constructed by adding further constraints to the ordering of operations in the data model.

The abstract data model specifies minimal constraints on the scheduling of operations in an NLG system. Anyone who recognises in their work levels of representation corresponding to our abstract data types will be able to exchange example datasets with similar researchers, though really useful exchange may only be possible within a cluster of researchers using the same instantiation (see section 2 below). Anyone implementing an operation defined in the abstract data model will be able to guarantee that this is of use to researchers who adopt the relevant parts of the model (though again this will be affected by the instantiations of the parts that are used). Researchers are free to find interesting ways of scheduling such operations in a complete system. The pipeline architecture exists as a concrete suggestion for one particular family of architectures and to facilitate sharing of datasets that span multiple levels.