<?xml version="1.0" standalone="yes"?>
<Paper uid="A92-1036">
  <Title>Portable Natural Language Generation using SPOKESMAN</Title>
  <Section position="4" start_page="0" end_page="237" type="metho">
    <SectionTitle>
:::::::::::::::::::::::::::::::::::::::::::::::::: LANOUAOE :::::::::::::::::::::::::::::::::::::::::::::::::::::::
1988 Architecture: Interfacing to Mumble-86
</SectionTitle>
    <Paragraph position="0"> While this modularization isolated the linguistic component, using it directly required ~e developer to be aware of very low level linguistic details. For example, the specification of a noun phrase requires that information about number, person, and determiner be included.</Paragraph>
    <Paragraph position="1"> Furthermore, there was no way to ensure that a particular specification built by a text planner would actually be expressible by the linguistic component. For example, there was no~hing to prevent a planner from composing a specification combining a completive event with a duration (e.g. *&amp;quot;the plane landed for ten minutes&amp;quot;). Also, the specification language itself cannot capture certain generalizations about what features can co-occur in language and what is expressed by certain combinations of features, leaving them to the text planner. For example, a single noun phrase with a definite article indicates that the entity is known (e.g. &amp;quot;the dog&amp;quot;); however if a proper name is used, the article is omitted even when the entity is known (e.g.</Paragraph>
    <Paragraph position="2"> &amp;quot;Fluffy&amp;quot;).</Paragraph>
    <Paragraph position="3"> While this architecture was a successful means of working directly with MUMBLE-86, it left a great deal of work to be done by the planner, most of which must be built specifically for each application. Our approach in developing a text planner for the current system was to introduce modularity into the text planner, separating what is general to language from that which is specific to an application. The resulting system is called SPOKESMAN, and its architecture is shown below. The general knowledge used by the .ext planner resides in the TEXT PLANNER CORE; the domain specific portions of the text planner are again indicated by diagonal lines.</Paragraph>
    <Paragraph position="4"> Note that three of the applications shown all use the same knowledge representation language, the Simple Frame Language (SFL, Abrett, et al. 1989). Following our overall approach of modularizing those portions of the system that are shared, we built a subsystem for interfacing with the representation language that contains all the routines for accessing objects in SFL and for handling what is common to all SFL-based applications, such as the concept THING.</Paragraph>
    <Paragraph position="5">  ; ~:: ::i i; i i i i i :i; i :i i; :i ::i ::)ii ii ii ::iii ii ii il :i iii ilii~ i i::iiiiiiiiiiiii::iiiiiiiiiiiiiiiiii:iiiiil i!ili! ::iii::i:: i:: !::}ii~ i?:rE XY PL~ R C 6 i~E i ;)ii ii ii il ii ii )iil )i ii i! i! ii ii ii ii ii i! ili;i;ii i i i:: i:: i:: ):: i:: i i i:: i::iiiiiii i i ::i ::i ::i i i ::i i i ~iii i iii i l i)ii ::i ::i ::i ::i ii ~iiiiiii::i ::i:: :: ::; .:..:.:.:.:,:.:,:.:.:.:.:.: :,:-:.:,:.:-:,:,:.:.:-:.:.:,:.:.:-:-:-:-:-:-:-:-:-:.: :.:..:.:.:.:.:::.:::::.::: :.:.::: :::::::.::::: ....................... . :. : : : ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :a:a:;:a::::::::::::.~::::::::::.~::::::::::~:::~:::~:~:~:::~:::~:~:::~:~:::~::::::~:~:~:::~:~:~:~::::::::.~:::::: SPECIFICATION LANGUAGE *:.&amp;quot; .............. :.`-.:`'.:`.~:~:.:.:~:~..~:~:.`.~:~:.:.:.:~:.:.:~`~:~:.:'.~:``~`:.:.:.:~:.:~:~:~:.:.:.:.:.: 1992 Architecture: The Spokesman is essentially an object-oriented program in  that the routines for mapping from one level to the other are specialized for the type of object being mapped, just as generic methods in CLOS or Flavors are specialized for different classes or flavors in those object oriented programming languages. Each mapping function is a table which, when given an object, will walk up the KB hierarchy until it finds a routine associated with that object's type or a type it inherits from. If that routine is a template, it will execute the template; if it is a class of alternatives, it will select one and execute that. This process is shown schematically below. There are different tables for the mappings between each level of representation in Spokesman, and, in some cases, different tables depending on the context defined by representational level.</Paragraph>
    <Paragraph position="6"> Mapping-. (foC/ type) funa/on  As we discussed earlier, one of our goals has been to isolate what is common to a language (though not necessarily all languages) from what is particular to the application the generator is speaking for. In particular, we wanted to both capture the generalizations available from the cooccurance of features in the linguistic specification and ensure that the specifications that are built are expressible in language.</Paragraph>
    <Paragraph position="7"> Within the text planner core, these generalizations are captured in the level of representation called the Text Structure (TS), which is used to compose the text. TS is a tree representing the constituency of the utterance, where constituents may be entire paragraphs related by rhetorical relations, or they may be lexically headed constituents internal to a clause. The terms of the TS are abstractions over the concrete resources of language (words, phrases, morphological markers). This vocabulary and the structure built with it provides the text planner with a representation of what decisions have already been made, thus constraining further decisions, and of what opportunities are available for further composition.</Paragraph>
    <Paragraph position="8"> 3. Capturing differences between domain In what we have presented so far, the focus has been on taking advantages of similarities within language and among applications to isolate domain independent components from those that need to be specific to the application program.</Paragraph>
    <Section position="1" start_page="237" end_page="237" type="sub_section">
      <SectionTitle>
Spokesman Generation System
</SectionTitle>
      <Paragraph position="0"> However, there are some things that are intrinsically domain specific, both in what information is expressed and in how it is expressed. A generation system that is to produce realistic texts in a domain must allow the developer to specialize routines at all levels of the generation process.</Paragraph>
      <Paragraph position="1"> One example of a domain specific expression is the way pilots are addressed in the Air Traffic Control domain.</Paragraph>
      <Paragraph position="2"> Rather than using the pilot's name, the controller addresses the pilot using the flight ID of the plane the pilot is flying--in effect he addresses the plane; similarly, pilots address controllers using their function (e.g approach, tower). In SPOKESMAN, this is handled using the mappings. Rather than using the mapping for PERSON, which pilot inherits from, a mapping specific to the concept PILOT is set up, which puts the aircraft instance rather than the pilot instance in the resultant Text Structure node. In the next phase of the generation process, which maps from the text structure to the linguistic specification, the mapping from the aircraft to the lexical resource is used, which combines the airline and the plane's ID number into a phrase, such as &amp;quot;United four fifty one&amp;quot;.</Paragraph>
    </Section>
  </Section>
class="xml-element"></Paper>