openWordnet-PT
openWordnet-PT copied to clipboard
own-pt
palavras duplicadas
Investigando a issue https://github.com/own-pt/wordnet-editor/issues/4 acabei identificando algumas entradas duplicadas de palavras. Esta issue e' para limpar estas duplicatas, corrigindo os links: temos que criar IRIs separados para cada lexical form diferente e ajustar os links dos word senses.
Para obter a lista de duplicatas use a opcao export duplicate statements.
Exemplo:
http://wnpt.brlcloud.com:10035/repositories/wn30#node/%3Chttps://w3id.org/own-pt/wn30-pt/instances/word-afiliar_se%3E
Parece que estes casos foram resultado do algoritmo que usamos para criar URIs para as palavras. A preocupação foi transformar espaços em underscore mas isto acabou colapsando diferentes scripts na mesma URI.
https://github.com/own-pt/wordnet-editor/blob/master/backend.lisp#L72
Parece fácil de resolver, mas temos que decidir o que fazer com casos como: https://w3id.org/own-pt/wn30-pt/instances/word-lua_de_mel
Queremos uma Word instance para cada diferente forma léxica ou queremos colapsar variações como estas de hífen vs sem hífen em uma mesma Word instance?
Os casos onde uma mesma Word Instance tem duas formas léxicas com espaço e outra com underscore no lugar do espaço, remover a versão com underscore. Um caso que já limpei foi "Mar Mediterrâneo" onde removi a forma "Mar_Mediterrâneo".
O que me preocupa é: http://wnpt.brlcloud.com/wn/synset?id=08295580-n
temos 3 'palavras' em PT na interface:
Mas no synset em PT temos apenas um sense: https://w3id.org/own-pt/wn30-pt/instances/synset-08295580-n
Mas temos duas palavra soltas:
https://w3id.org/own-pt/wn30-pt/instances/word-Organização_das_Nações_Unidas https://w3id.org/own-pt/wn30-pt/instances/word-Nações_Unidas
Nestes dois casos acima, manualmente eu removi as triplas duplicadas de rdf:type e wn30:lexicalForm onde a forma léxica duplicada era a variação com underscore. Mas como estas palavras acabaram soltas sem conexão com o synset?
Eu prefiro que lexical forms diferentes tenham words diferentes, ainda que a diferenca seja trivial.
Hum, concordo mas acho que estamos subestimando um problema mais delicado. Lemon e LMF tem expressividade para falar uma série de coisas sobre uma Word. Em alguns casos, podemos estar falando de uma mesma Word com diferentes IRIs. Mas concordo que, por enquanto, para nós Word é uma lexicalForm.
SPARQL:
select *
{
?w a wn30:Word .
?w wn30:lexicalForm ?lf1 .
?w wn30:lexicalForm ?lf2 .
filter (?lf1 != ?lf2) .
}
Usar < ao inves de != gera uma query vazia por algum motivo.
Estou pensando como resolver este problema. Um exemplo do problema:
http://wnpt.brlcloud.com:10035/repositories/wn30#node/%3Chttps://w3id.org/own-pt/wn30-pt/instances/word-compadecer_se%3E
Originalmente o synset 01822248-v contem a forma "compadecer se" e o synset 01821996-v contem a forma "compadecer-se".
Qq solucao a ser implementada tem que certificar-se que tanto o SOLR quanto a TS estejam corretamente sincronizadas ao final.
Bom pelo o numero de duplicatas e' da ordem de 100, o que permite ate' uma intervencao manual em ultimo caso.
but we need a principled story to tell on verbs with particle "se". we don't have this yet, I think. Claudia and Livy need to get some consensual theory because the problem is much bigger than a hundred. see paper https://www.researchgate.net/publication/281328895_Identifying_Pronominal_Verbs_Towards_Automatic_Disambiguation_of_the_Clitic_'se'_in_Portuguese
Registrando query para achar palavras duplicatas (case):
select ?ss ?lex ?lf1 ?lf2
{
?ss wn30:containsWordSense/wn30:word/wn30:lexicalForm ?lf1 ;
wn30:containsWordSense/wn30:word/wn30:lexicalForm ?lf2 .
?ssen wn30:lexicographerFile ?lex ;
owl:sameAs ?ss .
filter ( !sameTerm(?lf1,?lf2) && sameTerm(ucase(?lf1),ucase(?lf2))
&& str(?lf1) > str(?lf2))
}
order by ?ss ?lf1
@FredsoNerd os casos comentados acima foram todos resolvidos. Temos lua-de-mel e lua+de+mel como palavras diferentes. As palavras faltantes do synset sobre ONU já estão no synset. Para compadecer se e compadecer-se temos também duas palavras.
Mas a última query é interessante, onde são listados os casos de palavras potencialmente repetidas no mesmo synset a menos de maiusculas/minusculas. Por isso vou manter issue aberto, seria bom resolver estes problemas para release.
A consulta acima e repetida abaixo:
select ?ss ?lex ?lf1 ?lf2
{
?ss wn30:containsWordSense/wn30:word/wn30:lexicalForm ?lf1 ;
wn30:containsWordSense/wn30:word/wn30:lexicalForm ?lf2 .
?ssen wn30:lexicographerFile ?lex ;
owl:sameAs ?ss .
filter ( !sameTerm(?lf1,?lf2) && sameTerm(ucase(?lf1),ucase(?lf2))
&& str(?lf1) > str(?lf2))
}
order by ?ss ?lf1
me retorna 4376 casos. Que forma eficientes poderiamos usar para revisar cada caso e marcar a versão que deve ficar?
Criei esta página simples a fim de agilizar o acesso aos casos; essa foi uma solução inicial, mas aberto a sugestões. Por favor, dê uma olhada. O script responsável pela tarefa pode ser acessado por aqui
Vale lembrar que eventualmente, teremos o interesse em avaliar demais casos onde uppercase ocorre indevidamente.
O link do script não está funcionando. E temos que começar a organizar os scripts para não temos vários repositórios isolados. Também seria bom que todos os repositórios relacionados à OWN-PT estejam na organização http://github.com/own-pt/
A página funciona bem, mas vamos precisar atualiza-la de tempos em tempos... isto vai estar relacionado a como vamos manter o ciclo de updates do repo e interface http://openwordnet-pt.org até que possamos reescrever a interface usando outro backend.
@arademaker , o link corrigido https://github.com/FredsoNerd/py-ownpt/blob/ce2a5cb76ccb486bca20064a929f03337626df9a/pyownpt/cli/duplicated_words.py. Por organização, este é parte do pacote que venho desenvolvendo.
A página funciona bem, mas vamos precisar atualiza-la de tempos em tempos... isto vai estar relacionado a como vamos manter o ciclo de updates do repo e interface http://openwordnet-pt.org até que possamos reescrever a interface usando outro backend.
Concordo com a colocação, por isso mesmo precisamos pensar em soluções melhores.