Docs: "Let PRONOUN VERB" inconsistencies

[brendano]

We noticed these recently in the UD_English treebank... (version 1.4)

For "let PRONOUN VERB", it seems to always have either xcomp(let,VERB) or ccomp(let,VERB).

But for some cases there's

• dobj(let, PRONOUN)

and in others

• nsubj(VERB, PRONOUN)

I could see arguments either way of course. Here are two examples for "let me know" with the inconsistency. Or is there a consistency we're not seeing?

These are from grep -n ... | cut -f1,2,7,8 so the line numbers are included.

en-ud-dev.conllu:5363:1 Let     0       root
en-ud-dev.conllu-5364-2 me      3       nsubj
en-ud-dev.conllu-5365-3 know    1       ccomp

en-ud-train.conllu:71801:1      Let     0       root
en-ud-train.conllu-71802-2      me      1       dobj
en-ud-train.conllu-71803-3      know    1       ccomp

and some others

en-ud-train.conllu-53321-3      please  4       discourse
en-ud-train.conllu:53322:4      let     0       root
en-ud-train.conllu-53323-5      us      6       nsubj
en-ud-train.conllu-53324-6      know    4       ccomp

en-ud-train.conllu-85530-7      please  8       discourse
en-ud-train.conllu:85531:8      let     0       root
en-ud-train.conllu-85532-9      me      8       dobj
en-ud-train.conllu-85533-10     know    8       xcomp

and a more complex nsubj(VERB,PRONOUN) example (where VERB is replaced by predicate due to copula handling):

en-ud-train.conllu:103715:1     Let     0       root
en-ud-train.conllu-103716-2     your    3       nmod:poss
en-ud-train.conllu-103717-3     mind    9       nsubj
en-ud-train.conllu-103718-4     and     3       cc
en-ud-train.conllu-103719-5     body    3       conj
en-ud-train.conllu-103720-6     be      9       cop
en-ud-train.conllu-103721-7     totally 9       advmod
en-ud-train.conllu-103722-8     at      9       case
en-ud-train.conllu-103723-9     peace   1       ccomp
en-ud-train.conllu-103724-10    .       1       punct

[brendano]

Oh yeah I guess the construction actually is "Let NP VERB"

[nschneid]

"Make" can also have this argument structure, right? "let/make them eat cake"

Unlike classic examples of control (e.g., "want them to eat cake") the second verb is not preceded by infinitival "to". Nevertheless, xcomp seems to fit.

("Let X know" is an idiom, but that probably doesn't affect its syntactic analysis.)

[brendano]

On Friday, December 9, 2016, Nathan Schneider [e-mail]
wrote:

"Make" can also have this argument structure, right? "let/make them eat
cake"

Unlike classic examples of control (e.g., "want to eat cake") the second
verb is not preceded by infinitival "to". Nevertheless, xcomp
http://universaldependencies.org/u/dep/xcomp.html seems to fit.

this interp has obj(let/make, them)
and not nsubj(eat, them)
?

--
-brendan [mobile]

[nschneid]

Judging by this query of "encourage", the pronoun is the dobj of the matrix verb. I will add this to the documentation of xcomp.

[nschneid]

FYI, dobj is renamed to obj in UD v2.

[amir-zeldes]

I agree with @nschneid (I think he's saying it is nsubj(eat,them)). What's strange is I remembered the Stanford Parser outputs the structure @nschneid is suggesting, but with ccomp instead of xcomp, despite the non-subject pronoun being governed as a subject in the subordinate clause. I was just able to reproduce it with the Stanford parser and its conversion from gold PTB data, so it seems intentional:

root(ROOT-0, Let-1)
nsubj(eat-3, me-2)
ccomp(Let-1, eat-3)
dobj(eat-3, cake-4)

And this is the result of converting:

(ROOT
  (S
    (VP (VB Let)
      (S
        (NP (PRP me))
        (VP (VB eat)
          (NP (NN cake)))))
    (. .)))

Replacing 'let' with 'make' produces the same parse.

[nschneid]

No, I meant dobj(make, them). I've updated http://universaldependencies.org/u/dep/xcomp.html to reflect what I understand the convention to be based on the data. AFAIK this wasn't listed as one of the changes for v2.

[jnivre]

This looks like inconsistencies and/or conversion errors to me. It is definitely not a change in v2. As far as I know, the intended analysis has always been:

obj(let, them)
xcomp(let, know)

This is the "object cum infinitive" analysis, as opposed to the small clause analysis, which has been popular in generative grammar and which would yield:

ccomp(let, know)
nsubj(know, them)

But @manning or @sebschu should confirm this for English.

[mcdm]

Joakim is right. We talked about this construction and the analysis we adopted (obj and xcomp) in our DepLing 2013 paper "More constructions, more genres: Extending Stanford Dependencies".

[jnivre]

Or @mcdm of course. Sorry, Marie. :)

[brendano]

It may be helpful to have that paper on this list: http://universaldependencies.org/introduction.html

[nschneid]

It may be helpful to have that paper on this list: http://universaldependencies.org/introduction.html

Good suggestion. Done!

[manning]

Thanks @brendano, @nschneid and everyone! Yes, should be obj and xcomp, but doesn't seem to have been very consistently/reliably so annotated….

We’ll try to correct this shortly in UD_English dev branch.

@amir-zeldes: As @jnivre notes, UD uses an "object cum infinitive" or "raising to object" analysis, not the kind of small clause/ECM analyses of GP/P&P/MP. The nsubj(know, me) dependency appears only as an additional dependency in the enhanced dependencies representation.

[amir-zeldes]

@manning : thanks for the clarification, I also agree with this analysis, and we've been following it in an English corpus we're building as well. I was just surprised to see the Stanford parser seems to regularly produce this in the conversion from gold constituent data.

[manning]

I've also added a description and some examples of the object control case to the Complex Clauses documentation page. (Fixes to the corpus are yet to come, but hopefully soon!)

There is some code in the Stanford parser that tries to get this right, but one of the reasons why it is difficult is that the Penn Treebank uses the Chomskyan generative grammar "small clause" or ECM analysis, and so there's some kind of tricky remapping to try to convert things. (Also, I think the xcomp case is just rarer, and so the common case tends to win in the analysis.)

[manning]

I've just corrected this for all cases of the lexeme _let_ in the original UD_English files in the v2 dev branch. (Most of the examples were previously wrongly annotated. We should check over some other xcomp-taking verbs at some point.)