<?xml version="1.0" standalone="yes"?>
<Paper uid="W05-1603">
  <Title>Ten Years After: An Update on TG/2 (and Friends)</Title>
  <Section position="3" start_page="0" end_page="0" type="metho">
    <SectionTitle>
3 Major Use Cases
</SectionTitle>
    <Paragraph position="0"/>
    <Section position="1" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
3.1 Template generation in the appointment
scheduling domain
</SectionTitle>
      <Paragraph position="0"> Software agents communicated with human agents in order to schedule appointments on behalf of their owners. Communicative goals to be verbalized as dialogue steps in the COSMA system [Busemann et al., 1994] include just a few speech acts for proposing, accepting, modifying, rejecting, or confirming dates or date intervals. See [Busemann, 1996] for a discussion and examples.</Paragraph>
      <Paragraph position="1"> The event-oriented input is created by a non-linguistic component, the scheduling agent system, and converted into a surface-semantic representation, referred to as GIL in [Busemann, 1996], which is verbalized by TG/2.</Paragraph>
      <Paragraph position="2"> GIL was defined since the necessary distinctions at the linguistic level are often based on information distributed all over the input structure. For instance, the choice of prepositions depends on the choice of verbs, which is based on the speech act. TG/2 can only access part of the input at a given moment. Yet generating directly from event-oriented input would have been possible at the cost of complex tests or constraints - thereby affecting the transparency of the grammar - or of more backtracking.</Paragraph>
      <Paragraph position="3"> The necessary restructuring was implemented by simply exploiting the expressive power of the directed acyclic graphs used for feature structure input representation in TG/2. Using co-references, relations between the event-based IN and the language-orientedOUT feature of a set of semantic templates covering all possible inputs were defined. An input is unified with the IN feature, and TG/2 generates from the associated OUT value.</Paragraph>
      <Paragraph position="4"> An additional, practical reason for adopting an &amp;quot;internal&amp;quot; OUT representation is to encapsulate the generation grammar, rendering it independent of external changes of the input</Paragraph>
      <Paragraph position="6"> that this rule is applicable if the input suggests a certain syntactic structure called &amp;quot;s2&amp;quot;, the subject should be in topic position, and active voice is called for. The context-free rule underlying the rule is DECL!ARG FIN ARG fINFg. Path expressions following the category such as deep-subjrefer to substructures of the input, cf. Figure 3. Feature constraints assign nominative case to the first ARG and accusative case to the second; number and person are set to be equal on the first ARG and the verb complex, thus establishing subject verb agreement. Notation: Constraint variables refer to right-hand side elements by virtue of the indices Xi. The reserved index for the left-hand side is X0.</Paragraph>
      <Paragraph position="7"> language, which are accommodated by the feature structure mappings.</Paragraph>
      <Paragraph position="8"> As was to be expected it turned out that GIL, as it stood, was never reused. Instead other internal encodings were required, which could, however, be implemented straightforwardly using the technique mentioned above.</Paragraph>
    </Section>
    <Section position="2" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
3.2 Shallow multilingual generation from
</SectionTitle>
      <Paragraph position="0"> non-linguistic input Later projects required the verbalization of non-linguistic domain-specific representations in multiple languages. In Mietta, database content is verbalized in German, Finnish, Italian and English as part of cross-language information retrieval [Xu et al., 2000]. A useful input representation is created by applying a similar mechanism as in COSMA.</Paragraph>
      <Paragraph position="1"> In COMET, TG/2 is used to generate personalized activity recommendations in a conference scenario that differ with the context consisting of interest and focus values, which form part of the input [Geldof, 1999]. This application uses the possibility of creating side-effects from applying a rule to update a discourse memory whenever a discourse referent is mentioned. It is indeed possible to create arbitrary side-effects by function calls, but care has to be taken that these functions can be called a second time during backtracking to undo the side effects. As side-effects are rarely required, its backtrack functionality is currently not supported and thus requires explicit Lisp (and Java) programming.</Paragraph>
      <Paragraph position="2"> In TEMSIS, air quality reports reports are generated from a database containing measurement data [Busemann and Horacek, 1998]. The communicative goal is interactively specified by the user: the type of report (time series, threshold passing, etc.), the measuring station, the pollutant, a time interval of interest, and some further options relating to content selection. The generated texts can include confirmations about the user's choices as well as canned paragraphs informing about the measuring station or the pollutant in question. Corresponding views on previous periods are generated for comparison. If the report is composed of multiple elements, it is concluded by a summary that answers the key question again.</Paragraph>
      <Paragraph position="3"> A separate, language-independent component for text structuring, accessing the database and calculating further values (e.g., average values) was implemented. It produces the actual inputs for TG/2, each corresponding to one paragraph. All language-specific issues remained within the TG/2 grammar.</Paragraph>
      <Paragraph position="4"> The TEMSIS project was designed to be used in a border region of Germany and France. Thus the application initially generated German and French texts. The grammars comprised about 120 and 100 rules, respectively. In order to find out more details about the speed of grammar development for such an application, and in particular the time it takes to transport the application to a new language, native speakers of English, Chinese, Japanese and Portuguese were asked to produce a TG/2 grammar with the same coverage. Depending on programming skills, it took between two and four person-weeks to get acquainted with the system and to complete the final tests set up. While this result was very encouraging, the grammar writers stated that larger grammars would be less easily developed and maintained.2 As [Busemann and Horacek, 1998] show, the input structures are non-linguistic, i.e., they do not uniquely determine the content-bearing linguistic elements and the sentential structure to be used. These matters were defined in co-operation with the users (cf. [Reiter et al., 1997]). The agreed-upon pieces of text were entered as canned parts into the grammar.</Paragraph>
      <Paragraph position="5"> The grammars of Mietta, COMRIS and TEMSIS contain much more canned parts than the COSMA grammar. This is in direct correspondence to the nature of the respective input representations (see Figure 2).</Paragraph>
    </Section>
    <Section position="3" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
3.3 In-depth realization of surface-semantic
</SectionTitle>
      <Paragraph position="0"> sentence representations A much more in-depth use case for TG/2 is the generation of German sentences that form part of cross-lingual sum2A demonstrator of the resulting multilingual system is online at http://www.dfki.de/service/nlg-demo.</Paragraph>
      <Paragraph position="1"> maries of scientific medical papers written in Italian or English (MUSI project, [Lenci et al., 2002]). The sentences exhibit quite a complicated structure and much medical terminology. Their average length in a sample corpus is 22 words. The input structures (cf. Figure 3 for an example) are the results of a lexical and syntactic choice component [Busemann, 2002] that feeds TG/2. The structures contain specific references to syntactic &amp;quot;plans&amp;quot; (features SBP and NR). Test predicates in the rules check for these features, thus realizing the corresponding structure (cf. Figure 1). The morpho-syntacic features for inflecting the lexical stems are collected through the constraint mechanism and made available to the separate word inflection components MORPHIX-3 [Finkler and Neumann, 1988].</Paragraph>
      <Paragraph position="2"> The input is a rather typical for linguistic realization, a task initially not deemed suitable for systems like TG/2. Previous applications show that TG/2 grammars are domain-dependent and must be replaced when a new task is at at stake. [Busemann and Horacek, 1998] consider this lack of reuse a disadvantage, but state that it is nevertheless acceptable since new grammars can be developed very quickly. For realization, however, a linguistically justified, domain-independent grammar is needed that is expensive to develop but can be reused across applications.</Paragraph>
      <Paragraph position="3"> The parts of a grammar rule depending on input elements can be isolated and treated as an interface between the grammar and any input language. If an input language changes, the test predicates and the access to input substructures need to be recoded.3 This interface allows us to develop generic grammar knowledge that abstracts from specific semantics of test predicates and access details. We call such a generic grammar a protogrammar, as it is supposed to form the reusable basis for different instances geared towards different applications.</Paragraph>
      <Paragraph position="4"> Technically, a protogrammar can be instantiated by defining the test predicates and access methods needed for the input language in question.</Paragraph>
      <Paragraph position="5"> The protogrammar developed covers the main types of sentential structures, as specified by the Duden grammar [Dudenredaktion, 1998]. The NP syntax comprises prenominal APs (on the basis of adjective subcategorization frames), generic possessive constructions, a temporal, a locative and an adverbial modifier and a relative clause. In addition, nouns and adjectives can subcategorize for specific arguments.</Paragraph>
      <Paragraph position="6"> How could a protogrammar be developed independently of a particular input language, as it needs testing? An intuitive, minimal input representation would need to determine the depth of the nesting of constituents (as to avoid endless recursion), specify morpho-syntactic features such as case, number, tense etc., indicate the prepositions and distinguish the syntactic adjuncts at the sentence and NP level. After defining a corresponding language, grammar development could proceed in a way independent of the MUSI application.</Paragraph>
      <Paragraph position="7"> When the other parts of the MUSI system became stable and well-defined, the necessary adaptation of the input language and the grammar were made. It goes without saying that the 3Changes may include restructuring and recoding of information.</Paragraph>
      <Paragraph position="8"> Obviously if the input language encodes different kinds of information, the grammar possibly cannot be reused.</Paragraph>
      <Paragraph position="10"> grammar is not. The LANG feature is specified in the input, whereas the API feature is specified in the rules representing the individual grammars.</Paragraph>
      <Paragraph position="11"> grammar had to be extended to cover linguistic structures not foreseen explicitly in [Dudenredaktion, 1998], but the additional effort was surprisingly small.4 The MUSI grammar comprises about 950 rules with 135 categories, and 14 features for constraints. A sample rule is shown in Figure 1. During the development of this large grammar the use of standard text editors became a nuisance. A grammar development environment was designed and implemented that supports multi-format development of large grammars (see Section 5). With this system, all practical needs arising from using TG/2 as a syntactic realizer could be fulfilled.</Paragraph>
    </Section>
    <Section position="4" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
3.4 Other usage
</SectionTitle>
      <Paragraph position="0"> TG/2 is general enough to be usable for other tasks than NLG.</Paragraph>
      <Paragraph position="1"> A sample grammar for software configuration has been written using the constraint mechanism to define API properties of software components (the &amp;quot;lexicon&amp;quot;) and matching conditions for components to be integrated into a larger piece of software (the &amp;quot;grammar&amp;quot;). The input is a specification of the desired system (e.g., machine translation from Spanish to English), and the system would enumerate the possible specifications it can derive. A sample rule is shown in Figure 4.</Paragraph>
    </Section>
  </Section>
  <Section position="4" start_page="0" end_page="0" type="metho">
    <SectionTitle>
4 Modifications and Extensions
</SectionTitle>
    <Paragraph position="0"> The experience gained from the various applications suggested some modifications and extensions to the system. Also a closer look at comparable systems, most importantly YAG [McRoy et al., 2003], revealed opportunities for improvement. YAG differs from TG/2 in that it is deterministic and thus does not search. Every next rule to be chosen is depicted in the input or identified by a preceding table lookup. Therefore YAG is probably faster than TG/2 since TG/2 lets the interpreter select the next rule. On the other hand, as we will see in Section 4.2, this gives TG/2 some flexibility YAG does not exhibit: TG/2 output can vary according to non-linguistic parameters.</Paragraph>
    <Paragraph position="1"> The need for backtracking associated with search can be kept small in practice. Moreover the costs are small since TG/2 reuses previously generated substrings during backtracking, as described in [Busemann, 1996]. In practice an4The author's guess is that adaptation work required about 20% of the overall effort; unfortunately no reliable figures are available.  Bindungsstellen dieser Substanzen verursacht diese Wirkungen.&amp;quot; [&amp;quot;These effects are caused by a competitive antagonism with acetylcholine on the level of the muscarinic sights of these substances.&amp;quot;]. Comments are separated by semicolons. The structure is simplified by omitting gender, number, mood and phrase type information. other cost factor turned out to be sensible, namely the number of rules to be checked in each cycle. In experiments with automatic rule generation using meta-rules in eGram, [Rinck, 2003] showed a linear increase of TG/2 runtime with the number of rules per left-hand side category.</Paragraph>
    <Paragraph position="2"> With large grammars such as in MUSI, which has about 950 rules, it is important to reduce the number of alternative rules. This can be achieved by using optional right-hand side elements, thus covering many possible verbalizations by a single rule. The semantics of optional right-hand side elements has been refined to capture this idea fully; they must be verbalized if and only if there is input for them. A right-hand side element failing on non-empty input causes the parent rule to fail.</Paragraph>
    <Section position="1" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
4.1 Reducing the need for programming
</SectionTitle>
      <Paragraph position="0"> In comparing YAG and TG/2, [McRoy et al., 2003, p. 417] observe that &amp;quot;YAGs template language is also more declarative, yielding higher maintainability and comprehensibility&amp;quot;. While they do not point out details, it is true that defining TG/2 rules requires some Lisp programming. The test predicates have to be defined and the defined ones have to be called properly, and, in the version reviewed, the access functions to relevant parts of the input have to be specified. Calling an access function such as (theme) should return some part of the input structure that is accessible at the current state of processing. The function would encapsulate the way this is achieved. Access functions may fail, in which case the parent rule may fail.</Paragraph>
      <Paragraph position="1"> A number of frequently used general test predicates such as testing the presence of a feature at a certain location in the input structure, equality of some feature value with a given object, or a list element being the but last one in a list, can be held on offer for grammar developers. Usually most tests can be carried out using one of these, but new demands need programming. Since the structure of the Boolean test predicates is simple, such tasks are not difficult to solve. eGram offers support as for Java all the embedding code such as exception handling is provided and only the core condition must be written.</Paragraph>
      <Paragraph position="2"> Access functions were met with some disgust by grammar writers as new ones are required with the change of the input language, i.e. with any new generation task. It turned out that the advantage of having the access to input material encapsulated did not pay off. The implied possibility of reorganizing or renaming input was never used, as other ways to do this were preferred (cf. [Busemann, 1999]). Instead just relative path descriptions were implemented. The need to provide access functions in both Lisp and Java eventually gave rise to a uniform solution: now a single format for relative path descriptions is used in eGram as a source code that is compiled into Lisp and Java expressions to serve the runtime systems.</Paragraph>
      <Paragraph position="3"> Hence the rule in Figure 1 now has a feature path on each right-hand side element instead of function calls, as in [Busemann, 1996].</Paragraph>
    </Section>
    <Section position="2" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
4.2 Generating Personalized Text
</SectionTitle>
      <Paragraph position="0"> Given a certain input, different outputs may well desirable for different users. Some examples: A user may be an expert or a novice in the topic at stake. Expert users will read terminology whereas novices need explanations or circumscriptions.</Paragraph>
      <Paragraph position="1"> Depending on whether a user is interested in receiving background information, relevant hyperlinks may be inserted into the text.</Paragraph>
      <Paragraph position="2"> When text is generated for display on a hand-held device, it must be organized and presented differently. Sometimes the components producing input for the generator are not capable of accounting for the respective linguistic differences since they don't have a model of the grammar at their disposal. A mechanism is needed to feed the system with parameters corresponding to such distinctions and to translate the parameter settings into appropriate decisions in the generation process. For this purpose the approach to parameterization introduced in [Busemann, 1996] has been refined. First and foremost, all variations that could be generated for a given input must be covered by the grammar. Then the system would produce the complete set, one by one. The grammar writer defines, in cooperation with the application developer, parameters such as expertise, background, and device with appropriate values. She tags all rules that exhibit properties of some parameter value. Then the system can select a rule according to a single parameter. But parameters may be in conflict as well. TG/2 offers a linear preference scheme for the defined parameters implemented in step 2 of the basic algorithm. The grammar writer defines, in cooperation with the application developer, a partial order describing the relative importance of the parameters. With this scheme the system can produce a text that conforms best to the user's preferences.</Paragraph>
      <Paragraph position="3"> The scheme is best explained using an example of two parameters. Let us assume that the user chooses &amp;quot;nonexpert&amp;quot; text with background information. Assume that a conflict set contains the following tagged rules: fR1[expertise: expert, background: -], R2[expertise: non-expert, background: -], R3-[expertise: expert, background: +]g.</Paragraph>
      <Paragraph position="4"> None of the tags matches exactly the specifications. If the parameter expertise is defined to be more important than background, R2 will be selected. If, however, background is preferred over expertise, R3 is applied. [Busemann, 1998] has a more detailed description of this idea.</Paragraph>
      <Paragraph position="5"> While subsequent experiments seem to show the viability of this simple approach to let other components (or the user, via a task interface) influence the system behavior5, a real test will probably consist in its envisaged usage for answer presentation in Semantic Web contexts.</Paragraph>
    </Section>
  </Section>
  <Section position="5" start_page="0" end_page="0" type="metho">
    <SectionTitle>
5 Grammar Development
</SectionTitle>
    <Paragraph position="0"> The development of small grammars with 100 to 200 rules such as the ones underlying COSMA, TEMSIS, Mietta or COMET could safely be developed with standard text editors using the syntax exemplified in Figure 1. However even in this work, the difficulty of maintenance and a considerable error-proneness were observed. With the MUSI grammar, a dimension was reached that made a dedicated grammar development environment necessary. While some abstraction from 5Parameters should not depend on each other to guarantee that the best version is generated first, cf. the discussion in[Busemann, 1996, Section 5].</Paragraph>
    <Paragraph position="1"> the Lisp-like rule format was desirable, the Java implementation XtraGen [Stenzhorn, 2002] required a different format anyway, as it is consistently using XML to encode all objects.</Paragraph>
    <Paragraph position="2"> eGram [Busemann, 2004] was hence designed to developing grammars without bothering about their syntax or size or interpreting NLG system. Major benefits of eGram include a developer-friendly grammar format, syntactic and semantic checks of grammar knowledge, the option to derive additional grammar rules by metarules, and integration with grammar testing in generation systems.</Paragraph>
    <Paragraph position="3"> A major difficulty in the course of developing the MUSI grammar was to maintain consistency. Features used are sometimes not defined, values are not sufficiently restricted, or certain categories do not occur in any other rule. When such grammars are interpreted, errors occur that can be difficult and time-consuming to trace. eGram verifies that every new piece of grammar knowledge is fully consistent with what already exists, thus eliminating many obvious sources of mistake.</Paragraph>
    <Paragraph position="4"> eGram allows the definition of complex objects only after all their elements are defined. Before a rule may be entered, the categories, test predicates, access paths and constraints used must be defined. The eGram GUI offers dynamically generated menus for more complex elements in addition to textual input windows, where these remain necessary. For the definition of e.g. a constraint, a menu would offer all defined features, and for the selected feature, all defined values.</Paragraph>
    <Paragraph position="5"> Different working styles are supported: either the grammar writer pro-actively plans her work by first defining all low-level elements and then proceeding to higher-level ones, or she prefers to add missing elements &amp;quot;on the fly&amp;quot;, i.e. when eGram complains.</Paragraph>
    <Paragraph position="6"> eGram's main pane contains a set of tabs corresponding to the different elements. Clicking on a tab opens a new screen with all the tabs remaining available at any moment (see Figure 5). A set of tabs opens separate sub-panes allowing for the definition of the tests, RHS elements, and constraints of rules.</Paragraph>
    <Paragraph position="7"> In MUSI the major disadvantage of context-free grammars posed a problem. The rules cannot easily express certain linguistic phenomena, such as word order variation, pronominalization, voice, the relation between sentential structures and relative clauses, or verb positions. To cover these phenomena, several hundreds, if not thousands, of different rules must be defined. Every-day practice involved copy-and-paste approaches that are error-prone. Moreover such phenomena are often captured only partially, leaving unknown gaps in the coverage of the grammar.</Paragraph>
    <Paragraph position="8"> eGram is equipped with a meta-rule mechanism that is technically similar to that of Generalized Phrase Structure Grammars [Gazdar et al., 1985]. Meta-rule expansion starts with a set of base rules and then applies to the set of base rules and derived rules. Meta-rules serve as an abbreviation technique and do not affect the expressive power of the system. The basic meta-rule mechanisms and their integration into eGram are described in detail in [Rinck, 2003]. A redesign of the MUSI grammar led to a reduction to 452 base  express various agreement relations. The rule window can be dragged to some other location on the screen, allowing to view multiple objects at the same time. The rules names shown on the left-hand side can be filtered by the elements contained in the rules. For instance by selecting category NP, only the rules with NP as their LHS category are shown. rules. Applying to these base rules 19 meta-rules modeling the above phenomena resulted in 2.488 derived rules, demonstrating that the original grammar did in fact not systematically cover all the phenomena represented by the meta-rules. Integrating grammar development and grammar testing is crucial to verify the effects of modifying a grammar. eGram is implemented in Java and integrated with TG/2 via a client-server interface. The integration with XtraGen is achieved via a Java API. eGram provides suitable export formats for both.</Paragraph>
    <Paragraph position="9"> Calls to the generators can be issued from within eGram. A call to a running generation system consists of an input structure that can be defined within eGram, and the modifications of the grammar since the last call. The generator either returns the generated string or an error message.</Paragraph>
  </Section>
class="xml-element"></Paper>