<?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="11" start_page="74" end_page="75" type="concl">
    <SectionTitle>
6 Conclusions
</SectionTitle>
    <Paragraph position="0"> The reconstruction of CGS has taken the form of working out in detail the RAGS representations passed between modules at each stage for a set of key examples and reimplementing the modules (apart from the Planner and Realiser) in a way that correctly reproduces these representations. The actual implementation used an incrementally growing data store for the RAGS representations which the modules accessed in turn, though the passing of data could also have been achieved in other ways.</Paragraph>
    <Paragraph position="1"> The fact that the reconstruction has been successful indicates that the RAGS architecture is broadly adequate to redescribe this NLG system: * No changes to the existing levels of representation were needed, though it was necessary to make extensive use of partial and mixed representations. null o No new levels of representation needed to be introduced to capture the inter-module communication of the system.</Paragraph>
    <Paragraph position="2"> o All of the levels of representation_apart from the Conceptual level were used significantly in the reconstruction.</Paragraph>
    <Paragraph position="3"> In some ways, it is unfortunate that none of the inter-module interfaces of CGS turned out to use a single level of RAGS representation. Given the motivation for partial and mixed representations above, however, this did not really come as a surprise. It may well be that any really useful reusable modules for NLG will have to have this complexity.</Paragraph>
    <Paragraph position="4">  In spite of the successful testing of the RAGS data model, somedifficulties were encountered: * It was difficult to determine the exact nature of the representations produced by the Planner, though in the end we were able to develop a system to automatically translate these into a format we could deal with.</Paragraph>
    <Paragraph position="5"> o Although the theoretical model of CGS has a simple modular structure, in practice the modules are very tightly inte-gr~ifed and making-the &amp;quot; exact interfaces explicit was not always easy.</Paragraph>
    <Paragraph position="6"> (r) Referring expression generation requires further access to the &amp;quot;knowledge base&amp;quot; holding information about the graphic to be produced.</Paragraph>
    <Paragraph position="7"> This knowledge was only available via interactions with SAGE, and so it was not possible to determine whether the RAGS view of Conceptual Representations was applicable. Our own implementation of referring expression generation had to work around this problem in a nonportable way.</Paragraph>
    <Paragraph position="8"> (r) It became clear that there are many housekeeping tasks that an NLG system must perform following Lexical Choice in order for the final Semantic and Abstract Syntactic Representations to be appropriate for direct input to a realisation system such as FUF.</Paragraph>
    <Paragraph position="9"> o The fact that the system was driving FUF/SURGE seems to have had a significant effect on the internal representations used by CGS. The reconstruction echoed this and as a result may not be as general as could be desired.</Paragraph>
    <Paragraph position="10"> (r) Even though CGS only performs simple types of Aggregation, it is clear that this is a critical module for determining the final form of several levels of representation.</Paragraph>
    <Paragraph position="11"> The division of CGS into modules is different from that used in any NLG systems we have previously worked on and so has been a useful stimulus to think about ways in which reusable modules can be designed. We envisage reusmgat least,the reimplementation of the Centering module in our further work.</Paragraph>
  </Section>
class="xml-element"></Paper>