Closed suemi-higuchi closed 6 years ago
tente criar issues mais específicos. por problema. Os casos 38-40 e 61-62 vou deixar para discutirmos com @claudiafreitas , são delicados porque envolvem efetivamente mais de uma sentença dentro de quote.
Os demais corrigi como indiquei para vc em outro issue. Vc pode fazer também isso. Note que para quase todas as sentenças, o parser tinha que ser MUITO bom para acertar, nós humanos temos que ler uma ou mais vezes para entender o texto. A sentença 4 do arquivo 16.conllu é especialmente longa e acho que falta melhores marcações para, por exemplo, indicar que Comissão de Ciência e Tecnologia, Comunicação e Informática
é um nome. A vírgula atrapalha completamente o parser.
Não corrigi as análises, apenas forcei que as sentenças fossem analisadas em uma árvore única usando a http://lindat.mff.cuni.cz/services/udpipe/, para isso, indicando que o input já estava pré-segmentado, uma sentença por linha.
Vide commit relacionado.
@suemi-higuchi @arademaker o caso das aspas que rompem o limite da sentença são um problema nao tratado pelo UD. Acho que o melhor que fazemos agora é apenas indicar as frases em que isso acontece.
E ignorar as sentenças ?
por enquanto, ignoramos, mas deixamos indicado isso (talvez algo como "openaspas" no MISC?) Assim que tivermos a solução, voltamos lá e ajeitamos. Porque é importante que a solução seja compatível com o Bosque também. A @LRocha7 vai me mandar uma proposta simples de implementação pra gente estudar prós e contras.
@claudiafreitas não acho que precisamos de nenhuma marcação muito explicita, acho que estes casos conseguimos achar, o problema é que estas aspas desbalanceadas provavelmente devem influenciar na análise da sentença.
@arademaker e @suemi-higuchi fiz em anexo porque é complicado esse tipo de edição aqui. Digam o que acham. Alexandre, a ideia seria eventualmente usar a mesma coisa no Bosque. Sei que o sinal "@" já tem outros usos. Preciso que vc indique que sinais podemos usar no lugar, para não ficar confuso. ASPAS.docx
@claudiafreitas entendi a sua sugestão e acho que é uma solução boa. Vamos aguardar o comentário do @arademaker . Só uma pergunta: vc colocou como head da sentença o token "fecundidade". Para mim isso ainda não é muito óbvio, eu teria ido no "afirma". Por que "fecundidade"?
Reportei em https://github.com/UniversalDependencies/docs/issues/468. Sinceramente, não gosto muito de ficar criando muitas coisas no campo MISC.
Em eab5b186a estou apenas sugerindo que estes quotes apontem para os respectivos ROOT de suas sentenças, e não para o HEAD da subárvore que o open-quote abre. Concordam? Se sim podemos fechar este issu e adotar isto como regra possivelmente documentando no wiki.
@suemi-higuchi note que a @claudiafreitas não alterou o root da sentença 39, ele continua sendo afirma
. Ela apenas apontou o quote para o HEAD da subarvore de
brutalmente, com uma fecundidade e uma produtividade muito grandes
Mas eu não gosto disso, até porque, brutalmente
não está indo para fora deste fragmento, sendo filho de trabalhado
. Na realidade, nem sei o que seria este fragmento se isolado do resto da sentença 39.
Notem que os IDs de sentença não deveriam ganhar a força que estamos dando a eles, referenciar IDs de sentenças dentro das análises força uma preocupação maior agora com contexto das sentenças e ordenação delas. Se o pessoal de UD continuar querendo misturar sentenças para compor os arquivos dev, train, test , estas coisas podem se perder.
Vejam https://github.com/UniversalDependencies/docs/issues/468#issuecomment-328187771, na linha do que a @claudiafreitas sugeriu então mesmo.
No exemplo, o open-quote fica para o head da subarvore que ele abre. O close-quote fica para o head da frase que ele está.
@suemi-higuchi vc corrigi a sentença e fecha este issue? Daqui para frente podemos documentar isto no wiki. Mas o issue precisa ser fechado e eles precisam ser sempre pontuais.
Achlo que com ese ultimo commit 5f0876abb que está seguindo o que @claudiafreitas e alinhado com o pessoal de UD (vide link para o issue deles acima), podemos fechar o issue, certo?
OK, corrigi o outro caso do 15.conllu para fechar o issue logo. Vide 98aaf589a.
Ocorrendo no 15.conllu:
Ocorrendo no 16.conllu: