<?xml version="1.0" standalone="yes"?>
<Paper uid="A88-1006">
  <Title>FROM WATER TO WINE: GENERATING NATURAL LANGUAGE TEXT FROM TODAY'S APPLICATIONS PROGRAMS 1</Title>
  <Section position="4" start_page="0" end_page="41" type="metho">
    <SectionTitle>
A MOTIVATING EXAMPLE
</SectionTitle>
    <Paragraph position="0"> Consider the description &amp;quot;53rd Mechanized Division&amp;quot;. In most programs today a sufficient representation of the object it names could be just the symbol 53RD-MECHANIZED-DIVISION. The print name of the symbol conveys all the information that a person reading the code needs to know, without it actually playing a role in the program's reasoning. If all we cared about were a single communicative context, we might consider implementing the link between the symbol and the description as though the phrase were one long word without any internal structure. This expedient treatment would severely 2 For a comprehensive description of Mumble-86, see Meteer, McDonald, Anderson, Forster, Gay, Huetmer, &amp; Sibun 1987.  limit our options, however. Indefinite references, such as &amp;quot;a mechanized division&amp;quot;, and subsequent references, &amp;quot;the division&amp;quot;, would have to be handled separately. Pronominalization would not be possible since there are no associated features such as number, gender, and person. Furthermore, since an artificial word would have no internal syntactic structure, a speech production program would have no information on which to base intonation. A better treatment is to introduce into the interface itself some of the generality and structure that the underlying representation is missing.</Paragraph>
    <Paragraph position="1"> In the ALBM interface being developed at BBN, we associate an object like 53RD-MECHANIZED-DMSION with the application of a general template to an explicit set of arguments as shown below:</Paragraph>
    <Paragraph position="3"> By going to this slightly greater effort, we have supplied a hook for handling subsequent reference or other abstractions (&amp;quot;the 53rd and 42nd mechanized divisions&amp;quot;) without first requiring that the underlying program contain the necessary semantic distinctions and linguistic information. We return to this example later and show how the template named in Figure 1 builds an input specification for Mumble.</Paragraph>
  </Section>
  <Section position="5" start_page="41" end_page="42" type="metho">
    <SectionTitle>
MUMBLE'S PLACE
IN THE GENERATION PROCESS.
</SectionTitle>
    <Paragraph position="0"> A key question is what information the input specifications to Mumble represent. This amounts to asking how we take the generation process to divide into subprocesses---what decisions have already been made and are reflected in the specifications, and which ones remain. Since we have positioned the level of the specification language so as to fit the decomposition reflected in our own work and to expedite the use of Mumble-86 by other researchers, the answer can be given quite precisely. For a more complete discussion of our approach and how it contrasts with other work, see (McDonald, Meteer, &amp; Pustejovsky, 1987). Overall we can divide the generation process into three coarse stages: Underlying program-- Developed independently of the generator per se, this will be the expert diagnostician, cooperative database, ICAI tutor, etc. that the human users want to talk with.</Paragraph>
    <Paragraph position="1"> Some event within this underlying program will determine the goals the utterances are to achieve and initiate the generation process.</Paragraph>
    <Paragraph position="2"> Planning -- This process determines how the goals can be achieved in a given context. This includes selecting the information to be communicated (or omitted), determining what perspectives and rhetorical organization the information should be given, and choosing a mapping for the information onto the linguistic resources that the language provides (i.e. open-class words and syntactic constructions).</Paragraph>
    <Paragraph position="3"> Realization--This process carries out the planner's specifications to produce an actual text. It has the responsibility for insuring that the text is grammatical, and will handle the bulk if not all of the syntactic and morphological decision making.</Paragraph>
    <Paragraph position="4"> In these terms, Mumble-86 is a realization component. 3 As such, we expect any system that uses it to be able to supply the following kinds of information about each utterance that it wants produced, couching the information in terms of our specification language. Mumble-86 is agnostic as to whether this information was assembled by a theoretically interesting planning component or merely stipulated in predefined templates.</Paragraph>
    <Paragraph position="5"> (a) The units from which the utterance is to be composed. The mapping for each unit to its intended linguistic resource will either have been already made or will be fully defined for later execution.</Paragraph>
    <Paragraph position="6">  (b) The functional relationships among the units, e.g. predication, head, modifier, given, theme, etc., that direct or constrain the units' organization within the text.</Paragraph>
    <Paragraph position="7"> (c) Lexical choice. As the primary means of  delimiting what information is or is not communicated and what perspectives and connotations are presented, all open class words are choosen by the planner.</Paragraph>
    <Paragraph position="8"> 3 We also refer to Mumble as a &amp;quot;linguistic component&amp;quot;, reflecting the fact that all of the planners and underlying programs that have been used with Mumble to date have concentrated on conceptual issues and left all of the linguistic efforts to it; this designation may have to change in the coming years as the semantic and discourse level contributions of earlier components become more significant.</Paragraph>
    <Paragraph position="9">  We see our specification language as providing a medium for the results of a planner's decisions. The syntax of the language provides a flexible, compositional notation by which a planner may view the potential linguistic form of the utterance it is constructing without having to understand the myriad details entailed by descriptions at the level of the surface structure. In the next section, we describe the syntax of the specification language. We then look at how predefined templates can be used to abstract away some of the details to make it easier for a planner to construct them.</Paragraph>
  </Section>
  <Section position="6" start_page="42" end_page="43" type="metho">
    <SectionTitle>
THE INPUT SPECIFICATION LANGUAGE
</SectionTitle>
    <Paragraph position="0"> Mumble's input specifications may be seen as expressions over a vocabulary of elementary terms and a syntax for their composition. In defining this language, our choice of terms and compositional operators was driven by what appears to be most useful at the linguistic level. The simplest expressions in the language, kernel specifications, represent the choice of a class of phrases with a lexical head and the specification of its arguments.</Paragraph>
    <Paragraph position="1"> This reflects our belief that one almost never chooses just to use a certain word, but rather to describe an action with a verb and a specific set arguments for example (see also Kegl, 1987). The result of realizing a kernel is a phrasal unit comparable to an elementary tree of a Tree Adjoining Grammar. (See Joshi, 1987, for a discussion of properties of a TAG which make them well suited to generation.) Formally, a kernel consists of a realization function and a list of arguments which are applied to it, where a realization function is typically a class of phrases distinguished by the characteristics of the syntactic contexts in which they may appear. Executing the realization function consists of choosing among the phrases and instantiating the choice.</Paragraph>
    <Paragraph position="2"> Larger, more complex utterances are formed by composing kernels: joining them syntactically according to the relationships between them. This process is analogous to adjunction in a TAG. In Mumble, these compositional expressions are called bundles. They have three major parts: (1) The head is either a kernel or a bundle; it is realized first, as an &amp;quot;initial tree&amp;quot; into which other specifications are attached; every bundle must have a head.</Paragraph>
    <Paragraph position="3"> (2) Further-specifications have two parts, a specification (either a kernel or a bundle) and an attachment function, which constrains where the new tree may be adjoined to the surface structure already built; these correspond to the &amp;quot;auxiliary trees&amp;quot; of a TAG; a bundle may have any number of further specifications.</Paragraph>
    <Paragraph position="4">  (3) Accessories contain information about language-specific syntactic details, such as tense and number. Each bundle type has a specific set of obligatory and optional accessories associated with it.  Note that bundles are not constrained as to the size of the text they produce: they may produce a single noun phrase or an entire paragraph.</Paragraph>
    <Paragraph position="5"> Figure 2 shows a representation of the input specification for the description &amp;quot;53rd Mechanized Division&amp;quot; discussed at the beginning of the paper. In the next section we describe how this specification could be built from an object in the underlying program.</Paragraph>
    <Paragraph position="6">  Specifications are implemented as structured objects, indicated by the &amp;quot;#&lt; ... &gt;&amp;quot; convention of CommonLisp; the first symbol after the &amp;quot;&lt;&amp;quot; gives the object's type. Other symbols are either object names (e.g. &amp;quot;general-np&amp;quot;), or in a few cases print forms of whole objects (such as the accessories and their values). Strings in double quotes (e.g. &amp;quot;53rd&amp;quot;) designate words.</Paragraph>
  </Section>
  <Section position="7" start_page="43" end_page="45" type="metho">
    <SectionTitle>
DIRECT MAPPING: THE SIMPLE CASE
</SectionTitle>
    <Paragraph position="0"> The granularity and vocabulary of the input specification language are designed to be well suited for generating natural language. In principle the semantic organization could match the structure of the specification language exactly. If this were the case, the mapping between units in the underlying application program and the specifications to the generator would be direct and one to one. However, we cannot assume that today's underlying program will have the same granularity or be able to reason in the same vocabulary. For example, while the accessories NUMBER, GENDER, and PERSON in the specification above are necessary to determine the correct pronoun, few underlying programs working with mechanized divisions would bother to represent their gender. Rather than force a planner to deal in these terms, we provide a framework for building specifications piecemeal by applying templates that can be specialized to the application. Templates are abstractions of specifications, which stipulate some of the terms in the specification and parameterize others. An object in the underlying program may be mapped to a template through a default specification, as illustrated in Figure 1 and repeated below along with the template ARMED-FORCES=UNIT-NAME:  As a formal entity, this template is essentially a procedure for assembling the data structures that make up a specification. It is a Lisp program and draws on a set of predefined functions (e.g. setbundle-head, no-determiner) to simplify the statement of the necessary actions. Every template is required to provide all of the elements that make up a properly formed realization specification. In this case a bundle for a noun phrase is being assembled, and so there must be a kernel built for the head of the bundle and values given for all the accessories that bundles of that type require. Since the phrases specified by this particular template are compositions linguistically, i.e. they involve the adjunction of two modifiers to the inital np-common-noun, the template includes operations (&amp;quot;add-specializing-description&amp;quot;) that add the sources of the modifiers using the proper attachment function.</Paragraph>
    <Paragraph position="1"> These same techniques may be used to generate longer texts. The following example differs from the last one in three ways:  (1) The templates are building larger structures: discourse units which produce multiple sentences and clause bundles which produce complex sentences.</Paragraph>
    <Paragraph position="2"> (2) Default mappings are defined between classes of objects and templates rather than having to define a mapping for each instance of the class.</Paragraph>
    <Paragraph position="3"> (3) Templates can be called explicitly from other  templates with a dynamically chosen set of arguments.</Paragraph>
    <Paragraph position="4"> The example is from one of the generation tasks in the ALBM domain: to produce a &amp;quot;mission restatement&amp;quot; paragraph describing the essential tasks in some operation. These tasks are presented to the generator as a simple list of TASK-OBJECTS, expressing the who, what, when, where, and why of the task, along with a dependency graph representing the relations between them. Figure 4 shows an example of a task object and a portion of a mission restatment paragraph produced by our current prototype of the text planner.</Paragraph>
    <Paragraph position="5">  Our prototype text planner takes advantage of the uniformity of the objects in the underlying program that motivates the text and the uniformity in the form of the paragraphs to be produced. These uniformities allow us to use predefined templates for these paragraphs in much the same way as McKeown used schemas to produce the overall organization of definitions of data base attributes (McKeown, 1985). Note that there are two very important assumptions inherent in this approach: First, the information needed is explicitly represented in data structures in the underlying program. Second, those data structures are stable, that is, in the lifetime of the project, the structures will not change, or if they do, then the specific templates that access them must change as well.</Paragraph>
    <Paragraph position="6">  The top level function for generating the mission paragraph builds a discourse unit bundle with the first task-object as the head of the bundle and the rest as an ordered list of further-specifications. Since the relations between the task objects in this example is simply sequential-temporal, the default attachment function &amp;quot;new sentence&amp;quot; is used, resulting a sequence of separate sentences, one for each task.</Paragraph>
    <Paragraph position="7"> Figure 5 shows the default specifications for the class task-object and the template it references.</Paragraph>
    <Paragraph position="8"> This template is a specialist which picks out the information from the task object to be included in the mission paragraph. Note that the modularity of the task objects is different from that of the actual sentences which express them. The action and unit combine to form the matrix of the sentence and other slots function as adjuncts, such as the location and intent. The template shown in Figure 6 combines these elements into a clause bundle and sets the accessories to unmarked (not a question or command) and simple present tense. These features are stipulated as part of the style of these paragraphs rather than stemming from anything in the underlying representation.</Paragraph>
    <Paragraph position="9">  In the examples described above, our use of templates is a shorthand for building realization specifications. As such it is appropriate for the very simple text planning that typifies today's generation applications: Already formed objects and expressions in the underlying application program can be associated directly with semi-custom templates with the English words introduced as arguments. In more complex text planning where, for example, the same objects are presented from different perspectives depending on the communicative situation, there is unlikely to already be any expression with the right properties, and it will be the planner's task to construct one. Here too, our facility for mapping objects to specifications will be very useful.</Paragraph>
  </Section>
  <Section position="8" start_page="45" end_page="47" type="metho">
    <SectionTitle>
COMPOSING SPECIFICATIONS
</SectionTitle>
    <Paragraph position="0"> In this section we look ahead to the development of general planners with the ability to dynamically select and orchestrate information from the underlying program to fit the occasion. One of a planner's prime abilities will be to appreciate the functions and consequences of alternative forms and combinations by which the same body of information can be communicated. Our specification language permits such alternatives to be simply stated. We can see this in an illustration taken from our ongoing work with the KRS system in use at the Rome Air Development Center. KRS (&amp;quot;Chris&amp;quot;) is a rule based system for mission planning. Its internal representation is based on instantiating relations represented as lists of symbols: for example the three relations shown below in Figure 7 (&amp;quot;facts&amp;quot; in the lefthand side of one of KRS's production rules), along with their English realizations as given by the direct replacement generator presently included with KRS.</Paragraph>
    <Paragraph position="1">  While perhaps good enough to serve its purpose (i.e. as part of the KRS rule-editor), this text is unnatural--no person would ever say it. Stylistically it is chunky and awkward, but more importantly, it actually mis-communicates the relative value of the three facts by giving them equal weight in the utterance.</Paragraph>
    <Paragraph position="2"> A sophisticated text planner would want to convey not just propositional information but also to indicate its rhetorical significance, e.g. what is important, what is unusual. In the present case, the fact about the assignment of the target was specified by the user and is thus a given. The fact that the target has a search radar may or may not already be known. The fact that this particular radar is known to be active is the most significant, since it is this fact that has an impact on the planning of the mission (i.e. there now have to be radar-suppression aircraft included).</Paragraph>
    <Paragraph position="3"> Depending on whether or not the existence of the search radar is known, a much improved rendering of the three facts could be one of these two: &amp;quot;The target has an active search radar&amp;quot; &amp;quot;The target's search radar is active&amp;quot; Given that we will have already established mappings to suitable templates for each of the three facts independently, the specification of a single sentence expressing all three becomes a matter of combining them into a single specification, varying their positions as bundle heads or further specifications and specifying the appropriate attachment functions. This ability to combine parts without affecting their internal structure is one of the most powerful aspects of our specification language.</Paragraph>
    <Paragraph position="4"> The specification for &amp;quot;The target has an active search radar&amp;quot; (Figure 8) would be built by using the second fact, &amp;quot;part of', as the backbone of the bundle, supplying the head and thereby the main verb has.</Paragraph>
    <Paragraph position="5"> The first fact-- (target ... 8Es0310)--is then folded in as the way of describing BE50318 (interpreting the fact as ascribing the functional role of &amp;quot;target&amp;quot; to its second argument, the &amp;quot;battle element&amp;quot;), and the third fact--(PSsa ... electronics)--becomes a modifier in the description of the search radar.</Paragraph>
    <Paragraph position="6"> Alternatively, to specify &amp;quot;The target's search radar is active&amp;quot; (Figure 9), one would position the third fact as the head of the bundle and use the first two as the characterization of the search radar. As indicated on the two figures, these specifications are assembled from exactly the same three partial specifications, but combined in different orders with different attachment functions.</Paragraph>
    <Paragraph position="7"> Note that the pretty-printing of these specifications is a little simpler than the earlier ones so as to conserve space, and that it includes another field--&amp;quot;underlying-object&amp;quot;--to make the origins of the different parts of the specification clearer.</Paragraph>
    <Paragraph position="8"> One other point that may be unexpected is the fact that the Figures include two instances of the specification for the search radar, one as the second argument to have as we would expect, and a second embedded within the first as part of the &amp;quot;clause&amp;quot; specification for (ISA . . . electronics). Of course, if this second instance were missing--say as the result of some planning-level abbreviation in recognition that only the adjective within that specification was going to actually appear in the final text--then the Specifications in the two figures would not just be simple rearrangements of the same parts (a generalization we consider valuable); instead we have the selection of the adjective done as part of realization as one of the normal choices for simple predications, under control of the position where the specification is attached, i.e. as a modifier to an NP.</Paragraph>
  </Section>
class="xml-element"></Paper>