mwe: já não

[livyreal]

"já não" está tageado errado. não deveria ser ADV e a relação entre eles deveria ser "mwe".

aqui então temos que pegar todos os "já não" que são MWE e mudar a pós de "não NOUN" para "não ADV", a MWEPOS geral é ADV; a deprel de "não" aponta para "já" por mwe e a deprel de já aponta para a mesma coisa que "não" apontava" pela relação "neg".

Como era:

7	já	já	ADP	PRP|@ADVL>	_	8	case	_	MWE:já=não
8	não	não	NOUN	N|M|S|@P<	Gender=Masc|Number=Sing	9	nmod	_	_

Como fica

7	já	já	ADP	_	_	9	neg	_	MWE:já=não MWEPOS=ADV
8	não	não	ADV	_	_	7	mwe	_	_

@concordam, @vcvpaiva e @claudiafreitas ?

[vcvpaiva]

concordo @livyreal, exceto que como @fcbr vai te dizer tem que ser MWE:já_não MWEPOS=ADV em vez de já=não MWEPOS=ADV.

[fcbr]

@livyreal neg foi removido da v2, entao como fica a sua regra?

[livyreal]

CP911-6

como está:

9	já	já	ADP	PRP|@ADVL>	_	10	case	_	MWE=já_não
10	não	não	NOUN	N|M|S|@P<	Gender=Masc|Number=Sing	12	nmod	_	_

como fica:

9	já	já	ADP	_	_	12	advmod	_	MWE=já_não MWEPOS=ADV
10	não	não	ADV	_	_	10	fixed	       _	_

[fcbr]

@livyreal este e' um exemplo generico? Todos os "ja's" devem se conectar via advmod?

[livyreal]

sim.

[arademaker]

@livyreal seu exemplo está errado token 10 está apontando para o próprio token 10.

[livyreal]

obrigada, @arademaker!

como está:

9	já	já	ADP	PRP|@ADVL>	_	10	case	_	MWE=já_não
10	não	não	NOUN	N|M|S|@P<	Gender=Masc|Number=Sing	12	nmod	_	_

como fica:

9	já	já	ADP	_	_	12	advmod	_	MWE=já_não MWEPOS=ADV
10	não	não	ADV	_	_	9	fixed	       _	_

[arademaker]

@livyreal features ficam nulas mesmo? Não lembro por que estamos insistindo em manter no campo misc estes valores MWE e MWEPOS. E o campo misc não pode ter espaço, se formos manter isso, preicsamos de um separador, talvez o mesmo | usado no campo feats.

[livyreal]

não há nada nas mudanças de V2 que indicam uma nova marcação de quais são as expressões MWE então mantemos o span da mwe e também o general POS tag, como era em V1. Já era assim, mas nosso corpus estava incompleto.

De fato tem a feature Polarity=Neg, que é a grande mudança de V1 pra V2. Lançaram tantas features novas que eu estou perdida ainda.

Finalmente deve ficar:

9	já	já	ADP	_	_	12	advmod	_	MWE=já_não|MWEPOS=ADV
10	não	não	ADV	_	Polarity=Neg	9	fixed	       _	_

[arademaker]

@livyreal não entendi seu argumento!! Talvez seja melhor falarmos. Podemos pelas dependências recuperar a MWE original sim, não perdemos nada ao jogar fora estes valores MWE e MWEPOS do campo misc, eu acho.

[livyreal]

MWEPOS é o campo mais importante de todos... pq é ele que é relevante para a deprel que vai ligar a MWE ao resto da sentença! Se for uma mwe NOUN, ela pode participar da deprel nmod, se for uma mwe ADV, ela terá que participar de uma deprel advmod. No caso do "ou seja", "ou" é ADP, "seja" é verbo, mas "ou seja" é CCONJ. Isto é muito mais importante do que a POS de cada uma das palavras internamente.

Não dá pra jogar fora não. a MWE pós até daria mas não vejo pq já que as guidelines dizem isto e nós estamos com o corpus todo correto neste sentido.

[arademaker]

@livyreal por mais que eu goste da idéia de ter um sistema de tipos nas relações que pudessem garantir que uma dada relação pede determinadas POS tags nos seus extremos, nada nas documentações ou no script validate.py sugere que este tipo de validação seja feita.

Não temos os valores de MWE consistentes não, dado exatamente o caso #23. Acho que manter coisas que não são pedidas e podem ser recuperadas é tornar o trabalho de manutenção mais trabalhoso do que o necessário.

[livyreal]

só pra constar, depois do comentário acima do @arademaker , escrevi para a lista de UD (MWEPOS é o assunto do e-mail) e discutimos extensivamente como e onde marcar MWEPOS e MWEspan. MWEspan é redundante, mas MWEPOS é necessário (ainda que um parser comum não vá considerar estas expressões). já que temos todas as MWEspan no corpus e falta algumas MWEPOS, decidimos por manter as duas, já que a informação reducante está correta.

[arademaker]

@livyreal sim, documentar é bom. Correções: não temos um valor MWEspan apenas MWE. Não é nossa prioridade mas acho que antes do release final deveríamos remover este valor, não decidimos que vai ficar assim não, só adiamos a conversa, sem consenso. Sobre parser comum, escrevendo assim me pareceu que vc teria a expectativa de algum parser usar esta informação, acho que nenhum parser irá usar o campo MISC para aprender algo, este foi o comentário do Joakim.

[vcvpaiva]

gostaria de re-abrir esse issue pra perguntar: perdemos a marcacao de negativity entao completamente?

[fcbr]

A negativity foi transferida para a feature Polarity=Neg do token nao.

[arademaker]

podemos fechar?

[vcvpaiva]

@fcbr and @livyreal Polarity=Neg is not enough to characterize negation, I hope you do understand that this is worse that the relation "neg", which was not enough either, but it was more informative.

[arademaker]

@vcvpaiva do you have concrete examples? The v2 UD spec removed the relation 'neg', it was not our decision. But we can argue if we understand the concrete cases that justify the limits of polarity alone for characterize negations

[vcvpaiva]

claro que eu sei que a decisao foi deles @arademaker. veja no corpus SICK

1 Nobody nobody NOUN NN _ 3 nsubj _ PRP|?|?
2 is be VERB VBZ _ 3 aux _ VBZ|02604760-v|Entity+
3 playing play VERB VBG _ 0 ROOT _ VBG|01719302-v|DramaticActing+
4 ping ping NOUN NN _ 5 nn _ NN|07389569-n|RadiatingSound+
5 pong pong NOUN NN _ 3 dobj _ JJ|?|?

there is nothing indicating a negation, but that is there, right?

Now, the difference of having a word marked as Polarity=Neg versus a relation, is that the relation at least gives you some indication of where the scope of your negation is, while a word marked, does not.

But NO, there is no reason to take this to the UD guys, who know this fairly well.
As Chris Manning likes to repeat, if you want to move UDs in one of the directions that it's trying to accomplish(which we are, in the direction of semantics), it is very easy.
The difficulty is keeping all the other constraints that he's trying to keep (the universality, the easy of annotation, the respect to traditional grammar, etc. ) on the air.

[arademaker]

Now, the difference of having a word marked as Polarity=Neg versus a relation, is that the relation at least gives you some indication of where the scope of your negation is, while a word marked, does not.

The scope of the negation can be the subtree of the given node. Not true that using Polarity you don't have any clue about the scope.