Static Oracles

Recall that the job of the oracle is to create a sequence of transitions that can derive a given dependency tree. To this end, an oracle takes a current state and a dependency tree corresponding to the sentence as input and returns an applicable transition. Repeatedly applying this oracle, starting from an initial state until it reaches a terminal one will result

Algorithm 4.1 Generic static oracle Input: State s, dependency tree y

Output: The next applicable transition, given s and y 1: function NEXTTRANSITION(s, y)

2: if CANLEFTARC(s, y)then 3: return LeftArc

4: else if CANRIGHTARC(s, y)then 5: return RightArc

6: else if CANSWAP(s, y)then 7: return Swap

8: else

9: return Shift

in a transition sequence for a given sentence and tree. A generic view on static oracles is given in Algorithm 4.1. A number of predicates are sequentially tested in a pre-defined order, and the action matching the first true predicate is returned. If all else fails, Shift is the fallback option. The semantics of the predicates for LeftArc and RightArc are rather straightforward: if the two top tokens should be connected through an arc and the mod- ifier among the two has already collected all its own modifiers, then the corresponding transition can be applied.

We will shortly turn to the Swap transition, but we first note that if the oracle is ap- plied to a projective tree, the test for Swap (lines 6 and 7) can be skipped. In this case, the oracle is de facto an oracle for the ArcStandard system. An application of the oracle to the example sentence from Figure 4.1 is shown in Figure 4.4. To ease the interpretation of the derivation, the figure uses a slightly different notation for tokens on the stack and buffer, where the surface forms of the words are used and their indices in the sentence are used as subscripts. Every row denotes a state, and the stack and buffer on each row correspond to the state after application of the transition on the same row.

Testing for Swap is a bit more complicated and requires an auxiliary ordering of the input tokens called the projective order. The projective order is obtained by making an in-order traversal over the nodes in the dependency tree, and we will denote this order- ing by ≺PROJ. If the tokens in the input sentence are rearranged according to the pro-

jective order, the corresponding dependency tree becomes projective. For instance, the non-projective example from Figure 4.2 is given in Figure 4.5 with the tokens reordered according to the projective order.

State Transition Stack Buffer Arc Added

s0 [ROOT0] [Die1, ..., .7]

s1 Shift [ROOT0, Die1] [Rebellen2, ..., .7]

s2 Shift [ROOT0, Die1, Rebellen2] [haben3, ..., .7]

s3 LeftArcNK [ROOT0, Rebellen2] [haben3, ..., .7] Rebellen2

NK_→Die

1

s4 Shift [ROOT0, Rebellen2, haben3] [kein4, ..., .7]

s5 LeftArcSB [ROOT0, haben3] [kein4, ..., .7] haben3

SB

→Rebellen2

s6 Shift [ROOT0, haben3, kein4] [L¨osegeld5, ..., .7]

s7 Shift [ROOT0, ..., kein4, L¨osegeld5] [verlangt6, .7]

s8 LeftArcNK [ROOT0, haben3, L¨osegeld5] [verlangt6, .7] L¨osegeld5

NK_→kein

4

s9 Shift [ROOT0, ..., L¨osegeld5, verlangt6] [.7]

s10 LeftArcOA [ROOT0, haben3, verlangt6] [.7] verlangt6

OA

→L¨osegeld5

s11 RightArcOC [ROOT0, haben3] [.7] haben3

OC

→verlangt6

s12 Shift [ROOT0, haben3, .7] [ ]

s13 RightArc– [ROOT0, haben3] [ ] haben3

–

→.7

s14 RightArc– [ROOT0] [ ] ROOT0

–

→haben3

Figure 4.4: Oracle derivation for parsing the sentence from Figure 4.1.

ROOT That ’s they ’re what after t0 t1 t2 t4 t5 t3 t6 nsubj root pobj nsubj ccomp prep

Figure 4.5: The dependency tree from Figure 4.2 with tokens reordered according to the projective order.

stack are in reverse projective order. That is, when u0 ≺PROJ u1. In the example from

Figure 4.2, this means that Swap is applicable when u0 is either of they or ’re and u1

is what. An example derivation using Algorithm 4.1 on the sentence from Figure 4.2 is shown in Figure 4.6. The derivation starts out by applying two Shift and then a LeftArc, constructing the first arc between That and ’s. It then continues to Shift what onto the stack. However, since what belongs further to the right in the projective order, the system now needs to start using the Swap transition to move what closer to its governor after. This is accomplished by a sequence of Shift and Swap transitions, after which what can be attached to its governor.

While this oracle is able to produce a transition sequence for any non-projective sen- tence, it is very generous with the amount of Swap transitions. In fact, the example sen- tence just seen can be successfully parsed using only a single Swap transition. The pri- mary observation is that the oracle applies Swap as soon as it is applicable, even though a Shift transition may also be applicable. We therefore call this oracle EAGER. Drawing

State Transition Stack Buffer Arc Added

s0 [ROOT0] [That1, ..., after6]

s1 Shift [ROOT0, That1] [’s2, ..., after6]

s2 Shift [ROOT0, That1, ’s2] [what3, ..., after6]

s3 LeftArcNSUBJ [ROOT0, ’s2] [what3, ..., after6] ’s2 NSUBJ

→ That1

s4 Shift [ROOT0, ’s2, what3] [they4, ..., after6]

s5 Shift [ROOT0, ..., what3, they4] [’re5, after6]

s6 Swap [ROOT0, ’s2, they4] [what3, ..., after6]

s7 Shift [ROOT0, ..., they4, what3] [’re5, after6]

s8 Shift [ROOT0, ..., what3, ’re5] [after6]

s9 Swap [ROOT0, ..., they4, ’re5] [what3, after6]

s10 LeftArcNSUBJ [ROOT0, ’s2, ’re5] [what3, after6] ’re5 NSUBJ

→ they4

s11 Shift [ROOT0, ..., ’re5, what3] [after6]

s12 Shift [ROOT0, ..., what3, after6] [ ]

s13 LeftArcPOBJ [ROOT0, ..., ’re5, after6] [ ] after6 POBJ

→ what3

s14 RightArcPREP [ROOT0, ’s2, ’re5] [ ] ’re5 PREP_{→ after}

6

s15 RightArcCCOMP [ROOT0, ’s2] [ ] ’s2

CCOMP

→ ’re5

s16 RightArcROOT [ROOT0] [ ] ROOT0

ROOT_{→ ’s} 2

Figure 4.6: Example oracle derivation for the dependency tree from Figure 4.2 using the EAGER oracle.

upon this observation, Nivre et al. (2009) present an improved oracle that considerably reduces the number of swaps. Their oracle is based on the same basic structure as the one in Algorithm 4.1, but the semantics of CANSWAPare redefined. The oracle relies on a no- tion of maximal projective components (MPCs). In addition to requiring that u0 and u1

appear in the wrong order with respect to the projective order, this oracle also requires u0

and b0not to be part of the same MPCs. MPCs are defined as the connected components,

i.e., the resulting subtrees obtained by running the oracle parser without Swap until it hits a dead end. Nivre et al. (2009) show empirically that this oracle substantially reduces the number of Swap transitions, sometimes by up to 80%. The corresponding derivation for the non-projective example from Figure 4.2 is listed in Figure 4.7. This oracle does not admit the first Swap transition from EAGER. Instead, it continues by shifting ’re and then attaching they through a LeftArc. That is, the use of the Swap transition is postponed and the two intervening tokens between the modifier and governor of the non-projective arc are reduced to a subtree, removing the need for one extra Swap and Shift. As this oracle tries to postpone Swap transitions when possible, we will refer to it as LAZY.