File Information

File: 05-lr/acl_arc_1_sum/cleansed_text/xml_by_section/metho/93/e93-1010_metho.xml

Size: 25,373 bytes

Last Modified: 2025-10-06 14:13:18

<?xml version="1.0" standalone="yes"?>
<Paper uid="E93-1010">
  <Title>Head-driven Parsing for Lexicalist Grammars: Experimental Results</Title>
  <Section position="3" start_page="71" end_page="74" type="metho">
    <SectionTitle>
2 Two Head-driven Parsers
</SectionTitle>
    <Paragraph position="0"> In this section we present two head-driven parsing algorithms. Prolog code for simplifications of the algorithms is included in the appendix. For each grammar rule LHS --~ D1,..., Dh,..., Dn, it is assumed  that there is one daughter Dh which has been identified (by the grammar writer) as the head of that rule.</Paragraph>
    <Section position="1" start_page="72" end_page="72" type="sub_section">
      <SectionTitle>
2.1 Head-driven Chart Parsing
</SectionTitle>
      <Paragraph position="0"> The head-driven chart parser scans a sentence from left to right, storing items representing (partial) derivations in a chart. Items are of the form item(Cat, ToParse, BeginPos, EndPos). If ToParse is empty, the item is inactive, otherwise it is active. The parser is a bottom-up active chart parser without prediction, in which the addition of an active item based on a rule R is considered whenever an inactive item H is entered into the chart which matches the head of R. More precisely, if item(Cat, \[ \], B, E) is derived, and there is a rule LHS --* D1,...,Dh-1, Ca~,Dh+l, .... Dn and there are inactive items matching D1...Dh-1, ranging from B0 to B, an iIem(LHS, Dh+I...Dn,Bo, E) is added to the chart.</Paragraph>
      <Paragraph position="1"> If the leftmost daughter of each grammar rule is the head of the rule, then the head-driven chart parser reduces to an ordinary bottom-up active chart parser. If the rightmost daughter of each rule is the head, then the head-driven chart parser reduces to an inactive bottom-up chart parser (i.e. a breadth-first implementation of a shift-reduce parser).</Paragraph>
      <Paragraph position="2"> The head-driven strategy has a potential advantage over active bottom-up chart parsers, as it will assert substantially less active items for grammars that contain rules with an underspecified leftmost daughter (as in rule 1). In particular it avoids entering active items into the chart for which it is clear that the missing daughters cannot be derived.</Paragraph>
      <Paragraph position="3"> The head-driven parser also has a potential advantage over inactive bottom-up chart parsers for grammars that contain rules with an underspecified right-most daughter. An inactive chart parser must search in the chart for items matching the remaining daughter of such a rule each time an arbitrary category is derived. The head-driven parser on the other hand only needs to search for matching active items. The difference may lead to important efficiency improvements, especially if searching the chart is expensive. For example this is the case if the unification operation is expensive.</Paragraph>
    </Section>
    <Section position="2" start_page="72" end_page="73" type="sub_section">
      <SectionTitle>
2.2 Head-corner Parsing
</SectionTitle>
      <Paragraph position="0"> Head-corner parsing is a more radical approach to head-driven parsing in that it gives up the idea that parsing should proceed form left to right* Rather, the order of processing in a head-corner parser is bidirectional, starting from a head outward ('island'driven)* A head-corner parser can be thought of as a generalization of the left-corner parser \[Rosenkrantz and Lewis-II, 1970\]. As in the left-corner parser, the flow of information in a head-corner parser is both bottom-up and top-down.</Paragraph>
      <Paragraph position="1"> The basic idea of the head-corner parser is illustrated in figure 1. The parser selects the head of the string (1), and proves that this element is the head-corner of the goal. To this end, a rule is selected of which this lexical entry is the head daughter. Then the other daughters of the rule are parsed recursively in a bidirectional fashion: the daughters left of the head are parsed from right to left (starting from the head), and the daughters right of the head are parsed from left to right (starting from the head). The result is a slightly larger head-corner (2). This process repeats itself until a head-corner is constructed which dominates the whole string (3).</Paragraph>
      <Paragraph position="2"> Note that a rule is triggered only with a fully instantiated head-daughter. The 'generate-and-test' behavior observed for example 1 is avoided in a head-corner parser, because the rule is applied only if the vP is found, and hence Arg is instantiated. For example if At# = np(sg3, \[\], Snbj), the parser continues to search for a singular NP, and need not consider other categories.</Paragraph>
      <Paragraph position="3"> The head-relation holds between two categories h and m with respect to a grammar G iff G contains a rule with left hand side m and head daughter h. The relation 'head-corner' is the reflexive and transitive closure of the head relation. As in the left-corner' parser, a 'linking' table is maintained which represents important aspects of this head-corner relation. For some grammars this table simply represents the fact that the HEAD features of a category and its head-corner are shared* Note that unlike the left-corner parser, the head-corner parser may need to consider alternative words as a possible head-corner of a phrase, e.g. when parsing a sentence which contains several verbs* This problem is reduced because of the following three observations.</Paragraph>
      <Paragraph position="4"> The Quicksort Effect. A simplified version of the head-corner parser is provided in the appendix. The main difference with a simple version of the left-corner parser is -- apart from the head-driven se- null lection of rules -- the use of two pairs of indices, to implement the bidirectional way in which the parser proceeds through the string.</Paragraph>
      <Paragraph position="5"> Observe that each parse-goal in the left-corner parser is provided with a category and a left-most position. In the head-corner parser a parse-goal is provided either with a begin or end position (depending on whether we parse from the head to the left or to the right) but also with the extreme positions between which the category should be found.</Paragraph>
      <Paragraph position="6"> In general the parse predicate is thus provided with a category and two pair of indices. The first pair indicates the begin and end position of the category, the second pair indicates the extreme positions between which the first pair should lay. The following figure illustrates this point with an example:</Paragraph>
      <Paragraph position="8"> Suppose we found for a goal category s a possible head-corner v from position 5 to 6. In order to construct a complete tree s for this head-comer, a rule is selected which dictates that a category np should be parsed to the right, starting from position 6. To parse np, we predict the head-corner n between 7 and 8. Suppose furthermore that in order to connect n to np a rule is selected which requires a category adjp to the left of n. It will be clear that this category should end in position 7, but can never start before position 6. Hence the only candidate head-corner of this phrase is to be found between 6 and 7. This example illustrates that the use of two pairs of string positions reduces the number of possible head-corners for a given goal.</Paragraph>
      <Paragraph position="9"> String positions in head-corner table. Secondly, the head-corner table includes information about begin and end positions, following an idea in \[Sikkel and op den Akker, 1992\]. For example, if the goal is to parse a phrase with category sbar from position 7, and within positions 7 and 12, then for some grammars it can be concluded that the only possible head-corner for this goal should be a complementizer starting at position 7. Such information is compiled into the table as well. Hence the number of possible head-corners is reduced.</Paragraph>
      <Paragraph position="10"> Well-formed substring tables. Thirdly, the problem of multiple possible heads is reduced because a well-formed substring table is maintained.</Paragraph>
      <Paragraph position="11"> This is implemented by a memo-ization technique.</Paragraph>
      <Paragraph position="12"> This reduces the problem because even if the wrong head-corner is predicted for a given goal, it may turn out to be the case that the computations based on this wrong prediction may be useful later (each lexical category usually is the head of some projection). The well-formed substring table is implemented using an interesting generalization of the subsumption relation. A goal need not be investigated anymore if a more general goal has already been completed. It is easy to see that a certain goal with extreme positions 3 to 6 is more general than an otherwise identical goM with extreme positions 4 and 6.</Paragraph>
      <Paragraph position="13"> Head-driven vs. functor-drlven parsing. For categorial unification grammars in which we choose the functor as the head of a rule, the head-corner table is not going to be discriminating, because the grammar rules in such a grammar may simply be (in DCG notation, given appropriate operator definitions): 1</Paragraph>
      <Paragraph position="15"> As no information about word-class or morphology is stated in the rules, such information will not be found in the head-corner table.</Paragraph>
      <Paragraph position="16"> A possibly useful approach here is to compile some lexical information into the rule set, along the lines proposed in \[Bouma, 1991\]. In that paper it is proposed to compile lexical information into the rule-set, and parse with this 'enriched' rule-set. What seems to be most useful here, is to use this enriched grammar only for the compilation of the head-corner table. The parser then uses the general rule schemata themselves.</Paragraph>
      <Paragraph position="17"> However, given the usual analysis of modifiers as functors, even this approach may fail to yield an interesting head-corner table. Note that some analyses in categorial grammar prescribe that even in such cases certain morphological features are shared between the functor and its resulting value \[Bouma, 1993\].</Paragraph>
    </Section>
    <Section position="3" start_page="73" end_page="74" type="sub_section">
      <SectionTitle>
2.3 Comparison
</SectionTitle>
      <Paragraph position="0"> The important differences between both head-driven parsing algorithms can be summarized as follows (see Mso table 1). Firstly the head-driven chart parser proceeds from left-to-right as usual, whereas the head-corner parser proceeds bidirectionally. Secondly, the head-driven chart parser is an active chart parser (i.e. it also stores partial analyses of phrases);  the head-corner parser uses memo-ization of the parse predicate and the head-corner predicate (i.e.</Paragraph>
      <Paragraph position="1"> it only stores complete analyses of phrases, and partim analyses of head-corners).</Paragraph>
      <Paragraph position="2"> We also implemented an active head-corner chart parser along the lines of \[Sikkel and op den Akker, 1992\], but preliminary experiments indicate that (our implementation of) this parser is not useful for the grammars used in the experiments to be discussed in the next section. Note that it is not possible to incorporate top-down filtering in the head-driven chart parser in a simple way, because the necessary active items may not be available yet.</Paragraph>
      <Paragraph position="3"> Thirdly, although in both algorithms the way rules are applied is bottom-up in an important sense, there is an important flow of information in top-down direction in the head-corner parser. For grammars in which the head-corner table is discriminating, this should have important effects in practice. This expectation is confirmed in the experiments discussed in the next section.</Paragraph>
    </Section>
  </Section>
  <Section position="4" start_page="74" end_page="1474" type="metho">
    <SectionTitle>
3 The experiment
</SectionTitle>
    <Paragraph position="0"> This section describes experimental results for the parsing algorithms discussed above, in comparison with some obvious alternative strategies. The experiment consists of two parts.</Paragraph>
    <Paragraph position="1"> The first part of the experiment compares parsing strategies which proceed in a bottom-up fashion without the use of any top-down prediction. For CUG such parsers are suitable as no top-down information can be compiled from the rule schemata in a simple way. 2 It turns out that the head-driven bottom-up chart parser performs better than both an inactive and an active bottom-up chart parser, for a particular CUG for English. If the cost of unification is relatively high, the use of the head-driven chart parser pays off. If unification is cheap, then the inactive chart parser may still be the most efficient choice.</Paragraph>
    <Paragraph position="2"> The second part of the experiment concentrates on the comparison between the head-corner parser and the left-corner parser. Both of these parsers proceed in a bottom-up fashion, but use important top-down prediction. Such parsers are interesting for grammars in which interesting top-down information can be extracted from the rule schemata. It can be concluded from the experiment that for a specific lexicalist Definite Clause Grammar for Dutch the head-corner parser performs much better than the left-corner parser.</Paragraph>
    <Paragraph position="3"> These results indicate that at least for some grammars it is fruitful to apply parsing strategies which are sensitive to the linguistic notion 'head'.</Paragraph>
    <Paragraph position="4"> A CUG for English. The first grammar is a CUG for English which includes rules for leftward 2but see the discussion on head-driven vs. functor-driven parsing in the previous section.</Paragraph>
    <Paragraph position="5"> and rightward application and four construction specific rules to implement gap-threading. The grammar covers the basic sentence types (declaratives, WH and yes-no questions, and relative clauses) and a wide range of verbal and adjectival subcategorization types. PPs may modify nouns as well as vPs, leading to so-called PP-attachment ambiguities. The syntax of unbounded dependency constructions is treated rather extensively, including accounts of constraints on extraction, pied-piping, and the possibility of nested dependencies (as in which violin is this sonata easy to play on). The grammar is defined in terms of feature-structures, which may be combined using feature-unification. Furthermore, the treatment of nested dependencies uses lists of gaps. The interaction of these lists with certain lexical entries (such as easy) as well as the interaction of these lists with the checking of island-constraints requires that attempts at cyclic unifications must be detected and must fail. Therefore, the feature-unification procedure includes an occurs check.</Paragraph>
    <Paragraph position="6"> If the standard techniques for compiling a left-corner resp. a head-corner table are applied for this grammar, then, at best, the 'trivial' link would result, because the rule schemata do not specify any interesting information about morphological features etc.</Paragraph>
    <Paragraph position="7"> A lexicalist DCG for Dutch. This grammar is a definite clause grammar for Dutch, in which sub-categorization requirements are implemented using subcat-lists. The grammar handles topicalization using gap-threading. Verb-second is accounted for by a feature-based simulation of head-movement. The grammar analyses cross-serial dependencies by concatenating subcategorization lists (implemented as difference lists). As opposed to the CUG grammar, the second grammar uses actual 'empty elements' to introduce the traces corresponding to the topicalized phrases and verbs occurring in second position. Another difference with the first grammar is that first-order terms are used, rather than feature structures. The compilation of the left-corner resp. the head-corner table was done using the same restrictor. The left-corner table contained 94 entries, and the head-corner table contained 25 entries.</Paragraph>
    <Paragraph position="8"> The parsers. The parsers used in the experiment have a number of important properties in common (see table 1). First of all, they all use a chart to represent (partially or fully developed) analyses of substrings. Second, as categories are feature-structures or terms, rather than atomic symbols, special requirements are needed to ensure that the chart is always 'minimal'. That is, items are only added to the chart if no subsuming item exists, and, if an item is added to the chart, all more specific items are deleted from the chart. Finally, information about the derivational history of phrases is added to the chart in such a way that parse-trees can be recovered.</Paragraph>
    <Paragraph position="10"> This is done by using 'packed structures' (also called 'parse-forests') to obtain structure sharing in the case of ambiguities; semantic constraints (if present) are only evaluated when the syntactic analysis phase is completed. Our implementation of 'packing' follows that of \[Moore and Alshawi, 1992\], who implement it for a (unification-based) left-corner parser.</Paragraph>
    <Paragraph position="11"> Three different bottom-up chart parsers are implemented. The first one (hdc) is the head-driven chart parser presented above, in which the head of the rule is given by the grammar writer. The active chart parser (act) is the same as the head-chart parser, but now it is assumed that for each rule the left-most daughter is the head (active chart). The inactive chart parser (inact) is a version of the head-corner parser where each right-most daughter is assumed to be the head of the rule. Since the parser does not use active items, some (slight) simplifications of the head-driven chart parser were possible. The left-corner parser is a generalized version of the chart-based left-corner parser of \[Rosenkrantz and Lewis-II, 1970\]. As we also add items to construct parse-trees using 'packing', the resulting arser should be comparable to the CLE parser oore and Alshawi, 1992\]. The head-corner parser is the parser discussed in the previous section, a ZWe also implemented a generalized Earley parser.</Paragraph>
    <Paragraph position="12"> This parser was extremely slow for all sentences of both grammars.</Paragraph>
    <Paragraph position="13"> Results for CUG. One hundred arbitrarily chosen sentences (10 of length 3, 10 of length 6, etc.) were parsed, using the three pure bottom-up parsers (hde, inact, and act). The columns in table 2 give, for each sentence length (column 1), the average number of readings (column 2), the average number of items produced by hdc, and the average percentage of items produced by inaet and act, when compared with hdc (columns 3-6), the average time it took hdc to parse a sentence without recovering the different analyses and the average percentage of time needed for inact and act to do that (columns 7-9), and finally the average time it took to parse a sentence and recover all analysis trees for hde and the average percentage of time needed by inact and act to do that.</Paragraph>
    <Paragraph position="14"> The number of chart items illustrate clearly that hdc combines features of an inactive chart parser with that of an active chart-parser. Note that, in spite of the fact that English is mostly a head-initial language, act produces 80% more items than hdc, whereas inact almost produces 80% of the items produced by hdc. For languages which are predominantly head-final, the difference between act and hdc will probably be larger, whereas that between iaact and hdc should be smaller.</Paragraph>
    <Paragraph position="15"> The recognition times show that an active bottom-up chart parser is two-times slower for this grammar than a head-driven chart parser. The difference between the inactive chart parser and the head-driven  in the table has not been filled in.</Paragraph>
    <Paragraph position="16"> parser is less extreme, and is notably in favor of the head-driven parser only for relatively long and complex (in terms of number of analyses) sentences. Nevertheless, the difference is of enough significance to establish the superiority of a head-driven strategy in this case.</Paragraph>
    <Paragraph position="17"> The final three columns show that if recovery of parse trees is taken into account as well, the differences are much less extreme. The reason for this difference is simply that recovery (for which we used an Earley-style top-down algorithm which reconstructs explicit analysis trees on the basis of inactive items) may take up to eight times as long as doing parsing without recovery. Since the amount of time needed for recovery is (approximately) equal for all three parsers, this explains why the relative differences are much smaller in this case.</Paragraph>
    <Paragraph position="18"> The head-corner parser was applied to the same grammar and sentence set as well. It behaves much worse (up to 100 times as slow for recognition of 24words sentences) than the parsers listed in the tables due to the lack of guiding top-down information. The left-corner parser without top-down prediction reduces to the active chart parser.</Paragraph>
    <Paragraph position="19"> We also applied the same sentence set to a compiled version of the same CUG. In this compiled version first-order terms were used, rather than feature structures. Furthermore, we used ordinary Prolog unification on such terms rather than the previously mentioned feature unification including occurs check.</Paragraph>
    <Paragraph position="20"> This implied that we had to forbid multiple extractions in the compiled version of the grammar. Experiments indicate that in such cases the inactive chart parser performs consistently better than both the head-driven chart parser and the active chart parser. This should not come as a surprise given the discussion in section 2.1 where we expected the head-driven chart parser to be useful for grammars with an 'expensive' unification operation.</Paragraph>
    <Paragraph position="21"> Results for the DCG. The next table encodes the results for the Dutch grammar (cf. table 3).</Paragraph>
    <Paragraph position="22"> Again, one hundred sentences were chosen (ten of three words, ten of six words, etc).</Paragraph>
    <Paragraph position="23"> The head-corner parser improved with a well-formed substring table and packing beats the bottom-up chart parsers. This is explained by the fact that these parsers proceed strictly bottom-up, whereas the left-corner and head-corner parser employ both top-down and bottom-up information.</Paragraph>
    <Paragraph position="24"> The top-down information is available through a left-corner resp. head-corner table, which turn out to be quite informative for this grammar.</Paragraph>
    <Paragraph position="25"> The head-corner parser performs considerably better than the left-corner parser on average, especially if we only take the recognition phase into account.</Paragraph>
    <Paragraph position="26"> For longer sentences the differences are somewhat less extreme than for shorter sentences. This difference is due to the fact that the left-corner parser seems somewhat better suited for grossly ambiguous sentences. Furthermore, the number of items used for the representation of parse trees is not the same for the left-corner and head-corner parser. For ambiguous sentences the head-corner parser produces more useless items, in the sense that such items car never be used for the construction of an actual parse tree. As a consequence, it is more expensive to recover the parse trees based on this representation, than it is for the recovery of parse trees based on the smaller representation built by the left-corner parser. A few numbers for three typical (long) sentences are shown in table 4.</Paragraph>
    <Paragraph position="27"> This is a somewhat puzzling result. Useless items are asserted only in case the parser is following a dead-end. However, the fact that the number of useless items is larger for the head-corner parser than for the left-corner parser implies that the head-corner parser follows more dead-ends, yet the head-corner parser is much faster during the recognition phase.</Paragraph>
    <Paragraph position="28"> A possible explanation for this puzzling fact may be the overhead involved in keeping track of the ac- null sentences.</Paragraph>
    <Paragraph position="29"> tive items in the left-corner parser whereas no active items are asserted for the head-corner parser.</Paragraph>
    <Paragraph position="30"> Clearly for grammars with rules that contain many daughters (unlike the grammar under consideration) the use of active items may start to pay off.</Paragraph>
    <Paragraph position="31"> Note that we also implemented a version of the head-corner parser that asserts less useless items by delaying the assertion of items until a complete head-corner has been found. However, given the fact that this technique leads to a more complex implementation of the memo-ization of the head-corner relation, it turned out that this immediately leads to longer recognition times, and an overall worse behavior.</Paragraph>
  </Section>
class="xml-element"></Paper>
Download Original XML