File Information
File: 05-lr/acl_arc_1_sum/cleansed_text/xml_by_section/metho/01/w01-0805_metho.xml
Size: 18,135 bytes
Last Modified: 2025-10-06 14:07:39
<?xml version="1.0" standalone="yes"?> <Paper uid="W01-0805"> <Title>A Meta-Algorithm for the Generation of Referring Expressions</Title> <Section position="4" start_page="0" end_page="0" type="metho"> <SectionTitle> 3 Outline of the algorithm </SectionTitle> <Paragraph position="0"> In this section we give a high-level sketch of the algorithm. The algorithm (called make-ReferringExpression) consists of two main components, a subgraph construction algorithm (called findGraph) and a subgraph isomorphism testing algorithm (called matchGraphs). We assume that a scene graph a50 a15a152a51a54a53a153a23a57a56a59a58 is given. The algorithm systematically tries all relevant subgraphs a73 of the scene graph by starting with the subgraph containing only the node a92 (the target object) and expanding it recursively by trying to add edges from a50 which are adjacent to the subgraph a73 constructed so far. In this way we know that the results will be a connected subgraph. We refer to this set of adjacent edges as the</Paragraph> <Paragraph position="2"> The algorithm returns the cheapest distinguishing subgraph a73 which refers to a92 , if such a distinguishing graph exists, otherwise it returns the empty graph a154a48a15a34a51a149a49a89a23a25a49a29a58 .</Paragraph> <Section position="1" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 3.1 Cost functions </SectionTitle> <Paragraph position="0"> We use cost functions to guide the search process and to give preference to some solutions over others. If a73 a15a152a51a54a53 a74 a23a57a56 a74 a58 is a subgraph of a50 , then the costs of a73 , notation a133 a99 a73a130a101 , are given by summing over the costs associated with the nodes and edges of H. Formally: This assumption helps reducing the search space substantially, since extensions of subgraphs with a cost greater than the best subgraph found so far can safely be ignored. The costs of the empty, undefined graph are infinite, i.e. a133 a99 a154a169a101a97a15a171a170 .</Paragraph> </Section> <Section position="2" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 3.2 Worked example </SectionTitle> <Paragraph position="0"> We now illustrate the algorithm with an example.</Paragraph> <Paragraph position="1"> Suppose the scene graph a50 is as given in Figure 2, and that we want to generate a referring expression for object a19a72a21 in this graph. Let us assume for the sake of illustration that the cost function is defined in such a way that adding a node or an edge always costs 1 point. Thus: for each a92a172a70a173a53a81a80 and for each a164 a70a18a56a77a74 : a133 a99 a92a93a101a63a15 a133 a99a165a164 a101a174a15 a175 .</Paragraph> <Paragraph position="3"/> <Paragraph position="5"> process for a19a72a21 .</Paragraph> <Paragraph position="6"> (In the next section we describe a number of more interesting cost functions and discuss the impact these have on the output of the algorithm.) We call the function makeReferringExpression (given in Figure 5) with a19a72a21 as parameter. In this function the variable bestGraph (for the best solution found so far) is initialized as the empty graph and the variable a73 (for the distinguishing subgraph under construction) is initialized as the graph containing only node a19a72a21 ((i) in Figure 6). Then the function findGraph (see also Figure 5) is called, with parameters a19a72a21 , bestGraph and a73 . In this function, first it is checked whether the costs of a73 (the graph under construction) are higher than the costs of the bestGraph found so far. If that is the case, it is not worth extending a73 since, due to the monotonicity constraint, it will never end up being cheaper than the current bestGraph. The initial value of bestGraph is the empty, undefined graph, and since its costs are astronomically high, we continue. Then the set of distractors (the objects from which the intended referent should be distinguished, Dale & Reiter 1995) is calculated.</Paragraph> <Paragraph position="7"> In terms of the graph perspective this is the set of nodes in the scene graph a50 (other then the target node a92 ) to which the graph a73 refers. It is easily seen that the initial value of a73 , i.e., (i) in Figure 6, refers to every node in a50 . Hence, as one would expect, the initial set of distractors is a50 a104 nodes a212 a17a20a19a22a21a24a31 . Next we check whether the current set of distractors is empty. If so, we have managed to find a distinguishing graph, which is subsequently stored in the variable bestGraph. In this first iteration, this is obviously not the case and we continue, recursively trying to extend a73 by adding adjacent (neighboring) edges until either a distinguishing graph has been constructed (all distractmatchGraphs(a92 , a73 , a94 , a50 ) a17 if a73 .edges(a92 , a92 ) a196a60 a50 .edges(a94 , a94 ) then return false fi;</Paragraph> <Paragraph position="9"> if a194 matching a194 a15 a194a73 a194 then return true fi; if a214 a15a198a49 then return false fi; choose a fresh, unmatched a215 from a214 ;</Paragraph> <Paragraph position="11"> if a217 is a valid extension of the mapping ors are ruled out) or the costs of a73 exceed the costs of the bestGraph found so far. While bestGraph is still the empty set (i.e., no distinguishing graph has been found yet), the algorithm continues until a73 is a distinguishing graph. Which is the first distinguishing graph to be found (if one or more exist) depends on the order in which the adjacent edges are tried. Suppose for the sake of argument that the first distinguishing graph to be found is (ii) in Figure 6. This graph is returned and stored in bestGraph. The costs associated with this graph are 5 points (two nodes and three edges). At this stage in the generation process only graphs with lower costs are worth investigating, which yields a drastic reduction of the search space. In fact, there are only a few distinguishing graphs which cost less. After a number of iterations the algorithm will find the cheapest solution (given this particular, simple definition of the cost function), which is (iii) in Figure 6.</Paragraph> </Section> <Section position="3" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 3.3 Subgraph Isomorphism testing </SectionTitle> <Paragraph position="0"> gorithm which tests for subgraph isomorphism, matchGraphs. This function is called each time the distractor set is calculated. It tests whether the pair a99 a92a93a23a57a73a130a101 can refer to a99 a94a76a23 a50 a101 , or put differently, it checks whether there exists an isomorphism a86 such that a73 a126 a128 a50 with a86a105a104a106a92a66a15a220a94 . The function matchGraphs first determines whether the looping edges starting from node a92 (i.e., the properties of a92 ) match those of a94 . If not (e.g., a92 is a dog and a94 is a doghouse), we can immediately discard the matching. Otherwise we start with the matching a86a105a104a106a92a132a15a71a94 , and expand it recursively. Each recursion step a fresh and as yet unmatched nodea215 from a73 is selected which is adjacent to one of the nodes in the current matching. For each a215 we calculate the set a216 of possible nodes in a50 to which a215 can be matched. This set consist of all the nodes in a50 which have the same looping edges as a215 and the same edges to and from other nodes in the domain of the current matching function a86 : The matching can now be extended with a86a105a104a106a215a225a15a198a217 , for a217a226a70 a216 . The algorithm then branches over all these possibilities. Once a mapping a86 has been found which has exactly as much elements as a73 has nodes, we have found a subgraph isomorphism. If there are still unmatched nodes in a73 or if all possible extensions with a node a215 have been checked and no matching could be found, the test for subgraph isomorphism has failed.</Paragraph> </Section> <Section position="4" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 3.4 A note on the implementation </SectionTitle> <Paragraph position="0"> The basic algorithm outlined in Figures 5 and 7 has been implemented in Java. Various optimizations increase the efficiency of the algorithm, as certain calculations need not be repeated each iteration (e.g., the set a50 .neighbors(a73 )). In addition, the user has the possibility of specifying the cost function in a way which he or she sees fit.</Paragraph> </Section> </Section> <Section position="5" start_page="0" end_page="0" type="metho"> <SectionTitle> 4 Search methods and cost functions </SectionTitle> <Paragraph position="0"> Arguably, the algorithm outlined above is a metaalgorithm, since by formulating the cost function in certain ways we can simulate various algorithms known from the generation literature.</Paragraph> <Section position="1" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 4.1 Full (relational) Brevity Algorithm </SectionTitle> <Paragraph position="0"> The algorithm described in the previous section can be seen as a generalization of Dale's (1992) Full Brevity algorithm, in the sense that there is a guarantee that the algorithm will output the shortest possible description, if one exists. It is also an extension of the Full Brevity algorithm, since it allows for relational descriptions, as does the Dale & Haddock (1991) algorithm. The latter algorithm has a problem with infinite recursions; in principle their algorithm could output descriptions like &quot;the dog in the doghouse which contains a dog which is in a doghouse which ...etc.&quot; Dale & Haddock propose to solve this problem by stipulating that a property or relation may only be included once. In the graph-based model described above the possibility of such infinite recursions does not arise, since a particular edge is either present in a graph or not.a26 a227 Notice incidentally that Dale's (1992) Greedy Heuristic algorithm can also be cast in the graph framework, by sorting edges on their descriptive power (measured as a count of the number of occurrences of this particular edge in the scene graph). The algorithm then adds the most discriminating edge first (or the cheapest, if there are various equally distinguishing edges) and repeats this process until a distinguishing graph is found.</Paragraph> </Section> <Section position="2" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 4.2 Incremental Algorithm </SectionTitle> <Paragraph position="0"> Dale & Reiter's (1995) Incremental Algorithm, generally considered the state of the art in this field, has the following characteristic properties.</Paragraph> <Paragraph position="1"> (1) It defines a list of preferred attributes, list null ing the attributes which human speakers prefer for a certain domain. For example, when discussing domestic animals, speakers usually first describe the &quot;type&quot; of animal (dog, cat), before absolute properties such as &quot;color&quot; are used. If that still is not sufficient to produce a distinguishing description, relative properties such as &quot;size&quot; can be included. Thus, the list of preferred attributes for this particular domain could be a51 type, color, size a58 . The Incremental Algorithm now simply iterates through this list, adding a property if it rules out any distractors not previously ruled out. (2) The algorithm always includes the &quot;type&quot; attribute, even if it is not distinguishing. And (3) the algorithm allows subsumption hierarchies on certain attributes (most notably for the &quot;type&quot; attribute) stating things like a fox terrier is a dog, and a dog is an animal. In such a hierarchy we can specify what the basic level value is (in this case it is dog). Dale & Reiter claim that there is a general preference for basic level values, and hence their algorithm includes the basic level value of an attribute, unless values subsumed by the basic level value rule out more distractors.</Paragraph> <Paragraph position="2"> These properties can be incorporated in the graph framework in the following way. (1) The list of preferred attributes can easily be modelled using the cost function. All &quot;type&quot; edges should be cheaper than all other edges (in fact, they could be for free), and moreover, the edges corresponding to absolute properties should cost less than those corresponding to relative ones. This gives us exactly the effect of having preferred attributes.</Paragraph> <Paragraph position="3"> (2) It also implies that the &quot;type&quot; of an object is always included if it is in any way distinguishing.</Paragraph> <Paragraph position="4"> That by itself does not guarantee that type is always is included. The most principled and efficient way to achieve that would be to reformulate the findGraph algorithm in such a way that the &quot;type&quot; loop is always included. (Given such a minor modification, the algorithm described in the previous section would output (iii) from Figure 3 instead of (iii) from Figure 6 when applied to a19 a21 .) Such a general modification might be undesirable from an empirical point of view however, since in various domains it is very common to not include type information, for instance when the domain contains only objects of the same type (see van der Sluis & Krahmer 2001). (3) The subsumption hierarchy can be modelled in the same way as preferred attributes are: for a given attribute, the basic level value should have the lowest costs and the values farthest away from the basic level value should have the highest costs. This implies that adding an edge labeled dog is cheaper than adding an edge labeled chihuahua, unless more (or more expensive) edges are needed to build a distinguishing graph including dog than are required for the graph including chihuahua. Assuming that the scene representation is well-defined, the algorithm never outputs a graph which contains both dog and chihuahua, since there will always be a cheaper distinguishing graph omitting one of the two edges.</Paragraph> <Paragraph position="5"> So, we can recast the Incremental Algorithm quite easily in terms of graphs. Note that the original Incremental Algorithm only operates on properties, looped edges in graph terminology. It is worth stressing that when all edges in the scene graph are of the looping variety, testing for sub-graph isomorphism becomes trivial and we regain polynomial complexity. However, the above graph-theoretical formalization of the Incremental Algorithm does not fully exploit the possibilities offered by the graph framework and the use of cost functions. First, from the graph-theoretical perspective the generation of relational descriptions poses no problems whatsoever, while the incremental generation of relational descriptions is by no means trivial (see e.g., Theune 2000, Krahmer & Theune 1999). In fact, while it could be argued to some extent that incremental selection of properties is psychologically plausible, this somehow seems less plausible for incremental generation of relational extensions.a28 Notice that the use of a a38 As Dale & Reiter (1995:248) point out, redundant properties are not uncommon. That is: in certain situations people may describe an object as &quot;the white bird&quot; even though the simpler &quot;the bird&quot; would have been sufficient (cf. Pechmann 1989, see also Krahmer & Theune 1999 for discussion). However, a similar argument seems somewhat farfetched when applied to relations. It is unlikely that someone would describe an object as &quot;the dog next to the tree in front of the garage&quot; in a situation where &quot;the dog in front of the garage&quot; would suffice.</Paragraph> <Paragraph position="6"> cost function to simulate subsumption hierarchies for properties carries over directly to relations; for instance, the costs of adding a edge labeled next to should be less than those of adding one labeled left of or right of. Hence, next to will be preferred, unless using left of or right of has more discriminative power. Another advantage of the way the graph-based algorithm models the list of preferred attributes is that more fine-grained distinctions can be made than can be done in the Incremental Algorithm. In particular, we are not forced to say that values of the attribute &quot;type&quot; are always preferred over values of the attribute &quot;color&quot;. Instead we have the freedom to assign edges labeled with a common type value (e.g., dog) a lower cost than edges labeled with uncommon colors (such as Vandyke-brown), while at the same time edges labeled with obscure type values, such as polish owczarek nizinny sheepdog, can be given a higher cost than edges labeled with common colors such as brown.</Paragraph> </Section> <Section position="3" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 4.3 Stochastic cost functions </SectionTitle> <Paragraph position="0"> One of the important open questions in natural language generation is how the common, rule-based approaches to generation can be combined with recent insights from statistical NLP (see e.g., Langkilde & Knight 1998, Malouf 2000 for partial answers). Indeed, when looking at the Incremental Algorithm, for instance, it is not directly obvious how statistical information can be integrated in the algorithm. Arguably, this is different when we have cost functions. One can easily imagine deriving a stochastic cost function from a sufficiently large corpus and using it in the graph-theoretical framework (the result looks like but is not quite a Markov Model). As a first approximation, we could define the costs of adding an edge Thus, properties which occur frequently are cheap, properties which are relatively rare are expensive. In this way, we would probably derive that dog is indeed less expensive than Vandyke brown and that brown is less expensive than polish owczarek nizinny sheepdog.</Paragraph> </Section> </Section> class="xml-element"></Paper>