Relatorio Final LINX

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

Um Estudo de Caso Simplificado, mas Exemplar

Parte II
A Razão de Ser do LINX

Um Breve Histórico deste Projeto Integrado

Resultados de Publicações e Apresentações em Congressos e Conferências

Resultados de Cursos de Graduação e Pós-Graduação incluindo Matéria sobre o

LINX
Resultados de Participação em Projetos Internacionais

Resultados de Desenvolvimento de Programas

Resultados de Documentação
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
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.

símbolos IN
dispositivo de leitura
Rr
FUNÇÕES de TRANSFORMAÇÃO
Rg
dispositivo de gravação
símbolos OUT
memória auxiliar
conjunto de estados
regras de reconhecimento/geraçã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.
Interface Interface
Léxico- Léxico-
Gramática Gramática
Parser Raciocinador Parser

Base
Interpretador Interpretador
AQUISIÇÃO INTERROGAÇÃO E EXPLICAÇÃO
Figura 2: Arquitetura Mínima de um Shell para SIBC's usáveis
LINX - Relatório Final de Projeto - p.10

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. 1. pai(josé,pedro).

II. José é pai de Luiz. 2. pai(josé,luiz).
III. João é pai de José. 3. pai(joão,josé).
IV. João é pai de Paulo. 4. pai(joão,paulo).
V. X é avô de Y de X é pai do pai de Y. 5. avô(X,Y) :- pai(X,Z), pai(Z,Y).
VI. X é irmão de Y se o pai de X é pai de 6. irmão(X,Y) :- pai(Z,X), pai(Z,Y).
Y. 7. tio(X,Y) :- irmão(X,Z), pai(Z,Y).
VII. X é tio de Y se X é irmão do pai de Y.
s
'?'
sn sv
const 'é' sn sprep
'o' pred 'de' sn

'paulo'
'tio' 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.
tia(marta,luiz). tia(X,Y) :- mulher(X,Z),tio(Z,Y).

mulher(marta,paulo).
tio(paulo,luiz).
tio(X,Y):- irmão(X,Z),pai(Z,Y).
irmão(paulo,josé). irmão(X,Y):-pai(Z,X),pai(Z,Y).
pai(josé,luiz). pai(joão,paulo).
pai(joão,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).

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). (9) mulher(marta,paulo) (10)

marido(joão,maria). (8)
(a) (b)
Figura 6: Visualização dos Passos Críticos das Provas de mulher(maria,joao) e

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
enunciados da linguagem de explicação
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 - M. Carmelita Dias e 1996.1
PUC-Rio Violeta Quental
Introdução à Lingüística Computacional Curso Graduação - M. Carmelita Dias 1996.2
PUC-Rio
Introdução à Lingüística Computacional Mini-Curso - VI M. Carmelita Dias e outubro 96
Encontro da ASSEL- Violeta Quental
Rio
Representação da Informação Lexical Curso de Pós-graduação M. Carmelita Dias e 1997.1
- PUC-Rio Violeta Quental
Introdução à Lingüística Computacional Curso de Pós-graduação M. Carmelita Dias e 1997.2
- PUC-Rio Violeta Quental
2 No Departamento de Informática da PUC-Rio

Curso Nível Professor Período
Tópicos em Inteligência Artificial - Linguagens Curso pós-graduação - Clarisse Sieckenius de 1997.1
de Representação: Convergência entre PUC-Rio Souza
Programação e Aquisição de Conhecimento
Lingüística Computacional Interativa Curso pós-graduação - Clarisse Sieckenius de 1996.2 e
PUC-Rio Souza 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

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.

perguntas respostas
enunciado Gerenciador de Interações texto
Interpretador Gerador
sentenças básicas
Estruturas RST rotuladas
e estruturas conceituais
Solicitador de Provas Planejador de Respostas
Demandas de Prova Árvores de Prova
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 Noz Castanha Fruta
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> <Categoria Geral do que se assemelha a Sementes>
Fruto PseudoFruto Fruto Múltiplo caroço semente
4a. Perspectiva - tipos de fruto:
<Tipologia Geral dos Frutos>
seco fibroso carnoso
baga drupa baga drupa
deiscentes indeiscentes
folículo legume cápsula síliqua

aquênio cariopse sâmara
pixidiária septicida loculicida
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:

% * 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:

% * 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
Pergunta/Resposta SIM/NÃO
Núcleo Satélite
Pergunta Resposta
[a fórmula F é verdadeira?] [a fórmula F é verdadeira (v) ou falsa (f).]
Perguntas/respostas SIM/NÃO mapeadas:
• Afirmativa simples : existe na BC uma regra ou fato que confirma a pergunta.

Núcleo Satélite
Pergunta Resposta
[a fórmula F é verdadeira?] [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úcleo Satélite
Pergunta Resposta
[a fórmula F é verdadeira?] [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úcleo Satélite
Pergunta Resposta
[a fórmula F é verdadeira?] RST Evidência
Núcleo Satélite
[a fórmula F é falsa(f) .] alt (F )
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úcleo Satélite
Pergunta Resposta
[as fórmula F1 e F2 são verdadeiras?] RST Oposição
Núcleo Núcleo
[ F1 é verdadeira.] RST Evidência
Núcleo Satélite
[F2 é falsa] alt (F2)
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úcleo Satélite
Pergunta Resposta
[as fórmulas F1 e F2 são verdadeiras?] RST Lista
Núcleo Núcleo
RST Evidência RST Evidência
Núcleo Satélite Núcleo Satélite

[F1 é falsa] alt (F1) [F2 é falsa] alt (F2)
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úcleo Satélite
Pergunta Resposta
[as fórmulas F1 e F2 são verdadeiras?] RST Oposição
Núcleo Núcleo
[a fórmula F1 é verdadeira.] [a fórmula F2 é falsa.]
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úcleo Satélite
Pergunta Resposta
[as fórmulas F1 e F2 são verdadeiras?] RST Lista
Núcleo Núcleo
RST Evidência [F2 é falsa]
Núcleo Satélite
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úcleo Satélite
Pergunta Resposta
[F1 e F2 => F3 ?] [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úcleo Satélite
Pergunta Resposta
[ F1 e/ou F2 são verdadeiras?] RST Lista
Núcleo Núcleo
[a fórmula F1 é verdadeira.] [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úcleo Satélite
Pergunta Resposta
[ F1 e/ou F2 são verdadeiras?] RST Lista
Núcleo Núcleo
[a fórmula F1 é falsa.] [a fórmula F2 é falsa.]
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.
Pergunta/Resposta Alternativa
Núcleo Satélite
Pergunta Resposta
[ F1 ou F2 são verdadeiras?] RST Lista
Núcleo Núcleo
[a fórmula F1 é verdadeira.] [a fórmula F2 é falsa.]
Realização: F1 ou F2 ? F1.
Exemplo: Os cães latem ou miam ?
Latem.
• Afirmação de F1 e alt (F2)

Núcleo Satélite
Pergunta Resposta
[ F1 ou F2 são verdadeiras?] RST Oposição
Núcleo Núcleo
[ F1 é verdadeira.] RST Evidência
Núcleo Satélite
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úcleo Satélite
Pergunta Resposta
[as fórmulas F1 ou F2 são verdadeiras?] RST Lista
Núcleo Núcleo
RST Evidência RST Evidência
Núcleo Satélite Núcleo Satélite

[F1 é falsa] alt (F1) [F2 é falsa] alt (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úcleo Satélite
Pergunta Resposta
[ F1 ou F2 são verdadeiras?] [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úcleo Satélite
Pergunta Resposta
[ F1 ou F2 são verdadeiras?] RST Lista
Núcleo Núcleo
[a fórmula F1 é falsa] [a fórmula F2 é 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.
com existencial e QU-
Núcleo Satélite
Pergunta Resposta
[ F1 ?] RST Particularização
Núcleo Satélite
[F1 é verdadeira] [valor de x]
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.

com existencial e QU-
Núcleo Satélite
Pergunta Resposta
[ F1 ?] RST Evidência
Núcleo Satélite
[F1 é verdadeira] Generalização
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.
calt,n(token,_,singular),prel,verbo(singular,ativa,vtd).
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.
prel,verbo(plural,ativa,vtd).
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_suj2(Genero,Numero) --> sn_suj_1(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.
verbo(plural,ativa,vtd).
verbo(plural,ativa,vi).
adef(Genero,plural),n(type,Genero,plural),adj(Genero,plural),prel,
verbo(plural,ativa,vtd),sn_obj_dir2.
verbo(plural,ativa,vtd).
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.
calt,n(token,_,singular),prel,verbo(singular,ativa,vtd).
calt,n(token,_,singular),prel,verbo(singular,ativa,vi).
s_ment_cliv --> cop(ser,plural),adef(Gen,plural),n(type,Gen,plural),
prel,verbo(plural,ativa,vtd),
sn_obj_dir.
prel,verbo(plural,ativa,vtd).
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_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,
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,
%******* 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,_),
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,_),
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,_),
s_circunst_sim_nao_conj_pred -->
sn_suj_circunst(_,Numero),verbo(Numero,ativa,vti),prepl,
n(outro,Genero2,plural),
cadi,prepl,
s_circunst_sim_nao_disj --> sn_suj_1(Genero,_),cadialt,sn_suj_1(Genero,_),
s_circunst_sim_nao_disj --> sn_suj_3(Genero,_),cadialt,sn_suj_3(Genero,_),
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,_,_).
n(outro,_,_).
n(outro,_,_).
s_mat_disj --> sn_suj(_,Numero),verbo(Numero,ativa,vtd),
sn_obj_dir,calt,verbo(Numero,ativa,vtd),sn_obj_dir.
calt,verbo(Numero,ativa,vtd).
s_mat_disj --> sn_suj(_,Numero),verbo(Numero,ativa,vi),
calt,verbo(Numero,ativa,vi).
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,
cadi,verbo(Numero,ativa,vti),prepl,
s_mat_sim_nao_conj_mista --> sn_suj(_,Numero),verbo(Numero,ativa,vi),
sn_obj_dir,cadi,verbo(Numero,ativa,vtd),n(outro,_,_).
cadi,verbo(Numero,ativa,vtd),n(outro,_,_).
s_mat_sim_nao_conj_mista --> sn_suj(_,Numero),verbo(Numero,ativa,vi),

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,
cadialt,verbo(Numero,ativa,vti),prepl,
s_mat_sim_nao_disj_mista --> sn_suj(_,Numero),verbo(Numero,ativa,vi),
sn_obj_dir,cadialt,verbo(Numero,ativa,vtd),n(outro,_,_).
cadialt,verbo(Numero,ativa,vtd),n(outro,_,_).
s_mat_sim_nao_disj_mista --> sn_suj(_,Numero),verbo(Numero,ativa,vi),
s_int_atrib_disj --> sn_suj_1(Genero,Numero),cop(ser,Numero),
calt,sn_obj_int_atrib(Genero,Numero).
s_int_atrib_sim_nao_conj_mista --> sn_suj_1(Genero,Numero),cop(ser,Numero),
s_int_atrib_sim_nao_conj_mista --> sn_suj_1(Genero,Numero),cop(ser,Numero),
s_int_atrib_sim_nao_disj_mista --> sn_suj_1(Genero,Numero),cop(ser,Numero),
s_int_atrib_sim_nao_disj_mista --> sn_suj_1(Genero,Numero),cop(ser,Numero),
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,
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,
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 Seleção de Domínio
2 Montagem da Base para o Provador
Mapeamentos de Perguntas 3.1 3.2 Mapeamentos de Resposta
4 Montagem do Léxico
fim
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.

Relatorio Final LINX

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Relatorio Final LINX

Enviado por

Direitos autorais:

Formatos disponíveis

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

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

Relatório Final de Projeto

preparado por Clarisse Sieckenius de Souza

Rio de Janeiro, 30 de Agosto de 1997

The Tao that can be expressed is not the eternal Tao;

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

Sobre Sistemas Automáticos e Sistemas Formais

Um Estudo de Caso Simplificado, mas Exemplar

A Razão de Ser do LINX

Um Breve Histórico deste Projeto Integrado

Resultados de Publicações e Apresentações em Congressos e Conferências

Resultados de Cursos de Graduação e Pós-Graduação incluindo Matéria sobre o

Resultados de Participação em Projetos Internacionais

Resultados de Desenvolvimento de Programas

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

Concepção Geral de 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

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

Dos Rumos do LINX - Um shell para SIBC's (C.S.de Souza)

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

Caetano Vendrami Neto

Edward Hermann Haeusler

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

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

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

Sobre Sistemas de Informação Baseados em Conhecimento,

Sistemas de Informação Baseados em Conhecimento (SIBC's) definem-se no âmbito

a) Quão robusto é um SIBC?

A robustez de um SIBC está fundamentalmente aliada à robustez do raciocinador nele

A utilidade de um SIBC depende não apenas da quantidade e qualidade dos

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

existe. Porém, dados os limites formais de computabilidade das línguas humanas, à

Finalmente, julgamentos sobre o quão agradável é usar SIBC's são dependentes de

As considerações acima indicam a existência de importantes desafios de usabilidade para

Sobre Sistemas Automáticos e Sistemas Formais

O aproveitamento comercial da tecnologia de SIBC's, passadas quase três décadas do

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

aquisição de conhecimento, de explicação, de interfaces gráficas e textuais. Porém, apesar

O problema de fundo da IA clássica é o mesmo de toda a Ciência da Computação:

O esquema da Figura 1 pode elucidar como interfaces gráficas de um editor como o

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

Figura 1: Esquema Geral de Transformações Simbólicas

Este ponto formal pode elucidar porque os processos de aquisição de conhecimento

Parser Raciocinador Parser

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

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

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

Um Estudo de Caso Simplificado, mas Exemplar

O caso com que iremos exemplificar pontos críticos da usabilidade de shells é o da

Retomando-se o exemplo, admitamos que a linguagem de representação de

pergunta ↔ demanda de prova

Em função de AQUISIÇÃO, a linguagem usada pelo usuário que fornece novos

asserçãoi → cláusula expressando fato

Seja, portanto, o conjunto de cláusulas Prolog, abaixo, o conteúdo inicial C da diminuta

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

Abstraindo uma multiplicidade de detalhes morfossintáticos da língua portuguesa, seja a

Vocabulário: {∀ x | x ⊂ Predicados ∪ Constantes ∪ Variáveis-à-Esquerda} ∨

As variáveis-à-esquerda são as que aparecem `a esquerda das regras cuja enunciação é

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