<?xml version="1.0" standalone="yes"?>
<Paper uid="J97-2001">
  <Title>Floating Constraints in Lexical Choice</Title>
  <Section position="3" start_page="199" end_page="214" type="metho">
    <SectionTitle>
4 In fact, most portable syntactic components mentioned earlier, such as SURGE, MUMBLE, and TAGs, expect as input a fully lexicalized specification, thus supporting this approach.
5 The only argument for option 3 is that it allows for an integrated account of the influence of surface structure on lexical choice within a single component. However, our experience (corroborated by
</SectionTitle>
    <Paragraph position="0"> Elhadad, McKeown, and Robin Floating Constraints in Lexical Choice As we will show, this architecture allows us to convey several aspects of the semantic content using the same word and at the same time, allows us to realize the same semantic concept at a variety of syntactic ranks depending on the situation. In particular, by selecting words before a syntactic tree has been constructed, the lexical syntactic features associated with alternate lexical choices can constrain the high-level structure of the final tree, which is a key feature to handling floating constraints.</Paragraph>
    <Section position="1" start_page="200" end_page="202" type="sub_section">
      <SectionTitle>
2.2 Input and Output
</SectionTitle>
      <Paragraph position="0"> Given this organization, input to the lexical choice module will be structures from the application domain representation selected during content planning, possibly augmented with discourse relations. Following our criteria for generation, the structure of the conceptual input will not be committed to any linguistic structure, in order to avoid encoding assumptions about realization into the domain application, and in order to free the content planner from reasoning about linguistic features when determining what information should be included. Thus, it should be possible for a conceptual structure to be realized by a clause, a nominalization, a noun-noun modifier, a predicative adjective, or a prepositional phrase. Similarly, the mapping need not be one-to-one. Several conceptual elements may be realized by the same linguistic constituent, and conversely, several linguistic constituents may be needed to realize a single conceptual element.</Paragraph>
      <Paragraph position="1"> For example, consider the conceptual input to ADVISOR-II's Lexical Chooser whose graph is outlined at the top tier of Figure 2. The domain from which concepts are selected is an expert system rule base, which uses gradual rules of inference (e.g., the more assignments in a class, the harder the class). The input is a set of three relations, each of which is represented similarly by a set of attribute-value pairs in the feature structure form shown in the central tier of Figure 2, except for cardinality, which reduces to an integer. This content representation does not indicate which relations should appear as the head element in the linguistic structure and which should appear as dependents. Nor does it indicate which syntactic relations should be used.</Paragraph>
      <Paragraph position="2"> As a result, many different paraphrases of this content can be generate d, as illustrated by the five given at the bottom tier of Figure 2. Note that while in (1) the relation assignt-type surfaces as the main element in the syntactic structure, in (2)-(5) it appears as a dependent element. Note also the syntactic variety of these dependent elements. This example illustrates that, in contrast to much previous work in generation (but see Meteer \[1990\]), we do not assume that relations will be realized as verbs and objects as their arguments. Instead, the Lexical Chooser must reason about how different domain entities can be realized. The ability to realize relations by compact constituents such as predicative adjectives or noun-noun modifiers allows for the fluency of the sentences of Figure 2. Realizing all relations in the Figure 2 input as clauses would result in rather cumbersome sentences such as: Programming is the kind of assignments of the class whose topic is AI and the number of these assignments is six.</Paragraph>
      <Paragraph position="3"> Note that in order to choose between these sentences, the Lexical Chooser needs information other than just content encoded in the domain representation. In general, the Lexical Chooser needs information about discourse and about speaker intent. For this particular example, it needs information about the speaker's focus and her perspective, at this point in the discourse. Such information must be part of the input to the Lexical Chooser and can typically be provided by a content planner (McKeown Reiter's \[Reiter 1994\]) shows that the influences of syntax on lexical choice can be accounted for before syntactic realization.</Paragraph>
      <Paragraph position="4">  An example of an input conceptual network with paraphrases that can be generated from it. 1985; Polgu~re 1990; McCoy and Cheng 1991; Carcagno and Iordanskaja 1993), which must keep track of how focus shifts as it plans the discourse, or text. Similarly, any goals of the speaker must be provided as input to the Lexical Chooser. In the student advising domain, argumentative intent, or the desire of the speaker to cause the hearer to evaluate the information provided in a particular light, plays an important role. For example, whether the six programming assignments should be viewed as a plus of AI or a minus will depend both on hearer 6 goals and on what action the speaker 7 thinks the hearer should pursue (i.e., take AI or not). Such goals, or argumentative intent, are used by the content planner in reasoning about what information to include. Again,  Elhadad, McKeown, and Robin Floating Constraints in Lexical Choice since such goals are available to the content planner, they can easily be provided as input to the Lexical Chooser.</Paragraph>
    </Section>
    <Section position="2" start_page="202" end_page="202" type="sub_section">
      <SectionTitle>
2.3 Two Tasks for Lexical Choice
</SectionTitle>
      <Paragraph position="0"> Given the input and output specified above, this leaves two tasks for the Lexical Chooser: * Syntagmatic decisions: choosing among the many possible mappings from the fiat conceptual network it receives as input onto the thematic tree structure it must produce as output, (e.g., the choice of expressing the assignt_type relation in the network of Figure 2 as the main verb and the cardinal relation as a noun modifier in paraphrase \[1\]).</Paragraph>
      <Paragraph position="1"> * Paradigmatic decisions: choosing among alternative lexicalizations inside a particular thematic structure, (e.g., the choice of the verb to require to express the assignt_type relation in paraphrase \[1\] instead of to involve in \[2\]).</Paragraph>
      <Paragraph position="2"> While syntagmafic decisions may seem to be more syntactic in nature, they are directly intertwined with various lexical choices. Selecting the verb, or a higher-level relation such as a connective between two clauses, automatically determines overall thematic structure, while selecting which concept in the input will serve as head of the sentence directly influences choice of words. Minimally, syntagmatic decisions indude determining the main process, which constrains the set of possible verbs, s For example, in paraphrase (4) of Figure 2, this means choosing: * To map the relation class_assignt as the main process of the sentence.</Paragraph>
      <Paragraph position="3"> * A possessive thematic structure for that main process.</Paragraph>
      <Paragraph position="4"> * To map the arguments class and assignt of class_assignt onto respectively the possessor and possessed roles of the possessive process.</Paragraph>
      <Paragraph position="5"> Further syntagmatic choices determine which concepts will function as modifiers of any of these roles, ultimately surfacing as relative clauses, prepositional phrases, or adjectival describers. This mapping of conceptual structure to linguistic structure is carried out first in the Lexical Chooser. We call this initial stage involving syntagmatic decisions phrase planning. Then, the Lexical Chooser selects the actual words that are used to realize each role. We call this subsequent stage involving paradigmatic decisions lexicalization proper.</Paragraph>
      <Paragraph position="6"> Floating constraints are handled in both of these stages: for example merging two content units in a single linguistic unit is a phrase planning decision, whereas picking the appropriate collocate of an already chosen word is a paradigmatic decision.</Paragraph>
    </Section>
    <Section position="3" start_page="202" end_page="205" type="sub_section">
      <SectionTitle>
2.4 An Implementation Based on the FUF/SURGE Package
</SectionTitle>
      <Paragraph position="0"> The implementation of ADVlSOR-II builds on a software environment dedicated to the development of language generation systems: the FUF/SURGE package (Elhadad 1993a, 8 Here we use the word &amp;quot;process&amp;quot; in the systemic sense, see Section 2.4.2.</Paragraph>
      <Paragraph position="1">  Computational Linguistics Volume 23, Number 2 1993c). FUF (Functional Unification Formalism) is a programming language based on functional unification (Kay 1979). 9 Both the input and the output of a FUF program are feature structures called Functional Descriptions (FDs). The program itself, called a Functional Unification Grammar (FUG), is also a feature structure, but one which contains disjunctions and control annotations. The output FD results from the unification of this FUG with the input FD. The disjunctions in the FUG make unification nondeterministic.</Paragraph>
      <Paragraph position="2"> Functional unification has traditionally been used to represent syntactic grammars for sentence generation (e.g., Appelt 1983; McKeown 1985; Paris 1987) and FUF comes as a package with SURGE, a grammar of English implemented in FUF. SURGE is usable as a portable front-end for syntactic processing. FUF is the formalism part of the package, a language in which to encode the various knowledge sources needed by a generator. SURGE is the data part of the package, an encoded knowledge source usable by any generator. Using the FUF/SURGE package, implementing a generation system thus consists of decomposing nonsyntactic processing into subprocesses and encoding in FUF the knowledge sources for each of these subprocesses. Each such knowledge source is represented as a FUG. 1deg In the case of ADVISOR-II, the focus of nonsyntactic processing is lexical choice. ADVISOR-II thUS essentially consists of a pipeline of two FUGs: a lexical FUG encoding the domain-specific lexical chooser and the domain-independent syntactic FUG SURGE. Lexical choice is performed by unifying the conceptual input with the lexical FUG or lexicon. The resulting lexicalized thematic tree is then unified with SURGE, which produces the final sentence.</Paragraph>
      <Paragraph position="3"> We now briefly overview the FUF language and then the SURGE syntactic grammar before explaining in detail how unification is used to perform lexical choice.</Paragraph>
      <Paragraph position="4"> 2.4.1 FUF: A Functional Unification Formalism. Functional unification is based on two principles: information is encoded in simple and regular structures called functional descriptions (FDs) and FDs can be manipulated through the operation of unification. 11 A Functional Unifier takes as input two FDs and produces a new FD if unification succeeds and failure otherwise. Note that contrary to structural unification (SU, as used in Prolog for example), functional unification (FU) is not based on order and length (see Shieber \[1992\] and Carpenter \[1992\] for recent and comprehensive descriptions of feature structures).</Paragraph>
      <Paragraph position="5"> An important property of FDs is their ability to describe structure sharing (or reentrancy): an FD can describe an identity equation between two attributes. For example, subject-verb agreement in a sentence is described by the FD:</Paragraph>
      <Paragraph position="7"> In this FD, the notation \[1\] indicates that the value of the attribute number under subject must be identical to that of the attribute number under verb, whatever it may be. In FUF, tags like \[1\] are encoded with the path notation such as {verb number}. A path is best understood as a pointer within the FD. Because paths can be used with no constraints, the graph encoding an FD can include loops and does not need to be a tree.</Paragraph>
      <Paragraph position="8">  9 FUF is currently implemented in Common Lisp.</Paragraph>
      <Paragraph position="9"> 10 To avoid overloading the word &amp;quot;grammar,&amp;quot; we will use &amp;quot;FUG&amp;quot; to refer to the common representation formalism and &amp;quot;syntactic grammar&amp;quot; to refer to syntactic data encoded in SURCE using this formalism. 11 FDs are often called feature structures or attribute value matrices in the literature.  Elhadad, McKeown, and Robin Floating Constraints in Lexical Choice The alt keyword expresses disjunction in FUF. The value of the alt keyword is a list of FDs, each one called a branch. When unifying an input FD with such a disjunction, the unifier nondeterministically selects one branch that is compatible with the input. Disjunctions encode the available choice points of a system and introduce backtracking in the unification process. In this paper, alts are represented using the following standard notation for disjunctions in feature structures:</Paragraph>
      <Paragraph position="11"> A disjunction can be embedded in another one if necessary. In addition, disjunctions can be named using the def-alt notation, and referred to in other places using the notation (:! name). This notation allows for a modular notation of large grammars written in FUF. Other FUF constructs are introduced as needed in the rest of the paper.</Paragraph>
      <Paragraph position="12">  wide-coverage syntactic grammar of English implemented in FUF and usable as a syntactic front-end portable across domains. It has been progressively developed over the last seven years and extensively tested for the generation of texts as varied as multimedia explanations (McKeown et al. 1990), stock market reports (Smadja and McKeown 1991), student advisory sessions (Elhadad 1993c), telephone planning engineer activity reports (Kukich et al. 1994; McKeown, Kukich, and Shaw 1994), taxation correspondence, visual scene descriptions (Abella 1994), didactic biology term deftnitions (Lester 1994), basketball game summaries (Robin 1994a), workflow diagram descriptions (Passoneau et al. 1996), news article summaries (McKeown and Radev 1995), intensive care patient summaries (Dalai et al. 1996), and web-page access demographics. null SURGE represents our own synthesis, within a single working system and computational framework, of the descriptive work of several (noncomputational) linguists. Our main source of inspiration were: Halliday (1985) and Winograd (1983) for the overall organization of the grammar and the core of the clause and nominal subgrammars, Fawcett (1987) and Lyons (1977) for the semantic aspects of the clause, Pollard and Sag (1994) for the treatment of long-distance dependencies and Quirk et al. (1985) for the many linguistic phenomena not mentioned in other works, yet encountered in many generation application domains. Since many of these sources belong to the systemic linguistic school, SURGE is mostly a functional unification implementation of systemic grammar rules. In particular, the type of FD it accepts as input specifies a &amp;quot;process&amp;quot; in the systemic sense, i.e., any type of situation involving a given set of participants (or thematic roles). This situation can be an event, a relation, or state in addition to a process in its most common, aspectually restricted sense. In this broader systemic sense, a process is thus a very general concept, simply denoting a semantic class of verbs sharing the same thematic roles. However, SURGE also includes aspects of lexical grammars, such as subcategorization.</Paragraph>
      <Paragraph position="13"> Furthermore, while SURGE is essentially systemic in terms of the type of thematic structure it expects as input, it differs from a purely systemic grammar implementation such as NIGEL (Mann and Matthiessen 1983) in terms of control. Because it is based on functional unification, SURGE is driven by both the structure of the grammar and that  Computational Linguistics Volume 23, Number 2 of the input, working in tandem. In contrast, NIGEL is driven solely by the structure of the grammar, as encoded in its system networks.</Paragraph>
      <Paragraph position="14"> 2.4.3 Lexical Choice by Functional Unification. We apply FUF to lexical choice by representing the lexicon as a FUG whose branches specify both constraints on lexical choice (as tests) and the lexical features selected as a result of the different tests. Lexical choice is performed automatically by unifying the lexicon, or lexical FUG, with the conceptual input. During unification, the tests probe both the input conceptual network and the linguistic tree under construction.</Paragraph>
      <Paragraph position="15"> FUF is particularly suited for the representation of lexical constraints for a variety of reasons, some of which have been discussed elsewhere (e.g., McKeown and Elhadad 1990; McKeown et al. 1990). First, FUF allows the representation of constraints on lexical choice in a declarative and compositional manner. This means that each constraint can be represented separately and the ordering on how the constraints apply is determined dynamically through unification. Because the constraints are represented separately, lexical features are added as each constraint apphes, thus compositionally constructing the set of features that define the final choice. Finally, because unification is the governing process, constraints are bidirectional.</Paragraph>
      <Paragraph position="16"> Given the wide variety of constraints on lexical choice (Robin 1990) and the unpredictable manner in which they interact, these features of FUF are particularly desirable. Since in different contexts, different constraints play more or less of a role, unification can determine dynamically which constraints are triggered and in what order. This is a benefit in several different scenarios. For example, sometimes a constraint is stated in the input while at other times it may be derived from the choice of another word in the sentence. If the constraint is available, it can influence the choice of that word; if not, then if the word is selected based on other constraints, it will trigger the constraint, which may in turn trigger selection of other words. With lexical constraints that hold between two or more words, it is not critical which word is chosen first.</Paragraph>
      <Paragraph position="17"> Examples of such patterns of interaction are given in the following sections.</Paragraph>
    </Section>
    <Section position="4" start_page="205" end_page="211" type="sub_section">
      <SectionTitle>
2.5 A Simple Example
</SectionTitle>
      <Paragraph position="0"> To see how lexicalization works for our simple example sentence AI has six assignments, we will only consider semantic constraints. The input specification received by the Lexical Chooser is shown in Figure 3. The conceptual representation in the input is encoded as an FD under the semr (SEMantic Representation) attribute. In this example, it is a simple encoding in FUF notation of a binary relation CLASS_ASSIGNT holding between two entities: the individual AI and the set ASSIGNT_SET1. The link between the arguments of the relation and its fillers is indicated by path values (of \[1\] and \[2\] respectively). In the matrix notation used here, we use a number in brackets (In\]) to both label a value and subsequently represent the path to that value. As the Lexical Chooser proceeds, it adds features to this feature structure, representing the syntactic elements of the clause that is to be produced. The output is shown in Figure 4. It consists of the input semr attribute enriched by a syntactic structure of category clause (cf. note 1) with lexical items specified for each linguistic constituent (cf. note 3 and the features next to notes 4 and 5 of the figure). This output FD is then fed to the SURGE syntactic realization component, to eventually produce the expected sentence.</Paragraph>
      <Paragraph position="1"> In the architecture we are describing, the Lexical Chooser must meet the requirements of the underlying application, which feeds it its input, on the one hand, and on the other hand it must produce an output acceptable by the syntactic realization component. The particular semantic features (name of the relations and of the argu- null Conceptual input to the Lexical Chooser in FD format.</Paragraph>
      <Paragraph position="2"> ments) are specific to the ADVISOR-II domain. The particular thematic roles found in the output are characteristic of SURCE. The mapping process is generic.</Paragraph>
      <Paragraph position="3"> The Lexical Chooser first traverses the input conceptual structure (which appears under semr) to decide what syntactic category will be chosen to realize it. In this case, the Lexical Chooser decides to map a semantic relation to a simple clause. This decision is done during phrase planning, a process we detail in Section 3. As the clause is being constructed, the feature (cat clause) is added (cf. Note 1 in Figure 4) and the syntactic structure of a clause is constructed. A clause skeleton is added to the top level of the FD (cf. notes 2, 4, and 5).</Paragraph>
      <Paragraph position="4"> Since the main verb has not yet been selected, the Lexical Chooser cannot proceed further and determine which participants (or verb arguments) will be inserted in the clause, and how they will map to the arguments of the input semantic relation. But the phrase planning component has already determined to use the main verb to realize the input relation. To represent this decision, the Lexical Chooser copies information from the top-level semantic representation in the semr feature under process (cf. note 2), thus indicating that the main verb maps to the semantic relation CLASS_ASSIGNT. This is a general feature of the technique: the Lexical Chooser incrementally builds a syntactic structure, and each time a new linguistic constituent is introduced, a subconstituent from the semr is copied under the semr of the syntactic subconstituent, representing the mapping between semantic and syntactic constituents. This process is the generation counterpart of a compositional semantic interpretation.</Paragraph>
      <Paragraph position="5"> The next task of the Lexical Chooser is to select a word or phrase to realize the relation CLASS_ASSIGNT. The verb is selected by recursively unifying the process description (including its newly assigned semr feature, cf. note 2) with a disjunction of the verbs stored in the lexicon. The relevant fragment of the lexicon is shown in Figure 5.</Paragraph>
      <Paragraph position="6"> The selected entry contains two types of features: syntagmatic (constraints on daughter nodes in the syntactic tree) and paradigmatic (choice of alternative lexical entries for the same node in the tree). 12 First the verb to have is selected (cf. note 3 12 A generation lexicon is indexed by concepts instead of words. Each of its entries groups the alternative words to express a given concept.</Paragraph>
      <Paragraph position="7">  Output from the Lexical Chooser.</Paragraph>
      <Paragraph position="8"> in Figure 4) as the default option for possessive verbs---English uses a possessive metaphor to refer to the link existing between a class and its assignments (a class &amp;quot;owns&amp;quot; the assignments). 13 As discussed below, this is a domain-specific decision that only applies to the particular relation CLASS_ASSIGNT.</Paragraph>
      <Paragraph position="9"> Once the verb class is known, the transitivity of the clause is determined, and the clause skeleton can be extended by specifying the verb's complements. In SURGE, possessive clauses expect two participants, named POSSESSOR and POSSESSED. The second part of the lexical entry therefore determines how the semr features of the two syntactic participants are to be linked to the semantic arguments of the input semantic relation (in our case, this is done by the FUF pointers next to notes 4 and 5 in Figure 4). This mapping is domain-specific, and is completely contained in the lexicon en13 Under different conditions, the Lexical Chooser could select one of the other verbs represented in the entry, such as to require or a construction such as in class, there is assignment.</Paragraph>
      <Paragraph position="10">  % lexicalizafion and its cat and identify sub-constituents \[class \[1\]\] semr assignments \[2\] oc ss \[s r \[nome c ss ssignt \]\] ALT ASSIGNMENrI~ : bk-class ao % Lexicalizations: C requires A, C has A % there is A in C, in C they do A % Branch 1: C requires A % Branch 2: C has A \[ type possessive \]  process lex &amp;quot;have&amp;quot; % lex_cset declaration to handle recursion lcx_cset (\[3\] \[4\] ) possessee \[4\]\[sem~ \[2\]\] % Branch 3: In C there is A process \[ type existential \] lex_cset ( \[5\] \[61 ) participants \[located \[5\] \[ semr \[2\]\]\] circumstances \[location \[6\] \[ semr \[1\] \] \] ... Other types of classmelafions ...</Paragraph>
      <Paragraph position="11"> Figure 5 Fragment of the lexicon for Verb selection.</Paragraph>
      <Paragraph position="12"> try for the domain relation CLASS_ASSIGNT. In contrast to previous lexical choice approaches, such as Bateman et al. (1990), we make no claims that the linguistic relation of possession used in this case is more general than the domain relation CLASS_ASSIGNT. That is, we do not attempt to fit each domain relation under a general ontology based on linguistic generalizations. Such fixed categorization of domain relations in effect prevents a generator from realizing the same domain relation at various linguistic  Computational Linguistics Volume 23, Number 2 ranks and thus drastically reduces its paraphrasing power. 14 The only information this mapping encodes is that one option to lexicalize the domain relation CLASS_ASSlGNT in English is a possessive clause.</Paragraph>
      <Paragraph position="13"> At this point, the top-level unification of the input with the Lexical Chooser is completed. The intermediate FD corresponds to the features next to notes 1, 2, 4, and 5 in Figure 4. The verb has been selected and the clause structure has been built. In order to continue the lexicalization of the arguments, the Lexical Chooser must specify which constituents in this FD require further processing. This is accomplished by adding a lex_cset (LEXical Constituent SET) declaration to the (lexical) FUG. The value of lex_cset is a list of pointers to the constituents of the FD as shown in Figure 5. Constituents bring structure to functional descriptions. 15 To handle constituents, the complete unification procedure implemented in FUF is:</Paragraph>
      <Paragraph position="15"> Unify top-level input with the lexicon (i.e., the single unification step described just above).</Paragraph>
      <Paragraph position="16"> Identify constituents in result (i.e., read the lex_cset attribute). Recursively unify each constituent with the lexicon.</Paragraph>
      <Paragraph position="17"> The lexical entry for an argument-bearing word (usually a verb) includes a lex_cset declaration. In the example, it specifies the two complements, POSSESSOR and POS-SESSED, each of which will eventually be realized as an NP. When this is the case, the head noun of the NP realizes the argument of the conceptual relation. When this argument is shared by other relations in the input conceptual network, those other relations are realized as nominal modifiers. Lexicalizing such complex NPs requires determining: * Which relations in the complex NP will appear as premodifiers and which as postmodifiers.</Paragraph>
      <Paragraph position="18"> * Which postmodifiers will be realized as prepositional phrases and which as relative clauses.</Paragraph>
      <Paragraph position="19"> * Selecting the features the grammar needs in order to select a determiner, if any.</Paragraph>
      <Paragraph position="20"> Details on how the linguistic features appearing under the NP constituents are selected are given in Elhadad (1993b, 1996).</Paragraph>
      <Paragraph position="21"> In summary, the Lexical Chooser proceeds as follows: .</Paragraph>
      <Paragraph position="22"> .</Paragraph>
      <Paragraph position="23"> A stage of phrase planning first processes the semantic input and determines to which syntactic category it is to be mapped.</Paragraph>
      <Paragraph position="24"> A skeletal FD for the selected category enriches the semantic input. 14 Note that it is not the very idea of using an ontological upper-model that we criticize here (with all its advantages in terms of knowledge inheritance and reuse) but the use of the most common linguistic realization of each concept as the main criteria for classification. 15 SURaE also uses the special feature cset to encode the surface syntactic constituents of the sentence, following Kay (1979). Thus, two cross-cutting constituent structures, thematic and syntactic, can be represented in the same FD. SURCE ignores the lex_cset features and recurses according to the cset declarations.</Paragraph>
      <Paragraph position="25">  The head word for the linguistic constituent is selected by looking up the semantic feature in (i.e., unifying the semr feature with) the lexicon. The lexical entry for the head word is responsible for: Providing a lexical item with its lexical features.</Paragraph>
      <Paragraph position="26"> Mapping semantic subconstituents to the complements of the head word.</Paragraph>
      <Paragraph position="27"> The lex_cset attribute triggers recursion on the immediate descendants of the linguistic head. The linguistic structure is therefore incrementally expanded as each head is lexicalized in turn. The FUF default control regime develops this structure in breadth-first order.</Paragraph>
      <Paragraph position="28"> 3. Phrase Planning in Lexical Choice When the input semantic network contains more than one relation, the Lexical Chooser must decide how to articulate the different predicates into a coherent linguistic structure. We refer to this stage of processing as &amp;quot;phrase planning&amp;quot; because of its close relationship to paragraph planning. In a simplistic generation system, all semantic relations would be mapped to clauses, while entity and set descriptions would be mapped to noun phrases. This strategy is not felicitous when dealing with multiple relations, as illustrated by the two examples whose inputs and corresponding alternative outputs are shown in Figure 6 and Figure 7, respectively. If every relation is to be realized as a clause, then the only option for lexicalizing the relations 1 and 2 in Example 1 of Figure 7 is to generate two separate sentences as in (1), or to embed one of the relations as a relative clause modifier of the shared argument as in (2) or (3). Our corpus analysis (Robin and McKeown 1993), however, has shown that sentences in the basketball report domain tend to be more syntactically complex than sentences (1) to (3). Sentences (4) and (5) illustrate the type of complexity we found: the two semantic relations are merged into a single sentence, but the second relation is realized as a prepositional adjunct of different types. Example 2, in the ADVI$OR-II domain, shows other options for realizing attached relations: as noun-noun modifiers (AI assignments) or premodifier (programming assignments). To account for this observed syntactic complexity, the Lexical Chooser must be able to accept as input networks of several semantic relations, sharing certain arguments. The semantic networks corresponding to Examples 1, 2, and 3 are shown graphically in Figure 6.  Computational Linguistics Volume 23, Number 2 Example 1 (left network of Figure 6): (1) Two sentences: The Jazz defeated the Bulls.</Paragraph>
      <Paragraph position="29"> They extended their winning streak to three games.</Paragraph>
      <Paragraph position="30"> (2) One sentence - beat as head - No lexical optimization: The Jazz who extended thei r winning streak to three games, defeated the Bulls.  (3) One sentence - streak as head - No lexical optimization: The Jazz who defeated the Bulls, extended their winning streak to three games. (4) One sentence - beat as head - With lexical optimization: The Jazz defeated the Bulls for their third straight win.</Paragraph>
      <Paragraph position="31"> (5) One sentence - streak as head - With lexical optimization: The Jazz extended their winning streak to three games with a victory over the Bulls. Example 2 (right network of Figure 6, perspective alternation with fixed focus): (6) AI has six programming assignments. (perspective class_assignt, focus aI) (7) The six AI assignments require programming. (perspective assignt_type, focus AI) Example 3 (right network of Figure 6, focus alternation with fixed perspective): (8) AI requires six programming assignments. (perspective class_assignt, focus AI) (9) Six programming assignments are required in AI. (perspective class_assignt, focus assignt_set 1)  Alternative outputs for the input of Figure 6.</Paragraph>
    </Section>
    <Section position="5" start_page="211" end_page="212" type="sub_section">
      <SectionTitle>
3.1 Selecting the Head Relation and Building its Argument Structure
</SectionTitle>
      <Paragraph position="0"> The Lexical Chooser must first decide which relation to map to the main clause, and which one to embed as a modifier. 16 We refer to this decision as perspective selection. The notion of perspective is related to the notion of focus as used, for example, in McKeown (1985). However, the perspective is a relation in the conceptual network whereas the focus is an entity. Once the perspective is chosen, focus can shift between the participants of a relation, by switching the order of the complements, as in sentences (8) and (9) of Figure 7. This is in contrast to sentences (6) and (7) in the same figure, where perspective switches from class_assignt to assignt_type (with the focus being the same). We have not investigated further which pragmatic factors affect the selection of perspective. Our research has focused on building into the Lexical Chooser the ability to realize any choice of perspective on the structures produced by the content planner. We thus assume that perspective is given in the input to the Lexical Chooser. Figure 2 shows in FD form the input the Lexical Chooser receives for the example that produces sentences (6) to (9) (the network form for this input is shown on the right in Figure 6), depending on the values of the additional input features perspective and focus omitted in Figure 6.</Paragraph>
      <Paragraph position="1"> The ADVISOR-II system expects in its input up to four semantic relations, the highest number of relations that we observed expressed by a single sentence in our 16 Note that while an object cannot in general serve as a verb, a relation can serve as clause, noun, and a variety of different modifiers. Thus, while we are restricted to selecting a relation as a main clause, we are not restricted in how we do the mapping of other input relations to syntactic constituents.  Elhadad, McKeown, and Robin Floating Constraints in Lexical Choice model corpus of advising dialogues. The clause planning process has two components: one, domain specific, maps from the domain relations to a clause structure, and one, generic, maps the clause structure to the appropriate types of syntactic modifiers (relative clause, prepositional adjunct, adjectival premodifier, or noun-noun modifier).</Paragraph>
      <Paragraph position="2"> To explain this process, we will go through the clause planning of the example input shown in Figure 2 step-by-step. Assume that the content planner has decided the focus is on aI, and the perspective is on the class-assignt relation. First, the head constituent of the linguistic structure is built from the description of the class-assignt relation.</Paragraph>
      <Paragraph position="3"> This mapping is shown in the top half of Figure 8. The left-hand side shows the conceptual structure that is the input to the Lexical Chooser. The right-hand side shows the linguistic structure that is constructed. At this stage, the conceptual relation that will be realized as the head has been selected (shown by the dotted line pointing to the node class-assignt) and the Lexical Chooser has decided to use a process (i.e., ultimately a verb) to realize it. In addition, the roles feature is added as a generic argument structure for the clause. The roles point to the appropriate arguments of the class-assignt (again, note the dotted lines to the nodes AI and AI-assignt). Note, however, that during this stage of phrase planning, neither the syntactic category nor the lexical head of the constituent are yet chosen. The input conceptual graph is merely transformed into a semantic tree. It is only during the subsequent stage of lexicalization (proper), when the specific verb (to have in this example), is selected. 17 In the implementation, generic roles (role1, role2) are used to point to the arguments of a process as long as the specific verb is not selected. They are mapped to clausal participants (e.g., CARRIER, ATTRIBUTE) only once the verb is chosen.</Paragraph>
    </Section>
    <Section position="6" start_page="212" end_page="214" type="sub_section">
      <SectionTitle>
3.2 Attaching the Remaining Relations as Modifiers
</SectionTitle>
      <Paragraph position="0"> The second step of the mapping is to map the second relation, assignt_type, onto modifiers of the arguments of the head clause. The assignt_type is mapped onto the modifier slot of the attribute role of the head clause, when it is found that the assignt_type and class_assignt share an argument.</Paragraph>
      <Paragraph position="1"> This mapping is illustrated in the bottom half of Figure 8 for the example sentence: (5) AI has programming assignments.</Paragraph>
      <Paragraph position="2"> The modifier description has the same format as a clause in the linguistic structure. The process of the clause is mapped to the relation assignt-type and the process roles to the arguments of assignt-type. This does not mean that the modifier will  necessarily be realized by a clause as in the following sentence: (6) AI has assignments which involve programming.</Paragraph>
      <Paragraph position="3">  It can also be realized by an adjective or a noun. But these modifiers are analyzed as being derived from the relative clause construction using only linguistic derivations, following Levi (1978). Thus, sentence (5) above is analyzed as being derived from (6) by deletion of the predicate involve and migration of its object, programming, to a premodifier of the head assignments.</Paragraph>
      <Paragraph position="4"> Another option to attach a second relation is to add it as a separate clause to avoid deeply embedded structures. For example, the clause combination, sentence (7) below,  is preferred over the embedded combination, sentence (8) below, because in the latter the relative clause is twice embedded: (7) Intro to AI has many assignments which consist of writing essays. You do not have experience in writing essays.</Paragraph>
      <Paragraph position="5"> (8) Intro to AI has many assignments which consist of writing essays in which you do not have experience.</Paragraph>
      <Paragraph position="6"> In summary, the first step of the mapping from conceptual network to clause is (1) to select a perspective among the conceptual relations of the network, which deter- null mines a head clause, and (2) to attach the remaining relations as either embedded or subordinate modifiers of the head clause. The perspective is selected using focus constraints; the choice between embedding or subordination is based on simple stylistic criteria. The output of this stage is a hierarchical structure where heads correspond to linguistic constituents of a given category (clause or NP), but where the lexical heads are not yet selected.</Paragraph>
      <Paragraph position="7"> These two operations constitute clause planning, similar to text planning at the paragraph level. A similar process for NP planning is described in Elhadad (1996). Once the head clause structure has been built, it is passed to the rest of the Lexical Chooser, which determines which syntactic forms can be selected for each modifier, when appropriate lexical resources are found.</Paragraph>
      <Paragraph position="8"> These operations of phrase planning are possible in this approach because the conceptual input is not already linguistically structured. Such planning is a major source of paraphrasing power, and since it is controlled by pragmatic factors (as explained in Section 4) it also increases the sensitivity of the generator to the situation of enunciation.</Paragraph>
    </Section>
  </Section>
class="xml-element"></Paper>