formas M/F e SG/PL

[arademaker]

quantos casos temos de formas que são M e F? Na modelagem atual, ao invés de uma TAG especial, optamos por duplicar as entradas. O mesmo para plural e singular, quando a forma é a mesma, temos duas entradas.

Seria bom termos uma estatística destes casos para poder reavaliar nossa decisão se for o caso.

[leoalenc]

@arademaker, veja o que eu escrevi na questão #68.

[leoalenc]

quantos casos temos de formas que são M e F? Na modelagem atual, ao invés de uma TAG especial, optamos por duplicar as entradas. O mesmo para plural e singular, quando a forma é a mesma, temos duas entradas.

Seria bom termos uma estatística destes casos para poder reavaliar nossa decisão se for o caso.

@arademaker, vou criar um novo ramo issue-67 e colocar o resultado do meu script em Python referido aqui.

[arademaker]

pensei que o processo que estamos chamando de simplificação seria apenas um pré-processamento para a unificação com um corpus, não mudança efetiva e definitiva no Morpho-Br. Mas se vc acha que devemos efetivar estas mudanças no Morpho-Br, tudo bem para mim.

[arademaker]

Desculpe, estou um pouco perdido aqui. Este issue seria agora então uma duplicada em relação ao #68 ? Estamos então propondo mudar a estrutura do MorphoBr? Se sim, seu commit no branch issue-67 tem qual propósito? Algo a ser feito? Merge dele no master?

[arademaker]

@leoalenc , vi que no branch issue-67 vc criou novos arquivos como adjectives-aa.edt.txt. Mas isto não faz sentido em um sistema como git. Não queremos criar copias de arquivos, mas modificar os arquivos e assim com o versionamento conseguir comparar mudanças dos arquivos ao longo do tempo.

[arademaker]

Opa! @analununes , documente aqui progresso.. melhor. e relacionamos com #12

[arademaker]

não entendi a ultima frase de LR-POR/tools#5 (comment). Documente aqui progresso. Tá confuso, estamos com um issue aqui e outro no check-tools e outro no test.

[analununes]

@arademaker, na última frase quis dizer que os arquivos produzidos aqui não têm aqueles erros

[analununes]

@arademaker e @leoalenc, enquanto comentava o código percebi que eu estava aplicando todas as correções quando produzia o map, o certo é aplicar no map de adjectives as correções correspondentes e no map de nouns a correção correspondente. Para corrigir isso eu criei as funções newADJ e newNouns que substituem a newMorpho. Acho que agora está tudo certo

[arademaker]

No 82dea16, recriei o branch issue-67. @analununes , considerando que o #90 foi fechado, por favor, reexecute o código para 'simplificação'. como antes, os diretórios nouns e adjectives serão afetados. Mas note que aproveitei para reorganizar os arquivos:

1. tínhamos criado um diretório src mas já existia um diretório tools, movi os códigos de src para tools. De fato, antes da release, quero tirar deste repositório códigos. Melhor seria que este repositório seja apenas para os dados.
2. o diretório diminutives tinha dois arquivos, um com adjetivos e outro com substantivos mas em nouns e adjectives também tínhamos aumentativos e diminutivos. Então estava inconsistente. Movi os arquivos deste diretório para seus respectivos diretórios nouns e adjectives. Quando rodar a simplificação, lembre de considerar estes arquivos.

[leoalenc]

2. o diretório diminutives tinha dois arquivos, um com adjetivos e outro com substantivos mas em nouns e adjectives também tínhamos aumentativos e diminutivos. Então estava inconsistente. Movi os arquivos deste diretório para seus respectivos diretórios nouns e adjectives. Quando rodar a simplificação, lembre de considerar estes arquivos.

@arademaker, cabe um esclarecimento: na verdade, só havia diminutivos, mas alguns destes eram derivados de aumentativos. Por exemplo, uma forma como casarãozinho é o diminutivo da palavra casarão, por sua vez, aumentativo de casa Na classificação de uma palavra como diminutivo ou aumentativo, o que conta é a etiqueta que se encontra mais à direita. Independentemente dessa observação, foi uma boa ideia fundir a pasta de diminutivos com as outras pastas.

[arademaker]

No commit 9e7ca3a fechamos este issue. Várias outras correções manuais foram feitas ainda no branch. Também foram removidas duplicatas de DIM e AUG identificadas quando reorganizamos diretórios.

@analununes, alguma observação a ser feita sobre este issue? Tratamos aqui da remodelagem do recurso, trocando repetições por subspecificações nos ADJ e NOUN. No PR dei exemplos de ADJ.

Considerando que concordamos que NOUN não flexionam em gênero mas tem um gênero inerente, entradas como:

9292 aderentes	aderente+N+PL
9293 aderente	aderente+N+SG

12695 aderentes	aderente+A+PL
12696 aderente	aderente+A+SG

não seriam questionáveis? adotamos subspecificação para dizer que a forma é a mesma para qualquer valor do traço omitido. Mas para substantivos, temos 2 substantivos (masc e fem) e o adj. Pergunto se não deveriamos manter para os substantivos os traços de gênero e número @leoalenc sempre.

[arademaker]

De qualquer forma, a apresentação gerada é mais compacta, para todos os substantivos que não tiverem traço de gênero, sabemos que eles tem forma Fem e Masc iguais.

[analununes]

@analununes, alguma observação a ser feita sobre este issue?

Para simplificar as entradas dos arquivos de adjetivos e substantivos realizei as ações a seguir (vou usar como exemplo a forma óculos):

1. associar cada forma a uma lista de classificações (lemma + tags):
   óculos: [óculo+N+M+PL, óculos+N+M+SG, óculos+N+M+PL]
2. ordenar e eliminar duplicatas de cada lista associada a uma forma:
   óculos: [óculo+N+M+PL, óculos+N+M+PL, óculos+N+M+SG]
3. agrupar as classificações de acordo com o lema:
   óculos: [[óculo+N+M+PL], [óculos+N+M+PL, óculos+N+M+SG]]
4. fazer a interseção das classificações em cada grupo:
   óculos: [[óculo+N+M+PL], [óculos+N+M]]
5. construir uma string com todas as formas, ordenando de acordo com as classificações, o que faz com que entradas com um mesmo lema fiquem juntas:

...
óculos	óculo+N+M+PL
óculos	óculos+N+M
...

6. dividir a string em arquivos, mantendo entradas que tem um mesmo lema no mesmo arquivo, com número de linhas aproximadamente igual a 19000 (o que permite a visualização dos arquivos aqui no github).

Obs.: os nomes dos arquivos foram criados usando as três primeiras letras da primeira entrada do arquivo.

[leoalenc]

No commit 9e7ca3a fechamos este issue. Várias outras correções manuais foram feitas ainda no branch. Também foram removidas duplicatas de DIM e AUG identificadas quando reorganizamos diretórios.

@analununes, alguma observação a ser feita sobre este issue? Tratamos aqui da remodelagem do recurso, trocando repetições por subspecificações nos ADJ e NOUN. No PR dei exemplos de ADJ.

Considerando que concordamos que NOUN não flexionam em gênero mas tem um gênero inerente, entradas como:

9292 aderentes	aderente+N+PL
9293 aderente	aderente+N+SG

12695 aderentes	aderente+A+PL
12696 aderente	aderente+A+SG

não seriam questionáveis? adotamos subspecificação para dizer que a forma é a mesma para qualquer valor do traço omitido. Mas para substantivos, temos 2 substantivos (masc e fem) e o adj. Pergunto se não deveriamos manter para os substantivos os traços de gênero e número @leoalenc sempre.

@arademaker, bem lembrado. Pelo meu script SimplifyEntries.py, também gerei substantivos não especificados para gênero, por exemplo:

~/MorphoBr/nouns$ grep -P "\tdentista\+" new-nouns.dict

dentista dentista+N+SG
dentistas dentista+N+PL

Na PorGram, esse tipo de substantivo é instância do tipo common, enquanto substantivos como avião e maçã são instâncias do tipo masc e fem, respectivamente. A TFS de common tem o seguinte caminho:

CONT: [mrs HOOK: [hook INDEX:<4>= [ref-ind PNG: [png ... NUM: number GEND: gender]]

Parece-me que podemos conciliar essa definição com a noção de que todo substantivo possui gênero inerente.
Do ponto de vista do parsing com uma gramática HPSG, não há nenhuma vantagem em ter entradas diferentes para os dois gêneros no caso de substantivos como dentista que não exibem variação formal de gênero. Pelo contrário, aumenta a ambiguidade de sentenças como esta:

Dentistas são felizes.

É claro que uma função de busca do significado de um substantivo numa base lexical deve ser sensível à subespecificação do gênero. Dicionários tradicionais, como o da Porto Editora, não possuem entradas diferentes no caso de dentista, pois nenhum significado adicional à nocão de gênero se acrescenta com a variação de gênero, diferentemente do que ocorre em casos como gama:

https://www.infopedia.pt/dicionarios/lingua-portuguesa/dentista
https://www.infopedia.pt/dicionarios/lingua-portuguesa/gama

Na seguinte frase, trata-se da letra gama (referindo-se, por exemplo, a um personagem identificado por essa letra) ou da fêmea do gamo? Creio que podemos deixar isso em aberto no parsing.

Gama é feliz.

No entanto, a MRS indica o gênero neste caso:

A gama é feliz.

[leoalenc]

@arademaker, complementando o comentário anterior, o sintagma nominal de a dentista sorriu tem a seguinte TFS:

CONT: [mrs HOOK: <3> = [hook INDEX: [ref-ind PNG: [png ... NUM: singular GEND: feminine]]

Ao contrário, em dentistas sorriram, o NP tem a seguinte TFS:

CONT: [mrs HOOK: [hook INDEX: [ref-ind PNG: [png ... NUM: plural GEND: gender]]

[arademaker]

Estranho o valor unspecified de GEND ser "gender". Nao seria esperada a omissão da entrada GEND para o segundo caso?

[leoalenc]

Estranho o valor unspecified de GEND ser "gender". Nao seria esperada a omissão da entrada GEND para o segundo caso?

@arademaker, boa pergunta. Em princípio, acredito que poderíamos definir, numa gramática HPSG do português, um tipo de adjetivo ou substantivo sem o atributo gênero. No entanto, parece que isso complicaria a elaboração das regras de formação de sintagmas levando em conta classes com e sem o atributo gênero. Veja o tratamento do determinante the do inglês na minigramática de Copestake (2002, p. 50 e p. 82), para o qual o valor do atributo NUMAG é agr, ao passo que, para this, é sg.
O fato é que, na Grammar Matrix, todos os substantivos e todos os adjetivos têm o mesmo leque de atributos. Isso vem ao encontro da intuição ou generalização linguística de que todo substantivo tem gênero inerente, que o adjetivo concorda em gênero e número com o substantivo que modifica etc. Isso parece constituir herança da ERG. Não parece ser possível definir, dada o atual design da Grammar Matrix, um tipo de substantivo ou um adjetivo sem o mesmo leque de atributos.
Na arquitetura da HPSG, os valores de atributos, como GEND, são sempre tipos que, por sua vez, pertencem a determinados supertipos. Desse modo, masculine e feminine são subtipos de gender. O tipo do valor de GEND é gender, que, pela unificação com tipos, unifica com seus subtipos, ver Copestake (2002, p. 55). É o que ocorre num sintagma como dentista rica. O mesmo vale para a concordância entre determinante e substantivo, por exemplo em a dentista.

[arademaker]

Ok, faz sentido. Sub especificação é marcada com supertipo

[analununes]

Resolvido em 9e7ca3a

[arademaker]

@analununes poderia descrever o que foi feito no commit mencionado?

[analununes]

@arademaker, nesse commit foi realizada a simplificação das entradas, omitindo as tags quando a forma flexionada não varia. Por exemplo, as entradas:

simples simples+A+F+PL
simples simples+A+F+SG
simples simples+A+M+PL
simples simples+A+M+SG

foram simplificadas para:

simples simples+A