<?xml version="1.0" standalone="yes"?>
<Paper uid="W00-1410">
  <Title>Reinterpretation of an existing*NLG system in a Generic Generation Architecture</Title>
  <Section position="4" start_page="69" end_page="69" type="intro">
    <SectionTitle>
2 The RAGS datatypes
</SectionTitle>
    <Paragraph position="0"> The RAGS project initially set out to develop a reference architecture based on the three-stage pipeline suggested by Reiter (Reiter, 1994). However, a trees or Abstract Semantic Representations at the leaves.</Paragraph>
    <Section position="1" start_page="69" end_page="69" type="sub_section">
      <SectionTitle>
Rhetorical Abstract Rhetorical Representations
</SectionTitle>
      <Paragraph position="0"> are viewed as descriptions of sets of possible Rhetorical Representations. Each one may be transdetailed analysis of existing applied NLG systems formed into some subset of the possible Rhetori(Cahill and Reape~_~ l:998}:suggested~,that~ttch.an~ ar -~: ~&lt;. eaLReprese, ntations by,,means ~ofa,set..o_f~.petmitted chitecture was not specific enough and not closely transformations, e.g. reversing the order of nucleus enough adhered to by the majority of the systems surveyed for this to be used as the basis of the architecture. null The abstract functionality of a generation system can be specified without specific reference to processing. The RAGS approach to this is to develop a data model, that is, to define the functional modules entirely in terms of the datatypes they manipulate and the operations they can perform on them. On top of such a model, more specific process models can be created in terms of constraints on the order and level of instantiation of different types of data in the data model. A 'rational reconstnaction' of some pipeline model might then be produced, but other process models would also be possible.</Paragraph>
      <Paragraph position="1"> The RAGS levels of representation are as follows4: null Conceptual The conceptual level of representation is defined only indirectly through an API via which a knowledge base (providing the content from which generation takes place) can be viewed as if it were defined in a simple KL-ONE (Brachman and Schmolze, 1985) like system.</Paragraph>
    </Section>
  </Section>
class="xml-element"></Paper>