File Information
File: 05-lr/acl_arc_1_sum/cleansed_text/xml_by_section/intro/90/c90-3095_intro.xml
Size: 9,845 bytes
Last Modified: 2025-10-06 14:04:54
<?xml version="1.0" standalone="yes"?> <Paper uid="C90-3095"> <Title>apos;&quot; e'&quot; &quot; ' ' &quot; 1)I'1 ' ' , I h. I cxl, pla, nnmg (,ott~pot~<.nl of l,ho. I.,IIX)(I Sysl;C/.tn</Title> <Section position="4" start_page="0" end_page="0" type="intro"> <SectionTitle> 2. Architecture </SectionTitle> <Paragraph position="0"> Our textplanner basically decides what to say and gives as output a linear list of the conceptual entities that should be verbalized as answer to general questions of the kind What do you know about X? or What can you tell me about X? The planner takes as input a conummicative goal, e.g. describe(~), and needs access to all knowledge sources of the system, namely to the user model, the ontology, the background knowledge and the textknowledge. As the knowledge of the system is represented in LLILOG we use the inference engine for lookup and inferences. The user model currently only contains the facts that are already known to the hearer. The ontology is given by the sort hierarchy of the system, the background kmowledge contains world knowledge in the form of facts and inference rules and finally the textknowledge results from the analysis of seven short paragraphs describing places of interest in the city of Dfisseldorf.</Paragraph> <Paragraph position="1"> The output is a list of the entities and their attributes that should to be verbalized in. this order. This list is passed on to the generator that deterurines sentence boundaries and decides on the syntactic realization of the entities. The result of the generator is a formal description of the output sentence. This description is then takeu by the formulator that constructs a correctly inflected Germtu~ sentence. The formulator is. a system similar to SU-TRA (Busemann 88) or MUMBLE-86 (McDonald and Mercer 88).</Paragraph> <Section position="1" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 2.1 Implementation </SectionTitle> <Paragraph position="0"> In general, our implementation of the phmner is along the same lines a.s described in Hovy 88 except that we incorporate not only RST relations but also domaJnspecifie relations like ACCESS (how does one get to an object) and OPEN (when are the opening hours of an object). Moore and Swartout 89 and Moore and Paris 89 use the snme planning algorithm aud they have added plans like e.g. PERSUADE to the RST plans. This enables them to answer follow-up questions in advisory dialogues or in the explanation facility of an expert system. Most of the questions they cml answer are Why questions except two What questions: What is a concept? and What is the difference between two concepts? The general idea of their approach too is to gather the information that should be communicated but using their plaits we could not answer the kind of general question we have in mind.</Paragraph> <Paragraph position="1"> Like RST plans our plans consist of a nucleus and a satellite each associated with requirements and growth points. The nuclei contain the information that has to be verbalized obligatorily which is either done by recursively invoking other subplans or by an explicit verbalization cmmnand say(aQ. All plans are recursively expanded until they lead to a verbalization command. In contrast to nuclei sateBites, using the same notation, contain the same kind ofinfornmtion that can be optionally verbalized. The growth points allow for the inclusion of further infornmtion into the list of entities that is finally passed on to the generator. They again contain plans. Finally, the requirements for nucleus and satellite contain inquiries to the inference engine about e.g. the validity of certain subsort relations and about beliefs of the hearer. An exmnple of a plau, inleresting_~eature , is given below (the planner is implemented in PRO-LOG so the atoms with capital letters are variables): plan(intoxosting.featuxe(0bject), nucleus: \[say(0bjeot)\], satellite: \[say(Featuxo)\], nuoleuszequizement: axtd(\[subsozt(Objoct,object)\]), satellitezequizement: \[\], nucleus and..satelliterequirement:</Paragraph> <Paragraph position="3"> not(bel(heazer, attribute(Object, remarkability: Feature)))\]), nucleus gzowthpoirtt: \[interesting. feature(Feature)i, satellite.growth_point: \[\]) Fontal:e), Among the 12 plans used by PIT are domain dependent ones as. well as domain independent ones. The latter are formalizations of RST relations that lead to small text structures. The domain dependent Plans lead to larger structures, e.g. whole paragraphs. Each plan, even if it can be seen as domain independent, contains a domain specific part, namely the requirements for nucleus and satellite which are inquiries to the inference engine that have to heed the names of entities, roles, and features of the knowledge representation.</Paragraph> <Paragraph position="4"> The planning algorithm uses four data structures: the plans, a tree, a stack, and a usedllst. The text structure tree is binary. The root contains the commuuicative goal that initiates the phmning process. The nodes represent the executed plaits. Each node has successive nucleus and satellite edges.whose corresponding nodes may be either empty or contain an explicit verbalization command or further plans.</Paragraph> <Paragraph position="5"> The stack is used as an agenda. Its elements are tuples consisting of the plan to be executed next and a pointer to that leaf of the tree where the subtree stemming from the execution of the plan should be added.</Paragraph> <Paragraph position="6"> The used hst is a bookkeeping device representing which plan has been'used for which entity.</Paragraph> <Paragraph position="7"> The plmming algorithm consists of three phases: first, the text structure tree is built by a top-down hierarchical plmmer (Sacerdoti 75) using reeursive descent. Second, the verbalization eonunmlds are collected by traversing the tree depth-first, left-to-right. Third, the entities to be verbalized are expanded by their attributes contained in the knowledge base and 432 2 ~re passed on to the generator in a suit, able form. At the ;~tart of the planning process, i.e. when '~he communicative goal comes in, the tree, the stack, ~nd the used-list are empty. If the plan library offers a:n appropriate plan to achieve the goal it is tested whether this phm has already been executed for the entity in question. If so, the execution is aborted, otherwise the plan is put on the used list.</Paragraph> <Paragraph position="8"> Next the requirements of the plan are checked, first, the ones common to both nucleus and satellite and then the nucleus requirements. If they cannot be met, execution of the plan aborted, otherwise the requirements of the satellite are checked. If they canrot be met the corresponding plans of the satellite and the satelfite growth points are skipped. Are all requirements met, the new plans together with their pointers to that leaf of the tree where the subtrees ~;hould be added are pushed onto the stack in the following order: satellite growth points, nucleus growth points, satellite and nucleus.</Paragraph> <Paragraph position="9"> The second plan that is to be executed is popped fcom the stack and dealt with as described above with the addition that the agenda has to be updated when the tree has been expanded. The pointers of all plans to that leaf of the tree where a subtree has been added have to be changed in order to point to the nucleus of the new subtree.</Paragraph> <Paragraph position="10"> Planning stops when the agenda is empty.</Paragraph> <Paragraph position="11"> 3. Shortcomings and possible exten-</Paragraph> </Section> <Section position="2" start_page="0" end_page="0" type="sub_section"> <SectionTitle> :,;ions </SectionTitle> <Paragraph position="0"> The origlnal plans like the one shown above are based oil an extensive analysis of seven paragraphs describing places of interest in Diisseldorf. tlenee, they capture the typical structure of such descriptions and act as more flexible schemas that can be adapted to a user's needs by incorporating more communicative goals. Nevertheless, problems arise when new plans are added or when old ones are changed.</Paragraph> <Paragraph position="1"> \]It proved to be difficult to say in advance which text structure will be the outconle of the planl~ing protess. Through the top-down expansion of the text ~tructure tree new plans may be inserted into the tree t'A places w\]lere they do not have the desired effect C/,1 the text structure. E.g. the plan \]cat,ires(X) may be the nucleus of the initiating plan deseriplion(X) and ~dso satellite of a more fine grained plan. As those plans that have been pushed last onto the stack are executed first and no plan is executed twice the features may be verbalized at the wrong place in the text.</Paragraph> <Paragraph position="2"> Generally speaking, these problems point to the need to strictly separate the planning of the proposltlonal and the rhetorical. Although our hierarchical planner can be used successfully to plan the content of the descriptive paragraphs we feel that a non-linear planning algorithm 1night be better snited for the planning of the propositional content followed by a hierarchical planner for the rhetorical structure. Another problem is the domain dependence of the propositional planner which always snacks in through the requirements placed on nncleus and satellite. The :requirements are stated in terms of the knowledge representation langamge. The only partial solution to this problem is to use general terms in the planner and a separate mapping of these general terms onto the knowledge representation language.</Paragraph> <Paragraph position="3"> Our further research is directed in this direction.</Paragraph> </Section> </Section> class="xml-element"></Paper>