File Information
File: 05-lr/acl_arc_1_sum/cleansed_text/xml_by_section/metho/80/j80-3001_metho.xml
Size: 48,914 bytes
Last Modified: 2025-10-06 14:11:16
<?xml version="1.0" standalone="yes"?> <Paper uid="J80-3001"> <Title>Computing Story Trees</Title> <Section position="3" start_page="0" end_page="0" type="metho"> <SectionTitle> (TRADINGVOYAGE A RUFOLO WITH GOODS IN SHIP TO CYPRUS) <= (BUY A RUFOLO TH SHIP) (BUY A RUFOLO TH GOODS) (LOAD A RUFOLO TH SHIP WITH GOODS) (SAIL A RUFOLO TO CYPRUS MEANS SHIP) </SectionTitle> <Paragraph position="0"> is a meaningful rule. (Here case notation is used: A for Agent, TH for THeme, etc.) On the other hand,</Paragraph> </Section> <Section position="4" start_page="0" end_page="0" type="metho"> <SectionTitle> (TRADINGVOYAGE A RUFOLO WITH GOODS IN SHIP TO CYPRUS) <: (SAIL A RUFOLO TO CYPRUS MEANS SHIP) (LOAD A RUFOLO TH SHIP WITH GOODS) (BUY A RUFOLO TH GOODS) (BUY A RUFOLO TH SHIP) </SectionTitle> <Paragraph position="0"> is nonsensical. The rules of coherence that order the antecedent propositions may involve several criteria: causal connectedness (B causes/is the result of C, which causes/is the result of D), or temporal ordering (B happens before/after C, which happens before/ after D), etc. Note that the ordering of antecedent propositions can be tied to textual order within the framework of ordinary Horn clauses by adding extra arguments to the propositions. This has been done in the theory of definite clause grammars (Colmerauer, 1978; Pereira and Warren, 1980).</Paragraph> <Paragraph position="1"> The above TRADINGVOYAGE rule can be interpreted in either of two ways. If we are given the proposition</Paragraph> </Section> <Section position="5" start_page="0" end_page="0" type="metho"> <SectionTitle> (TRADINGVOYAGE A RUFOLO WITH GOODS IN SHIP TO CYPRUS) </SectionTitle> <Paragraph position="0"> in a text, or a summary of a text, we may infer the chain of events</Paragraph> </Section> <Section position="6" start_page="0" end_page="0" type="metho"> <SectionTitle> (BUY A RUFOLO TH SHIP) (BUY A RUFOLO TH GOODS) (LOAD A RUFOLO TH SHIP WITH GOODS) (SAIL A RUFOLO TO CYPRUS MEANS SHIP) </SectionTitle> <Paragraph position="0"> and, if given these events in order in a text, we may infer that Rufolo was performing a TRADINGVOYAGE. null Because of this capability for use in two directions, this rule form can be used both in parsing and generating tasks. A parser can avail itself of these rules to group sets of propositions in a text into units headed by macrostructures (which are the consequents of the rules). These can be further grouped into more generalized macrostructures recursively to yield a story tree. A generator can proceed in the other direction, starting with the top node of a tree and expanding it and its constituents downward recursively (by using the rules that operate on the precondition propositions) to arrive at a tree whose terminals form a coherent text.</Paragraph> <Section position="1" start_page="0" end_page="0" type="sub_section"> <SectionTitle> American Journal of Computational Linguistics, Volume 6, Number 3-4, July-December 1980 137 Alfred Correira Computing Story Trees 2.3 Extended Horn Clauses </SectionTitle> <Paragraph position="0"> After several early experiments with this rule form on a simple text (the Margie story - Rumelhart, 1975) it was discovered that this simple rule form, although capable of handling the computations necessary for the text at hand, did not bring out several inherent attributes that macrostructures generally have in common.</Paragraph> <Paragraph position="1"> For example, in a TRADINGVOYAGE rule, several divisions can be recognized. In order to go on a TRADINGVOYAGE, Rufolo must have the money for a ship and goods and the necessary knowledge about competition to make a profit. Given these, Rufolo will follow a certain sequence of actions; he will obtain a ship and goods, load the goods onto the ship and then sail to Cyprus. The result of this effort will be that Rufolo is in a position to sell or trade his goods (and perhaps make a profit). Therefore, we can break the TRADINGVOYAGE rule into several natural groupings:</Paragraph> </Section> </Section> <Section position="7" start_page="0" end_page="0" type="metho"> <SectionTitle> TRADINGVOYAGE RULE : HEAD : (TRADINGVOYAGE A RUFOLO WITH GOODS IN SHIP TO CYPRUS) PRE : (POSSESS A RUFOLO TH WEALTH) EXP : (MAKE A RUFOLO TH (CALCULATIONS MOD MERCHANTS TYPE USUAL) ) (BUY A RUFOLO A SHIP) (BUY A RUFOLO TH GOODS) (LOAD A RUFOLO TH SHIP WITH GOODS) (SAIL A RUFOLO TH SHIP TO CYPRUS) POST : (MAKE A RUFOLO TH PROFIT) </SectionTitle> <Paragraph position="0"> Structurally, this rule form will be referred to as an &quot;extended&quot; Horn clause (EHC). The first part of the rule is the HEAD of the rule, and represents the macrostructure pattern. The second part is the PREcondition for the rule. The propositions in the precondition are the conditions which must be true, or can be made true, before Rufolo can embark on an episode of TRADINGVOYAGE. The third part is the EXPansion of the rule. If Rufolo goes on a TRADING-VOYAGE, then these are the (probable) actions he will take in doing so. The final part of the rule is the POSTconditic~n of the rule, which consists of the propositions that'will become true upon the successful completion (instantiation) of the TRADINGVOYAGE rule.</Paragraph> <Paragraph position="1"> The resulting rule form is related conceptually and historically to the notion of a script as developed by Schank and Abelson (1977) (el. Norman and Rumelhart, 1975). The precondition sets the stage for the invocation of a rule. It describes the setting and the roles of the characters involved in the rule. The expansion consists of the actions normally taken during the invocation of the rule. The postcondition is the result of these actions. When used in a script-like role, a rule is activated when its precondition has been satisfied, and its expansion can then be sequentially instantiated.</Paragraph> <Paragraph position="2"> A rule can also be used as a plan. A plan is a data structure that suggests actions to be taken in pursuit of some goal. This corresponds to activating a rule according to its postcondition, i.e. employing a rule because its postcondition contains the desired effect. If one has the goal &quot;make money&quot; one might wish to employ the TRADINGVOYAGE rule to achieve it.</Paragraph> <Paragraph position="3"> This extension of the Horn clause structure serves two purposes. First, by separating the propositions subsumed under a macrostructure into three parts, the EHC rule form renders it unnecessary to label the roles that the individual propositions play in the macrostructure. A macrostructure will usually have preconditions, expansion(s), and a postcondition set, which would have to be labeled (probably functionally) in a simple Horn clause system. Secondly, it serves as a means of separating those propositions which must be true before a rule can be invoked (preconditions) from those whose success or failure follows the invocation of the rule.</Paragraph> <Paragraph position="4"> A rule may have multiple preconditions if there are several sets of circumstances under which the rule can be invoked. Thus a rule for watching a drive-in movie could have the form</Paragraph> </Section> <Section position="8" start_page="0" end_page="0" type="metho"> <SectionTitle> WATCH DRIVE-IN MOVIE RULE: HEAD : (WATCH A PERSON TH DRIVE-IN MOVIE) PRE : (OR ((PERSON IN CAR) (CAR IN DRIVE-IN)) ((SEE A PERSON TH SCREEN) (CAN A PERSON TH (READ A PERSON TH LIPS)))) </SectionTitle> <Paragraph position="0"> A rule may also have several expansions attached to it, one for each potential instantiation of the rule.</Paragraph> <Paragraph position="1"> Thus if a couple want a child they could employ a rule:</Paragraph> </Section> <Section position="9" start_page="0" end_page="0" type="metho"> <SectionTitle> POSSESS RULE : HEAD : (POSSESS A COUPLE TH CHILD) EXP : (OR (CONCEIVE A COUPLE TH CHILD) (ADOPT A COUPLE TH CHILD) (STEAL A COUPLE TH CHILD) (BUY A COUPLE TH CHILD)) </SectionTitle> <Paragraph position="0"> where each of the propositions, CONCEIVE, ADOPT, STEAL, BUY expands by a complex rule of the same form as the POSSESS rule.</Paragraph> <Section position="1" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 138 American Journal of Computational Linguistics, Volume 6, Number 3-4, July-December 1980 Alfred Correira Computing Story Trees </SectionTitle> <Paragraph position="0"> A rule can have but a single postcondition, composed of simple propositions, since by definition the postcondition is the set of propositions that are true if the rule succeeds. If a postcondition could contain an expandable proposition, then that proposition could fail independently of the rule for which it is part of the postcondition - since it could have its own preconditions - thus contradicting the definition of the postcondition. null</Paragraph> </Section> <Section position="2" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 2.4 Indexed Rule Network of Extended Horn Clauses </SectionTitle> <Paragraph position="0"> The rules are stored in memory in a semantic network. However, unlike the usual semantic networks for case predicates, where the individual nodes (tokens) are connected by case relations (Simmons and Chester, 1977), the semantic links in the EHC rule network are based on the story tree structure.</Paragraph> <Paragraph position="1"> Each rule node (or instantiation of one) in the network may have an arc for each part of an EHC rule: precondition, expansion, and postcondition. All the case relations in the head of the proposition are kept in a single list attached to the node as arc-value pairs. Negation is marked by embedding the node in a (NOT OF ...) proposition form. For example, if a point is reached in a narrative where John is expected to kiss Mary but he does not, then the story tree would contain at that point a node that would print as</Paragraph> </Section> </Section> <Section position="10" start_page="0" end_page="0" type="metho"> <SectionTitle> (NOT OF (KISS A JOHN TH MARY)). </SectionTitle> <Paragraph position="0"> Each node in the database represents either a class object or an instance of a class object. Every class object points to all of the tokens subsumed by it in the network. For example, the class object representing DOG would have pointers to each of its tokens, DOG1, DOG2, DOG3, etc., which represent individual objects of the class DOG.</Paragraph> <Paragraph position="1"> The database retrieval functions utilize a kind of &quot;fuzzy&quot; partial matching to retrieve potential rules to be applied to a proposition. Partial matching allows the rule-writer to combine rules that only differ in one or two minor arc names, but which all share the same major arc names; only one rule need be written, specifying the major case relations and ignoring the minor ones (which can be checked for in the preconditions of the rules). Partial matching allows the generator to bring more operators to bear at a given point in the story construction. However, the parser pays the price for this flexibility by having to examine more alternatives at each point in its parsing where rules apply. The function which queries the database for the existence of facts (instantiatcd propositions), uses a &quot;complete&quot; pattern-matching algorithm, since &quot;John ate cake last night&quot; is not deemed a sufficient answer to the question &quot;Who ate all the cake last night at Mary's place?&quot;.</Paragraph> <Paragraph position="2"> 3. Story Analysis Using Extended Horn Clauses This section describes the use of the Extended Horn Clause rule form and illustrates the process of rule-writing using several paragraphs from the Rufolo story as an example. The notion of rule failure is also presented as an integral feature of parsing and generating narrative texts.</Paragraph> <Section position="1" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 3.1 Writing Rules Using Extended Horn Clauses </SectionTitle> <Paragraph position="0"> The EHC rule form divides the propositions subsumed by a macrostructure into three categories: the preconditions, the expansions, and the postconditions.</Paragraph> <Paragraph position="1"> The preconditions define the applicability of a particular rule. When a precondition has been satisfied, then a rule's expansions and postcondition correspond roughly to the traditional add/delete sets of problem-solving systems. The add set consists of the ordered list of actions to be taken as a result of the rule's invocation plus the postcondition states of the actions.</Paragraph> <Paragraph position="2"> Members of the delete set are propositions of the form (NOT OF NODE) appearing in the expansion and postcondition of a rule.</Paragraph> <Paragraph position="3"> The question then becomes one of mapping a text into rules of this structure. To illustrate this process consider the following streamlined version of two paragraphs from the Rufolo story: Rufolo made the usual calculations that merchants make. He purchased a ship and loaded it with a cargo of goods that he paid for out of his own pocket. He sailed to Cyprus. When he got there he discovered other ships docked carrying the same goods as he had. Therefore he had to sell his goods at bargain prices. He was thus brought to the verge of ruin.</Paragraph> <Paragraph position="4"> He found a buyer for his ship. He bought a light pirate vessel. He fitted it out with the equipment best suited for his purpose. He then applied himself to the systematic looting of other people's property, especially that of the Turks.</Paragraph> <Paragraph position="5"> After a year he seized and raided many Turkish ships and he had doubled his fortune.</Paragraph> <Paragraph position="6"> At the top level of the story we have two complex actions taking place: a trading voyage and a pirate voyage. A TRADINGVOYAGE requires a merchant, a ship, some trade goods and a destination on a seacoast (for example, an island). So we embody this in Given that these conditions are true, then Rufolo plans his strategy, obtains both ship and goods and sails to Cyprus with them (the function of the asterisks is notational only and is used to distinguish those predicates that have rule expansions from those that do</Paragraph> <Paragraph position="8"> One might consider doing without the PURCHASE rule. Its precondition could have been pushed into the precondition for the TRADINGVOYAGE rule and its expansion inserted into TRADINGVOYAGE at the same point where the PURCHASE is now. But this rule-splitting is not just a stylistic choice; there are several advantages to this strategy. First, keeping rule size small makes the rule easier to read and write.</Paragraph> <Paragraph position="9"> Experience with writing rules showed that an average rule size of three to five propositions proved to be most efficient in this respect. Second, smaller rule size cuts down on the number of permutations of a rule that need to be recognized by the parser, due to missing propositions or the transposition of propositions that describe more or less contemporaneous events.</Paragraph> <Paragraph position="10"> Finally, smaller rules make for more conciseness in summaries generated from the rules.</Paragraph> <Paragraph position="11"> The postcondition of the PURCHASE rule is that the wealth used to buy the ship and goods is no longer in the possession of its original owner. This would have been inserted into the postcondition of TRADINGVOYAGE if the PURCHASE rule had been incorporated into it directly.</Paragraph> <Paragraph position="12"> The difference between the POSSESS* and POSSESS** propositions in the PURCHASE rule is illuminating. The POSSESS* in the precondition does not have a rule attached to it, so it cannot be expanded. If a merchant does not already possess wealth when he reaches this point, he cannot go about obtaining it through rule expansion (although the generator can fudge and assert that he does have wealth at this point to move the story generation along). If the pre-condition of the PURCHASE rule had contained a POSSESS** instead, then the merchant would be able to apply the POSSESS rule above to acquire wealth if he did not have any. The convention, as illustrated above, is for the expandable propositions to be suffixed with two asterisks, and for terminal elements to be suffixed with a single asterisk. This feature is only a notational device.</Paragraph> <Paragraph position="13"> The TRADE rule describes a trading scenario under conditions of heavy competition:</Paragraph> <Paragraph position="15"> Note that the two POSSESS** rules above would be combined into a single rule in the database.</Paragraph> <Paragraph position="16"> Rufolo outfits his newly purchased ship as a pirate vessel and then over the course of a year uses it to seize the ships of many Turks, until at the end he has doubled his wealth. The postcondition of this activity is that he no longer wishes to double the amount of his (old) wealth and that he now possesses twice as much wealth as before.</Paragraph> <Paragraph position="17"> These rules do not thoroughly map the exact meaning of the two paragraphs above, but they do give a flavor for the process of rule-writing, and linguistic precision is easy to ensure by use of additional rules to pin down precisely every nuance in the text, particularly with respect to selling and buying and change of ownership.</Paragraph> <Paragraph position="18"> Rule-writing using EHCs follows standard top-down programming practice. At the top level are the rules that describe the narrative structure of the text. For the Rufolo story, we have: The Rufolo story is basically a SETTING followed by an EPISODE, where EPISODE is defined recursively as either an INTERLUDE, which leads into an episode followed by a new EPISODE, a COMPLICA-TION followed by a new EPISODE, or a COMPLI-CATION and a RESOLUTION if the COMPLICA-TION does not cause any new problems to arise (due to rule failure - see next section).</Paragraph> <Paragraph position="19"> Experience with simple narrative text leads to the belief that it is relatively easy to learn to program using EHC rules, and that their expressive power is limited only by the ingenuity of the rule-writer. Experiments with other text forms - encyclopedia articles, magazine articles, dialogues, etc. - need to be performed before a final judgement can be made concerning the fitness of the EHC as a general form for processing.</Paragraph> </Section> <Section position="2" start_page="0" end_page="0" type="sub_section"> <SectionTitle> American Journal of Computational Linguistics, Volume 6, Number 3-4, July-December 1980 141 Alfred Correira Computing Story Trees 3.2 Success and Failure in EHC Rules </SectionTitle> <Paragraph position="0"> The idea of rule success or failure in the EHC rule form is tied to the domain the rules attempt to model real life motivated behavior (actions) where things can, and do, go wrong, and actors fail to achieve their goals. In real life, Rufolo's decision to go on a TRADINGVOYAGE does not guarantee that the voyage will be successful, or even begun. For a given rule, one of three conditions may arise. First the rule's preconditions may fail to be true and the rule cannot be applied. In the TRADINGVOYAGE rule, if Rufo1o does not have the money necessary for trading in Cyprus or does not possess the knowledge to successfully compete, then the TRADINGVOYAGE cannot be completed despite Rufolo's best intentions. A rule is not invoked until one of its precondition sets has been successfully processed (i.e. each precondition in the set has been successfully fuzzy-matched).</Paragraph> <Paragraph position="1"> Once this condition is satisfied then the rule can be invoked and Rufolo can start his TRADINGVOY-AGE. At each point of expanding the macrostructure, i.e as Rufolo performs each step in the expansion of the rule, he is subject to success or failure. He may succeed in buying the goods, or he may fail, and the same is true for buying the ship and the loading of the ship with goods, etc. If he does manage to perform all the actions in an expansion, then the rule is said to succeed, and its postcondition propositions can be asserted as being true. In the TRADINGVOYAGE rule, an-assertion that Rufolo makes a profit would be instantiated.</Paragraph> <Paragraph position="2"> But if an expansion fails, a different logic applies.</Paragraph> <Paragraph position="3"> If Rufolo has loaded the ship with his goods, but the ship burns in the harbor, then the last expansion proposition, sailing to Cyprus, cannot be performed. The rule is said to fail, and the postcondition propositions are negated. In the TRADINGVOYAGE rule, an assertion that Rufolo does not make a profit would be instantiated because no other expansion options remain. null Rule failure is an important concept with respect to narratives. Many narratives consist of a series of episodes in pursuit of a goal; often each episode, except the last, represents an instance of a failed rule. If a rule prior to the last succeeded, then the goal would have been achieved and no further episodes would have been forthcoming, (unless a new goal were chosen). The mechanism of rule failure is a natural one for analyzing this type of narrative pattern.</Paragraph> </Section> </Section> <Section position="11" start_page="0" end_page="0" type="metho"> <SectionTitle> 4. Generation and Parsing </SectionTitle> <Paragraph position="0"> In this section a procedure for using ma'crostructures, embodied in the EHC rule-form, to generate and parse stories, and a program, BUILDTALE/ TELLTALE, that implements it are discussed.</Paragraph> <Section position="1" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 4.1 Generation </SectionTitle> <Paragraph position="0"> The paradigm used by TELLTALE for story generation is similar to that used by Meehan (1976) in his TALESPIN program, which wrote &quot;metanovels&quot; concerning the interrelationships, both physical and mental, of the motives and actions of anthropomorphized animals possessing simple behavior patterns. Meehan described a story as an exposition of events that occur when a motivated creature attempts to achieve some goal or fulfill some purpose, such as satisfying a need or desire, solving a problem, doing a job, etc.</Paragraph> <Paragraph position="1"> TALESPIN was basically a problem-solver that operated on a database consisting of living entities, inanimate objects, and a set of assertions (rules) typifying the relationships among them, and describing operations for affecting those relationships. The rules were organized into plans based on conceptual relatedness, which aided in retrieval of specific rules.</Paragraph> <Paragraph position="2"> Meehan emphasized the use of plans as a mechanism for generating stories. Plan activation was a process of assigning a goal to a character and then calling up any relevant plans that were indexed by this goal.</Paragraph> <Paragraph position="3"> In the EHC rule form the precondition governs the ability of a rule to be invoked. If a rule is considered to be a plan in the Meehan sense above, then instead of indexing the rule by its postcondition propositions, it can be indexed by its precondition if the precondition contains information relating to motivation. For example, the rule, is a rule that can be activated if some X, who must be a man, WANTs Y, who must be a woman, to marry X.</Paragraph> <Paragraph position="4"> Each rule could contain propositions in its preconditions that restrict the set of objects that can instantiate the variables of the rule.</Paragraph> <Paragraph position="5"> The last proposition in the precondition, the WANT*, is a goal statement; it states that the MARRY rule can be invoked when one person wants to marry another. In the process of generating a story, if a point is reached where a man develops the goal of wanting to marry a woman, the MARRY rule can be</Paragraph> </Section> <Section position="2" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 142 American Journal of Computational Linguistics, Volume 6, Number 3-4, July-December 1980 Alfred Correira Computing Story Trees </SectionTitle> <Paragraph position="0"> invoked to attempt to satisfy that want. Of course, if the ASK* or ACCEPT* fails, then the postcondition becomes (NOT OF (MARRY* ...)) instead.</Paragraph> <Paragraph position="1"> The main advantage of inserting the WANT* into the preconditions is that the generator need not, as a result, contain special logic to examine the postconditions of a rule to ascertain which rules to apply at a point in the story. The normal rule activation mechanism (a rule can only be applied if one of its precondition sets succeeds) will automatically weed out unwanted rules because of the information relating to motivation.</Paragraph> <Paragraph position="2"> TELLTALE generates stories (sequences of propositions) based on such rules contained in its database, either under user control or directed by the program itself. The database is a semantic network of nodes created by building a network of the case-predicate rules supplied by the user. The input to TELLTALE is the root of a story tree, which informs TELLTALE as to the type of story which is to be generated (fairy tale, etc.). The output from TELLTALE is an instantiated story tree whose terminals are the propositions of the text. The program SUMMARIZE computes summaries from the story tree. An annotated example rule-base can be found in Appendix A for generating a set of fairy tales. A sequence of propositions for a story generated from that rule-base is shown in Appendix B. Two summaries of the story are shown in Appendix C.</Paragraph> <Paragraph position="3"> Starting with the root, TELLTALE executes until no nodes remain to be expanded, because all have been reduced to terminal propositions or some depth limit has been reached. A traversal of the terminals of the resulting story will yield the proposition text of the story; any higher level traversal will yield a summary of the story.</Paragraph> </Section> <Section position="3" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 4.2 Parsing </SectionTitle> <Paragraph position="0"> This section describes a procedure, BUILDTALE, for using macrostructures to parse stories. The goal in writing the generator-parser system has been to create a program capable of understanding those texts that it can generate from a rule-base. Diagrammatically</Paragraph> <Paragraph position="2"> the diagram above should be the same as the output from part D. The story trees might or might not be identical, depending on whether the story grammar is ambiguous.</Paragraph> <Paragraph position="3"> The philosophy of the understander can be summarized by recalling a concluding statement by Rumelhart (1975): &quot;It is my suspicion that any automatic 'story parser' would require ... 'top-down' global structures .... but would to a large degree discover them, in any given story, by the procedures developed by Schank (1975).&quot; The procedures developed by Schank emphasize the &quot;bottom-up&quot; approach to story parsing. Starting with the raw input data, emphasis is placed on integrating each sentence into the developing narrative structure. The structures used are scripts (and plans), and parsing integrates propositions into scripts. The scripts form an implicit episodic structure, but the higher order relationships among the scripts are not generally made specific (i.e. what structures form episodes, setting information, complications, resolutions, etc). BUILDTALE is a program that combines the top-down and bottom-up approaches. As the parse progresses, BUILDTALE attempts to integrate the terminal propositions into the context of a story tree. It manipulates the terminals bottom-up, integrating them into macrostructures, while it is building story structure nodes (STORY, SETTING, EPISODE, etc.) topdown. If BUILDTALE successfully parses the text, these two processes will converge to instantiate a complete story tree.</Paragraph> <Paragraph position="4"> Starting with the root of a story tree and an unmarked string of text propositions, BUILDTALE executes, by an algorithm described in Section 4.4, until one of three conditions occurs: 1) If the procedure exhausts the proposition list before the STORY node has been built, then it fails.</Paragraph> <Paragraph position="5"> 2) If the procedure builds an instance of STORY but there still remain unmarked propositions, then it fails.</Paragraph> <Paragraph position="6"> 3) If an instance of STORY is built and the text stream is empty, the the procedure returns the instantiated root.</Paragraph> <Paragraph position="7"> A terminal-level traversal of the resulting tree will yield the original input text proposition stream; higher level traversals will yield summaries of the text. The tree that results from the story generator should yield the same bottom-level terminal propositions as the tree that results from the parsing of the terminal propositions of the story, i.e. the output from part B in</Paragraph> </Section> <Section position="4" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 4.3 The Relationship Between Generating and Parsing </SectionTitle> <Paragraph position="0"> There are several differences between the BUILDTALE and TELLTALE procedures. First, whereas the parser is restricted to propositions from the input</Paragraph> </Section> <Section position="5" start_page="0" end_page="0" type="sub_section"> <SectionTitle> American Journal of Computational Linguistics, Volume 6, Number 3-4, July-December 1980 143 Alfred Correira Computing Story Trees </SectionTitle> <Paragraph position="0"> text for its terminals, the generator is free to build a terminal any time one can be generated. Second, the generator is free at each step to choose any rule that will match a proposition it is trying to expand, and also to use any of a rule's preconditions or expansions in any order. The parser must be careful in its choice of rules and in how it examines the preconditions and expansions in a rule, always examining them in order of decreasing length, to ensure that it does not build a story tree and find left-over unmarked text propositions when done.</Paragraph> <Paragraph position="1"> The generator builds a proposition by first instantiating its precondition, expansion, and postcondition, and then attaching them to the instantiated head. The generator knows at all times the father of the proposition it is instantiating; in fact it knows every ancestor of that proposition between it and the root, since it operates strictly top-down.</Paragraph> <Paragraph position="2"> The parser operates primarily as a left-corner bottom-up procedure, with overall direction supplied by some top-down processing. When the parser builds a structure, it cannot be sure at that time that the structure is indeed the correct one to be integrated into the tree at that point, i.e. it does not yet know the correct path to the root. The parser must, therefore, save the context information of its build decisions, so that they can be undone (or at least ignored) if they are later found to be in error. In fact, the final structure of the tree can only be assigned after all the textual propositions have been analyzed. This is in agreement with the statement of van Dijk (1975, pg. 11): &quot;Strictly speaking, a definite hierarchical structure may be assigned to a discourse sequence of propositions only after processing of the last propositions. For long discourses this would mean that all other propositions are kept in some memory store.&quot; Structures are built as the parse progresses, and some might be discarded or rearranged. Their final position in the tree cannot be determined until all the propositions have been examined.</Paragraph> <Paragraph position="3"> Some previous parsers solved this problem by resorting to higher-level languages like CONNIVER and PLANNER, paying the price in higher computational costs. A conscious effort was made with this project to avoid the expense of resorting to a higher-level language by having LISP perform the necessary book-keeping to handle the backtracking involved in undoing an incorrect choice (build). In BUILDTALE, the bookkeeping is accomplished by pushing context information onto the LISP control stack. Usually, when a build is performed , instead of returning (popping the LISP stack), a further descent is made in order to integrate the next proposition. If a build is later found to be in error, then a FAIL function automatically causes LISP to back up in its stack to the point where the build was made and undo it, since all the information that was around when the first decision was made to build is still present on the stack.</Paragraph> <Paragraph position="4"> These differences should not obscure the very real similarities between the two processes. TELLTALE and BUILDTALE use the same functions to analyze the preconditions, expansions and the postcondition of a rule. In fact, the &quot;basic&quot; control structure of TELLTALE is a special case of the control structure of BUILDTALE. The difference between the two occurs at build time. In BUILDTALE, when a node in the tree is built, a check is made to see if this node matches the root of the derivation tree being built.</Paragraph> <Paragraph position="5"> This may not be the case since the node may be many levels lower in the tree than the root in question, and these levels will need to be built before the derivation tree is complete. Of course, if the node should match the root, then it is returned.</Paragraph> <Paragraph position="6"> TELLTALE, on the other hand, never descends more than a single level in the tree at a time. When a build is performed, it will always derive from the derivation tree being processed. The node and the root always match, and the node is returned. At build time, when BUILDTALE decides whether to call itself recursively (to add the next higher level in the tree) or to pop the stack (returning the derivation tree root), TELLTALE will always pop the stack.</Paragraph> <Paragraph position="7"> Generation and parsing use the same grammar with different terminating conditions to define the control paths through the grammar. They resemble each other in computing as output a derivation tree whose terminals are the propositions of the text. This fact was borne out during the implementation of the system.</Paragraph> <Paragraph position="8"> TELLTALE was coded first, and the eventual TELLTALE/BUILDTALE control structure for processing preconditions, expansions, and postconditions was debugged and tested by generating many story trees. BUILDTALE grew out of TELLTALE by adding the build-time recursion/backup mechanism to the control structure.</Paragraph> <Paragraph position="9"> The symmetric relationship between generation and parsing with respect to the computation of derivation trees is one significant feature of the EHC rule system.</Paragraph> </Section> <Section position="6" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 4.4 The Basic Control Structure </SectionTitle> <Paragraph position="0"> BUILDTALE and TELLTALE are essentially large separate PROG-defined LISP functions that effect different initialization conditions, and then execute the same set of underlying functions. Below is a description of the basic control structure shared by TELLTALE and BUILDTALE:</Paragraph> </Section> <Section position="7" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 144 American Journal of Computational Linguistics, Volume 6, Number 3-4, July-December 1980 Alfred Correira Computing Story Trees </SectionTitle> <Paragraph position="0"> I: For each proposition being examined: 1) If it exists instantiated in the data base, then return the instantiation, whether it is found negated or not; 2) if there are no rules for the node, then it can be asserted; 3) otherwise, for each rule until one succeeds: a) for each precondition in the rule until one succeeds, do I for each proposition in the precondition; b) if no precondition succeeds, then fail; c) otherwise, for each expansion until one succeeds, do I for each proposition in the expansion; d) if an expansion succeeds, then for each proposition in the postcondition, do I and return the instantiated node (rule success); e) otherwise, for each proposition in the postcondition, do I for the negation of the proposition and generate a (rule) failure.</Paragraph> <Paragraph position="1"> &quot;Do I&quot; means &quot;follow the procedure labelled 'I'&quot; which is the entire basic control structure outlined above. Since postcondition propositions do not have rule expansions, they never perform step 3 above. Also, rule failure is not marked by negation (another mechanism is used) so, if a negated node is encountered, it will never fall through to step 3. Finally, it should be noticed that, although it is possible for the algorithm to generate erroneous propositions in step 2 if exploring an incorrect path during parsing (BUILDTALE), these propositions will be undone during backup when the path has been recognized as incorrect.</Paragraph> </Section> </Section> <Section position="12" start_page="0" end_page="0" type="metho"> <SectionTitle> 5. Extracting Summaries From Story Trees </SectionTitle> <Paragraph position="0"> One of the principal reasons for choosing the Kintsch and van Dijk macrostructure theory was the resulting property of summarizability; the ability to produce coherent summaries is one mark of intelligence in a parser. The summarizer produces various strings of propositions from the story tree which form summaries of a text. One such string is composed of the terminals and represents the complete story. Any sequence of propositions output by the summarizer is a well-formed input to the parser. The system is thus able to parse all proposition sequences it can generate.</Paragraph> <Paragraph position="1"> Since the summary feature is inherent in the trees as they are given to the summarizer, a simple leveltraversal algorithm would have been sufficient to generate useful output. However, this would have resulted in needless redundancy of propositions (since some are checked repeatedly by the preconditions of the rules and have pointers to them at many places in the tree). Therefore, the summarizer remembers what it has already output in the summary, so as never to repeat itself.</Paragraph> <Paragraph position="2"> Another area of repetition concerns attributes for objects in the story. To avoid repeating an object's attributes, the summarizer keeps a list of objects that have already appeared in at least one proposition, and whenever it encounters in a new proposition an object not on this list, it outputs it with all of its properties and then places it on the list of expanded objects.</Paragraph> <Paragraph position="3"> Since no time-markers are put on an object's properties, they are all printed out at once, even if some of those properties are not attached to the object until much later in the story; this reveals a weakness in the procedure that can be corrected by the introduction of time-markers for objects (actions already possess timemarkers). null One attribute of story trees is that, at their higher nodes, one can read off the syntactic structure of the story. For example suppose a story consists of a setting followed by three episodes. As a summary, &quot;setting plus three episodes&quot; is usually not very interesting; therefore the summarizer has the ability to recognize and descend below these story structure nodes in the final summary. These nodes are treated like all other nodes to the tree building procedures, but the summarizer descends below the nodes to print their descendants, no matter what level summary is being computed.</Paragraph> <Paragraph position="4"> There is also the question of summarizing the macrostructures (rules). By definition, these nodes are expandable, i.e., they have a rule for expanding them in the rule-base. Maerostructures are not marked with a NOT if they fail; only simple propositions - terminals - are. However, whether a script achieves its goal or not is vital information to be included in any reasonable summary produced from the tree. Therefore, when summarizing a macrostructure, the summarizer outputs both the head (the macrostructure pattern) and its postcondition (if the script fails to achieve its goal, the postcondition will have been negated).</Paragraph> <Paragraph position="5"> Finally, the summarizer outputs only those propositions it recognizes as non-stative descriptions; it never outputs state descriptions. The reason for this is that a stative always describes the attribute(s) of some object, and can therefore be output the first time that that object appears in an active proposition.</Paragraph> <Paragraph position="6"> The summarizer is an algorithm that, given a story tree and a level indicator, scans the nodes of the tree at that level, and applies the following rules to each node: American Journal of Computational Linguistics, Volume 6, Number 3-4, July-December 1980 145 Alfred Correira Computing Story Trees 1) If the node is a story structure node, then summarize its sons.</Paragraph> <Paragraph position="7"> 2) If the node has already been processed, then skip it.</Paragraph> <Paragraph position="8"> 3) If the node is marked as a script, return its head followed by its postcondition propositions.</Paragraph> <Paragraph position="9"> 4) If the node is a stative, then skip it.</Paragraph> <Paragraph position="10"> For each case value in a proposition to be output (for example, RUFOLO1, DOUBLE*l, and WEALTH1 in (WANT*I A RUFOLO1 TH (DOUBLE*I A RUFOLO1 TH WEALTH1))), the following rule is applied: 5) If the case value has not appeared in a previously accepted proposition, print it and all its attributes; otherwise, just print the case value itself.</Paragraph> <Paragraph position="11"> For example, if RUFOLO1 has been mentioned in a proposition prior to WANT*I in a summary, then only RUFOLO1 will be present in the WANT*I proposition, and not the fact that RUFOLO1 is a MERCHANT1 from RAVELLO1, etc.</Paragraph> <Paragraph position="12"> An initial version of an English language generator was written that applies a set of rules to the output of the summarizer to produce well-formed English texts (Hare and Correira, 1978). This generator uses rule forms and the summarizer output to solve some of the problems involved in: reasonable paragraphing and sentence connectivity, elision of noun groups and verbs, and pronominalization of nouns. The decisions are based, in part, on the structure of the story tree and the positions of individual propositions in that tree.</Paragraph> </Section> <Section position="13" start_page="0" end_page="0" type="metho"> <SectionTitle> 6. Discussion and Conclusions </SectionTitle> <Paragraph position="0"> The task of text processing requires solutions to several important problems. The computational theory for macrostructures using Extended Horn Clauses was designed with the following goals in mind. A computational model should have some degree of psychological validity, both to provide a humanly useful representation of textual content and organization and to ensure that the task of rule-writing is as natural as possible for the human grammar producer. It should be conceptually simple, in both design and implementation, taking advantage of similarities between generation and parsing, and it should offer a rigorous data structure that is uniform and avoids the growth of ad hoe large-scale structures.</Paragraph> <Paragraph position="1"> The computational macrostructures realized by the Extended Horn Clause notation succeed in many ways in satisfying these goals. They appear to resemble the structures humans build mentally when reading narrative texts. The story tree is a logical way to organize these macrostructures, with the terminals of a particular story tree comprising the actual textual propositions, and the interior nodes containing the instantiated heads of rules (corresponding to macrostructures). The story tree has the summary property: if the tree is truncated at any level, then a &quot;meaningful&quot; (coherent) summary of the original text can be read off directly.</Paragraph> <Paragraph position="2"> The generality of the macrostructure propositions increases as one nears the level of the root (going from the level of specific actions to the rules that contain them, to the story categories that contain these rules), which can be considered as the title for the text at its terminals.</Paragraph> <Paragraph position="3"> The concept of rule failure takes the EHC out of the strictly logical system of the normal (Kowalskitype) Horn clause logic, since failure in a normal logic system means something different from failure here.</Paragraph> <Paragraph position="4"> In narratives, failure needs to be recorded, since it is one source of &quot;interest&quot; in the resulting story; striving, failing, and striving again is a common occurrence in simple narratives. These failure points, and their consequences, have to be recorded in the story tree (whereas, in normal logic systems, failure points are invisible to the final result) and, furthermore, they restrict the choice of paths that can reasonably be expected to emanate from the point of failure. The failure mechanism is tailored for narratives involving entities exhibiting motivated behavior. Other text forms, such as technical or encyclopedia articles, would probably not require the failure mechanism.</Paragraph> <Paragraph position="5"> The underlying approach in BUILDTALE/ TELLTALE is that of a problem-solver, as was also true of Meehan's story-writer. A rule-base, organized as a hierarchy of story trees, is used to generate a particular, instantiated, story tree by an inference procedure augmented via the rule failure mechanism detailed in Section 3.2. Each instantiated tree is treated as a context, consisting of the events, objects, and their relationships, relating to a particular story. The facts and rules in the rule-base serve as a model for the possible states in the microworld formed by that story tree. These states are categorized using linguistic entities, such as SETTING, EPISODE, COMPLI-CATION, and RESOLUTION.</Paragraph> <Paragraph position="6"> The problem-solving approach, coupled with the story grammar concept, is a natural one for processing most forms of narratives. Analogous systems of rules could be used for processing other large text forms, although the categories involved would be different.</Paragraph> <Paragraph position="7"> Notes on the Appendices The rules are all written in a case predicate notation (Fillmore, 1968). The general form for such a predicate is (HEAD ARC1 VALUEq ... ARC In\] VALUE \[n\] ) The HEAD of a case predicate is either a verb or a noun form; because no formal lexicon was maintained for the TELLTALE/BUILDTALE program, verb forms were marked with an asterisk and objects were left unmarked. The ARCs are standard case relations, 146 American Journal of Computational Linguistics, Volume 6, Number 3-4, July-December 1980 Alfred Correira Computing Story Trees such as Agent, THeme, LOCation, INSTance, etc., although no attempt was made to be strictly correct linguistically with their every use, and a few relations were created for the sake of convenience. When a good arc name did not suggest itself, then an arbitrary arc name - R1, R2, etc. - was used instead. The VALUE can be either a verb form, an object, or another case predicate.</Paragraph> <Paragraph position="8"> The case predicates used in the program were written to enhance readability. For example, in the fairy-tale story (Appendix B), the case predicate</Paragraph> </Section> <Section position="14" start_page="0" end_page="0" type="metho"> <SectionTitle> (WANT*I TO POSSESSI A GEORGEI TH MARYI) </SectionTitle> <Paragraph position="0"> can be rendered into English as &quot;George wants to possess Mary&quot;. The sequence</Paragraph> </Section> <Section position="15" start_page="0" end_page="0" type="metho"> <SectionTitle> (GO*3 A GEORGEI TO IRVINGI) (SLAY*I A GEORGEI TH IRVINGI) (RESCUE*I A GEORGEI TH MARYI ) </SectionTitle> <Paragraph position="0"> can be rendered as &quot;George goes to Irving. George slays Irving. George rescues Mary.&quot;.</Paragraph> </Section> class="xml-element"></Paper>