<?xml version="1.0" standalone="yes"?>
<Paper uid="P98-1118">
  <Title>A Framework for Customizable Generation of Hypertext Presentations</Title>
  <Section position="3" start_page="0" end_page="718" type="metho">
    <SectionTitle>
2 PRESENTOR Architecture
</SectionTitle>
    <Paragraph position="0"> The architecture of PRESENTOR illustrated in Figure 1 consists of a core generator with several associated knowledge bases. The core generator has a pipeline architecture which is similar to many existing systems (Reiter, 1994): an incoming request is received by the generator interface triggering sequentially the macroplanning, micro-planning, realization and fi- null nally the formatting of a presentation which is then returned by the system. This pipeline architecture minimizes the interdependencies between the different modules facilitating the upgrade of each module with minimal impact on the overall system. It has been proposed that a pipeline architecture is not an adequate model for NLG (Rubinoff, 1992). However, we are not aware of any example from practical applications that could not be implemented with this architecture. One of the innovations of PRESENTOR is in the use of a common presentation structure which facilitates the integration of the processing by the different modules. The macro-planner creates a structure and the other components add to it.</Paragraph>
    <Paragraph position="1"> All modules use declarative knowledge bases distinguished from the generator engine. This facilitates the reuse of the framework for new application domains with minimal impact on the modules composing the generator. As a result, PRESENTOR can allow non-programmers to develop their own generator applications.</Paragraph>
    <Paragraph position="2"> Specifically, PRESENTOR uses the following  types of knowledge bases: * Environment variables: an open list of variables with corresponding values used to specify the configuration.</Paragraph>
    <Paragraph position="3"> * Exemplars: a library of schema-like structures (McKeown, 1985; Rambow and Korelsky, 1992) specifying the presentation to be generated at different levels of abstraction (rhetorical, conceptual, syntactic, surface form). * Rhetorical dictionary: a knowledge base indicating how to realize rhetorical relations linguistically. null * Conceptual dictionary: a knowledge base used to map language-independent conceptual structures to language-specific syntactic structures. null * Linguistic grammar:, transformation rules specifying the transformation of syntactic structures into surface word forms and punctuation marks.</Paragraph>
    <Paragraph position="4"> * Lexicon: a knowledge base containing the  syntactic and morphological attributes of lexemes. null * Format style: formatting specifications associated with different elements of the presentation (not yet implemented).</Paragraph>
    <Paragraph position="5"> As an example, let us consider a simple case illustrated in Figure 2 taken from a design summarization domain. Hyperlinks integrated in the presentation allow the user to obtain additional generated presentations.</Paragraph>
    <Paragraph position="6">  FDBMgris a software component which is deployed on host Gauss.</Paragraph>
    <Paragraph position="7"> FDBM~r ~ns as is a server and a daemon and is written in C(ANSI) and JAVA.</Paragraph>
    <Paragraph position="8"> ...... Figure 2i Presentation Sample The next sections present the different types of knowledge used by PRESENTOR to define and construct the presentation of Figure 2.</Paragraph>
  </Section>
  <Section position="4" start_page="718" end_page="720" type="metho">
    <SectionTitle>
3 Exemplar Library
</SectionTitle>
    <Paragraph position="0"> An exemplar (Rambow et al., 1998; White and Caldwell, 1998) is a type of schema (McKeown, 1985; Rambow and Korelsky, 1992) whose purpose is to determine, for a given presentation request, the general specification of the presentation regarding its macro-structure, its content and its format. One main distinction between the exemplars of PRESENTOR and ordinary schemas is that they integrate conceptual, syntactic and surface form specifications of the content, and can be used for both deep and shallow generation, and combining both generality and simplicity. An exemplar can contain dif- null ferent type of specifications, each of which is optional except for the name of the exemplar: * Name: Specification of the name of the exemplar. null * Parameters: Specification of the arguments passed in parameters when the exemplar is called.</Paragraph>
    <Paragraph position="1"> * Conditions of evaluation: Specification of the conditions under which the exemplar can be evaluated.</Paragraph>
    <Paragraph position="2"> * Data: Specification of domain data instantiated at run-time.</Paragraph>
    <Paragraph position="3"> * Constituency: Specification of the presentation constituency by references to other exemplars. null * Rhetorical dependencies: Specification of the rhetorical relations between constituents. \] * Features specification: Open list of features (names and values) associated with an element of presentation. These features can be used in other knowledge bases such as grammar, lexicon, etc.</Paragraph>
    <Paragraph position="4"> * Formatting specification: Specification of  HTML tags associated with the presentation structure constructed from the exemplar.</Paragraph>
    <Paragraph position="5">  cation of the content (any level of granularity) at the surface level.</Paragraph>
    <Paragraph position="6"> * Documentation: Documentation of the ex null emplar for maintenance purposes.</Paragraph>
    <Paragraph position="7"> Once defined, exemplars can be clustered into reusable libraries.</Paragraph>
    <Paragraph position="8"> Figure 3 illustrates an exemplar, softdescription, to generate the textual description of Figure 2, Here, the description for a given object $SOFT, referring to a piece of software, is decomposed into seven constituents to introduce a title, two paragraph breaks, and some specifications for the software type, its host(s), its usage(s) and its implementation lan- \] guage(s). In this specification, all the constituents are evaluated. The result of this evaluation creates seven presentation segments added as constituents (daughters) to the current growth point in the presentation structure being generated. Referential identifiers (ref 1, ref2, ..., ref4) assigned to some constituents are also being used to specify a rhetorical relation of elaboration and to specify syntactic conjunction. null</Paragraph>
    <Paragraph position="10"> the conceptual specification of an object type.</Paragraph>
    <Paragraph position="11"> The notational convention used in this paper is to represent variables with labels preceded by a $ sign, the concepts are upper case English labels preceded by a # sign, and conceptual relations are lower case English labels preceded by a # sign. In Figure 4 the conceptual content specification is used to built a conceptual tree structure indicating the state concept #HAS-TYPE has as an object $OBJECT which is of type $TYPE. This variable is initialized by a call to the function ikrs.getData( $OBJECT #type ) defined for the application domain.</Paragraph>
    <Paragraph position="12">  resentations to linguistic domain-indepenent representations. This mapping (transition) has the advantage that the modules processing conceptual representations can be unabashedly domain-specific, which is necessary in applications, since a broad-coverage implementation of a domain-independent theory of conceptual representations and their mapping to linguistic representations is still far from being realistic. Linguistic representations found in the conceptual dictionary are deep-syntactic structures (DSyntSs) which are conform to those that REALPRO (Lavoie and Rambow, 1997), PRE-SENTOR'S sentence realizer, takes as input. The main characteristics of a deep-syntactic structure, inspired in this form by I. Mel'~uk's Meaning-Text Theory (Mel'~uk, 1988), are the following: * The DSyntS is an unordered dependency tree with labeled nodes and labeled arcs.</Paragraph>
    <Paragraph position="13"> * The DSyntS is lexicalized, meaning that the nodes are labeled with lexemes (uninflected words) from the target language.</Paragraph>
    <Paragraph position="14"> * The DSyntS is a syntactic representation, meaning that the arcs of the tree are labeled with syntactic relations such as &amp;quot;subject&amp;quot; (represented in DSyntSs as I), rather than conceptual or semantic relations such as &amp;quot;agent&amp;quot;. * The DSyntS is a deep syntactic representation, meaning that only meaning-bearing lexemes are represented, and not function words.</Paragraph>
    <Paragraph position="15"> Conceptual representations (ConcSs) used by PRESENTOR are inspired by the characteristics of the DSyntSs in the sense that both types of representations are unordered tree structures with labelled arcs specifying the roles (conceptual or syntactic) of each node. However, in a ConcS, concepts are used instead of lexemes, and conceptual relations are used instead of relations. The similairies of the representions for the ConcSs and DSyntSs facilitate their mapping and the sharing of the functions that process them.</Paragraph>
    <Paragraph position="16"> Figure 5 illustrates a simple case of lexicalization for the state concept #HAS-TYPE introduced in the exemplar defined in Figure 4. If the goal is a sentence, BE1 is used with $OBJECT as its first (I) syntactic actant and $TYPE as its second (II). If the goal is a noun phrase, a complex noun phrase is used (e.g., software component FDBMgr). The lexicalization can be controlled by the user by modifying the appropriate lexical entries.</Paragraph>
  </Section>
  <Section position="5" start_page="720" end_page="720" type="metho">
    <SectionTitle>
5 Rhetorical Dictionary
</SectionTitle>
    <Paragraph position="0"> PRESENTOR uses a rhetorical dictionary to indicate how to express the rhetorical relations connecting clauses using syntax and/or lexical means (cue words). Figure 6 shows a rule used to combine clauses linked by an elaboration relationship. This rule combines clauses FDBMgr is a software component and FDBMgr is deployed on host Gauss into FDBMgr is a software component which is deployed on host Gauss.</Paragraph>
  </Section>
class="xml-element"></Paper>