Contribuições com o Projeto OMCS-Br

Este pesquisador contribuiu na construção da arquitetura do projeto OMCS-Br, conforme é apresentado nas próximas subseções, com o intuito de (i) permitir a coleta de informações relevantes para a realização do estudo de caso deste trabalho no site do projeto e (ii) o aumento da variedade de conhecimento na base, para futuros planejamentos de AA.

O pesquisador também contribuiu no desenvolvimento da ConceptNetBr, que será utilizada no suporte computacional que está sendo desenvolvido e tem participado da manutenção da arquitetura do projeto.

7.1.2.1. Elaboração e Implementação de Temas e Atividades para o Site do Projeto OMCS-Br

Concernente a coleta de dados, este pesquisador realizou a definição dos templates da atividade “Saúde”, discutindo com especialistas no domínio que tipos de informações sobre o cuidador familiar são importantes para um profissional de saúde saber, e elaborando templates para coletar estes tipos de conhecimento.

Definidos os templates, este pesquisador desenvolveu-os e inseriu-os no processo de retro-alimentação do site, para que as informações obtidas através deles pudessem ser utilizadas por outras atividades do site.

O pesquisador também conduziu a elaboração de templates relacionados às atividades “Feito de”, “Parte de”, “Habilidades”, “Eventos”, “Situações” e “Personalidades”, bem como definiu a inserção desses no processo de retro-alimentação do site OMCS-Br. No passo seguinte, os templates foram implementados por alunos de Iniciação Científica do LIA.

Outro tema no qual o pesquisador teve participação na elaboração de

templates foi o tema educação sexual, sobre o qual se pretende planejar uma AA em

breve.

Através do desenvolvimento destes temas e atividades, espera-se aumentar a variedade de conhecimento coletado no site do projeto OMCS-Br e contribuir com o crescimento da base de conhecimento do projeto.

7.1.2.2. Geração da ConceptNetBr

Paralelamente ao planejamento e execução do estudo de caso deste trabalho, o pesquisador desenvolveu, junto aos demais integrantes da equipe OMCS-Br, os módulos de geração da ConceptNet, realizando as seguintes atividades:

1. Discutindo as regras de extração para cada template com os demais integrantes da equipe OMCS-Br, definindo colaborativamente essas regras e implementando-as no Módulo de Extração.

2. Dando manutenção ao Normalizador desenvolvido por Tsutsumi (2006), modificando o módulo em Python de acesso às funções do Curupira, disponibilizadas pela .dll fornecida pelo NILC ao LIA. Aqui foram identificados alguns casos nos quais o Curupira etiquetava uma mesma palavra mais de uma vez e fez-se o módulo retornar para o normalizador apenas a primeira etiquetação realizada. Os casos identificados foram:

• Ênclise – quando ocorre ênclise no verbo o Curupira atribui as seguintes etiquetas à expressão e as suas partes: ENCLISE VERBO, HÍFEN, PPOA PPODA (ver ANEXO I para os significados de cada etiqueta). Exemplo: fazê-lo Î fazê-lo – ENCLISE VERBO | -lo – HÍFEN | -lo – PPOA PPODA.

• Algumas palavras compostas. Exemplo: fada-madrinha Î fada- madrinha – SUBST | -madrinha – HÍFEN | -madrinha – SUBST.

Diz-se algumas, pois nem todas as palavras compostas são etiquetadas mais de uma vez. As palavras “guarda-roupa”, “estrela- do-mar” e “guarda-chuva”, por exemplo, são etiquetadas apenas uma vez como SUBST.

• Sintagmas nominais compostos, etiquetados como substantivo. Exemplo: veículo 0 Î veículo 0/SUBST | veículo/SUBST | 0/NUMERO. Nesse caso específico, descarta-se o sintagma composto e retornam-se ao normalizador os itens que o compõem (no caso anterior, veículo/SUBST e 0/NUMERO), pois no processo de normalização desenvolvido, todo item a ser normalizado necessita estar associado a uma etiqueta. Caso fosse considerado “veículo 0/SUBST”, o normalizador tentaria verificar a forma normal de “veículo” e após de “0/SUBST”, ocorrendo um erro em tempo de execução.

Outra modificação feita no Normalizador foi manter a variação de gênero. Anteriormente a normalização colocava as palavras femininas no masculino, seguindo o processo realizado no projeto americano. Contudo, a equipe OMCS-Br decidiu manter a variação de gênero por considerar que essa alteração poderia modificar a semântica da sentença que deu origem a uma determinada relação.

3. Implementando a versão brasileira para as regras de inferência para geração de novas relações SuperThematicKLine, ThematicKLine, PropertyOf, CapableOf e CapableOfReceiveingAction a partir de relações geradas previamente por regras de extração.

4. Definindo e implementando a representação da negação em relações cujo verbo que lhe dá origem é acompanhado de uma partícula negativa (nunca, quase nunca, raramente e não, por exemplo). No projeto americano, essa informação estava sendo perdida ao gerar-se a ConceptNet.

Adotou-se uma interpretação da idéia de negação de predicado, apresentada por Levelt (1993), gerando para cada relação da ConceptNet uma versão negativa acrescentando a partícula “Not” antes do predicado. Assim, a sentença “Um(a) cachorro não pode voar”, que na versão norte-americana gerava a relação (CapableOf “cachorro” “voar”), é representada na versão brasileira como (NotCapableOf “cachorro” “voar”).

Identificado esse problema, a equipe norte-americana foi contatada e informada das idéias que haviam surgido no Brasil para solucionar esse problema. Tal

equipe implementou outra idéia surgida no Brasil, que consistia de adicionar mais um argumento às relações, como os argumentos f e i, para indicar se a relação tinha uma polaridade positiva ou negativa.

A equipe brasileira optou pelas versões negativas dos predicados, pois averiguou que seriam necessárias menos alterações nas funções da API do projeto, para considerar a negação em seus processos de inferência.

Dessa forma o pesquisador contribuiu para a geração completa da ConceptNetBr, isto é, com todas os tipos de relações definidos no contexto do projeto OMCS.

7.1.2.3. Módulo de carregamento da ConceptNetBr

Este pesquisador participou no desenvolvimento do módulo de carregamento da ConceptNetBr, implementando a regra de inferência que gera novas relações

PropertyOf utilizando relações IsA e PropertyOf já existentes, discutida no Capítulo 4,

e o mecanismo que verifica se a ConceptNet filtrada de acordo com perfil determinado na aplicação já se encontra disponível no servidor do projeto, carregando-a, caso afirmativo, ou gerando-a e carregando-a caso contrário.