<?xml version="1.0" standalone="yes"?>
<Paper uid="W98-1428">
  <Title>EXEMPLARS: A Practical, Extensible Framework For Dynamic Text Generation</Title>
  <Section position="6" start_page="271" end_page="273" type="evalu">
    <SectionTitle>
4 Related Work
</SectionTitle>
    <Paragraph position="0"> Following \[Reiter &amp; Meilish 92\], we view the process of selecting the most specific exemplar to be one of rule classification. Intheir approach, the process begins by forming a rule instance with appropriate fillers, which is then classified in the taxonomy of rules. Once the rule instance has been classified, any relevant (possibly inherited) attributes are read off, and its particular action is invoked. Our approach is very much the same, though the terms are slightly different: first an exemplar instance is constructed and initialized with the given arguments; this instance is then classified in the exemplar specialization hierarchy (making use of more specialized but otherwise equivalent exemplar instances); once the most specific applicable exemplar has been found, its particular action is likewise invoked, unless its (possibly inherited) exclusion conditions are true.</Paragraph>
    <Paragraph position="1"> The primary way in which our approach differs from that of Reiter and Mellish is in the choice of classification procedure: while we employ a simple decision tree-style traversal of a tree-structured specialization hierarchy, they make use of a more sophisticated Classification algorithm in a potentially more complex taxonomy. The particular classification algorithm they employ is the one built-in to I1, the knowledge representation system used in their IDAS system. While this algorithm potentially offers more in the way of automated reasoning, in our view it suffers from the inability to easily make use of dynamically determined constraints, such as those pertaining to the addressee or the discourse Context.</Paragraph>
    <Paragraph position="2"> As Reiter and Mellish point out, their classification-based approach to planning closely resembles systemic approaches (e.g. \[Vander Linden &amp; Martin 95\]), especially insofar as both are deterministic choice makers (in contrast to unification-based systems). In a sense, our approach is even more closely related to systemic ones, at least those that allow arbitrary Lisp code in the choosers that determine the features used in systemic network traversal. However, what Reiter and MeUish fail to point* out is the rather different flavor of classification vs. systemic network traversal: in a classification-based approach, no action is taken until the most specific rule is found; in contrast, in the systemic approach, action (in the form of executing realization statements) is performed as the network is traversed. As we saw in the preceding section, it is possible for a more specific rule to augment, the action of its parent in the hierarchy,*yielding much the same behavior as with systemic network traversal; nevertheless, it should be emphasized that this is not required in a classification-based approach.</Paragraph>
    <Paragraph position="3"> Turning now to schema-based approaches such as that of \[Lester &amp; Porter 97\], beyond the obvious differences of representation and the absence of classification, one way in which our approach differs is that we have explicitly embraced a powerful object-oriented programming language, rather than simply embedding a handful of procedural constructs. Since schemas are interpreted rather than reasoned about  as formal objects (as in AI planning approaches), we suggest that the added flexibility of building upon an advanced programming language more than offsets any loss in declarativity.</Paragraph>
    <Paragraph position="4"> Beyond flexibility, the Java basis of EXEMPLARS provides numerous further practical benefits. Perhaps foremost of these is that with just-in-time compilers, the compiled Java code supports the performance demands of interactive web applications. An important factor in this picture is the ability to directlY integrate with application objects, rather than integrating indirectly via some interpretive schemei direct integration also offers better static checking than is usually possible otherwise. Another key practical benefit of the approach is that it becomes possible to take advantage of advanced Java-based system architectures, such as the Java Servlet API \[Sun 98\].3 Finally, looking outside the NLG community, it is worth observing that while we have seen the emergence of numerous template-style HTML generation frameworks e.g., the page compilation facility included with the-Java Web Server --- none include * anything like our extensible classification-based planning mechanism, or even the ability to generate HTML * in a trulY hierarchical fashion. Typically, these frameworks embed special tags and code into HTML, rather than the other way around; while limiting in many respects, note that the mainstream approach does promise a more streamlined authoring process.</Paragraph>
  </Section>
class="xml-element"></Paper>