你好!
当我使用UniversalDependencyConverter模块从解析树生成UD时,遇到了意外的输出。正如你所看到的,第18行在下面的命令输出中没有头部(它有一个_
代替)。你知道这可能是什么原因吗?
$ CORENLP_HOME="/home/gaguil20/tools/stanford-corenlp-full-2018-10-05"
$ java -cp "$CORENLP_HOME/*" \
-mx5g edu.stanford.nlp.trees.ud.UniversalDependenciesConverter \
-outputRepresentation enhanced++ \
-treeFile parsing.txt
1 What what PRON WP _ 3 nsubj 3:nsubj _
2 's be VERB VBZ _ 3 cop 3:cop _
3 interesting interesting ADJ JJ _ 14 dep 14:dep _
4 , , PUNCT , _ 14 punct 14:punct _
5 I I PRON PRP _ 6 nsubj 6:nsubj _
6 mean mean VERB VBP _ 18 parataxis 14:dep|18:parataxis _
7 , , PUNCT , _ 14 punct 14:punct _
8 reading read VERB VBG _ 14 dep 14:dep _
9 the the DET DT _ 10 det 10:det _
10 article article NOUN NN _ 8 dobj 8:dobj _
11 , , PUNCT , _ 14 punct 14:punct _
12 basically basically ADV RB _ 14 dep 14:dep _
13 a a DET DT _ 17 det:qmod 17:det:qmod _
14 lot lot NOUN NN _ 13 mwe 13:mwe _
15 of of ADP IN _ 13 mwe 13:mwe _
16 the the DET DT _ 17 det 17:det _
17 celebrities celebrity NOUN NNS _ 0 root 0:root _
18 paid pay VERB VBN _ _ _ _ _
19 by by ADP IN _ 20 case 20:case _
20 him he PRON PRP _ 18 nmod:by 18:nmod:by _
21 to to PART TO _ 22 mark 22:mark _
22 attend attend VERB VB _ 18 xcomp 18:xcomp _
23 charity charity NOUN NN _ 24 compound 24:compound _
24 functions function NOUN NNS _ 22 dobj 22:dobj _
25 . . PUNCT . _ 14 punct 14:punct _
parsing.txt
文件包含以下解析树(取自OntoNotes 5.0的Broadcast News部分):
(TOP
(FRAG
(SBAR
(WHNP
(WP What))
(S
(VP
(VBZ 's)
(ADJP
(JJ interesting)))))
(, ,)
(PRN
(S
(NP
(PRP I))
(VP
(VBP mean))))
(, ,)
(S
(VP
(VBG reading)
(NP
(DT the)
(NN article))))
(, ,)
(ADVP
(RB basically))
(NP
(NP
(DT a)
(NN lot))
(PP
(IN of)
(NP
(DT the)
(NNS celebrities))))
(VP
(VBN paid)
(PP
(IN by)
(NP
(PRP him)))
(S
(VP
(TO to)
(VP
(VB attend)
(NP
(NN charity)
(NNS functions))))))
(. .)))
非常感谢你的帮助,并感谢你提供这样一个伟大的工具!
祝好,
古斯塔沃
[更新]:我在Red Hat 7.6上运行此命令,OpenJDK版本为1.8
6条答案
按热度按时间jgzswidk1#
我也遇到了同样的问题。有任何更新吗?
kt06eoxx2#
这个解析树是一堆废墟——它从哪里来?理论上,即使没有好的依赖结构来连接,我们也应该产生某种"dep"连接,我可以调查为什么没有发生这种情况,但理想情况下,树本身的解析方式应该是不同的。
jogvjijk3#
在我的情况下,它来自Switchboard-NXT:带有不流畅的口语对话转录、部分单词等。对于整个语料库,我认为这种错误只发生过几次。
以下是从NXT直接取的一个例子:
转换(在第13个标记处出错):
wqnecbli4#
在这种情况下,转换器中不支持编辑后的节点。然而,如上所述,应该有能力添加一个未标记的箭头。我会尝试修复这个问题。
tvmytwxo5#
好消息!经过长时间的探索,我终于找到了问题所在,并大致了解了如何解决它。问题在于,没有找到EDITED头的实际规则,因此无论上下文如何,都会将最左边的成分视为头。然而,有一些规则在VP旁边有PRN时将其视为依赖关系的头。这就像物质和反物质一样,会混合并消除整个依赖关系树。我假设2.5年前原始的树在HeadFinder中的头规则和依赖关系规则中存在类似的冲突。有很多方法可以进行粗略的修补,当然还有方法可以将树正确地转换为依赖关系,所以让我下周与我的PI商量一下,然后再回复你。
ModCollinsHeadFinder,由SemanticHeadFinder和UniversalSemanticHeadFinder使用:对于EDITED的规则只是“左”,不考虑有关成分。UniversalEnglishGrammaticalRelations中,这个从属关系的规则使VP成为关系的头,而不是PRN:“VP $ (PRN=target [ < S|SINV|SBAR | < VP < @np ] )”, // 插入问句:是否应该为这种成分的顶级关系(如上所示)有一个$关系?这似乎总是会导致这样的碰撞,除非VP在每个HeadFinder规则中优先于PRN。我们甚至可以制作一个单元测试,检查这种构造,无论是否与HeadFinder规则进行比较。
1cosmwyk6#
事实证明,这些错误都是由同一个bug引起的!在CoreNLP的下一个版本中将会修复这个问题。我怀疑到那时我们是否能实现将"EDITED"转换为"reparandum"的规则添加目标,但你永远不知道(尤其是如果你对添加这种能力感兴趣的话)