enhanced DEPS ambiguity?

[odanoburu]

hello,

I gather this might be a specification issue, but as it was in corpus that I noticed it I thought I might ask here.

I have implemented a(nother) CoNLL-U parser, and was wondering how I should go about parsing the part 21:conj:and of the DEPS field of the word below:

# test
# sent_id = weblog-blogspot.com_aggressivevoicedaily_20060629164800_ENG_20060629_164800-0005
# text = KENNEDY filed an opinion concurring in part, in which SOUTER, GINSBURG, and BREYER joined as to Parts I and II.
23	II	ii	NUM	CD	NumType=Card	21	conj	20:compound|21:conj:and	SpaceAfter=No

from what I understand from the spec, the and is the third possible subfield (case information) of an enhanced dependency.

but how is a CoNLL-U parser supposed to 'know' this? should I try parsing all the possible relation sub-types, and when that fails, conclude it should be case information?

[arademaker]

@odanoburu, I would not assume a fixed list of enhanced deps relations. Even the UD dependencies are not fixed regarding the sub-relations, I didn't hear about any definition of a core set of enhanced deps that should be used in UD. As far as I know, there are many proposals besides the one that the Stanford group proposed.

[odanoburu]

@arademaker so you agree that the example above seems ambiguous?

[jnivre]

There isn't a fixed list for all subtypes, but every language has to specify what subtypes they use in the edeprel.* file. Note that this is different from the deprel.* file, so the set of subtypes may be different in basic and enhanced. Given this information, the representation should not be ambiguous (unless the lemma of a word happens to be identical to the suffix of a subtype).

[odanoburu]

oh, right. silly me, I didn't know about these files... thanks for the clarification!

[odanoburu]

@jnivre where is the edeprel.en file located? I can't find it at https://github.com/UniversalDependencies/tools/tree/master/data

[jnivre]

There was a bug in the validator for the latest release, which allowed treebanks to pass validation even with a missing edeprel file. We have asked the English UD team to supply the missing edeprel.en, and @sebschu has promised to fix this, but apparently it has not happened yet.