missing V tag in clitics

[odanoburu]

há várias entradas no diretório verbs/clitics/ sem a tag V, que deveria aparecer depois do lema da palavra e antes do lema do clítico:

ababadai-nos    ababadar+nós.AD.1.PL+PRS+2+PL

usando grep -E " [^\+]+\+[^V]" clitics.all (o espaço na string é uma TAB)

[leoalenc]

@odanoburu é verdade!

[leoalenc]

@odanoburu eu contei quase 650.000 entradas com esse problema!

[leoalenc]

@odanoburu Todas têm tag AD

[leoalenc]

@odanoburu 2,3 milhões têm AD e V

[leoalenc]

@odanoburu Outro aspecto desse bug é que, nos casos onde +V faltou, a ambiguidade de "nos" também não foi reconhecida quando o verbo termina em nasal, por ex. abagaçam-nos. Descobri a causa desse bug e corrigi: é que uma regex com \w não pegou carácteres não ASCII.

[leoalenc]

@odanoburu nos outros casos em que o verbo não termina por nasal e o "nos" , Portanto, não é ambíguo , a causa do bug era outra, que eu também corrigi. Quando falo em correções, falo no programa conversor, não mudei nada nos arquivos dos verbos.

[odanoburu]

Outro aspecto desse bug é que, nos casos onde +V faltou, a ambiguidade de "nos" também não foi reconhecida quando o verbo termina em nasal, por ex. abagaçam-nos.

então para cada uma dessas linhas está faltando uma outra linha, certo?

Quando falo em correções, falo no programa conversor, não mudei nada nos arquivos dos verbos.

sim sim, mas precisamos mudar.. fico pensando se não é melhor gerar do zero -- assim não precisamos de corrigir um script e fazer outro pra corrigir (o que abre possibilidade de mais bugs)

[arademaker]

@leoalenc vc diz que corrigiu o programa conversor, mas no repositório seu último commit foi no dia 1, antes deste issue ser aberto. Então imagino que vc ajustou o programa mas ainda não mandou para o repositório, é isso?

Seu 'programa conversor' é este arquivo https://github.com/LFG-PTBR/MorphoBr/blob/master/tools/morphology/BuildPairsFromDELAF.py ?

[leoalenc]

@arademaker eu corrigi o programa conversor localmente, ainda não subi a versão atualizada por conta do prazo do artigo. Também não mexi nas listas de verbos do repositório. Mas eu acho melhor corrigir o que está no repositório por no meio do sed @odanoburu. Isso porque provavelmente o que já está lá tem correções que foram feitas por conta de bugs do dicionário de São Carlos. E perdemos controle a respeito dessas alterações. O programa conversor servirá para converter novas entradas que vierem a ser acrescentados no dicionário de São Carlos. O que vocês acham?

[leoalenc]

@odanoburu mas vejo agora que tem o caso da ambiguidade, talvez seja melhor então rodar o conversor de novo E fazer uma lista das alterações que foram realizadas ao longo de todo projeto até o momento. Isso está disperso nos e-mails, mensagens de WhatsApp e nessas questões daqui.

[odanoburu]

@leoalenc acho interessante refazermos, dessa vez colocando todas as mudanças num script, para que elas sejam reproduzíveis! e assim sempre que tivermos uma modificação podemos rerodar o script!

eu fiz uma lista dos erros encontrados que ainda está no overleaf, usando as issues do repositório (talvez ainda tenha algo só no email, mas a gente consegue recuperar). se vcs concordarem, vamos fazer?

[leoalenc]

@odanoburu sim, vamos! Proponho o seguinte: primeiro, por meio de scripts (juntados num único script) , corrigir o que for automaticamente corrigível no dicionário de São Carlos, preparando uma versão desse desse dicionário, no formato deles, sintaticamente correta E com as adições de formas faltantes que nós podemos incluir facilmente por meio do sed. Sobre essa versão limpa aplicamos então os conversores. Mais tarde eu posso mandar um esquema do que eu já organizei nesse sentido bem como disponibilizar os scripts que eu já tinha preparado .

[leoalenc]

@odanoburu É importante também que essa versão limpa do dicionário de São Carlos, no formato deles, elimine as etiquetas ambíguas como a letra S

[odanoburu]

beleza, @leoalenc ! me passa o que vc tiver que eu completo!

E com as adições de formas faltantes que nós podemos incluir facilmente por meio do sed.

aqui tanto faz incluir antes ou depois da conversão, certo?

coloquei a lista de erros do DELAF e GFL que compilei no repositório, é uma boa irmos atualizando ela sempre que acharmos um problema! se tiver faltando algo, avisem por favor!

[odanoburu]

@leoalenc comecei a fazer um script para preparar o DELAF para conversão para formato MBR. qualquer feedback é bem-vindo!

estou seguindo uma proposta um pouco diferente: quando vc disse

E com as adições de formas faltantes que nós podemos incluir facilmente por meio do sed

eu acho melhor separar a correção das adições, pq assim conseguimos calcular mais facilmente o que efetivamente adicionamos aos recursos originais!

[odanoburu]

@leoalenc estou trabalhando sobre assunto em #53

ja incorporei isso:

@odanoburu É importante também que essa versão limpa do dicionário de São Carlos, no formato deles, elimine as etiquetas ambíguas como a letra S

[leoalenc]

@odanoburu Vou retomar hoje o trabalho nó repositório. Vou dar uma olhada no seu script.

[odanoburu]

ok! ainda não terminei, though...

[leoalenc]

Sim, vi que faltam algumas coisas.

[leoalenc]

@odanoburu, o script atual ainda não separa as correções das adições, como você propôs, certo?

[odanoburu]

hum, pelo que olhei aqui, só fiz a parte de correção: então, sim, separa!

[leoalenc]

@odanoburu eu pensei que teríamos dois scripts separados, um para as correções e outro para as adições. A função que está no início do script atual adiciona entradas. É claro que o script ainda está em construção, o desdobramento em dois scripts separados poderá ser feito depois.

[odanoburu]

sim, vamos criar um script para as adições!

acho que aí temos uma questão de definição: pra mim a função só corrige a entrada, embora seja verdade que de uma entrada (inválida) passemos a ter duas (válidas) -- por isso é justo interpretar como adição também. mas como não tem um jeito fácil de adicionar depois de corrigir, faz sentido ficar no script de correção.

[leoalenc]

@odanoburu veja o que eu escrevi a respeito da questão #53. Parece que a adição é indevida nesse caso. Deveria ser feita apenas a correção do último número da entrada para s minúsculo.

[analununes]

@arademaker e @leoalenc, em 7cc1e71 implementei um algoritmo que adiciona a tag V aos clíticos que não a possuíam. Porém, lendo os comentários antigos dessa issue e da issue #53 vi que existia uma ambiguidade nessas entradas com pronome nos. Isso já foi corrigido? Caso não tenha sido, podem me ajudar a entender melhor essa questão para que eu adicione no meu algoritmo o que for necessário para resolver?

[leoalenc]

@arademaker e @leoalenc, em 7cc1e71 implementei um algoritmo que adiciona a tag V aos clíticos que não a possuíam. Porém, lendo os comentários antigos dessa issue e da issue #53 vi que existia uma ambiguidade nessas entradas com pronome nos. Isso já foi corrigido? Caso não tenha sido, podem me ajudar a entender melhor essa questão para que eu adicione no meu algoritmo o que for necessário para resolver?

@analununes , a ambiguidade da forma clítica nos consiste em que pode representar tanto alomorfe de os, pronome átono masculino acusativo de terceira pessoal do plural, quanto a forma átona acusativa ou dativa de nós, ou seja, primeira pessoal do plural. Conforme descrito em Alencar, Cuconato e Rademaker (2018), essa ambiguidade foi resolvida. O script em Python que elaborei para converter as entradas do DELAF-PB, disponível no repositório, faz o enriquecimento das representações originais, incluindo as informações morfossintáticas devidas. Atualmente, temos:

awk '$1 ~ /\-nos$/ && $2 ~ /^comprar\+/' clitics-a*.dict

... comprava-nos comprar+nós.AD.1.PL+IMPF+1+SG comprava-nos comprar+nós.AD.1.PL+IMPF+2+SG comprava-nos comprar+nós.AD.1.PL+IMPF+3+SG compravam-nos comprar+V.ele.ACC.3.M.PL+IMPF+3+PL compravam-nos comprar+V.nós.AD.1.PL+IMPF+3+PL ...

Veja que nos é etiquetado como ele.ACC.3.M.PL e nós.AD.1.PL nas duas últimas entradas. Aparentemente, trata-se de questão resolvida. No entanto, realmente falta a tag V nas três primeiras entradas.

[analununes]

@leoalenc, entendi, obrigada! Vou apenas adicionar a tag V então.

@arademaker, o algoritmo para adicionar a tag funciona de forma simples. Primeiro é feito um split na entrada, por exemplo:

abaratei-me abaratar+V.eu.AD.1.SG+PRF+1+SG -> abaratei-me [[abaratar],[V,eu,AD,1,SG],[PRF],[1],[SG]]
abaratei-nos    abaratar+nós.AD.1.PL+PRF+1+SG   -> abaratei-nos [[abaratar],[nós,AD,1,PL],[PRF],[1],[SG]]

se o primeiro elemento da segunda lista interna não é "V", ou seja, se a primeira tag depois do lema não é V, a mesma é adicionada; caso contrário nada é feito

abaratei-me abaratar+V.eu.AD.1.SG+PRF+1+SG
abaratei-nos    abaratar+V.nós.AD.1.PL+PRF+1+SG

[arademaker]

Na biblioteca, seu objeto Entry deve comportar de alguma forma estas entradas de clitics certo? note que a biblioteca deve funcionar em camadas. A leitura/escrita deve lidar com apenas a leitura dos arquivos e criação das instancias do tipo Entry e vice-versa. O código desta issue então seria algo a ser aplicado na lista destes objetos Entry. Me parece pela sua ideia acima que vc está ignorando esta separação e fazendo cada função acessar diretamente a camada de leitura do arquivo e/ou lidar com estruturas de dados diferentes.

[arademaker]

como parte deste issue, vc teve que modificar algo no repositório da biblioteca, pode colocar link para o issue correspondente na biblioteca? link para o commit da mudança na biblioteca?

[analununes]

@arademaker, havia um link para o commit em meu último comentário. Me descuidei e não criei uma issue, corrigi isso agora: https://github.com/LR-POR/tools/issues/29 Novo commit: f605f37