File Information
File: 05-lr/acl_arc_1_sum/cleansed_text/xml_by_section/metho/96/w96-0401_metho.xml
Size: 24,214 bytes
Last Modified: 2025-10-06 14:14:25
<?xml version="1.0" standalone="yes"?> <Paper uid="W96-0401"> <Title>The HealthDoc Sentence Planner</Title> <Section position="5" start_page="0" end_page="0" type="metho"> <SectionTitle> 2 The Sentence Planner </SectionTitle> <Paragraph position="0"/> <Section position="1" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 2.1 Constraints and Desiderata </SectionTitle> <Paragraph position="0"> Given the nature of the task (namely, the transformation and/or augmentation of partial sentence specifications into full ones), a set of constraints emerge for the design of the Sentence Planner. We believe these constraints to be fairly general; that is, that sentence planners developed for applications other than HealthDoc will have much the same structure. These constraints are the following: 1. The sP must transform an underspecified input of deep semantics into a suitably specified output of shallow semantics.</Paragraph> <Paragraph position="1"> 2. The sP must modularize sentence planning tasks as far as possible, to facilitate design clarity, development, and maintenance. Since the sentence planning tasks listed above are not single-step operations, since they do not have to be performed in strict sequence \[De Smedt, 1990; Reithinger, 1992\], and since the planner's operation is non-deterministic (early choices may undergo subsequent revision), this suggests that each sentence planning task should be implemented by a separate module or by several modules.</Paragraph> <Paragraph position="2"> 3. The intermediate steps of the sP should be accessible and easily interpretable to people building the sP, to enable cross-module interconnection and debugging.</Paragraph> <Paragraph position="3"> 4. The sP must be extensible, allowing new modules to be introduced as a need for them is identified.</Paragraph> <Paragraph position="4"> 5. The level of sophistication of the knowledge within a module must not be ccnstrained by the sP architecture, so that the modules might be crude initially but then can incrementally be refined without impeding throughput. To facilitate this, the rules and knowledge resources employed by the sP modules should be represented as declaratively as possible.</Paragraph> <Paragraph position="5"> Constraints I and 3 suggest that the intermediate form(s) of the data during sP operation be some sort of SPL-in-emergence; that is, a frame continually evolving from the more abstract input to the final SPL output(s). One way to achieve this is to see sP modules as treetransformation engines (viewing SPL and pre-SPL expressions as trees2). This means that their effects must be written as tree-rewriting rules in the following general form (see Section 2.3): \[pre~sPil ~ pre-sPi2\] Naturally, each module must know which tree transformation rule to apply to any given pre-sPI, under any given conditions. A suitable mechanism is provided by system networks, used just as in KPML'S grammar \[Matthiessen and Bateman, 1991\]. Each module contains a feature (system) network that discriminates arbitrarily finely to a desired state. At any point in the network, the selection of a feature with an associated tree-rewriting rule causes application of that rule to the current pre-sP5. Thus tree-rewriting rules are realization statements in the sP modules (several other realization operators are also supported).</Paragraph> <Paragraph position="6"> Constraints 2, 4, and 5 suggest that the sP * employ a blackboard architecture. As has already been argued by \[Nirenburg et hi., 1989\], a blackboard is best suited to accommodate the flexible order in which modules can take action. It also supports the addition of new modules without requiring the revision of the interfaces of existing modules.</Paragraph> </Section> <Section position="2" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 2.2 Sentence Planner Architecture </SectionTitle> <Paragraph position="0"> The architecture of the HealthDoc sentence planner is shown in Figure I. Solid arrows indicate data flow; dashed arrows indicate control flow. The components are:</Paragraph> <Paragraph position="2"> Planner in HealthDoc.</Paragraph> <Paragraph position="3"> Endophoric Lexical Choice. 3 2. Knowledge sources: the lexicon (essentially KPML's lexicon extended by collocational \[Wanner and Bateman, 1990\] and qualia \[Pustejovsky, 1995\] information), the semantic and lexicogrammatical resources as discussed in \[Wanner, 1994\], the Penman Upper Model \[Bateman, 1990\], the HealthDoc Domain Model, and the Reader Model of the patient.</Paragraph> <Paragraph position="4"> Not shown in Figure I is the history of choices made in the course of processing.</Paragraph> <Paragraph position="5"> 3. The blackboards: the main blackboard, which contains the latest pre-SPL expression(s) and their derivation history, and the control blackboard, which contains bookkeeping information such as the flags that signal the status (running/idle/etc.) of each module.</Paragraph> <Paragraph position="6"> 4. The Administrator: the top-level process that invokes modules, updates pre-sPL expressions, manages parallel alternative expressions, etc.</Paragraph> <Paragraph position="7"> 5. The Tree Transformer: the engine that matches the left-hand sides of tree transforaWe also foresee an Ordering module.</Paragraph> <Paragraph position="8"> mation rules to pre-SPL expressions and, when they match, unifies all variables and replaces the matched tree fragments with the right-hand sides of the rules.</Paragraph> </Section> </Section> <Section position="6" start_page="0" end_page="4" type="metho"> <SectionTitle> 6. The Network Traverser: a process that tra- </SectionTitle> <Paragraph position="0"> verses the system network of each module, handles the choice criteria functions (typically, these criteria pertain either to the input pre-SPL or to one of the knowledge resources), and upon reaching tree transformation rules, hands them off to the Tree Transformer.</Paragraph> <Section position="1" start_page="0" end_page="4" type="sub_section"> <SectionTitle> 2.3 The Planning Process </SectionTitle> <Paragraph position="0"> The sentence planning process transforms an input TSL expression(s) into one or more SPL expressions. null Input and output notation. TSL is currently under development. When fully developed, its degree of detail will be variable from one-to-one equivalent with SPL, to an abstract form that contains only the deep semantic frame for a predication (thereby being a notation in which, for example, commit suicide has suicide as head, rather than commit). The flexible degree of detail of the TSL will allow either more semantic or more surface-oriented sentence planning.</Paragraph> <Paragraph position="1"> For illustration, compare the following two TSLS of varying degrees of abstraction for sentences (1) to (3) above: A more abstract TSL expression:</Paragraph> <Paragraph position="3"> Note that coreference information is here encoded by using the same variables.</Paragraph> <Paragraph position="4"> A more specific TSL expression: In the more specific TSL expression, the deep semantic roles have been replaced by surface semantic roles (:actor, :actee), and syntactic information (tense) and textual information (theme) have been added. To see the difference between the TSL and SPL, consider the $PL expression for the first sentence in (0)-(3): Overall planning process. The planning process starts with the Administrator, which places a pre-sPL fragment onto the blackboard and activates a module.</Paragraph> <Paragraph position="5"> Linguistically, it is not possible to prespecify a fixed sequence in which the modules should apply \[De Smedt, 1990; Nirenburg et al., 1989\]. In some cases, mutual dependencies exist between different linguistic phenomena (i.e., also planning tasks) that cause race conditions or deadlock. We briefly discuss conflict resolution strategies in Section 4. In general, though, we define a (partial) default sequence for the modules: the Discourse Structuring and Sentence Structuring modules run first, and in parallel. 4 They are followed by the Content Delimitation module, and finally by the Exophoric and Endophoric Choice modules, also in parallel. This is in accordance with the increasing delicacy of phenomena the modules deal with. However, we will also experiment with other sequences. A user-specifiable Agenda that determines the ordering of module application has been implemented. null Upon activation, a module removes a pre-SPL from the blackboard, refines and enriches it, and replaces it on the blackboard. The outputs of parallel modules are unified and the unified pre-SPL expression becomes the working copy.</Paragraph> <Paragraph position="6"> The output of non-parallel modules become the working copy immediately. After all modules have run, the constructed sPL on the blackboard is passed to KPML for realization.</Paragraph> <Paragraph position="7"> In our current implementation, all modules except Discourse Structuring are defined uniformly using system networks. 5 This allows us to adopt an already developed and well-known representation, and the machinery that processes the information encoded in terms of this representation. For example, in \[Panaget, 1994; Wanner, 1994\], this machinery has been applied to construct an SPL expression from a 'text plan'. Unlike this work, which builds up SPL expressions anew using the text plan as a source of information to guide processing, our sP transforms the text plan itself into the SPL. We believe that such a transformation is more transparent to the sP builders, enabling them to inspect and manipulate directly the pre-sPL ex4 &quot;In parallel&quot; here means in arbitrary order. SHowever, each module is an independent black box. This enables separate and parM.lel developraent of each module using any formalism.</Paragraph> <Paragraph position="8"> pressions formed during the planning process.</Paragraph> <Paragraph position="9"> The types of planning operations required remain the same in both cases.</Paragraph> <Paragraph position="10"> To implement transformation rules in the framework of system networks, we define three new realization operators: REWRITE, ADD, and SUPPLANT. Each operator has a different effect on the fragment(s) of pre-SPL that match its left hand side: RBWRIT~ alters its content or structure, ADD adds new information but alters nothing, and SUPPLANT replaces the matched portion with something else (see \[Jakeway et al., 1996\]). The transformation rules invoke the Tree Transformer when the features they are associated with are chosen. The Tree Transformer then applies the rules to the current pre-SPL expression. null Four general types of transformation are generally required during sentence planning (symbols preceded by ? are wildcards and match any variable or symbol in the pre-SPL): 1. Augment a pre-SPL expression: (ADD ((?X / CAUSS) -+ (:dmarker causation))) in which any fragment of the current pre-SPL containing as head the deep semantic type CAUSE is augmented by the addition of the role :dmarker with the filler causation (i.e., a cue word signaling causation in the surface form).</Paragraph> <Paragraph position="11"> 2. Modify a pre-sPL expression: (R~WRITB ((?X / RST-RELATm~) ~ (7~ / RST-CAUSE))) in which the head of a pre-SPL fragment is changed from RST-RELATION to RST-CAUSE.</Paragraph> <Paragraph position="12"> 3. Remove a portion of a pre-SPL expression:</Paragraph> <Paragraph position="14"> in which the intermediate roles :role1 and :function are removed as soon as the process type (and, therefore, also the name of the agent role) are determined, and replaced by appropriate information. null 4. Move a portion of a pre-SPL expression:</Paragraph> <Paragraph position="16"> in which the intermediate role :situation is removed Pnd its filler moved to occupy the head of the fragment rooted at '?x'. (This occurs when it has been decided that the predicate 'y' e.g., MOVE--is to be expressed as the verb \[to\] move, rather than as the support verb construction make a move; now MOVE must be promoted to be the head of ?x in the emerging SPL). Note that 'remove a fragment' always implies 'move a fragment'.</Paragraph> </Section> <Section position="2" start_page="4" end_page="4" type="sub_section"> <SectionTitle> 2.4 Inter-Module Conflict Resolution </SectionTitle> <Paragraph position="0"> If a module is activated but is not able to make all the decisions it needs to, or if it makes decisions that are known to be possibly incompatible with those made by other modules later on, there are in general three options for how to proceed: 1. The module must suspend operation until all information required is available.</Paragraph> <Paragraph position="1"> 2. The module must make decisions somewhat blindly and allow backtracking when a decision turns out later to be incompatible.</Paragraph> <Paragraph position="2"> 3. The module must not make the decision but produce all alternatives in parallel, to be winnowed out by later processing.</Paragraph> <Paragraph position="3"> We do not discuss the first two options since they are standard AI search techniques. The third option is inspired by the treatment of alternatives in statistics-based NLP and the way alternative options are handled in MTM \[Mel'~uk, 1981\]. In this option, we allow a module to replace an input with multiple alternative outputs instead of only one when it cannot make a choice. All such alternative pre-SPLs are spawned and propagated onto the blackboard, so that other modules can work on them all, as parallel alternatives. Should one of the alternatives later turn out to be incompatible with some module's decision, that alternative simply 'dies' and is removed from the blackboard. If, on the other hand, all alternatives remain viable to the end, then the sP has produced more than one valid locution from the input. This option is only feasible if the networks of the modules are not very detailed, i.e., do not lead to an excessive number of alternatives. Although we will experiment with all three modes, our primary intention is to employ mode 1; currently, for implementational reasons, we use mode 2 in its simplest instantiation: when the changes made by a module turn out to be incompatible with those of other modules, the module starts again.</Paragraph> </Section> </Section> <Section position="7" start_page="4" end_page="4" type="metho"> <SectionTitle> 3 The Modules </SectionTitle> <Paragraph position="0"> This section describes the functionality of each module. As an example, we show the creation of the SPL expressions for the sentences (1) to (3). Lack of space prevents us from discussing the criteria and heuristics that are responsible for the individual choices.</Paragraph> <Section position="1" start_page="4" end_page="4" type="sub_section"> <SectionTitle> 3.1 Discourse Structuring Module </SectionTitle> <Paragraph position="0"> The Discourse Structuring module decides upon the way a discourse relation is communicated.</Paragraph> <Paragraph position="1"> So far, three major distinctions are made: 1. Marker/no-marker: For example, the CONDITION relation can be marked by if, in case, etc.</Paragraph> <Paragraph position="2"> 2. Explicit/implicit: CONDITION can be com null municated explicitly by discourse means and/or lexical means (such as the verb necessitate), or implicitly, obtainable via inference. 3. Nucleus/satellite salience: In the case of CONDITION, salience can be shifted by change of the order of the condition and effect arguments. The pre-SPL expression created by the Discourse Structuring module reflects the choices made regarding sentences 1 to 3 above in the type and number of roles to introduce, the role filler information, etc. The following fragment shows the result of the discourse structuring module for the sample sentences:</Paragraph> <Paragraph position="4"> The fragment D1 is not changed. For fragment C1, the use of a discourse marker has been determined. Also, due to the salience of the condition part of the utterance, the ':range' role will be expressed first.</Paragraph> </Section> <Section position="2" start_page="4" end_page="4" type="sub_section"> <SectionTitle> 3.2 Sentence Structuring Module </SectionTitle> <Paragraph position="0"> The Sentence Structuring module determines the structure of the sentences to be encoded in the SPL. This includes: 1. Sentence boundaries: If two separate sen- null tences are to be produced, the SPL is split into one per sentence and built up sequentially. 2. Global sentence structure: A sentence can be a hypotactic clause complex, a paratactic clause complex, or a simple clause. To determine this, the Sentence Structuring module evaluates whether the predications in the pre-SPL are to be communicated as a sequence or as a composite, complex event. A sequence of events can further be emphasized by a marker. In our example, the SPL under construction undergoes the following changes: It has been determined that the first sPL will contain a paratactic clause complex and that there will be a disjunction marker between the L and F fragments. Since a CONDITION that is represented by the roles :domain and :range is expressed in KPML as a hypotactic clause complex, fragment C1 remains unchanged (note that the aggregation module still has not run to make the changes for (3)).</Paragraph> </Section> <Section position="3" start_page="4" end_page="4" type="sub_section"> <SectionTitle> 3.3 Content Delimitation Module </SectionTitle> <Paragraph position="0"> The Content Delimitation module determines the material to be included into each separate SPL expression. At the present stage, this includes the following: 1. Constituents of a predication: Con null stituents that are to be encoded in the pre-SPL. Depending on the contextual and linguistic constraints, roles that are listed in the input might be suppressed and additional ones might be introduced. null</Paragraph> </Section> </Section> <Section position="8" start_page="4" end_page="4" type="metho"> <SectionTitle> 2. Causal~ temporal~ aspectual nuances: </SectionTitle> <Paragraph position="0"> Nuances of the predication that are to be encoded in the pre-sPL.</Paragraph> <Paragraph position="1"> The Content Delimitation module primarily introduces realization statements into the pre-sPL expression that constrain the exophoric choice module.</Paragraph> <Paragraph position="2"> In our example, which starts from a relatively specific TSL, the content delimitation module does not make visible changes: all roles present in the pre-SPL are determined to be realized. Starting from the abstract TSL, intermediate roles :situation would have been introduced in the fragments labeled by the variables W, L, F, and R. This syntactically neutral role :situation enables the Exophoric Choice module to generate different internal clause structures.</Paragraph> <Section position="1" start_page="4" end_page="4" type="sub_section"> <SectionTitle> 3.4 Aggregation Module </SectionTitle> <Paragraph position="0"> The Aggregation module eliminates redundancy in the pre-sPL by grouping entities that are arguments of the same relation, process, etc., together. The actions of the Aggregation module affect, as a rule, the resulting syntactic structure. In our example, redundancy is apparent in pre-SPL fragments W, L, and F, since their only internal difference is their type, as well as the repetition of the whole D1 in fragment CI.</Paragraph> <Paragraph position="1"> The actions of the Aggregation module result in the following changes within pre-SPL C1 for</Paragraph> </Section> <Section position="2" start_page="4" end_page="4" type="sub_section"> <SectionTitle> 3.5 Exophoric Lexical Choice Module </SectionTitle> <Paragraph position="0"> The Exophoric Lexical Choice module chooses lexical units for those entities specified in the pre-SPL that are new in the discourse. More precisely, it makes the pre-SPL more concrete along three lines: 1. Lexicalization of discourse structure relations: Discourse relations (and their cue words) may be realizable by lexical means. In our example, the CONDITION marker in (1), (2) is lexicalized as if; the DISJUNCTION marker as or, and the CONJUNCTION marker as and.</Paragraph> <Paragraph position="1"> 2. Internal clause structuring: The internal clause structure is predetermined by, among other means, the valency schema of the lexical unit that is chosen to serve as a head of a clause or phrase. With the choice of a head lexical unit, the salience of the arguments is also pre-determined (see, e.g., \[Wanner and Bateman, 1990\]). One of the choices the exophoric lexical choice module makes while generating (2), is the replacement of the fragment D1 in the CONDITION part by If replacement is needed.</Paragraph> <Paragraph position="2"> This choice can be made because the KB contains the process of replacement as a possible consequence of an implant being worn out, loosened, or having failed. It is not motivated by the presence of the coreference link in the TSL. The pre-SPL reflects this choice as follows: 3. Lexicallzation of the entities: this is traditionally considered to be the task of the lexical choice process. We do not discuss this issue here.</Paragraph> </Section> <Section position="3" start_page="4" end_page="4" type="sub_section"> <SectionTitle> 3.6 Endophoric Lexical Choice Module </SectionTitle> <Paragraph position="0"> The Endophoric Lexical choice module chooses lexical units for entities that have already been introduced in the discourse either verbatim or by related entities. If an entity has been introduced verbatim, its next mention can be realized as a personal pronoun, generalized name, definite name, deictic pronoun, or ellipsis. If a related entity has been introduced, the new lexical unit depends on the relation between the two entities; compare \[Tutin and Kittredge, 1992\].</Paragraph> <Paragraph position="1"> In our example, if the Exophoric module runs first, the Endophoric module ends up only pronominalizing implant in the last clause. If instead the Endophoric module runs first, the SPL produced is (1) rather than (2), i.e., the Endophoric Choice module chooses the phrase this happens to refer to an implant wears out, loosens, or fails. If we assume this variant, the pre-SPL expression for the second sentence is</Paragraph> </Section> </Section> <Section position="9" start_page="4" end_page="4" type="metho"> <SectionTitle> 4 Related Research </SectionTitle> <Paragraph position="0"> Related work falls into two areas. The first is sentence planning as a task, including the organization of the planning process. The second covers specific subtasks of sentence planning.</Paragraph> <Paragraph position="1"> Since we have already provided extensive references to work in the second area, and our focus in this paper is not on the detailed presentation of these subtasks, we refrain from discussing it further.</Paragraph> <Paragraph position="2"> In the first area, our sP appears, at first glance, to closely resemble DIOCENES \[Nirenburg et al., 1989\]: both systems contain a blackboard with different sentence planning tasks performed by separate modules. However, significant differences exist with respect to processing strategies, including blackboard management and conflict resolution; the assignment of different subtasks to modules; the organization of the modules; and the organization of knowledge resources. This issue is discussed in \[Jakeway et al., 1996\].</Paragraph> <Paragraph position="3"> In other related work \[Appelt, 1985; Meteer, 1991; Horacek, 1992\], several sentence planning tasks are treated within the process of text planning. \[Rambow and Korelsky, 1992; Panaget, 1994\] have a separate sentence planning component, but they do not separate the specific subtasks of sentence planning into distinct submodules. Necessarily, some subtasks, such as content delimitation, exophoric, and endophoric choice, then play a less prominent role.</Paragraph> </Section> class="xml-element"></Paper>