JOSIANE MELCHIORI PINHEIRO FERREIRA
O USO DE LINGUAGEM NATURAL CONTROLADA COMO
INTERFACE PARA CONSTRUÇÃO DE ONTOLOGIAS
MARINGÁ
2005
JOSIANE MELCHIORI PINHEIRO FERREIRA
O USO DE LINGUAGEM NATURAL CONTROLADA COMO
INTERFACE PARA CONSTRUÇÃO DE ONTOLOGIAS
Dissertação apresentada ao Programa de PósGraduação em Ciência da Computação da
Universidade Estadual de Maringá, como
requisito parcial para obtenção do grau de
Mestre em Ciência da Computação.
Orientador: Prof. Dr. Sérgio R. P. da Silva
MARINGÁ
2005
DEDICATÓRIA
Dedico este trabalho
Aos meus pais, Oraci e Regina e ao meu marido Heitor, com todo amor do mundo.
AGRADECIMENTOS
Ao professor Sérgio R. P. da Silva, meu orientador, por ter acreditado em meu
trabalho, me incentivado e ajudado quando necessário.
Aos meus colegas graduandos e mestrandos do nosso grupo de pesquisa, pela
paciência de ver minhas apresentações e sempre contribuir com algo relevante em nossas
discussões.
Aos meus colegas do Departamento de Informática da UEM, que entenderam que eu
não poderia contribuir o quanto era necessário durante o desenvolvimento deste trabalho.
Ao CNPQ, pela ajuda financeira recebida durante a execução deste trabalho.
À minha família, principalmente meus pais Oraci e Regina, que lutaram o quanto
puderam para que eu tivesse a oportunidade de hoje defender o grau de mestre. Pelo amor,
carinho, educação e respeito que me proporcionaram durante toda a vida.
Ao meu esposo Heitor, por ter compreendido a minha ausência e o meu cansaço. Pelo
amor, carinho, paciência e incentivo que me proporcionou durante o desenvolvimento deste
trabalho.
[...] talvez não tenhamos conseguido fazer o
melhor, mas lutamos para que o melhor fosse
feito [...] Não somos o que deveríamos ser,
mas somos o que iremos ser. Mas graças a
Deus, não somos o que éramos (Martin
Luther King).
RESUMO
Neste trabalho, desenvolvemos uma linguagem de especificação de ontologias baseada em
uma linguagem natural controlada com o intuito de permitir que um especialista em um
domínio seja capaz de, ele próprio, construir uma base de conhecimento contendo uma
ontologia para o domínio. Com o uso desta linguagem, procuramos evitar que problemas
comuns de comunicação entre o engenheiro de conhecimento e o especialista afetem a
qualidade da base de conhecimento gerada. Procuramos evitar também que o especialista
tenha que expressar seu conhecimento por meio de uma tecnologia de representação de
conhecimento que ele não domina. Neste escopo, foram desenvolvidos um parser e um
algoritmo de mapeamento para traduzir a linguagem de especificação, automaticamente, para
a linguagem OWL. Estes elementos foram incorporados em um protótipo de um editor de
ontologias dirigido por processo, que visa restringir a linguagem empregada pelo especialista,
auxiliando-o durante o processo de desenvolvimento da ontologia do domínio. Deste modo,
somente as sentenças que podem ser utilizadas em cada passo do processo de construção de
ontologias, estarão disponíveis para escolha do especialista, facilitando, assim, seu trabalho e,
possivelmente, ampliando seu desempenho.
Palavras-chave: Representação de Conhecimento, Ontologia, Linguagem Natural Controlada
e OWL.
ABSTRAT
In this work, we have developed an ontology specification language based on controlled
natural language aiming to allow a domain expert to build a knowledge base, containing an
ontology of the domain, by her/himself. Using this approach, we try to avoid common
communications problems between knowledge engineers and domain experts that can result
in a low quality knowledge base. Additionally, we will also trying to avoid that the domain
expert has to express his/her knowledge through a knowledge representation language that
he/she does not dominate. In this scope, we developed a parser and a mapping algorithm to
automatically translate the specification language, to the OWL language. These elements were
added to a prototype of a process driver ontology editor, with the aim to limit the language
used by the domain expert, supporting him/her in the ontology development process. In this
way, only the sentences that can be used in each step of the ontology building process, will be
available for the expert to choose, making the expert’s work easy, and, possibly, improving
his/her performance.
Keywords: Knowledge Representation, Ontology, Controlled Natural Language, OWL.
LISTA DE TABELAS E ILUSTRAÇÕES
Figura 1: Composição de um SBC. Adaptado de Stefik [STEFIK, 1995, pág 297].................................. 7
Figura 2: Um exemplo simples de uma rede semântica. .................................. ................................. 14
Figura 3: Exemplo de uma rede semântica com vários significados. Baseada em Woods, 1975....... 15
Figura 4: Estrutura de uma rede semântica baseada em atributo e valor. ......................................... 16
Figura 5: Uma rede semântica com dois tipos de arcos diferentes. Baseada em Woods, 1975 ........ 17
Figura 6: A representação de um conceito de acordo com as idéias de Brachman. Adaptado de
Brachman, 1976, pág. 137. .................................. .................................. ........................................... 19
Figura 7: Exemplo dos vinhos agora representado por uma estrutura de frames. ............................. 21
Tabela 1: Tipos de referências válidas na sublinguagem de referenciação …................................... 44
Figura 8: Um fragmento de uma ontologia utilizando as sentenças da metalinguagem. ................... 56
Figura 9: Os principais módulos do parser implementado por Blackburn. ......................................... 60
Tabela 2: Mapeamento das sentenças da metalinguagem para DRS….........................................… 62
Tabela 3: A relação entre os construtores da linguagem OWL DL e a metalinguagem. .................... 65
Tabela 4: mapeamento das sentenças para OWL/DL…..................................................................... 68
Figura 10: Mapeamento de uma sentença do tipo 1 para OWL. .................................. ..................... 75
Figura 11: Mapeamento de uma sentença do tipo 7 para OWL. .................................. ..................... 76
Figura 12: Mapeamento de uma sentença do tipo 8 pra OWL............................................................ 77
Figura 13: Mapeamento de uma sentença do tipo 9 pra OWL............................................................ 78
Figura 14: A interface do editor de ontologias proposto. .................................. ................................. 80
Figura 15: As templates das sentenças que podem ser utilizadas pelo usuário para a construção da
ontologia. .................................. .................................. .................................. ................................... 82
Figura 16: Os menus pop-up disponíveis para a definição de um valor para uma propriedade......... 85
Figura 17: A escolha de uma propriedade para a definição de seu tipo. ........................................... 85
Figura 18: A escolha de um tipo para a propriedade. .................................. ..................................... 86
Figura 19: O processo global de construção de uma ontologia utilizando o editor............................. 88
Figura 20: O subprocesso 1 do processo de criação de ontologias. .................................. ............... 90
Figura 21: O subprocesso 2 do processo de criação de ontologias. .................................. ............... 91
Figura 22: O subprocesso 3 do processo de construção de ontologias. .................................. ......... 91
Figura 23: O subprocesso 4 do processo de construção de ontologias.. ........................................... 92
Figura 24: O subprocesso 5 do processo de construção de ontologias. ............................................ 92
Figura 25: O subprocesso 6 do processo de construção de ontologias. ............................................ 93
Figura 26: O subprocesso 7 do processo de construção de ontologias. ............................................ 93
LISTA DE ABREVIATURAS E SIGLAS
BC
Base de Conhecimento
DL
Description Logics
DRS
Discourse Representation Structure
DRT
Discourse Representation Theory
EC
Engenheiro de Conhecimento
LN
Linguagem Natural
LNC
Linguagem Natural Controlada
LPO
Lógica de Primeira Ordem
OWL
Ontology Web Language
RC
Representação de Conhecimento
SBC
Sistema Baseado em Conhecimento
TRC
Tecnologia de Representação de Conhecimento
SUMÁRIO
1 Introdução .............................................................................................................................. 1
2 Sistemas Baseados em Conhecimento.................................................................................. 6
1
O Problema da Representação de Conhecimento............................................................. 8
2
Tecnologias de Representação de Conhecimento .......................................................... 13
3
Modelagem de Conhecimento, Ontologias e a Linguagem OWL................................. 25
4 O Processo de Aquisição de Conhecimento ................................................................... 30
3 O Uso da Linguagem Natural Controlada ........................................................................ 38
1 Porque Utilizar Linguagem Natural Controlada............................................................. 38
2
A Origem da Linguagem Natural Controlada Proposta ................................................. 41
3
A Linguagem Natural Controlada Proposta ................................................................... 43
4 O Mapeamento da Linguagem Natural Controlada para a Linguagem OWL ............. 58
1
A Implementação de um Parser para a Linguagem Proposta ........................................ 58
2
O Mapeamento das DRSs Resultantes do Parser para a Linguagem OWL .................. 64
2.1 Exemplos de Aplicação do Algoritmo de Mapeamento........................................ 75
5 O Editor de Ontologias ....................................................................................................... 79
6 Conclusão ............................................................................................................................. 95
Referências ............................................................................................................................ 102
Anexo I - Algoritmo de Mapeamento de DRS para OWL............................................... 109
1
Capítulo 1
Introdução
A
tualmente o processo construção de bases de conhecimento (BC) é, geralmente,
realizado por um engenheiro de conhecimento (EC) [PÉREZ, 2002]. Sua função
é estudar o domínio em questão por meio de algumas fontes de conhecimento e
representar este conhecimento na BC. Na maioria dos domínios a fonte mais rica de
conhecimento é um especialista no domínio. Sendo assim, o engenheiro de conhecimento
deve procurar adquirir o conhecimento do especialista no domínio e codificá-lo na BC. No
entanto, este processo apresenta algumas desvantagens como, por exemplo, a dificuldade do
especialista para descrever seu conhecimento; a dificuldade do engenheiro para entender o
que o especialista descreve e para representar este conhecimento por meio de uma tecnologia
de representação de conhecimento (TRC) que, muitas vezes, não permite expressar o que o
engenheiro deseja; a grande quantidade de tempo e, conseqüentemente, o alto custo deste
processo; entre outras. Uma desvantagem bastante relevante é que a passagem de
conhecimento de um especialista em um domínio para a BC é feita de forma indireta, ou seja,
2
por não conhecer a TRC, o especialista tem de passar seu conhecimento do domínio para o
EC que por sua vez o introduz na BC. Este processo indireto pode gerar diferentes
interpretações do especialista e do engenheiro quanto ao conhecimento do domínio. Isso
ocorrerá pelo fato de que, conforme nos mostra a semiótica [PIERCE, 1931] [ECO, 1976], é
comum duas pessoas, ao se comunicarem, gerarem interpretações diferentes para uma mesma
sentença. No contexto da construção de BCs este problema de interpretação freqüentemente
ocorre porque o especialista tem conhecimento pleno do domínio, mas geralmente não tem
conhecimento da TRC empregada na construção das BCs. Já o EC, por sua vez, tem pleno
conhecimento da TRC, mas não necessariamente tem conhecimento do domínio da aplicação.
Sendo assim, o resultado desta passagem indireta de conhecimento pode ser uma BC de baixa
qualidade, que não corresponde às expectativas do usuário do sistema.
Se pudermos fazer com que o próprio especialista no domínio construa a BC
diretamente, resolveríamos tanto o problema de comunicação entre o especialista e o EC,
quanto o problema do alto custo dos serviços de um EC. Assim, temos duas alternativas: 1)
podemos fazer com que o especialista no domínio aprenda a codificar seu conhecimento na
forma de uma TRC, ou 2) podemos permitir que ele expresse seu conhecimento por meio de
uma linguagem para representação de conhecimento que ele possa utilizar mais facilmente e
fazermos, então, o mapeamento desta linguagem para uma TRC. A primeira alternativa é uma
tarefa um tanto quanto difícil, pois ele terá que aprender uma linguagem totalmente nova para
se expressar — considerando que o especialista, normalmente, é leigo no assunto de
representação de conhecimento, ou seja, ele pode não ter nenhum conhecimento de
linguagens formais. Já a segunda alternativa, pode ser uma solução viável, contanto que três
fatores sejam levados em consideração, são eles: 1) que a linguagem para representação de
conhecimento utilizada seja semelhante com alguma que o especialista já conheça como, por
exemplo, a linguagem natural; 2) que esta linguagem tenha expressividade suficiente para
3
representar o domínio em questão; e 3) que seja possível obter um mapeamento eficiente dela
para uma TRC. A proposta deste trabalho é estudar a viabilidade de aplicação da segunda
alternativa discutida acima. Para tal, propomos disponibilizar uma linguagem de especificação
de ontologias baseada em uma linguagem natural controlada (LNC) [ALTWARG, 2000] para
que o especialista possa expressar seu conhecimento e, também, automatizar o mapeamento
desta linguagem para uma TRC. Desta forma, estaremos tentando melhorar o processo de
construção de BCs, trazendo o especialista no domínio para o primeiro plano desta tarefa. O
uso de linguagem natural na forma controlada, ou seja, o emprego de um subconjunto de
sentenças válidas na linguagem natural, porém não ambíguas para os especialistas e para o
parser que faz seu mapeamento, é necessário para manter o tratamento computacional da
linguagem de especificação dentro de uma faixa de eficiência razoável, de forma a não
inviabilizar sua implementação.
A questão da expressividade da linguagem de representação é uma questão complexa
sendo dependente, principalmente, da TRC para a qual ela será mapeada, pois, em última
instância, é esta quem define quais propriedades poderão ser modeladas no domínio. A TRC
escolhida para este trabalho foi a linguagem OWL (Web Ontology Language)
[MCGUINESS e HARMELEN, 2003]. A escolha pela linguagem OWL se deve ao fato de ela ser
um padrão proposto pelo W3C (World Web Wide Consortium) para ser a linguagem de
representação da Web Semântica, que é o domínio de aplicação que pretendemos atingir.
A LNC proposta neste trabalho é um subconjunto da linguagem usada pelas pessoas
leigas (não-programadores) para expressar planos no seu dia-a-dia, como a linguagem usada
nas receitas de bolo e nos manuais de faça-você-mesmo. A linguagem utilizada como base
para a criação da LNC proposta neste trabalho, foi proposta por Da Silva [2001], permitindo o
emprego de mecanismos lingüísticos naturais, como o uso de anáforas e elipses. Este tipo de
4
linguagem deve facilitar o entendimento do usuário na tarefa de construir a BC, pois ele
necessitará apenas de aprender a restringir um conhecimento que já dispõe.
Para fazer o mapeamento da LNC para a TRC utilizada na BC, propomos adaptar a
implementação de um parser construído por Blackburn e Bos [1999], baseado na teoria de
representação de discurso (Discourse Representation Theory - DRT) [KAMP, 1981]. Este
parser tem como entrada um texto que representa as sentenças que estarão presentes na BC e
gera como saída uma representação em DRT — muito próxima à lógica de primeira ordem.
Esta representação será, então, processada para construir uma BC representada na linguagem
OWL. A opção de se utilizar o parser já implementado por Blackburn e Bos foi feita pelo fato
de a gramática coberta por ele ser bastante ampla, o que possibilita uma futura expansão da
LNC, inicialmente proposta, de forma muito rápida e eficiente. Além disso, a representação
baseada em DRT nos disponibiliza muito mais recursos para resolver anáforas e elipses mais
elaboradas (bastante comuns em linguagem natural) se no futuro assim o desejarmos. A
linguagem empregada no presente trabalho é um subconjunto da língua inglesa. Esta escolha
reflete simplesmente o fato de já partirmos de uma linguagem e de um parser já existentes
[DA SILVA, 2001]. No entanto, é possível desenvolver o mesmo tipo de proposta para outras
línguas.
É importante salientar que a simples definição de uma LNC que o especialista no
domínio possa utilizar, de forma mais natural, para representar seu conhecimento, em geral,
não resolve o problema de construção de BCs. Deste modo, propomos também neste trabalho
a utilização de um ambiente de edição que auxilie o especialista na tarefa de expressar seu
conhecimento, visto que isto também não é uma tarefa comum para um especialista no
domínio. Este editor deverá ter incorporado um agente, no formato de agenda, que conheça o
processo de construção de ontologias e que guie o especialista do domínio na sua tarefa de
especificação da BC.
5
Com o desenvolvimento desta LNC, do seu mapeamento para a TRC utilizada, e a sua
integração com o ambiente de construção de BCs, pretendemos, tornar a tarefa de construir
BCs mais eficiente e menos custosa.
No capítulo 2 deste trabalho, discutimos o que é um sistema baseado em
conhecimento, quais os problemas envolvidos na representação de conhecimento, as
principais tecnologias de representação de conhecimento utilizadas para codificar bases de
conhecimento, e a principal fase do desenvolvimento de um sistema baseado em
conhecimento — a fase de aquisição de conhecimento. Ainda no capítulo 2, apresentamos
uma breve discussão sobre o tipo de conhecimento que a linguagem proposta por este trabalho
pretende focar (as ontologias) e porque mapeamos a linguagem proposta para a linguagem
OWL DL. No capítulo 3, discutimos o emprego de LNCs em diversas tarefas, a origem da
linguagem por nós proposta e, finalmente, apresentamos a LNC que utilizaremos como
interface entre um especialista no domínio e a BC por ele construída. No capítulo 4,
apresentamos a implementação de um parser para a LNC proposta e o mapeamento desta para
a linguagem OWL DL. No capítulo 5, propomos algumas facilidades que um editor deveria
prover para auxiliar o especialista no domínio em sua tarefa. Finalmente, no capítulo 6,
apresentamos uma discussão dos resultados obtidos e os possíveis trabalhos futuros desta
dissertação.
6
Capítulo 2
Sistemas baseados em
conhecimento
U
m sistema baseado em conhecimento (SBC)1 é um sistema de computador que é
guiado pelo conhecimento específico de um domínio para resolver problemas
sobre este domínio. Ou ainda, segundo Stefik [1995, p. 297], “um sistema
[baseado em] de conhecimento é um sistema de computador que representa e usa
conhecimento para cumprir uma tarefa”.
Na década de 70 quando estes sistemas começaram a ser desenvolvidos acreditava-se
que se eles tivessem o conhecimento necessário, poderiam superar ou equiparar o
desempenho
de
especialistas
humanos
em
tarefas
bem
definidas
[RUSSEL e NORVING, 2004, p. 352]. Um dos primeiros SBCs desenvolvidos foi o MYCIN
criado para diagnosticar infecções sangüíneas [FEIGENBAUM, BUCHANAN e LEDERBERG, 1971].
Com cerca de 450 regras, o MYCIN foi capaz de fazer diagnósticos tão bem quanto alguns
especialistas
1
e
até
melhor
de
que
alguns
médicos
em
início
de
carreira
Também chamado de sistema inteligente ou sistema especialista. Mark Stefik [1995, p. 297] faz uma breve
discussão sobre os termos sistema especialista e sistema baseado em conhecimento.
7
[RUSSEL e NORVING, 2004, p. 24]. Esta e outras aplicações impulsionaram a criação dos SBCs
que hoje são desenvolvidos para desempenhar as mais diversas tarefas, a saber: interpretação
de dados, simulação, diagnóstico, projeto, planejamento, monitoramento, depuração, reparo,
instrução e controle [WATERMAN, 1986].
Um SBC é composto geralmente por uma interface com o usuário — que permite ao
usuário utilizar o sistema; uma interface de aquisição de conhecimento — que permite que o
conhecimento necessário seja colocado no sistema; uma BC e um motor de inferência (ou
raciocinador), como mostrado na Figura 1 a seguir. A BC e o motor de inferência são as duas
partes essenciais de um SBC. A BC contém a representação de conhecimento do domínio
sobre a qual o motor de inferência irá trabalhar para encontrar soluções para um problema de
um domínio em particular.
Usuário
Especialista
e EC
Interface com
o usuário
Interface de
aquisição
Fatos e
questões
Resultados
Conhecimento
Sistema de
inferência
Conhecimento
Base de
Conhecimento
Sistema Baseado em Conhecimento
Figura 1: Composição de um SBC. Adaptado de Stefik [1995, p. 297].
Na próxima seção, vamos levantar os principais pontos que devem ser considerados
durante o processo de representação de conhecimento. Em seguida, vamos apresentar algumas
tecnologias utilizadas para representar conhecimento, e seus problemas inerentes. Ainda neste
8
capítulo apresentamos o tipo de conhecimento que estamos interessados em representar e os
problemas envolvidos na fase de aquisição deste conhecimento.
1
O problema da representação de conhecimento
A área de representação de conhecimento (RC), na ciência da computação, é uma
subárea da inteligência artificial que estuda como o conhecimento pode ser representado e
quais os tipos de raciocínio podem ser feitos com este conhecimento [GINSEBERG, 1994].
Apesar de parecer uma tarefa fácil, os problemas começam quando nos perguntamos: o que
exatamente é conhecimento? Qual é a diferença entre dados, informações e conhecimento?
Segundo Sattler [2005], dado é o termo sempre utilizado para se referir as informações
armazenadas no computador, são fatos representados em linguagem legível (números,
caracteres, imagens ou outros métodos de gravação), não carregando, por si só, nenhum
significado. Informação é um dado que foi interpretado, traduzido, ou transformado para
revelar o seu significado, é uma coleção de fatos dos quais podemos tirar conclusões.
Conhecimento, por sua vez, pode ser visto como o resultado psicológico da percepção, da
aprendizagem e do raciocínio; o corpo da verdade, informação, e princípios adquiridos pela
humanidade; informação avaliada e organizada na mente humana que pode ser usada
intencionalmente.
Talvez por esta definição de conhecimento ser de certa forma filosófica é que a
representação de conhecimento é um campo da inteligência artificial que vem sendo
amplamente discutido. Davis, Shrobe e Szolovitis [1993], em um dos principais artigos sobre
o assunto intitulado “What is knowledge representation” (“O que é representação de
conhecimento”), enumera cinco importantes papéis que uma representação de conhecimento
deve assumir, reforçando a afirmação de que representar conhecimento não é uma tarefa fácil.
De fato, de nossos estudos podemos dizer que muito é discutido sobre o assunto, porém não
existe uma linearidade sobre como proceder para representar conhecimento. O que
9
observamos é que as diversas publicações levantam aspectos que uma representação deve ter,
ou que não deve ter [WOODS, 1987], papéis que uma representação deve assumir
[DAVIS, SHROBE e SZOLOVITIS, 1993], como a representação deve ser utilizada pelo
raciocinador, e como as tecnologias de representação de conhecimento2 influenciam a RC
[DAVIS, SHROBE e SZOLOVITIS, 1993] [WOODS, 1987], mas isto ainda está muito longe de ser
algo linear e fácil de reproduzir.
Podemos entender a representação de conhecimento como uma estrutura simbólica que
representa o conhecimento sobre algo. Esta estrutura deve ter algumas características
importantes para que o conhecimento por ela representado possa ser utilizado e interpretado
de forma correta. Davis, Shrobe e Szolovitis [1993] destacam que, primeiramente, devemos
entender que nenhuma representação é precisa. De fato, os elementos do mundo real, sejam
objetos ou fatos, tem relacionamentos e detalhes que muitas vezes nem mesmo nos damos
conta. Por exemplo, quando representamos as entidades envolvidas no sistema de uma
empresa, temos clientes, funcionários, proprietários e etc. Alguns atributos destas entidades,
que são importantes para o sistema, podem ser representados como: nome, endereço, telefone
e etc. Mas, na maioria das vezes, ignoramos que estas entidades são pessoas e que também
fazem parte de outros grupos sociais. Isto acontece porque as outras informações não são
relevantes para o nosso sistema e, portanto, não precisam ser representadas naquele escopo.
Segundo Davis, Shrobe e Szolovitis [1993], uma representação pode ser vista como um
substituto (que nunca é preciso) dos elementos do mundo real que podem ser utilizados em
simulações do mundo real3, as quais muitas vezes não podem ser feitas na realidade. Para os
autores, somente representações para elementos formais, como entidades matemáticas, podem
ser capturadas exatamente. Este ponto de vista também é compartilhado por Woods
2
3
Também conhecidas como linguagens de representação de conhecimento.
Visto desta forma o próprio fato de raciocinar sobre uma representação (fazer uma simulação) é em parte um
substituto para as ações no mundo, quando não podemos ou não queremos (ainda) executar uma ação.
10
[WOODS, 1987], que diz que “uma característica inevitável do modelo interno de mundo é que
ele é na melhor das hipóteses um modelo incompleto do mundo externo real”. Para Woods
estas diferenças entre o mundo interno (modelo do mundo) e o mundo real podem acontecer
por que:
a)
O mundo está em constante mudança, e as representações podem não
acompanhá-las;
b)
Existe uma enorme quantidade de coisas que devem ser modeladas, e a
representação pode não ser completa;
c)
As limitações que a própria tecnologia de representação impõe — a
expressividade das linguagens empregadas na representação de conhecimento
muitas vezes não é suficiente para que possamos representar tudo o que
desejamos.
De fato, o mundo real é cheio de detalhes, sua complexidade é imensa, e modelar tudo
isso fielmente parece realmente impossível, não sendo, na maioria das vezes, necessário (pois
se está interessado em aspectos mais simples do problema) e nem desejável (devido à
complexidade que isto poderia acarretar). Desta forma, devemos ter ciência de que o modelo
de mundo representado em um sistema baseado em conhecimento geralmente não
corresponde exatamente ao mundo real.
Como não podemos representar o mundo real de forma precisa, devemos então
selecionar quais as propriedades que são mais importantes de serem destacadas em cada
representação. Para Davis, Shrobe e Szolovitis “é como se víssemos o mundo através de uma
lente que determina o que podemos ver, trazendo alguma parte do mundo para o foco e
deixando as outras partes com um efeito distorcido”. Isto é o que os autores chamam de
conjunto de compromissos ontológicos que estamos assumindo ao representar conhecimento
— ao escolher uma representação estamos decidindo quais são os aspectos importantes do
11
mundo que devem fazer parte da representação. Eles ainda comentam que os primeiros
compromissos ontológicos são assumidos quando escolhemos uma tecnologia de
representação de conhecimento, pois toda tecnologia4 tem limites em sua expressividade, não
nos permitindo representar alguma coisa sobre o domínio em questão.
Um outro aspecto que não podemos deixar de destacar é que uma RC será a fonte de
conhecimento para um raciocinador que, mecanicamente falando, nada mais é do que um
processo computacional. Desta forma, também temos que nos preocupar com a eficiência
deste raciocinador. As tecnologias de representação de conhecimento tipicamente especificam
dois conjuntos de inferências que são úteis para melhorar a eficiência do raciocinador: o
conjunto das inferências sancionadas e o das inferências recomendadas. As inferências
sancionadas são aquelas consideradas possíveis de serem realizadas para tirar conclusões
sobre o conhecimento disponível na representação. O conjunto das inferências recomendadas
é um subconjunto das inferências sancionadas que guia o raciocinador para fazer inferências
eficientes. Como o conjunto de inferências sancionadas é muito grande, qualquer sistema
automatizado que tentar raciocinar guiado somente por elas brevemente se encontrará perdido
em suas próprias escolhas [CERCONE e MCCALLA, 1987, p.5]. Um outro problema em relação
à eficiência do raciocinador é que existe um balanceamento implícito entre o poder de
expressividade de uma representação e a eficiência computacional do raciocinador que a
processa. Woods [WOODS, 1987, p. 52] sustenta que “quanto maior a fidelidade do modelo
menor é a simplicidade e a eficiência de seu uso”. Uma opinião também compartilhada por
Stefik [1995]: “tipicamente, um aumento na precisão requer um decréscimo na eficiência”.
Por isso, sempre devem ser observados os objetivos de cada representação de forma a
maximizar sua precisão ou sua eficiência.
4
Algumas tecnologias de RC serão apresentadas na seção 2.3.
12
Ainda quanto a este assunto, Woods [1987, p. 65] destaca dois aspectos que devem ser
considerados ao representar conhecimento: a eficácia notacional, que “se preocupa com a
forma atual e a estrutura da representação, assim como o impacto desta estrutura nas
operações do sistema”; e a adequação expressiva (expressive adequacy), que diz respeito ao
“poder expressivo da representação”, ou seja, o que pode ser representado. Ele ainda
subdivide a eficácia notacional em alguns pontos: eficiência computacional, clareza
conceitual, concisão da representação e facilidade de modificação; e sustenta que as pesquisas
na área de RC deveriam se dedicar simultaneamente à eficácia notacional e à adequação
expressiva.
Um outro ponto importante de ser destacado é que a tecnologia de representação de
conhecimento utilizada influencia diretamente a qualidade da RC. Segundo Davis, Shrobe e
Szolovitis [1993] uma TRC “é um meio de comunicação e expressão pelo qual contamos às
máquinas (e talvez a outras pessoas) coisas sobre um domínio”. Assim, se uma tecnologia de
representação de conhecimento torna possível expressar algo, mas não de forma fácil, então,
nós como usuários reais, podemos nunca saber se interpretamos mal a representação
resultante do uso da tecnologia e somente não sabemos como usá-la, ou se a tecnologia
empregada verdadeiramente não pode expressar alguma coisa que gostaríamos de dizer. A
representação resultante deve ser legível e redigível não só para a máquina, mas também para
nós humanos. Além disso, os autores destacam que uma tecnologia de representação é uma
linguagem na qual nos comunicamos, e, desta forma, devemos ser capazes de nos expressar
com ela sem nenhum esforço heróico.
Após levantar alguns aspectos que devemos ter em mente enquanto representamos
conhecimento, discutiremos na próxima seção as principais tecnologias empregadas para
representar conhecimento.
13
2
Tecnologias de representação de conhecimento
A maioria das tecnologias de representação de conhecimento conhecidas atualmente
tem algum fundamento na lógica. O poder expressivo da lógica de primeira ordem5 (LPO) fez
com que ela fosse muito utilizada para representar conhecimento nos primeiros SBC. Segundo
Cercone e McCalla [1987] “... não existe nenhuma dúvida de que a precisão formal e a
interpretabilidade da lógica são úteis e fornecem certos tipos de expressividade na qual os
outros esquemas de representação de conhecimento falham”. Porém, quanto à eficiência a
LPO deixa a desejar. A este respeito Cercone e McCalla discute que, para representar
restrições de tempo e espaço, a LPO necessitaria de uma quantidade enorme de predicados e
que a tentativa de tornar estas representações consistentes seria quase impossível.
Bittencourt [2001, p. 258] ainda discute que existem problemas com respeito à facilidade de
uso da LPO. Segundo ele, quando modelamos um domínio é muito comum termos a
necessidade de expressar conhecimento incerto e incompleto, o qual a LPO não consegue
representar diretamente. Por isso, novas abordagens à representação de conhecimento
surgiram com o intuito de suprir estas necessidades.
As redes semânticas são uma destas abordagens. Elas foram introduzidas por
Quillian [1968] e representam conhecimento por meio de grafos, sendo que os nós
representam conceitos e os arcos entre eles representam os relacionamentos semânticos entre
os conceitos. Existem vários tipos de redes semânticas, cada uma enfatizando diferentes tipos
de
relacionamentos
entre
as
informações
representadas
na
rede
[CERCONE e MCCALLA, 1987, p. 9].
Em termos de poder expressivo as redes semânticas são similares a LPO. Além disso, a
facilidade de se representar herança de características fez com que o interesse pelas redes
semânticas se tornasse ainda maior. Nestas redes, as características descritas em uma
5
Também chamada de cálculo de predicados de primeira ordem [RUSSEL e NORVING, 2004, p. 232].
14
categoria superior de elementos são herdadas por todas as categorias inferiores, desta forma, o
raciocínio sobre herança tornou-se muito simples, pois basta caminhar através dos arcos para
descobrir se uma característica de um objeto é “herdada” de uma categoria de objetos
superior. Segundo Russel e Norvig [2004, p. 339] “a simplicidade e a eficiência deste
mecanismo de inferência, comparado à prova de teoremas lógicos, foram os principais fatores
de atração das redes semânticas”.
A Figura 2 representa uma rede semântica simples para um pequeno domínio sobre
vinhos. Todos os vinhos (Wine) são subclasses de uma classe de líquidos potáveis
(PotableLiquid). A classe superior de vinhos (Wine) tem um descritor de vinhos
(WineDescriptor), associado a ela por meio da relação has, e é especificada por três
subclasses de vinhos: tinto (RedWine), rosé (RoseWine) e branco (WhiteWine). As classes
vinho branco, vinho rosé e vinho tinto herdam a relação has da classe mãe. Assim, toda classe
de vinhos terá um descritor associado a ela. A classe cor de vinhos (WineColor) tem três
instâncias: vermelho (Red), rosé e branco (White) ligadas a ela por meio de um arco is-a. As
linhas pontilhadas ligando estas instâncias às classes vinho tinto (RedWine), vinho rosé
(RoseWine) e vinho branco (WhiteWine), indicam que vinhos que pertencem a estas classes
têm as cores ligadas a ela como padrão.
Figura 2: Um exemplo simples de uma rede semântica.
15
Dois trabalhos influenciaram fortemente as pesquisas sobre redes semânticas na
década de 70. O artigo de Woods [1975] que discute o que a estrutura e a notação utilizadas
nas redes semânticas podem significar, e o artigo de Brachman [1977] que discute como se
faz a representação de conceitos, mostrando que ela está um nível acima da representação de
nós e arcos das redes semânticas.
Woods se preocupou com o significado da “semântica” das redes semânticas e
sustenta que as redes que estavam sendo construídas, não estavam sendo interpretadas de
forma adequada. O significado das redes parecia depender da intuição do leitor, que poderia
não ser a mesma intuição do autor da rede. Ele ainda destaca que as especificações semânticas
(transformações de sentenças de entrada para uma representação “semântica”), também
necessitam especificar o seu significado. Para Woods, “muitas técnicas usadas nas redes
semânticas existentes são inadequadas para representar conhecimento em geral”. Ele também
fala que uma representação semântica deve ter uma adequação lógica — deve ser formal,
precisa e não ambígua — e que, além disso, deve existir um algoritmo que traduz uma
sentença nesta representação e um outro algoritmo capaz de utilizar esta representação
resultante para fazer inferências e deduções.
A Figura 3 é um exemplo utilizado por Woods para falar sobre o problema da
“semântica” das redes semânticas. O que esta rede representa? “o conceito de ‘telefone preto’,
ou talvez o relacionamento dos conceitos telefone e negritude — isto é, que telefones são
pretos (todos os telefones? Alguns telefones?)” [WOODS, 1975, p. 49].
Figura 3: Exemplo de uma rede semântica com vários significados. Baseada em Woods, 1975.
16
Woods chama a atenção para o fato de que, além de especificar os tipos de nós e arcos
que podem ser usados em uma rede semântica, também é importante especificar o que cada
um destes tipos de arcos significam (representam). Ele utiliza diferentes estruturas de nós e
arcos para tentar representar os conceitos e as especificações sobre o que elas significam.
Segundo ele, as estruturas podem ser baseadas na noção de atributo e valor como na Figura 4
a seguir, na qual os arcos ou ponteiros são atributos (heigth, hairColor e Occupation) que
“apontam” para os valores (6 feet, Brown e scientist).
Figura 4: Estrutura de uma rede semântica baseada em atributo e valor. Baseada em Woods, 1975.
Mas se tivéssemos que representar a sentença de entrada “John’s height is greater than
6 feet”, uma estrutura baseada em atributo e valor não seria mais adequada, pois o nó John
estaria ligado por meio de um arco height a um nó greaterThan 6 feet que não é mais um
valor para um atributo (height), mas um predicado que deve ser verdade para um valor (a
altura real de John). Desta forma, teríamos duas especificações de significado para a estrutura
de arcos e nós, sendo que alguns arcos apontariam para valores e outros para predicados.
Um outro problema da estrutura de arcos seria a sentença de entrada “John hit Mary”,
que poderia se representada de forma que o verbo hit se tornaria um arco de ligação entre
John e Mary, sendo que este arco não representaria mais um valor, ou um predicado, como
nos exemplos acima, mas sim uma relação entre os nós, como mostra a Figura 5 a seguir.
Então teríamos mais uma especificação para uma estrutura entre nós e arcos onde os arcos
agora representam relações arbitrárias entre os nós. Em uma rede, como a representada na
17
Figura 5, deveríamos indicar que os arcos height, hairColor e occupation são diferentes do
arco hit, para que a máquina de inferência tratasse os arcos da forma adequada.
Figura 5: Uma rede semântica com dois tipos de arcos diferentes. Baseada em Woods, 1975.
A importância de distinguir entre nós que representam asserções ou fatos e nós que
representam a estrutura da rede é um assunto enfatizado tanto por Woods quanto por
Brachman [1977]. Porém, Brachman enfatiza mais a representação dos conceitos — “no
sentido do que os autores pensam que eles são e como os nós das redes [semânticas] podem
representá-los”. Ele chama a atenção para o fato de que um conceito é muito mais do que um
nó e sugere que um conceito seja representado como um conjunto de propriedades e que estes
nós de definição de propriedades sejam diferenciados dos nós de instanciação presentes na
rede. Brachman fala sobre a representação de classes por meio de nós, considerados nós
conceitos, e o que isso implica, pois os nós que representam classes terão suas propriedades
herdadas pelos nós que serão instâncias dessas classes. Ele também levanta alguns problemas
quanto à maneira que as propriedades dos nós conceitos estavam sendo representadas. O
primeiro problema está no fato de que as propriedades são ligadas aos conceitos por meio de
arcos semelhantes àqueles que representam o fato de que uma classe participa de um
relacionamento com outra classe. O segundo problema está no fato de que a asserção de que
um atributo tem um valor particular para toda instância parece exatamente igual à asserção de
que um indivíduo em particular tem aquele valor. Por exemplo, a asserção <telefone cor
preto> (onde telefone é um conceito — representado por um nó; cor é uma propriedade —
representado por um arco-propriedade; e preto é o valor do atributo — também representado
18
por um nó) representa que todos os indivíduos da classe “telefone” devem ter o valor “preto”
para a propriedade “cor”. Já a asserção <T1 cor preto>, semelhante à anterior, significa
explicitamente que somente o indivíduo “T1” tem como valor da propriedade “cor” o valor
“preto”.
Brachman defende a idéia de um conceito ser representado por um conjunto
estruturado de propriedades, que seriam ligadas ao conceito por meio de um tipo de arco
primitivo que ele chamou de DATTRS (define as attributive parts – defina como parte
atributiva). Estes arcos ligariam um nó conceito a um tipo especial de nó que representa uma
descrição de um atributo ou parte. Este nó especial seria associado com vários outros nós que
juntos representariam a definição da parte ou do conceito, e poderiam incluir os seguintes
arcos: value/restriction — que será ligado a um conceito que representa o tipo dos valores
daquela propriedade; role — que representa a inter-relação entre o arco DATTRS e o nó
conceito; number — que aponta para um predicado e representa um numero dessas partes que
são esperadas para uma instância do nó conceito; modality — que indica se esse atributo é
opcional ou não para o conceito; e o arco default — que aponta para um valor que pode ser
usado durante o processo de inferência, quando nenhum valor é especificado na instância.
Brachman sustenta que este conjunto de arcos é apenas uma sugestão e que nada impede que
outros arcos sejam criados.
Além da idéia dos arcos DATTRS para um nó de descrição, Brachman também sugere
um novo arco chamado ATTRS que representa a instância de um atributo de um conceito
(atributo este ligado ao nó conceito por meio de um arco DATTRS). Desta forma, os arcos
DATTRS associam descrições com conceitos, e os arcos ATTRS introduzem a existência de
um valor particular para uma instância de um atributo. Para entendermos melhor estes arcos
vamos analisar a Figura 6 a seguir. O conceito pessoa (person) é representado com dois
atributos altura (heigth) e peso (weight). As descrições destes atributos estão ligadas ao
19
conceito por meio de arcos DATTRS. Outros arcos, além dos arcos role, como os arcos
value/restriction, number, modality e default sugeridos por Brachman, poderiam estar ligados
aos nós de descrição (DATTRS). O nó “John” é representado como uma instância do conceito
pessoa. Por meio dos arcos ATTRS são feitas asserções que representam instâncias dos
atributos peso e altura de John, que estão ligados aos seus valores correspondentes por meio
dos arcos VAL.
Figura 6: A representação de um conceito de acordo com as idéias de Brachman. Adaptado de
Brachman, 1976, pág. 137.
O objetivo de Brachman com esta estrutura de conceito é permitir que as redes
semânticas sejam melhor entendidas e, principalmente, utilizadas de forma correta pelas
máquinas de inferência, que desta forma poderão distinguir entre nós de descrição e nós de
instanciação e asserção.
Esta abordagem de definir um conceito como um conjunto de propriedades
influenciou muito a concepção de outras tecnologias de RC, entre elas a idéia de frames
introduzidas por Minsky [1975].
O mecanismo de frames é uma outra abordagem para representar conhecimento.
Segundo Cercone e McCalla [1987], a idéia por traz do conceito de frames é “agrupar
20
pedaços de conhecimento, os quais podem se úteis para o entendimento de um conceito ou
situação em particular” (p. 29). Um frame é uma descrição de um conceito. Ele é identificado
por um nome e consiste de um conjunto de atributos, muitas vezes chamados de slots. Os
valores dos slots descrevem as características do conceito que está sendo representado pelo
frame, e podem inclusive referenciar outros frames. O slot mais comum a um frame é o slot
“is-a” cujo valor é o nome do frame hierarquicamente superior. Cada frame possui um frame
hierarquicamente superior, fornecendo assim a base do mecanismo de herança6. Um slot
possui um nome único ao frame em que está definido. Os slots consistem de um conjunto de
atributos de valores particulares — denominados facets. As facets contêm informações que
descrevem características dos slots. Estas informações podem definir explicitamente os
valores que o slot pode assumir ou indicar de que forma calcular ou deduzir o seu valor. As
facets têm um papel fundamental na expressividade dos frames, por permitirem expressar
restrições semânticas sobre os slots, assim como definir mecanismos de instanciação
complexos e diversificados [ÁVILA e MONARD, 1992].
A Figura 7 a seguir mapeia o exemplo dos vinhos agora para a abordagem de frames.
Os frames têm slots que referenciam outros frames. Por exemplo, o frame Wine tem três
valores para o slot subclasses: WhiteWine, RedWine e RoseWine, que referenciam os frames
de mesmo nome. A idéia da representação é a mesma descrita para o exemplo da Figura 2.
6
Característica herdada das redes semânticas.
21
Figura 7: Exemplo dos vinhos agora representado por uma estrutura de frames.
O conceito de deamons, também coopera para que a representação de conhecimento
por frames se torne muito flexível. Um deamon é uma função associada a um slot que é
disparada quando alguma condição é satisfeita, assim como um trigger em um banco de
dados. Podemos, por exemplo, ter um deamon que acrescenta uma determinada facet no slot,
caso o valor inserido em uma outra facet seja aquele determinado pelo deamon. Os deamons
também são úteis para manter a coerência no mecanismo de herança múltipla, e são
responsáveis pelos mecanismos de inferência específicos de cada frame.
Segundo Brachman e Nardi [2003], “devido às suas origens centradas no ser humano,
tanto os frames quanto as redes semânticas foram consideradas mais atraentes e mais
eficientes, do ponto de vista prático, do que as abordagens lógicas”, mas falharam no que diz
respeito à caracterização da precisão semântica, levantando a questão de como fornecer
semântica para estas estruturas de representação. Estudos neste sentido originaram um novo
22
formalismo chamado “redes de herança estruturada” (strutured inheritance networks),
implementado no sistema KL-ONE [BRACHMAN, 1979] [BRACHMAN e SCHMOLZE, 1985].
Além de destacar a computação sobre uma taxonomia como o principal serviço do sistema,
este formalismo também implementa vários construtores de conceitos como: conjunção,
disjunção, negação, restrições universais de valor, hierarquias de papéis (role hierarchies),
mapeamentos papéis-valores, entre outros. Depois disso, o KL-ONE foi incrementado com
uma semântica ‘Tarski-style’ bem definida que fixou o significado das estruturas baseadas em
rede7 e conduziu à definição das Lógicas Descritivas (do inglês Descriptions Logics – DL).
Estas lógicas foram, inicialmente, chamadas de linguagens terminológicas “para enfatizar que
a linguagem de representação foi utilizada para estabelecer a terminologia básica adotada em
um domínio modelado”, e de linguagens de conceitos “para enfatizar o conjunto de
construtores de conceito admitidos na linguagem” [BRACHMAN e NARDI, 2003].
Resumidamente uma lógica descritiva é um fragmento estruturado da lógica de
primeira ordem. Um dos grandes ganhos das lógicas descritivas, em relação à lógica de
primeira ordem, é que os sistemas que utilizam esta abordagem tomam cuidados para que a
linguagem seja simples, de forma que toda inferência possa ser feita em tempo polinomial
(em relação ao número de objetos), assegurando, assim, a tratabilidade da representação de
conhecimento. Além disso, os sistemas de inferência que trabalham com DL permitem dois
tipos especiais de inferência [FRANCONI, 2002]: eles permitem verificar se uma categoria C1 é
um subconjunto de uma categoria C2 — um processo de inferência chamado de subsumption;
e também permitem verificar se um objeto O pertence a uma categoria C — um processo de
inferência chamado de “classificação”.
Devido às suas características, a representação em DL não requer o uso de variáveis,
sendo feita no nível de predicados. Assim, a sentença em lógica de primeira ordem
7
As redes semânticas e os frames, às vezes são assim chamados — estruturas baseadas em rede. Também são
conhecidas como abordagens frames-like [BRACHMAN e NARDI, 2003] .
23
{x | Student(x) ∧ ∃y.friend(x,y) ∧ Married(y)}
se torna em lógica descritiva
Student ⊓ ∃friend.Married onde predicados como “Married” e “Student” denotam
classes (ou conceitos — predicados unários); e predicados como “friend” denotam
propriedades (ou papéis — predicados binários ou relações) [FRANCONI, 1994]. Segundo
Brachman e Nardi [2003, p. 11], um conceito é interpretado como um conjunto de indivíduos,
e um papel é interpretado como um conjunto de pares de indivíduos. Como exemplo,
considere os conceitos atômicos Feminino, Pessoa, Mulher e os papéis atômicos
temFilhos e temParentesFeminino. Utilizando os operadores de intersecção ⊓ (ou
conjunção), união ⊔ (ou disjunção) e complemento ⌐ (ou negação) podemos descrever os
conceitos:
•
“pessoas que não são femininas” Î Pessoa ⊓ ⌐Feminino
•
“indivíduos que são masculinos ou femininos” Î Feminino ⊔ Masculino
Também podemos utilizar os quantificadores universal (∀) e existencial (∃) para
definir restrições sobre os papéis. Por exemplo:
•
“indivíduos que têm filhos do sexo feminino” Î ∃temFilhos.Feminino
•
“indivíduos cujos filhos são todos do sexo feminino” Î ∀temFilhos.Feminino
•
“indivíduos que são pais” Î ∃temFilho.Pessoa ⊓ ∀temFilho.Pessoa.
Outros tipos de restrições de papéis são as restrições de número, as quais restringem a
cardinalidade do conjunto de valores para os papéis. Por exemplo:
•
“indivíduos que têm no máximo 3 filhos e no máximo 2 parentes do sexo
feminino” Î (≤ 3 temFilhos) ⊓ (≤ 2 temParente.Feminino)
•
“uma mulher tendo no máximo duas filhas” Î
Mulher ⊓ (≤ 2 temFilhos.Feminino)
24
Segundo Brachman e Nardi [2003, p.16] em uma base de conhecimento em DL existe
a distinção clara entre o conhecimento intensional — conhecimento geral sobre o domínio do
problema, e conhecimento extensional — conhecimento específico para um problema em
particular. O conhecimento intensional, na forma de uma terminologia ou taxonomia, é
chamado de TBox e traz declarações sobre as propriedades gerais dos conceitos; enquanto o
conhecimento extensional, na forma de asserções, é chamado de ABox e traz declarações
sobre indivíduos do domínio.
A declaração mais básica em um TBox é a definição de um novo conceito em termos
de outros previamente definidos. Podemos definir, por exemplo, o conceito “Mulher” como
“uma pessoa do sexo feminino”: Mulher ≡ Pessoa ⊓ Feminino. Esta declaração é,
normalmente, interpretada como uma equivalência lógica e quantifica condições necessárias e
suficientes para classificar um indivíduo como uma mulher. A este tipo de definição
chamamos de conceitos definidos. Quando não somos capazes de especificar todas as
condições suficientes e necessárias para que um indivíduo seja classificado em um conceito,
podemos definir um conceito primitivo, dizendo que um conceito deriva de outro:
Pássaro ⊑ Animal, representando que pássaro é um tipo de animal. Este tipo de declaração,
normalmente, é interpretado como implicação lógica e quantifica apenas condições
necessárias para classificar que todo pássaro é um animal, mas não quantifica condições
necessárias para classificar que todo animal é um pássaro.
Em um ABox podemos fazer, por exemplo, uma asserção sobre um conceito,
definindo um indivíduo chamado “Ana” que é uma pessoa do sexo feminino:
Feminino ⊓ Pessoa(ANA). Esta definição nos permite derivar que “Ana” é uma mulher.
Também podemos fazer uma asserção de um papel (propriedade): temFilhos(ANA, JOHN),
especificando que “Ana” tem “John” como filho.
25
Vários outros sistemas que implementaram a lógica descritiva, além do KL-ONE,
contribuíram com alguma característica relevante para a DL que conhecemos hoje. Entre eles
podemos citar: Krypton [BRACHMAN, 1983], Classic [COHEN, 1993], Loom [BRILL, 1993] e
GRAIL [RECTOR, 1997].
Nesta seção apresentamos as principais tecnologias de representação de conhecimento
e suas particularidades. Na próxima seção vamos mostrar, especificamente, qual é o tipo de
conhecimento no qual estamos interessados em representar — as ontologias — e a tecnologia
de representação de conhecimento que escolhemos para isso.
3
Modelagem de conhecimento, ontologias e a linguagem OWL
Segundo Guarino [1995], as pesquisa atuais em modelagem de conhecimento tendem a
focar mais a natureza do raciocínio sobre o conhecimento do que a natureza do mundo real.
Desta forma, as representações de conhecimento atuais ficam fortemente dependentes das
tarefas para as quais elas são modeladas. De fato, Clancey [1993] já havia sugerido esta
mudança de perspectiva, argumentando que “o objetivo primário da engenharia de
conhecimento é modelar sistemas no mundo e não replicar como as pessoas pensam”, ou seja,
a modelagem de um domínio deve ser feita de forma independente da tarefa a qual será
realizada sobre ela. Realmente, segundo Guarino, existe uma forte tendência em valorizar as
bases de conhecimento independentes de tarefa — chamadas de ontologias.
A palavra ontologia vem do grego e significa “o estudo do ser”. Na filosofia, ontologia
é uma área da metafísica que “estuda o ser ou a existência, assim como as categorias básicas
existentes, tentando encontrar quais entidades e quais tipos de entidades existem”
[ONTOLOGY, 2005]. Em ciência da computação, o sentido da palavra ontologia é um pouco
diferente e vários autores tentam descrever seu sentido. Segundo Gruber [1996], uma
ontologia é “uma especificação explícita de uma conceitualização”. Por conceitualização
podemos entender um conjunto de objetos, conceitos e outras entidades de um domínio e o
26
relacionamento entre eles. Para Guarino e Giaretta [1995] o problema com a definição de
Gruber é o termo ‘conceitualização’. Pois segundo os autores, uma ontologia deve trazer o
aspecto intensional das coisas — as características de um conceito, “uma rede conceitual a
qual se superpõe a vários possíveis ‘estados das coisas’” —, enquanto uma conceitualização
“é um grupo de relações extensionais descrevendo um ‘estado particular das coisas’”. Para
Borst [1997, p. 12] “uma ontologia é uma especificação formal e explícita de uma
conceitualização compartilhada”, onde o termo “especificação explícita” diz respeito a
conceitos, propriedades, relações, funções, restrições, axiomas, explicitamente definidos; o
termo “formal” diz respeito a ser legível para computadores; e “compartilhado” quer dizer que
existe um conhecimento consensual. Neste trabalho vamos utilizar a palavra ontologia como
“um modelo conceitual sobre determinado domínio, onde podemos representar conceitos e os
relacionamentos entre eles” [KNUBLAUCH, 2004], além de axiomas que regem estes
relacionamentos.
Mas quais são as razões que nos levam a desenvolver uma ontologia? Noy e
McGuiness [2001] levantam as seguintes razões:
•
Para compartilhar entendimento comum de uma estrutura de informações entre
pessoas ou agentes de software: este é um dos objetivos mais comuns ao se
desenvolver uma ontologia. Como exemplo, podemos pensar em vários sites da
web que utilizam termos de uma mesma ontologia como base. Desta forma,
agentes de software serão capazes de extrair e agregar informações a estes
diferentes sites.
•
Para permitir reuso do conhecimento de um domínio: se um grupo de pesquisa
desenvolve uma ontologia detalhada sobre um domínio, outros pesquisadores
poderão reutilizá-la em seus domínios. Assim, se precisarmos de uma grande
ontologia, podemos agregar várias ontologias já existentes, ou se precisarmos de
27
uma ontologia mais completa podemos apenas estender uma ontologia já existente
para os nossos propósitos.
•
Para tornar explícitas as suposições do domínio: especificações explícitas sobre o
conhecimento do domínio são úteis para novos usuários que precisam aprender o
que os termos significam no domínio.
•
Para separar o conhecimento do domínio do conhecimento operacional: o mesmo
conhecimento do domínio pode ser utilizado para implementar várias operações
necessárias no domínio.
•
Para analisar o conhecimento do domínio: quando uma especificação declarativa
dos termos está disponível, a análise formal dos termos é extremamente valiosa na
tentativa de reusar e estender as ontologias existentes.
Apesar das ontologias representarem elementos diferentes para cada domínio,
normalmente, elas possuem alguns componentes básicos que, segundo Gruber [1996] são:
•
Conceitos (ou classes) — são entidades organizadas taxonomicamente;
•
Relações (ou propriedades) — representam a interação entre os conceitos de um
domínio;
•
Axiomas — são usados para modelar sentenças sempre verdadeiras; e
•
Instâncias — representam elementos específicos, ou seja, os próprios dados.
Uma ontologia, em ciência da computação, é desenvolvida utilizando-se uma
linguagem de construção de ontologias, ou seja, uma TRC. Existem inúmeras TRCs
empregadas para esta tarefa, dentre as quais podemos citar [ALMEIDA, 2005]:
•
LOOM: que é descendente da KL-ONE e utiliza lógica descritiva e regras de
produção para representar conceitos, taxonomias, relações, funções e axiomas
[BRILL, 1993].
28
•
Ontolíngua: que combina características de frames e lógica de primeira ordem para
representar conceitos, taxonomias, relações, funções, axiomas, instâncias e
procedimentos [CHAUDHRI, 1998].
•
OML (Ontology Markup Language): que é baseada em lógica descritiva e grafos
conceituais, representando conceitos organizados em taxonomias, relações e
axiomas [KENT, 1999].
•
RDF (Resource Description Framework) e RDFS (RDF Schema): estes padrões
são baseadas em grafos direcionados e apresentam uma sintaxe sobre XML. Eles
foram desenvolvidos pelo W3 Consortium e utilizam um formalismo semelhante
às redes semânticas para representar conceitos, taxonomias de conceitos e relações
binárias [LASSILA e SWICK, 1999].
•
OIL (Ontology Interchange Language): que combina linguagens baseadas em
frames com a semântica formal e serviços de inferência de lógica descritiva
[FENSEL, 2001], tendo como objetivo se tornar uma linguagem para Web
Semântica.
•
DAML (DARPA Agent Markup Language) + OIL: que é uma linguagem de
marcação semântica para a Web baseada em DAML, RDF e RDFS, tendo e
características de linguagens lógicas [HORROCKS, 2001].
Devido ao crescente interesse em colocar semântica nos documentos da Web, segundo
Antoniou e van Harmelen [2004], “pesquisadores dos Estados Unidos e da Europa
identificaram a necessidade de linguagem mais poderosa [do que RDF e RDFS] para modelar
ontologias”. Esta necessidade fez com que um projeto conjunto surgisse entre a linguagem
DAML, proposta pelos Estados Unidos, e a linguagem OIL, proposta pelos europeus,
nascendo, assim, uma linguagem mais rica, chamada de DAML+OIL. Esta linguagem foi o
ponto de partida para que o grupo de trabalho em ontologias para Web da W3 Consortium
29
definisse a linguagem OWL, uma linguagem que tem por objetivo tornar-se um padrão
amplamente aceito como uma linguagem para ontologias na Web. A linguagem OWL possui
maiores facilidades para representar a semântica sobre um domínio e tem como objetivo
modelar a semântica dos documentos na Web e tornar possível o processamento destes
documentos por aplicações de software [MCGUINESS e HARMELEN, 2003].
A linguagem OWL compreende três sublinguagens que combinam um balanceamento
entre expressividade e raciocínio eficiente, são elas:
•
OWL Full: é a sublinguagem que tem maior expressividade. Sua vantagem é a
completa compatibilidade com RDF, tanto sintática como semanticamente. Sua
desvantagem é que ela se torna tão poderosa quanto indecidível, tirando qualquer
possibilidade de suportar raciocínio completo e eficiente;
•
OWL DL: com o intuito de manter a eficiência computacional, esta linguagem é
uma sublinguagem de OWL Full que restringe como os construtores de OWL e
RDF podem ser utilizados, assegurando que a linguagem corresponda a uma lógica
descritiva (DL) bem estudada. Sua vantagem é suportar raciocínio eficiente e sua
desvantagem está no fato de perder a compatibilidade com RDF. Desta forma todo
documento em OWL DL é um documento em RDF, mas nem todo documento em
RDF é um documento em OWL DL.
•
OWL Lite: é uma sublinguagem de OWL DL que restringe ainda mais o
subconjunto dos construtores da linguagem. Sua vantagem é que o raciocínio sobre
ela fica ainda mais simples. Sua desvantagem é, obviamente, a expressividade
limitada.
Neste trabalho, não pretendemos permitir que um especialista em um domínio seja
capaz de representar qualquer tipo de conhecimento. Estamos interessados em dar apoio para
que o especialista construa uma ontologia inicial de um domínio, suficiente para que o
30
engenheiro de conhecimento possa, mais tarde, refiná-la. Sendo assim, a linguagem por nós
proposta deve ser mapeada para uma linguagem de construção de ontologias (ou TRC).
Escolhemos a linguagem OWL DL para este mapeamento, (veja seção 4.2 para maiores
detalhes sobre o mapeamento) primeiramente porque existem ótimos raciocinadores sobre ela,
que com certeza facilitarão o nosso trabalho, como o RACER [HAARSLEV, 2005] e o PELLET
[PARCIA e SIRIN, 2003]. Além disso, a linguagem OWL está se tornando uma linguagem
padrão da W3 Consortium para Web Semântica, o que também nos possibilita utilizar a
linguagem por nós proposta para que usuários leigos construam páginas com semântica na
Web.
Nesta seção apresentamos o conceito de ontologia, as principais linguagens utilizadas
para a construção de ontologias e nossas razões para a escolha da linguagem OWL como a
TRC para qual a linguagem por nós proposta será mapeada. Na próxima seção, vamos falar
sobre como adquirir o conhecimento que é representado por meio de uma TRC.
4
O processo de aquisição de conhecimento
Uma das fases mais importantes no desenvolvimento de um SBC é a fase em que o
conhecimento do domínio é colocado na BC. Segundo Bittencourt [2001, p. 255], o
desempenho de um SBC está diretamente ligado ao conhecimento armazenado em sua BC.
Isto é bastante pertinente, pois é por meio do conhecimento armazenado na BC que o motor
de inferência trabalha para resolver os problemas do domínio. Este conhecimento
normalmente é adquirido de um especialista no domínio8 para o qual a aplicação está sendo
desenvolvida. A este processo de passar o conhecimento de um especialista para um SBC, se
dá o nome de aquisição de conhecimento. Ainda segundo Bittencourt [2001, p. 257], “a
8
Na verdade pode existir a necessidade de se adquirir conhecimento de mais de um especialista do domínio,
como apresentado por Liou [1990, p. 216-219]. No entanto, para a discussão abordada aqui, não nos fará mal
algum se nos referirmos a estes especialistas do domínio somente como um especialista. Será o que faremos de
agora em diante. Além disso, estamos considerando que o especialista e o usuário do SBC sejam a mesma
pessoa. Porém, se o sistema contemplar algum usuário que não é o especialista (o que é comum), este também
deve fazer parte do processo de aquisição de conhecimento.
31
parte mais sensível no desenvolvimento de um SE [sistema especialista, ou SBC] é,
certamente, a aquisição de conhecimento”. Ela é a parte mais problemática do
desenvolvimento de um SBC porque o conhecimento adquirido é o elemento central do
sistema e envolve a passagem de conhecimento de uma entidade humana (o especialista) para
uma entidade “mecânica” (o computador).
Segundo Stefik [1995, p. 295], “dentro da inteligência artificial e da engenharia de
conhecimento, o termo aquisição de conhecimento refere-se a qualquer técnica pela qual
sistemas de computadores podem obter o conhecimento que eles necessitam para executar
suas tarefas”. Porém, o próprio Stefik observa que conhecimento não é como uma substância
que pode ser adquirida ou transportada de um lugar para outro (como sugere o termo
aquisição de conhecimento), ou seja, adquirir conhecimento é muito mais complexo do que
simplesmente passar conhecimento de um especialista para um SBC.
Como os especialistas normalmente não têm conhecimento sobre como construir um
SBC (mais especificamente como representar conhecimento), o processo de aquisição de
conhecimento envolve um profissional qualificado, o engenheiro de conhecimento (EC), que
desempenha o papel de intermediário entre os especialistas e a BC. Segundo Russel e Norving
[2004, p. 252], “um engenheiro de conhecimento é alguém que investiga um domínio
específico, aprende quais conceitos são importantes nesse domínio e cria uma representação
formal dos objetos e relações no domínio”. O processo de investigação de um domínio pode
ser feito por meio de várias fontes de conhecimento, mas com certeza a fonte mais rica sobre
o domínio é o especialista, pois ele já tem conhecimento sobre os procedimentos, estratégias e
regras práticas sobre o domínio e qual é o conhecimento necessário para executá-los. Sendo
assim, o engenheiro de conhecimento deve poder adquirir o conhecimento do especialista no
domínio e codificá-lo na BC. No entanto, este processo apresenta algumas desvantagens
como, por exemplo:
32
•
A dificuldade do especialista em expressar seu próprio conhecimento — muitos
dos procedimentos realizados pelos especialistas envolvem raciocínio implícito
que eles não conseguem descrever. Isto ocorre porque a maioria do conhecimento
na cabeça do especialista está “compilado” (como um programa compilado –
rápido e eficiente, mas ilegível);
•
A dificuldade do EC em entender o que o especialista descreve – o EC tem acesso
ao conhecimento do domínio por um ponto de vista diferente do especialista, o que
complica o entendimento preciso deste conhecimento. Além disso, muitas áreas de
especialidade são altamente técnicas, e o EC pode ter dificuldades em entendê-las
e representá-las corretamente;
•
A participação de vários especialistas com diferentes experiências pode ser
vantajosa, mas ela pode criar conflitos de opiniões e ainda mais problemas de
comunicação [SEE, 1997];
•
A personalidade do especialista também pode trazer dificuldades, pois este pode:
(i) pensar que o sistema irá substituí-lo e, então, não cooperar; (ii) não gostar do
seu trabalho e, então, fornecer informações incorretas; (iii) nunca estar disponível
para as reuniões; (iv) não falar sobre assuntos pertinentes durante a reunião; (v)
não gostar de se comunicar; (vii) concordar com tudo o que o EC diz por simples
falta de interesse; (vii) pensar que sabe tudo sobre SBC e não deixar que o EC faça
a sua parte [SEE, 1997].
•
O custo do processo — esta forma de aquisição de conhecimento é um processo
lento e consequentemente caro, e o tempo do EC (e também do especialista) é
precioso;
33
•
As limitações impostas pela TRC — as limitações de expressividade inerentes às
TRCs muitas vezes não permitem ao EC expressar o conhecimento adquirido de
forma adequada;
Existem basicamente duas formas de um engenheiro de conhecimento obter
conhecimento de um especialista: manualmente ou com a ajuda de computadores. Os métodos
manuais utilizam técnicas emprestadas da engenharia de software, como entrevistas
(estruturadas ou não), análise de protocolo (o especialista resolve alguns problemas enquanto
narra o seu raciocínio em voz alta), análise de discurso (as expressões obtidas nas entrevistas
são analisadas), observação do comportamento do especialista, entre outras. McGraw e
Harbison-Briggs [1989] citam as duas fraquezas mais comuns destas abordagens manuais: o
tempo e o custo necessário para que o EC tenha conhecimento suficiente do domínio para
adquirir conhecimento do especialista e traduzi-lo em código de forma eficiente; e a variedade
de habilidades (técnicas, abordagens e especialidades) que podem ser exigidas do EC durante
o processo de aquisição.
Mas a principal limitação destes métodos é que eles são lentos, caros, e à vezes podem
não
ter
BRIGGS,
podem
um
resultado
[TURBAN e FRENZEL, 1992]
preciso
[MCGRAW e HARBISON-
1989]. Isto acontece, principalmente, por causa dos problemas de comunicação que
ocorrer
entre
o
EC
e
o
especialista
(como
citado
anteriormente)
[TURBAN e FRENZEL, 1992], pois eles estão em contextos diferentes do problema. O
especialista tem conhecimento pleno sobre o domínio, mas não tem conhecimento sobre como
um SBC é construído. Já o EC, tem pleno conhecimento de como construir um SBC, mas
muitas vezes não tem conhecimento nenhum sobre como o domínio da aplicação funciona.
Segundo a semiótica [PEIRCE, 1931] [ECO, 1976], duas pessoas sempre geram interpretações
diferentes sobre o mesmo objeto (neste caso o conhecimento do domínio), o mesmo podendo
ocorrer com uma só pessoa em situações diferentes. Este fato pode ocasionar diferentes
34
interpretações sobre o mesmo assunto (entre o EC e o especialista), ocasionando um processo
de aquisição de conhecimento ainda mais longo e custoso do que ele já se apresenta
[TURBAN e FRENZEL, 1992], [MCGRAW e HARBISON-BRIGGS, 1989].
Pelas razões discutidas acima, o papel do EC como intermediário começou a ser
questionado [ADELLI, 1990]. Surgiu então o interesse na possibilidade de fornecer ferramentas
para aquisição de conhecimento, tornando este um processo direto entre o especialista e o
computador. Segundo Turban e Frenzel [1992] estas ferramentas podem ser subdivididas em
semi-automáticas — ferramentas de software que ajudam o especialista a construir a BC sem
depender (muito ou quase nada) do EC9; e totalmente automáticas — ferramentas que
permitem que a BC seja construída com pouca ou nenhuma necessidade de um EC e de um
especialista10.
Apesar destes tipos de ferramentas reduzirem muito a necessidade do EC como um
intermediário, a maioria delas ainda precisa do EC para algumas tarefas como [ADELI, 1990]:
•
Assessorar o especialista no processo interativo de aquisição de conhecimento;
•
Gerenciar interativamente a ferramenta, configurando-a apropriadamente;
•
Editar as partes mais complexas da BC em colaboração com o especialista;
•
Validar a aplicação da BC em colaboração com o especialista;
•
Implementar a interface do sistema em colaboração com especialista e usuários;
•
Treinar os usuários para uso efetivo do SBC.
Adeli ainda chama a atenção da necessidade do EC estar presente validando o que foi
feito pelo especialista: “a atenção para o controle de qualidade através da validação de cada
9
McGraw e Harbison-Briggs [1989] diz que o especialista pode ser treinado para agir como o EC, mas isto pode
não ser adequado em todos os casos. Desta forma, MacGraw e Harbison-Briggs defendem que deve ser
permitido ao especialista colocar informações sobre o domínio do sistema diretamente, poupando, assim, tempo
do EC que ficará livre para refinar o conhecimento e implementar o SBC.
10
Pesquisas no campo da aprendizagem de máquina permitem que o conhecimento seja induzido por meio da
entrada de exemplos dos especialistas. A ferramenta permite a indução de uma lei através dos exemplos, mas a
aquisição de conhecimento pode não ser de alta qualidade [MCGRAW e HARBISON-BRIGGS, 1989].
35
passo do processo de aquisição de conhecimento é a chave para o desenvolvimento efetivo do
sistema”.
McGraw e Harbison-Briggs [1989] também enumeram algumas vantagens de se
utilizar ferramentas de aquisição de conhecimento:
•
O EC gasta menos tempo aprendendo o domínio, sua linguagem e seus conceitos;
•
O SBC reflete a visão do especialista do domínio ao invés de uma visão
intermediária;
•
A qualidade do conhecimento pode ser melhorada porque o especialista interage
diretamente com a ferramenta que traduz conhecimento em código;
As principais ferramentas de aquisição de conhecimento têm como objetivo construir
um modelo para o domínio da aplicação. Vamos citar algumas destas ferramentas
[MCGRAW e HARBISON-BRIGGS, 1989]:
•
Teiresias: foi projetada para permitir aquisição automática de conhecimento novo
para o sistema MYCIN [BUCHANAN e SHORTLIFE, 1984]. A ferramenta faz uso das
regras de encadeamento-para-frente do MYCIN para adquirir, refinar e editar
conhecimento novo;
•
Ferramentas baseadas em repertory grids: ajudam o EC a determinar a
conceitualização expressada pelo especialista para o seu campo de conhecimento.
São úteis para trabalhar com análises que envolvem classificação, interpretação ou
diagnóstico de problemas. Consistem de uma tabela em que as linhas contêm
problemas do domínio, e as colunas contêm algumas soluções para estes
problemas. O especialista examina as soluções e determina uma nota (valor) para
cada uma delas. A ferramenta, então, ajudará o especialista a melhorar o
conhecimento colocado na tabela. Entre este tipo de ferramenta podemos citar o
36
sistema de transferência de especialidade (Expertise Transfer System – ETS), a
BDM-KAT, a KNACK, e a MORE.
•
Ambientes de aquisição de conhecimento: o AQUINAS — baseada em repertory
grids oferece representação hierárquica permitindo ao especialista decompor
problemas em conjunto menores; o KRITON — ferramenta de aquisição de
conhecimento híbrida, que combina vários métodos para capturar conhecimento,
inclusive automatizando os métodos de entrevista; e o TDE — (TEST
Development Environment) permite ao EC ou especialista treinado construir um
SBC para TEST (Troubleshooting Expert System Tool), por meio de entrevistas
automáticas com o especialista.
O problema é que estas ferramentas de aquisição de conhecimento ainda são voltadas
para a pesquisa e específicas para um certo tipo de aplicação. Desta forma, para que elas
sejam utilizadas para outras aplicações, elas necessitam de mudanças, que normalmente não
são simples de serem feitas. Em conseqüência disso, estas ferramentas tornam-se caras e
bastante limitadas [MCGRAW e HARBISON-BRIGGS, 1989] e, assim, o processo de aquisição de
conhecimento automatizado fica limitado à existência de ferramentas adequadas para o SBC
que está sendo desenvolvido.
Ainda sobre o processo de aquisição de conhecimento (facilitado ou não por uma
ferramenta), é importante dizer que este é um processo interativo e incremental. Um SBC é
desenvolvido e testado usando um grande conjunto de casos. Os resultados obtidos são
discutidos entre o EC e o especialista para determinar se o sistema necessita de ajustes. Em
caso afirmativo, o sistema continua o seu processo de desenvolvimento e aquisição de
conhecimento. Após a conclusão do sistema, Stefik [1995, p. 298] destaca que “a BC é
mudada periodicamente para refletir mudanças ou extensões para o domínio de
conhecimento” e “... em situações de mudanças os sistemas [baseados em] de conhecimento
37
necessitam acomodar novo comportamento sempre baseado em um novo conhecimento”.
Desta forma, a BC do SBC estará sempre em constante atualização.
Neste capítulo mostramos o contexto para o qual estamos desenvolvendo este trabalho.
Apresentamos o que é um sistema baseado em conhecimento, o problema de representar
conhecimento e as principais tecnologias utilizadas para representar conhecimento. Além
disso, apresentamos o conceito de ontologia — o tipo de conhecimento no qual estamos
interessados neste trabalho —, as principais linguagens utilizadas pra construir ontologias e os
motivos que nos levaram a escolher a linguagem OWL DL como a TRC a ser utilizada neste
trabalho. No próximo capítulo vamos falar sobre o uso da linguagem natural controlada e a
origem da linguagem por nós proposta, além de apresentarmos a linguagem natural controlada
que é o objetivo deste trabalho.
38
Capítulo 3
O uso da linguagem natural
controlada
N
este capítulo vamos discutir as razões porque a linguagem proposta por este
trabalho é baseada em linguagem natural. Vamos apresentar, também, a origem
da linguagem proposta e os detalhes de seu desenvolvimento, assim como a sua
expressividade.
1
Porque utilizar linguagem natural controlada
Como discutido anteriormente, a proposta deste trabalho é fornecer um ambiente para
aquisição de conhecimento no qual o especialista poderá interagir com o computador, de
forma direta, para criar um modelo do conhecimento que dispõem sobre o domínio, o qual
poderá ser utilizado em um sistema baseado em conhecimento. Em geral, o especialista tem
conhecimento sobre o domínio do sistema, mas não tem conhecimento sobre a tecnologia de
representação de conhecimento que é utilizada para codificar a base de conhecimento. Sendo
assim, temos duas opções: ou fazemos com que o especialista aprenda a expressar seu
39
conhecimento por meio da TRC utilizada no sistema; ou fornecemos um meio para que o
especialista expresse seu conhecimento de forma mais natural, utilizando uma linguagem que
facilite o seu trabalho.
O processo de aprendizagem de uma tecnologia de representação de conhecimento é
uma tarefa árdua e demorada, pois a maioria destas tecnologias é projetada visando a melhor
forma de representar conhecimento e mantendo sua eficiência computacional, sem se
preocupar com o seu processo de aprendizagem ou sua forma de comunicação com as pessoas
[FUCHS, SCHWERTEL e SCHWITTER, 1999] [HALL, 1990]. Assim, seus usuários têm que
aprender uma forma de expressar seu conhecimento ao sistema por meio de uma linguagem
totalmente diferente daquela a que estão acostumados a usar no dia-a-dia.
Uma outra forma de fazer com que o especialista coloque seu conhecimento no sistema
é disponibilizar uma linguagem parecida com alguma que ele já conheça como meio para
expressar o seu conhecimento. Deste ponto de vista, a linguagem mais adequada seria a
linguagem natural (LN), a qual é de conhecimento de todos e tem aspectos comunicativos
bastante apropriados. Entretanto, além da ambigüidade inerente a tal linguagem, o
processamento de sua forma irrestrita ainda não é viável, apesar dos enormes avanços
alcançados [INTERNATIONAL..., 2003]. No entanto, podemos utilizar apenas um subconjunto
da LN, de forma que este subconjunto não contenha ambigüidade, do ponto de vista do
especialista e do parser que vai processá-lo, e mantenha, assim, seu processamento viável e
seus aspectos comunicativos adequados às necessidades do problema. A utilização da
linguagem natural controlada (LNC) tem sido explorada, com relativo sucesso, em tarefas
como a especificação de requisitos [FUCHS, SCHWERTEL e SCHWITTER, 1999], a aquisição e
representação de conhecimento [HOEFLER, 2004] [SCHWITTER, 2004] [PULMAN, 1996], entre
outras. A eliminação da ambigüidade e a facilidade de aprendizado e uso fazem com que as
LNCs também sejam amplamente utilizadas para a especificação de procedimentos nos quais
40
não pode existir nenhum tipo de ambigüidade como, por exemplo, em manuais de usuário
[ALTWARG, 2000]. Alguns exemplos de uso das LNCs em empresas são: a LNC utilizada pela
Boeing para manutenção do espaço aéreo [BOEING, 2005] e a LNC utilizada pela Scania para
manutenção de caminhões [ALMQVIST e HEIN, 1996], entre outros.
Um outro exemplo de sucesso de uma LNC é a linguagem ACE — Attempt Controlled
English
—
que
foi
inicialmente
projetada
para
especificação
de
requisitos
[FUCHS, SCHWERTEL e SCHWITTER, 1999]. O sucesso de seu emprego nesta tarefa, e as
pesquisas decorrentes de sua melhoria fizeram com que ela evoluísse para uma linguagem que
pode ser utilizada na aquisição e representação de conhecimento [HOEFLER, 2004]. Em termos
de conhecimento prévio, ela exige somente conhecimento básico da gramática inglesa para
que um usuário possa utilizá-la. No capítulo 6 examinaremos as diferenças entre a linguagem
ACE e a linguagem por nós proposta.
Utilizar uma LNC significa dizer que todas as sentenças da LNC são corretas na LN,
mas nem todas as sentenças da LN são permitidas na LNC, já que esta é um subconjunto
daquela. Desta forma, o especialista somente terá que aprender quais são os tipos de sentenças
que ele pode e quais ele não pode utilizar para expressar o seu conhecimento do domínio, o
que é bem mais simples do que aprender a expressar seu conhecimento de uma forma
totalmente nova, ou seja, por meio de uma tecnologia de representação de conhecimento.
A LNC permite que o especialista utilize mecanismos comunicativos (como
quantificadores, qualificadores e figuras de linguagem) para expressar o seu conhecimento de
forma muito mais natural. No entanto, é extremamente importante que o conjunto de
mecanismos comunicativos permitidos na LNC com intuito de facilitar a expressão do
especialista mantenha o processamento computacional da LNC dentro de uma faixa de
eficiência razoável, de forma a não inviabilizar sua implementação.
41
2
A origem da linguagem natural controlada proposta
A linguagem natural controlada por nós proposta tem sua origem no trabalho de Da
Silva [2001]. Em sua tese Da Silva apresenta uma análise da linguagem utilizada por usuários
finais para expressar planos no dia-a-dia como, por exemplo, receitas e manuais de faça-vocêmesmo. Naquele trabalho, Da Silva visava, dentre outras coisas, a obtenção de uma
linguagem-tipo na forma de uma LNC para programação por usuários finais. Contudo, a
função final desta linguagem era a de atualizar uma base de conhecimento construída pelo
designer da aplicação, contendo a ontologia e as extensões criadas pelos usuários. Um ponto
relevante ressaltado naquele trabalho é que a estrutura dos planos descritos pelas pessoas no
dia-a-dia permite expressar dois tipos de conhecimento: o procedimental, quando especificam
o processo a ser executado sobre as entidades de um domínio; e o declarativo, quando
introduzem as entidades a serem usadas no processo (que é semelhante ao tipo de declaração
feita na definição da ontologia de um domínio).
A diferença entre as linguagens comumente empregadas pelos usuários finais para a
especificação de entidades e processos e as linguagens formais (linguagens de programação,
tecnologias de representação de conhecimento, entre outras) está, principalmente, no
mecanismo empregado para a referenciação a objetos. A linguagem normalmente empregada
por estes usuários apresenta uma forma muito natural de operar sobre objetos estruturados,
usando conhecimento de senso comum do domínio e mecanismos lingüísticos como
quantificadores (do tipo “all”, “every” e “each” e plurais), qualificadores, seletores e figuras
de linguagem (anáforas e elipses) para facilitar a referenciação a estes objetos. Tais
mecanismos ajudam as pessoas a fazerem referência às características de objetos complexos
de uma forma direta e simples, uma vez que eles ocultam muitos detalhes sobre a estrutura
usada na implementação do objeto. Além disso, é importante observar que os substantivos,
que descrevem objetos no domínio, geralmente são substituídos por pronomes nas referências
42
subseqüentes a sua introdução no texto, um caso de anáfora. Também é comum o uso de
elipses, limitadas às formas básicas, para ocultar objetos e verbos das sentenças. Neste caso,
os nomes ocultados sempre se referem a objetos já mencionados no contexto formado pelas
sentenças anteriores, podendo ser omitidos sem prejuízo à sua interpretação.
Estes tipos de mecanismos comunicativos são muito importantes, pois tornam o
processo de descrever algo por meio de uma linguagem muito mais natural para os usuários.
Além disso, eles previnem a necessidade de escrever e, portanto, interpretar sentenças muito
longas, o que é particularmente difícil para as pessoas. Por outro lado, devido às suas
características, estas referências são de simples resolução, facilitando em muito sua
implementação. Deste modo, o custo computacional exigido para a resolução destes
mecanismos se torna baixo, quando comparado aos lucros obtidos na comunicação com o
emprego dos mesmos.
A linguagem de planos analisada por Da Silva [2001] deu origem a uma linguagemtipo na forma de uma LNC para programação por usuários finais. Esta linguagem-tipo está
dividida em três sublinguagens, que são as sublinguagens de:
•
Referenciação a objetos, que incorpora os mecanismos comunicativos
anteriormente citados, atuando de forma ortogonal às outras sublinguagens,
visando aumentar a coesão textual e, portanto, facilitar a interpretação por parte do
usuário final;
•
Metalinguagem, que permite a criação e extensão da ontologia de um domínio por
meio da definição de conhecimento declarativo, fazendo amplo uso da
sublinguagem de referenciação a objetos;
•
Controle, que permite a criação e definição do conhecimento procedimental e/ou
do controle inferencial em alguns casos, também utilizando a sublinguagem de
referenciação.
43
É importante ressaltar que, apesar do corpus empregado na análise de Da Silva referirse à língua inglesa, os comentários lá realizados também são válidos para outras línguas
(feitos os devidos ajustes), uma vez que foram analisados elementos que pertencem aos
“mecanismos lingüísticos universais” [LYONS, 1981] como, por exemplo, a estrutura frasal das
diferentes formas de se referenciar um objeto nas linguagens naturais.
Para a linguagem proposta neste trabalho faremos uso somente da sublinguagem de
referenciação e da metalinguagem. Na próxima seção vamos apresentar a linguagem natural
controlada por nós proposta para criações de ontologias, obtida a partir da linguagem-tipo de
Da Silva.
3
A linguagem natural controlada proposta
A linguagem-tipo proposta por Da Silva [2001] foi inicialmente projetada para a
programação por usuários finais. Como o nosso objetivo é auxiliar o especialista a escrever
sua visão do domínio e este especialista pode ser considerado, na maioria das vezes, um
usuário final, podemos fazer uso da linguagem-tipo proposta por Da Silva com alguns ajustes.
Desta forma, podemos aproveitar os ganhos comunicativos e os estudos quanto à facilidade de
uso desta linguagem. Porém, como o objetivo da linguagem-tipo é um pouco diferente do
nosso, fizemos algumas adaptações na mesma para que atendesse as nossas necessidades.
Estas adaptações foram necessárias para aproveitar os recursos disponibilizados pela
linguagem OWL/DL e aumentar, assim, a expressividade da linguagem proposta em relação a
TRC adotada neste trabalho. A linguagem resultante desta adaptação conserva a divisão entre
a sublinguagem de referenciação a objetos e a metalinguagem. Um exemplo dos elementos
presentes na sublinguagem de referenciação proposta é mostrado na Tabela 1 a seguir:
44
Tabela 1: Tipos de referências válidas na sublinguagem de referenciação
Tipo da referência
noun
[a/an] noun
noun(s)
cardinal noun(s)
the/this noun
the noun of [the] noun
pronouns
all [the] noun(s)
each/every noun
Reference and reference
Exemplo
wine
a wine
wines
three grapes
the wine
the sender of the message
It has …
all [the] wines
each message
a color and a body
Esta sublinguagem de referenciação é o diferencial da linguagem proposta em relação
às linguagens citadas por Pulman [1996]. Ele destaca que as sentenças que ele chamou de
“notações no estilo de macro” (parecidas com as sentenças da metalinguagem proposta) não
têm flexibilidade. Pulman utiliza exemplos do tipo: A <subtype> is_a <type>, onde os
elementos entre <...> somente podem ser objetos. A metalinguagem por nós proposta é
formada por sentenças semelhantes, porém, permitimos a utilização de referências mais ricas
ao invés de somente nomear objetos simples. Estas referências permitem que os usuários
trabalhem com objetos complexos de forma natural, inclusive com a utilização de anáforas, o
que nos traz um ganho de usabilidade da linguagem, pois ela ficará mais próxima daquela
com a qual o usuário está acostumado a se expressar. Por exemplo, se o especialista
introduziu o elemento “book” no discurso em uma sentença anterior, digamos, “Book is a
publication”, ele poderá referenciá-lo em outras sentenças posteriores utilizando somente o
pronome “it”, por exemplo, “It has chapters and sections”.
A metalinguagem proposta faz grande uso da sublinguagem de referenciação e será
empregada para definir a ontologia do domínio propriamente dita. Cada sentença permitida na
metalinguagem tem um propósito na definição da ontologia do domínio. As sentenças e seus
propósitos são apresentados no final desta seção.
45
Antes de mostrarmos as sentenças permitidas na metalinguagem é necessário explicar
alguns conceitos importantes sobre a TRC que será utilizada. Em OWL DL uma classe é vista
como se fosse um conjunto de indivíduos com características similares. Elas são representadas
por meio de descrições de classe, que podem ser combinadas com axiomas de classes para
representá-las. Segundo Bechhofer et al [2004], uma descrição de classe pode ser:
•
Um identificador de uma classe, que descreve a classe por meio apenas de um
nome (sem especificar nenhum detalhe sobre a classe). Exemplo: a definição de
uma classe “wine”.
<owl:Class rdf:ID="Wine"/>;
•
Uma enumeração exaustiva dos indivíduos, que juntos formam as instâncias da
classe. Exemplo: a definição de uma classe com todas as cores de vinhos.
<owl:Class>
<owl:oneOf rdf:parseType="Collection">
<owl:Thing rdf:about="#Red"/>
<owl:Thing rdf:about="#Rose"/>
<owl:Thing rdf:about="#White"/>
</owl:oneOf>
</owl:Class>
•
Uma restrição de propriedade, que descreve a classe de todos os indivíduos que
satisfazem uma restrição de propriedade particular. As restrições de propriedade
podem ser restrições de valores ou de cardinalidade. Por exemplo, a restrição de
valor constituída pela definição de uma classe na qual todos os valores da
propriedade “hasParent” são da classe “Human”.
<owl:Restriction>
<owl:onProperty rdf:resource="#hasParent" />
<owl:allValuesFrom rdf:resource="#Human" />
</owl:Restriction>
Ou a restrição de cardinalidade constituída pela definição de uma classe na qual
todos os indivíduos têm no máximo dois valores para a propriedade “hasParent”.
46
<owl:Restriction>
<owl:onProperty rdf:resource="#hasParent" />
<owl:maxCardinality
rdf:datatype="&xsd;nonNegativeInteger">2
</owl:maxCardinality>
</owl:Restriction>
•
A interseção ou união de duas ou mais descrições de classes como, por exemplo, a
definição uma classe “Woman”, que é a intersecção de uma classe “Person” com
uma classe “Female”.
<owl:Class rdf:ID="Woman">
<owl:intersectionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Person" />
<owl:Class rdf:about="#Female" />
</owl:intersectionOf>
</owl:Class>
•
O complemento da descrição de uma classe como, por exemplo, a definição de
uma classe “NotMeat”, a qual é o complemento de uma classe “Meat”.
<owl:Class rdf:ID="NotMeat">
<owl:complementOf>
<owl:Class rdf:about="#Meat"/>
</owl:complementOf>
</owl:Class>
Um axioma de classe, por sua vez, contém tipicamente componentes adicionais que
declaram condições necessárias e/ou suficientes para que um indivíduo pertença a esta classe.
A linguagem OWL DL contém três construtores da linguagem que combinam descrições de
classes com axiomas de classes:
•
subClassesOf: que nos permite definir uma descrição de classe a qual é um
subconjunto de outra descrição de classe como, por exemplo, a definição de uma
classe “Bird” que é uma subclasse de uma classe “Animal”.
<owl:Class rdf:ID="Bird">
<rdfs:subClassOf rdf:resource="#Animal"/>
</owl:Class>
Na definição de uma classe utilizando o axioma subClassOf, o objeto da
declaração subClassOf deve ser um identificador de classe (como no exemplo
acima) ou uma restrição de propriedade (que também representa uma classe).
47
Axiomas de subclasse nos fornecem uma definição parcial para uma classe, ou
seja, eles estabelecem condições necessárias mas não suficiente para
classificarmos um indivíduo como membro de uma determinada classe;
•
equivalentClass: que nos permite definir uma descrição de classe que é
exatamente igual à outra definição de classe como, por exemplo, a definição de
uma classe “Automobile” que é equivalente a descrição de uma classe “Car”.
<owl:Class rdf:about="#Automobile">
<equivalentClass rdf:resource="#Car"/>
</owl:Class>
•
disjointWith: que nos permite definir que uma descrição de classe não tem
nenhum membro em comum com uma outra definição de classe como, por
exemplo, a definição de uma classe “Man” que não tem nenhum indivíduo em
comum com a classe “Woman”.
<owl:Class rdf:about="#Man">
<owl:disjointWith rdf:resource="#Woman"/>
</owl:Class>
Alguns destes construtores de classes não são contemplados em nossa linguagem.
Alguns, como intersectionOf, unionOf, complementOf, simplesmente porque
ainda não conseguimos uma sentença em linguagem natural que seja simples e intuitiva para
que o usuário leigo (como o especialista) não tenha dificuldades em entendê-la e usá-la.
Outros, como class e disjointWith, são utilizados implicitamente para o mapeamento
de uma sentença em LNC para OWL DL, mas a linguagem não contempla sentenças que
podem ser mapeadas diretamente para eles. Os construtores que são contemplados ou não na
linguagem proposta são apresentados na Tabela 3 da seção 4.2.
A linguagem proposta, além da definição de classes, ainda permite a definição de
propriedades para as classes. Uma propriedade em OWL DL é uma relação que pode ligar
uma classe a uma outra classe, ou uma classe a um valor. Na seção 4.2 mostraremos os
48
construtores da linguagem OWL DL e explicaremos quais foram ou não utilizados e o porquê
da não utilização.
A seguir vamos apresentar os tipos de sentenças da metalinguagem, explicitando seu
propósito, um exemplo de uso e sua sintaxe na metalinguagem. É interessante explicar a
notação utilizada nesta parte. Elementos sublinhados são entidades que estão sendo inseridas
na ontologia e, portanto, não fazem parte do léxico; elementos ‘em negrito e aspas simples’
são elementos fixos da linguagem e a abreviação “Ref” significa a presença de uma referência
como as mostradas na Tabela 1 (a qual pode ser composta). As referências marcadas com *
poderão ser qualquer uma das classes já definidas na ontologia. As referências marcadas com
# poderão ser, além de qualquer uma das classes da ontologia, qualquer um dos tipos de dados
permitidos pela TRC empregada. As referências marcadas com + poderão ser qualquer uma
das propriedades já definidas na ontologia para a classe especificada na sentença. E as
referências marcadas com & poderão ser qualquer uma das propriedades já definidas na
ontologia, mas que ainda não tiveram seu domínio especificado.
Sentenças para construção de classes:
1) Propósito: definir uma classe (Ref1) que é uma subclasse de uma outra classe (Ref2).
Exemplo:
a) Wine is a kind of drink.
b) A book is a kind of publication.
c) Wine is a drink.
d) A book is a publication.
Metalinguagem:
a) Ref1 ‘is a kind of’ Ref2* ‘.’
b) Ref1 ‘is a’ Ref2* ‘.’
49
— Nos exemplos “a” e “c”, Ref1 contempla substantivos não contáveis (e.g. wine), que
não admitem o artigo indefinido (“a”). Enquanto, nos exemplos “b” e “d”, Ref1 contempla
substantivos contáveis (e.g. book), que exigem o artigo indefinido (como em “a book”).
Para os propósitos da linguagem, atualmente, não existe muita diferença se o substantivo é
contável ou não contável. Sendo assim, por enquanto, estamos permitimos que os usuários
escolham a forma que julgarem mais natural de se escrever (com ou sem o artigo
indefinido). Porém, gramaticalmente falando, seria errado escrever “a wine”, em uma
sentença com o sentido de referenciar vinhos em geral. Como trabalhos futuros,
pretendemos fazer a verificação de quais substantivos são contáveis ou não e,
conseqüentemente, permitir somente a forma gramaticalmente correta.
2) Propósito: definir uma classe (Ref1) que é uma subclasse de uma outra classe (Ref2) e que
também tem propriedades (Ref3).
Exemplo:
a) Wine is a kind of drink that has color.
b) A book is a kind of publication that has an ISBN.
c) Wine is a drink that has color.
d) A book is a publication that has an ISBN.
Metalinguagem:
a) Ref1 ‘is a kind of’ Ref2* ‘that has’ Ref3 ‘.’
b) Ref1 ‘is a’ Ref2* ‘that has’ Ref3 ‘.’
— Nos exemplos “a” e “c”, Ref1 e Ref3 contêm substantivos não contáveis que não
admitem o uso do artigo indefinido (como “wine” e “color”). Enquanto, os exemplos “b”
e “d”, contêm substantivos contáveis que admitem o uso do artigo indefinido (como em “a
book” e “an ISBN”).
50
3) Propósito: definir classes que são partes (Ref1) de uma classe já definida (Ref2).
Exemplo: A motor is part of an automobile.
Metalinguagem: Ref1 (‘is part of’ | ‘are parts of’) Ref2* ‘.’
4) Propósito: definir uma classe por meio de uma restrição de valor para uma propriedade. A
restrição determina que todos os indivíduos de uma classe (Ref1) que têm, no mínimo, um
indivíduo de outra classe (Ref3) como valor para uma propriedade (Ref2) fazem parte desta
classe. Ou seja, esta restrição requer que pelo menos um valor para a propriedade (Ref2)
seja um indivíduo de uma classe determinada (Ref3) para que ele faça parte da classe que
está sendo definida (Ref1). Podem existir outros valores para a propriedade que não são
indivíduos da classe determinada (em Ref3).
Exemplos:
a) A wine has at least one maker that must be a winery.
b) All wines have at least one maker that must be a winery.
Metalinguagem: Ref1 (‘has’|‘have’) at least one’ Ref2 ‘that must be’ Ref3* ‘.’
— No exemplo “a”, Ref1 contêm um substantivo considerado não contável (e.g. wine)
com o artigo indefinido (“a wine”). Isto é possível porque neste tipo de sentença Ref1 está
referenciando uma instância da classe (um indivíduo da classe wine). Sendo assim,
dependendo do significado da sentença, substantivos não contáveis podem admitir o artigo
indefinido.
5) Propósito: definir uma classe por meio de uma restrição de valor para uma propriedade. A
restrição determina que todos os indivíduos de uma classe (Ref1) que têm como valor, para
uma propriedade (Ref2), somente indivíduos de uma outra classe (Ref3) fazem parte desta
classe. Ou seja, esta restrição requer que todos os valores para a propriedade (Ref2) sejam
indivíduos de uma classe determinada (Ref3) para que ele faça parte da classe que está
sendo definida (Ref1). Esta restrição não requer que o indivíduo da classe que está sendo
51
definida (Ref1) tenha um valor para a propriedade (Ref2), mas se houver um valor, ou
mais, estes devem ser do tipo da classe determinada (em Ref3).
Exemplo:
a) All the wine makers must be wineries.
b) All the makers of wines are wineries.
Metalinguagem:
a) Ref1 Ref2 ‘must be’ Ref3* ‘.’
b) Ref2 Ref1 ‘are’ Ref3* ‘.’
— Ref1 será uma referência quantificada universalmente (“all”), neste caso, o uso do
artigo definido “the” é opcional.
— Ref2 será uma referência que qualifica a propriedade de uma classe (e.g. “makers of
wine” ou “wine makers”).
6) Propósito: definir uma classe por meio de uma restrição de valor para a propriedade. A
restrição determina que todos os indivíduos de uma classe (Ref2) que têm um valor
determinado (Ref3) como valor para uma propriedade (Ref1) fazem parte desta classe. Ou
seja, todo indivíduo que tiver pelo menos uma instância da propriedade (Ref1) com um
valor determinado (Ref3) será um indivíduo desta classe (Ref2).
Exemplo: The color of a redWine must be red.
Metalinguagem: Ref1 ‘of’ Ref2 ‘must be’ Ref3 ‘.’
— Ref1 será uma referência definida, pois qualifica a propriedade de uma classe. O
pronome definido “the” é utilizado na função de um determinante catafórico
[QUIRK et al, 1972, p.155].
— Ref3 poderá ser qualquer um dos valores possíveis para a propriedade definida em Ref1.
52
7) Propósito: definir uma classe por meio de uma restrição de cardinalidade para uma
propriedade. A restrição determina que todos os indivíduos de uma classe (Ref1) que têm
exatamente uma quantidade de valores determinada para a propriedade (Ref2) fazem parte
desta classe.
Exemplo: A wine must have exactly one maker.
Metalinguagem: Ref1 ‘must have exactly’ Ref2 ‘.’
— Ref2 será uma referência do tipo “cardinal noun”.
— Novamente, Ref1 está referenciando uma instância de uma classe (um indivíduo da
classe “wine”). Por isso, o uso do artigo indefinido é admitido com um substantivo não
contável.
8) Propósito: definir uma classe por meio de uma restrição de cardinalidade para uma
propriedade. A restrição determina que todos os indivíduos de uma classe (Ref1) que têm
no mínimo uma quantidade de valores determinada para a propriedade (Ref2) fazem parte
desta classe.
Exemplo: A wine must have at least one maker.
Metalinguagem: Ref1 ‘must have at least’ Ref2 ‘.’
— Ref2 será uma referência do tipo “cardinal noun”.
— Novamente, Ref1 está referenciando uma instância de uma classe (um indivíduo da
classe wine). Por isso, o uso do artigo indefinido é admitido com um substantivo não
contável.
9) Propósito: Definir uma classe por meio de uma restrição de cardinalidade para a
propriedade. A restrição determina que todos os indivíduos de uma classe (Ref1) que têm
no máximo uma quantidade de valores determinada para a propriedade (Ref2), fazem
parte desta classe.
53
Exemplos: A wine must have at most one maker.
Metalinguagem: Ref1 ‘must have at most’ Ref2 ‘.’
— Ref2 será uma referência do tipo “cardinal noun”.
10) Propósito: definir uma classe (Ref1) por meio da enumeração exaustiva de seus indivíduos
(Ref2).
Exemplo: A wine can only be a redWine, a roseWine and a whiteWine.
Metalinguagem: Ref1 ‘can only be’ Ref2 ‘.’
— Ref2, normalmente, será uma referência composta.
— Novamente, Ref1 está referenciando uma instância de uma classe (um indivíduo da
classe wine). Por isso, o uso do artigo indefinido é admitido com um substantivo não
contável.
11) A sentença a seguir pode ser utilizada para três propósitos:
a) Definir uma classe (Ref1) que é exatamente igual uma outra classe que já foi definida
(Ref2).
b) Definir uma propriedade (Ref1) que é exatamente igual a uma outra propriedade já
definida (Ref2).
c) Definir um indivíduo de uma classe (Ref1) que é exatamente igual a um outro
indivíduo já definido (Ref2).
Exemplo: A car is also known as an automobile.
Metalinguagem: Ref1 ‘is also known as’ Ref2*+ ‘.’
— A diferenciação entre cada um dos propósitos será feita mediante uma consulta na base
de conhecimento para verificar se Ref2 é uma classe, uma instância ou uma propriedade já
definida.
54
Sentenças para definição de propriedades e valores para as propriedades :
12) Propósito: definir propriedade(s) (Ref2) para uma classe já definida (Ref1).
Exemplo:
a) A wine has a maker.
b) A book has an edition.
Metalinguagem: Ref1* (‘has’ | ‘have’) Ref2 ‘.’
13) A sentença a seguir pode ser utilizada para dois propósitos:
a) Definir um tipo (Ref2) para uma propriedade (Ref1) já definida anteriormente.
b) Definir uma instância (Ref1) de uma classe (Ref2).
Exemplos:
a) The maker is a winery.
b) W1 is a wine.
Metalinguagem: Ref1& (‘is’ | ‘are’) Ref2# ‘.’
— A diferenciação entre os dois propósitos é feita utilizando a estrutura da referência
Ref1. Para o propósito de sentenças do tipo “a” o artigo definido “the” é utilizado na
função de um determinante anafórico [QUIRK et al, 1972, p.155]. Ou seja, com o propósito
de referenciar uma entidade do discurso que já foi previamente definida. Desta forma,
toda vez que Ref1 for uma referência definida, estamos definindo um tipo para uma
propriedade já existente na ontologia (e, neste caso, Ref2 será uma referência
indefinida), caso contrário, estaremos introduzindo uma nova instância de uma classe na
ontologia. Sentenças do tipo “a” normalmente são utilizadas após a definição de uma
propriedade, empregando-se sentenças do tipo 2, 4, 5, 6, 7, 8, 9 ou 12.
14) Propósito: definir os valores possíveis (Ref2) para uma propriedade já definida
anteriormente (Ref1).
55
Exemplo: The color has possible values red, white and rosé.
Metalinguagem: Ref1& ‘has possible values’ Ref2 ‘.’
— Este tipo de sentença é, normalmente, utilizado após a definição de uma propriedade,
utilizando sentenças do tipo 2, 4, 5, 6, 7, 8, 9 ou 10.
— Novamente o artigo “the” é utilizado na função de um determinante anafórico, pois faz
referência à propriedade definida anteriormente, e Ref2, normalmente, é uma referência
composta.
15) Propósito: definir propriedades (Ref2) para uma classe já definida (Ref1) e a faixa de
valores possíveis (Ref3) para estas propriedades (enumeração).
Exemplo: A wine has a body, with possible values full, medium and
light.
Metalinguagem: Ref1* ‘has’ Ref2 ‘, with possible’ (‘value’ | ‘values’) Ref3 ‘.’
— Ref3, normalmente, é uma referência composta.
16) Propósito: definir propriedades (Ref2) para uma classe já definida (Ref1) e o tipo dos
valores possíveis para estas propriedades (Ref3) — que podem ser classes ou tipos.
Exemplo: A wine has a grape, which is a wineGrape.
Metalinguagem: Ref1* ‘has’ Ref2 ‘, which is’ Ref3# ‘.’
17) Propósito: definir um valor default (Ref2) para uma propriedade já definida de uma classe
(Ref1).
Exemplo: The color has default value rosé.
Metalinguagem: Ref1 ‘has default value’ Ref2 ‘.’
— Ref1 poderá ser qualquer propriedade de qualquer classe, já definida na ontologia, que
já teve seus valores possíveis especificados, e será uma referência definida (com o uso do
56
artigo “the” como determinante anafórico), pois estará referenciando uma propriedade já
definida na ontologia.
18) Propósito: definir um valor (Ref3) para uma propriedade (Ref1) de uma instância (Ref2).
Exemplo: The color of wine1 is rosé.
Metalinguagem: Ref1+ ‘of’ Ref2 ‘is’ Ref3 ‘.’
— Ref1 poderá ser qualquer propriedade de qualquer classe, já definida na ontologia, que
já teve seus valores possíveis especificados, e será uma referência definida, pois estará
qualificando a propriedade de uma instância já definida na ontologia (atuando como um
determinante catafórico)
— Ref2 poderá ser qualquer instância de uma classe que tenha a propriedade Ref1.
Na Figura 08, a seguir, mostramos um exemplo de uso das sentenças da
metalinguagem, no qual definimos um fragmento de uma ontologia. Os números à esquerda
das sentenças correspondem ao número da sentença na metalinguagem.
1)
A winery is a kind of industry.
2)
Wine is a kind of drink that has a maker.
13a) The maker is a winery.
12)
A wine has a color.
14)
The color has possible values red, white and rosé.
6)
The color of a redWine must be red.
6)
The color of a roseWine must be rose.
6)
The color of a whiteWine must be white.
15)
A wine has a body, with possible values full, medium and
light.
17)
The maker has default value Ventana.
13b) FormanCabernetSauvignon is a wine
18)
The color of FormanCabernetSauvignon is red.
18)
The maker of FormanCabernetSauvignon is Forman.
Figura 8: Um fragmento de uma ontologia utilizando as sentenças da metalinguagem.
57
Nesta seção, apresentamos a linguagem por nós proposta para a definição de
ontologias, e um exemplo de seu uso. No próximo capítulo, vamos mostrar como um parser
para esta linguagem foi desenvolvido e o mapeamento da linguagem proposta para a
linguagem OWL DL.
58
Capítulo 4
O mapeamento da linguagem
natural controlada para a
linguagem OWL
O
mapeamento da LNC proposta neste trabalho para uma tecnologia de
representação de conhecimento começa pela implementação de um parser para
esta linguagem. O parser por nós implementado é apresentado na próxima
seção. A seguir apresentamos o mapeamento propriamente dito da LNC proposta para a
linguagem OWL.
1
A implementação de um parser para a linguagem proposta
Um dos principais pontos de destaque na implementação de um parser para a
linguagem proposta é o processo de resolução de anáforas. Para que as anáforas sejam
resolvidas de forma correta, temos que considerar o texto gerado por meio da linguagem
como um discurso, no qual as sentenças possam referenciar entidades que foram introduzidas
em sentenças anteriores. Neste sentido, uma forma de representação de discurso chamada
DRT (do inglês, Discourse Representation Theory) tem fornecido métodos para a resolução
de anáforas e pressuposições de uma forma bastante atraente.
59
Introduzida por Kamp [1981], a DRT é facilmente mapeada para lógica de primeira
ordem, o que sustenta a sua expressividade. Ela representa discursos por meio de DRSs
(Discourse Representation Structures), estruturas que permitem codificar a informação
contida em um discurso e, de uma forma bastante natural, tratar pronomes anafóricos e
pressuposições. Segundo Blackburn e Bos [1999], “a DRT é hoje em dia amplamente aceita
como notação padrão em lingüística e lingüística computacional”. Um exemplo de uso da
DRT
é
a
linguagem
ACE
[FUCHS, SCHWERTEL e SCHWITTER, 1999]
utilizada
para
especificação de requisitos. As especificações em ACE são mapeadas para DRSs que são
utilizadas como a representação lógica interna da base de conhecimento, as quais, por meio de
um processo de inferência, podem mais tarde responder perguntas sobre elas. Outros
exemplos
de
uso
que
podemos
[SCHWITTER e TILBROOK, 2004],
destacar
são
[SCHWITTER, 2004]
os
trabalhos
de
Schwitter
e
Nelken
e
Francez
[NELKEN e FRANCEZ, 1996], entre outros.
A representação que será empregada para DRS será drs([R],[C]), na qual R é um
conjunto de referências do discurso e C é um conjunto de condições a respeito dos elementos
de R. Inicialmente a DRS está vazia (drs([],[])). Conforme o parser recebe as sentenças
em linguagem natural, esta DRS vazia será preenchida com outras DRSs que representam as
sentenças do discurso.
Blackburn e Bos apresenta técnicas de semântica computacional que representam a
linguagem natural por meio da lógica de primeira ordem [BLACKBURN e BOS, 2005] e DRT
[BLACKBURN e BOS, 1999]. Estas representações podem perfeitamente ser utilizadas para
futuras inferências. Segundo Blackburn e Bos, a DRT “é uma das mais influentes (e
certamente uma das mais interessantes) abordagens nos dias de hoje para a [representação]
semântica da linguagem natural”. Blackburn e Bos [1999] apresenta a implementação de um
parser (em linguagem Prolog) para uma gramática do inglês bastante ampla. O parser mapeia
60
linguagem natural em DRSs, resolve as anáforas por meio do conceito de DRS acessíveis e
não acessíveis e também trata pressuposições de forma bastante natural.
Analisando a gramática utilizada por Blackburn e Bos [1999] para a implementação do
parser concluímos que ela cobre grande parte da linguagem proposta neste trabalho e que,
portanto, seu parser poderia ser utilizado (após alguns ajustes) para mapear as sentenças de
nossa gramática para DRSs e, assim, resolver as anáforas e elipses nela presentes. Além disso,
como a gramática de Blackburn e Bos é bastante genérica, isso nos possibilita melhorar a
nossa linguagem e acrescentar cada vez mais flexibilidade a ela no futuro, sem muitas
mudanças no parser. Um outro ponto relevante é que, utilizando esta abordagem de mapear as
sentenças em linguagem natural para uma forma intermediária no nível de discurso (as
DRSs), podemos mapeá-las para diferentes tipos de tecnologias de representação de
conhecimento, bastando, para isso, mapear uma estrutura formal, como as DRSs, para uma
outra estrutura formal (as TRCs), o que se torna bem mais simples do que trabalhar com
linguagem natural controlada.
A Figura 9 mostra os principais módulos que compõe o parser apresentado por
Blackburn e Bos [1999] e como eles interagem entre si.
Figura 9: Os principais módulos do parser implementado por Blackburn e Bos.
1. ReadLine: um módulo que lê o discurso e devolve uma lista de palavras que
representam o discurso lido;
61
2. PresupDRT: este módulo recebe a lista de palavras que representa o discurso e
devolve as DRSs resultantes. Ele inicialmente chama o módulo que contém a
gramática (englishGrammar) passando a lista de palavras que representa o
discurso como parâmetro.
ƒ
EnglishGrammar: este módulo tentará casar o discurso (representada por uma
lista de palavras) à gramática prevista. Internamente este módulo chama outro
módulo que contém o léxico previsto (englishLexicon), sendo este um dos
pontos que foram mudados para atender as nossas necessidades. Cada regra
gramatical e léxica tem uma regra semântica correspondente em DRS, que
utiliza marcações de lambda calculus para orientar a montagem das sentenças
corretamente e outra marcação (alfa) para assinalar as referências do discurso
que
ainda
não
foram
resolvidas
(como
as
anáforas).
O
módulo
englishGrammar ainda faz uso, internamente, de um outro módulo chamado
combine, onde as DRSs de cada regra gramatical e léxica são combinadas e em
seguida são passadas para um outro módulo chamado betaConvert, que irá
resolver as marcações lambda.
ƒ
ResolveDrs: este módulo recebe as DRSs, após a execução do betaconvert, e,
após resolver todas as marcações alfa e montar a DRS resultante do discurso,
termina a execução do módulo PresupDRT;
3. PrintRepresentations: este módulo recebe como entrada as DRSs resultantes de
PresupDRT e, simplesmente, imprime os DRSs.
Um dos pontos que tiveram que ser adaptados para a nossa linguagem é que, no parser
original, todas as palavras do discurso deveriam estar presentes no léxico. Para o nosso caso
isto não é correto, pois, por exemplo, o nome de uma classe ou propriedade pode aparecer
pela primeira vez em sua definição, e não teria sentido exigir que este nome pertencesse ao
62
léxico. Desta forma, modificamos o parser para que nas sentenças que definem novos
elementos aceitasse elementos do discurso que não estivessem no léxico. Assim que o parser
aceitar a sentença que define o novo elemento (ainda fora do léxico), este elemento fará parte
da base de conhecimento. Então, tivemos que acrescentar uma interação da base de
conhecimento com o léxico, de forma que todo elemento acrescentado à base também fosse
acrescentado ao léxico.
Além disso, outras mudanças na estrutura da gramática foram necessárias como, por exemplo,
o acréscimo de alguns tipos especiais de cópula: o “is a kind of”, utilizado para definir uma
subclasse; e o “is part of” utilizado para definir uma classe que é parte de uma outra classe.
Feitas estas considerações, as sentenças da metalinguagem mapeadas para as DRSs
resultantes são apresentadas na Tabela 2 a seguir. Preferimos utilizar sentenças-exemplo ao
invés de sentenças genéricas para facilitar o entendimento. Os elementos sublinhados são
elementos que estão sendo inseridos na ontologia e, portanto, não fazem parte do léxico.
Tabela 2: Mapeamento das sentenças da metalinguagem para DRS.
1)
a) Wine is a kind of drink.
drs([A, B],
[wine(A), drink(B), ako(A, B)])
b) Wine is a drink.
2)
a) Wine is a kind of drink that
has a color.
b) Wine is a drink that has a
color.
3) A motor is part of an
automobile.
drs([A, B, C],
[wine(A), color(C), has(A, C),
drink(B), ako(A, B)])
drs([A, B],
[motor(A), automobile(B),
partof(A,B)])
63
4)
a) A wine has at least one
maker that must be a winery.
b) All wines have at least one
maker that must be a winery.
5)
a) All the wine makers must be
wineries.
drs([A, B, C],
[wine(A), maker(B), winery(C),
atleast(B, 1), mustbe(B, C)])
drs([],
[imp(drs([A],
[wine(A)]),
drs([B, C],
[maker(B),winery(C),
mustbe(B,C), has(A, B),
atleast(B, 1)]))])
b) All the makers of wines are
wineries.
drs([],
[imp(
drs([A, B],
[wine(B), of(A, B),
maker(A)]),
drs([C],
[winery(C),
mustbe(A, C)])
)])
6) The color of a redWine must
be red.
drs([A, B, C],
[color(A), redwine(B), of(A, B),
red(C), mustbe(A, C)])
7) A wine must have exactly one
maker.
drs([A, B],
[wine(A), maker(B),
musthave(A, B), exactly(1, B)])
8) A wine must have at least one
maker.
drs([A, B],
[wine(A), maker(B),
musthave(A, B), atleast(1, B)])
9) A wine must have at most one
maker.
drs([A, B],
[wine(A), maker(B),
musthave(A, B), atmost(1, B)])
10) A wine can only be a
redWine, a roseWine or a
whiteWine.
drs([A, B, C,
[wine(A),
canbe(A,
canbe(A,
canbe(A,
11) A car is also known as an
automobile.
drs([A, B],
[car(A), automobile(B),
alsoknown(A, B)])
12)
drs([A, B],
[wine(A), maker(B), has(A, B)])
A wine has a maker.
D],
redwine(B),
B), rosewine(C),
C), whitewine(D),
D)])
64
13)
a) The maker is a winery.
drs([A, B],
[maker(A), winery(B), range(A,
B)])
b) W1 is a wine.
drs([A, B],
[eq(A,w1), wine(B), isa(A, B)])
14) The color has possible
values red, white and rosé.
drs([A, B],
[color(A), red(B), white(B),
rose(B), possibleValues (A, B)])
15) A wine has a body, with
possible values full, medium
and light.
drs([A, B, C],
[wine(A), body(B), has(A, B),
full(C), medium(C), light(C),
possibleValues(B, C)])
16) A wine has a grape, which
is a wineGrape.
drs([A, B, C],
[wine(A), grape(B), has(A, B),
winegrape(C), range(B, C)])
17) The color has default
value rosé.
drs([A, B],
[color(A), rose(B),
defaultValue(A, B)])
18) The color of wine1 is
rosé.
drs([A, B, C],
[wine1(B), color(A), of(A, B),
rose(C), value(A, C)])
O mapeamento das sentenças da metalinguagem para DRS nos permite processar as
DRSs e alimentar uma base de conhecimento para uma vasta gama de TRCs. Na próxima
seção, apresentamos a linguagem OWL DL destacando o subconjunto que a LNC proposta
neste trabalho cobre e o mapeamento das DRSs para a linguagem OWL.
2
O mapeamento das DRSs resultantes do parser para a linguagem
OWL
Após o texto em LNC ser processado pelo parser, as DRSs resultantes passam por um
algoritmo (vide anexo I) que vai mapeá-las para a linguagem OWL. Das três sublinguagens de
OWL, nossa linguagem cobre parte da OWL DL [MCGUINESS e HARMELEN, 2003].
65
Tabela 3: A relação entre os construtores da linguagem OWL DL e a metalinguagem.
Construtores da linguagem OWL DL
Sentenças da metalinguagem ou
o porquê não cobrirmos.
As características de RDF Shema:
Class: permite definir classes de indivíduos
sem definir seus detalhes.
rdfs:subClassOf: permite definir classes por
meio de uma hierarquia de classes.
rdfs:Property: permite definir relacionamentos
entre indivíduos de uma ontologia.
Não contemplamos este construtor por
entendermos que para se definir uma
classe, alguma característica a respeito de
seus indivíduos deve ser importante.
1e2
2, 4, 5, 6, 7, 8, 9, 11, 12, 15, e 16
Apesar de não existir uma sentença direta
rdfs:subPropertyOf: permite definir hierarquias que defina uma subpropriedade, este
elemento é utilizado implicitamente para
de propriedades.
definir uma propriedade default.
Apesar de não existir uma sentença direta
rdfs:domain: permite definir os indivíduos para que defina o domínio de uma propriedade,
este construtor é utilizado implicitamente
os quais a propriedade será aplicada.
para a definição de uma propriedade.
rdfs:range: permite definir quais indivíduos
13a, 14, 15 e 16
uma propriedade pode ter como seu valor.
Individual: permite definir instâncias
13b
(indivíduos) de classes definidas na ontologia.
Igualdade e diferença:
equivalentClass: permite definir que uma
classe é exatamente igual à outra classe da
11
ontologia.
equivalentProperty: permite definir que uma
propriedade é exatamente igual à outra
11
propriedade da ontologia.
sameAs: permite definir que uma instância é
11
exatamente igual à outra instância da ontologia.
Apesar de não existir uma sentença direta
que defina que um indivíduo é diferente de
outro, este construtor é utilizado
implicitamente para definir que todas as
instâncias que foram definidas na ontologia
são diferentes umas das outras por default,
DifferentFrom: permite definir que um
(salvo aquelas que são explicitamente
indivíduo (instância) é diferente de um outro
declaradas como iguais). Para poupar
indivíduo.
código e facilitar o entendimento, vamos
utilizar o construtor AllDifferent para fazer
isso, pois ele tem o mesmo efeito de
utilizar o construtor DifferentFrom para
cada um dos elementos.
66
AllDifferent: permite definir que vários
indivíduos são diferentes entre si.
Apesar de não existir uma sentença direta
que defina que vários elementos são todos
diferentes entre si, este construtor é
utilizado implicitamente para a definição
de uma classe enumerada.
Característica das propriedades
ObjectProperty: permite definir propriedades
2, 4, 5, 6, 7, 8, 9, 11, 12, 15, e 16
que tem instâncias de classes como valores.
DatatypeProperty: permite definir propriedades
que tem elementos (que são datatypes) como
2, 4, 5, 6, 7, 8, 9, 11, 12, 15, e 16
valores.
InverseOf: permite definir uma propriedade
que é o inverso de uma outra propriedade
TransitiveProperty: permite definir
propriedades que são transitivas.
SymmetricProperty: permite definir
propriedades que são simétricas.
FunctionalProperty: permite definir
propriedades que são funcionais, ou seja, tem
apenas um valor.
InverseFunctionalProperty: permite definir
que o inverso da propriedade é funcional, ou
seja, tem apenas um valor.
Por enquanto a LNC proposta não cobre
estes construtores porque não conseguimos
uma sentença em linguagem natural que
fosse de fácil entendimento para o usuário
leigo.
Restrições de valor para as propriedades:
allValuesFrom: equivalente ao quantificador
“para todo” (∀) da lógica, permite definir que
todo valor para uma propriedade P de uma
5a e 5b
classe X deve ser um indivíduo de uma outra
classe Y, para que um indivíduo faça parte da
classe X.
someValuesFrom: equivalente ao quantificador
“existencial” (∃) da lógica, permite definir que
pelo menos um valor da propriedade P de uma
4a e 4b
classe X deve ser um indivíduo de uma outra
classe Y, para que um indivíduo faça parte da
classe X.
hasValue: permite definir um valor requerido
para uma propriedade P para que um indivíduo 6
faça parte de uma classe X.
Restrições de cardinalidade para a propriedade:
minCardinality: permite definir o mínimo de
vezes que qualquer indivíduo de uma classe X
deve estar relacionado com um outro indivíduo
por meio de uma propriedade P.
8
67
maxCardinality: permite definir o máximo de
vezes que qualquer indivíduo de uma classe X
deve estar relacionado com um outro indivíduo
por meio de uma propriedade P.
cardinality: permite definir uma quantidade
exata de vezes que qualquer indivíduo de uma
classe X deve estar relacionado com um outro
indivíduo por meio de uma propriedade P.
9
7
Datatypes:
xsd datatypes
13a e 16
Axiomas de classe:
oneOf: permite definir classes enumeradas.
disjointWith: permite definir que os indivíduos
de uma classe são disjuntos dos indivíduos de
uma outra classe.
10 e implicitamente nas sentenças 14 e 15
Apesar de não existir uma sentença direta
que defina que os indivíduos de uma classe
são disjuntos dos indivíduos de uma outra
classe, este construtor é utilizado
implicitamente para definir que todas as
classes que foram definidas na ontologia
são disjuntas por default.
Combinações booleanas de descrições de classes:
unionOf: permite definir uma classe como a
união de outras classes já definidas.
complementOf: permite definir uma classe
como o complemento de outra classe já
definida.
intersectionOf: permite definir uma classe
como a interseção de outras classes já definidas.
Por enquanto a LNC proposta não cobre
estes construtores porque não conseguimos
uma sentença em linguagem natural que
fosse de fácil entendimento para o usuário
leigo.
Informações de Cabeçalho:
Ontology
Imports
Definições de versionamento:
versionInfo
priorVersion
backwardCompatibleWith
incompatibleWith
DeprecatedClass
DeprecatedProperty
Anotações sobre as propriedades:
rdfs:label
rdfs:comment
rdfs:seeAlso
rdfs:isDefinedBy
Estes construtores não foram contemplados
por enquanto na linguagem proposta, mas
poderão ser incorporados como
propriedades do documento que especifica
a BC, por meio de um quadro de
propriedades no editor proposto na seção 5.
68
Após descrevermos os construtores utilizados pela linguagem OWL DL para
representar conhecimento e a relação destes construtores com a linguagem por nós proposta,
mostraremos na Tabela 4 abaixo (novamente por meio de exemplos) o mapeamento de cada
uma das sentenças em linguagem natural controlada para a linguagem OWL DL.
Tabela 4: mapeamento das sentenças para OWL/DL.
1)
a) Wine is a
<owl:Class rdf:ID=”Wine”>
<rdfs:subclassof rdf:resourse=”#Drink”/>
kind of drink.
<owl:disjointWith rdf:resourse=”#X”/>**
</owl:Class>
b) Wine is a
drink.
2)
a) Wine is a
kind of drink
that has a
color.
<owl:Class rdf:ID=”Wine”>
<rdfs:subclassof rdf:resourse=”#Drink”/>
<owl:disjointWith rdf:resourse=”#X”/>**
</owl:Class>
<owl:ObjectProperty rdf:ID=”hasColor”11 >
b) Wine is a
<rdfs:domain rdf:resource=”#Wine”>
drink that has
</owl:ObjectProperty>
a color.
3) A motor is
part of an
automobile.
**
11
<owl:Class rdf:ID=”Automobile”>
<rdfs:subclassof
rdf:resourse=”#Automobile_or_part of_Automobile”/>
<owl:disjointWith rdf:resourse=”#X”/>**
</owl:Class>
<owl:Class rdf:ID=”Partof_Automobile”>
<rdfs:subclassof
rdf:resourse=”#Automobile_or_part of_Automobile”/>
<owl:disjointWith rdf:resourse=”#X”/>**
</owl:class>
<owl:Class rdf:ID=”Motor”>
<rdfs:subclassof
rdf:resourse=”#Partof_Automobile”/>
<owl:disjointWith rdf:resourse=”#X”/>**
</owl:Class>
Este tipo de cláusula será repetido para cada uma das classes presentes na ontologia.
Aqui estamos considerando que os valores possíveis para esta propriedade (range em OWL) são classes, e por
isso uma ObjectProperty foi definida. Se os valores possíveis para esta propriedade fossem datatypes, então a
propriedade deveria ser definida como uma DatatypeProperty.
69
4)
a) A wine has at
least one
maker that
must be a
winery.
<owl:Class rdf:ID="Wine">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#hasMaker"/>
<owl:someValuesFrom rdf:resource="#Winery"/>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
b) All wines
have at least
one maker that
<owl:ObjectProperty rdf:ID=”hasMaker”>
must be a
<rdfs:domain rdf:resource=”#Wine”>
winery.
<rdfs:range rdf:resource=”#Winery”>
</owl:ObjectProperty>
5)
<owl:Class rdf:ID="Wine">
a) All the wine
makers must be
<rdfs:subClassOf>
<owl:Restriction>
wineries.
<owl:onProperty rdf:resource="#hasMaker"/>
<owl:allValuesFrom rdf:resource="#Winery"/>
b) All the
</owl:Restriction>
makers of
</rdfs:subClassOf>
wines are
</owl:Class>
wineries.
<owl:ObjectProperty rdf:ID=”hasMaker”>
<rdfs:domain rdf:resource=”#Wine”>
<rdfs:range rdf:resource=”#Winery” >
</owl:ObjectProperty>
6) The color of
<owl:Class rdf:ID="RedWine">
a redWine must
<owl:Restriction>
be red.
<owl:onProperty rdf:resource="#hasColor"/>
<owl:hasValue rdf:resource="#Red"/>
</owl:Restriction>
</owl:Class>
<owl:ObjectProperty rdf:ID=”hasColor” >
<rdfs:domain rdf:resource=”#RedWine”>
</owl:ObjectProperty>
7) A wine must
have exactly
one maker.
<owl:Class rdf:ID="Wine">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#hasMaker" />
<owl:cardinality
rdf:datatype="&xsd;nonNegativeInteger">1
</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
<owl:ObjectProperty rdf:ID=”hasMaker>
<rdfs:domain rdf:resource=”#Wine”>
</owl:ObjectProperty>
70
8) A wine must
have at least
one maker.
<owl:Class rdf:ID="Wine">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#hasMaker" />
<owl:minCardinality
rdf:datatype="&xsd;nonNegativeInteger">1
</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:ObjectProperty rdf:ID=”hasMaker>
<rdfs:domain rdf:resource=”#Wine”>
</owl:ObjectProperty>
9) A wine must
have at most
one maker.
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#hasMaker" />
<owl:maxCardinality
rdf:datatype="&xsd;nonNegativeInteger">1
</owl:maxCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<owl:ObjectProperty rdf:ID=”hasMaker >
<rdfs:domain rdf:resource=”#Wine”>
</owl:ObjectProperty>
10)
A wine can
only be a
redWine, a
roseWine or a
whiteWine.
<owl:Class rdf:ID="Wine">
<owl:oneOf rdf:parseType="Collection">
<owl:Thing rdf:about="#RedWine"/>
<owl:Thing rdf:about="#RoseWine"/>
<owl:Thing rdf:about="#WhiteWine"/>
</owl:oneOf>
</owl:Class>
<Wine rdf:ID="RedWine"/>
<Wine rdf:ID="RoseWine"/>
<Wine rdf:ID="WhiteWine"/>
<owl:AllDifferent>
<owl:distinctMembers rdf:parseType="Collection">
<Wine rdf:about="#RedWine"/>
<Wine rdf:about="#RoseWine"/>
<Wine rdf:about="#WhiteWine"/>
</owl:distinctMembers>
</owl:AllDifferent>
71
11)
a) A car is also
known as an
automobile.
<owl:Class rdf:about="#Car">
<equivalentClass rdf:resource="#Automobile"/>
</owl:Class>
b) A maker is
also known as
a
manufacturer.
<owl:Property rdf:about="#hasManufacturer">
<equivalentProperty rdf:resource="#hasMaker"/>
</owl:Property>
c) Wine2 is also
known as
wine1.
<rdf:Description rdf:about="#Wine2">
<owl:sameAs rdf:resource="#Wine1"/>
</rdf:Description>
12)
A wine has
a maker.
<owl:ObjectProperty rdf:ID=”hasMaker” >
<rdfs:domain rdf:resource=”#Wine”>
</owl:ObjectProperty>
13)
a) The maker is
a winery.
<owl:ObjectProperty rdf:ID=”hasMaker”>
<rdfs:range rdf:resource=”#Winery”12>
</owl:ObjectProperty>
b) W1 is a wine.
<Wine rdf:ID=”W1” />
<owl:AllDifferent>
<owl:distinctMembers rdf:parseType="Collection">
<Class rdf:about="#Instance"/>◊
</owl:distinctMembers>
</owl:AllDifferent>
12
Se este nome fosse um datatype, então a propriedade seria definida como uma DatatypeProperty. Mas como
estamos considerando que este é o nome de uma classe previamente definida na ontologia, definimos uma
ObjectProperty.
◊
Esta cláusula será repetida para cada instância definida na ontologia.
72
14)
The color
has possible
values red,
white and
rosé.
Definição da classe enumerada13:
<owl:Class rdf:ID="WineColor">
<owl:oneOf rdf:parseType="Collection">
<owl:Thing rdf:about="#White"/>
<owl:Thing rdf:about="#Rose"/>
<owl:Thing rdf:about="#Red"/>
</owl:oneOf>
</owl:Class>
<WineColor rdf:ID="Red" />
<WineColor rdf:ID="Rose" />
<WineColor rdf:ID="White" />
<owl:AllDifferent>
<owl:distinctMembers rdf:parseType="Collection">
<WineColor rdf:about="#Red" />
<WineColor rdf:about="#White" />
<WineColor rdf:about="#Rose" />
</owl:distinctMembers>
</owl:AllDifferent>
Definição do domínio da propriedade:
<owl:ObjectProperty rdf:ID=”hasColor”>
<rdfs:domain rdf:resource=”#Wine”>
<rdfs:range rdf:resource=”#WineColor”>
</owl:ObjectProperty>
15)
A wine has
a body, with
possible
values full,
medium and
light.
Definição da classe enumerada:
<owl:Class rdf:ID="WineBody">
<owl:oneOf rdf:parseType="Collection">
<owl:Thing rdf:about="#Full"/>
<owl:Thing rdf:about="#Médium"/>
<owl:Thing rdf:about="#Ligth"/>
</owl:oneOf>
</owl:Class>
<WineBody rdf:ID="Full" />
<WineBody rdf:ID="Médium" />
<WineBody rdf:ID="Ligth" />
<owl:AllDifferent>
<owl:distinctMembers rdf:parseType="Collection">
<WineBody rdf:about="#Full" />
<WineBody rdf:about="#Médium" />
<WineBody rdf:about="#Ligth" />
</owl:distinctMembers>
</owl:AllDifferent>
Definição do domínio da propriedade:
<owl:ObjectProperty rdf:ID=”hasBody”>
<rdfs:domain rdf:resource=”#Wine”>
<rdfs:range rdf:resource=”#WineBody”>
</owl:ObjectProperty>
13
Este tipo de sentença, normalmente, vem após a definição da propriedade por outra sentença (dos tipos 2, 6, 7,
8 e 12), que especifica também o nome da classe domínio da propriedade. O nome da classe enumerada será a
concatenação do nome da classe domínio e do nome da propriedade para qual a faixa de valores está sendo
definida.
73
16)
a) A wine has a
grape, which
is a
wineGrape.
b) A wine has a
yearOfMaking,
which is
integer.
17)
“wineGrape” é uma classe:
<owl:ObjectProperty rdf:ID=”hasGrape”>
<rdfs:domain rdf:resource=”#Wine”>
<rdfs:range rdf:resource=”#WineGrape” >
</owl:ObjectProperty>
“integer” é um datatype:
<owl:DatatypeProperty rdf:ID=”hasYearOfMaking
<rdfs:domain rdf:resource=”#Wine”>
<rdfs:range rdf:resource ="&xsd;nonNegativeInteger”>
</owl:DatatypeProperty>
“hasColor” é uma ObjectProperty:
a) The color has
default value
rosé.
b) The
yearOfMaking
has default
value 1990.
18)
The color
of wine1 is
rosé.
<owl:ObjectProperty rdf:ID="ColorDefaultValue">
<rdfs:subPropertyOf rdf:resource="#hasColor"/>
<owl:Restriction>
<owl:hasValue rdf:resource="#Rosé" />
</owl:Restriction>
</owl:ObjectProperty>
“yearOfMaking” é uma DatatypeProperty:
<owl:DatatypeProperty rdf:ID="YearOfMakingDefaultValue">
<rdfs:subPropertyOf rdf:resource="#hasYearOfMaking"/>
<owl:Restriction>
<owl:hasValue
rdf:datatype="&xsd;nonNegativeInteger">1990
</owl:hasValue>
</owl:Restriction>
</owl: DatatypeProperty>
<Wine rdf:ID="Wine1">
<hasColor rdf:resource="#Rosé" />
</Wine>
As sentenças do tipo 2, 4, 5, 6, 7, 8, 9 e 12 são armazenadas, em uma lista de
propriedades não definidas, até que os valores possíveis da propriedade sejam especificados
(utilizando as sentenças do tipo 13a, 14, 15 e 16) para, então, serem de fato colocadas na base
de conhecimento. Isto é necessário devido ao fato de que, para definir uma propriedade OWL,
necessitamos saber se seus valores possíveis são datatypes ou instâncias de uma classe da
ontologia. Se forem datatypes, então uma DatatypeProperty será definida. Se forem
instâncias de uma classe, então uma ObjectProperty é definida.
As sentenças do tipo 3 seguem a abordagem sugerida por Rector [2004] para a
modelagem de classes que são partes de outras classes (relação todo-parte), visto que a
74
linguagem OWL não contempla este tipo de relação diretamente. Nesta abordagem, estamos
construindo uma superclasse (Automobile_or_partof_automobile) que será especificada pela
classe que representa o todo (Automobile) e por uma outra classe que representa as partes do
todo (Partof_automobile). Depois disso é que realmente construímos a classe-parte que está
sendo definida (motor), que é uma subclasse da classe que representa as partes do todo
(Partof_automobile). Este tipo de modelagem evita erros de interpretação do tipo “a motor is
a kind of autobile”, que seria a interpretação correta no caso de definirmos a classe “motor”
como uma subclasse de “automobile”.
Para processar as sentenças do tipo 13a, 14, 15 e 16, primeiramente verificamos se a
faixa de valores possíveis declarada é um datatype, para que uma DatatypeProperty seja
definida. Se a faixa não for um datatype, então uma verificação é feita na base de
conhecimento para encontrar a classe declarada como a faixa de valores e somente então é
definida uma ObjectProperty. Se a classe procurada não for encontrada, o usuário deverá ser
avisado de que esta sentença poderá ocasionar um erro, porque a classe declarada ainda não
existe na base. Depois que a DatatypeProperty ou a ObjectProperty for devidamente colocada
na base, as sentenças do tipo 2, 4, 5, 6, 7, 8, 9 e 12 podem ser recuperadas e processadas.
As sentenças do tipo 17 também necessitam verificar o tipo da propriedade para a qual o valor
default está sendo declarado. A subpropriedade default declarada deverá ser do mesmo tipo
(DatatypeProperty ou ObjectProperty) da propriedade. Além disso, o valor default declarado
deve estar dentro dos valores permitidos para a propriedade.
O algoritmo responsável por todas estas checagens e, por conseguinte, pelo
mapeamento como um todo, está apresentado no Anexo I. Na próxima seção apresentamos
alguns exemplos de aplicação deste algoritmo.
75
2.1
Exemplos de aplicação do algoritmo de mapeamento
As Figuras 10 a 13 abaixo mostram, por meio de associações, a aplicação do algoritmo
sobre algumas DRSs e o conseqüente mapeamento para a linguagem OWL. As setas das
associações estão enumeradas para facilitar o entendimento da explicação.
Figura 10: Mapeamento de uma sentença do tipo 1 para OWL.
A Figura 10 mostra o mapeamento de uma sentença do tipo 1 (A wine is a drink.) para
a linguagem OWL. Por meio da condição “ako”, o algoritmo identifica que está sendo
definida uma subclasse (associação 1). Mas a relação “ako” traz somente os referentes do
discurso que participam da relação “(A, B)”, então o algoritmo procura pelo nome da
subclasse (“wine(A)” — associação 2), e depois procura pelo nome da classe mãe (“drink(B)”
— associação 3). De posse dos nomes que fazem parte da relação, o algoritmo verifica se a
classe mãe já existe na ontologia e se a subclasse não pertence à ontologia. Se os dois casos
forem positivos, então o texto em OWL é montado, com as associações mostradas na Figura
10, fazendo sempre com que a classe que está sendo definida seja disjunta de todas as demais
da ontologia. Caso contrário, um erro é reportado para o especialista, dizendo que a classe
mãe não está definida, ou que já existe uma classe com o nome da subclasse na ontologia.
76
Figura 11: Mapeamento de uma sentença do tipo 7 para OWL.
A Figura 11 mostra o mapeamento de uma sentença do tipo 7 (A wine must have
exactly one maker.) para a linguagem OWL. Por meio da condição “musthave” o algoritmo
detecta que se trata da definição de uma classe por meio de uma restrição de cardinalidade.
Então ele procura pelo nome da propriedade (“maker(B)” — associação 2) e em seguida pelo
nome da classe que está sendo definida (“wine(A)” — associação 3). De posse do nome da
classe, o algoritmo verifica se esta classe já existe na ontologia, caso contrário um erro é
reportado. Em seguida o tipo da cardinalidade (exactly ou atleast ou atmost) e o número
correspondente é procurado (“exactly(1, B)” — associação 4). E, por último, a restrição de
cardinalidade é definida em OWL, seguindo as associações da Figura 11. Além disso, o nome
da propriedade e da classe correspondente são armazenadas em uma lista de propriedades a
serem definidas, até que o tipo da propriedade seja estabelecido.
77
Figura 12: Mapeamento de uma sentença do tipo 8 para OWL.
A Figura 12 mostra o mapeamento de uma sentença do tipo 16 (A wine has a maker
which is a winery.) para a linguagem OWL. Por meio das condições “isa” e “has” o algoritmo
detecta que se trata da definição de propriedade para uma classe e da sua faixa de valores
(associações 1 e 2). Então ele procura pelo nome da propriedade (“maker(B)” — associação
3) e depois pelo nome da classe (“wine(A)” — associação 4). De posse do nome da classe, o
algoritmo verifica se a classe já existe, senão retorna erro. Em seguida procura pelo nome da
faixa de valores (“winery(C)” — associação 5) e verifica se esta faixa de valores é um
Datatype ou uma classe da ontologia. Se for um Datatype, uma DatatypeProperty é definida,
senão o algoritmo procura se a faixa de valores é uma classe da ontologia. Se for, uma
ObjectProperty é definida, seguindo as associações da Figura 12. Se a faixa de valores não for
nem um Datatype, nem uma classe da ontologia, um erro é reportado dizendo que a faixa não
é válida.
78
Figura 13: Mapeamento de uma sentença do tipo 9 para OWL.
A Figura 13 mostra o mapeamento de uma sentença do tipo 17 (The color has default
value rosé.) para a linguagem OWL. Por meio da condição “defaultvalue” o algoritmo detecta
que se trata da definição de um valor default para uma propriedade (associação 1). Então ele
procura pelo nome da propriedade (“color(A)” — associação 2) e em seguida pelo valor
default que está sendo definido (“rose(B)” — associação 3). De posse do nome da
propriedade, o algoritmo verifica se esta propriedade foi definida como uma
DatatypeProperty ou uma ObjectProperty, pois o valor default será definido como uma
subpropriedade que deve ser do mesmo tipo. Em seguida ele verifica se o valor default
definido é um valor válido para a propriedade. Se for, uma subpropriedade com uma restrição
de valor é definida seguindo as associações da Figura 13. Outros mapeamentos podem ser
verificados no algoritmo presente no Anexo I.
Até agora estamos levando em conta que o usuário da linguagem (o especialista)
escreverá cada uma das sentenças. Por isso, todas as verificações acima são necessárias, além
da verificação de existência das classes utilizadas nas sentenças. Mas podemos melhorar
muito a interação do especialista com a linguagem, disponibilizando um editor que o auxilie
durante a tarefa de construção da ontologia. No próximo capítulo, vamos descrever o editor de
ontologias proposto e suas principais funcionalidades que, esperamos, devem facilitar a tarefa
do especialista.
79
Capítulo 5
O editor de ontologias
C
omo mencionamos nos capítulos anteriores, acreditamos que o especialista terá
menos dificuldades em expressar seu conhecimento por meio de uma linguagem
natural controlada, do que se ele tivesse que expressá-lo por meio de uma TRC.
Tentando auxiliar ainda mais a interação do especialista com a base de conhecimento,
propomos a utilização de um editor dirigido por processo, que sugere uma ordem para a
construção de ontologias, ao mesmo tempo em que filtra as sentenças da metalinguagem e os
elementos das sentenças que devem ser utilizados em cada passo do processo. Este editor é
uma adaptação dos trabalhos de Godoi [2004] e Oliveira [2004], que implementam o
ambiente proposto por Da Silva [2001] para auxiliar um usuário final no processo de estender
uma aplicação de software. A interface do editor pode ser visualizada na Figura 14
apresentada na próxima página.
O editor proposto é formado basicamente por uma área de edição — na qual o texto
que representa a ontologia será composto; uma área que representa o processo de construção
80
da ontologia e sinaliza em qual fase do processo o usuário se encontra; e uma área de
explicação que pode, por exemplo, mostrar ao usuário qual é o significado da sentença que
está sendo composta para a ontologia. Na área de texto o usuário poderá clicar com o botão
direito do mouse e terá a sua disposição uma lista de templates, que representam as sentenças
possíveis de serem utilizadas para editar a ontologia, naquele momento.
Figura 14: A interface do editor de ontologias proposto.
A principal vantagem de utilizar templates é que o usuário não necessita aprender a
linguagem de especificação. O editor disponibiliza as templates das sentenças permitidas na
linguagem e o usuário escolhe aquela que lhe for de interesse. A partir deste ponto, as
referências da sentença podem ser completadas para que ela seja de fato processada pelo
parser. Nesta fase da edição, o editor tem uma intensa interação com a base de conhecimento,
pois, de acordo com a sentença escolhida pelo usuário, a base deverá ser consultada e os
elementos que podem ser usados pelo usuário, para preencher as referências, devem ser
81
disponibilizados por meio de menus pop-up. Esta abordagem evita que o usuário cometa erros
comuns, como, por exemplo, uso do nome de uma classe que não existe, ou o uso do nome de
uma classe onde deveria estar o nome de uma propriedade. Além disso, podemos ter as DRSs
correspondentes a cada uma das templates já pré-processadas, diminuindo assim, o
processamento exigido para mapear as sentenças para a linguagem OWL. Desta forma, as
DRS seriam utilizadas somente para a resolução de anáforas e pressuposições. Uma
abordagem semelhante para edição de textos utilizando LNC é proposta por Schwitter,
primeiramente em um editor para especificações formais [SCHWITTER et al, 2003] e mais
tarde em uma abordagem para representação de conhecimento [SCHWITTER, 2004] e
[SCHWITTER, 2005]. Na abordagem proposta por Schwitter, o usuário começa a digitar o texto
e o editor o auxilia, sugerindo quais classes gramaticais são esperadas nas próximas palavras
das sentenças, forçando, assim, o usuário a utilizar a LNC especificada. No capítulo 6, vamos
discutir as semelhanças e diferenças entre a abordagem proposta por Schwitter e a abordagem
por nós proposta.
As templates disponibilizadas no editor proposto correspondem às sentenças que
compõe a metalinguagem de especificação proposta (apresentadas na seção 3.3). Porém, ao
invés de utilizarmos os elementos “Ref” como apresentamos na seção 3.3, estamos utilizando,
como nome para as referências, os elementos da ontologia esperados em cada uma delas, para
facilitar o entendimento do usuário. As templates estão resumidas na Figura 15, mostrada na
próxima página:
82
1)
a) Class1 is a kind of Class2 *.
b) Class1 is a Class2 *.
2)
a) Class1 is a kind of Class2 * that has Property.
b) Class1 is a Class2 * that has Property.
3) Class1 (is part of | are parts of) Class2*.
4) Class1 (has | have) at least one Property that must be Class2*.
5)
a) Class1 Property must be Class2*.
b) Property Class1 are Class2*.
6) Property of Class1 must be Class2.
7) Class1 must have exactly number Property.
8) Class1 must have at least number Property.
9) Class1 must have at most number Property.
10) Class1 can only be Instances.
11) Class1 is also known as Class2 *+.
12) Class1 * (has | have) Property.
13) Property& | Instance (is | are) Class | Type#.
14) Property & has possible values Values.
15) Class1 * has Property, with possible (value | values) Values.
16) Class1 * has Property, which is Class | Type#.
17) Property has default value Value.
18) Property + of Instance is Value.
Figura 15: As templates das sentenças que podem ser utilizadas pelo usuário para a construção da
ontologia.
Os elementos em negrito são fixos da linguagem, os demais elementos são referências
(dos tipos mostrados na Tabela 1 — seção 3.3) que serão preenchidas pelo usuário com a
ajuda das indicações feitas pelo editor. Para as referências marcadas com * um menu pop-up
deve disponibilizar (após uma consulta na base de conhecimento) todas as classes que já
existem na ontologia, para que o especialista possa escolher uma delas. Nas referências
marcadas com # devem ser são mostradas todas as classes existentes na ontologia e também
83
os tipos de dados permitidos pela TRC. Nas referências marcadas com + devem ser
disponibilizadas todas as propriedades já definidas na ontologia para a classe especificada na
sentença. Nas referências marcadas com & o editor deverá disponibilizar todas as
propriedades já definidas na ontologia, mas que ainda não tiveram seu domínio especificado.
Somente as referências que estão sublinhadas serão realmente escritas pelo usuário, pois se
tratam da definição de elementos da ontologia. O elemento definido somente ficará disponível
para uma possível escolha do usuário, nos menus pop-up das templates, depois que a sentença
que o definiu for processada.
É interessante ressaltar a semelhança sintática entre as templates do tipo “1b”
“Class1 is a Class2.”
e
as
templates
“Property&|Instance (is|are) Class|Type.”
do
depois
tipo
que
estas
“13”
forem
instanciadas. A instanciação da template “1b” — definição de uma classe — poderia ser, por
exemplo: “A car is a automobile.” e a instanciação da template “13” poderia ser, por exemplo,
a definição dos valores possíveis para uma propriedade já definida: “The maker is winery”, ou
a definição da instância de uma classe predefinida: “C1 is a car”. Mas, de qualquer forma, a
parte fixa da template é muito semelhante. Neste caso, a diferenciação entre uma sentença e
outra é feita basicamente pelo passo do processo, ou seja, se o usuário estiver na fase de
definição de classes, o processo permitirá que ele utilize a template “1b”. Se o usuário estiver
na fase de definição de propriedades ou tipo para as propriedades, o processo permitirá que
ele utilize a template “13” porém ele somente poderá instânciá-la com propriedades (na
primeira referência) e classes ou tipos (na segunda referência). Se o usuário estiver na fase de
definição de instâncias, o processo permitirá que ele utilize templates do tipo “13”, porém ele
somente poderá instânciá-la com o nome da instância (na primeira referência) e das classes
(na segunda referência).
84
Existe uma outra forma de fazer a diferenciação entre uma sentença e outra, sem fazer
uso do passo do processo. As templates do tipo “13”, instanciadas com a primeira referência
contendo o determinante anafórico “the”, são fáceis de serem identificadas pois o uso do
artigo definido “the” permite ao editor inferir que a sentença referencia uma entidade que já
existe na ontologia, e, portanto, esta definindo a faixa de valores permitidos para uma
propriedade já existente na ontologia. Para diferenciar os outros dois propósitos (definir uma
classe ou definir a instância de uma classe), podemos utilizar uma abordagem chamada de
avaliação tardia (late evaluation). Desta forma, ao processar uma sentença que pode ter
vários propósitos, o editor pode guardar informações sobre ela e esperar mais informações
sobre elementos da sentença para então, processá-la. Por exemplo, se tivéssemos a sentença
“A car is a automobile”, o editor poderia guardar as informações sobre a sentença, esperando
pela definição de mais algum detalhe sobre “a car” como, por exemplo, a definição de uma
propriedade ou a definição de uma subclasse. Quando alguma definição deste tipo acontecer,
o editor pode processar a sentença anterior como a definição de uma classe. Caso contrário, se
nenhuma destas definições acontecerem até a fase de checagem de consistência, o editor pode
concluir que se trata da definição de uma instância de uma classe. Com esta abordagem
poderíamos até mesmo abolir as restrições de ordem dos passos que o processo necessita
como, por exemplo, exigir sempre que uma propriedade seja definida previamente ou
juntamente com a classe à qual a propriedade pertence.
Como um exemplo de uso das templates, vamos supor que o usuário queira definir um
tipo para uma propriedade previamente definida na ontologia de vinhos. Então ele utilizará a
template “13”:
Property& | Instance (is | are) Class | Type#.
85
No momento que o usuário escolhe uma template as referências serão transformadas
em menus pop-up, um para a escolha do determinante e um para a escolha do substantivo
correspondente aos elementos da ontologia. Como esta template tem dois propósitos
diferentes, e, portanto, duas opções na primeira referência (Property | Instance), o usuário terá
que escolher uma delas antes do editor disponibilizar os menus pop-up. Como nosso propósito
é definir um tipo para uma propriedade, então escolhemos a opção “Property”. Desta forma, o
elemento “Property | Instance” será transformado em dois menus: um com os determinantes
permitidos para a linguagem e outro com todas as propriedades definidas na ontologia. O
cursor será deslocado automaticamente para o campo do determinante, como mostra a Figura
16 abaixo. Se a intenção do usuário fosse definir uma instância para uma classe, então um
campo de edição normal seria disponibilizado para que o usuário digitasse o nome da
instância que ele estivesse definindo.
Figura 16: Os menus pop-up disponíveis para a definição de um valor para uma propriedade.
Assim que o usuário escolher um dos determinantes, o editor habilitará o menu das
propriedades e seleciona todas as propriedades que já foram definidas na ontologia, mas ainda
não tiveram seu tipo especificado, como mostra a Figura 17 abaixo:
Figura 17: A escolha de uma propriedade para a definição de seu tipo.
86
Assim que o usuário escolher uma das propriedades, os elementos correspondentes a
“Class | Type” serão habilitados e o cursor será automaticamente deslocado para o
determinante desta referência. O substantivo esperado nesta referência é o nome de uma
classe previamente definida na ontologia, ou o nome de um datatype permitido na TRC e, por
isso, o editor já os seleciona para o usuário, como mostra a Figura 18 abaixo:
Figura 18: A escolha de um tipo para a propriedade.
Após todos os elementos terem sido preenchidos, a sentença é aceita pelo editor como
parte da definição da ontologia:
The maker is a winery.
Esta forma de ativar um elemento da interface de acordo com a sentença, guiando o
especialista, é controlada por um processo de construção da ontologia que, além disso,
também sinaliza ao usuário quais tarefas ele já realizou e o que deve ser feito em seguida.
Para isso, foi definido um processo de construção de ontologias, que guiará o usuário durante
seu trabalho com o editor. Para a implementação do processo de construção de ontologias
utilizamos uma adaptação da máquina de estados implementada por Oliveira [2004]. A Figura
19, na página seguinte, mostra o processo global de construção de ontologias utilizando o
editor proposto. Os estados sombreados apresentam subprocessos e serão descritos a seguir.
87
O estabelecimento de uma ordem para a definição da ontologia permite auxiliar o
usuário de forma que este cometa menos erros durante a definição da ontologia. Ao invés de
deixamos que o usuário escreva qualquer coisa para preencher as templates, o processo
permite que o usuário utilize apenas classes, propriedades e valores que já foram definidos na
ontologia14. Desta forma, o usuário não corre o risco de utilizar uma classe, propriedade ou
um valor durante a construção da ontologia e esquecer de defini-los, o que ocasionaria um
erro de consistência, que somente seria detectado durante a fase de checagem de consistência
ao final da especificação. Um outro ponto importante é que a carga cognitiva de escolher uma
das templates sugeridas provavelmente deve diminuir, uma vez que o editor utiliza o processo
para restringir as templates que podem ser utilizadas em cada etapa (subprocesso).
O processo apresentado na Figura 19 tenta mostrar ao usuário como o processo geral
de construção da ontologia foi modelado. A priori, as atividades (subprocessos) podem ser
realizadas em qualquer ordem, bastando, para isso, que as pré-condições de cada atividade
sejam válidas. Algumas pré-condições são apresentadas a seguir:
•
Para definir uma classe baseada em uma outra classe, a segunda deve ser
previamente definida;
•
Para definir uma propriedade a classe que terá esta propriedade precisa ser definida
previamente ou juntamente com a propriedade;
•
Para definir um tipo, ou valores enumerados para uma propriedade, é necessário
que a propriedade seja definida anteriormente;
•
Para definir um valor default para uma propriedade é necessário que o tipo ou os
valores possíveis para propriedade sejam definidos anteriormente;
14
Esta restrição de utilizar somente os elementos já definidos na ontologia pode ser relaxada se utilizarmos
avaliação tardia. Esta é uma abordagem que devemos investigar no futuro, pois, provavelmente, existe um
balanceamento entre utilizar somente os elementos já definidos na ontologia e a carga cognitiva exigida do
usuário para definir a ontologia sem se esquecer de definir nenhum elemento utilizado nela.
88
•
Para definir um valor para uma propriedade de uma instância é necessário que a
instância já tenha sido definida e, para definir uma instância de uma classe é
necessário que a classe já tenha sido definida.
Figura 19: O processo global de construção de uma ontologia utilizando o editor
Como pode ser visto na figura acima, em qualquer parte do processo de construção da
ontologia o usuário poderá verificar a consistência da ontologia que está criando.
A Figura 20, na página seguinte, destaca o subprocesso 1 que permite definir novas
classes para a ontologia das seguintes formas: A) por meio de uma hierarquia de classes
(utilizando templates do tipo 1) e, opcionalmente, também definir o nome de uma propriedade
89
que esta classe contém (utilizando templates do tipo 2); B) por meio da definição de uma
classe que é parte de uma classe todo (utilizando templates do tipo 3); C) por meio de uma
restrição de valor (utilizando templates dos tipos 4, 5 e 6) ou cardinalidade (utilizando
templates dos tipos 7, 8 e 9) de uma propriedade; D) por meio da enumeração de seus
indivíduos (utilizando templates do tipo 10); e E) por meio da igualdade de classes já
definidas (utilizando templates do tipo 11). As templates utilizadas estão destacadas abaixo:
1) a) Class1 is a kind of Class2*.
b) Class1 is a Class2*.
2) a) Class1 is a kind of Class2* that has Property.
b) Class1 is a Class2* that has Property.
3) Class1 (is part of | are parts of) Class2*.
4) Class1 (has | have) at least one Property that must be Class2*.
5) a) Class1 Property must be Class2*.
b) Property Class1 are Class2*.
6) Property of Class1 must be Class2.
7) Class1 must have exactly number Property.
8) Class1 must have at least number Property.
9) Class1 must have at most number Property.
10) Class1 can only be Instances.
11) Class1 is also known as Class2*+.
90
Figura 20: O subprocesso 1 do processo de criação de ontologias.
A Figura 21 destaca o subprocesso 2 que permite definir propriedades e associá-las a
uma classe (utilizando templates do tipo 12) e, opcionalmente, definir seu tipo (utilizando
templates do tipo 16) ou enumerar seus valores possíveis (utilizando templates do tipo 15). As
templates utilizadas para o subprocesso 3 são:
12) Class1* (has | have) Property.
15) Class1* has Property, with possible (value | values) Values.
16) Class1* has Property, which is Class | Type#.
91
Figura 21: O subprocesso 2 do processo de criação de ontologias.
A Figura 22 mostra o subprocesso 3 que permite definir um tipo para uma propriedade
já definida na ontologia, utilizando templates do tipo 13:
13) Property& | Instance (is | are) Class | Type#.
Figura 22: O subprocesso 3 do processo de construção de ontologias.
92
A Figura 23 mostra o subprocesso 4 que permite enumerar os valores que uma
propriedade pode assumir, utilizando templates do tipo 14:
14) Property & has possible values Values.
Figura 23: O subprocesso 4 do processo de construção de ontologias.
A Figura 24 apresenta o subprocesso 5 que permite a definição de valores default para
uma propriedade que já teve seu tipo, ou a enumeração dos valores possíveis, definido(s).
Para isso, são utilizadas templates do tipo 17:
17) Property has default value Value.
Figura 24: O subprocesso 5 do processo de construção de ontologias.
93
A Figura 25 mostra o subprocesso 6 que permite definir instâncias de uma classe
previamente definida na ontologia, utilizando templates do tipo 13:
13) Property& | Instance (is | are) Class | Type#.
Figura 25: O subprocesso 6 do processo de construção de ontologias.
A Figura 26 mostra o subprocesso 7 que permite definir valores para as propriedades
de uma instância previamente definida na ontologia, utilizando templates do tipo 18:
18) Property + of Instance is Value.
Figura 26: O subprocesso 7 do processo de construção de ontologias.
94
O processo apresentado impõe uma ordem parcial que deverá ser seguida pelo usuário
para a definição de uma ontologia. Alguns dos benefícios esperados para esta abordagem
foram observados no início desta seção como, por exemplo, a pretensão de diminuir os erros
de consistência e a carga cognitiva para o usuário.
Neste capítulo apresentamos uma proposta para a construção de um editor de
ontologias, os mecanismos nele acrescidos para facilitar a interação do usuário com a BC, e o
processo de construção de ontologias proposto. No próximo capítulo discutiremos as
limitações desta abordagem e as diferenças e semelhanças com outras abordagens encontradas
na literatura.
95
Capítulo 6
Conclusão
O
s editores de ontologias que temos conhecimento, em sua maioria, são voltados
para uso do engenheiro de conhecimento, ou de profissionais com alguma
experiência na área de construção de ontologias. Como mostrado por Pérez
[PÉREZ, 2002], eles, geralmente, utilizam a própria tecnologia de representação de
conhecimento (TRC) na qual a ontologia será codificada, além de recursos gráficos
disponibilizados pelo editor, como meio de comunicação entre a ferramenta e seu usuário.
Este tipo de comunicação não é eficiente para o nosso propósito, uma vez que nossa idéia é
permitir que o especialista do domínio consiga utilizar a ferramenta para colocar seu
conhecimento diretamente no sistema e, na maioria das vezes, ele não tem conhecimento
nenhum sobre uma TRC.
Deste modo, pelos motivos já descritos nas seções anteriores, propomos a adoção de
uma linguagem natural controlada como meio de comunicação entre o especialista e a
codificação da ontologia em uma TRC. Visando dar sustentação a este objetivo, no capítulo 3
96
apresentamos uma linguagem de especificação que se baseia em uma LNC; no capítulo 4
discutimos seu mapeamento para uma TRC, a OWL, a qual está sendo adotada como padrão
na Web semântica; e no capítulo 5 apresentamos um editor de ontologias que incorpora estes
recursos e utiliza um processo de construção de ontologias visando auxiliar o especialista na
construção de sua ontologia, conforme havíamos proposto.
Outros trabalhos podem ser encontrados na literatura atual que têm o mesmo objetivo,
ou objetivo semelhante o nosso. Entre eles, alguns merecem ser analisados. O projeto
Attempto [FUCHS, SCHWERTEL e SCHWITTER, 1999], do qual se originou a linguagem ACE,
apresenta uma abordagem semelhante à nossa, fazendo uso de LNC como interface para
representação de conhecimento. O projeto Attempto é um projeto incremental e tem
publicações sobre o uso da LNC a pelo menos dez anos [FUCHS e SCHWITTER, 1995]. A
linguagem ACE, definida em seu âmbito inicialmente para a criação de especificações de
requisitos de software, evoluiu a ponto de ser aplicada também para representação de
conhecimento em geral. Em sua abordagem, o usuário tem a liberdade de digitar as sentenças
que descrevem as especificações, as quais são analisadas pelo processador da linguagem e
mapeadas para as DRSs. Sentenças ambíguas são reportadas para o usuário para que este
possa decidir sobre a semântica de cada uma delas. O usuário também pode acrescentar uma
palavra ou modificar o conteúdo do léxico por meio de uma interface que exige o mínimo de
conhecimento lingüístico. As DRSs geradas a partir das especificações em ACE formam a
base de conhecimento que representam estas especificações. Esta representação pode ser
utilizada para futuras consultas sobre as especificações ou para raciocínio sobre o
conhecimento gerado [FUCHS e SCHWERTEL, 2003].
Originada do projeto Attempto, a proposta de Schwitter [2005] também reside na
utilização de LNC como interface entre o usuário e uma TRC. Nesta abordagem, o usuário
começa digitando o texto e o editor sugere as estruturas sintáticas que devem vir em seguida,
97
mantendo, assim, o aspecto controlado da linguagem. Um processador é chamado toda vez
que uma palavra é digitada. Este processador compõe uma DRS, que representa o discurso
digitado, procura pelas categorias gramaticais seguintes, compõe informações para uma
paráfrase e resolve referências anafóricas definidas dinamicamente. Caso uma palavra não
faça parte do léxico, o usuário tem a opção de estendê-lo por meio de um editor do léxico. O
editor de especificações relaciona as sentenças em LNC com um fragmento de lógica de
primeira ordem, normalmente alguma linguagem baseada em lógica descritiva (como RDF ou
OWL), a qual pode ser utilizada por construtores de modelos e raciocinadores para responder
questões sobre o seu conteúdo.
Apesar da LNC proposta neste trabalho ser limitada em comparação com o projeto
Attempto [FUCHS, SCHWERTEL e SCHWITTER, 1999], podemos, com certa facilidade, ampliar
sua expressividade em trabalhos futuros. Isso será possível por ela ter sido implementada de
forma modular, utilizando o parser proposto por Blackburn e Bos [1999], o qual é um parser
para uma linguagem bem mais expressiva do que a inicialmente considerada neste trabalho. A
priori, as restrições feitas à linguagem proposta neste trabalho se devem, principalmente, a
questão do tempo disponível para a realização do mapeamento para a linguagem OWL, no
entanto, não é descartável a hipótese de que tecnicamente não seja possível identificar
sentenças não ambíguas para alguns dos elementos não mapeados.
Em comparação com o trabalho de Schwitter [2005], o qual constrói as sentenças de
forma semelhante à nossa abordagem, podemos dizer que a expressividade da LNC proposta
por ele é semelhante à nossa. Apesar de ele cobrir alguns construtores da linguagem OWL DL
que não cobrimos como, por exemplo, sentenças que permitem a representação de uma
característica de uma propriedade (e.g., o fato de a propriedade ser transitiva, inversa ou
simétrica), ele não cobre outros construtores que nós cobrimos como, por exemplo, a
representação do quantificador existencial (someValuesFrom), da equivalência de instâncias,
98
da enumeração de membros de uma classe e das restrições de cardinalidade. Além disso,
algumas sentenças propostas por Schwitter não são muito naturais para um usuário leigo
como, por exemplo, a sentença “’ObjectProperty’ as the range ‘class’”, que pode ser
instanciada para “A maker has the range winery”.
Quanto ao problema de extensão do léxico, o editor por nós proposto apresenta
vantagens em relação às propostas acima, pois ele permite a inclusão de substantivos de forma
automática, visto que a declaração de uma nova entidade da ontologia se traduz
automaticamente na inclusão de um novo substantivo no léxico. A inclusão de elementos de
outras classes gramaticais como verbos, adjetivos, etc., não foi considerada neste trabalho por
questões de tempo, mas estes elementos poderão ser tratados de forma semelhante.
É interessante lembrar que o editor de ontologias dirigido por processo proposto
limita, parcialmente, a expressão do usuário, quando da especificação da base de
conhecimento, obrigando-o a seguir uma ordem parcial para definir os elementos da
ontologia. Esta abordagem tem o benefício de evitar que o especialista cometa erros de
consistência muito comuns como, por exemplo, a referenciação de um elemento que ainda
não existe na ontologia. Além disso, os menus pop-up utilizados na área de edição evitam que
o especialista referencie um elemento da ontologia de forma incorreta como, por exemplo,
fazer referência a uma classe ao invés de referenciar uma propriedade — o que ocasionará um
erro na fase de mapeamento da linguagem. A introdução destes menus nas templates ajuda o
especialista a lembrar dos elementos que foram previamente definidos na ontologia,
diminuindo, assim, a carga cognitiva sobre ele. Outro fato interessante é que o uso de
templates possibilita, como efeito secundário, que as sentenças sejam pré-processadas (isto é,
pré-parseadas), eliminando a necessidade de um parser explicito, o qual será substituído por
um agente de software que possa resolver as anáforas e elipses presentes na árvore sintática
do discurso.
99
Existem outras formas de implementação do editor. Uma delas seria permitir que o
usuário digitasse qualquer sentença dentro da linguagem, e completasse as referências com
qualquer elemento que julgasse necessário, estivesse ele definido ou não na ontologia
(utilizando avaliação tardia para o processamento do texto). Desta forma, os erros de
consistência da ontologia como, por exemplo, o uso de elementos desconhecidos (não
presentes na ontologia) somente seriam detectados durante o processo de checagem de
consistência. Além disso, o usuário poderia utilizar nomes de classes nas referências nas quais
são esperados nomes de propriedades, ou nomes de propriedades onde são esperados nomes
de valores, ou qualquer outra confusão deste tipo, que são evitadas com a abordagem que
adotamos. Esta segunda abordagem somente teria interação com a base de conhecimento
durante o processo de checagem de consistência da ontologia e teria que adiar muitas das
avaliações das sentenças, visto que, a permissão de que o usuário defina a ontologia em
qualquer ordem aceita que ele referencie elementos da ontologia que serão definidos após a
sua referenciação.
Uma outra forma de implementação do editor seria combinar as duas abordagens
anteriores e, sem estabelecer uma ordem para que o especialista construa a ontologia, também
sugerir as classes, propriedades e valores que podem ser utilizados para o preenchimento das
templates, mas sem obrigar que estes elementos sejam utilizados. Isto permitiria que o
especialista completasse as sentenças com qualquer referência que desejar mesmo que esta
não referencie um elemento já presente na ontologia. Esta abordagem mantém o auxilio ao
usuário, procurando diminuir os erros mais comuns de coerência que seriam cometidos na
abordagem anterior sem, no entanto, estabelecer uma ordem fixa para o processo de definição
da ontologia. Esta abordagem também necessitaria de avaliação tardia para a sua
implementação.
100
Somente uma avaliação de usabilidade do editor de ontologias poderá identificar o
ponto de balanceamento ideal entre o custo de implementação e o potencial de liberdade de
expressão do usuário que pode ser atingido, esclarecendo qual das abordagens é a mais
interessante.
É importante ressaltar que a proposta de um processo de construção de ontologias,
associado à linguagem de especificação, representa um ganho em relação ao projeto Attempto
e ao trabalho de Schwitter, pois estes não se preocupam em sugerir um processo deste tipo
para guiar o especialista nesta tarefa. Um outro editor de ontologias, chamado DOE
(Differential Ontology Editor) [DOE, 2005], mais voltado para engenheiros de conhecimento,
sugere alguns passos que devem ser seguidos para o processo de especificação de uma
ontologia. No primeiro passo, o usuário deve construir uma taxonomia de conceitos e relações
e depois deve justificar porque cada classe filha é diferente da classe mãe e porque classes do
mesmo nível são diferentes umas das outras. No segundo passo, o usuário pode definir
restrições aos domínios das relações. E no terceiro passo, a ontologia pode ser traduzida para
uma TRC específica. Nosso processo é mais flexível, não obrigando o usuário a definir uma
taxonomia completa para depois definir suas restrições. Se o usuário achar necessário definir
uma subclasse e, em seguida, definir suas propriedades, faixa de valores possíveis para ela e
também suas restrições, ele pode fazer isso. Por outro lado, o editor DOE é voltado para
profissionais acostumados a definir ontologias, enquanto nosso trabalho tem o foco voltado
para o especialista do domínio, que pode não ter experiência no ramo.
Deste modo, nosso trabalho procurou por meio da definição de uma linguagem natural
controlada, de um mapeamento para uma tecnologia de representação de conhecimento e da
proposta de um editor dirigido por processo tornar possível a um especialista de um domínio
construir uma base de conhecimento. Para afirmar que a LNC proposta neste trabalho será
facilmente utilizada e aprendida pelo especialista é necessário que sejam realizados testes de
101
usabilidade tanto da linguagem quanto do conjunto editor-linguagem, os quais serão metas
futuras deste trabalho.
Além disso, se considerarmos a possibilidade de expressar conhecimento
procedimental, uma outra possível aplicação desta linguagem seria como uma linguagem de
extensão em aplicações extensíveis por usuários finais, visto que os usuários destas aplicações
não têm conhecimento de programação. Para isto é necessário ampliar o conjunto de
templates disponíveis aos usuários e definir um mapeamento para uma linguagem de regras. É
interessante observar que este mesmo tipo de linguagem também poderá ser utilizado na
especificação de regras de negócio na Web semântica, tornando este tipo de tarefa acessível
aos usuários leigos.
102
Referências
ADELI, H. Knowledge engineering. New York: Ohio State University: McGraw Hill, 1990.
368 p. ISBN: 0-07-000355-6.
ALLEN, J. Natural language understanding. 2nd. ed. Redwood City: Addison Wesley,
1995. 654 p. ISBN 0-8053-0334-0.
ALMEIDA, M. B. Linguagens utilizadas na construção de ontologias. Disponível
em:<http://www.eci.ufmg.br/mba/p1_2_2.html>. Acesso em: 25 abr. 2005.
ALTWARG, R. Controlled languages: an introduction. Macquarie University, Graduate
Program in Speech and Language Processing. Macquarie, 2000. Disponível em:
<http://www.shlrc.mq.edu.au/masters/students/raltwarg/clwhatisa.htm>. Acesso em:
22 jun. 2004.
ALMQVIST, I.; HEIN, A. S. Defining ScaniaSwedich – a controlled language for truck
maintenance. In: INTERNATIONAL WORKSHOP ON CONTROLLED
LANGUAGE APPLICATIONS, 1., 1996, Proceedings… Leuven, Belgium:
Katholieke Universiteit Leuven, Centre for computational Linguistics, 1996. pp. 159164.
ANTONIOU, G.; VAN HARMELEN, F. A semantic Web primer. Massachusetts:
Massachusetts Institute of Tecnology: MIT Press, 2004. 237 p. ISBN 0-262-01210-3.
ÁVILA, B. C.; MONARD, M. C., SEMARF: um sistema para manipular frames. Ponta
Grossa: UEPG(ITI), Setor de Ciências Agrárias e de Tecnologia, Departamento de
Informática, 1992.
BECHHOFER, S.; et al. OWL Web Ontology Language Reference. 2004. Disponível em:
<http://www.w3.org/TR/owl-ref>. Acesso em: 12 jul. 2004.
BITTENCOURT, G. Inteligência artificial: ferramentas e teorias, 2. ed.; Florianópolis, SC:
Ed. da UFSC, 2001.
BLACKBURN, P.; BOS, J. Representation and inference for natural language: a first course
in computational semantics. [s.l.]:CSLI Publications, 2005. ISBN 1575864959.
BLACKBURN, P.; BOS, J. Computational semantics for natural language: course notes,
Indiana University, jun. 2003. Disponível em:
<www.iccs.informatics.ed.ac.uk/~jbos/comsem/download/nasslli.pdf>. Acesso em: 24
nov. 2004.
BLACKBURN, P.; BOS, J. Representation and inference for natural language: a first course
in computational semantics. Universität dês Saarlandes, Sep. 1999. V.2 – Working
with discourse representation structure. Disponível em:
<http://www.cogsci.ed.ac.uk/~jbos/comsem/book2.html>. Acesso em: 21 jul. 2004.
103
BOEING. Checker for ASD Simplified Technical English Now Available From Boeing.
2005. Disponível em:<www.boeing.com/phantom/sechecker/se.html>. Acesso em: 05
maio 2005.
BORST, W.N. Construction of engineering ontologies for knowledge sharing and reuse.
Thesis.( Phd ) - University of Twente, The Netherlands. 1997. Disponível em:
<http://www.ub.utwente.nl/webdocs/inf/1/t0000004.pdf>. Acesso em: 12 jul. 2005.
BRACHMAN, R. J., et al. Krypton: a functional approach to knowledge representation. IEEE
Computer, v. 16, n. 10, p. 67-73, 1983.
BRACHMAN, R. J. 1979. On the epistemological status of semantic networks. In
ASSOCIATIVE NETWORKS. Representation and use of knowledge by computers.
Findler, N.V: Academic Press, New York, 1979, pp. 3-50.
BRACHMAN, R. J. What’s a concept: structural foundations for semantic networks.
International Journal of Man-Machine Studies, v. 9, p. 127-152, 1977.
BRACHMAN R. J.; NARDI, D. An introduction to description logic. In: BAAD, F. et al.
(Ed.). The description logic handbook: theory, implementation, and applications.
(S.l.): Cambridge University Press, 2003. ISBN0521781760.
BRACHMAN, R. J.; SCHMOLZE J. G. An overview of the KL-ONE knowledge
representation system. Cognitive Science, v. 9, n. 2, p.171-216, 1985.
BRILL, D. Loom reference manual. California: Information Sciences Institute, University of
Southern California, Dec., 1993. Disponível em:
<http://www.isi.edu/isd/LOOM/LOOM-HOME.html>. Acesso em: 25 maio 2005.
BUCHANAN, B. G.; SHORTLIFE, E. H. Rule-based expert systems: the MYCIN
experiments of the stanford heuristic programming project. Massachusetts: AddisonWesley, 1984. 748 p. ISBN: 0201101726.
CERCONE, N.; MCCALLA, G. What is knowledge representation? In: CERCONE, N.;
MCCALLA, G. (Ed).. The Knowledge Frontier: essays in the Representation of
Knowledge, New York: Springer-Verlag, 1987. p. 1-43.
CLANCEY, W. J. The knowledge level reinterpreted: modeling socio-technical system.
International Journal of Intelligent Systems, v. 8, p. 33-49, 1993.
CHAUDHRI V. K. et al. Open knowledge base connectivity 2.0. 1998. Disponível em:
<http://www-ksl-svc.stanford.edu:5915/doc/release/okbc/okbc-spec/okbc-2-0-3.pdf>
Acesso em: 25 maio 2005.
COHEN, W.W. Learnability of restricted logic programs. In: INTERNATIONAL
WORKSHOP ON INDUCTIVE LOGIC PROGRAMMING, 3.,1993. Proceedings…
New Jersey: Muggleton S., 1993. p. 41-72. Disponível em:
<citeseer.ist.psu.edu/article/cohen93learnability.html>. Acesso em 10 jul. 2005.
DA SILVA, S. R. P. Um modelo semiótico para programação por usuários finais. Tese
(Doutorado) - Departamento de Informática, Pontifícia Universidade Católica do Rio
de Janeiro, Rio de Janeiro, maio 2001.
104
DA SILVA, S. R. P.; PINHEIRO, J. M. Um framework para criação de linguagens de
domínio específico, In: SIMPÓSIO BRASILEIRO DE LINGUAGENS DE
PROGRAMAÇÃO, 8., 26-28 maio 2004, Niterói, Rio de Janeiro. Anais... Niterói: [s.
n.], 2004.
DAVIS, R.; SHROBE, H.; SZOLOVITIS, P. What is Knowledge Representation? AI
Magazine, vol 14, nº1, pp. 17-33. 1993. Disponível
em:<http://medg.lcs.mit.edu/ftp/psz/k-rep.html> Acesso em: 25 jul. 2005.
DESCRIPTION LOGICS. Disponível em: <http://dl.kr.org/>. Acesso em: 07 jul. 2004.
DOE. Differential ontology editor. Disponível em: <http://opales.ina.fr/public/>. Acesso em:
21 jun. 2005.
ECO, U. Theory of semiotics. Bloomington: Indiana: University Press. 1976.
FEIGENBAUM, E. A.; BUCHANAN, B. G.; LEDERBERG, J. On generality and problem
solving: A case study using DENDRAL program. In: NELTZER, B; NICHIE, D.
(Ed.). Machine Intelligence. Edinburg: Edinburgh University Press, Scotland, 1971.
p.165-190.
FENSEL, D. et al. OIL: ontology infrastructure to enable the semantic web. IEEE Inteligent
Systems, v. 16, n. 2, p. 38-45, 2001.
FRANCONI, E. Description logic course. Department of Computer Science, University of
Manchester, p.165-190. 2002. Disponível em:
<http://www.cs.man.ac.uk/_franconi/dl/course/2002/>. Acesso em: 02 abr. 2004.
FRANCONI, E. Description logic for natural language processing. In: AAAI FALL
SYMPOSIUM ON KNOWLEDGE REPRESENTATION FOR NATURAL
LANGUAGE PROCESSING IN IMPLEMENTED SYSTEMS, 1994, New Orleans.
Proceedings... New Orleans: [s. n.], 1994.
FUCHS, N. E.; SCHWERTEL U. Reasoning in attempto controlled English. In: F. BRY, F.;
HENZE, N. Henze; MALUSZYNSKI, J. Maluszynski (Ed.). Principles and Practice of
Semantic Web Reasoning: International Workshop PPSWR 2003, Mumbai, India,
Dec. 2003. Lecture Notes in Computer Science 2901, Springer Verlag, 2003.
FUCHS, N. E.; SCHWERTEL, U.; SCHWITTER, R. Attempto controlled english – not just
another logic specification language. In: LNCS 1559. Título, Springer (1999), p. 1–20.
FUCHS, N.E.; SCHWITTER, R.; SCHWERTEL, U. Attempto controlled english
(ACE):Language manual. Zürich: Institut für Informatik der Universität of Zürich,
1999.
FUCHS, N. E.; SCHWITTER, R. Specifying Logic Programs in Controlled Natural
Language. In: WORKSHOP ON COMPUTATIONAL LOGIC FOR NATURAL
LANGUAGE PROCESSING, 1995, University of Edinburgh, Proceedings…
University of Edinburgh: [s.n.], Apr. 1995.
GINSEBERG, M. Essentials of Artificial Intelligence. San Francisco: University of Oregon,
Eugene. Morgan Kaufmann Publishers, 1994. 430 p. ISBN:1-55860-221-6. Disponível
105
em: <http://www.cirl.uoregon.edu/research/kr.html>. Acesso em: 09 mar. 2005.
Computational Intelligence Research Laboratory (CIRL).
GODOI, M. S. Implementação de Uma Interface para o Ambiente de Extensões para
Aplicações Extensíveis. Relatório Técnico. Maringá:Departamento de Informática,
Universidade Estadual de Maringá, Brasil, ago. 2004. 22 p.
GRUBER, TOM. What is an ontology? 1996. Disponível em:
<http://www.ksl.stanford.edu/kst/what-isan-ontology.html>. Acesso em: 15 set. 2004.
GUARINO, N. Formal ontology, conceptual analysis and knowledge representation.
International Journal of human and Computer Studies, v. 43 n. 5/6, 1995. Special
issue.
GUARINO, N.; GIARETTA, P. Ontologies and knowledge bases, towards a terminological
clarification. 1995. Disponível em:
<http://www.ladseb.pd.cnr.it/infor/Ontology/Papers/KBKS95.pdf>. Acesso em: 13 jul.
2005.
HAARSLEV, V. Racer – An Inference Engine for Semantic Web. Concordia: Department of
computer science and software engineering, University of Concordia, 2005.
Disponível em: <http://www.franz.com/products/racer/Racer_presentation.pdf>.
Acesso em: 28 jul. 2005.
HALL, A. Seven myths of formal methods. IEEE Software, v. 48, n. 1, (1990), p. 67–79
HESS, M. Recent developments in discourse representation theory. Switzerland, In:
COMMUNICATION WITH MEN AND MACHINES, 1991, Geneva. Working
Notes… Geneva: M. King, 1991.
HOEFLER, S. The syntax of attempto controlled English: an abstract grammar for ACE 4.0.
Technical report. Zürich: Department of informatics, University of Zurich,
Switzerland, mar. 2004.
HORROCKS, I. et al. Reference description of the DAML+OIL ontology markup
language. Technical Report. Jan. 2001. Disponível em:
<http://www.daml.org/2000/12/reference.html> Acesso em: 12 jun. 2005.
INTERNATIONAL CONTROLLED LANGUAGE APPLICATIONS WORKSHOP, 4., 15 –
17 May. 2003, Dublin, Ireland. Proceedings… Dublin: [s.n.], 2003.
KAMP, H. A theory of truth and semantic representation. In: GROENENDIJK, J. et al. (Ed.).
Formal methods in the study of languages Foris, Amsterdam: Mathematisch Centrum,
1981.
KENT, R.E. Conceptual knowledge markup language: the central core . In: WORKSHOP ON
KNOWLEDGE ACQUISITION, MODELING AND MANAGEMENT, 12., Banff,
1999. Proceedings ... Disponível em:
<http://sern.ucalgary.ca/KSI/KAW/KAW99/papers.html>. Acesso em: 23 maio 2005.
106
KNUMBLAUCH, H. Editing OWL ontologies with protégé. Stanford University, jan. 2004.
Disponível em: <http://protege.stanford.edu/plugins/owl/publications/2004-07-06OWL-Tutorial.ppt> Acesso em: 24 fev. 2005.
LASSILA, O.; SWICK, R. R. Resource description framework (RDF): model and syntax
specification, 22 Feb. 1999. Disponível em: <http://www.w3.org/TR/1999/REC-rdfsyntax-19990222>. Acesso em: 12 jun. 2005.
LIOU, Y. I. Knowledge acquisition: issues, techniques, and methodology. In: of the 1990
ACM SIGBDP: conference on Trends and directions in expert systems. Proceedings…
ACM Press: New York, 1990. p.. 212 – 236. ISBN:0-89791-416-3.
LYONS, J. Language and Linguistics: an introduction. Cambridge, UK: Cambridge
University Press, 1981. ISBN 0521297753.
MCGRAW, K.L.; HARBISON-BRIGGS, K. Knowledge acquisition: principles and
guidelines. Prentice-Hall: NJ, 1989. 376 p. ISBN:0-13-516436-2.
MCGUINESS, D. L.; HARMELEN, F. OWL web ontology language - overview, 2003.
Disponível em:<http:www.w3.org/TR/2003/PR-owl-features-20031215>, Acesso em:
10 jan. 2004.
MINSKY, M.L. A framework to represent knowledge. In: WINSTON, P. J. (Ed.). The
Psychology of Computer Vision. New York: McGraw Hill, 1975. . pp 211-277.
NELKEN, R.; FRANCEZ, N. Translating natural language system specifications into
temporal logical via DRT. Technical report. Laboratory for Computational
Linguistics, Israel Institute of Technology: Computer Science Department, 1996.
NOY, F. N.; McGUINESS, D. L. Ontology development 101: a guide to creating your first
ontology. Stanford Knowledge Systems Laboratory Technical Report KSL-01-05,
Mar. 2001 Disponível em:
<http://protégé.stanford.edu/publications/ontology_development/ontology101-noymcguiness.html>. Acesso em: 23 mar. 2005.
OLIVEIRA, E. M. Integração e Implementação de um Ambiente de Extensão para Aplicações
Extensíveis. 2004. 51 f. Monografia (Graduação em Ciência da Computação) –
Departamento de Informática, Universidade Estadual de Maringá, Maringá, jan. 2004.
ONTOLOGY. Disponível em <http://en.wikipedia.org/wiki/Ontology>. Acesso em: 12 jul.
2005. PARCIA, B; SIRIN, E. Pellet: An OWL DL Reasoner, MINDSWAP Research
Group, Maryland: University of Maryland, 2003. Disponível em:
<http://iswc2004.semanticweb.org/posters/PID-ZWSCSLQK-1090286232.pdf>.
Acesso em: 28 jul. 2005.
PÉREZ, A. G. et al. A survey on ontology tools. OntoWeb. May, 2002. Disponível em:<
http://ontoweb.aifb.uni-karlsruhe.de/About/Deliverables/D13_v1-0.zip>. Acesso em:
23 jun. 2005.
PEIRCE, C.S. Collected papers. Cambridge: Ma. Harvard University Press, 1931. (Excerpted
in BUCHLER, J., ed., Philosophical Writings of Peirce. New York: Dover, 1955).
107
PINHEIRO, J. M. Atualização de bases de conhecimento pelo usuário final. 2003. 63 f.
Monografia (Graduação em Ciência da Computação) – Departamento de Informática,
Universidade Estadual de Maringá, Maringá, 2003.
PULMAN, S.G. Controlled Language and Knowledge Representation. In:
INTERNATIONAL WORKSHOP ON CONTROLLED LANGUAGE
APPLICATIONS, 1., Belgium, Mar. 1996. Proceedings… Belgium: Katholieke
Universiteit Leuven, 1996. p. 233-242.
QUILLIAN, M. R. Semantic memory. In: MINSKY, M.(Ed). Semantic information
processing. Cambrige: M.I.T. Press, 1968. p. 227-270.
QUIRK, R. et al. A grammar of contemporary English. 1st ed. Essex, UK: Longman Group,
1972. ISBN 0 582 52444 x.
RECTOR, A. et al. Ontology design patterns and problems: practical ontology engineering
using Protege-OWL. In: THIRD INTERNATIONAL SEMANTIC WEB
CONFERENCE, (ISWC), 2004. Tutorial. Hiroshima, Japan: Springer-Verlag, 2004.
RECTOR, A. L. et al. The grail concept modeling language for medical terminology.
Artificial Intelligence in Medicine, Kluwer Publishing, v. 9, p. 139-171, 1997.
RUSSEL, S; NORVING, P. Inteligência artificial. 2. ed. Tradução da Ed. Elsevier. Rio de
Janeiro: Ed. Campus, 2004. ISBN 85-352-1177-2.
SATTLER, U. Early Knowledge Representation Formalisms. Lecture Notes, mar. 2005..
Disponível em: <www.cs.man.ac.uk/~sattler/teaching/Section1+2.pdf> Acesso em: 20
maio 2005.
SCHWITTER R. Controlled natural language as interface language to the semantic web.
Sydney, Australia: Centre for Language Technology Macquarie Universit, 2005.
SCHWITTER, R.; TILBROOK, M. Controlled Natural Language meets the Semantic Web.
In: ASUDEH, A. C.; PARIS, S. Wan (Ed.). Proceedings of the Australasian Language
Technology Workshop. 8th. Macquarie University, December 2004, pp. 55-62, 2004.
SCHWITTER, R. Representing knowledge in controlled natural language: a case study. In:
NEGOITA, M. G.; HOWLETT, R. J.; JAIN, L. C. (Ed.). Knowledge-based intelligent
information and engineering systems. INTERNATIONAL CONFERENCE, KES, 8.,
2004, Wellington. Proceedings… Wellington, New Zealand, p. 711-717, Sep. 2004,
Part I, Springer LNAI 3213.
SCHWITTER, R.; LJUNGBERG, A.; HOOD, D. ECOLE: a look-ahead editor for a
controlled language. Proceedings of EAMT-CLAW03, controlled language
translation, Dublin City University, p. 141–150, May 15-17, 2003.
SEE, D. C; SLACKS , N.; STANLEY, C.; TECLLAB , M.; TOBUN , A.; WILLIAMS, N.
Questions on Knowledge Acquisition. Computing course at South Bank University,
1997. Disponível em: <http://www.scism.sbu.ac.uk/inmandw/tutorials/kaqu/g1.htm>
Acesso em: 15 jan. 2005.
108
SOWA, J. F. Knowledge representation: logical, philosophical and computational
foundations. Pacific Grove, California: Brooks Cole Publishing Co., 1999. 512 p.
ISBN 0534949657.
STEFIK, M. Introduction to knowledge systems. San Francisco, Califórnia: Morgan
Kaufmann Publishers, 1995. ISBN 1-55860-166-X.
TURBAN, E.; FRENZEL, J. L. E. Expert systems and applied artificial intelligence.
Englewood Cliffs, NJ: Prentice Hall, 1992. ISBN 0024216658.
WATERMAN, D. A. A guide to expert systems. Boston, MA: Addison-Wesley Longman
Publishing, 1986.
WEB ONTOLOGY LANGUAGE. Disponível em: <http://www.w3.org/2004/OWL/>.
Acesso em: 12 fev. 2004.
WOODS, A. W. Knowledge Representation: What’s Important About It? In: CERCONE, N.;
MCCALLA, G. (Ed.). The knowledge Frontier: Essays in the representation of
knowledge. New York: Springer-Verlag, 1987.
WOODS, A. W. What’s a link? Foundations for semantic networks. Ed. Bobrow, D. G., &
Collins, A. M. Representations and Understanding: Studies in cognitive Science. New
York: Academic Press, 1975. p. 35-82.
109
ANEXO I
Algoritmo de mapeamento de DRS para OWL
Observações importantes para o entendimento do algoritmo:
1) Variáveis estão destacadas no estilo VARIÁVEL
2) UNIFY é um procedimento que unifica uma condição com algum elemento de uma
lista de condições. Por exemplo: se quisermos saber se existe uma condição com o
argumento A na lista de condições, chamamos UNIFY(CON, A, COND). Se existir uma
condição como, por exemplo, wine(A), a variável CON será instanciada com wine. Se
quisermos saber se existe uma condição isa(A, B), chamamos UNIFY(isa, [A, B],
COND). Se não conseguir unificar devolve false, se conseguir, devolve true;
3) A entrada do algoritmo será uma drs da forma drs([R],[COND]), onde R é uma lista de
referentes do discurso e COND é uma lista de condições sobre estes referentes.
Exemplo: Na drs([A, B], [wine(A), drink(B), ako(A, B)]), A e B são elementos que o
discurso referencia e wine(A), drink(B) e ako(A, B) são condições para os referentes A
e B.
4) Todas as chamadas de funções estão em letras MAIÚSCULAS e as funções estão
descritas no fim do algoritmo.
Input: drs([R],[COND]), onde R é uma lista de referentes do discurso e COND é uma lista de
condições sobre estes referentes.
Output: TOWL, uma representação em OWL da DRS de entrada ou erro.
Variáveis globais:
LCLASS: um conjunto das classes definidas na ontologia;
LNOTDEF: um conjunto das propriedades que foram definidas nas sentenças mas aguardam a
definição da faixa para serem definidas na ontologia;
LVALUES: um conjunto de valores enumerados para uma propriedade;
LISNT: um conjunto das instâncias definidas na ontologia;
/************ Sentenças cobertas no próximo trecho do algoritmo**************
1 - A wine is a drink.
drs([A, B], [wine(A), drink(B), ako(A, B)])
2 - A wine is a drink that has a color.
drs([A, B, C], [wine(A), color(C), has(A, C), drink(B), ako(A, B)])
********************************************************************/
Case UNIFY(ako,[A, B],COND) then
UNIFY(SUB, [A], COND); {onde SUB é a subclasse que está sendo definida}
UNIFY(CLASS, [B], COND); {onde CLASS é a classe mãe de SUB}
if CLASS ∉ LCLASS
then return error(‘The Class ’,CLASS,’ is not defined’);
else if SUB ∈ LCLASS
then return error(‘The class ‘,SUB,’ has been already defined’);
else begin
DEFINE_CLASS(CLASS, SUB, LCLASS, TOWL);
LCLASS <= LCLASS + SUB;
end;
110
if UNIFY(has, [A, C], COND)
then begin
UNIFY(PROPER, [C],COND); {PROPER é a propriedade que está sendo definida}
LNOTDEF <= LNOTDEF + prop(SUB, PROPER);
end;
return TOWL;
/************ Sentenças cobertas no próximo trecho do algoritmo**************
3 - A motor is part of an automobile.
drs([A, B],[motor(A), automobile(B), partof(A,B)])}
********************************************************************/
Case UNIFY(part of, [A, B],COND) then
UNIFY(PART(A) ∈ COND; {PART é a parte que está sendo definida para a classe}
if PART ∈ LCLASS
then return error(‘The class ‘,PART,’ has been already defined’);
UNIFY(CLASS, [B], COND); {CLASS é a classe para qual a PART está sendo definida}
if CLASS ∈ LCLASS
then begin
SUPERCLASS <= CONSULT_SUPER_CLASS(BC, CLASS);
RETIRE_DEFINITION(BC, CLASS);
DEFINE_PARTOF(SUPERCLASS, CLASS, PART, TOWL);
end;
else return error(‘The Class ’,CLASS,’ is not defined’);
return TOWL;
/************ Sentenças cobertas no próximo trecho do algoritmo**************
4a – A wine has at least one maker that must be a winery.
drs([A, B, C],
[wine(A), winery(C), mustbe(B, C), maker(B), has(A, B), atleast(B,1)])
********************************************************************/
Case (UNIFY(atleast, [B,1], COND )) and (UNIFY(mustbe, [B,C], COND )) then
UNIFY(PROPER, [B], COND); {PROPER é a propriedade para a qual está sendo definida a
restrição}
UNIFY(RANGE, [C], COND); {RANGE é faixa de valores de PROPER}
UNIFY(CLASS, [A], COND); {CLASS é a classe domínio de PROPER}
if CLASS ∈ LCLASS
then return error(‘The class ‘,CLASS,’ has been already defined’);
if RANGE ∉ LCLASS
then return error(‘The class ‘,RANGE,’ is not defined);
DEFINE_RESTRICTION(CLASS, PROPER, RANGE, ‘someValuesFrom’, TOWL);
DEFINE_OBJECTPROPERTY(PROPER, CLASS, RANGE, TOWL);
return TOWL;
/************ Sentenças cobertas no próximo trecho do algoritmo**************
4b – All wine has at least one maker that must be a winery.
drs([],[imp(
drs([A],[wine(A)]),
drs([B, C],[maker(B), winery(C), mustbe(B,C), has(A,B),
atleast(B,1)])
111
)])
5a - All the wine makers must be wineries.
5b - All the wine makers must be wineries.
drs([],
[imp(
drs([A, B], [wine(B), of(A, B), maker(A)]),
drs([C], [winery(C), mustbe(A, C)])
)])
********************************************************************/
case UNIFY(imp, [DRS1, DRS2] COND) then
case (UNIFY(drs, [[RA], [CONDA]], DRS1)) and (UNIFY(drs, [[RC], [CONDC]], DRS2)) then
case (UNIFY(atleast, [B,1], CONDC)) and (UNIFY(mustbe, [B,C], CONDC )) then {4B}
UNIFY(PROPER, [B], CONDC); {PROPER é a propriedade para a qual está sendo definida a
restrição}
UNIFY(RANGE, [C],CONDC);RANGE é faixa de valores de PROPER}
UNIFY(CLASS, [A], CONDA); {CLASS é a classe domínio de PROPER}
if RANGE ∉ LCLASS
then return error(‘The class ‘,RANGE,’ is not defined);
DEFINE_RESTRICTION(CLASS, PROPER, RANGE, ‘someValuesFrom’, TOWL);
DEFINE_OBJECTPROPERTY(PROPER, CLASS, RANGE, TOWL);
return TOWL;
case UNIFY(mustbe, [A,C], CONDC) then {5A e 5B}
UNIFY(PROPER, [A], CONDA); {PROPER é a propriedade para a qual está sendo definida a
restrição}
UNIFY(RANGE, [C], CONDC); {RANGE é faixa de valores de PROPER}
UNIFY(CLASS, [B], CONDA); {CLASS é a classe domínio de PROPER}
if RANGE ∉ LCLASS
then return error(‘The class ‘,RANGE,’ is not defined);
DEFINE_RESTRICTION(CLASS, PROPER, RANGE, ‘allValuesFrom’, TOWL);
DEFINE_OBJECTPROPERTY(PROPER, CLASS, RANGE, TOWL);
return TOWL;
/************ Sentenças cobertas no próximo trecho do algoritmo**************
6- The color of a redWine must be red.
drs([A, B, C], [color(A), redwine(B), of(A, B), red(C), mustbe(A, C)])
********************************************************************/
Case UNIFY(mustbe, [A,C] COND) then {6}
UNIFY(PROPER, [A], COND); {PROPER é a propriedade para a qual está sendo definida a
restrição}
UNIFY(VALUE, [C], COND){VALUE é o valor que PROPER deverá ter}
UNIFY(CLASS, [B], COND); {CLASS é a classe domínio de PROPER}
DEFINE_RESTRICTION(CLASS, PROPER, RANGE, ‘hasValue’, TOWL);
LNOTDEF <= LNOTDEF + prop(CLASS, PROPER);
return TOWL;
/************ Sentenças cobertas no próximo trecho do algoritmo**************
7 - A wine must have exactly one maker.
drs([A, B], [wine(A), maker(B), musthave(A, B), exactly(1, B)])
8 - A wine must have at least one grape.
drs([A, B], [wine(A), grape(B), musthave(A, B), atleast(1, B)])
9 - A wine must have at most one grape.
112
drs([A, B], [wine(A), grape(B), musthave(A, B), atmost(1, B)])
********************************************************************/
Case UNIFY(musthave, [A,B], COND) then {7, 8, 9}
UNIFY(PROPER, [B], COND); {PROPER é a propriedade para a qual está sendo definida a
restrição}
UNIFY(CLASS, [A], COND); {CLASS é a classe domínio de PROPER}
if CLASS ∈ LCLASS
then return error(‘The class ‘,CLASS,’ has been already defined’);
UNIFY(CARD, [NUMBER, B], COND){VALUE é o valor que PROPER deverá ter}
DEFINE_CARDINALITY(CLASS, PROPER, CARD, NUMBER, TOWL);
LNOTDEF <= LNOTDEF + prop(CLASS, PROPER);
return TOWL;
/************ Sentenças cobertas no próximo trecho do algoritmo**************
10 – A wine can only be a redwine, a rosewine or a whitewine.
drs([A, B, C, D], [wine(A), redwine(B), rosewine(C), whitewine(C), canbe(A, B),
canbe(A, C), canbe(A, D)])
********************************************************************/
Case UNIFY(canbe, [A, C], COND) then
UNIFY(CLASS, [A], COND); {CLASS é a classe enumerada que está sendo definida}
if CLASS ∈ LCLASS
then return error(‘The class ‘,CLASS,’ has been already defined’);
for all UNIFY(canbe, [A, Y], COND) do
begin
UNIFY(X, [Y], COND);
LVALUES <= LVALUES + X;
end;
NAMECLASS <= CONCATENA(CLASS, PROPER);
ENUMCLASS <= DEFINE_ENUMERATEDCLASS(NAMECLASS, LVALUES, TOWL);
return TOWL;
/************ Sentenças cobertas no próximo trecho do algoritmo**************
11 – A car is also known as automobile.
drs([A, B], [car(A), automobile(B), isequal(A, B)])
********************************************************************/
Case UNIFY(isequal,[A, B],COND) then
UNIFY(DEF, [A], COND); {onde DEF é a classe que está sendo definida}
UNIFY(EQUAL, [B], COND); {onde EQUAL é a classe que já existe}
case EQUAL ∈ LCLASS
then if DEF ∈ LCLASS
then return error(‘The class ‘,DEF,’ has been already defined’);
else begin
DEFINE_CLASS_EQUAL(EQUAL, DEF, LCLASS, TOWL);
LCLASS <= LCLASS + CLASS;
end;
case EQUAL ∈ LINST
then if DEF ∈ LINST
then return error(‘The instance ‘,DEF,’ has been already defined’);
else begin
113
DEFINE_INST_EQUAL(EQUAL, DEF, LINST, TOWL);
LINST <= LINST + instance(EQUAL, INST);
end;
case CONSULT_PROPER (EQUAL, BC)
then if CONSULT_PROPER (DEF, BC)
then return error(‘The proper ‘,DEF,’ has been already defined’);
else begin
DEFINE_PROPER_EQUAL(EQUAL, DEF, TOWL);
end;
return TOWL;
/* Sentença 12 será o último case porque várias outras sentenças tem has(A,B).
se não casar com as sentenças 4, 14, 15, 16 e 17 , então será a sentença 4 */
/************ Sentenças cobertas no próximo trecho do algoritmo**************
13a – The maker is a winery.
drs([A, B], [maker(A), winery(B), range(A, B)])
16 – A wine has a grape, which is a wineGrape.
drs([A, B, C], [wine(A), grape(B), has(A, B), winegrape(C), range(B, C)])
********************************************************************/
Case UNIFY(range, [A, B], COND) then
UNIFY(range, [A, B], COND)
UNIFY(PROPER, [A], COND); {PROPER é a propriedade que está sendo definida}
UNIFY(RANGE, [B], COND); { RANGE é a faixa que está sendo definida para PROPER }
if has(C,A) ∈ COND {sent 13a}
then begin
if not UNIFY(prop, [CLASSDOM, PROPER], LNOTDEF)
then return error(‘The property ’, PROPER,’ is not defined’);
LNOTDEF <= LNOTDEF - prop(CLASSDOM, PROPER);
end;
else begin {sent 16}
UNIFY(CLASSDOM, [C], COND);
if CLASSDOM ∉ LCLASS
then return error(‘The class ’, CLASS,’ is not defined’);
end;
if RANGE for um datatype
then DEFINE_DATATYPEPROPERTY(PROPER, CLASSDOM, RANGE, TOWL);
else if RANGE ∈ LCLASS
then DEFINE_OBJECTPROPERTY(PROPER, CLASSDOM, RANGE, TOWL);
else error(‘The range ’, RANGE,’ is not valid’);
return TOWL;
/************ Sentenças cobertas no próximo trecho do algoritmo**************
13b – w1 is a winery.
drs([A, B], [eq(A,w1), wine(B), isa(A, B)])
********************************************************************/
Case UNIFY(eq, [A, INST], COND) then
UNIFY(CLASS, [B],COND); {CLASS é a classe para qual a instância Inst está sendo definida}
if CLASS ∈ LCLASS
114
then return error(‘The class ’,CLASS,’ not defined’);
DEFINE_INTANCE(CLASS, INST, TOWL);
LINST <= LINST + instance(CLASS ,INST);
return TOWL;
/************ Sentenças cobertas no próximo trecho do algoritmo**************
14 – The color has possible values red, white and rose.
drs([A, B], [color(A), possibleValues(A, B), red(B), white(B), rose(B)])
15 – A wine has a color with possible values red, white and rose.
drs([A, B, C],
[wine(A), body(B), has(A, B), possibleValues(B, C), full(C), medium(C), light(C)])
********************************************************************/
Case UNIFY(possibleValues, [B,C], COND) then
UNIFY(PROPER, [B], COND); { PROPER é a propriedade para a qual a faixa está sendo
definida}
for all UNIFY(X, [C], COND) do
LVALUES <= LVALUES + X;
if not UNIFY(prop, [CLASSDOM, PROPER], LNOTDEF)
then
begin
UNIFY(has, [A, B], COND);
UNIFY(CLASSDOM, [A] COND);
if CLASSDOM ∉ LCLASS
then return error(‘The class ’, CLASS,’ is not defined’);
end;
else LNOTDEF <= LNOTDEF - prop(CLASSDOM, PROPER); {Se pertence a LnotDef, a classe
existe}
ENUMCLASS <= DEFINE_ENUMERATEDCLASS(CLASSDOM, PROPER, LVALUES, TOWL);
DEFINE_OBJECTPROPERTY(PROPER, CLASSDOM, ENUMCLASS, TOWL);
return TOWL;
/************ Sentenças cobertas no próximo trecho do algoritmo**************
17- The color has default value rose.
drs([A, B], [color(A), defaultValue(A, B), rose(B)])
********************************************************************/
Case UNIFY(defaultValue, [A, B], COND) then
UNIFY(PROPER, [A], COND);{PROPER é a propriedade para a qual está sendo definido o
valor default}
UNIFY(VALUE, [B], COND); {VALUE é o valor default para PROPER}
CONSULT_PROPERTY_TYPE(BC, PROPER, TYPEPROPER);
ALLOWEDVALUE <= CONSULT_PROPERTY_VALUE(BC, PROPER, VALUE);
If not ALLOWEDVALUE { VALUE não é um valor permitido}
then return error(VALUE, ‘is an invalid value to ’, PROPER)
DEFINE_DEFAULTVALUE(PROPER, TYPEPROPER, VALUE, TOWL);
return TOWL;
/************ Sentenças cobertas no próximo trecho do algoritmo**************
115
12 - A wine has a color.
drs([A, B], [wine(A), color(B), has(A,B)])
********************************************************************/
Case UNIFY(has, [A,B], COND) then
UNIFY(PROPER, [B], COND); {PROPER é a propriedade que está sendo definida}
UNIFY(CLASS, [A, COND); {CLASS é a classe domínio de PROPER}
if CLASS ∉ LCLASS then
return error(‘The Class ’,CLASS,’ not defined’)
LNOTDEF <= LNOTDEF + prop(CLASS, PROPER);
return TOWL;
/************ Sentenças cobertas no próximo trecho do algoritmo**************
18 – The color of wine 1 is rosé.
drs([A, B, C], [wine1(B), color(A), of (A, B), rose(C), value(A, C)])
********************************************************************/
Case UNIFY(of, [A, B], COND) and UNIFY(value, [A, C], COND) then
UNIFY(PROPER, [A], COND); {PROPER é a propriedade que está sendo definido o valor}
UNIFY(INST, [B], COND); {INST é a instância que está sendo definido o valor}
UNIFY(VALUE, [C], COND);
if instance(CLASS ,INST) ∉ LINST then
return error(‘The instance ’,INST,’ not defined’)
ALLOWEDVALUE <= CONSULT_PROPERTY_VALUE(BC, PROPER, VALUE);
if not ALLOWEDVALUE then
return error(‘The value ’,VALUE,’ is not valid to proper ‘,PROPER)
DEFINE_INSTANCE_VALUE(CLASS, INST, PROPER, VALUE, TOWL)
return TOWL;
/****************
Descrição das Funções utilizadas *******************/
INST(REL, ARGS, LIST) {onde REL, ARGS e LIST são variáveis em Prolog}
begin
if existe uma condição C ∈ LIST que tem ARGS como argumentos
then
begin
Compõe C em RELACAO e ARGUMENTOS; {em Prolog (C =.. [RELAÇÃO |
ARGUMENTOS ].)}
REL <= RELACAO;
return true;
end;
else return false;
end;
DEFINE_CLASS(CLASS: Class, SUB: Class, LCLASS: SetClass, var TOWL: Text);
begin
TOWL <= TOWL + <owl:Class rdf:ID=”SUB”>
<rdfs:subclassof rdf:resourse=”#CLASS”/>
for all X ∈ LCLASS do
TOWL <= TOWL + <owl:disjointWith
rdf:resourse=”#X”/>
116
TOWL <= TOWL + </owl:class>
end;
DEFINE_PARTOF(SUPERCLASS: Class, CLASS: Class, PART: Class, TOWL: Text);
begin
CLASS_PARTOF_CLASS <= CONCATENA(CLASS, ‘_or_part of_’, CLASS);
PART OF_CLASS <= CONCATENA(‘Partof_’, CLASS);
DEFINE_CLASS(SUPERCLASS, CLASS_PARTOF_CLASS, LCLASS, TOWL);
DEFINE_CLASS(CLASS_PARTOF_CLASS, CLASS, LCLASS, TOWL);
DEFINE_CLASS(CLASS_PARTOF_CLASS, PARTOF_CLASS, LCLASS, TOWL);
DEFINE_CLASS(PARTOF_CLASS, PART, LCLASS, TOWL);
end;
DEFINE_CLASS_EQUAL(EQUAL, DEF, LCLASS, TOWL);
begin
TOWL <= TOWL + <owl:Class rdf:about="#DEF ">
<equivalentClass rdf:resource="#EQUAL "/>
for all X ∈ LCLASS do
TOWL <= TOWL + <owl:disjointWith rdf:resourse=”#X”/>
TOWL <= TOWL + </owl:Class>
end.
DEFINE_INST_EQUAL(EQUAL, DEF, LINST, TOWL);
begin
TOWL <= TOWL + <rdf:Description rdf:about="#DEF ">
<owl:sameAs rdf:resource="#EQUAL "/>
TOWL <= TOWL + </rdf:Description>
TOWL <= TOWL + <owl:AllDifferent>
<owl:distinctMembers rdf:parseType="Collection">
for all X ∈ LINST do
TOWL <= TOWL +
<CLASS rdf:about="#INSTX"/>
TOWL <= TOWL +
</owl:distinctMembers>
</owl:AllDifferent>
end.
DEFINE_PROPER_EQUAL(EQUAL, DEF, TOWL);
begin
TOWL <= TOWL + <owl:Property rdf:about="#hasManufacturer">
<equivalentProperty rdf:resource="#hasMaker"/>
</owl:Property>
end.
DEFINE_INTANCE(CLASS: Class, INST: Text, var TOWL: Text)
begin
TOWL <= TOWL + <Class rdf:ID=”INST”/>
<owl:AllDifferent>
<owl:distinctMembers rdf:parseType="Collection">
for all X ∈ LINST do
TOWL <= TOWL +
<CLASS rdf:about="#INSTX"/>
TOWL <= TOWL +
</owl:distinctMembers>
</owl:AllDifferent>
end;
117
DEFINE_OBJECTPROPERTY(PROPER: Property, CLASSDOM: Class, RANGE: Class, var
TOWL: Text);
begin
NAMEPROPER <= CONCATENA(‘has’, PROPER);
TOWL <= TOWL + <owl:ObjectProperty rdf:ID=”NAMEPROPER”>
<rdfs:domain rdf:resource=”#CLASSDOM”>
<rdfs:range rdf:resource=”#RANGE”>
</owl:ObjectProperty>
end;
DEFINE_DATATYPEPROPERTY(PROPER: Proprety, CLASSDOM: Class, RANGE: Datatype,
var TOWL: Text);
begin
NAMEPROPER <= CONCATENA(‘has’, PROPER);
NAMERANGE <= CONCATENA(‘&xsd;’, RANGE);
TOWL <= TOWL + <owl:DatatypeProperty rdf:ID=”NAMEPROPER”>
<rdfs:domain rdf:resource=”#CLASSDOM”>
<rdfs:range rdf:resource=”NAMERANGE”>
</owl: DatatypeProperty>
end;
DEFINE_ENUMERATEDCLASS(NAMECLASS: :Text, LVALUES: SetValues, var TOWL: Text);
begin
TOWL <= TOWL + <owl:Class rdf:ID=”NAMECLASS”>
<owl:oneOf rdf:parseType=”Collection”>
for all X ∈ LVALUES do
TOWL <= TOWL +
<owl:Thing rdf:about=”#X”/>
TOWL <= TOWL +
</owl:oneOf>
</owl:Class>
for all X ∈ LVALUES do
TOWL <= TOWL + <NAMECLASS rdf:ID=”X”/>
TOWL <= TOWL + <owl:AllDifferent>
<owl:distinctMembers rdf:parseType=”Collection”>
for all X ∈ LVALUES do
TOWL <= TOWL +
<NAMECLASS rdf:about=”#X”/>
TOWL <= TOWL +
</owl:distinctMembers>
</owl:AllDifferent>
return NAMECLASS;
end;
DEFINE_DEFAULTVALUE(PROPER: Property, TYPEPROPER: Text, VALUE: Text, var TOWL:
Text);
begin
NAMEPROPER <= CONCATENA(‘has’, PROPER);
NAMESUBPROPERTY <= CONCATENA(PROPER ,‘DefaultValue’,);
TOWL <= TOWL + <owl:TYPEPROPER rdf:ID=”NAMESUBPROPERTY”>
<rdfs:subPropertyOf rdf:resource=”#NAMEPROPER”/>
<owl:Restriction>
<owl:hasValue rdf:resource=”#VALUE”/>
</owl:Restriction>
</owl:TYPEPROPER>
end;
118
DEFINE_RESTRICTION(CLASS: Class, PROPER: Propety, RANGE: Class, TYPE:Text; TOWL:
Text);
begin
NAMEPROPER <= CONCATENA(‘has’, PROPER);
TOWL <= TOWL + <owl:Class rdf:ID="CLASS">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource=”#NAMEPROPER”/>
<owl: TYPE rdf:resource=”#RANGE”/>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
end;
DEFINE_CARDINALITY(CLASS, PROPER, CARD, NUMBER, TOWL);
begin
NAMEPROPER <= CONCATENA(‘has’, PROPER);
TOWL <= TOWL + <owl:Class rdf:ID=”CLASS”>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource=”#NAMEPROPER”/>
<owl:CARD
rdf:datatype="&xsd;nonNegativeInteger">NUMBER
</owl:CARD>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
end;
DEFINE_INSTANCE_VALUE(CLASS, INST, PROPER, VALUE, TOWL)
begin
NAMEPROPER <= CONCATENA(‘has’, PROPER);
TOWL <= TOWL + < CLASS rdf:ID="INST">
< NAMEPROPER rdf:resource="#VALUE" />
</ CLASS >
end;
/***************** Funções de Consulta à Base ***********/
CONSULT_PROPERTY_TYPE(BC, PROPER, var TYPEPROPER);
begin
{procura o na BC se a propriedade PROPER é um datatypeProperty, ou um
objectProperty}
{ TYPEPROPER <= datatypeProperty ou objectProperty }
end;
CONSULT_PROPERTY_VALUE(BC, PROPER, VALUE);
begin
{verifica na BC se VALUE é um valor permitido pela RANGE de PROPER}
{Se VALUE for um valor permitido
then return true
else return false }
end;
119
CONSULT_SUPER_CLASS(BC, CLASS);
begin
{procura na BC a CLASSEMÃE de CLASS }
{return CLASSEMÃE}
end;
RETIRE_DEFINITION(var BC, CLASS);
begin
{procura na BC a definição de CLASS e revoga esta definição}
end;
CONSULT_PROPER (PROPER, BC)
begin
{procura na BC a definição de PROPER
se achou
then return true
else return false }
end;