padrão das molduras de valência

[leoalenc]

@arademaker e @lucasrct , por conta da inexistência de um padrão explícito de formatação das strings, tive bastante dificuldade na construção de funções em Python, usando expressões regulares ou códigos meramente procedurais, para extrair dados das molduras valenciais. Creio que o alcance da biblioteca seria ampliado se esse padrão fosse definido. Algumas ideias:

1. Definir gramática em BNF para a linguagem das molduras.
2. Definir critérios de ordenamento das relações dentro da moldura e dos diferentes elementos ligados por +.

É preciso levar em conta algumas propriedades da valência para se implementar esse padrão de maneira efetiva:

1. Como na química, valência nas línguas naturais constitui um set e não uma list.
2. No entanto, existe uma ordem canônica de realização dos argumentos em todas ou na maioria das línguas. Isso é normalmente levado em conta nos dicionários de valência. Em português, essa ordem se manifesta nos exemplos da PorGram. Pelo fato de ser uma gramática inicial, somente a ordem dos argumentos canônica dos argumentos foi implementada até o momento, limitação que decorre da própria Grammar Matrix. Vejamos alguns exemplos:

nsubj obj iobj

ele doou a bicicleta a o artista

nsubj ccomp

o gato sabe que os cachorros latem

nsubj obj xcomp

eu autorizei os alunos a escreverem a carta

nsubj iobj ccomp

o artista contou a o estudante que o gato tinha matado uma ratazana

(No último exemplo, coloquei iob porque há exemplos no Bosque desse tipo, ao lado de nsubj obj ccomp.)

O Bosque contém muitos exemplos com anotações espúrias, com combinações de relações inexistentes na língua portuguesa (e talvez impossíveis na própria Gramática Universal), por exemplo, xcomp e ccomp ao mesmo tempo, ou nsubj e csubj. Isso dificulta estabelecer um ordenamento canônico para a linguagem das molduras que seja independentemente motivado. Creio que toda essa discussão tem uma relevância computacional, pois envolve a questão sobre como facilitar a busca de padrões e garantir que não ocorram erros de omissão. Um passo mais adiante seria modelar as molduras como objetos constituídos de outros objetos. Por exemplo, xcomp seria um objeto, eu poderia acessar suas propriedades como set de complementadores (comps) e forma verbal (vform). Do mesmo modo para obj, iobj, ccomp (mood me daria o modo verbal) etc. Concluo com um exemplo final que sugere ser vantajosa a abordagem baseada em objetos. Constatei várias combinações suspeitas do tipo de xcomp:de+a+Inf e xcomp:de+a+que+Inf, mas dificultaram muito levantar esses casos as várias ordens de que, de e a. Na verdade, deveríamos ter um padrão só. Essas variações de ordem fizeram inchar o número de molduras, pois xcomp:de+a+que+Inf equivale a xcomp:a+de+que+Inf etc. (e tudo está igualmente errado...). Se tenho o set de complementadores, busco apenas pelas ocorrências de xcomp cujo conjunto de comps seja maior que 1 para extrair casos suspeitos.

[lucasrct]

Concordo com os pontos, acho que uma unificação na definição da exibição das valências é fundamental. Atualmente o padrão é, começar pelo VERB, depois nsubj, caso haja, e os outros complementadores em seguida, em ordem alfabética. No entanto, os tokens que aparecem em cada complementador não possuem uma ordem definida, aparecendo na ordem que aparecem na sentença.

Sobre o objeto para cada deprel, acho que faz sentido também. O objeto "Relation" capta todas as informações do token, em particular a deprel, mas não existe ainda uma visualização do deprel como o próprio objeto. Precisamos no entanto entender como seria a arquitetura.

Atualmente, o que se pode fazer é o seguinte:

Considere o seu exemplo, o verbo poder

v = poder.valences

In: v[0]
Out: <VERB:act,nsubj,xcomp:Inf>

In: v[0].nsubj
Out: {'PRON': [esse,nsubj,PRON]}

Ou seja, um dicionário com as chaves, o UPOS de cada token nsubj ligado ao verbo em questão, na valência específica.

In: v[0].nsubj['PRON']
Out: [esse,nsubj,PRON]

Esse é o objeto do tipo Relation e isso é só uma exibição das informações do objeto, ele não é uma lista por padrão.

Podemos acessar os seguintes atributos desse objeto:

['deprel', 'lemma', 'metadata', 'relation', 'token', 'upos']

Por exemplo,

In: v[0].nsubj['PRON'].metadata
Out: OrderedDict([('Gender', 'Fem'), ('Number', 'Sing'), ('PronType', 'Dem')])

[leoalenc]

@lucasrct, obrigado pelo comentário. As mudanças que sugeri, se de fato se comprovarem relevantes, constituem objetivo de médio prazo. Gostaria de propor, de imediato, algo mais simples: colocar todos os complementadores (i.e., elementos da categoria SCONJ) em ordem alfabética nas molduras, pois isso reduziria o número de molduras repetidas. Lembro que a ordem não é relevante para a valência. No entanto, para detecção de erros de anotação, talvez seja, mas acredito que essa informação possa ser recuperada dos exemplos. Desse modo, as três molduras, por exemplo,

xcomp:de+a+que+Inf xcomp:a+de+que+Inf xcomp:que+a+de+Inf

seriam normalizados com base na ordem alfabética para

xcomp:a+de+que+Inf

A propósito: na ordenação alfabética, você só levou em conta, iobj, xcomp sem os modificadores após :, , certo?

[arademaker]

Como está este issue @lucasrct?

[lucasrct]

@arademaker e @leoalenc Estou reestruturando a library para deixar tudo mais organizado. Não queria criar um objeto para cada relação, mas agora entendo que talvez seja a melhor opção, dado que as informações que precisamos extrair diferem para relações diferentes. Enquanto isso, fiz a mudança na arquitetura antiga, já atualizei dicionário do bosque também.

@leoalenc, perdão pela demora em responder, acabei só vendo com esse novo comentário do @arademaker. Isso, a ordenação ocorre antes de passar a informação para a string que será impressa na tela, esse : existe apenas na visualização.

Solved on commit #33