relatório final de projeto - clarisse/linx/relatoriofinallinx.pdf · (iii) realizar inferências...

LINX - Interfaces para Construção e Utilização de Sistemas Baseados em Conhecimento

Apoio CNPq: Processos # 521857/95-3, #523499/95-7

Relatório Final de Projeto

preparado por Clarisse Sieckenius de Souza

Departamento de Informática

Rio de Janeiro, 30 de Agosto de 1997

(c) Clarisse Sieckenius de Souza, 1997

The Tao that can be expressed is not the eternal Tao; the name that can be defined is not the unchanging name.

Tao Te King, I

SUMÁRIO Parte I

Sobre Sistemas de Informação Baseados em Conhecimento, suas Interfaces e sua Abrangência

Clarisse Sieckenius de Souza Sobre Sistemas Automáticos e Sistemas Formais Clarisse Sieckenius de Souza Um Estudo de Caso Simplificado, mas Exemplar Clarisse Sieckenius de Souza

Parte II

A Razão de Ser do LINX Clarisse Sieckenius de Souza Um Breve Histórico deste Projeto Integrado Clarisse Sieckenius de Souza Resultados de Publicações e Apresentações em Congressos e Conferências Clarisse Sieckenius de Souza Resultados de Cursos de Graduação e Pós-Graduação incluindo Matéria sobre o LINX Clarisse Sieckenius de Souza Resultados de Participação em Projetos Internacionais Clarisse Sieckenius de Souza Resultados de Desenvolvimento de Programas Clarisse Sieckenius de Souza Resultados de Documentação Clarisse Sieckenius de Souza

LINX - Relatório Final de Projeto - p. 2


Parte III

Concepção Geral de um SIBC LINX Equipe LINX

Um SIBC LINX Interação no Ambiente LINX (L.S.García e C.Vendrami Neto) Ontologias de Domínio e Base Lexical (M.C.P Dias, V.S.T.D.B. Quental e D.A.S. Oliveira) Base de Conhecimentos - Extrato Representativo A Implementação do Provador (por D.A.S. Oliveira) Especificações Originais das Gramáticas de Interpretação e Geração (V.S.T.D.B.Quental e L.S.García) Dos Rumos do LINX - Um shell para SIBC's (C.S.de Souza)

Parte IV

Apreciação Final Clarisse Sieckenius de Souza

Referências



Equipe LINX

Caetano Vendrami Neto Clarisse Sieckenius de Souza (Coordenadora) Daniel Wyllie Rodrigues (1995-1996) Denise Aboim Sande e Oliveira Laura Sánchez García Maria Carmelita Pádua Dias Paulo Francisco Sedrez (1997) Violeta de San’Tiago Dantas Barbosa Quental

Colaboradores Históricos

Donia R. Scott Letícia Sicuro Correa Margarida Basílio Maria das Graças Volpe Nunes

Colaboradores Correntes

Edward Hermann Haeusler Josafá Carlos de Siqueira, SJ Marcelo Gattass

Apoios ao Projeto

CNPq TeCGraf PUC-Rio, Informática PUC-Rio, Letras CEFET-Pr, PPGTE CITS

Agradecimentos

O Projeto agradece ao CNPq, pelo apoio financeiro concedido, e ao TeCGraf, sem cuja cessão de recursos humanos especializados a

implementação do ProTeoS não seria possível. Agradece também ao Pe. Josafá, do Departamento de Geografia da PUC-Rio, por ter sido o

especialista consultado para a construção da base “Frutas Brasileiras”. A Coordenação do Projeto agradece de maneira especial ao Prof.

Marcelo Gattass, pela confiança, e a todos os participantes - Laura, Caetano, Carmelita, Violeta, Denise e Sedrez - que, movidos pelo

entusiasmo, pela competência individual, pela responsabilidade e pela valiosa amizade e fé no que virá, tornaram tudo o que está aqui relatado

uma realidade.



Índice PARTE I.............................................................................................................................. 6

Sobre Sistemas de Informação Baseados em Conhecimento, suas Interfaces e sua Abrangência .................................................................................................................... 7

Sobre Sistemas Automáticos e Sistemas Formais ...................................................... 8 Um Estudo de Caso Simplificado, mas Exemplar .................................................... 11

PARTE II .......................................................................................................................... 18 A Razão de Ser do LINX.............................................................................................. 19

Um Breve Histórico deste Projeto Integrado ............................................................ 20 Resultados de Publicações e Apresentações em Congressos e Conferências........... 22 Resultados de Cursos de Graduação e Pós-Graduação incluindo Matéria sobre o LINX......................................................................................................................... 24 Resultados de Participação em Projetos Internacionais............................................ 24 Resultados de Desenvolvimento de Programas ........................................................ 24 Resultados de Documentação ................................................................................... 25

PARTE III ......................................................................................................................... 26 Concepção Geral de um SIBC LINX............................................................................ 27

Um SIBC LINX ........................................................................................................ 27 Interação no Ambiente LINX (L.S.García e C.Vendrami Neto) .............................. 28 A Implementação do Provador (por D.A.S. Oliveira) .............................................. 44 Especificações Originais das Gramáticas de Interpretação e Geração (V.Quental e L.S.García)................................................................................................................ 50 Estruturação e Controle de Discurso......................................................................... 69 Dos Rumos do LINX - Um shell para SIBC's (C.S.de Souza) ................................. 69

Apreciação Final ........................................................................................................... 74 Referências.................................................................................................................... 75



PARTE I



Sobre Sistemas de Informação Baseados em Conhecimento, suas Interfaces e sua Abrangência Sistemas de Informação Baseados em Conhecimento (SIBC's) definem-se no âmbito deste projeto como aplicações computacionais destinadas a (i) armazenar, (ii) recuperar, (iii) realizar inferências sobre e (iv) arquirir novos conhecimentos. Estes, por sua vez, são informações de natureza factual ou conceitual. SIBC's são, portanto, aplicações específicas da área de Inteligência Artificial (IA), e, no Projeto LINX, recebem um tratamento voltado para questões de usabilidade. As investigações realizadas no projeto visam, pois, obter respostas para as seguintes perguntas: a) Quão robusto é um SIBC? b) Quão útil é um SIBC? c) Quão fácil de usar é um SIBC? d) Quão agradável de usar é um SIBC? A robustez de um SIBC está fundamentalmente aliada à robustez do raciocinador nele embutido, relevadas as considerações sobre a correção dos programas que implementam os diversos módulos da aplicação. Robustez computacional do raciocínio tem sido tradicionalmente a vantagem associada ao uso de representações e manipulações de conhecimento baseadas em Lógica, de vez que a axiomatização de domínios e os mecanismos de prova sobre ela aplicados levam a cálculos simbólicos de correção formalmente comprovável. A utilidade de um SIBC depende não apenas da quantidade e qualidade dos conhecimentos incluídos na base da aplicação, mas também, e de maneira determinante, do espectro de variações a que se presta a base original, no sentido de resistir a inclusões, exclusões e alterações de conhecimentos nela contidos. Ainda como fator fundamental de utilidade, figura a resistência da base à construção a partir "do zero" da representação de um novo domínio do mesmo tipo que o original. Em ambos os casos, a aplicação é de fato tão útil quanto a possibilidade de acomodar o novo. Uma peculiaridade dos SIBC's é o fato de que o novo deve não apenas poder ser representado na base e manipulado pelo raciocinador, como também, e imprescindivelmente, apresentado para o usuário e oferecido a suas interações. A situação não é, a rigor, diferente do que em qualquer outra aplicação útil no sentido aqui defendido; porém, ela se torna tanto mais complexa na medida em que herda inevitavelmente a complexidade da computação simbólica e das nuances semânticas inerentes a aplicações de IA. Facilidade de uso, em SIBC's, diz respeito aos códigos de interação oferecidos aos usuários para questionar, sondar, adicionar, excluir e modificar conhecimentos da aplicação. Sendo questionar e sondar atividades caracteristicamente assentadas sobre discurso, é comum (e, na realidade, esperado) que um dos códigos da interface de usuário seja a linguagem natural (LN), o sistema discursivamente mais rico e sofisticado que



existe. Porém, dados os limites formais de computabilidade das línguas humanas, à parcela computável de LN, as interfaces de SIBC's acrescentam outros códigos (de natureza visual ou textual, tipicamente), disponibilizando uma interação em multimeios [Maybury'93]. Finalmente, julgamentos sobre o quão agradável é usar SIBC's são dependentes de fatores, entre outros, estéticos e ergonômicos associados a idiossincrasias psicossociais e físicas dos usuários visados. Na impossibilidade de um único esquema externo de apresentação da interface do software agradar igualmente a todos, a solução encontrada por quase todas as aplicações comerciais de hoje, SIBC's ou não, é a de possibilitar a sintonia fina de parâmetros de layout, funcionalidade e interatividade, de modo a que a apresentação da aplicação esteja maximamente ajustada aos gostos e necessidades dos usuários. As considerações acima indicam a existência de importantes desafios de usabilidade para SIBC's, cujas soluções só podem ser realmente avaliadas mediante extensos e consistentes testes empíricos. Ora, a viabilidade de tais testes presume obviamente disponibilidade de aplicações. Mas, conclusões sólidas e aproveitamento científico somente se podem alcançar se houver como identificar, para cada aspecto da aplicação, a origem (durante o processo de design), teórica ou técnica, do efeito observado (no processo de uso), bem como as possibilidades e conseqüências de mudanças de escolha (que resultarão em novo design da aplicação). Em outras palavras, o alcance e a qualidade dos testes de usabilidade serão sempre dependentes da sistematicidade e rigor no processo de design. Esta foi a motivação central para todo o desenvolvimento do Projeto LINX. Seu início foi marcado por uma série de pesquisas de natureza teórica, que ora se integram em um sistema de escolhas de design para que, em etapa futura, se realizem testes com usuários e aplicações reais das metodologias e técnicas dele resultantes. O principal resultado do projeto é, portanto, uma visão integrada e objetivada das etapas de construção conceitual e prática de SIBC's que pretendem exibir tais qualidades de robustez, utilidade e facilidade de uso. A qualidade estética e ergonômica não foi contemplada como as demais, por envolver a contribuição de áreas de conhecimento totalmente indisponíveis dentre os membros da equipe de projeto.

Sobre Sistemas Automáticos e Sistemas Formais O aproveitamento comercial da tecnologia de SIBC's, passadas quase três décadas do surgimento dos primeiros sistemas especialistas [Dendral; Mycin; R1], popularizou o uso de técnicas de IA para enriquecer aplicações em inúmeros segmentos da indústria de software [CACM on AI]. SIBC's de várias naturezas e distintos graus de complexidade foram desenvolvidos, mobilizando engenheiros do conhecimento para a construção de bases em diferentes domínios. O uso de shells comerciais, como o Smart Elements [Ref] e seus congêneres, facilitou o desenvolvimento de aplicações, oferecendo recursos para codificação de bases com diferentes tipos de representação de conhecimento, módulos de



aquisição de conhecimento, de explicação, de interfaces gráficas e textuais. Porém, apesar de automatizar o tratamento e desempenho destas tarefas, os shells obscurecem os problemas de fundo e as condições de solução associados ao desenvolvimento de software para IA. O problema de fundo da IA clássica é o mesmo de toda a Ciência da Computação: explorar os limites de formalização do processamento simbólico através da especificação de gramáticas ou esquemas de indução. Dito de outra maneira, este problema é equivalente a tratar, com recursos finitos, um número infinito de situações de mesmo tipo. Assim, da mesma forma que um compilador Pascal deve permitir a construção de uma quantidade indefinidamente grande de programas, ou que um editor como o MSWord™ deve permitir a escrita e gravação de uma quantidade indefinidamente grande de documentos, um shell deve permitir a construção de infinitos SIBC's. Um exame mais demorado revela que os três exemplos acima têm naturezas bem distintas. O compilador gera infinitos programas exigindo de seus usuários (os programadores) um conhecimento satisfatório da sintaxe e semântica da linguagem de programação. O editor de textos gera infinitos documentos exigindo de seus usuários (os autores) um conhecimento satisfatório da interface do aplicativo. E finalmente os shells geram infinitos SIBC's exigindo de seus usuários (divididos entre analistas de desenvolvimento e engenheiros de conhecimento, senão também os usuários finais de aplicativos gerados) um conhecimento de linguagens de programação, de representação de conhecimento e de interfaces. Ou seja, os shells são ao mesmo tempo análogos aos compiladores e aos editores de texto. Nos três casos, a capacidade de as aplicações gerarem infinitos produtos está associada à existência de mecanismos de escrita e interpretação de símbolos de entrada (ou seja, aqueles produzidos pelo usuário na interface da aplicação) os quais são processados iteradas vezes até a produção final de símbolos de saída (ou seja: o produto ou resultado da aplicação). Na Figura 1, um esquema geral de transformação simbólica, evocando a arquitetura básica de Máquinas de Turing, indica a existência de ao menos um CONJUNTO de símbolos de entrada (símbolos IN) e saída (símbolos OUT). Porém, quando têm estrutura interna e interpretações específicas, eles formam mais que um conjunto: constituem de fato uma LINGUAGEM, definida por sintaxe e semântica formais. O esquema da Figura 1 pode elucidar como interfaces gráficas de um editor como o MSWord, por exemplo, são constituídas de ao menos um CONJUNTO de símbolos gráfico-textuais, sobre os quais funções de transformação simbólica atuam para produzir outros símbolos gráfico-textuais de saída. Se, e quando, os símbolos de entrada são, mais do que um conjunto, uma linguagem, as funções de transformação são funções de tradução e interpretação lingüística, dependentes das regras de reconhecimento e geração de ambas as linguagens envolvidas (a de entrada e a de saída). Tal é, por exemplo, o caso dos compiladores e, em boa parte, o caso dos shells.



FUNÇÕES de TRANSFORMAÇÃO

Rr

Rg

símbolos IN

símbolos OUT

memória auxiliar

conjunto de estados

regras de reconhecimento/geração

dispositivo de leitura

dispositivo de gravação

Figura 1: Esquema Geral de Transformações Simbólicas O traço distintivo evidente dos shells, agora no âmbito formal, quando comparados a editores de texto ou compiladores, é que para atingir a meta de utilidade (i.e. permitir que SIBC's por eles gerados sejam extensíveis e manuteníveis pelos próprios usuários finais, através de um processo de aquisição de conhecimentos controlado pela interface), a gramática geradora de novos símbolos de representação de conhecimento na base tem de ser acompanhada de uma gramática de geração de símbolos correspondentes na interface, de acordo com funções específicas de traduação de uma linguagem para outra. Este ponto formal pode elucidar porque os processos de aquisição de conhecimento abertos pela interface de SIBC's aos usuários finais são tão restritos. Mesmo na mais didática e simplificada das ilustrações de sistemas baseados em conhecimento, o problema se configura em toda sua dimensão. Para ilustrá-lo melhor, segue um exemplo detalhado das gramáticas das linguagens de representação e de interface e potenciais problemas de usabilidade a elas associados.

Base Raciocinador

Interface

Léxico-Gramática

Parser

Interpretador

Interface

Léxico-Gramática

Parser

Interpretador

AQUISIÇÃO INTERROGAÇÃO E EXPLICAÇÃO

Figura 2: Arquitetura Mínima de um Shell para SIBC's usáveis



Um Estudo de Caso Simplificado, mas Exemplar O caso com que iremos exemplificar pontos críticos da usabilidade de shells é o da proverbial base de conhecimento sobre relações de parentesco, tão repetidas vezes utilizada em livros-texto de IA. Estaremos considendo um shell com a arquitetura mínima proposta na Figura 2. O par base-raciocinador, que é o coração de um SIBC, tem duas interfaces para usuários: uma destinada a interrogação e explicação; outra destinada a aquisição de conhecimentos. Não estão sendo considerados aqui os aspectos relativos à construção de uma base inteira (i.e. a partir de tabula rasa) os quais normalmente envolvem um considerável esforço de programação dos desenvolvedores do SIBC. O que se entende por aquisição é tão-somente o conjunto de operações de inserção, exclusão e alteração de conhecimentos dado um conjunto inicial de conhecimentos da base C, para C≠ ∅. Retomando-se o exemplo, admitamos que a linguagem de representação de conhecimentos na base contenha predicados e cláusulas de Horn tais como aparecem na linguagem Prolog [Clocksin & Mellish'81]. Isto significa que, em função de INTERROGAÇÃO e EXPLICAÇÃO, a linguagem usada pelo usuário que faz perguntas e pede explicações ao Raciocinador deve permitir as seguintes traduções:

pergunta ↔ demanda de prova

pedido de explicação ↔ demanda de caminho de prova

Em função de AQUISIÇÃO, a linguagem usada pelo usuário que fornece novos conhecimentos para a Base deve permitir as seguintes traduções:

asserçãoi → cláusula expressando fato

asserçãoj → cláusula expressando regra

Seja, portanto, o conjunto de cláusulas Prolog, abaixo, o conteúdo inicial C da diminuta base de um SIBC exemplar.

1. pai(josé,pedro). 2. pai(josé,luiz). 3. pai(joão,josé). 4. pai(joão,paulo). 5. avô(X,Y) :- pai(X,Z), pai(Z,Y). 6. irmão(X,Y) :- pai(Z,X), pai(Z,Y). 7. tio(X,Y) :- irmão(X,Z), pai(Z,Y).



Abstraindo uma multiplicidade de detalhes morfossintáticos da língua portuguesa, seja a linguagem de interface de INTERROGAÇÃO E EXPLICAÇÃO aquela constituída pelos seguintes recursos lingüísticos: Vocabulário: {∀ x | x ⊂ Predicados ∪ Constantes ∪ Variáveis-à-Esquerda} ∨ {∀ x | x ∈ {'é', 'de', 'o', 'se'} As variáveis-à-esquerda são as que aparecem `a esquerda das regras cuja enunciação é aceitável na linguagem aqui descrita. Isto significa, por exemplo, que a variável (à direita) Z, nas regras de 5 a 6 acima não fazem parte do Vocabulário em questão. De fato, tais variáveis são ocultas para a linguagem e aparecem como resultado de mecanismos anafóricos e elípticos, abundantes na linguagem natural.

Gramática: S[tSC] → SN[tSC], SV[tSC] | SN[tSC], SV[tSC], 'se', S[tSC]

SN[tSC] → 'o' , Predicado[tSC] | Constante[tSC] | Variável-à-Esquerda[tSC]

SV[tSC] → 'é', SN[tSC], SPrep[tSC]

SPrep[tSC] → 'de', SN[tSC] | 'de' , SN[tSC], SPrep[tSC] O índice subscrito [tSC] nas regras gramaticais acima refere-se a traços de sub-categorização e é o mecanismo pelo qual se abstraem refinamentos morfossintáticos (como por exemplo a concordância nominal ou a coordenação entre formantes da sentença), bem como cálculos de consistência semântica (como por exemplo a correferência ou a herança de atributos de uma ontologia). Em termos práticos, no exemplo que seguimos, a sub-categorização em regras léxico-gramaticais como: 1. sv(sverb(P1,P2,P3),SubCat) :- palavra(é,tr(verb,SubCat)), sn(P2,pred), sp(P3,const). 2. s(sent(P1,P2),SubCat) :- sn(P1,const),sv(P2,SubCat). que são uma tradução em Prolog das regras de reescritura: I. S[tSC] → SN[tSC], SV[tSC] II. SV[tSC] → 'é', SN[tSC], SPrep[tSC] permite que o usuário seja compreendido pelo interpretador da linguagem de interface se ele escrever: a. Paulo é o tio de Pedro. b. João é o avô de Luiz. A língua portuguesa, ao contrário da inglesa, por exemplo, permite a distinção entre formas interrogativas e afirmativas através da pontuação final da sentença: o ponto de interrogação é o transformador gráfico de uma asserção em pergunta (e.g. O Paulo é o tio do Pedro. vs. O Paulo é o tio do Pedro?). Esta característica sempre foi muito tentadora na



medida em que as linguagens de interrogação, resposta/explicação e aquisição aparentemente podem compartilhar uma boa porção das regras gramaticais. As funções de tradução/interpretação entre a sub-linguagem natural e a sub-linguagem Prolog (representadas por ↔ e →, nos esquemas gerais) podem ser exemplificadas, continuando com os exemplos acima, através de mapeamentos como:

(s(sent(P1,P2),SubCat)) → predicado(argumento1,argumento2). que se pode melhor avaliar através da Figura 3. Esquemas similares de transformações vão permitir também que o usuário possa utilizar as sentenças de I a VII para alimentar a base de conhecimento com os fatos e regras de 1 a 7. I. José é pai de Pedro. II. José é pai de Luiz. III. João é pai de José. IV. João é pai de Paulo. V. X é avô de Y de X é pai do pai de Y. VI. X é irmão de Y se o pai de X é pai de

Y. VII. X é tio de Y se X é irmão do pai de Y.

1. pai(josé,pedro). 2. pai(josé,luiz). 3. pai(joão,josé). 4. pai(joão,paulo). 5. avô(X,Y) :- pai(X,Z), pai(Z,Y). 6. irmão(X,Y) :- pai(Z,X), pai(Z,Y). 7. tio(X,Y) :- irmão(X,Z), pai(Z,Y).

s

sn sv

const

'paulo'

'é' sn

'o' pred

'tio'

sprep

'de' sn

const

'pedro' Paulo é o tio de Pedro ?

'?'

cláusula_com_fato(P1,P2,P3) :- s(sent(snom(P2),sverb(_,snom(_,P1),sprep(_,snom(P3))))gera_consulta :- clausula_com_fato(P1,P2,P3), write(P1,'(',P2,',',P3,').').

tio(paulo,pedro).

Figura 3: Esquema de mapeamentos e transformação de sentenças simples em cláusulas com fatos

A adição de um novo conhecimento, pela interface de AQUISIÇÃO, poderia ser realizada com a seguinte entrada do usuário:

VIII. João é marido de Maria.



Pelas regras de mapeamento da Figura 3, seria gerada sem qualquer problema a representação:

8. marido(João,Maria).

A atualização automática da base léxico-gramatical com as novas constantes e predicados permitiria ao usuário formular a pergunta: João é marido de Maria? Ele obteria com sucesso a resposta positiva, após a qual ele poderia formular, intencionalmente ou não, a pergunta: Maria é mulher de João? Por não deter em sua léxico-gramatica conhecimento sobre o item mulher, o SIBC poderia usar recursos programados na interface para emitir uma mensagem dizendo algo como: O sistema desconhece a palavra mulher. Deseja inserir conhecimento na base? Continuando a conjectura, suponha-se que o usuário decidisse incrementar a base com o seguinte conhecimento:

IX. X é mulher de Y se Y é marido de X. mapeado para a cláusula:

9. mulher(X,Y) :- marido(Y,X).

Prosseguindo no processo de aquisição, o usuário poderia acrescentar ainda outros conhecimentos como:

X. X é tia de Y se X é mulher do tio de Y. mapeado para a regra:

10. tia(X,Y) :- mulher(X,Z), tio(Z,Y). Corretamente, o SIBC assim instruído poderia exibir o seguinte comportamento em uma seqüência de asserções, pergundas e respostas:

U: Marta é mulher de Paulo. S: Adquirido o conhecimento de que mulher(marta,paulo). (10) U: Marta é tia de Luiz? S: Sim, Marta é tia de Luiz. U: Paulo é marido de Marta? S: Não. Paulo não é marido de Marta.

Esta última surpreendente resposta certamente deixaria o usuário intrigado, uma vez que é esperado que o SIBC tenha usado o fato de que Paulo e Marta são marido e mulher para concluir que ela é tia de Luiz. O diálogo hipotético a seguir mostra aspectos muito sutis e cruciais da construção de bases de conhecimento com aquisição direta do usuário.

U: Mostre que Marta é tia de Luiz. S: X é tia de Y se X é mulher do tio de Y.

Marta é mulher de Paulo. Resta saber se Paulo é tio de Luiz. X é tio de Y se X é irmão do pai de Y. José é pai de Luiz. Resta saber se Paulo é irmão de José.



X é irmão de Y se o pai X é pai Y. João é pai de Paulo. João é pai de José. Logo Paulo é irmão de José. Logo Paulo é tio de Luiz. Logo Marta é tia de Luiz.

A expressão Mostre que aparece em sentenças válidas da interface de INTERROGAÇÃO E EXPLICAÇÃO por uma regra como:

III. S[tSC] → 'Mostre que',SN[tSC], SV[tSC] o mesmo mecanismo possibilitando à interface gerar sentenças do tipo Resta saber se ... e Logo ... que são de uso exclusivo no discurso produzido pelo SIBC para o Usuário. A explicação textual do raciocínio do SIBC, na interface, deveria ser acompanhada de algum recurso de visualização da prova, no estilo do que se propõe na Figura 4.

tio(X,Y):- irmão(X,Z),pai(Z,Y).

pai(josé,luiz).

tia(marta,luiz). tia(X,Y) :- mulher(X,Z),tio(Z,Y).

mulher(marta,paulo).

tio(paulo,luiz).

irmão(X,Y):-pai(Z,X),pai(Z,Y).

pai(joão,paulo).

pai(joão,josé).

irmão(paulo,josé).

Figura 4: Visualização dos Passos Críticos da Prova de tia(marta,luiz).

Considere-se, para efeitos de ilustração, que o usuário deste exemplo percebeu que, ao ensinar ao SIBC que Marta era mulher de Paulo, ele não estabeleceu automaticamente a relação simétrica de Paulo com Marta -- a de que ele é marido de Marta. Para completar esta lacuna, o usuário poderia seguir uma de duas estratégias possíveis, ambas com importantes (e por vezes indesejáveis) conseqüências para a engenharia do conhecimento. Estratégia 1:

U: Paulo é marido de Marta. S: Adquirido o conhecimento de que marido(paulo,marta).

Estratégia 2:

U: X é marido de Y se Y é mulher de X. S: Adquirido o conhecimento de que marido(X,Y):-mulher(Y,X).

A conseqüência da primeira estratégia numa resposta para Mostre que Paulo é marido de Marta seria a inexistência de um caminho de prova, uma vez que a pergunta se referiria a um axioma (fato) contido na base. Já a conseqüência da segunda estratégia seria a existência de um caminho de prova simples, como mostra a Figura 5.



marido(paulo,marta). marido(X,Y) :- mulher(Y,X).mulher(marta,paulo).

Figura 5: Visualização dos Passos Críticos da Prova de marido(paulo,marta). A conseqüência ainda não salientada da introdução do conhecimento mulher(marta,paulo) na base é que, não importa qual das duas estratégias tenha sido escolhida pelo usuário hipotético do SIBC deste exemplo, foi a incontornável quebra da homogeneidade das explicações fornecidas pelo raciocinador para conhecimentos de natureza semelhante. Basta observar o que aconteceria se fosse solicitado ao sistema mostrar que Maria é mulher de João. Enquanto a explicação para isto forneceria uma visualização como a que aparece na Figura 6a, a explicação para a mesma pergunta, referente ao casal Marta e Paulo (ou seja mostrar que Marta é mulher de Paulo) seria diferente, como mostra a Figura 6b. No primeiro caso (6a), a explicação seria resultante de uma prova simples. No segundo (6b), não haveria prova, pois o fato estaria marcado como um axioma da base.

mulher(maria,joao) mulher(X,Y)) :- marido(Y,X).marido(joão,maria).

(9)

(8)

mulher(marta,paulo) (10)

(a) (b)

Figura 6: Visualização dos Passos Críticos das Provas de mulher(maria,joao) e mulher(marta,paulo).

A aparente irrelevância deste caso é traiçoeira pois pode obscurecer as conseqüências desta diferença para (a) as tarefas de manutenção de bases de conhecimento e (b) as tarefas de explicação de raciocínio. Para que qualquer das duas possa ser executada com apoio do SIBC (isto é, com algum grau de geração ou controle automático da construção de representações e apresentações de conhecimento), é imprescindível a existência da noção de tipo de conhecimentos (i.e. uma ontologia) e uma verificação constante de que a base cresce em conformidade com as operações de inferência e explicação permitidas sobre cada um dos tipos. Em outras palavras, é necessária a existência de um esquema de indução formal de novos conhecimentos. Como visto no exemplo, a indução de novos conhecimentos tem de ser acompanhada da indução de novos itens lexicais e, opcionalmente, de novas regras sintáticas e semânticas das linguagens de interface. Chamaremos a isto de indução de novo discurso sobre conhecimento. Não havendo tal indução, um conhecimento novo não poderia ser interrogado ou explicado sistematicamente pela interface. Esta é a razão fundamental pela qual a maioria dos SIBC's que alegam "adquirir automaticamente conhecimentos direto com os usuários" o fazem de maneira extremamente controlada e restrita, permitindo não raramente que só novos fatos (isto é, axiomas) sejam incluídos na base. Alguns permitem apenas a inclusão de novas instâncias para um subconjunto específico de tipos de conhecimento integrantes de suas ontologias. Os mecanismos de supervisão de efeitos colaterais de cada inclusão controlada garantem que não fica comprometida a geração



automática de textos explicativos, nem tampouco a interpretação de consultas sobre os novos tópicos. Este extenso exemplo, embora sobre uma base diminuta, servirá de referência para a apresentação dos resultados correntes do Projeto LINX, da apreciação que deles fazemos, e dos caminhos de pesquisa que pretendemos seguir a partir do ponto em que ora nos encontramos.



PARTE II



A Razão de Ser do LINX O simplificado exemplo apresentado anteriormente deve ter destacado aspectos fundamentais envolvidos na produção de software para SIBC's. Como sugerido na Figura 2, a arquitetura mínima de um SIBC usável é em si bastante sofisticada. Porém, mesmo com um conjunto de linguagens de interface (textuais e visuais) razoavelmente fáceis de entender e usar, o exemplo mostrou que a geração automática de novos conhecimentos, e dos esquemas de interrogração e explicação dos quais eles podem participar tão logo são inseridos na base, depende de esquemas de indução de numerosos recursos simbólicos, dentre os quais figuram preponderantemente:

1. um construtor/mantenedor de ontologias (i.e. de formas e estruturas canônicas permitidas na base)

2. um construtor/mantenedor de lexicalizações (alternativas, preferenciais, correlatas) de cada (novo) item das ontologias

3. um construtor/mantenedor de fatos e regras do domínio (i.e. da base de conhecimento, propriamente dita)

4. um construtor/mantenedor de lexicalizações (alternativas, preferenciais, correlatas) para fatos e regras da base de conhecimento

5. um construtor/mantenedor de formas gramaticais aceitáveis como enunciados da linguagem de interrogação

6. um construtor/mantenedor de formas gramaticais aceitáveis como enunciados da linguagem de explicação

7. um construtor/mantenedor de formas gramaticais aceitáveis como enunciados da linguagem de aquisição

Vale ressaltar algumas distinções nem sempre claras sobre os itens acima. Primeiramente, estabelece-se uma diferença entre ontologia e base de conhecimento. A percepção de que ambas as coisas são idênticas é a razão pela qual, no exemplo de aquisição do fato Maria é mulher de Paulo, aconteceu uma duplicidade totalmente indesejável na representação (e conseqüentemente na explicação) do raciocínio que o SIBC pode seguir para responder a Mostre que [Alguém] é mulher de [Alguém]. Havendo uma ontologia que governa a representação de conhecimentos na base, ela seria obviamente usada para impor a aquisição da forma canônica deste conhecimento, já existente na base (na forma mulher(X,Y) :- marido(Y,X).), obtendo através de meta-inferências ou de interação com o usuário o conhecimento sobre qual o valor correto da variável Y no predicado marido(Y,X). O efeito da ontologia vem do fato de que nela marido é uma relação básica, ao passo que mulher é uma relação derivada (e não se pode adquirir conhecimento derivado sem a aquisição simultânea de sua base). É também pela existência de ontologias que as explicações de raciocínio podem tornar-se homogêneas e ser, por isto, automatizadas, sem maior prejuízo de legibilidade e compreensão. A segunda distinção a ser ressaltada é a de que, a despeito do exemplo sugerir que as linguagens de explicação, interrogação e aquisição são idênticas (porque nelas aparecem



praticamente as mesmas estruturas lexicais e sintáticas), uma análise mais fina mostra que isto não é verdade. Trivialmente mostra-se que a existência de sentenças como Mostre que Maria é mulher de Paulo na linguagem de explicação ou de aquisição causaria erros de comunicação importantes na interface. No caso da linguagem de explicação, o gerador dos textos (i.e. das respostas explicativas) é sempre o sistema. Dificilmente faria sentido que o sistema se dirigisse ao usuário com uma sentença como Mostre que Maria é mulher de Paulo. Tal situação só seria pensável se o sistema fosse capaz de avaliar a demonstração de conhecimento dada pelo usuário, ou seja: a sua explicação para a interpelação do sistema (o que constituiria uma aquisição bastante sofisticada de conhecimento). Já a não inclusão de formulações lingüísticas do tipo Mostre que [...] na linguagem de aquisição garante a consistência mínima da lógica dos atos de fala [Searle'75] que se executam pela interface de aquisição: o sistema não pode ser solicitado a demonstrar um conhecimento de que ainda não dispõe. A geração de novos conhecimentos e de novo discurso sobre eles exige um alto grau de automatização na extensão das linguagens (de interface e de base, podendo também atingir as ontologias). Enquanto os processos não forem automatizados, o engenheiro de conhecimento será o único agente capaz de aumentar consistentemente a inteligência do SIBC, para cobrir novos fatos e regras do domínio. O impacto desta dependência de um recurso humano fala por si no cenário atual da indústria de software. Entretanto, também falam por si as complexidades teóricas até aqui discutidas. O Projeto LINX vem, desde 1988, investigando parcelas deste quadro geral, no intuito de conseguir oferecer como produto usável de software, a médio prazo, SIBC's construídos pelo shell LINX. Este relatório de projeto contém o estado atual das pesquisas que prosseguem no caminho desta meta-maior. Um fator estimulante adicional é o de que as linguagens de interface não podem ser herdadas de aplicações similares desenvolvidas em qualquer país estrangeiro, de vez que a dependência lingüística e cultural deste tipo de software, relativamente à comunidade de usuários que visa atender, é patente. Em seu bojo, este fator acarreta outro, igualmente estimulante, que é a natureza intrinsecamente interdisciplinar da pesquisa, da qual têm de participar lingüistas locais.

Um Breve Histórico deste Projeto Integrado Em 1995, a Coordenadora do Projeto LINX submeteu ao CNPq um Projeto Integrado que almejava transferir os conhecimentos acadêmicos de então, contidos em uma dúzia de teses e dissertações de Informática e Lingüística, para uma aplicação real. Na ocasião, o TECPAR (Instituto de Tecnologia do Paraná) mostrara interesse em trabalhar com a equipe do LINX para desenvolver um SIBC para o setor de saúde pública do Estado do Paraná. O CITS (Centro Internacional de Tecnologia de Software) apoiaria também o projeto, cedendo recursos disponíveis em Curitiba. O Projeto Integrado, atendido e protocolado sob o número 523499/95-7, ofereceu para a equipe os seguintes recursos: • 2 bolsas de iniciação científica (IC) • R$5000,00



Tanto o TECPAR quanto o CITS diminuíram drasticamente o seu apoio ao projeto quando o cliente que encomendara o desenvolvimento do sistema teve de suspender o acordo por causa de cortes de verbas e mudanças de prioridades. Restaram 2 bolsistas de IC, um trabalhando no Paraná e um trabalhando no Rio de Janeiro, que assim como os demais membros da equipe ficaram em espera sobre o que fazer com recursos virtualmente inexistentes e a falta de uma encomenda real de produto. A esta altura, uma implementação demonstrativa de um SIBC LINX já estava disponível como resultado das teses de doutorado de 3 dos integrantes da equipe de pesquisa: 1 Maria Carmelita Pádua Dias (Letras'94) 2 Violeta San Tiago Dantas Barbosa Quental (Letras'95) 3 Laura Sánchez Garcia (Informática'95) Esta implementação era parcial e não continha um real provador de teoremas como raciocinador. O comportamento do provador era simulado por meio de templates de provas e teoremas típicos do que o futuro provador viria a gerar. Já estava em curso o programa de doutoramento de Denise Aboim Sande e Oliveira, sob orientação da Coordenadora do Projeto, cuja meta é a de propor uma linguagem multimodal de interface e um sistema de representação/elaboração de conhecimento que garantam qualidade da base e produtividade na interação usuário-SIBC [Oliveira'96a]. O trabalho envolve, de fato, a especificação completa de um provador de teoremas, sua implementação e integração à interface proposta por García [García'95]. A opção da coordenação do projeto, em acordo com os membros da equipe do Rio de Janeiro e do Paraná, foi reformular as metas originais e ter como novo objetivo: subsidiar pesquisas futuras sobre a usabilidade de interfaces em linguagem natural para sistemas de informação baseados em conhecimento e sobre as facilidades de aquisição de conhecimento integradas à (re)programação da interface por parte de usuários finais. (LINX'96) A reformulação foi relatada e submetida à aprovação do CNPq em agosto de 1996, juntamente com o pedido de renovação das 2 bolsas de IC. Conseguidas a aprovação e a renovação de bolsas, a equipe de Projeto dedicou-se integralmente a completar a implementação de uma nova base demonstrativa, de fato um novo SIBC LINX, para exibição no II Encontro de Processamento Computacional de Português Escrito e Falado, realizado junto ao XIII Simpósio Brasileiro de Inteligência Artificial. A base versava sobre uma sub-área da Botânica (Frutos) e foi alimentada por um especialista do Departamento de Geografia da PUC-Rio (Dr. Josafá Carlos de Siqueira,SJ). Em outubro/novembro de 1996, porém, um dos bolsistas de IC (Daniel Wyllie Lacerda Rodrigues) abandonou o projeto e não houve possibilidade de repassar a sua bolsa para outro aluno. Em dezembro de 1996, porém, chegou ao grupo a notícia da liberação de verba para a aquisição de material. A verba foi utilizada para a aquisição de um computador LAPTOP, capaz de ser usado pelos diferentes membros da equipe, em



diferentes localidades físicas, e isto agilizou o processo de implementação das metas de projeto. Poucos meses depois, um acordo entre a coordenação do Projeto LINX e o Coordenador do Laboratório de Tecnologias de Software (TeCGraf) do Departamento de Informática da PUC-Rio deu novo e definitivo impulso ao LINX, na medida em que o TeCGraf disponibilizou um programador profissional para implementar o provador de teoremas dos SIBC's LINX. Assim é que, nos últimos 4 meses de projeto, com um equipamento portátil e um programador senior trabalhando na escrita de bibliotecas ANSI C (portáveis) para o provador de teoremas, o LINX conseguiu reunir uma série de resultados parciais, dos quais damos conta adiante.

Resultados de Publicações e Apresentações em Congressos e Conferências A equipe do Projeto LINX atingiu, no biênio entre agosto de 1995 e julho de 1997, os seguintes resultados. 1 Publicações em Anais de Conferências Internacionais Oliveira,D.A.S.; de Souza,C.S.; Haeusler,E.H. (1996) Structured Argument

Generation in Logic Based KB Systems. In Proceedings of ITALLC'96 (Second Conference on Information-TheoreticApproaches to Logic, Language, and Computation Regent's College, London. 21-24 July, 1996 pp.173-181

2 Publicações em Anais de Conferências Nacionais de Souza,C.S.; García,L.S.; Dias,M.C.P.; Quental,V.S.D.B.(1996) LINX: O Papel da

Linguagem Natural na Representação, Explicação e Aquisição de Conhecimentos em Sistemas de Informação. Anais do II Encontro para o Processamento Computacional de Português Escrito e Falado. Curitiba,Pr. 21-22 de Outubro de 1996. PPGTE-CEFET-PR. pp.29-39

García,L.S.; Dias,M.C.P.; e Quental,V.S.T.D.B. (1995) LINX - um ambiente integrado

para usuários de sistemas de informação baseados em conhecimento. Anais do G.T. de Linguística Aplicada do IX Encontro da ANPOLL, 1995.

3 Palestras e Apresentações em Eventos Internacionais “LINX: un lenguaje integrado de interacción hombre-máquina” (autoria de Laura

Sánchez Garcia, Maria Carmelita Dias e Violeta Quental), comunicação apresentada no V Simpósio Internacional de Comunicación Social, promovido pelo Centro de Lingüística Aplicada do Ministério de Ciencia, Tecnologia y



Medio Ambiente de Cuba, realizado em Santiago, Cuba, de 22 a 25 de janeiro de 1997 (resumo publicado)

4 Palestras e Apresentações em Eventos Nacionais Panorama do Processamento de Linguagem Natural no Brasil. (Palestra Convidada

de Clarisse Sieckenius de Souza). II Encontro de Processamento Computacional de Prtuguês Escrito e Falado. Curitiba,PR. 21 e 22 de Outubro de 1996.

Sistema LINX: Uma Linguagem de Interação Homem-Máquina, (autoria de Laura

Sánchez Garcia, Maria Carmelita Dias e Violeta Quental). Poster apresentado na 48a Reunião Anual da SBPC, São Paulo, julho de 1996 (resumo publicado)

5 Monografias Publicadas Oliveira,D.A.S.;de Souza,C.S.;Haeusler,E.H. (1995) Converting Large Proof

Structures into Natural Language Hypertext-like Explanations. C.J.P.Lucena (Ed.) Monografias em Ciência da Computação. MCC10/95. Departamento de Informática. PUC-Rio

6 Artigo Aceito para Publicação em Livro Oliveira,D.A.S.; de Souza,C.S.; Haeusler,E.H. (s/d) Structured Argument Generation

in Logic Based KB Systems. Aceito para publicação em livro editado por L.Moss, contendo papers selecionados do ITALLC'96. Esta versão estende consideravelmente a parte de exemplos e de detalhes sobre o funcionamento do provador, relativamente ao trabalho homônimo apresentado no ITALLC'96 [Oliveira,D.A.S.; de Souza,C.S.; Haeusler,E.H. (1996)].



Resultados de Cursos de Graduação e Pós-Graduação incluindo Matéria sobre o LINX 1 No Departamento de Letras da PUC-Rio Curso Nível Professor Período Introdução às Linguagens de Interface Curso Graduação -

PUC-Rio M. Carmelita Dias e Violeta Quental

1996.1

Introdução à Lingüística Computacional Curso Graduação - PUC-Rio

M. Carmelita Dias 1996.2

Introdução à Lingüística Computacional Mini-Curso - VI Encontro da ASSEL-Rio

M. Carmelita Dias e Violeta Quental

outubro 96

Representação da Informação Lexical Curso de Pós-graduação - PUC-Rio


1997.1

Introdução à Lingüística Computacional Curso de Pós-graduação - PUC-Rio


1997.2

2 No Departamento de Informática da PUC-Rio Curso Nível Professor Período Tópicos em Inteligência Artificial - Linguagens de Representação: Convergência entre Programação e Aquisição de Conhecimento

Curso pós-graduação - PUC-Rio

Clarisse Sieckenius de Souza

1997.1

Lingüística Computacional Interativa Curso pós-graduação - PUC-Rio

Clarisse Sieckenius de Souza

1996.2 e 1997.2

Resultados de Participação em Projetos Internacionais 1 Participação no Projeto UNL-Brasil Duas integrantes da Equipe do Projeto foram, em razão direta de sua experiência com a pesquisa realizada sobre Processamento de Linguagem Natural no LINX, convidadas para integrar o Projeto UNL-Brazil. O Projeto é uma iniciativa da Universidade das Nações Unidas, em associação com o segmento empresarial japonês, que tem por objetivo desenvolver uma Universal Networking Language, espécie de Esperanto para a Internet, a qual servirá de inter-língua para a tradução entre (idealmente) todas as línguas em uso na World-Wide Web. Laura Sánchez García foi uma das primeiras convidadas a integrar o Projeto UNL Brasil (coordenado por Eduardo Tadao Takahashi, ex-RNP/CNPq) e Clarisse Sieckenius de Souza foi recentemente convidada para ser parte do Conselho de Consultores do Projeto.

Resultados de Desenvolvimento de Programas 1 Demo LINX exibido no II EPCPEF 2 Nova Interface LINX (em fase final de implementação) 3 Provador LINX (em fase final de implementação)



Os arquivos referentes às 3 implementações (completas ou parciais) estarão disponíveis e constantemente atualizados na Internet, a partir da página do projeto, na URL: http://www.inf.puc-rio.br/~linx/.

Resultados de Documentação 1 LINX - Concepção Geral de um SIBC LINX (integra este relatório)



PARTE III



Concepção Geral de um SIBC LINX

Equipe LINX

Caetano Vendrami Neto Clarisse Sieckenius de Souza

Denise Aboim Sande e Oliveira Laura Sánchez García

Maria Carmelita Pádua Dias Violeta de San Tiago Dantas Barbosa Quental

Um SIBC LINX Um SIBC LINX é um sistema de informação baseado em conhecimento cujo raciocinador é um provador de teoremas em Dedução Natural (DN), completo e consistente, que gera provas na forma normal. Ele trabalha sobre uma base de axiomas em Lógica de Primeira Ordem (LPO), representados em notação pré-fixada, sem quaisquer outras restrições sintáticas sobre as fórmulas. O usuário de um SIBC LINX tem a sua disposição uma interface capaz de aceitar perguntas e fornecer explicações utilizando meios gráficos e textuais. Os meios gráficos são aqueles disponibilizados por interfaces WIMP típicas para ambiente MSWindows [Microsoft'95], e os meios textuais são essencialmente um subset da língua portuguesa falada no Brasil (LpN). A atividade simbólica central do ambiente LINX [García'95] é um processos de conversões sucessivas de enunciados do usuário (em LpN) em fórmulas lógicas (na LPO) e de estruturas de prova (geradas por DN) em textos linearizados (em LpN). Na Figura 7 apresenta-se a arquitetura geral deste ambiente.



Gerenciador de Interações

Interpretador Gerador

Planejador de RespostasSolicitador de Provas

perguntas respostas

textoenunciado

sentenças básicase estruturas conceituais

Demandas de Prova Árvores de Prova

Estruturas RST rotuladas

Raciocinador Automático

Figura 7: Arquitetura Geral do Ambiente LINX

A linha mestra de um SIBC LINX é a construção integrada das linguagens de interface e representação de conhecimento, de tal modo a haver mapeamentos sistemáticos entre a estrutura de predicados, proposições e fórmulas da LPO, por um lado, e a semântica lexical, estrutura sintática, retórica e informacional de enunciados em LpN, por outro. Tal sistematicidade permite que se proponham métodos de desenvolvimento integrado de bases e interfaces de um SIBC LINX.

Interação no Ambiente LINX (L.S.García e C.Vendrami Neto) A interface LINX é constituída de três áreas básicas: a janela de consulta, a janela do discurso e a janela da resposta (v. Figura 8, p.20). Estas três janelas são passíveis de ativação pelo usuário de maneira arbitrária; em outras palavras, o usuário pode compor consultas utilizando, de forma integrada e sem ordem fixa, os diferentes recursos por elas oferecidos. A interação começa quando o usuário seleciona ou o primeiro menu de palavras ou a entrada direta (type-ahead) de consultas. Enquanto compõe a consulta por meio da seleção de palavras em menus dinâmicos subsequentes, o usuário detém o controle da interação. No final do processo de composição, o usuário é obrigado a disparar o envio da consulta ao sistema de maneira explícita. Quando a consulta é formulada por type-ahead, ela é analisada pela mesma gramática que analisa e gera os menus. Se a consulta não tem sucesso na análise, a sequência de



palavras até a última palavra correta, inclusive, é devolvida como feedback. Ao mesmo tempo, é oferecido ao usuário um contexto de menus correspondente à escolha seguinte à última palavra analisada com sucesso, obrigando-o a se utilizar do apoio dos menus para fechar a consulta de maneira válida. Iniciado um novo contexto (pela efetivação de um ato de consulta bem sucedido), a estrutura do discurso é exibida para o usuário, na janela correspondente, de maneira a permitir que as sentenças proferidas até o momento corrente sejam passíveis de seleção e (re)ativação (v. Figura 9, p. 21). Sentenças com referência - anafórica ou elíptica - podem ser incorporadas à consulta de forma dinâmica, ao longo do processo de sua composição (seja via menus, seja via type-ahead), por meio da seleção e ativação (posicionamento do mouse na opção correspondente e pressão do botão esquerdo do mouse) de uma subárvore ou sentença específica, e da subsequente efetivação da entrada da consulta (de maneira idêntica à finalização da entrada por menus ou type-ahead). Este recurso traz, além das vantagens relativas à facilitação do processo de interpretação (pela explicitação do tópico e do foco do discurso), vantagens computacionais, na medida em que as sentenças pertencentes ao contexto corrente não precisam ser re-interpretadas. De posse da consulta, o sistema interpreta a mesma, atualizando o contexto do discurso. O sistema passa a sentença lógica ao provador, recebe resposta deste, analisa-a e entra em um processo (eventualmente iterativo) de elaboração de perguntas adicionais que têm por objetivo a obtenção do conhecimento necessário à elaboração de respostas finais cooperativas. O controlador de interface envia a prova ao gerador de respostas, que, a partir da resposta sintética ou da estrutura simplificada da prova recebida do provador (resposta Sim/Não ou Qu_ e explicação, respectivamente), constrói a resposta apoiando-se em estruturas RST (Rethorical Structure Theory [Mann and Thompson'87]) e em uma posterior linearização, enviando-a ao controlador de interface, que a exibe na janela correspondente, juntamente com as âncoras que marcam os trechos da explicação passíveis de detalhamento (v. Figura 10 p.21). O usuário pode utilizar as âncoras de maneira análoga à estrutura do discurso, isto é, incorporando-as dinamicamente à consulta em construção.

A Gramática Implementada Devido a imposições computacionais (viabilidade dos menus), a gramática implementada difere substancialmente daquela especificada. Por esse motivo, são descritos, aqui, os seus aspectos distintivos. A Gramática do LINX é uma gramática gerativa. As regras são implementadas como DCGs (Definite Clause Grammars [Pereira and Warren'80]). As regras são geradas por meio da chamada do predicado phrase, que é utilizado, também, para verificar se uma



sentença é sentença da linguagem definida pela gramática e para gerar todas as palavras possíveis para a próxima posição da sentença em construção. As regras têm, como um de seus argumentos, o nível da gramática, que pode assumir os valores: “classes”, “chaves” e “completa”. Estes níveis foram definidos de forma a viabilizar (do ponto de vista computacional) a entrada por menus. A subgramática de classes tem a função de restringir o espaço de sentenças possíveis na geração do menu de itens lexicais na construção de consultas. A subgramática de chaves define um espaço maior, mas ainda restrito em relação à gramática completa. A subgramática completa é a gramática entendida no sentido estrito. As três gramáticas determinam as palavras a comporem o espaço de solução para o menu subsequente a um dado instante da elaboração de consultas. As classes seriam as classes gramaticais propriamente ditas, como “substantivo” ou “artigo definido”. Substantivos seriam expandidos em chaves, como “planta”, “bananeira” e “abacate”, que, na gramática completa, assumiriam os traços morfológicos, como em “planta” e “plantas”. Artigo definido corresponderia ao item “o” na gramática de chaves e, na gramática completa, se expandiria em “o”, “a”, “os” e “as”.

Consultas no Domínio de Aplicação da Versão Atual A seguir são relacionadas algumas consultas (com suas respectivas respostas) geradas pela gramática no domínio de aplicação da versão atual. P1: a) O que é uma [planta]? b) O que é uma [fruta]? c) O que é uma [relação com planta]? R1: a) Uma [planta] é uma [morfologia] da família das [família], do gênero [gênero], de

classificação científica [classificação científica], originária do [origem]. b) Uma [fruta] é um fruto da [planta], [morfologia] da família das [família], do gênero

[gênero], de classificação científica [classificação científica], originária do [origem] (...)

(A [fruta] é [consistência], [no. De carpelos], [deiscência], [forma] e [tipo]., quando solictada informação adicional)

a) Um [relação com planta] é ... (definição do dicionário, para perguntas sobre os conceitos semânticos constantes do Léxico)

Exemplos: a) O que é uma bananeira?



Uma bananeira é uma palmeira da família das musáceas, do gênero musa, de classificação científica musa_sapientum, originária do Sudeste Asiático e das Américas. a) O que é um abacate? Um abacate é um fruto do abacateiro, árvore da família das lauráceas, do gênero persea, de classificação científica persea_gaentin, originária da América. (...) O abacate é carnoso, unicapelar, deiscente, ovoide e drupa. (varredura de argumentos) a) O que é um fruto? Um fruto é a parte de uma planta ... (definição do dicionário) P2: Quais os tipos de fruto/pseudo_fruto? R2: Os tipos de fruto são: baga, drupa e esperídio. Os tipos de pseudo_fruto são: simples, composto e múltiplo. P3: a) O [fruta] é um [relação_com_planta_1] ou [relação_com_planta_2]? b) O [fruta] é [consistência_1/no_de_carpelos_1/desicência_1/forma_1/tipo_1] (ou

[consistência_2/no_de_carpelos_2/desicência_2/forma_2/tipo_2])? c) O [fruta] é [indeiscente/simples/composto/múltiplo] tipo [tipo1] (ou tipo [tipo_2])? (o tipo é associado a cada uma das categorias acima.) Exemplos: a) O abacate é um fruto (ou um pseudo-fruto)? b) O abacate é carnoso (ou seco)? c) O abacate é indeiscente tipo cariose (ou tipo sâmara)? (respostas possíveis: uma das alternativas, nenhuma, ambas, correção de

pressuposição. As perguntas necessárias à composição destas respostas alternativas são geradas pela interface.)

Este esquema de perguntas também deve atender a consultas sobre types de

conhecimento, como por exemplo: As drupas são secas? P4: O [fruta] tem casca [textura_1/cor_1/de_pelugem_1/resistência_1/resina_1/grossura_1] (ou [textura_2/cor_2/de_pelugem_2/resistência_2/resina_2/grossura_2])? Exemplo P4: O abacate tem casca lisa (ou áspera)? P5: a) Qual a [forma/consistência/deiscência/tipo] de uma [fruta]?



b) Quantos carpelos tem a [fruta]? R5: a) A [fruta] é [forma/consistência/deiscência/tipo]. b) A [fruta] é [unicarpelar/bicarpelar/multicarpelar]. Exemplos: Qual a forma de um morango? O morango é cônico.

A Geração de Palavras possíveis para os Menus Seqüentes Com base na frase corrente, o algoritmo de palavras possíveis gera as palavras a comporem o menu subsequente a um dado estado da elaboração de uma consulta. Em termos gerais, o algoritmo funciona da seguinte forma:

1. Transforma a frase corrente em “sentença de classes lexicais”; 2. Procura itens lexicais que podem ser adicionados à frase na posição seguinte à

corrente; 3. Transforma a sequência de itens lexicais em sentença de gramática de chaves; 4. Expande cada chave em elementos da gramática completa; 5. Verifica gênero e número, tentando casar a frase da gramática completa,

descartando as sentenças que não casam; 6. Apresenta relação de palavras compondo o menu subsequente.

Primeiramente, o predicado phrase_lex é chamado de forma a retornar todas as classes lexicais possíveis, como pode ser visto a seguir. Suponha que a frase corrente seja [quais as características do]. Esta frase, transformada para sentença de classes lexicais, ficaria [lex_classificador1,lex_subclassificador1]. Como retorno do phrase_lex , teríamos o Conjunto X de P tal que [lex_classificador1,lex_subclassificador1,P | _]. Assim, integrariam X as classes lexicais [planta,fruta]. A partir daí seriam expandidas para Y como chaves da gramática em [abacateiro, jaqueira, ..., abacate, morango, pêssego, ...]. Cada elemento de Y seria expandido em gramática completa, adicionado ao fim da frase corrente e testado na no algoritmo da gramática. Tomando como exemplo a jaqueira e o morango: phrase([quais,as,caracteristicas,do,jaqueira|_]) [FALSE] phrase([quais,as,caracteristicas,do,jaqueiras|_]) [FALSE] phrase([quais,as,caracteristicas,do,morango|_]) [TRUE] phrase([quais,as,caracteristicas,do,morangos|_]) [FALSE]



Deste modo, as palavras possíveis para esta frase seguindo o contexto lexical acima (abacateiro,jaqueira,abacate,morango,pêssego) seriam [abacateiro, abacate, morango, pêssego] excluindo portanto [abacateiros, abacates, jaqueira, jaqueiras, morangos, pêssegos]. A palavras sem conteúdo semântico pleno, como preposições e artigos, são retornadas por um algoritmo simples associado ao conversor léxico->gramática completa. O algoritmo de geração de palavras possíveis se utiliza de uma “gramática de classes lexicais” que funciona de forma semelhante à gramática propriamente dita, ou seja, como DCG. A diferença está nos grupos de palavras definidas e na utilização de regras de léxico. Esta é a única variação (adição) substancial do Léxico implementado em relação ao modelo de Léxico da especificação original [García]. Um exemplo de frase gerada pelo léxico, através do predicado phrase_lex, é o seguinte: lex_classificador1, lex_subclassificador2, lex_fruta sendo que um lex_classificador1 é a chave léxica “qual”, e um lex_subclassificador pode ser “tipo”, “caracteristica” e lex_fruta pode ser qualquer fruta definida neste conjunto do Léxico. A frase gerada seria então: qual,tipo,[fruta] qual,característica,[fruta] Após a geração de frases neste formato, elas são mapeadas para palavras-chave da gramática de chaves, ficando: Qual,tipo,abacate Qual,tipo,morango Qual,caracteristica,pessego Estas “frases lexicais” são então transformadas em frases gramaticais correntes através do algoritmo de palavras possíveis. Está em estudo (sendo questionada), na etapa atual, a real necessidade do uso dos três níveis de gramática (classes, chaves e completa), em decorrência da utilização da “gramática de classes lexicais” recém descrita.

A Resolução de Referências Anafóricas e Elípticas A possibilidade de ocorrência de referência anafórica ou elíptica é aberta quando é enunciada uma consulta por meio de uma sentença completa (isto é, com tema e foco presentes).



Elipses podem ocorrer em diversos níveis, de acordo com as diferentes possibilidades de marcação de foco nas perguntas Sim/Não (decrescente ao se aumentar a expressão a partir da última palavra, e da direita para a esquerda). Exemplo: O abacate é carnoso?

E indeiscente tipo X? E tipo Y?

E o morango?

Esta última interação inicia novo contexto e é mostrada a nova consulta completa “O morango é indeiscente tipo y ?”, como caso default. Opcionalmente, pode haver manipulação direta do discurso anterior (através de checkboxes, presentes na Figura 9 p.21) e assim integrar-se à nova consulta estruturas selecionadas da janela do discurso. Ao se abrir, portanto, a possibilidade da ocorrência de referência ficam automaticamente determinados, no caso de anáfora pronominal, o referente (que assume o valor do tema corrente) e, no caso de pergunta elíptica, os elementos da sentença que completam a pergunta. Este são preenchidos ao se alcançar sucesso nas verificações de pertinência do elemento instanciado na nova sentença - elíptica - ao conjunto definido pelas classes lexicais, da direita para a esquerda. No caso de ambiguidade, isto é, quando a elipse pode ser resolvida tanto pelo tema quanto pelo foco da sentença completa do contexto de discurso corrente, é colocada a ambiguidade ao usuário, solicitando-se deste uma definição. Isto não ocorre no domínio corrente do Projeto LINX, pois os objetos básicos (plantas, frutos e outros) não interagem, isto é, não podem aparecer simultaneamente nos papéis de tema e foco na sentença.



Figura 8: Layout Básico da Interface LINX

Figura 9: Instantâneo de interação depois de consulta via menus e resposta do SIBC.



Figura 10: Instantâneo da Interface LINX, entre um click sobre âncora no texto

explicativo e a efetivação da consulta interpretada pelo sistema (v. área de Pergunta Formulada)

Ontologias de Domínio e Base Lexical (M.C.P Dias, V.S.T.D.B. Quental e D.A.S. Oliveira)

Entidades gerais: FRUTOS (e suas PLANTAS) O Projeto constrói nesta etapa o segundo SIBC LINX, embora ainda em implementações parciais. O primeiro foi o proposto em [García'95], trabalho que especificou todos os mecanismos e sublinguagens da interface LINX, usando como exemplo o domínio de classificação geral dos animais. A seguir, serão apresentadas as linhas gerais das ontologias e da Base Lexical para o domínio de Frutas Brasileiras, aplicando as propostas específicas contidas em [Dias'94]. ENTIDADES ESPECÍFICAS: ABACATE, ABACAXI, ABÓBORA, ACEROLA, AMORA-PRETA, BANANA, CAJU, CASTANHA-DE-CAJU, CASTANHA-DO-PARÁ, ESPIGA DE MILHO, FEIJÃO, FIGO, JACA, LARANJA, MORANGO, NOZ-PECÃ, PÊSSEGO, PINHÃO, ROMÃ, TOMATE, VAGEM-DE-FEIJÃO.

HIERARQUIAS GERAIS



Hierarquias Gerais são as que não indicam propriedades, mas uso geral. Elas servem de orientação na representação do conhecimento, mas foram temporariamente desconsideradas na estruturação semântica porque as palavras Fruto e Fruta representam de fato duas perspectivas sobre o mesmo domínio. O tratamento de múltiplas perspectivas e ontologias é objeto de uma tese de doutorado em fase de conclusão [Oliveira'96a] e, portanto, não está implementado nesta versão do SIBC. 1a.Perspectiva - conhecimento leigo e conhecimento técnico:

<Categoria Geral Abrangente>

Fruta Fruto

Embora a notação gráfica das ontologias ainda não esteja suficientemente ajustada para marcar, sem ambigüidades, os casos de categorias lexicalizadas ou não, categorias mutuamente exclusivas ou não, e conjuntos abertos ou fechados de categorias equivalentes, ela marca algumas distinções, como por exemplo, as categorias não-lexicalizadas (através do uso de '<' e '>').



2a. Perspectiva - tipos de fruta:

<Categoria Geral da Perspectiva FRUTAS>

Legume FrutaNoz Castanha HIERARQUIAS QUE SERVEM DE BASE PARA A ESTRUTURAÇÃO SEMÂNTICA DO DOMÍNIO: 3a. Perspectiva - relação com estrutura da planta: <Categoria Geral do que Carrega a Semente>

Fruto caroçoPseudoFruto Fruto Múltiplo semente

<Categoria Geral do que se assemelha a Sementes>

4a. Perspectiva - tipos de fruto:

<Tipologia Geral dos Frutos>

seco carnosofibroso

baga drupa baga drupa

deiscentes indeiscentes

folículo legume cápsula síliqua

pixidiária septicida loculicida

aquênio cariopse sâmara

Todo domínio de um SIBC LINX se representa através de Frames, conforme proposto em [Dias'94].



Estrutura Semântica do Domínio de Frutos em Frames PROPRIEDADES DE FRUTO (GERAL) “Tipo(type)” “Relação com planta” “Planta” “Consistência” “Carpelaridade” “Casca” conexão para frame próprio RELAÇÃO DAS PROPRIEDADES (VALORES): Relação com plantas: [fruto / pseudofruto / semente / caroço] Planta: [abacateiro / abacaxizeiro / aboboreira / pé-de-acerola, amoreira-preta, bananeira, cajueiro, castanheira, feijoeiro, figueira, jaqueira, laranjeira, milho, morangueiro, nogueira, pessegueiro, pinheiro-do-paraná, romanzeira, tomateiro] Consistência: [carnoso / seco / fibroso] Carpelaridade: [unicarpelar /bicarpelar/multicarpelar] Casca: [Frame próprio: pelugem, resina, textura, cor, resistência, grossura)] Vê-se pela estrutura acima, no exemplo de "Casca", que a representação semântica do domínio é de fato uma rede de frames. Isto dá suporte a ricas representações de ontologias como discutido em [Dias'94; de Souza et. al.'96]. PROPRIEDADES DA CASCA: “Pelugem da casca” “ Resina da casca” “Textura da casca” “Cor” (da casca) “Resistência da casca” “Grossura” RELAÇÃO DAS PROPRIEDADES (VALORES): pelugem: [glabra / pilosa / aveludada] resina: [resinosa / não-resinosa] textura: [lisa / áspera / lenhosa / rugosa / verrugosa / coriácea] cor: [vermelha / amarela / verde / laranja / vermelho-escuro / vermelho-amarela / cinzenta

/ castanha / branca / verde-amarelada / castanha-rajada-de-preto / amarelada ] resistência: [delicada / resistente ] grossura: [fina / espessa]



Propriedades de PLANTAS (as árvores frutíferas): “Morfologia” “Família” “Gênero” “Classificação científica” (gênero + espécie + classificador) “Origem” RELAÇÃO DAS PROPRIEDADES: Morfologia: [árvore / trepadeira / bromélia / arbusto / palmeira / erva / erva rasteira / erva trepadeira ] Família: . . .<dados ainda não levantados no domínio> Gênero: . . <dados ainda não levantados no domínio> Classificação Científica: . . <dados ainda não levantados no domínio> Origem: [Brasil, Índia, Austrália] As entradas lexicais da interface LINX refletem as ontologias representadas pela rede de frames. O mesmo já ocorria na primeira das bases LINX - de animais - e as entradas lexicais para aquele (como também para este) tinham a seguinte configuração: BANANA - N [ __ ] SN G: Fem; N: Sing [coisa Tipo 3,2] [-ANIMADO] COME - V SNi [agente] [ __ Processo material] SNj [objeto] 3ps - Indpres DE ([Lug FORA DE ([ Coisa TIPO-ANIMADO]i)]) [Ev IR ([Coisa SÓLIDO]j, [Dir PARA([LugDENTRO DE ([Coisa BOCA DE TIPO-ANIMADO]i)])])] “alimentação” SÓLIDO = FRUTO Nela se verificam as estruturas semânticas propostas por Jackendoff [Jackendoff'90], no quarto slot da entrada, responsável pelos mapeamentos integrados das ontologias sobre os itens lexicais e sobre os argumentos e predicados das fórmulas lógicas da base.

Base de Conhecimentos - Extrato Representativo A base atual de Conhecimentos está representada através de fórmulas como as exemplificadas a seguir.



% Base de Conhecimento - Frutas Brasileiras % % Arquivo Base1Min.Txt % Ultima Atualizacao: 28 de Agosto de 1997 % Nota: % Sintaxe Logica de Primeira Ordem: % * : Quantificador Universal % # : Quantificador Existencial % ->: Implicacao % & : Conjuncao % | : Disjuncao % ~ : Negacao % PARTE I % Hierarquia I: % Dominio: Objetos Frutos % Perspectiva: Formal % Sub-Dominio: Frutos % Nota : % Axiomas gerados sistematicamente a partir da Hierarquia % Tipos de Fruto: % Nem todas as alternativas estao registradas! % * X fruto(X) -> carnoso(X) | seco(X) | ... * X carnoso(X) -> fruto(X) & ~seco(X) * X seco(X) -> fruto(X) & ~carnoso(X) % Deiscencia dos Frutos: Depende do Tipo * X fruto(X) -> deiscente(X) | indeiscente(X) * X carnoso(X) -> indeiscente(X) * X deiscente(X) -> seco(X) & ~indeiscente(X) * X indeiscente(X) -> fruto(X) & ~deiscente(X) % Frutos Carnosos: Hierarquia Nao-Exclusiva! * X carnoso(X) -> baga(X) | drupa(X)



* X baga(X) -> indeiscentes(X) & ~drupa(X) * X drupa(X) -> indeiscentes(X) & ~baga(X) % Frutos (Secos) Deiscentes: % nem todas as alternativas estao registradas! % * X deiscente(X) -> capsula(X) | foliculo(X) | legume(X) ... * X capsula(X) -> deiscente(X) & ~foliculo(X) & ~legume(X) * X foliculo(X) -> deiscente(X) & ~capsula(X) & ~legume(X) * X legume(X) -> deiscente(X) & ~capsula(X) & ~foliculo(X) % Frutos (Secos Deiscentes) Capsulas: % Nem todas as alternativas estao registradas! % * X capsula(X) -> septicida(X) | loculicida(X) | pixidiaria(X) | ... * X septicida(X) -> capsula(X) & ~loculicida(X) & ~pixidiaria(X) * X loculicida(X) -> capsula(X) & ~septicida(X) & ~pixidiaria(X) * X pixidiaria(X) -> capsula(X) & ~septicida(X) & ~loculicida(X) % Frutos Secos Indeiscentes: % Nem todas as alternativas estao registradas! % * X seco(X) & indeiscente(X) -> aquenio(X) | cariopse(X) | samara(X) | ... * X aquenio(X) -> seco(X) & indeiscente(X) & ~cariopse(X) & ~samara(X) * X cariopse(X) -> seco(X) & indeiscente(X) & ~aquenio(X) & ~samara(X) * X samara(X) -> seco(X) & indeiscente(X) & ~aquenio(X) & ~cariopse(X) % Carpelaridade dos Frutos: * X fruto(X) -> unicarpelar(X) | bicarpelar(X) | multicarpelar(X) * X unicarpelar(X) -> fruto(X) & ~bicarpelar(X) & ~multicarpelar(X) * X bicarpelar(X) -> fruto(X) & ~unicarpelar(X) & ~multicarpelar(X) % PARTE II % Instancias da Hierarquia I % Abacate carnoso(abacate) drupa(abacate)



% Abobora carnoso(abobora) baga(abobora) % Acerola carnoso(acerola) baga(acerola) % Banana carnoso(banana) baga(banana) % Castanha de Caju aquenio(castanha_de_caju) % Castanha do Para pixidiaria(castanha_do_para) % Coco da Bahia drupa(coco) % Laranja carnoso(laranja) % Pessego carnoso(pessego) drupa(pessego) % Roma carnoso(roma) baga(roma) % Tomate carnoso(tomate) baga(tomate) % Vagem de Feijao legume(feijao)



A Implementação do Provador (por D.A.S. Oliveira) Apresentação O desenvolvimento de um provador de teoremas em Dedução Natural para a Lógica Clássica que satisfizesse os requisitos de interface para bases de conhecimento começou em 1991, com o sistema EhLogico, um provador para a Lógica Proposicional implementado em Prolog. A especificação de um provador para a Lógica Clássica completa, com a possibilidade de algumas extensões na linguagem lógica, foi terminada em 1992 [Oliveira'92; Oliveira et al.'93]. Com o Projeto LINX, decidiu-se implementar uma versão do provador, na linguagem C, que pudesse se integrar à interface proposta em [García'95] e ora em fase de reprojeto. Algumas alterações na especificação original foram feitas, devido à experiência acumulada e a previsão de desenvolvimentos futuros. O resultado é um sistema robusto, multiplataforma e expansível, para uso em pesquisa e desenvolvimento de sistemas inteligentes que enfatizem a comunicação do raciocínio lógico.

Características Gerais O ProTeoS é um provador de teoremas em Dedução Natural desenvolvido especificamente para ser o raciocinador de um sistema inteligente usável com interface cooperativa. Do ponto de vista teórico, ele é um provador completo e consistente, gerando provas em Dedução Natural na forma normal [Oliveira'92; Haeusler'90; Prawitz'65]. Tais provas, por sua vez, são sistematicamente convertidas em estruturas retóricas [Nunes'91;Quental'95] que formam o plano de texto para explicações em linguagem natural. Devido ao raciocínio direto normalmente envolvido em uma prova por Dedução Natural, tais explicações são mais facilmente compreendidas do que explicações derivadas de raciocínios por contradição. Além disto, provas normais em Dedução Natural podem ser estruturadas e simplificadas, evidenciando o raciocínio lógico subjacente e simplificando consideravelmente a expressão de raciocínios longos e complexos [Oliveira et al'96]. A implementação do ProTeoS privilegia aplicações para fins de pesquisa. Seu núcleo é desenvolvido unicamente em ANSI C já prevendo migração para outras plataformas, especialmente UNIX. Trabalha sobre uma base de axiomas em Lógica de Primeira Ordem, representados em notação prefixada, sem nenhuma outra restrição sobre a sintaxe das fórmulas. Funciona como uma biblioteca, aceitando pedidos de prova para fórmulas específicas e retornando provas em Dedução Natural já simplificadas e estruturadas, ajustadas para o processo de geração de explicações. Várias medidas foram tomadas para reduzir o tempo gasto em uma prova, especialmente provas diretas, caso em que o provador é bastante eficiente. Alguns desafios permanecem, como um tratamento mais adequado para provas por absurdo, que são de compreensão inerentemente mais difícil. Futuramente está prevista a incorporação de heurísticas que reflitam os resultados de sua utilização para pesquisa e que aumentem sua eficiência para tipos específicos de bases de



conhecimento. Ainda está prevista a integração de níveis sublógicos (que expressem conhecimento específico difícil de se obter diretamente em lógica) e a expansão da linguagem (com a inclusão da igualdade e de operadores aritméticos, além da possibilidade de inclusão, segundo a necessidade, de outros operadores lógicos como por exemplo modalidades). A incorporação de um algoritmo de identificação de incompletudes no conhecimento da base, permitindo a formulação de perguntas por parte do sistema de interface, previsto na primeira especificação [Oliveira'92], também é uma possibilidade a ser pesquisada.

Algoritmo de Prova O algoritmo básico do provador se baseia no desenvolvimento de uma estrutura algébrica, a árvore de Prova para uma fórmula F em uma teoria T [Oliveira'92; Oliveira et al.'93,2]. Esta estrutura é definida por relações de transformação entre folhas e nós da estrutura, para cada uma das regras de Dedução Natural (regras de introdução e eliminação de conectivos e regra do absurdo clássico).É esta estrutura formalmente definida que garante as características teóricas de consistência e completude. Além disto, toda lógica, para a qual possa ser definida uma estrutura que mantenha estas características, pode ser utilizada no provador. Em cada nó da árvore, correspondendo a uma determinada fórmula, estão representadas todas as possíveis alternativas de prova normal em DN para esta fórmula neste contexto (posição na estrutura e hipóteses vigentes). Esta estrutura contém então de certa forma todas as possíveis provas normais para a fórmula F na teoria T. O algoritmo de prova consiste basicamente em desenvolver a estrutura de prova, utilizando as relações definidas, realizando uma busca exaustiva por uma solução (uma prova completa da raiz da árvore), garantindo um paralelismo no desenvolvimento dos diversos ramos da árvore (o que permite garantir que uma solução será eventualmente encontrada, se existir). A estrutura pode ser subdividida em dois tipos de sub-árvores: árvores de introdução e árvores de eliminação. As árvores de eliminação, por dependerem principalmente da base de conhecimento, são pré-processadas. Isto leva a uma espécie de "compilação" da base de conhecimento, redundando em grande aumento de eficiência, sem que se perca em momento algum a representação do conhecimento na forma exata em que foi expresso na base. O algoritmo consiste então simplesmente em desenvolver as relações de introdução e do absurdo clássico, ligando quando necessário com as árvores de eliminação, e em extrair as provas possivelmente resultantes. A maior parte do código é utilizada na manutenção das estruturas (de fórmula, incluindo a unificação, de árvore de prova e de prova) e na extração das provas (que exige a resolução das regras de eliminação da disjunção e do existencial, necessariamente as últimas a serem processadas e as mais complexas). No desenvolvimento e extração das provas, o código segue estreitamente a especificação da estrutura, o que simplifica tanto posteriores expansões e modificações, quanto a implementação de heurísticas.



Diferenças com relação à especificação original As principais diferenças aqui relatadas com relação à especificação original do provador residem na escolha das fórmulas mínimas e no pré-processamento das árvores de eliminação. O pré-processamento das árvores de eliminação, além de resultar em maior eficiência, permitiu a redefinição da aplicação das regras de eliminação da disjunção e do existencial, tornando-as estritamente locais, o que simplificou consideravelmente o algoritmo e tornou-o na prática totalmente paralelo (é relativamente fácil alterar a implementação para permitir o processamento paralelo em múltiplos processadores e/ou máquinas, e mesmo com múltiplas bases). A mudança no critério de determinação das fórmulas mínimas foi feita para aumentar a eficiência, ligada ao pré-processamento das árvores de eliminação. Já que a fórmula mínima é o ponto de ligação entre as (sub-) árvores de eliminação e de introdução, é interessante reduzir seu número e simplificar a aplicação da unificação entre duas árvores de introdução e eliminação. Isto foi feito definindo que só será considerada uma possível fórmula mínima uma fórmula atômica ou uma fórmula em que a negação, a disjunção ou o existencial seja o operador principal. Isto reduz notavelmente o tamanho da estrutura resultante sem prejudicar a completude. A única possível desvantagem, a eventual geração de provas com aplicações redundantes de regras, é minimizada pelo uso do algoritmo de simplificação/estruturação da prova e pode, se desejável, ser totalmente eliminada por pós- processamento da prova. Afora estas duas alterações, a especificação do provador (algoritmo, baseado na mesma estrutura original) se mantém.

Principais diferenças com relação a outras abordagens e implementações Nosso provador em Dedução Natural, ProTeoS, foi desenvolvido com um fim específico, a saber, para utilização como raciocinador no LINX e sistemas semelhantes de interface para bases de conhecimento. Para tal, a principal característica desejada é a adequação das provas resultantes à transformação em explicações em linguagem natural. Neste contexto, a eficiência é uma característica secundária, embora desejável. É este critério da qualidade das explicações geradas a partir das provas que utilizamos para comparar ProTeoS com outros raciocinadores existentes, desenvolvidos em geral com outros critérios em vista. Provadores baseados em resolução são numerosos, em geral eficientes, e a técnica já é bem conhecida e estudada. Por outro lado, do nosso ponto de vista, eles apresentam duas características bastante indesejáveis. A base de conhecimentos original, para uso na resolução, é processada reduzindo suas fórmulas a uma forma normal, que obscurece a representação original do conhecimento e a torna inacessível. Por outro lado, a prova gerada, mesmo que possa ser estruturada em forma semelhante Dedução Natural, é uma prova por contradição, que é um tipo de raciocínio de mais difícil compreensão. Explicações baseadas em um raciocinador por resolução são portanto de forma geral



inerentemente mais complexos e mais distantes da formulação original do conhecimento do que explicações usando um provador por Dedução Natural como ProTeoS. Há alguns provadores por Dedução Natural sendo pesquisados ultimamente. Do nosso ponto de vista, eles apresentam de modo geral algumas características indesejáveis. Uma delas é um tratamento deficiente da eliminação da disjunção e/ou do existencial, o que leva incompletude teórica do sistema. Outra é o fato de não gerarem provas normais. Para provas não normais, não é possível a aplicação do algoritmo de que dispomos para a transformação de provas, evidenciando o raciocínio subjacente de uma forma compacta, recursiva e pouco redundante, favorável à expressão em linguagem natural. Uma terceira característica é a utilização de outras regras de dedução que não as regras básicas da Dedução Natural (introdução e eliminação de conectivos e o absurdo clássico). Por nosso critério, tais regras são desejáveis somente se representarem uma simplificação do raciocínio envolvido na prova. Estamos inclusive pesquisando seu uso para diminuir a necessidade da aplicação do absurdo clássico. De modo geral, porém, sua utilização implica na quebra da forma normal das provas e na necessidade de heurísticas para sua aplicação, o que pode obscurecer a sistemática de prova dificultando ao usuário a compreensão do raciocínio do sistema. Não há até o momento outro provador por Dedução Natural que seja completo e gere somente provas normais, usando as regras básicas, que seja de nosso conhecimento. Há outros métodos de prova para os quais foram desenvolvidos ou especificados provadores de teoremas. Um exemplo são os métodos "semânticos" como tableaux, ou ainda jogos. Métodos de prova alternativos são interessantes especialmente por já terem sido desenvolvidos para outras lógicas como modais, paraconsistentes, etc. Embora de nosso ponto de vista só seja interessante a adoção de uma outra lógica quando seus operadores forem "naturalmente" traduzíveis à linguagem natural (cf. [Oliveira et al'96]), estamos prevendo pesquisa na direção de lógicas alternativas para aumentar a capacidade expressiva da linguagem de representação de conhecimento. Assim, provadores para lógicas alternativas são bastante interessantes para nós, visto que a extensão do método de Dedução Natural para tais lógicas requer pesquisa própria. Sabemos que para alguns dos métodos foram desenvolvidos esquemas de tradução de suas provas para provas em Dedução Natural. Não dispomos porém até o momento de dados comparativos sobre a qualidade de tais provas como base para explicações.

Desafios e desenvolvimentos futuros A principal questão a ser abordada imediatamente é o tratamento do absurdo. Visto ser bastante indesejável sua ocorrência em uma explicação, queremos reduzir ao máximo sua utilização na prova. Quando o uso do absurdo é necessário, sua expressão na explicação pode ser minimizada pelo uso do algoritmo de estruturação de provas, que permite passá-lo para uma explicação secundária. Mas ele não pode ser totalmente eliminado. Por outro lado, o tratamento do absurdo na prova é um dos principais pontos de ineficiência, em particular quando a fórmula sendo testada não é teorema da base. Assim, pesquisamos duas alternativas para a redução do uso do absurdo: sua restrição a determinados pontos



da prova (sem prejudicar a completude) e o uso de regras derivadas especiais para o tratamento de fórmulas negadas, que permitam raciocínios mais "diretos". Outros pontos de pesquisa são a extensão da linguagem lógica (com operadores modais, por exemplo) e o uso de níveis sublógicos de raciocínio. Estes níveis permitiriam a implementação de conhecimento não linguístico (tipicamente raciocínios espaciais, por exemplo) com o uso de "regras" para derivar fatos que utilizem tais conhecimentos. Por sua vez, tais fatos podem ser justificados ou explicados, a posteriori, com o uso de axiomas e teoremas que reflitam parte (expressível) deste conhecimento. Pretendemos, a partir do resultado das pesquisas utilizando o sistema LINX com o provador ProTeoS atual, investigar ainda possíveis outras formas de por um lado aumentar a expressividade do sistema (como por exemplo a capacidade de formular perguntas a partir da detecção de incompletudes pontuais do conhecimento) e por outro lado melhorar a qualidade da interação (via maior eficiência, heurísticas para geração de "melhores" provas e novas regras e operadores). A integração do próprio provador com o resto do sistema é também ponto para pesquisa, como por exemplo o desenvolvimento de metodologias de construção de bases de axiomas que levem em conta o método de prova, para produzir bases cujas provas possam transmitir de modo mais fiel o ponto de vista do formulador original do conhecimento.

Conclusão Com o término da implementação, ProTeoS é um produto acabado e flexível, destinado à pesquisa, com características teóricas únicas para utilização em sistemas de interface de bases de conhecimento. Como raciocinador do Projeto LINX, ele oferece uma base segura para a pesquisa com bases de conhecimento em Lógica de Primeira Ordem. Com a documentação, futuramente disponível, será possível sua integração em outros projetos de pesquisa. Há ainda várias possibilidades de desenvolvimento futuro no próprio provador, respondendo a necessidades levantadas pelos diversos resultados de pesquisa. Neste momento, o provador se destina a tratar os seguintes conectivos lógicos para que gerem respostas cooperativas no formato sugerido abaixo: e: P: A e B? R1: Sim V,V R2: A, mas não B. V,F R3: Não; nem A, nem B. F,F R4: A, mas não se sabe B. V,? R5: Não; não A (mas não se sabe B). F,? R6: Não (mas não se sabe qual é falso) F,? ou ?,F



ou: P: A ou B? R1: Sim, A. V,F R2: Sim; A, mas não se sabe B. V,? R3: Sim (mas não se sabe sobre A isolado e B isolado) V,? ou ?,V R4: Sim; A e B. V,V R5: Não; nem A, nem B F,F R6: Não A (mas não se sabe se B) F,? ->: P: A -> B? R1: Sim. V,V ou F,F R2: B, mesmo quando não A. V, V ou F,V (?,V)

independência R3: Não B. V,F ou F,F (?,F)

independência R4: Não (há casos não B, mas A) V,V ou V,F (V,?) irrelevância R5: Não A (mas por vezes B) F, ? irrelevância R6: Não A, mas B F,V R7: Não; A, mas não B V,F R8: Sim, A e B V,V R9: Nem A, nem B F,F ~: P: ~A? R1: A. V R2: Não A F Um tratamento bem mais sofisticado relativo à semântica dos operadores, incluídos aí os quantificadores, é objeto de pesquisa de tese de doutorado [Oliveira'96a]. É esperado que até o final deste ano, haja resultados expressivos neste campo do projeto.



Especificações Originais das Gramáticas de Interpretação e Geração (V.Quental e L.S.García) Apresentam-se a seguir as decisões de projeto das gramáticas de geração de respostas e de interpretação de perguntas no ambiente LINX. É fundamental salientar que um SIBC LINX tem sua especificação governada pelas necessidades de geração, e não de interpretação. A gramática de geração delimita o espaço de expressividade da base de conhecimentos, permitindo que haja uma coincidência máxima entre aquilo que o sistema sabe (ou pode saber) e aquilo que o usuário pode interrogar ou pedir como explicação ao SIBC. Neste sentido, encontram-se a seguir as regras vigentes para a expressão de bases em domínios classificatórios tratados pelo LINX. Os exemplos são do domínio de animais, mas aplicam-se sem maiores modificações ao domínio de frutas brasileiras. Eles foram extraídos de [Quental'95; García'95]. Perguntas tratadas em domínio classificatórios

Nos domínios LINX (animais e frutas), as perguntas serão sobre : • inclusão (de classes em super-classes ou de indivíduos em classes);

ex: Os [classe] [estado] [super-classe]? Os morcegos são mamíferos?

• propriedades de indivíduos e/ou classes ex: Algum [coisa] [evento] algum [coisa]?

Algum morcego ataca algum mamífero? Os [coisa] [estado] [propriedade]? Os morcegos são domésticos?

Estamos considerando, em domínios de tipo descritivo, como os que foram tratados, que eventos são propriedades, na medida em que os verbos aparecem sempre com aspecto atributivo, acronístico, no presente do indicativo. Desse modo, os eventos específicos de cada entidade (indivíduo ou classe) fazem parte dos seus “frames” ( informações sobre sua alimentação, suas características físicas, relações com outros animais etc). Para preservar a generalidade e a expansibilidade do sistema, foi mantida a categoria EVENTO, apesar dessa peculiaridade dependente de domínio. Como o sistema pretende ser cooperativo com o usuário, caso a pergunta receba uma resposta negativa, apresenta-se uma alternativa correta para a informação desejada. Considera-se informação desejada aquela que corresponde ao foco de dúvida do usuário, definido conforme mais adiante.

Levantamento de modelos de perguntas disponíveis na linguagem:

• Perguntas sim/não • Perguntas alternativas Exclusivas (ou) Não-exclusivas (e/ou)



Obs. Para evitar a ambiguidade inerente ao conectivo OU, incorporou-se à LPO e à gramática a distinção entre conectivos ou, para disjunção exclusiva e e/ou (XOR) para disjunção inclusiva. • Perguntas QU-

Esquemas retóricos e sintatização básica de perguntas e respostas tratadas nesses domínios

Foi definida uma relação retórica inspirada na RST, de nível acima do nível de estruturação sentencial, para dar conta da sequência do diálogo: pares de enunciados adjacentes do tipo pergunta/resposta. A essa relação nomeou-se RST Pergunta/Resposta, no caso, do tipo SIM/NÃO. Assim, o esquema geral de um par pergunta/resposta SIM/Não é: Pergunta/Resposta Sim/Não

NúcleoPergunta

[a fórmula F é verdadeira?]

SatéliteResposta

[a fórmula F é verdadeira (v) ou falsa (f).]

Pergunta/Resposta SIM/NÃO

Perguntas/respostas SIM/NÃO mapeadas: • Afirmativa simples : existe na BC uma regra ou fato que confirma a pergunta.

NúcleoPergunta


SatéliteResposta

[a fórmula F é verdadeira (v) .]


Realização: F é verdadeira? Sim. Exemplo: Os morcegos são mamíferos? Sim. • Negativa simples: o provador verifica a falsidade da proposição e não foi

encontrada alternativa correta para o foco da pergunta na BC.

NúcleoPergunta


SatéliteResposta

[a fórmula F é falsa(f) .]


Realização: F é verdadeira? Não.



Exemplo: Os morcegos têm dono? Não. • Negação com alternativa: o provador verifica a falsidade da proposição, mas

encontra, dentro do mesmo conjunto semântico, uma alternativa (alt) verdadeira para o foco da pergunta.

NúcleoPergunta


Núcleo[a fórmula F é falsa(f) .]

Satélitealt (F )

SatéliteResposta

RST Evidência


Realização: F é verdadeira? Não. Alt (F) Exemplo: Os morcegos são aves? Não. São mamíferos. Obs. Esse esquema serve também a conjunções e disjunções não-exclusivas, quando houver uma mesma alternativa para os dois elementos em contraste. Nesse caso, o satélite da resposta seria [alt (F1 e F2)]. Exemplo: Os pinguins e as galinhas são mamíferos? Não. São aves. • Negação com alternativa para uma das partes de uma conjunção ou disjunção

não-exclusiva.

NúcleoPergunta

[as fórmula F1 e F2 são verdadeiras?]

Núcleo[ F1 é verdadeira.]

Núcleo[F2 é falsa]

Satélitealt (F2)

NúcleoRST Evidência

SatéliteResposta

RST Oposição


Realização: F1 e (e/ou) F2 ? Não. F1, mas alt (F2) Exemplo: Os cães e os gatos latem? Não. Os cães latem, mas os gatos miam. Obs. Usamos no exemplo, arbitrariamente, valor verdadeiro para F1 e falso para F2. Caso o inverso seja verdadeiro, procede-se a inversão na linearização,



mantendo-se a ordem de apresentação inicial do que for verdadeiro. Também o advérbio de negação “Não”deve ser linearizado no início da resposta. • Negação com alternativas diferentes para cada parte de uma conjunção ou de

disjunção não exclusiva.

NúcleoPergunta

[as fórmulas F1 e F2 são verdadeiras?]


Satélitealt (F1)



Satélitealt (F2)


SatéliteRespostaRST Lista


Realização: F1 e (e/ou) F2? Não. Alt (F1) e alt (F2). Exemplo: Os pombos e (e/ou) os marimbondos são mamíferos? Não. Os pombos são aves e os marimbondos são insetos.

• Negação sem alt para uma das partes de conjunção ou disjunção não exclusiva, porque não há alt na BC.

NúcleoPergunta


Núcleo[a fórmula F1 é verdadeira.]

Núcleo[a fórmula F2 é falsa.]

SatéliteResposta

RST Oposição


Realização: F1 e (e/ou) F2? Não. F1, mas não F2. Exemplo: Os pombos são domésticos e têm dono? Não. São domésticos, mas não têm dono. Obs. Caso a conjunção ou disjunção ocorra com fórmulas cujo sujeito não é idêntico, sua realização na resposta será:

Não. P (x), mas y, não Ex: Os gatos e os besouros são mamíferos? Não. Os gatos são mamíferos, mas os besouros, não.

• Negação de conjunção ou disjunção não-exclusiva, com alt para F1 e sem alt para F2, por não existir na BC.



NúcleoPergunta



Satélitealt (F1)





Realização: F1 e (e/ou) F2 são verdadeiras? Não. Alt (F1) e não F2. Exemplo: Os morcegos são aves e têm dono? Não. Os morcegos são mamíferos e não têm dono.

• Negação de pressuposição evidenciada em conjunção com implicação.

NúcleoPergunta

[F1 e F2 => F3 ?]

SatéliteResposta

[a conjunção F1 e F2 é falsa(f) .]


Realização: ( F1 e F2 ) => F3 ? Não existem F1 e F2. Exemplo: Os morcegos domésticos atacam? Não existem morcegos domésticos. • Afirmativa de disjunção não-exclusiva.

NúcleoPergunta

[ F1 e/ou F2 são verdadeiras?]


Núcleo[a fórmula F2 é verdadeira]



Realização: F1 e/ou F2 ? Sim. F1 e F2. Exemplo: Os cães e/ou os gatos são mamíferos ? Sim. Os cães e os gatos são mamíferos. Obs. Consideramos necessária a repetição da conjunção na resposta, para evitar ambiguidade. • Negação sem alt para disjunção não exclusiva.



NúcleoPergunta

[ F1 e/ou F2 são verdadeiras?]





Realização: F1 e/ou F2 ? Não. Não F1, nem F2. Exemplo: Os morcegos têm dono e/ou são domésticos? Não. Os morcegos não têm dono, nem são domésticos.

Obs. Se os elementos disjuntos forem sujeito, a realização será: Não. Nem F1, nem F2. Exemplo: Os pombos e/ou os gafanhotos têm pelos? Não. Nem os pombos, nem os gafanhotos têm pelos. Perguntas alternativas já mapeadas:

• Afirmação de uma das fórmulas em disjunção exclusiva.

NúcleoPergunta

[ F1 ou F2 são verdadeiras?]




Pergunta/Resposta Alternativa

Realização: F1 ou F2 ? F1. Exemplo: Os cães latem ou miam ? Latem. • Afirmação de F1 e alt (F2)



NúcleoPergunta


Núcleo[ F1 é verdadeira.]


Satélitealt (F2)


SatéliteResposta

RST Oposição


Realização: F1 ou F2 ? F1. Alt (f2). Exemplo: São os cães ou os gatos que miam ? Os gatos. Os cães latem. • Negação de F1 e F2 de conjunção exclusiva, com alts diferentes para cada uma.

NúcleoPergunta

[as fórmulas F1 ou F2 são verdadeiras?]


Satélitealt (F1)



Satélitealt (F2)




Realização: Nem F1, nem F2. Alt (F1) e alt (F2). Exemplo: São os cães ou os gatos que arrulham ? Nem os cães, nem os gatos arrulham. Os cães latem e os gatos miam.

• Negação da pressuposição de exclusão. Nega-se que a afirmação de um dos elementos em disjunção exija a negação do outro. Assim, a disjunção transforma-se numa conjunção verdadeira.

NúcleoPergunta


SatéliteResposta

[F1 e F2 são verdadeiras.]


Realização: F1 ou F2 ? F1 e F2. Exemplo: Os cães comem carne ou ração? Comem carne e ração.



• Negação de F1 e F2 de disjunção exclusiva.

NúcleoPergunta


Núcleo[a fórmula F1 é falsa]




Realização: F1 ou F2 ? Nem F1, nem F2. Exemplo: Os cães miam ou arrulham ? Nem miam, nem arrulham. Perguntas com quantificador existencial e perguntas QU-. Essas perguntas se comportam como as perguntas bipolares SIM/NÃO, no caso das respostas serem afirmativas ou negativas simples. Assim, para a pergunta:

- Alguma galinha voa ? Teríamos: - Sim.

- Não. Para termos respostas cooperativas, no entanto, no caso de respostas afirmativas,

deveríamos oferecer um exemplo, generalizar a afirmação, ou apresentar uma alternativa. O mesmo acontece para perguntas com mais de um quantificador e perguntas QU-. Os esquemas retóricos para esses casos são os mesmos apresentados para perguntas SIM/NÃO, exceto no caso da exemplificação e da generalização. Assim: • Afirmativa seletiva: exemplificação.

NúcleoPergunta

[ F1 ?]

Núcleo[F1 é verdadeira]

Satélite[valor de x]

SatéliteResposta

RST Particularização

Pergunta/Resposta SIM/NÃOcom existencial e QU-

Realização: F1 ? Valor de x, por exemplo. Exemplo: Algum morcego é doméstico? / Que morcego é doméstico ? Fulano, por exemplo. • Afirmativa categórica: generalização.



NúcleoPergunta

[ F1 ?]

Núcleo[F1 é verdadeira]

SatéliteGeneralização

SatéliteResposta

RST Evidência

Pergunta/Resposta SIM/NÃOcom existencial e QU-

Realização: F1? Generalização de F1. Exemplo: Algum cão é mamífero?/ Que cão é mamífero ? Todos os cães são mamíferos.

Estrutura Sentencial As decisões a respeito da estruturação sentencial partem de duas limitações: a da necessidade de mapeamento com a lógica de primeira ordem e a imposta pelos domínios tratados, de tipo classificatório, para um ambiente de consulta a SBCs. • A estrutura argumental Definiram-se equivalências entre posições dos argumentos na fórmula e papéis temáticos e funções sintáticas. Assim: predicado (argumento 1 , argumento 2 , argumento 3 , argumento 4 ) P ( X , [Y] , [Z] , [N] ) SV ( SN , [SN] , [Sprep] , [Spreps] ) verbo ( sujeito , [obj. dir.] , [Obj.ind.] , [Sadvs] ) processo ( agente , [paciente] , [beneficiário], [circunstanc.]) Estrutura informacional do diálogo: Para gerar respostas cooperativas, isto é, para guiar a busca de informações a partir da dúvida expressa pelo usuário na pergunta ao SBC, foi necessário definir o foco de dúvida na pergunta. Assim, por exemplo, para a pergunta “Os figos são frutos?” é fundamental que o raciocinador restrinja a possibilidade de alternativas corretas à classificação dos figos e não apresente alternativas para figos, listando todos os frutos contidos na BC, ou fornecendo um exemplo de frutos. A definição de foco foi feita, então, como o elemento mais à direita da pergunta, isto é, o último argumento de uma fórmula lógica, ou a última fórmula de uma expressão. Foi prevista também a possibilidade desse último elemento não ter alternativa na BC, quando, então, a busca incorpora o penúltimo argumento/fórmula, recursivamente. Assim:

X são frutos deiscentes? Foco 1: deiscentes Foco 2: frutos deiscentes.

A noção de foco tem uma contrapartida na noção de tópico, definido como o argumento 1 de uma fórmula. A delimitação de tópico vai permitir também a pronominalização do



argumento sujeito (argumento 1) no diálogo, assim como sua elipse. O tratamento de anáforas restringiu-se, até o momento a esses casos. As possibilidades de ambiguidade ficam resolvidas na interface, na medida em que, no campo destinado à linearização das perguntas, um SN pronominalizado ou elíptico aparece em sua forma plena, permitindo a correção de mal-entendidos pelo usuário.

A gramática básica e as gramáticas auxiliares Seguem-se as gramáticas especificadas através do formalismo das DCGs [Pereira e Warren’80] e codificadas para o protótipo do ambiente. Gramática básica %***** VOZ ATIVA ***** s --> s_sim_nao. s --> s_qu. s --> s_que. s --> s_alt. s --> s_eliptica. s --> s_explic. s --> s_pas. s_pas --> s_mat_pas. s_sim_nao --> s_mat_sim_nao. s_sim_nao --> s_ment_sim_nao. s_sim_nao --> s_int_atrib_sim_nao. s_sim_nao --> s_int_ident_sim_nao. s_sim_nao --> s_circunst_sim_nao. s_sim_nao --> s_posses_sim_nao. s_sim_nao --> s_transf_conect_sim_nao. s_qu --> s_mat_qu. s_qu --> s_ment_qu. s_qu --> s_int_atrib_qu. s_qu --> s_int_ident_qu. s_qu --> s_circunst_qu. s_qu --> s_posses_qu. s_que --> s_mat_que. s_que --> s_ment_que. s_que --> s_int_atrib_que. s_que --> s_int_ident_que. s_que --> s_circunst_que.



s_que --> s_posses_que. s_alt --> s_transf_conect_alt. s_alt --> s_cliv. s_cliv --> s_mat_cliv. s_cliv --> s_ment_cliv. s_cliv --> s_circunst_cliv. s_cliv --> s_posses_cliv. s_mat_sim_nao --> sn_suj(_,Numero),verbo(Numero,ativa,vtd),sn_obj_dir. s_mat_qu --> pinte,verbo(singular,Ativa,vtd),sn_obj_dir. s_mat_qu --> pinte,verbo(singular,Ativa,vtd). s_mat_qu --> pinte,verbo(singular,Ativa,vi). s_mat_que --> prel,n(type,_,singular),verbo(singular,Ativa,vtd),sn_obj_dir. s_mat_que --> prel,n(type,_,singular),verbo(singular,Ativa,vtd). s_mat_que --> prel,n(type,_,singular),verbo(singular,Ativa,vi). s_mat_cliv --> cop(ser,singular),n(token,_,singular), calt,n(token,_,singular),prel,verbo(singular,ativa,vtd), sn_obj_dir. s_mat_cliv --> cop(ser,singular),n(token,_,singular), calt,n(token,_,singular),prel,verbo(singular,ativa,vtd). s_mat_cliv --> cop(ser,singular),n(token,_,singular), calt,n(token,_,singular),prel,verbo(singular,ativa,vi). s_mat_cliv --> cop(ser,plural),adef(Gen,plural),n(type,Gen,plural), calt,adef(Gen2,plural),n(type,Gen2,plural), prel,verbo(plural,ativa,vtd), sn_obj_dir. s_mat_cliv --> cop(ser,plural),adef(Gen,plural),n(type,Gen,plural), calt,adef(Gen2,plural),n(type,Gen2,plural), prel,verbo(plural,ativa,vtd). s_mat_cliv --> cop(ser,plural),adef(Gen,plural),n(type,Gen,plural), calt,adef(Gen2,plural),n(type,Gen2,plural), prel,verbo(plural,ativa,vi). sn --> sn_suj(_,_). sn --> sn_ident(_,_). sn --> pronpes(_,_). sn --> sn_obj_1(_,_). sn --> sn_obj_2(_,_). sn --> sn_obj_posses. sn(Gen,Num) --> sn_suj(Gen,Num). sn(Gen,Num) --> sn_ident(Gen,Num). sn(Gen,Num) --> pronpes(Gen,Num). sn(Gen,Num) --> sn_obj_1(Gen,Num). sn(Gen,Num) --> sn_obj_2(Gen,Num).



sn(Gen,Num) --> sn_obj_posses. sn_suj(Genero,Numero) --> sn_suj_1(Genero,Numero). sn_suj(Genero,Numero) --> sn_suj_2(Genero,Numero). sn_suj(Genero,Numero) --> sn_suj_3(Genero,Numero). sn_suj(Genero,Numero) --> sn_suj_4(Genero,Numero). sn_suj(Genero,Numero) --> sn_suj_5(Genero,Numero). sn_suj(Genero,Numero) --> sn_suj_6(Genero,Numero). sn_suj2(Genero,Numero) --> sn_suj_1(Genero,Numero). sn_suj2(Genero,Numero) --> sn_suj_2(Genero,Numero). sn_suj2(Genero,Numero) --> sn_suj_3(Genero,Numero). sn_suj2(Genero,Numero) --> sn_suj_4(Genero,Numero). sn_suj_1(Genero,plural) --> adef(Genero,plural),n(type,Genero,plural). sn_suj_2(Genero,singular) --> qexist(Genero,singular),n(type,Genero,singular). sn_suj_3(Genero,singular) --> n(token,Genero,singular). sn_suj_4(Genero,plural) --> adef(Genero,plural),n(type,Genero,plural),adj(Genero,plural). sn_suj_5(Genero,plural) --> adef(Genero,plural),n(type,Genero,plural),prel, verbo(plural,ativa,vtd),sn_obj_dir2. sn_suj_5(Genero,plural) --> adef(Genero,plural),n(type,Genero,plural),prel, verbo(plural,ativa,vtd). sn_suj_5(Genero,plural) --> adef(Genero,plural),n(type,Genero,plural),prel, verbo(plural,ativa,vi). sn_suj_6(Genero,plural) --> adef(Genero,plural),n(type,Genero,plural),adj(Genero,plural),prel, verbo(plural,ativa,vtd),sn_obj_dir2. sn_suj_6(Genero,plural) --> adef(Genero,plural),n(type,Genero,plural),adj(Genero,plural),prel, verbo(plural,ativa,vtd). sn_suj_6(Genero,plural) --> adef(Genero,plural),n(type,Genero,plural),adj(Genero,plural),prel, verbo(plural,ativa,vi). sn_obj_dir --> sn_suj(_,_). sn_obj_dir --> n(outro,_,_). sn_obj_dir2 --> sn_suj2(_,_). sn_obj_dir2 --> n(outro,_,_). %**** Processos mentais **** s_ment_sim_nao --> sn_suj(_,Numero),verbo(Numero,ativa,vtd),sn_obj_dir.



s_ment_sim_nao --> sn_suj(_,Numero),verbo(Numero,ativa,vtd). s_ment_sim_nao --> sn_suj(_,Numero),verbo(Numero,ativa,vi). s_ment_qu --> pinte,verbo(singular,ativa,vtd),sn_obj_dir. s_ment_qu --> pinte,verbo(singular,ativa,vtd). s_ment_qu --> pinte,verbo(singular,ativa,vi). s_ment_que --> prel,n(type,_,singular),verbo(singular,ativa,vtd),sn_obj_dir. s_ment_que --> prel,n(type,_,singular),verbo(singular,ativa,vtd). s_ment_que --> prel,n(type,_,singular),verbo(singular,ativa,vi). s_ment_cliv --> cop(ser,singular),n(token,_,singular), calt,n(token,_,singular),prel,verbo(singular,ativa,vtd), sn_obj_dir. s_ment_cliv --> cop(ser,singular),n(token,_,singular), calt,n(token,_,singular),prel,verbo(singular,ativa,vtd). s_ment_cliv --> cop(ser,singular),n(token,_,singular), calt,n(token,_,singular),prel,verbo(singular,ativa,vi). s_ment_cliv --> cop(ser,plural),adef(Gen,plural),n(type,Gen,plural), calt,adef(Gen2,plural),n(type,Gen2,plural), prel,verbo(plural,ativa,vtd), sn_obj_dir. s_ment_cliv --> cop(ser,plural),adef(Gen,plural),n(type,Gen,plural), calt,adef(Gen2,plural),n(type,Gen2,plural), prel,verbo(plural,ativa,vtd). s_ment_cliv --> cop(ser,plural),adef(Gen,plural),n(type,Gen,plural), calt,adef(Gen2,plural),n(type,Gen2,plural), prel,verbo(plural,ativa,vi). %**** Processos Relacionais **** %**** 1. Intensivo **** s_int_atrib_sim_nao --> sn_suj_int_atrib(Genero,Numero),cop(ser,Numero),sn_obj_int_atrib(Genero,Numero). sn_suj_int_atrib(Genero,Numero) --> sn_suj_1(Genero,Numero). sn_suj_int_atrib(Genero,Numero) --> sn_suj_2(Genero,Numero). sn_suj_int_atrib(Genero,Numero) --> sn_suj_3(Genero,Numero). sn_obj_int_atrib(Genero,Numero) --> sn_obj_1(Genero,Numero). sn_obj_int_atrib(Genero,Numero) --> sn_obj_2(Genero,Numero). sn_obj_1(Genero,Numero) --> n(type,Genero,Numero). sn_obj_2(Genero,Numero) --> adj(Genero,Numero). s_int_atrib_qu --> pinte,cop(ser,singular),sn_obj_int_atrib(_,singular). s_int_atrib_que --> prel,n(type,_,singular),cop(ser,singular),sn_obj_int_atrib(_,singular). %************************************************************************************** s_int_atrib_cliv --> cop(ser,singular),n(token,Genero,singular), calt,n(token,Genero,singular),prel,cop(ser,singular),



sn_obj_int_atrib(Genero,singular). s_int_atrib_cliv --> cop(ser,plural),adef(Genero,plural),n(type,Genero,plural), calt,adef(type,Genero,plural),n(type,Genero,plural),prel, cop(ser,plural),sn_obj_int_atrib(Genero,singular). %************************************************************************************** %******* b. Identificador ******** s_int_ident_sim_nao --> sn_suj_int_ident(Genero,Numero), cop(ser,singular),sn_ident(Genero,Numero). sn_suj_int_ident(Genero,Numero) --> sn_suj_3(Genero,Numero). sn_ident(Genero,singular) --> adef(Genero,singular), n(outro,Genero,singular),prep, n(token,_,singular). s_int_ident_qu --> pinte,cop(ser,singular),sn_ident(Genero,singular). s_int_ident_que --> prel,n(type,_,singular),cop(ser,singular),sn_ident(Genero,singular). %******* 2. circunstancial ******** s_circunst_sim_nao --> sn_suj_circunst(_,Numero), verbo(Numero,ativa,vti), prepl, n(outro,Genero,plural). sn_suj_circunst(Genero,Numero) --> sn_suj(Genero,Numero). s_circunst_qu --> pinte,verbo(singular,ativa,vti),prepl,n(outro,Genero,plural). s_circunst_que --> prel,n(type,_,singular),verbo(singular,ativa,vti),prepl,n(outro,Genero,plural). s_circunst_cliv --> cop(ser,singular),n(token,_,singular),calt,n(token,_,singular),prel, verbo(singular,ativa,vti),prepl, n(outro,Genero,plural). s_circunst_cliv --> cop(ser,plural),adef(Genero,plural),n(type,_,plural),calt,adef(Genero,plural), n(type,_,plural),prel,verbo(plural,ativa,vti),prepl, n(outro,Genero,plural). %******* 3. possessivo ******** sn_obj_posses --> n(outro,_,_). s_posses_sim_nao --> sn_suj_posses(_,singular),[tem],sn_obj_posses. s_posses_sim_nao --> sn_suj_posses(_,plural),['têm'],sn_obj_posses. sn_suj_posses(Genero,Numero) --> sn_suj(Genero,Numero). s_posses_qu --> pinte,[tem],sn_obj_posses.



s_posses_que --> prel,n(type,_,singular),[tem],sn_obj_posses. s_posses_cliv --> cop(ser,singular),n(token,_,singular),calt,n(token,_,singular),prel, verbo(singular,ativa,vtd),sn_obj_posses. s_posses_cliv --> cop(ser,plural),adef(Genero,plural),n(type,Genero,plural),calt, adef(Genero2,plural),n(type,Genero2,plural),prel, verbo(plural,ativa,vtd),sn_obj_posses. %******* 4. Sentencas com transformacoes com conectivos aditivos ou alternativos *** s_transf_conect_sim_nao --> s_transf_conect_sim_nao_suj. s_transf_conect_sim_nao --> s_transf_conect_sim_nao_pred. s_transf_conect_sim_nao_suj --> s_mat_sim_nao_conj_suj. s_transf_conect_sim_nao_pred --> s_mat_sim_nao_conj_pred. s_transf_conect_sim_nao_suj --> s_mat_sim_nao_disj. s_transf_conect_sim_nao_suj --> s_int_atrib_sim_nao_conj_suj. s_transf_conect_sim_nao_pred --> s_int_atrib_sim_nao_conj_obj. s_transf_conect_sim_nao_suj --> s_int_atrib_sim_nao_disj. s_transf_conect_sim_nao_pred--> s_circunst_sim_nao_conj_pred. s_transf_conect_sim_nao_suj --> s_cicunst_sim_nao_conj_suj. s_transf_conect_sim_nao_suj --> s_circunst_sim_nao_disj. s_transf_conect_sim_nao_pred--> s_posses_sim_nao_conj_pred. s_transf_conect_sim_nao_suj --> s_posses_sim_nao_conj_suj. s_transf_conect_sim_nao_suj --> s_posses_sim_nao_disj. s_transf_conect_sim_nao_pred --> s_int_ident_sim_nao_conj. s_transf_conect_sim_nao_pred --> s_mat_sim_nao_conj_mista. s_transf_conect_sim_nao_pred --> s_mat_sim_nao_disj_mista. s_transf_conect_sim_nao_pred --> s_int_atrib_sim_nao_conj_mista. s_transf_conect_sim_nao_pred --> s_int_atrib_sim_nao_disj_mista. s_transf_conect_sim_nao_pred --> s_int_ident_sim_nao_conj_mista. s_transf_conect_sim_nao_pred --> s_int_ident_sim_nao_disj_mista. s_transf_conect_alt --> s_mat_disj. s_transf_conect_alt --> s_int_atrib_disj. s_transf_conect_alt --> s_int_ident_disj. s_transf_conect_alt --> s_posses_disj. s_mat_sim_nao_conj_suj --> sn_suj(_,_),cadi,sn_suj(_,_),verbo(plural,ativa,vtd),sn_obj_dir. s_mat_sim_nao_conj_suj --> sn_suj(_,_),cadi,sn_suj(_,_),verbo(plural,ativa,vtd). s_mat_sim_nao_conj_suj --> sn_suj(_,_),cadi,sn_suj(_,_),verbo(plural,ativa,vi). s_mat_sim_nao_conj_pred --> sn_suj(_,Numero),verbo(Numero,ativa,vtd), sn_obj_dir,cadi,verbo(Numero,ativa,vtd),sn_obj_dir. s_mat_sim_nao_conj_pred --> sn_suj(_,Numero),verbo(Numero,ativa,vtd), cadi,verbo(Numero,ativa,vtd).



s_mat_sim_nao_conj_pred --> sn_suj(_,Numero),verbo(Numero,ativa,vi), cadi,verbo(Numero,ativa,vi). s_mat_sim_nao_disj --> sn_suj(_,_),cadialt,sn_suj(_,_),verbo(plural,ativa,vtd),sn_obj_dir. s_mat_sim_nao_disj --> sn_suj(_,_),cadialt,sn_suj(_,_),verbo(plural,ativa,vtd). s_mat_sim_nao_disj --> sn_suj(_,_),cadialt,sn_suj(_,_),verbo(plural,ativa,vi). s_int_atrib_sim_nao_conj_suj --> sn_suj_1(Genero,_),cadi,sn_suj_1(Genero,_), cop(ser,plural),sn_obj_int_atrib(Genero,plural). s_int_atrib_sim_nao_conj_suj --> sn_suj_3(Genero,_),cadi,sn_suj_3(Genero,_), cop(ser,plural),sn_obj_int_atrib(Genero,plural). s_int_atrib_sim_nao_conj_obj --> sn_suj_1(Genero,Numero),cop(ser,Numero), sn_obj_int_atrib(Genero,Numero), cadi,sn_obj_int_atrib(Genero,Numero). s_int_atrib_sim_nao_disj --> sn_suj_1(Genero,_),cadialt,sn_suj_1(Genero,_), cop(ser,plural),sn_obj_int_atrib(Genero,plural). s_int_atrib_sim_nao_disj --> sn_suj_3(Genero,_),cadialt,sn_suj_3(Genero,_), cop(ser,plural),sn_obj_int_atrib(Genero,plural). s_int_atrib_sim_nao_disj --> sn_suj_2(Genero,_),cadialt,sn_suj_2(Genero,_), cop(ser,plural),sn_obj_int_atrib(Genero,plural). s_circunst_sim_nao_conj_suj --> sn_suj_1(Genero,_),cadi,sn_suj_1(Genero,_), verbo(plural,ativa,vti),prepl, n(outro,Genero2,plural). s_circunst_sim_nao_conj_suj --> sn_suj_3(Genero,_),cadi,sn_suj_3(Genero,_), verbo(plural,ativa,vti),prepl, n(outro,Genero2,plural). s_circunst_sim_nao_conj_pred --> sn_suj_circunst(_,Numero),verbo(Numero,ativa,vti),prepl, n(outro,Genero2,plural), cadi,prepl, n(outro,Genero3,plural). s_circunst_sim_nao_disj --> sn_suj_1(Genero,_),cadialt,sn_suj_1(Genero,_), verbo(plural,ativa,vti),prepl, n(outro,Genero2,plural). s_circunst_sim_nao_disj --> sn_suj_3(Genero,_),cadialt,sn_suj_3(Genero,_), verbo(plural,ativa,vti),prepl, n(outro,Genero2,plural). s_circunst_disj --> sn_suj_circunst(_,Numero),verbo(Numero,ativa,vti),prepl, n(outro,Genero2,plural), calt,prepl,qexist(Genero3,singular), n(outro,Genero3,singular). s_posses_sim_nao_conj_suj --> sn_suj_1(Genero,_),cadi,sn_suj_1(Genero,_),['têm'], n(outro,_,_). s_posses_sim_nao_conj_suj --> sn_suj_3(Genero,_),cadi,sn_suj_3(Genero,_),['têm'], n(outro,_,_).



s_posses_sim_nao_conj_pred --> sn_suj_posses(Genero,singular),[tem],n(outro,_,_),cadi, n(outro,_,_). s_posses_sim_nao_conj_pred --> sn_suj_posses(Genero,plural),['têm'],n(outro,_,_),cadi, n(outro,_,_). s_posses_disj --> sn_suj_posses(Genero,singular),[tem],n(outro,_,_),calt, n(outro,_,_). s_posses_disj --> sn_suj_posses(Genero,plural),['têm'],n(outro,_,_),calt, n(outro,_,_). s_posses_sim_nao_disj --> sn_suj_1(Genero,_),cadialt,sn_suj_1(Genero,_),['têm'], n(outro,_,_). s_posses_sim_nao_disj --> sn_suj_3(Genero,_),cadialt,sn_suj_3(Genero,_),['têm'], n(outro,_,_). s_posses_sim_nao_disj --> sn_suj_2(Genero,_),cadialt,sn_suj_2(Genero,_),['têm'], n(outro,_,_). s_mat_disj --> sn_suj(_,Numero),verbo(Numero,ativa,vtd), sn_obj_dir,calt,verbo(Numero,ativa,vtd),sn_obj_dir. s_mat_disj --> sn_suj(_,Numero),verbo(Numero,ativa,vtd), calt,verbo(Numero,ativa,vtd). s_mat_disj --> sn_suj(_,Numero),verbo(Numero,ativa,vi), calt,verbo(Numero,ativa,vi). s_mat_disj --> sn_suj(_,Numero),verbo(Numero,ativa,vtd), sn_obj_dir,calt,sn_obj_dir. s_mat_sim_nao_conj_mista --> sn_suj(Genero,Numero),verbo(Numero,ativa,vtd), sn_obj_dir,cadi,cop(ser,Numero),sn_obj_int_atrib(Genero,Numero). s_mat_sim_nao_conj_mista --> sn_suj(Genero,Numero),verbo(Numero,ativa,vtd), cadi,cop(ser,Numero),sn_obj_int_atrib(Genero,Numero). s_mat_sim_nao_conj_mista --> sn_suj(Genero,Numero),verbo(Numero,ativa,vi), cadi,cop(ser,Numero),sn_obj_int_atrib(Genero,Numero). s_mat_sim_nao_conj_mista --> sn_suj(_,Numero),verbo(Numero,ativa,vtd), sn_obj_dir,cadi,verbo(Numero,ativa,vti),prepl, n(outro,Genero,plural). s_mat_sim_nao_conj_mista --> sn_suj(_,Numero),verbo(Numero,ativa,vtd), cadi,verbo(Numero,ativa,vti),prepl, n(outro,Genero,plural). s_mat_sim_nao_conj_mista --> sn_suj(_,Numero),verbo(Numero,ativa,vi), cadi,verbo(Numero,ativa,vti),prepl, n(outro,Genero,plural). s_mat_sim_nao_conj_mista --> sn_suj(_,Numero),verbo(Numero,ativa,vtd), sn_obj_dir,cadi,verbo(Numero,ativa,vtd),n(outro,_,_). s_mat_sim_nao_conj_mista --> sn_suj(_,Numero),verbo(Numero,ativa,vtd), cadi,verbo(Numero,ativa,vtd),n(outro,_,_). s_mat_sim_nao_conj_mista --> sn_suj(_,Numero),verbo(Numero,ativa,vi),



cadi,verbo(Numero,ativa,vtd),n(outro,_,_). s_mat_sim_nao_disj_mista --> sn_suj(Genero,Numero),verbo(Numero,ativa,vtd), sn_obj_dir,cadialt,cop(ser,Numero),sn_obj_int_atrib(Genero,Numero). s_mat_sim_nao_disj_mista --> sn_suj(Genero,Numero),verbo(Numero,ativa,vtd), cadialt,cop(ser,Numero),sn_obj_int_atrib(Genero,Numero). s_mat_sim_nao_disj_mista --> sn_suj(Genero,Numero),verbo(Numero,ativa,vi), cadialt,cop(ser,Numero),sn_obj_int_atrib(Genero,Numero). s_mat_sim_nao_disj_mista --> sn_suj(_,Numero),verbo(Numero,ativa,vtd), sn_obj_dir,cadialt,verbo(Numero,ativa,vti),prepl, n(outro,Genero,plural). s_mat_sim_nao_disj_mista --> sn_suj(_,Numero),verbo(Numero,ativa,vtd), cadialt,verbo(Numero,ativa,vti),prepl, n(outro,Genero,plural). s_mat_sim_nao_disj_mista --> sn_suj(_,Numero),verbo(Numero,ativa,vi), cadialt,verbo(Numero,ativa,vti),prepl, n(outro,Genero,plural). s_mat_sim_nao_disj_mista --> sn_suj(_,Numero),verbo(Numero,ativa,vtd), sn_obj_dir,cadialt,verbo(Numero,ativa,vtd),n(outro,_,_). s_mat_sim_nao_disj_mista --> sn_suj(_,Numero),verbo(Numero,ativa,vtd), cadialt,verbo(Numero,ativa,vtd),n(outro,_,_). s_mat_sim_nao_disj_mista --> sn_suj(_,Numero),verbo(Numero,ativa,vi), cadialt,verbo(Numero,ativa,vtd),n(outro,_,_). s_int_atrib_disj --> sn_suj_1(Genero,Numero),cop(ser,Numero), sn_obj_int_atrib(Genero,Numero), calt,sn_obj_int_atrib(Genero,Numero). s_int_atrib_sim_nao_conj_mista --> sn_suj_1(Genero,Numero),cop(ser,Numero), sn_obj_int_atrib(Genero,Numero), cadi,verbo(Numero,ativa,vti),prepl, n(outro,Genero2,plural). s_int_atrib_sim_nao_conj_mista --> sn_suj_1(Genero,Numero),cop(ser,Numero), sn_obj_int_atrib(Genero,Numero), cadi,verbo(Numero,ativa,vtd),n(outro,_,_). s_int_atrib_sim_nao_disj_mista --> sn_suj_1(Genero,Numero),cop(ser,Numero), sn_obj_int_atrib(Genero,Numero), cadialt,verbo(Numero,ativa,vti),prepl, n(outro,Genero2,plural). s_int_atrib_sim_nao_disj_mista --> sn_suj_1(Genero,Numero),cop(ser,Numero), sn_obj_int_atrib(Genero,Numero), cadialt,verbo(Numero,ativa,vtd),n(outro,_,_). s_int_ident_sim_nao_conj --> sn_suj_int_ident(Genero,singular),cop(ser,singular), sn_ident(Genero,singular), cadi,sn_ident(Genero,singular). s_int_ident_disj --> sn_suj_int_ident(Genero,singular),cop(ser,singular), sn_ident(Genero,singular), calt,sn_ident(Genero,singular).



s_int_ident_sim_nao_conj_mista --> sn_suj_int_ident(Genero,singular),cop(ser,singular), sn_ident(Genero,singular),cadi,verbo(Numero,ativa,vti),prepl, n(outro,Genero,plural). s_int_ident_sim_nao_disj_mista --> sn_suj_int_ident(Genero,singular),cop(ser,singular), sn_ident(Genero,singular),cadialt,verbo(Numero,ativa,vti),prepl, n(outro,Genero,plural). s_int_ident_sim_nao_conj_mista --> sn_suj_int_ident(Genero,singular),cop(ser,singular), sn_ident(Genero,singular),cadi,[tem],n(outro,_,_). s_int_ident_sim_nao_disj_mista --> sn_suj_int_ident(Genero,singular),cop(ser,singular), sn_ident(Genero,singular),cadialt,[tem],n(outro,_,_). %***** sentencas com referências ***** sn_suj(Genero,Numero) --> pronpes(Genero,Numero). sn_suj_int_atrib(Genero,Numero) --> pronpes(Genero,Numero). sn_suj_int_ident(Genero,Numero) --> pronpes(Genero,Numero). sn_suj_int_circunst(Genero,Numero) --> pronpes(Genero,Numero). sn_suj_int_posses(Genero,Numero) --> pronpes(Genero,Numero). sn_ident --> adef(Genero,singular),pronpos(Genero,singular),n(outro,Genero,singular). s_eliptica --> cadi,sn_obj_dir. s_eliptica --> cadi,verbo(Genero,ativa,vtd),sn_obj_dir. s_eliptica --> cadi,verbo(Genero,ativa,vti),prepl,n(outro,_,plural). s_eliptica --> cadi,verbo(Genero,ativa,vi). s_eliptica --> cadi,n(type,_,_). s_eliptica --> cadi,verbo3(Genero,ativa,vtd),n(outro,Genero,_). %***** VOZ PASSIVA ***** s_mat_pas --> sn_suj(Genero,Numero), cop(ser,Numero), verbo_pas(Genero,Numero,passiva), ag_passiva. ag_passiva --> [por],n(token,_,singular). ag_passiva --> prepapcontr(Genero,Numero),n(type,Genero,Numero). %***** SOLICITACAO DE EXPLICACOES ***** s_explic --> pintec,s_sim_nao.



Estruturação e Controle de Discurso O discurso se estrutura internamente em três níveis: pergunta-mãe (pergunta completa e sem referências que introduz novo tema e dá lugar a novo contexto; perguntas-filhas (relativas ao elemento temático da pergunta-mãe que, por sua vez, podem originar perguntas dependentes); perguntas elípticas geradas através da função alternativa (que procura alternativas válidas para respostas cooperativas a perguntas com resposta negativa) aplicada ao foco, a partir das perguntas-filhas. Com base nas diretrizes ditadas por conhecimento lingüístico, usando a estrutura do discurso e de algumas outras auxiliares, procedimentos de atualização do contexto nas perguntas e respostas determinam de forma dinâmica e unívoca (às vezes recorrendo a processos de desambiguação por interação via WIMP) o valor dos marcadores correntes. A partir destes marcadores, os procedimentos apontam para a viabilidade ou não da ocorrência imediata de referências anafóricas e elípticas, assim como para a potencial solução correspondente. A estrutura do discurso é exibida ao usuário em sua forma superficial, através da estrutura de enunciação correspondente às sentenças proferidas ao longo do diálogo. Perguntas com referência são exibidas identadas, para marcar sua dependência em relação às perguntas anteriores. Quando é definido um segundo nível na estrutura, são associados botões à esquerda da sentença-mãe (para determinar referência à estrutura como um todo) e à direita da sentença-filha (para indicar referência à sentença específica). Todas as perguntas-filhas são assim marcadas e o processo é repetido ao se passar do segundo para o terceiro nível. Isto possibilita a seleção de diferentes escopos de referência elíptica. A possibilidade desta marcação através de recursos gráficos tem uma vantagem computacional associada. As sentenças marcadas não precisam ser processadas (como seriam se formuladas através de menus ou type-ahead), tendo apenas recuperados, a partir do contexto de ocorrência, os valores de seus papéis temáticos não-preenchidos.

Dos Rumos do LINX - Um shell para SIBC's (C.S.de Souza) Apresentada a concepção geral do ambiente LINX e os passos envolvidos no desenvolvimentos de novas bases para domínios classificatórios, podem-se tirar algumas conclusões importantes relativamente à distância entre o que se tem hoje e o que seria um shell ideal. Em primeiro lugar, este shell ideal deveria atender aos quesitos de 1 a 7 definidos em A Razão de Ser do LINX. Como discutido então, só mediante a observação e atendimento dos mesmos se poderia pensar em ambientes totalmente automatizados de aquisição, interrogação e explicação de conhecimentos para raciocinadores específicos.



A magnitude do problema pode ser resumida pelo fato de que não apenas se deve poder induzir (a) extensões na base de conhecimento, (b) extensões nas ontologias de domínio, e (c) extensões nas linguagens de interface, como também e principalmente se deve poder induzir a todas de maneira integrada e consistente. Facilmente se conclui que a existência de meta-raciocinadores torna-se tão imprescindível quanto, de fato, quimérica, no atual estado da arte. Porém, entre o ideal e o conformismo, estende-se o caminho que o LINX tem explorado. Como se pôde concluir das seções anteriores, uma aplicação LINX segue uma metodologia de desenvolvimento e pauta-se em um acervo de conhecimentos sistemáticos sobre Lingüística, Lógica e Interfaces de Usuário. Essencialmente, o loop de desenvolvimento é o representado na Figura 11.

1

2

3.1 3.2

4

fim

Seleção de Domínio

Montagem da Base para o Provador

Mapeamentos de Perguntas Mapeamentos de Resposta

Montagem do Léxico

Figura 11: Loop de Desenvolvimento de um SIBC LINX

Já é possível concluir que a extensão das funcionalidades de um SIBC Linx de hoje para que incluam algum grau de aquisição de conhecimento pode ser atingida progressivamente, através de passos de complexidade crescente como:

1. aquisição de novos tokens de conhecimento para os types presentes na ontologia

2. aquisição das lexicalizações destes tokens em estruturas sintáticas básicas e fixas

3. aquisição de lexicalizações de sinonímia estrita (semântica e sintática) para tokens já presentes na base

Os mapeamentos mostrados nesta parte do relatório sugerem que (1), (2) e (3) são possíveis, embora sejam também modestos em relação à usabilidade almejada para



SIBC’s ideais. Na realidade, a maioria dos shells que oferecem extensões automáticas da base de conhecimentos não ultrapassa estes limites, havendo até os que não os atinjam totalmente. SIBC’s construídos ad hoc, isto é sem a sistematicidade necessária para que uma troca de domínio dispense reprogramação extensiva do software, têm um comportamento bastante heterogêneo, podendo tanto ultrapassar estes limites, como também sequer aproximar-se deles. A colocação de dispositivos hard wired ao invés de mapeamentos sistemáticos entre base e interfaces não permite que se formulem julgamentos a priori sobre a usabiliade destes SIBC’s.

Um dos pontos centrais do Projeto LINX é a investigação sistemática sobre que possibilidades há de que as linguagens de interface funcionem como uma espécie de linguagem de programação do Shell LINX. Ou seja, que usuários finais e especialistas de domínio possam escrever informações e procedimentos na base e que o shell os compile e gere um programa - o SIBC. Tal como programas devem ser extensíveis (seja diretamente pela ação de usuários finais, seja pela interveniência dos chamados programadores de aplicação), o SIBC LINX deveria ser extensível também neste sentido.

Este desafio reedita, de maneira menos teórica, o ideal de usabilidade por nós proposto, mas emparelha os objetivos práticos com aqueles já contemplados por software comercial extensível como o conjunto MS Office’97™. Por esta razão, a tese de doutorado de D.A.S. Oliveira é, neste momento, uma contribuição central para os rumos de projeto. Sua investigação é centrada na semântica de operadores da Lógica Clássica e dos mecanismos de estruturação de provas em Dedução Natural, tais que a linguagem de representação (baseada em LPO) resultante e seus respectivos mapeamentos sobre as linguagens de interface circunscrevam um território extensível seguro para um Shell LINX no futuro. Esta possibilidade causaria um impacto positivo no cenário de software para IA no Brasil, visto que o shell traria embutido os traços lingüísticos e culturais do país, atendendo mais de perto a comunidade de usuários local. Vale ressaltar que quando estes traços não são embutidos no software, a complexidade de interação com um SIBC (que já é grande) se multiplica. No atual estágio de desenvolvimento do projeto, as metas de curto e médio prazo apontam para a possibilidade de realização de testes de usabilidade importantes. Há uma grande lacuna sobre avaliações empíricas acerca de SIBCs com interface em linguagem natural. Torna-se difícil, senão impossível, identificar os reais desafios e obstáculos para o uso de processamento de linguagem natural (PLN) nas interfaces, antes que se tenha um ambiente em que a mesma linguagem de entrada seja usada para a saída conversacional da aplicação. Só assim há um verdadeiro diálogo entre os interlocutores humano e automático, e não apenas uma superficial coincidência de códigos textuais entre a linguagem de entrada e a de saída. Uma contribuição tecnológica já realizada é que os resultados do projeto LINX têm sido transferidos para desenvolvimento tecnológico na área de documentação ativa e suporte



inteligente ao design em engenharia. Produtos já desenvolvidos pelo ADDLabs (Laboratório de Documentação Ativa e Design Inteligente, do Dep. De Ciência da Computação da UFF) incorporam conhecimentos gerados pelo LINX na área de explicações.



PARTE IV



Apreciação Final Projeto LINX é um projeto de muito longo prazo [de Souza et al’96]. Suas metas representam um contínuo de conquistas parciais na direção de se construir um shell usável, no Brasil. Os aspectos de localização do software estão intrinsecamente associados ao fato de que a matéria processada pos SIBC’s é conhecimento, portanto é também língua e cultura. \assim, não se percebe que a localização seja uma restrição, mas, sim, um valor adicional do produto. Durante o período de vigência do Projeto Integrado, apoiado pelo CNPq, a despeito de dificuldades com a obtenção dos recursos para a compra de material e a mudança radical nos planos iniciais de parceria, a equipe conseguiu levar adiante a meta de montar um novo SIBC, desta vez sobre o domínio de Frutas Brasileiras. Em agosto de 1997, a implementação do provador ProTeoS está em fase de finalização e a o ambiente de Interface (com módulos de Interrogação e Explicação) está implementado para testes não integrados ao provador. Com a integração, os processos de conversão de provas em estruturas RST deverão ser re-conferidos. A previsão é de que no mês de outubro de 1997 a primeira versão completa do software esteja disponível. A equipe disponibilizará o software desenvolvido para que outros pesquisadores brasileiros possam utilizá-lo para seus fins específicos de investigação. É notável a interseção temática entre as pesquisas feitas no LINX e aquelas necessárias para a maior parte do software relativo a PLN. O recente início do projeto UNL Brasil (v. Parte II) mostrou inúmeras oportunidades de colaboração da equipe LINX com as equipes de desenvolvimento de codificadores / decodificadores lingüísticos e ferramentarias. Dentre as mais práticas, está o uso do paradigma da interface LINX para os codificadores de texto em linguagem UNL. Já, dentre os mais científicos, figura a representação de ontologias em redes de frames e as condições de extensibilidade consistente das mesmas. Como dado importante, o Projeto LINX foi abrigado recentemente no TeCGraf (Laboratório de Tecnologias em Computação Gráfica, do Departamento de Informática da PUC-Rio). Este laboratório de pesquisa e desenvolvimento está interessado em software de processamento lingüístico (e.g. geração automática de textos) e em sistemas de help inteligentes para aplicações computacionais (gráficas, principalmente). Vê-se, portanto, que o projeto vem encontrando seu caminho, ainda que com dificuldades inerentes ao tema e à complexidade de se constituir, gerenciar e preservar equipes intedisciplinares de trabalho.



Referências [CACM] Communications of the ACM (1994) Artificial Intelligence. March 1994. Vol.

37, No. 3. ACM Press

[de Souza et al’96] de Souza,C.S.; García,L.S.; Dias,M.C.P.; e Quental,V.S.T.D.B. (1996) Linx: O papel da Linguagem Natural na Representação, Exploração e Aquisição de Conhecimentos Usados em Sistemas de Informação. Anais do II Encontro para o Processamento Computacional de Português Escrito e Falado. Pp. 30-39. Curitiba , 21-22 de outubro de 1996. CEFET-Pr (PPGTE).

[DENDRAL] Buchanan,B.G. and Feigenbaum,E.A. (1978) Dendral and Meta-Dendral - Their Application Dimensions. Journal of Artificial Intelligence. No.11, pp.5-24.

[Dias’94] Dias,M.C.P. O Léxico em Sistemas de Análise e Geração Automática de Textos em Língua Portuguesa. Tese de Doutorado. Departamento de Letras. PUC-Rio. Rio de Janeiro,RJ. 1994.

[García'95] García,L.S. (1995) Linx: Um Ambiente Integrado de Interface para Sistemas de Informação Baseados em Conhecimento. Tese de Doutorado. Departamento de Informática. PUC-Rio. Rio de Janeiro, RJ. 191pp.

[Haeusler'90] Haeusler, Edward H. Prova Automática de Teoremas em Dedução Natural: Uma Abordagem Abstrata. Tese de Doutorado, Depto. de Inform tica, PUC-Rio, 1990.

[Jackendoff’90] Jackendoff,R. (1990) Semantic Structures. Cambridge, Mass. MIT Press.

[LINX'96] Projeto LINX (1996) Relatório Parcial de Pesquisa. Documento do Projeto CNPq 52523499/95-7. Enviado ao CNPq em agosto de 1996.

[Mann & Thompson’87] Mann,W. And Thompson, S. (1987) Thetorical Structure Theory: A Theory of Text Organization. In Polanyi,L. (Ed.) The Structure of Discourse. ABLEX.

[Maybury'93] Maybury,M. (1993) Intelligent User Interfaces. Cambridge,Mass. MIT Press.

[Microsoft’95] Microsoft Corporation (1995) - The Windows Interface Guidelines for Software Design. Microsoft Press.

[MYCIN] Shortliffe,E.H. (1976) Computer-Based Medical Consultation. New York,NY. Elsevier.

[Nunes'91] Nunes, Maria das Graçãas V. A Geração de Respostas Cooperativas em Sistemas Baseados em Lógica. Tese de Doutorado, Depto. de Informática, PUC-Rio, 1991.

[Oliveira et al'93] Oliveira, Denise A.S.; Haeusler, Edward H. & Pequeno, Tarcísio H. C. Prova Automática de Teoremas em Dedução Natural. Anais do X Simpósio Brasileiro de Inteligência Artificial, pp. 111-125, Outubro de 1993.



[Oliveira et al'96] Oliveira, Denise A. S.; de Souza, Clarisse S. & Haeusler, Edward H. Structured Argument Generation in a Logic-Based KB System. Proceedings of the Second Conference on Information-Theoretic Approaches to Logic, Language and Computation, pgs 173-181, Londres, Julho de 1996.

[Oliveira'92] Oliveira, Denise A. S. Um Provador de Teoremas em Dedução Natural Capaz de Complementar seu Conhecimento. Dissertação de Mestrado, Depto. de Inform tica, PUC-Rio, Abril de 1992.

[Oliveira'96a] Oliveira, D.A.S. (1996) Uma Abordagem Semiótica para a Aquisição e Representação de Conhecimento. Proposta de Tese de Doutorado aprovada e não publicada. Departamento de Informática, PUC-Rio. Rio de Janeiro,RJ.

[Pereira and Warren’80] Pereira,F.C.N. and Warren,D.H.D. (1980) Definite-clause grammars for language analysis: A survey of the formalism and comparison with augmented transition networks. Artificial Intelligenge 13, no., pp. 231-278

[Prawitz'65] Prawitz, Dag. Natural Deduction - A Proof-Theoretical Study. Stockholm, 1965.

[Quental’95] Quental,V.S.T.D.B. Uma Gramática para Compreensão e Geração Automática de Textos em Língua Portuguesa. Tese de Doutorado. Departamento de Letras, PUC-Rio. Rio de Janeiro, RJ. 1995.

[R1] MacDermott,J. (1982) R1: A Rule-Based Configurer of Computer Systems. Artificial Intelligence. Vol.19, pp.39-88

[Searle'79] Searle,J. (1979) Expression and Meaning. Cambridge. Cambridge University Press.

[Smart Elements] Neuron Data - Smart Elements. Product Documentation. Neuron Data. Palo Alto, California.


relatório final de projeto - clarisse/linx/relatoriofinallinx.pdf · (iii) realizar inferências...

Documents