<?xml version="1.0" standalone="yes"?>
<Paper uid="P06-1033">
  <Title>Graph Transformations in Data-Driven Dependency Parsing</Title>
  <Section position="4" start_page="257" end_page="258" type="intro">
    <SectionTitle>
2 Background
</SectionTitle>
    <Paragraph position="0"/>
    <Section position="1" start_page="257" end_page="257" type="sub_section">
      <SectionTitle>
2.1 Dependency Graphs
</SectionTitle>
      <Paragraph position="0"> The basic idea in dependency parsing is that the syntactic analysis consists in establishing typed, binary relations, called dependencies, between the words of a sentence. This kind of analysis can be represented by a labeled directed graph, defined as follows:  * Let R = {r1,...,rm} be a set of dependency types (arc labels).</Paragraph>
      <Paragraph position="1"> * A dependency graph for a string of words</Paragraph>
      <Paragraph position="3"> - W is the set of nodes, i.e. word tokens in the input string, ordered by a linear precedence relation &lt;.</Paragraph>
      <Paragraph position="4">  - A is a set of labeled arcs (wi,r,wj), wi, wj [?] W, r [?] R.</Paragraph>
      <Paragraph position="5"> * A dependency graph G = (W,A) is well null formed iff it is acyclic and no node has an in-degree greater than 1.</Paragraph>
      <Paragraph position="6"> We will use the notation wi r- wj to symbolize that (wi,r,wj) [?] A, where wi is referred to as the head and wj as the dependent. We say that an arc is projective iff, for every word wj occurring between wi and wk (i.e., wi &lt; wj &lt; wk or wi &gt; wj &gt; wk), there is a path from wi to wj. A graph is projective iff all its arcs are projective. Figure 1 shows a well-formed (projective) dependency graph for a sentence from the Prague</Paragraph>
    </Section>
    <Section position="2" start_page="257" end_page="257" type="sub_section">
      <SectionTitle>
Dependency Treebank.
2.2 Coordination and Verb Groups
</SectionTitle>
      <Paragraph position="0"> Dependency grammar assumes that syntactic structure consists of lexical nodes linked by binary dependencies. Dependency theories are thus best suited for binary syntactic constructions, where one element can clearly be distinguished as the syntactic head. The analysis of coordination is problematic in this respect, since it normally involves at least one conjunction and two conjuncts.</Paragraph>
      <Paragraph position="1"> The verb group, potentially consisting of a whole chain of verb forms, is another type of construction where the syntactic relation between elements is not clear-cut in dependency terms.</Paragraph>
      <Paragraph position="2"> Several solutions have been proposed to the problem of coordination. One alternative is to avoid creating dependency relations between the conjuncts, and instead let the conjuncts have a direct dependency relation to the same head (Tesni`ere, 1959; Hudson, 1990). Another approach is to make the conjunction the head and let the conjuncts depend on the conjunction. This analysis, which appears well motivated on semantic grounds, is adopted in the FGD framework and will therefore be called Prague style (PS). It is exemplified in figure 1, where the conjunction a (and) is the head of the conjuncts bojovnost'i and tvrdost'i. A different solution is to adopt a more hierarchical analysis, where the conjunction depends on the first conjunct, while the second conjunct depends on the conjunction. In cases of multiple coordination, this can be generalized to a chain, where each element except the first depends on the preceding one. This more syntactically oriented approach has been advocated notably by Mel'Vcuk (1988) and will be called Mel'Vcuk style (MS). It is illustrated in figure 2, which shows a transformed version of the dependency graph in figure 1, where the elements of the coordination form a chain with the first conjunct (bojovnost'i) as the topmost head. Lombardo and Lesmo (1998) conjecture that MS is more suitable than PS for incremental dependency parsing.</Paragraph>
      <Paragraph position="3"> The difference between the more semantically oriented PS and the more syntactically oriented MS is seen also in the analysis of verb groups, where the former treats the main verb as the head, since it is the bearer of valency, while the latter treats the auxiliary verb as the head, since it is the finite element of the clause. Without questioning the theoretical validity of either approach, we can again ask which analysis is best suited to achieve high accuracy in parsing.</Paragraph>
    </Section>
    <Section position="3" start_page="257" end_page="258" type="sub_section">
      <SectionTitle>
2.3 PDT
</SectionTitle>
      <Paragraph position="0"> PDT (HajiVc, 1998; HajiVc et al., 2001) consists of 1.5M words of newspaper text, annotated in three layers: morphological, analytical and tectogrammatical. In this paper, we are only concerned with the analytical layer, which contains a surface-syntactic dependency analysis, involving a set of 28 dependency types, and not restricted to projective dependency graphs.1 The annotation follows FGD, which means that it involves a PS analysis of both coordination and verb groups. Whether better parsing accuracy can be obtained by transforming  this to MS is one of the hypotheses explored in the experimental study below.</Paragraph>
    </Section>
    <Section position="4" start_page="258" end_page="258" type="sub_section">
      <SectionTitle>
2.4 MaltParser
</SectionTitle>
      <Paragraph position="0"> MaltParser (Nivre and Hall, 2005; Nivre et al., 2006) is a data-driven parser-generator, which can induce a dependency parser from a treebank, and which supports several parsing algorithms and learning algorithms. In the experiments below we use the algorithm of Nivre (2003), which constructs a labeled dependency graph in one left-to-right pass over the input. Classifiers that predict the next parser action are constructed through memory-based learning (MBL), using the TIMBL software package (Daelemans and Van den Bosch, 2005), and support vector machines (SVM), using</Paragraph>
    </Section>
  </Section>
class="xml-element"></Paper>