You are on page 1of 139

Universidade de Brası́lia

Instituto de Ciências Exatas


Departamento de Ciência da Computação

Framework para Redes Bayesianas


Multi-Entidades e Ontologias Probabilı́sticas

Shou Matsumoto
Laécio Lima dos Santos

Monografia apresentada como requisito parcial


para conclusão do Bacharelado em Ciência da Computação

Orientador
Prof. Dr. Marcelo Ladeira

Co-orientador
Dr. Paulo Cesar Guerreiro da Costa

Brası́lia
2008
Universidade de Brası́lia – UnB
Instituto de Ciências Exatas
Departamento de Ciência da Computação
Curso de Bacharelado em Ciência da Computação

Coordenador: Guilherme Albuquerque Pinto

Banca examinadora composta por:


Prof. Dr. Marcelo Ladeira (Orientador) – CIC/UNB
Dr. Paulo Cesar Guerreiro da Costa – George Mason University
Prof a.̄ Dr a.̄ Célia Ghedini Ralha – CIC/UNB
Prof. Dr. Malthus Fonseca Galvão – Faculdade de Medicina/UNB

CIP – Catalogação Internacional na Publicação

Shou Matsumoto.

Framework para Redes Bayesianas Multi-Entidades e Ontologias Proba-


bilı́sticas/ Laécio Lima dos Santos, Shou Matsumoto. Brası́lia : UnB,
2008.
139 p. : il. ; 29,5 cm.

Monografia (Graduação) – Universidade de Brası́lia, Brası́lia, 2008.

1. MEBN, 2. PR-OWL, 3. Ontologias Probabilı́sticas,


4. UnBBayes, 5. SSBN, 6. Redes Bayesianas, 7. Raciocı́nio
Probabilı́stico, 8. Web Semântica, 9. Lógica de Primeira Ordem

CDU 004

Endereço: Universidade de Brası́lia


Campus Universitário Darcy Ribeiro – Asa Norte
CEP 70910–900
Brası́lia – DF – Brasil
Universidade de Brası́lia
Instituto de Ciências Exatas
Departamento de Ciência da Computação

Framework para Redes Bayesianas


Multi-Entidades e Ontologias Probabilı́sticas

Shou Matsumoto
Laécio Lima dos Santos

Monografia apresentada como requisito parcial


para conclusão do Bacharelado em Ciência da Computação

Prof. Dr. Marcelo Ladeira (Orientador)


CIC/UNB
Dr. Paulo Cesar Guerreiro da Costa (Co-orientador)
George Mason University

Prof. Dr. Malthus Fonseca Galvão Prof a.̄ Dr a.̄ Célia Ghedini Ralha
Faculdade de Medicina/UNB CIC/UNB

Guilherme Albuquerque Pinto


Coordenador do Bacharelado em Ciência da Computação

Brası́lia, 24 de junho de 2008


Dedicatória
Dedicamos este trabalho aos nossos pais, por nos trazerem a este mundo sem
desistência nos momentos difı́ceis. Sem eles, certamente este documento não veria
a luz do dia.
Agradecimentos
Agradecemos o Prof. Orientador Dr. Marcelo Ladeira, por nos orientar
durante esse ponto crucial da longa jornada de graduação; sempre educando
conscientemente os alunos, formando cidadãos responsáveis e preparados para
o exercı́cio profissional.

Gostarı́amos também de agradecer nosso Co-orientador, Dr. Paulo César G.


da Costa, pela grande disponibilidade que tem nos oferecido para esclarecimentos
e apoios durante o projeto. Essa atenção e o entusiasmo foram uma grande ajuda
para o nosso trabalho. Agradecemos também o mestre Rommel Novaes Carvalho.
Todo nosso trabalho tem como base seu projeto de mestrado; portanto, sem ele
nosso trabalho nem teria nascido.

Por fim, agradecemos a todos os amigos e familiares que certamente con-


tribuı́ram para a conclusão deste trabalho.
Resumo
Trantando-se de formalismo hı́brido, redes bayesianas e lógica de primeira or-
dem em inteligência artificial; MEBN (Multi-Entity Bayesian Network ) são redes
bayesianas multi-entidades, uma extensão das redes bayesianas em que a lógica
de primeira ordem é integrada.

A equipe de inteligência artificial da UnB, com o framework UnBBayes, tem


se mostrado pioneiro na implementação de editor gráfico e máquina de inferência
sobre o referente formalismo. No entanto, poucos domı́nios de aplicação são co-
nhecidos para o exercı́cio da MEBN. O presente trabalho tem como objetivo
identificar e modelar novos exemplos de domı́nios de aplicação, formular dire-
tivas para a modelagem de conhecimento representado em MEBN e avaliar a
utilização do UnBBayes como ferramenta computacional de edição e inferência,
realizando devidas alterações e otimizações na ferramenta, em caso de necessi-
dade. O domı́nio é modelado em linguagem PR-OWL.

A pesquisa oferece importantes contribuições para o UnBBayes, entre as quais


se destacam a elaboração e implementação de um novo algoritmo de geração de
redes bayesianas de situação especı́fica (SSBN), a análise e otimização de desem-
penho, novos exemplos de domı́nios de aplicação, melhorias na compatibilidade
com ontologias não-probabilı́sticas e aprimoramentos na interface gráfica.

Palavras-chave: MEBN, PR-OWL, Ontologias Probabilı́sticas, UnBBayes, SSBN,


Redes Bayesianas, Raciocı́nio Probabilı́stico, Web Semântica, Lógica de Primeira
Ordem
Abstract
Generally speaking about hibrid formalizations, Bayesian Networks, and First-
Order Logic application on artificial intelligence; MEBN are Multy-Entity Bayesian
Networks, an extension of Bayesian Networks by adding First-Order Logic (FOL).

UnB’s artificial intelligence research group is proud to announce UnBBayes


framework, pioneer as MEBN graphical edition tool and reasoning engine. How-
ever, not so many domains are known to be MEBN-worthy. This work gives a
try to identify and model new knowledge-domains for MEBN usage, formulate
guidelines for MEBN modeling, and analize UnBBayes framework as a plausible
tool for MEBN edition and reasoning, bringing optimizations wherever needed.
The knowledge domain model is written in PR-OWL.

This research has provided some important contributions for UnBBayes: cre-
ation of a brand-new Situation Specific Bayesian Network (SSBN) generation
algorithm, performance profiling and tuning, new samples of domains, compat-
ibility solutions for non-probabilistic ontologies, and an improved user-friendly
graphical interface.

Keywords: MEBN, PR-OWL, Probabilistic Ontologies, UnBBayes, SSBN, Bayesian


Networks, Probabilistic Reasoning, Semantic Web, First-Order Logic
Sumário

Lista de Figuras 11

Capı́tulo 1 Introdução 13

Capı́tulo 2 Base teórica 16


2.1 Redes Bayesianas (BN) . . . . . . . . . . . . . . . . . . . . . . . 16
2.2 Lógica de Primeira Ordem (FOL) . . . . . . . . . . . . . . . . . . 21
2.3 Web Semântica e Ontologias . . . . . . . . . . . . . . . . . . . . . 24
2.3.1 O que é ontologia . . . . . . . . . . . . . . . . . . . . . . . 25
2.3.2 A Linguagem OWL - Web Onthology Language . . . . . . 26
2.4 A necessidade de tratamento de incertezas em ontologias . . . . . 27
2.4.1 Justificativa da abordagem probabilı́stica em ontologias . . 30

Capı́tulo 3 Estado da arte 33


3.1 MEBN - Redes Bayesianas Multi-Entidade . . . . . . . . . . . . . 33
3.2 MFrags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3 Recursividade em MEBN . . . . . . . . . . . . . . . . . . . . . . . 36
3.4 MTheories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5 Uma ontologia probabilı́stica - PR-OWL . . . . . . . . . . . . . . 39

Capı́tulo 4 Arquitetura geral do UnBBayes 45


4.1 Visão arquitetural do UnBBayes . . . . . . . . . . . . . . . . . . . 46
4.1.1 Diagramas de influência e redes bayesianas . . . . . . . . . 47
4.1.2 Redes bayesianas múltipla-seccionadas . . . . . . . . . . . 48
4.1.3 Modelagem geral da versão inicial do UnBBayes-MEBN . . 49

Capı́tulo 5 Implementação do UnBBayes-MEBN 58


5.1 Interface Gráfica . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.1.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.1.2 Painel Principal . . . . . . . . . . . . . . . . . . . . . . . . 61
5.1.3 Edição de MFrags e de seus elementos . . . . . . . . . . . 63
5.1.4 Edição de entidades e findings . . . . . . . . . . . . . . . . 65
5.1.5 Questionamentos e geração de SSBN . . . . . . . . . . . . 65
5.2 Lógica de primeira ordem utilizando PowerLoom . . . . . . . . . . 67
5.2.1 O PowerLoom . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.2.2 Lógica de Primeira Ordem no PowerLoom . . . . . . . . . 69
5.2.3 Uso do PowerLoom para a avaliação dos nós de contexto . 71
5.3 Entrada e Saı́da no UnBBayes . . . . . . . . . . . . . . . . . . . . 75
5.3.1 O Protégé . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.3.2 Arquivo UBF - UnBBayes File . . . . . . . . . . . . . . . 78
5.3.3 Implementação no UnBBayes . . . . . . . . . . . . . . . . 80

Capı́tulo 6 SSBN - Algoritmos de geração 83


6.1 Bottom-Up SSBN Generation . . . . . . . . . . . . . . . . . . . . 83
6.2 Novo algoritmo de geração de SSBN . . . . . . . . . . . . . . . . . 85
6.2.1 Modelagem das classes envolvidas no algoritmo . . . . . . 86
6.2.2 Descrição do algoritmo . . . . . . . . . . . . . . . . . . . . 87

Capı́tulo 7 Análise de qualidade e manutenção 90


7.1 Profiling e Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
7.2 Manutenibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
7.2.1 Simplicidade estrutural . . . . . . . . . . . . . . . . . . . . 93
7.3 Outras alterações importantes . . . . . . . . . . . . . . . . . . . . 94
7.3.1 Compatibilidade OWL - PR-OWL . . . . . . . . . . . . . 94

Capı́tulo 8 Ontologias - StarTrek e PizzaVinho 99


8.1 Ontologia StarTrek . . . . . . . . . . . . . . . . . . . . . . . . . . 99
8.2 Ontologia Pizza e Vinho . . . . . . . . . . . . . . . . . . . . . . . 107
8.2.1 MFrag Pizza . . . . . . . . . . . . . . . . . . . . . . . . . 108
8.2.2 MFrag Served Together . . . . . . . . . . . . . . . . . . . 109
8.2.3 MFrag Topped By . . . . . . . . . . . . . . . . . . . . . . . 110
8.2.4 MFrag Wine . . . . . . . . . . . . . . . . . . . . . . . . . . 111
8.2.5 Algumas considerações . . . . . . . . . . . . . . . . . . . . 111
8.3 Processo de modelagem de ontologias probabilı́sticas . . . . . . . 112

Capı́tulo 9 Projeto de identificação humana baseada em raciocı́nio


probabilı́stico 114
9.1 Membros da equipe de pesquisa . . . . . . . . . . . . . . . . . . . 115
9.2 Descrição do projeto . . . . . . . . . . . . . . . . . . . . . . . . . 115
9.2.1 Objetivo principal . . . . . . . . . . . . . . . . . . . . . . . 116
9.2.2 Hipótese . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
9.2.3 Material e método . . . . . . . . . . . . . . . . . . . . . . 117
9.2.4 Responsabilidades . . . . . . . . . . . . . . . . . . . . . . . 118
9.2.5 Da publicidade dos resultados . . . . . . . . . . . . . . . . 118
9.3 Análise dos resultados . . . . . . . . . . . . . . . . . . . . . . . . 118
9.3.1 Passos gerais para modelagem do domı́nio . . . . . . . . . 118
9.4 Modelagem do domı́nio no UnBBayes . . . . . . . . . . . . . . . . 121
9.4.1 Metodologia de modelagem no UnBBayes . . . . . . . . . . 121
9.4.2 Ajuste de dados . . . . . . . . . . . . . . . . . . . . . . . . 123
9.4.3 Resultado da modelagem . . . . . . . . . . . . . . . . . . . 123
9.5 Metáfora UnBBayes . . . . . . . . . . . . . . . . . . . . . . . . . . 124
9.5.1 Arquitetura da metáfora . . . . . . . . . . . . . . . . . . . 125

9
Capı́tulo 10 Conclusão 129
10.1 Trabalhos futuros ou correlatos . . . . . . . . . . . . . . . . . . . 129

Referências 131

Apêndice A Exemplos de código em OWL 134

Apêndice B Elementos da PR-OWL 135


B.1 Listagem das classes definidas na PR-OWL . . . . . . . . . . . . . 135
B.2 Listagem das propriedades definidas na PR-OWL . . . . . . . . . 137

10
Lista de Figuras

2.1 Figura exemplo de Rede bayesiana [12] . . . . . . . . . . . . . . . 17


2.2 Um subdomı́nio do StarTrek para ilustrar problemas na BN[28]. . 19
2.3 BN para o caso de uma espaçonave, com recursão . . . . . . . . . 20
2.4 Ilustração da tripla forma-conceito-referente. . . . . . . . . . . . . 26

3.1 Figura exemplo de MFrag . . . . . . . . . . . . . . . . . . . . . . 34


3.2 Um MFrag recursivo [15] . . . . . . . . . . . . . . . . . . . . . . . 41
3.3 Modelagem de uma situação recursiva . . . . . . . . . . . . . . . . 42
3.4 Conjunto de MFrags que formam uma MTheory [15] . . . . . . . 43
3.5 Principais conceitos da PR-OWL [17] . . . . . . . . . . . . . . . . 44
3.6 Elementos de uma ontologia probabilı́stica PR-OWL [17] . . . . . 44

4.1 Logotipo do UnBBayes. . . . . . . . . . . . . . . . . . . . . . . . 45


4.2 Modelagem de classes para BN e ID. . . . . . . . . . . . . . . . . 47
4.3 Modelagem de classes para MSBN. . . . . . . . . . . . . . . . . . 49
4.4 Modelagem de classes para MTheory . . . . . . . . . . . . . . . . 50
4.5 Modelagem de classes para MFrag. . . . . . . . . . . . . . . . . . 51
4.6 Modelagem de classes para os nós de uma MEBN. . . . . . . . . . 52
4.7 MFrag Starship Data. . . . . . . . . . . . . . . . . . . . . . . . . 54
4.8 Modelagem de classes do compilador do pseudo-código. . . . . . . 55
4.9 Diagrama de classes da tabela temporária do compilador de pseudo-
código do UnBBayes-MEBN. . . . . . . . . . . . . . . . . . . . . . 56
4.10 Organização das colunas e células da tabela temporária. . . . . . . 57

5.1 Arquitetura da GUI . . . . . . . . . . . . . . . . . . . . . . . . . . 59


5.2 Diagrama de sequência de criação dos objetos da GUI - parte 1 . 60
5.3 Diagrama de sequência de criação dos objetos da GUI - parte 2 . 61
5.4 Componentes do Painel Principal do UnBBayes . . . . . . . . . . 62
5.5 Exibição do MFrag ativo . . . . . . . . . . . . . . . . . . . . . . . 63
5.6 Janela de edição da CPT . . . . . . . . . . . . . . . . . . . . . . . 64
5.7 Painel de edição do nó de input . . . . . . . . . . . . . . . . . . . 64
5.8 Edição da fórmula do nó de contexto . . . . . . . . . . . . . . . . 65
5.9 Edição de entidades . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.10 Edição de evidências . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.11 Painel da rede compilada . . . . . . . . . . . . . . . . . . . . . . . 67
5.12 Modelagem do uso do PowerLoom. . . . . . . . . . . . . . . . . . 71
5.13 Nós de contexto da MFrag Starship. . . . . . . . . . . . . . . . . 74
5.14 Tela de edição de classes/indivı́duos no Protégé. . . . . . . . . . . 76
5.15 Modelagem de IO de MEBN . . . . . . . . . . . . . . . . . . . . . 81

6.1 SSBN gerada para HarmPotential(ST4, T3) utilizando o Bottom-


Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.2 Classes utilizadas na geração do SSBN . . . . . . . . . . . . . . . 86
6.3 Classe SSBNNode e classes relacionadas . . . . . . . . . . . . . . 87
6.4 SSBN gerada para HarmPotential(ST4, T3 ) utilizando o novo
algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

7.1 Tela de profiling do TPTP. É possı́vel analisar seqüência de execução


e gerar diagramas UML de seqüência. . . . . . . . . . . . . . . . . 90
7.2 Tela de log (esquerda) e testes (direita) do TPTP. . . . . . . . . . 91
7.3 Laudo de tempo-base antes da otimização . . . . . . . . . . . . . 95
7.4 Laudo de tempo base de execução após a otimização. . . . . . . . 96
7.5 Diagramas de classe da compatibilidade OWL - PR-OWL . . . . . 97
7.6 Seqüência de carregamento de arquivo PR-OWL, mantendo o OWL-
Model em memória. . . . . . . . . . . . . . . . . . . . . . . . . . . 97
7.7 Seqüência de armazenamento de arquivos PR-OWL mantendo OWL-
Model em memória. . . . . . . . . . . . . . . . . . . . . . . . . . . 98

8.1 MTheory para o domı́nio StarTrek . . . . . . . . . . . . . . . . . 99


8.2 MFrag StarshipData . . . . . . . . . . . . . . . . . . . . . . . . . 100
8.3 MFrag SRData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
8.4 MFrag Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
8.5 MFrag DangerToOthers modelada no UnBBayes. . . . . . . . . . 102
8.6 MFrag DangerToSelf . . . . . . . . . . . . . . . . . . . . . . . . . 103
8.7 MFrag SensorReport . . . . . . . . . . . . . . . . . . . . . . . . . 104
8.8 MFrag SRData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
8.9 MFrag SRData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
8.10 Uma sugestão de MTheory para a ontologia Pizza e Vinho, extraı́da
de [18] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
8.11 MFrag Pizza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
8.12 MFrag Served Together . . . . . . . . . . . . . . . . . . . . . . . 110
8.13 MFrag Topped By . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
8.14 MFrag Wine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
8.15 MFrag Wine com recursividade . . . . . . . . . . . . . . . . . . . . 112

9.1 Formulário para coleta de dados . . . . . . . . . . . . . . . . . . . 117


9.2 BN de identificação humana . . . . . . . . . . . . . . . . . . . . . 124
9.3 Entrada de evidências pela metáfora. . . . . . . . . . . . . . . . . 126
9.4 Tela de laudo da metáfora. . . . . . . . . . . . . . . . . . . . . . . 126
9.5 Diagrama de classes da metáfora. . . . . . . . . . . . . . . . . . . 127
9.6 Diagrama de seqüência de abertura de BN. . . . . . . . . . . . . . 128
9.7 Seqüência de execução de queries, propagação de evidências.. . . 128

12
Capı́tulo 1

Introdução

As redes bayesianas (Bayesian Network - BN ), amplamente utilizadas na área


de Inteligência Artificial, modelam matematicamente algum domı́nio de conheci-
mento, cujo seu comportamento não é determinado por completo, necessitando
assim do uso de algum tipo de raciocı́nio probabilı́stico. São bastante úteis para
modelar relações de causa e efeito, possibilitando assim a criação de modelos com-
putacionais voltados à decisão.

Elas são utilizadas em várias áreas de aplicação. Na NASA (National Aero-


nautics and Space Administration), as redes bayesianas são aplicadas para inter-
polação de dados espaciais para aquisição de conhecimentos [35]. A Microsoft,
por sua vez, utiliza-o para o assistente do Office [22]. Entretanto, com esta cres-
cente exploração das utilidades do formalismo, as limitações foram se tornando
mais claras, mostrando que o seu uso não era possı́vel em diversas situações do
cotidiano. Esta falha surge principalmente pela impossibilidade de se represen-
tar situações cujo número de variáveis aleatórias envolvidas é desconhecido. Isso
pode se tornar claro quando se precisa representar domı́nios com recursividade,
como variáveis cujo estado depende do seu estado em um momento anterior.

Tornou-se então necessário o desenvolvimento de novos mecanismos que per-


mitissem a modelagem e inferência de cenários probabilı́sticos mais complexos.
Muitas pesquisas foram realizadas com o intuito de estender o poder expressivo
das redes bayesianas, de forma a permitir a modelagem de domı́nios mais com-
plexos. Pode-se citar como exemplo as Redes Bayesianas Dinâmicas (DBN) [21],
que permitem repetições de nós no tempo, como uma solução para o problema
da recursividade. Entretanto, para a representação de situações mais gerais de
recursão e variação na quantidade de variáveis, torna-se necessário mecanismos
mais avançados.

Abordagens com lógica de primeira ordem oferecem um formalismo represen-


tacional poderoso, porém não possui suporte natural ao raciocı́nio com incertezas.
A MEBN (Multi-Entities Bayesian Networks) é um formalismo que unifica redes
bayesianas à lógica de primeira ordem, permitindo uma representação mais com-
pleta de domı́nios com incertezas. A MEBN ultrapassa as limitações das redes

13
bayesianas normais ao utilizar o conceito de entidades, que são instanciadas de
acordo com a necessidade, montando redes bayesianas especı́ficas para cada si-
tuação (Situation Specific Bayesian Network - SSBN) do domı́nio modelado.

A criação da primeira ferramenta computacional para a edição, inferência e


verificação de consistência da MEBN foi tema do projeto de mestrado do mestre
Rommel Novaes Carvalho [10], projeto no qual atuamos como programadores.
Para a implementação de tal ferramenta, foi utilizado o framework UnBBayes [9]
como base, estendendo-o para o suporte à MEBN. O novo módulo, UnBBayes-
MEBN, permite a edição gráfica de MEBN, persistência dos modelos gerados
como uma ontologia em linguagem PR-OWL [14], verificação de consistência
semântica-estrutural e geração de SSBN para realização de inferências. Como
uma SSBN se comporta à semelhança de uma rede bayesiana convencional, pode-
se utilizar algoritmos convencionais de manipulação de redes bayesianas para o
seu posterior tratamento1 .

Infelizmente, sendo o módulo de MEBN uma funcionalidade nova, testes mais


aprofundados em domı́nios mais realı́sticos tornaram-se uma exigência. O tema
central deste trabalho reside na identificação de novos domı́nios de aplicação
de MEBN, documentação de procedimentos para modelagem de ontologias em
MEBN/PR-OWL2 e ajuste do UnBBayes-MEBN para a avaliação de sua viabili-
dade nos domı́nios identificados, promovendo também aprimoramentos no desem-
penho e usabilidade da ferramenta. Para minimizar os riscos inerentes à grande
complexidade da pesquisa, a seguinte metodologia foi aplicada aos alunos para o
acompanhamento:

1. A tarefa de implementação do formalismo de MEBN no UnBBayes foi o


objeto de pesquisa de mestrado (em Informática), sob a orientação do Prof.
Ladeira, do aluno Rommel Carvalho. Para auxiliar esse mestrando nessa
tarefa, submeteu-se dois pleitos de apoio na forma de Iniciação Cientı́fica
(Projeto de Iniciação Cientı́fica - PIC UNB). As atividades associadas à
Iniciação Cientı́fica, como a elaboração de relatórios e apresentação em con-
gressos, ofereceram uma maturidade para a pesquisa sistemática, elaboração
formal de documentos e defesa de teses.

2. Efetivou-se a matrı́cula nas disciplinas “Estudos em Inteligência Artifi-


cial”, “Estudos em Sistemas de Computação”, “Estudos em Sistemas de
Informação” e “Trabalho de Graduação / Trabalho de Graduação 2” da
Universidade de Brası́lia, ofertadas pelo orientador Marcelo Ladeira, para
auxiliar no acompanhamento detalhado do progresso do trabalho. Os prin-
cipais instrumentos de acompanhamento foram as reuniões semanais e a
elaboração semestral de monografias prévias, acompanhadas por suas res-
1
O MEBN pode ser entendido como um template para geração de SSBN
2
A presente pesquisa aborda dois caminhos diferentes de modelagem: modelagem guiada a
dados (projeto IDENTIFICAÇÃO HUMANA) e modelagem guiada à observação do especialista
(ontologia pizza e vinho).

14
pectivas defesas. A presente monografia é fruto de extensões seqüenciais
das monografias prévias.

3. O gerenciamento do projeto UnBBayes está centralizado no sı́tio Source-


forge (http://www.sourceforge.net). Realizou-se a inclusão como membros
do projeto UnBBayes no Sourceforge para permitir remotamente o desen-
volvimento em equipe do software. Eventuais falhas e pedidos de novas
funcionalidades tiveram seus registros na referida plataforma.

4. Efetivou-se a participação em um mini-curso com 10 horas de duração sobre


MEBN, ministrado pelo mestrando Rommel Carvalho, para o entendimento
dos conceitos raı́zes da pesquisa.

Os capı́tulos seguintes relatam os resultados da pesquisa; iniciando com o


capı́tulo 2, que introduz as bases teóricas para a compreensão de conhecimentos
modelados em MEBN e da implementação do UnBBayes, começando com algu-
mas idéias básicas sobre redes bayesianas, lógica de primeira ordem e ontologias.

O capı́tulo 3 descreve o formalismo MEBN e a linguagem PR-OWL. Os


capı́tulos 4 e 5 descrevem a arquitetura e implementação do UnBBayes-MEBN.
O capı́tulo 6 apresenta o novo algoritmo de geração de SSBN desenvolvido para
corrigir erros da implementação anterior. O capı́tulo 7 descreve a análise de quali-
dade e manutenibilidade feita com o objetivo de garantir a qualidade do software
disponibilizado para o público.

O capı́tulo 8 apresenta as ontologias-teste - StarTrek e PizzaEVinho - mode-


ladas para o exercı́cio da ferramenta e realização dos procedimentos e técnicas
de modelagem MEBN. Por fim, o capı́tulo 9 descreve o projeto Identificação Hu-
mana Apoiada Em Ontologias e Inteligência Artificial (Raciocı́nio Probabilı́stico),
uma colaboração do Grupo de Inteligência Artificial da UnB (GIA) com a Fa-
culdade de Medicina/Medicina Legal da UnB e ilustra as principais dificuldades
encontradas em uma modelagem de um domı́nio real.

15
Capı́tulo 2

Base teórica

Este capı́tulo fará uma introdução teórica aos conceitos necessários para a
compreenção do estado da arte. Conceitos referentes às redes bayesianas, lógica
de primeira ordem, ontologias e web semântica serão tratados aqui.

2.1 Redes Bayesianas (BN)

Uma BN é um grafo acı́clico direcionado (Direct Acyclic Graphic - DAG) que


representa uma função de distribuição de probabilidades conjunta de variáveis
que modelam certo domı́nio de conhecimento. Ela é constituı́da de um DAG, de
variáveis aleatórias (também chamadas de nós da rede), arcos direcionados da
variável pai para a variável filha e uma tabela de probabilidades condicionais ou
Condition Probability Table(CPT)) associada a cada variável [26].

A Figura 2.1, mostra um exemplo de rede bayesiana. A Tabela 2.1 mostra a


distribuição de probabilidades para o nó “Cachorro fora de Casa” de acordo com
os valores dos pais.

Cachorro passando mal Famı́lia Saiu Verdadeiro Falso


Verdadeiro Verdadeiro 10% 90 %
Verdadeiro Falso 20% 80%
Falso Verdadeiro 70% 30%
Falso Falso 90% 10%

Tabela 2.1: Tabela de distribuição de probabilidades para o nó “Cachorro fora de


casa”.

Nesse exemplo, suponhamos que se queira determinar se a famı́lia está em casa


ou se ela saiu. Pelo grafo, podemos perceber que o fato da luz da varanda estar
acesa e do cachorro estar fora de casa são indı́cios de que a famı́lia tenha saı́do.
Como estamos trabalhando com incertezas, o conhecimento dos valores dessas

16
Figura 2.1: Figura exemplo de Rede bayesiana [12]

variáveis não é determinado, mas sim estimado. Quanto maior for a probabili-
dade da luz da varanda estar acesa, maior é a probabilidade da famı́lia ter saı́do.
Por outro lado, se sabemos com certeza que o cachorro não está fora de casa (ou
seja, probabilidade 1), então a probabilidade da famı́lia ter saı́do é diminuı́da. As
Tabelas de Probabilidades Condicionais (Conditional Probability Tables - CPT)
podem ser construı́das por um especialista do domı́nio ou por regularidades es-
tatı́sticas.

Uma das vantagens de se trabalhar com BN é o fato de não ser necessário


especificar a distribuição de probabilidades de todo o domı́nio, envolvendo todas
as variáveis. Isso é possı́vel devido às independências condicionais.

As variáveis conectadas por arcos são diretamente dependentes. Assim, se a


probabilidade de uma variável é alterada, a outra também será alterada por causa
dessa relação direta. As variáveis não conectadas por arcos são ditas condicional-
mente independentes.

Para o exemplo anterior, dado que não haja certeza se o cachorro está fora
de casa, se a probabilidade da famı́lia ter saı́do é alterada, então a do cachorro
estar fora de casa também será. Conseqüentemente, a do cachorro estar latindo
também. Porém, caso tenhamos certeza de que o cachorro está fora de casa
(sabemos que a variável “cachorro” fora de casa tenha 100% de chance de ser
verdadeira), então a variável “Famı́lia saiu” não influenciará mais a variável “Ca-
chorro latindo”, pois esta será influenciada diretamente pela variável “Cachorro
fora de casa”, cujo valor já é conhecido1 .

Assim, em vez de termos de especificar as relações de probabilidade entre


todas as variáveis, precisamos especificar apenas as relações das variáveis direta-
1
Essa entrada de informação conhecida é chamada de entrada de evidências.

17
mente dependentes. Isso facilita o uso das redes bayesianas computacionalmente.
É possı́vel calcular a distribuição de probabilidade conjunta através da fórmula
abaixo:

Qn
P (x1 , ..., xn ) = i=1 P (xi |pais(xi ))

Sendo P (xi |pais(xi )) a probabilidade de ocorrência de xi condicionada às


variáveis pais. Portanto, é possı́vel calcular a distribuição de probabilidade con-
junta a partir de probabilidades condicionais locais, tornando a rede bayesiana
uma representação bastante compacta.

As redes bayesianas possuem diversas aplicações. Entre elas, podemos citar:


diagnósticos de defeitos em processadores (técnica utilizada pela Intel), exames
patológicos, troublesolver do Microsoft Word, aplicações militares, controle de
spam, entre outros. Inclusive, o GIA pesquisa a aplicação de modelos de in-
ferência bayesiana na web.

Entretanto, as redes bayesianas carecem de uma expressividade forte o sufici-


ente para representar diversas situações do mundo real. Esta incapacidade surge
principalmente pela impossibilidade de se representar situações cujo número de
variáveis aleatórias envolvidas é desconhecido e da incapacidade de se representar
recursão.

Apesar dessas redes bayesianas convencionais serem úteis para a modelagem


de um domı́nio incerto, ele não tem a capacidade de modelar corretamente a
incerteza de quantidade de condicionantes (incerteza sobre quantos pais um de-
terminado nó possui - isto deve estar pré-determinado). Adicionalmente, como o
grafo deve ser acı́clico, não há como modelar recursividade de variáveis aleatórias
(quando uma variável condiciona a ela mesma direta ou indiretamente), cujo o
número de etapas que devem ser consideradas é indeterminado.

Para exemplificar as deficiências, será utilizada uma parte do domı́nio StarTrek[1].


A ontologia StarTrek, apresentada em [15], é baseada na série de televisão homônima
que mostra as diversas missões de exploração do espaço inter-estelar da nave
U.S.S. Enterprise. A nave é equipada com diversos sensores que oferecem ao
comandante as informações necessárias para navegar pelo espaço: informações
sobre o lugar (zona) onde ele se encontra, sobre as naves na adjacência e os nı́veis
de perigo que elas trazem, entre outras (a ontologia StarTrek está descrita em
detalhes na Seção 8.1.

A modelagem apresentada na Figura 2.2 modela como os sensores captam


informações para informar o comandante se há uma nave Romulana nas proximi-
dades (os Romulanos são inimigos da Federação Intergaláctica) e qual o nı́vel de
perigo que esta traz para a Enterprise. Todas as outras espaçonaves são conside-
radas ou amigas ou neutras.

18
Figura 2.2: Um subdomı́nio do StarTrek para ilustrar problemas na BN[28].

O grafo de influências indica quais são os nós que influenciam as probabi-


lidades de uma variável aleatória. As probabilidades de Operator Species, por
exemplo, são influenciadas por Zone Nature, que se refere aos possı́veis tipos de
lugares aonde a Enterprise pode se encontrar, pois há locais mais propı́cios para
encontrar Romulanos, por exemplo, que outros. As naves Romulanas podem es-
tar em Cloak Mode, estado que faz com que elas fiquem invisı́veis aos sensores da
Enterprise. No entanto, uma nave em cloak mode produz uma enorme quanti-
dade de energia, causando um distúrbio magnético (DM) no espaço. A Enterprise
possui um sensor de distúrbio magnético, porém é difı́cil distinguir o DM causado
pela nave inimiga do que já seria causado normalmente pela situação na qual a
Enterprise se encontra.

Cada variável aleatória contém uma coleção de estados. O nó Zone Nature é
o nó raiz (não é influenciado por nenhum outro nó), podendo ter sua distribuição
de probabilidade diretamente. Os outros nós são influenciados pelos nós pais,
conforme mostra o grafo de dependência, sendo esta influência quantificada por
uma tabela condicional de probabilidade (CPT), como a exemplificada na Tabela
2.2, que especifica a probabilidade de cada estado do nó para cada combinação
possı́vel dos estados dos nós pais.

Zone nature Cloak mode Magnetic distribution report


Low Medium High
Deep space True 80 13 7
False 85 10 5
Planetary True 20 32 48
Systems False 25 30 45
Black hole True 5 10 85
boundary False 6,9 10,6 82,5

Tabela 2.2: Tabela de Probabilidade Condicional para Distúrbio Magnético

19
Esta modelagem simples funciona apenas quando houver no máximo uma nave
nas proximidades. Caso haja duas naves se aproximando simultaneamente, será
necessário utilizar um novo modelo. Ora, em uma situação real não se sabe a
priori quantas naves vão se aproximar, tornando essa modelagem utilizando re-
des bayesianas inviável, pois seria necessário um modelo para cada número de
espaçonaves (note que, neste caso, o número de possibilidade é infinito). As redes
bayesianas carecem de poder expressivo para representar tipos de entidades que
podem ser instanciadas tantas vezes quanto requeridas pela situação.

Considere agora uma segunda situação. Admita que apenas uma nave esteja
nas proximidades da Enterprise em um determinado momento, validando o mo-
delo proposto. Suponha que em momento T1, a Enterprise esteja viajando pelo
espaço profundo (Deep Space) e que o seu sensor indique que não há nenhuma
nave nas proximidades. Suponha que em um momento T2 o sensor de distúrbio
magnético reporte a ocorrência de um alto distúrbio.

De acordo com a CPT mostrada na Tabela 2.2, as chances são de 7/5 de que
um distúrbio tenha sido causado por uma nave em cloak-mode na vizinhança.
Porém, esta ocorrência não é garantida, pois os distúrbios podem ser distúrbios
anormais de fundo. Uma forma de confirmar a ocorrência de tal nave é comparar
as medições seguintes do sensor, pois é natural que distúrbios anormais de ambi-
ente mostrem flutuações randômicas, enquanto, por outro lado, um distúrbio cau-
sado por uma espaçonave mostrará um padrão temporal caracterı́stico: quando
há uma espaçonave em cloak mode na vizinhança, o estado do distúrbio magnético
em um dado momento dependerá de seu estado prévio (Figura 2.3). Ora, as redes
bayesianas são estáticas, impedindo a recursão necessária para resolver problemas
deste tipo. Esta é outra restrição que imprede a continuação da modelagem.

Figura 2.3: BN para o caso de uma espaçonave, com recursão

20
Estes dois exemplos mostram dificuldades que um modelador poderá enfrentar
ao tentar representar o mundo utilizando redes bayesianas convencionais, Estas
limitações impedem que redes bayesianas sejam utilizadas, em sua forma pura,
para representar problemas complexos; limitando o seu uso apenas a situações
especı́ficas e simples. Para a solução desses problemas, foi proposta a MEBN,
uma abstração mais genérica sobre redes bayesianas.

2.2 Lógica de Primeira Ordem (FOL)

Desde a antiguidade o homem inventa formalismos para descrever o mundo


de uma forma a eliminar as ambigüidades da linguagem natural. O principal ob-
jetivo destas descrições é permitir mecanismos de inferência para se obter novos
conhecimentos a partir de uma base formal de conhecimento. A lógica surgiu no
intuito de explicar as várias noções da verdade, codificando os enunciados (vistos
como verdades lógicas), avaliar a legitimidade (validade) de argumentos e realiar
inferências plausı́veis.

A lógica possui vários formalismos. O mais famoso seria a lógica proposi-


cional, que assume o mundo como uma composição de fatos, sendo estes a sua
unidade básica. Fatos são verdades em algum mundo relevante. Ora, apesar de
resolver problemas particulares, a lógica proposicional falha por não poder repre-
sentar generalizações, sendo portanto uma representação bastante limitada.

Uma lógica com poder expressivo de primeira ordem, por outro lado, vê o
mundo como um conjunto de objetos, estes possuindo identidades individuais e
propriedades que os distinguem de outros objetos.

Antes de entrar em detalhes nas caracterı́sticas da lógica de primeira ordem,


vamos definir alguns conceitos comuns a todos os formalismos lógicos:

• O vocabulário da lógica é composto por sı́mbolos, podendo estes serem


sı́mbolos lógicos ou sı́mbolos não-lógicos. Os sı́mbolos não-lógicos variam
de linguagem para linguagem, fornecendo um vocabulário especı́fico para
cada domı́nio de aplicação.

• A sintaxe fornece regras que permitem combinar os sı́mbolos, formando ex-


pressões legais.

• As regras de inferência especificam caminhos pelos quais novas expressões


podem ser derivadas a partir de expressões legais existentes.

• A semântica caracteriza o significado das expressões.

21
• Uma teoria é um conjunto que engloba as sentenças de uma linguagem e
suas conseqüências lógicas, definidas graças à existência de uma semântica.

A lógica deve possuir funções de mapeamento que permitam transformar fra-


ses da linguagem natural em uma frase no formalismo lógico e vice-versa. As
funções de mapeamento, via de regra, não são funções um para um.

A validade de um argumento independe da sua observação no mundo real. De-


pende somente das validades de suas premissas e a validade da conclusão. Esta
relação é chamada de relação de conseqüência.

A lógica de primeira ordem foi inventada por Frege e Peirce, independente-


mente, no final do século dezenove.

A gramática abaixo mostra, em formato BNF, a definição dos elementos da


Lógica de Primeira Ordem (First Order Logic - FOL). Esta é uma adaptação da
definição encontrada em [26].

< F ormula > := < F ormulaAtomica >

| < F ormula >< Conectivo >< F ormula >


| < Quantif icador >< V ariavel >, ... < F ormula >
|~< F ormula >
|(< F ormula >)

< F ormulaAtomica > := < P redicado > (< T ermo >, ...)

| < T ermo >=< T ermo >

< T ermo > := < F uncao > (< T ermo >, ...)

| < Constante >


| < V ariavel >

V W
< Conectivo > := → | |

< Quantif icador > := ∀ | ∃

< Constante > := A|X|M aria| ....

< V ariavel > := a|x|s| ...

< F uncao > := P aiDe|RaizQuadradaDe| ...

< P redicado > := Antes|T emCor|Chovendo|...

Seguem abaixo algumas descrições:

• Sı́mbolos Constantes: são sı́mbolos que representam os objetos do domı́nio.


A interpretação deve especificar qual é a entidade especificada. São escritas
iniciadas com letra maiúscula ou com um número. Ex.: A, Maria, 1888.
22
• Sı́mbolos Predicados: refere-se a uma relação particular no modelo (es-
pecificado pela interpretação). É definido por um conjunto de tuplas de
objetos que as satisfazem. Ex.: Irmão(Eduardo, Pedro).
• Sı́mbolos Funcionais: são relações especiais, cujo um dado objeto é relaci-
onado exatamente com outro objeto. Ex.: Pai (cada pessoa tem exatamente
uma pessoa, que é seu pai). Funções podem ser utilizadas para se referir a
objetos particulares sem utilizar seus nomes diretamente, como por exemplo
PaiDe(Maria).
• Termos: são utilizados para se referir a entidades no domı́nio, podendo
servir como argumentos para funções e predicados. Pode ser uma variável,
uma constante ou uma função, sendo estas últimas termos complexos; os
argumentos da função serão dispostos em uma lista parentetizada de termos,
com os termos separados por virgulas.
• Sentenças Atômicas: representam fatos. É formado por um predicado se-
guido por uma lista parentetizada de termos. Ex.: Irmão(Eduardo, Pedro),
que pela interpretação significa que Eduardo e Pedro são irmãos. Uma sen-
tença atômica é verdadeira se a relação referida pelo predicado é verdadeira
para os objetos referidos como seus argumentos.
• Sentenças Complexas: são construı́das a partir de sentenças W atômicas
utilizando-se os sı́mbolos lógicos. Ex.: Irmão(Eduardo, Pedro) Irmão(Maria,
Joana).
• Quantificadores: são utilizados para expressar propriedades de coleções de
objetos, ao invés de ter que enumerar os objetos por nome, como proposto
na lógica proposicional. A FOL contém dois quantificadores padrões:

– Quantificador Universal ( ∀ ): é utilizado para especificar sentenças que


são validas para todas os objetos. Ex.: ∀x (Gato(x) → Mamı́fero(x)).
– Quantificador Existencial ( ∃ ): é utilizado para especificar sentenças
que são válidas para
V algum objeto, sem no entanto, nomear este. Ex:
∃x(Irmã(x,Spot)) (Gato(x))

• Igualdade: é utilizada para dizer que dois termos se referem ao mesmo


objeto. Ex.: Pai(John) = Henry. A igualdade pode ser tratada como um
predicado.

Para aplicar a lógica de primeira ordem, deve-se definir um conjunto de axio-


mas, ou sentenças, que definam os fatos relevantes a respeito do domı́nio. Junta-
mente com as conseqüências dos axiomas, este conjunto forma a teoria do domı́nio.
O conjunto de conseqüências será um subconjunto próprio de todas as sentenças
sintaticamente corretas, caso os axiomas sejam consistentes; ou todas as sen-
tenças, caso os axiomas sejam inconsistentes; pois qualquer proposição segue de
uma contradição.

23
Como forma de usar a FOL para descrever o mundo, as ontologias de domı́nio
expressam conhecimento sobre os tipos de entidades no domı́nio de aplicação,
bem como seus atributos, comportamentos e relacionamentos. Para tal, pode-se
utilizar lógicas de propósito especial, construı́das sobre a FOL, que provêem cons-
truções pré-definidas para raciocı́nio sobre tipos, espaço ou tempo; permitindo que
o modelador possua uma base por onde começar a modelagem do domı́nio estu-
dado.

Apesar de sua grande expressividade, a FOL não possui suporte natural ao


tratamento de incertezas. A MEBN é um formalismo hı́brido que integra o trata-
mento de incertezas das redes bayesianas com a expressividade da FOL, trazendo
para a FOL o tratamento de incertezas. Maiores informações sobre a MEBN
podem ser obtidas na Seção 3.1.

2.3 Web Semântica e Ontologias

A Web Semântica é um projeto idealizado por Tim Berners-Lee, criador da


HTML e da World Wide Web (WWW), sob os auspı́cios do W3C - World Wide
Web Consortium [7]. O objetivo deste projeto é melhorar as potencialidades
da Web através da criação de ferramentas e de padrões que permitam atribuir
significados claros aos conteúdos das páginas e facilitar a sua publicação e manu-
tenção [8]. O W3C definiu a web semântica como um esforço colaborativo entre
o próprio W3C e um grande número de pesquisadores e parceiros industriais que
querem estender a web como um framework comum que permita que dados sejam
compartilhados entre aplicações, negócios e comunidades internacionais.

Os documentos da web tradicional são construı́dos em linguagens orientadas


a sintaxe, como o HTML e o XML. A XML é uma linguagem de marcação que
permite que os usuários criem tags personalizadas sobre o documento criado; dife-
rentemente da HTML, que possui estrutura de tags fixas, impedindo a criação de
um novo conjunto de descritores. Apesar da estrutura de tags permitir que sejam
providas regras sintáticas e convenientes para extrair, transformar e trocar dados,
estas informações são insuficientes para a manipulação pelos computadores, ca-
bendo portanto ao ser humano realizar tarefas árduas de extração de informação
e formulação de conhecimento.

Com a evolução dos computadores e o crescimento da massa de informações


disponı́veis na web, tornou-se necessário um planejamento para permitir que o
próprio computador possa realizar raciocı́nios a fim de formular conhecimento.
Segundo [8], os computadores necessitam ter acesso a coleções estruturadas de
informações (dados e metadados) e um conjunto de regras de inferência para
permitir um raciocı́nio automatizado. Em outros termos, precisamos de uma re-
presentação “inteligente” dos dados disponı́veis na web.

24
Os agentes inteligentes são programas que realizam buscas e processamentos
das informações disponı́veis, de forma a oferecer soluções “úteis” para determina-
dos problemas do usuário. Um agente inteligente poderia, por exemplo, marcar
uma consulta médica para o usuário, procurando o médico mais acessı́vel - em ter-
mos de proximidade e preço - e agendando uma consulta a partir de negociações
com o agente inteligente do médico. A web atual não permite tal independência
máquina-homem, necessária para efetuar operações com esse nı́vel de complexi-
dade.

Os agentes inteligentes devem ser capazes de identificar o significado exato


das palavras e as relações lógicas entre elas. Para que os computadores entendam
o conteúdo da web, é necessário que eles consigam acessar dados estruturados
e tenham conhecimento de conjuntos de regras que os ajudem a conduzir seus
raciocı́nios. As novas páginas da web terão de ser escritas então em uma nova
linguagem, que permita a compreenção uniforme por diversos sistemas. A espe-
cificação formal dos significados dos elementos da linguagem será feita através de
ontologias.

2.3.1 O que é ontologia

A ontologia define conceitos; todavia, o próprio conceito sobre ontologias pas-


sou por ligeiras modificações ao ser estudado por diferentes ramos da ciência.
Abaixo, mostraremos os diferentes conceitos sobre ontologia em diferentes ramos
da ciência.

Ontologia na filosofia: segundo Aristóteles, em Metafı́sica, a ontologia é


conhecida como a ciência da existência, uma disciplina da filosofia. Lida com a
natureza e a organização da realidade. A ontologia filosófica aborda temas como
“o que caracteriza um ser” e “o que é um ser”.

Ontologia na lingüı́stica: na lingüı́stica, a ontologia é uma tripla entre


a forma, o conceito e o referente. A forma é definida como o “canal” de re-
presentação da informação (ex. A seqüência de letras “Tanque de guerra”). O
conceito é definido como um conjunto das idéias relacionadas. O referente é a
entidade referenciada pela forma e conceito. Veja o esquema da figura 2.4 para
uma visualização abstrata.

Na visão do W3C, a ontologia é um artefato de engenharia, utilizada para


a criação da Web Semântica. Pode ser definida como uma ferramenta para es-
pecificação formal de significados e associações entre anotações/tags, utilizadas
em documentos Web. Adicionalmente, provê um vocabulário de termos, cujas
novas termologias podem ser formuladas através das existentes. A semântica
(significado) das entidades é especificada de modo formal e permite identificar
relacionamentos entre termos pertencentes a diversas ontologias.

25
Figura 2.4: Ilustração da tripla forma-conceito-referente.

Sua estrutura possui tipicamente dois componentes distintos:

• nomes dos conceitos importantes ao domı́nio, também conhecidos como


“classes”;
– Ex. Humano: conceito sobre membros de uma categoria de animais.
Adulto: conceito sobre seres vivos com idade maior do que um deter-
minado valor que depende da categoria do ser vivo. Humano Adulto:
conceito sobre humanos com mais de 20 anos.
• conhecimentos e restrições sobre o domı́nio, também conhecido como “pro-
priedades” .
– Ex. Nenhum Indivı́duo pode ser Adulto e Recém Nascido. Todos os
Humanos ou são Homens ou Mulheres. Um Humano Adulto Homem
tem em torno de 1,70m de altura.

A seguir, apesentaremos a linguagem OWL (Web Ontology Language) [32], re-


comendada pelo W3C como linguagem de descrição de ontologias na web semântica.

2.3.2 A Linguagem OWL - Web Onthology Language

É uma extensão da linguagem XML (Extensible Markup Language) e do voca-


bulário do RDF/RDFS (Resource Description Framework / Resource Description
Framework Schema)[5]. Acrescenta mais relações entre classes, como disjunção,
cardinalidade, igualdade, tipos mais ricos, propriedades simétricas ou transitivas;
sendo também basicamente composta pelas triplas (sujeito, predicado, objeto) do
RDF.

A estrutura se divide em:

• cabeçalho, que importa ontologias e declara informações sobre a versão;


• definição das classes, usando propriedades como equivalentClass, dis-
jointWith ou oneOf ;
26
• definição das propriedades, a partir de propriedades padrões como Tran-
sitiveProperty ou inverseOf.

• e a declaração dos fatos dos indivı́duos, que utiliza definições como


type para instanciação de classes2 .

Veja o apêndice A para um exemplo de cabeçalho e corpo em linguagem OWL.

A OWL define subconjuntos com restrições de acordo com a necessidade do


projetista da ontologia. Veja abaixo os subconjuntos da OWL.

2.3.2.1 OWL Full

É definido como a junção do DAML+OIL[4] com RDF. Possui grande expres-


sividade, podendo até considerar classes como indivı́duos. Entretanto, não há
garantia de computabilidade.

2.3.2.2 OWL DL (OWL Description Logic)

Inclui todas as construções da OWL, mas com algumas restrições que ga-
rantam computabilidade. É equivalente a uma subcategoria bastante conhecida
da lógica - a Description Logic - e essa equivalência traz grande entendimento
na semântica, propriedades formais, algoritmos de verificação, implementações e
otimizações; pois Description Logic já foi intensamente estudado.

2.3.2.3 OWL Lite

É um subconjunto de OWL-DL. Possui suporte imediato aos problemas de


hierarquia de classificação e cardinalidade binária (0 e 1). É uma ferramenta sim-
ples, sugerida para processos de migração de uma linguagem ontológica qualquer
para a OWL.

2.4 A necessidade de tratamento de incertezas


em ontologias

O processo geral de modelagem de uma ontologia funciona da maneira se-


guinte:

2
As instâncias de classes são chamadas de indivı́duos.

27
1. capturar do domı́nio todas as informações relevantes para a sua repre-
sentação;

2. as informações capturadas são categorizadas em objetos e propriedades;

3. adiciona-se algumas informações especiais para que os computadores possam


processar corretamente o domı́nio (claro, pois nem tudo que é de compre-
ensão imediata ao ser humano é compreensı́vel por uma máquina).

Modeladores de diferentes domı́nios de estudo estarão criando ontologias dessa


maneira, gerando assim uma diversidade de ontologias que descrevem um determi-
nado domı́nio. Posteriormente, os agentes inteligentes acessarão essas ontologias
para resolver os problemas dos seus “clientes” (que devem, a princı́pio, ser huma-
nos ou outros agentes).

Para que dois agentes inteligentes possam interagir, devem haver acordos so-
bre o tratamento dos conceitos, logo, devem compartilhar ontologias para que
haja uma uniformidade na interpretação nos descritores dos domı́nios. A solução
ideal para evitar incompatibilidades seria definir uma ontologia única que cobrisse
todas as áreas do conhecimento humano, porém, devido a impressionante escala
de informação que trafega atualmente no mundo, tal ontologia necessitaria de
um conjunto enorme de descritores, tornando a catalogação exaustiva; logo, seria
necessário um processo de automação de integração das ontologias. Além disso,
afirmações idênticas podem ter significados diferentes dependendo do domı́nio que
se está sendo tratado; logo, a integração das ontologias causará o surgimento de
contradições ou informações incertas.

De forma geral, as linguagens comuns de definição e manipulação de onto-


logias não podem tolerar a existência de contradições ou informações incertas,
pois tais informações seriam imediatamente consideradas como inconsistentes e
perderiam seu valor. O que ocorre é que certas informações inconsistentes são va-
liosas ou alguns domı́nios de conhecimento possuem sua própria natureza ligada
à incerteza (ex. Fı́sica Quântica ou Genética). Surgiu-se assim a necessidade de
representação e manipulação de ontologias incertas, que é um dos nossos objetos
de estudo.

Um exemplo de incerteza poderia ser ilustrado no problema de “grau de as-


sociação” abaixo. Imagine os seguintes axiomas simultaneamente presentes na
mesma ontologia.

Europa contém Rússia.


Ásia contém Rússia.
Ásia n~
ao contém Europa.
Europa n~ao contém Ásia.

28
Esse conjunto de axiomas gerará conflitos em ontologias convencionais (as que
não tratam incertezas), pois não foi tratado o “grau” da associação “contém”.
Ontologias convencionais tratam as informações de forma exclusiva (se é integral-
mente verdadeira ou integralmente falsa), não havendo a consideração do nı́vel
em que uma propriedade estaria ligada a uma outra. No caso acima, as primeiras
duas afirmações indicam que a Rússia está contida “integralmente” na Ásia e na
Europa (seja, que a Rússia está em um território em comum entre a Ásia e a
Europa); entretanto, as duas últimas afirmações indicam que não existe território
em comum entre a Europa e a Ásia, logo, a Rússia não existiria ou existiriam
duas Rússias!

Para contornar problemas como esse, associamos à relação “contém” um nu-


meral que indica em que grau a relação é válida para um mesmo objeto. É mais
intuitivo que esse numeral esteja entre 0 e 1, com o 0 indicando a invalidade da
relação e 1 indicando a validade completa da relação. O exemplo anterior com
a adição do indicador de grau de associação resultaria o exemplo abaixo. Por
questão de comodidade, representaremos o grau em percentagem.

Europa contém 20% da Rússia.


Ásia contém 80% da Rússia.
Ásia contém 0% da Europa.
Europa contém 0% da Ásia.
Com esse tipo de construção, é possı́vel modelar perfeitamente a situação em
que parte da Rússia pertença à Ásia e uma outra parte à Europa; mas que, por
sua vez, a Europa e a Ásia não tenham territórios em comum. Note que, neste
caso, devemos tomar cuidado para que a soma do “grau” da relação “contém”
sobre a Rússia deve totalizar em 1 (ou 100%). Esse controle deve ser feito pela
ferramenta de controle da ontologia ou manualmente pelo próprio administrador.

Outro problema que se imagina ocorrer em ontologias convencionais é o pro-


blema de informações incompletas. Esse tipo de situação ocorre quando instâncias
(indivı́duos) de classes são pesquisadas, mas algumas instâncias crı́ticas para ter-
minar a pesquisa não estão presentes.

Com condição acima, uma busca que trata essas instâncias geraria resultados
duvidosos, pois não haveria elementos que atenderiam a 100% do requisitado. O
modelo convencional somente considera os casos de requisitos “completamente
atendidos” ou “completamente falhos”; nesse caso, as instâncias que atendem
“parcialmente” aos requisitos deveriam ser eliminadas ou consideradas? Note que
se considerarmos as “parciais” como “completas”, as “parciais” que atenderam
a poucos requisitos serão tratadas com a mesma importância dos que atende-
ram mais requisitos; no caso contrário, se ignorarmos os resultados “parciais”,
informações preciosas serão desperdiçadas e a busca não seria eficaz.

Adicionalmente, problemas de confiabilidade da fonte de informação podem


surgir. Há a necessidade de ponderar informações através da credibilidade dessa
29
informação. Se não houver esse tipo de classificação das fontes de informação,
surgiriam afirmações contraditórias ou inconsistentes durante a integração de
múltiplas ontologias e cairemos no mesmo problema do “grau de associação”,
mostrado inicialmente nesta seção.

Devemos descartar completamente as informações desconfiáveis ou tratá-las


somente como menos confiáveis? Note que a abordagem convencional teria de des-
cartar as informações contraditórias ou inconsistentes para manter a qualidade
da ontologia, enquanto que a abordagem com o tratamento de incertezas poderia
incorporar essa informação categorizando-a como menos (ou mais) confiáveis do
que as outras informações que entraram em choque.

Ex.: Na Bioinformática, é comum ponderarmos os resultados do empare-


lhamento de genes baseando-se nos resultados previstos pela teoria testada ou
considerando-se os resultados obtidos anteriormente. Para piorar a situação das
ontologias convencionais, há a incerteza herdada da linguagem de representação.
Isso ocorre em definições e conceitos vagos, que freqüentemente ocorrem na nossa
linguagem natural. Veja os exemplos abaixo.

O dia 08/09/2006 foi "frio".


Mostre-me os dias "quentes" deste ano.

O termo “frio” e “quente” indicam um conjunto que não está semanticamente


definido de forma absoluta, seja, não há uma divisória concreta que separa es-
ses conjuntos nem uma descrição formal sobre quais elementos estão contidos no
“frio” ou no “quente”. Um determinado elemento pode estar parcialmente incluso
no conjunto “frio” e “quente”, mas raramente estará contido “totalmente” em um
deles e nunca totalmente em ambos.

Em tratamentos convencionais, não há como representar “inclusão parcial”,


pois recai ao mesmo problema do “grau de associação”.

A Uncertainty Reasoning for the World Wide Web Incubator Group[29], um


grupo incubado pelo W3C, está em contı́nuo estudo na determinação de soluções
para tratamento de incertezas em tecnologias World Wide Web. A linguagem PR-
OWL (vide Seção 3.5), com sua abordagem probabilı́stica, está sendo referenciada
como uma das possı́veis abordagens.

2.4.1 Justificativa da abordagem probabilı́stica em onto-


logias

A abordagem probabilı́stica baseia-se nas teorias da probabilidade para a re-


presentação de incertezas em uma ontologia. A probabilidade está intimamente
relacionada com a freqüência, crença, ocorrência ou relações de causa e efeito
sobre um evento. Podemos aplicar diversos conceitos da teoria do conjunto para
30
o tratamento de probabilidades.

A representação é feita através de numerais com valores dentro do intervalo


fechado entre 0 e 1. O processo de validação e inferência é feita basicamente com
o auxı́lio de modelos bayesianos. Um exemplo é a PR-OWL, linguagem tratada
na Seção 3.5 como proposta de extensão da OWL para a incorporação de trata-
mento de incerteza por uso de probabilidades. A representação de incerteza da
PR-OWL segue o formalismo MEBN.

As razões que podem justificar o uso da abordagem probabilı́stica são muitas.


Dentre elas, podemos citar as seguintes:

• A abordagem probabilı́stica possui o domı́nio limitado de valores possı́veis


[0,1].

• Possui propriedades bem definidas e predizı́veis matematicamente.

• Possui restrições suficientes para manter o resultado computável.

• É semanticamente bem definida.

• Intimamente ligada à “freqüência” ou “chance” de ocorrência; seja, está li-


gada à estatı́stica, a observação dos fatos; logo, abstrai-se a capacidade de
atualização das ontologias através da observação dos fatos.

• Comparado ao modelo fuzzy, pode ser mais facilmente estendido a domı́nios


maiores, pois sua semântica é definida e a lógica fuzzy representa um con-
ceito relativamente restrito de incerteza (o “vago”).

• Desde que uma informação represente somente um (1) “significado” em um


determinado momento, a probabilidade representa melhor a realidade do
que a lógica fuzzy. Ilustrando esse exemplo, informações ambı́guas com
50% de validade indicam que uma das interpretações é válida com 50% de
chance (mas que somente uma das interpretações da instância será válida
em um determinado momento).

• Como comparação, o “0.5” na lógica fuzzy indica que uma instância está
“meio” verdadeira e “meio” falsa simultaneamente, enquanto que na pro-
babilı́stica ele indica que a instância fará parte da verdade na metade das
ocasiões observadas (ou com a metade da chance total) - no final, a instância
pertencerá a somente um dos conjuntos, nunca em ambos.

31
Uma linguagem de representação de ontologias não possui valor prático sem
um modelo computacional de edição e inferência. O UnBBayes-MEBN realiza
uma implementação de editor e máquina de inferência para a PR-OWL, linguagem
de ontologia probabilı́stica.

32
Capı́tulo 3

Estado da arte

Conceitos recentes são muitas vezes referenciados como estado da arte. Este
capı́tulo apresentará o formalismo MEBN e a linguagem PR-OWL, novidades que
estendem tecnologias bastante conhecidas, como redes bayesianas e ontologias
OWL.

3.1 MEBN - Redes Bayesianas Multi-Entidade

Redes bayesianas Multi-Entidades (MEBN) são uma extensão das Redes baye-
sianas (BN), através da inclusão da Lógica de Primeira Ordem (FOL). O domı́nio
de conhecimento em MEBN é expresso por MEBN Fragments (ou MFrags), que
são organizadas em MEBN Theories (ou MTheories). Uma MTheory é um con-
junto de MFrags que satisfaz determinadas condições de consistência, que garan-
tem a existência de uma distribuição de probabilidade conjunta única sobre suas
variáveis aleatórias [26].

Um MFrag representa uma distribuição de probabilidade condicional de suas


variáveis aleatórias residentes, dados os valores das instâncias de seus pais no
grafo. Para que essa distribuição se aplique, as restrições de contexto do domı́nio
devem ser satisfeitas. Um conjunto de MFrags representa uma distribuição de pro-
babilidade conjunta sobre um determinado número de instâncias de suas variáveis
aleatórias, que são instanciadas dinamicamente [16].

De forma radical, pode-se dizer que a MEBN é um template para a geração


automática de Redes bayesianas de Situações Especı́ficas (SSBN - Situation Spe-
cific Bayesian Network ) a partir da entrada de dados (evidências) pelo usuário.
As SSBN são equivalentes às redes bayesianas convencionais e representam o
domı́nio da MEBN em um determinado momento especı́fico. Algoritmos usados
pelo UnBBayes-MEBN para a geração de SSBN estão descritos no capı́tulo 6.

As seções seguintes utilizarão a ontologia StarTrek, descrita na Seção 8.1, para


ilustrar e exemplificar o formalismo MEBN.

33
3.2 MFrags

MEBN representa o domı́nio de conhecimento através de conjuntos de MFrags.


MFrags são compostos por nós (ou variáveis aleatórias), que representam as carac-
terı́sticas e os relacionamentos das entidades do domı́nio; e por arcos direcionados,
que representam relacionamentos entre esses nós.

Como já foi dito, um MFrag representa uma distribuição de probabilidade


condicional das instâncias de suas variáveis aleatórias, dados os valores de seus
pais, contanto que os nós de contexto sejam satisfeitos. A Figura 3.1 representa
o nı́vel de perigo a que uma determinada nave é exposta.

Figura 3.1: Figura exemplo de MFrag

Esse MFrag possui oito nós: cinco de contexto, dois de entrada e um residente.

Nós de contexto são variáveis booleanas que representam condições que de-
vem ser satisfeitas para que a distribuição de probabilidade dos nós residentes de
aplique. Seus valores possı́veis são:

• True, quando a condição é satisfeita;

• False, quando a condição não é satisfeita;

• Absurd, quando uma expressão não tem sentido algum. Ocorre geralmente
quando um valor é avaliado com parâmetros não previstos ou inválidos.
34
Nós de entrada são variáveis que influenciam a distribuição de probabilida-
des dos nós residentes, mas as suas distribuições estão definidas nos seus próprios
MFrags. Ou seja, em uma MTheory consistente, se em um MFrag existe um nó
de entrada, então é necessário que exista um outro MFrag em que esse nó seja
residente, para que sua distribuição de probabilidades seja bem definida.

Nós residentes possuem as distribuições locais de probabilidades. Neles


estão definidas as dependências probabilı́sticas dos valores de seus pais (que po-
dem ser tanto nós de entrada quanto outros nós residentes). Em uma MTheory
completa, cada variável aleatória possui apenas um home MFrag, onde sua dis-
tribuição local é definida1

Um nó pode ter uma lista de argumentos entre parênteses. Esses argumentos
são substituı́dos por identificadores únicos 2 das entidades do domı́nio de conhe-
cimento quando uma rede é instanciada. Duas entidades distintas não podem ter
o mesmo identificador único.

Na Figura 3.1, observou-se que os valores dos estados dos nós não foram mos-
trados no grafo de MFrag. Isso porque um MFrag é apenas um template, ou
seja, ele não representa variáveis aleatórias individuais, mas sim uma classe de
variáveis aleatórias que podem existir na SSBN. Os valores reais dos estados só
são concretizados em uma instanciação de MFrag.

A especificação da MEBN não define padrões para declarar a CPT em um


nó de um MFrag [16]. No UnBBayes-MEBN, utilizamos um pseudo-código para
declarar as CPT para uma classe de variáveis aleatórias. Abaixo, o pseudo-código
é utilizado para ilustrar a distribuição da variável DangerToSelf(s,t) no âmbito
da MEBN.

if any st have ( OperatorSpecies = Cardassian


& HarmPotential = true ) [
Un = .90 + MIN( .10 ; .025 * CARDINALITY (st) ) ,
Hi = ( 1 - Un ) * .80 ,
Medium = ( 1 - Un ) * .20 ,
Low = 0
] else if any st have ( OperatorSpecies = Romulan
& HarmPotential = true ) [
Un = .70 + MIN( .30 ; .03 * CARDINALITY (st) ) ,
Hi = ( 1 - Un ) * .60 ,
Medium = ( 1 - Un ) * .30 ,
Low = ( 1 - Un ) * .10
] else if any st have ( OperatorSpecies = Unknown
& HarmPotential = true ) [
Hi = .50 - MIN (.20 ; .02 * CARDINALITY (st) ) ,

1
Seja, a lógica MEBN padrão não suporta polimorfismo de variáveis aleatórias, já que uma
variável aleatória só pode estar definida 1 vez.
2
Na documentação original em [26], por convenção, esses identificadores começam por ponto
de exclamação.

35
Un = ( .50 - Hi ) ,
Medium = .50 - MIN (.20 ; .02 * CARDINALITY (st) ),
Low = (.50 - Medium)
] else if any st have ( OperatorSpecies = Klingon
& HarmPotential = true ) [
Un = .10 ,
Hi = .15 ,
Medium = .15 ,
Low = .60
] else if any st have ( OperatorSpecies = Friend
& HarmPotential = true ) [
Un = 0 ,
Hi = 0 ,
Medium = .01 ,
Low = .99
] else [
Un = 0 ,
Hi = 0 ,
Medium = 0,
Low = 1
]

Esse pseudo-código define a distribuição local para o perigo em que uma nave
é submetida devido a todas as naves que influenciam o seu nı́vel de perigo. Essa
distribuição leva em conta o número de naves, que não é previamente conhecido.

A Default Distribution - distribuição padrão declarada na porção else do


pseudo-código - está presente para o caso em que não exista, nos dados forne-
cidos pelo usuário, instâncias dos pais - HarmPotential(st,t) e OpSpec(st) -
que satisfaçam a validade dos nós de contexto de MFrag. Nesse caso; a distri-
buição padrão, que não faz referência a nenhum estado dos pais, é utilizada.

3.3 Recursividade em MEBN

Para aplicações da vida real, é importante que um modelo de probabilidade


condicional tenha possibilidade de representação recursiva. Entretanto, uma das
grandes limitações das redes bayesianas é a falta do suporte a recursividade, pois
uma rede bayesiana deve ser um grafo acı́clico. MEBN fornece suporte a de-
finições de recursão bem gerais. A Figura 3.2 apresenta um MFrag em que a
recursão está presente.

Observa-se que, para que as distribuições dos nós residentes se apliquem, é


necessário que z seja uma zona (Zone) e que st seja uma nave. Além disso, st
precisa estar localizada na zona z.

A recursão apresentada na Figura 3.2 é a temporal. Para que as distribuições


se apliquem, ambos t e tprev precisam ser perı́odos de tempo (entidades TimeS-
tep) e, além disso, tprev precisa ser um tempo anterior a t. Essa definição de
ordem, indicando que t vem “depois” de tprev, é implementada no UnBBayes-
MEBN através da definição nativa de ordem de entidades. Se uma entidade (ou,
por convenção, podemos chamá-lo de tipo) for declarada como ordenável, todas as

36
suas instâncias (valores possı́veis) possuirão ordem total. Com isso, torna-se des-
necessária a criação de nós para a obtenção do tempo anterior (por exemplo, não
é mais necessário criarmos um nó P rev(t), que retorna uma instância anterior a t).

Outros tipos de recursão também são representados em MEBN por MFrags


que permitem influências entre instâncias do mesmo nó residente. É necessário
que, ao se permitir definições de recursão, garanta-se que uma variável aleatória
não possa influenciar a sua própria distribuição de probabilidade, pois senão a
BN representável por esse template poderia ser um grafo cı́clico, desrespeitando
um dos requisitos de uma BN [26].

Os nós de entrada de um MFrag podem incluir instâncias de nós definidos re-


cursivamente no próprio MFrag. Por exemplo, o nó de entrada DistFromOwn(st,
tprev) representa a distância da espaçonave st à minha espaçonave no perı́odo
de tempo anterior ao t; e esse nó influencia a distância atual, dado pela variável
DistFromOwn(st, t). A recursão precisa de uma distribuição de probabilidades
no perı́odo incial (que, por convenção, chamamos de T 0), que não dependa de
um distúrbio anterior, para que não tenhamos um laço infinito. No UnBBayes-
MEBN, isso é garantido pelo fato de sempre existir um elemento mı́nimo em
entidades ordenáveis3 .

A Figura 3.3 mostra como as definições de recursividade podem ser aplicadas


para construir um SSBN (Situation-Specific Bayesian Network, ou rede bayesi-
ana de situação especı́fica). Nesse caso, deseja-se saber o potencial de dano no
perı́odo de tempo T3 da espaçonave ST4.

O processo de construção do grafo mostrado na Figura 3.3 começa criando-se a


instância de MFrag no nó HarmPotential(ST4,T3), que é o nó cuja distribuição
deseja-se conhecer. Instanciam-se, então, as variáveis aleatórias que sobraram,
para as quais os nós de contexto estão satisfeitos. A seguir, são construı́das as
CPT que podem ser obtidas com os dados já disponı́veis. Os passos para cons-
trução de SSBN são detalhados no capı́tulo 6.

Note que seria fácil especificar um conjunto de MFrags com influências cı́clicas,
ou um conjunto tendo distribuições conflitantes para uma variável aleatória em
diferentes MFrags. Na geração de SSBN, o UnBBayes-MEBN notifica o usuário
em caso de existência desses tipos de falhas.

3.4 MTheories

Para construir um modelo coerente, é necessário que o conjunto de MFrags


satisfaça coletivamente condições de consistência, garantindo a existência de uma
distribuição de probabilidades conjunta única sobre as instâncias das variáveis
3
A ordem total implica a presença de um elemento mı́nimo, garantindo que a recursividade
pare

37
aleatórias de MFrags. Esse conjunto coerente de MFrags é chamado de teoria
MEBN, ou MTheory.

Uma MTheory representa uma distribuição de probabilidade conjunta única


sobre um número (que pode tender ao infinito) de instâncias de suas variáveis
aleatórias. Essa distribuição é especificada pelas distribuições local e padrão de
cada MFrag. Esses MFrags são parte de uma MTheory, que resume as regularida-
des estatı́sticas que caracterizam o domı́nio. Essas regularidades são capturadas
e codificadas em uma base de conhecimento por um especialista ou aprendido por
observação.

Cada variável aleatória deve ter um único home MFrag. Além disso, uma
MTheory válida deve garantir que todas as definições de recursão terminem em
passos finitos e não contenham influências circulares. Ferramentas computacio-
nais devem permitir essa verificação de consistência4 .

Para que uma MTheory raciocine sobre situações particulares, é necessário


informar o sistema sobre instâncias que estão envolvidas em uma determinada
situação.

A inferência bayesiana pode ser usada tanto para responder a perguntas de


interesse (chamadas de query) quanto para refinar uma MTheory (através de fin-
dings, ou evidências).

Findings é o mecanismo básico para incorporar novas informações em MThe-


ories. Eles são representados por MFrags de apenas dois nós: um de entrada e um
residente. Assim, MEBN tem a capacidade de incorporar novos axiomas quando
novas evidências surgem, atualizando as distribuições de todas as variáveis en-
volvidas na situação especı́fica. São equivalentes à adição de um novo axioma na
lógica de primeira ordem.

A lógica MEBN contém um conjunto de built-in MFrags (ou seja, MFrags


presentes em qualquer situação criada, que incluem quantificadores, referência
indireta e MFrags booleanos que representam conectivos, como “AND” e “OR”),
que dão ao sistema a habilidade de representar qualquer sentença da lógica de
primeira ordem.

A Figura 3.4 mostra um diagrama de uma MTheory que foi utilizada para a
modelagem da ontologia StarTrek, apresentada na Seção 8.1.

A MFrag Entity Type é usada para declarar tipos de entidade que podem ser
encontradas no modelo. Como MEBN não é um sistema tipado, é necessária a
criação desse tipo de MFrag quando se deseja construir um sistema tipado. Esse
4
O UnBBayes-MEBN realiza essa verificação em dois passos: estaticamente - garantindo
que o editor não permita a inserção de variáveis inconsistentes - e dinamicamente - realizando
o teste de consistência na etapa de instanciação

38
MFrag define uma estrutura bem simples de tipagem, porém MEBN pode ser
estendida para acomodar qualquer mecanismo de sistema tipado; inclusive poli-
morfismo5 .

Vale notar que existem inúmeras maneiras de se representar uma MTheory.


Por exemplo, podemos criar uma nova MTheory equivalente através de divisão das
grandes MFrags presentes naquela MTheory em MFrags menores. Esse processo
de divisão de um MFrag é conhecido como fragmentação [15].

3.5 Uma ontologia probabilı́stica - PR-OWL

Proposta por Paulo Costa em 2005 [15] [17], a PR-OWL é uma linguagem de
representação de ontologias que estende a famosa linguagem OWL para suporte à
representação de incertezas. Permitirá a interoperabilidade entre ontologias con-
vencionais com as novas ontologias probabilı́sticas, mas necessita de ferramentas
especiais para o processamento da sintaxe adicional6 . Esta linguagem foi proje-
tada para representar diversos modelos bayesianos complexos.

A lógica por trás de PR-OWL se baseia em Redes bayesianas Multi-Entidade7


(MEBN) [26]. Essa linguagem pode definir a distribuição de probabilidade sobre
modelos de qualquer teoria FOL axiomatizável, sendo enorme sua expressividade
e sua liberdade. Como conseqüência, a PR-OWL pode ser considerada uma de-
rivação da OWL-Full e não há garantia de sua computabilidade [17].

Por ser compatı́vel com OWL, o modelador pode utilizar os recursos novos da
PR-OWL apenas para as partes da ontologia que necessitarem de suporte pro-
babilı́stico. As partes probabilı́sticas da ontologia devem formar uma MTheory
válida.

Por ser baseada na FOL, a PR-OWL não garante que as queries efetuadas
sejam tratáveis. Na OWL ocorre o mesmo problema e, no exemplo da OWL, fo-
ram criadas três versões diferentes da linguagem, com crescente poder expressivo,
desenhadas para uso por comunidades especı́ficas de desenvolvedores e usuários
(refiro-me à OWL-Full, OWL-DL e OWL-Lite). Seguindo o mesmo princı́pio,
uma restrição da PR-OWL poderia ser criada (digamos, um PR-OWL Lite) [17].

A Figura 3.5 mostra os principais conceitos envolvidos na definição de uma


MTheory em PR-OWL. No diagrama, as elipses representam as classes gerais,
enquanto que os arcos representam os principais relacionamentos entre as classes.
Uma ontologia probabilı́stica deve ter ao menos um indivı́duo da classe MThe-
5
O UnBBayes-MEBN, para a simplificação da verificação de consistência, utiliza nativamente
um sitema de tipagem forte, forçando que qualquer entidade tenha tipo associado.
6
O UnBBayes-MEBN é pioneira no tratamento da PR-OWL.
7
A estruturação da PR-OWL segue o mesmo raciocı́nio da MEBN, inclusive o fato do domı́nio
ser representado em MFrags.

39
ory, sendo que este é ligado com um grupo de MFrags que coletivamente formam
uma MTheory válida. MFrags são compostos por nós, sendo que estes podem
ser residentes, de contexto, ou de entrada. Cada indivı́duo da classe N ode é
uma variável aleatória e esta possui um conjunto mutuamente exclusivo e co-
letivamente exaustivo de possı́veis estados. Cada variável aleatória possui uma
distribuição de probabilidade condicional ou incondicional [17].

A Figura 3.6 mostra uma versão cobrindo os elementos principais da PR-


OWL, suas subclasses e os elementos secundários necessários para representar
MTheory e as relações que são necessárias para expressar a estrutura complexa
dos modelos probabilı́sticos bayesianos usando a sintaxe da OWL. Para uma des-
crição detalhada da PR-OWL, veja apêndice B.

As tabelas de probabilidade condicional da PR-OWL no UnBBayes podem


ser declaradas respeitando-se a gramática descrita na Seção 4.1.3.4.

Construir MFrags e todos os seus elementos em uma ontologia probabilı́stica


é um processo cansativo e sujeito a erros, exigindo um conhecimento profundo
da estrutura de dados da PR-OWL. Torna-se necessário o desenvolvimento de
um software que permite uma modelagem visual, ou um plugin para alguma
das ferramentas bayesianas existentes. O módulo UnBBayes-MEBN, referenciado
neste documento nos capı́tulos 4 e 5, possui funcionalidades de edição de arquivos
PR-OWL, permitindo que a MTheory seja salva neste formato, fornecendo ao
modelador um meio visual, intuitivo e guiado para a construção das ontologias
probabilı́sticas.

40
Figura 3.2: Um MFrag recursivo [15]

41
Figura 3.3: Modelagem de uma situação recursiva

42
Figura 3.4: Conjunto de MFrags que formam uma MTheory [15]

43
Figura 3.5: Principais conceitos da PR-OWL [17]

Figura 3.6: Elementos de uma ontologia probabilı́stica PR-OWL [17]

44
Capı́tulo 4

Arquitetura geral do UnBBayes

Figura 4.1: Logotipo do UnBBayes.

O UnBBayes é um framework implementado pelo Grupo de Inteligência Ar-


tificial da Universidade de Brası́lia [25], inicialmente desenvolvido em Delphi e
posteriormente em Java, para suporte ao raciocı́nio probabilı́stico. Possui um
editor visual de fácil uso, permitindo que o usuário construa, de forma intuitiva,
redes bayesianas, diagramas de influência e redes bayesianas múltiplas secionadas,
além da entrada e propagação de evidências, realização de inferência probabilı́stica
e aprendizagem da topologia e/ou parâmetros de uma BN. O framework está em
constante desenvolvimento, desde o ano 2000.

Atualmente, o software é distribuı́do gratuitamente para uso não comercial,


sob a licença GNU-GPL versão 3. API e documentação em JavaDoc são disponi-
bilizadas para desenvolvedores, possibilitando que os interessados em raciocı́nio
probabilı́stico possam utilizar funcionalidades do UnBBayes em suas aplicações.

O principal ambiente de desenvolvimento do UnBBayes foi, e continua sendo, o


Eclipse [20], dado seus diversos plugins para facilitar a criação e testes das funcio-
nalidades. Ultimamente, o UnBBayes foi estendido para permitir a representação
de ontologias probabilı́sticas e a realização de inferências em PR-OWL/MEBN,
resultando o UnBBayes-MEBN. O trabalho atual realiza diversas otimizações e
correções sobre esse novo módulo.

45
4.1 Visão arquitetural do UnBBayes

A arquitetura aqui apresentada visa apenas fornecer uma noção abstrata do


programa, não entrando em detalhes muito internos. O leitor interessado em estu-
dar e utilizar a API encontrará a documentação JavaDoc e o código na página do
UnBBayes[9]. Contribuições deste trabalho na arquitetura do UnBBayes-MEBN
também podem ser encontrados nos capı́tulos 5 e 7.

Os pacotes que compõem o software são os seguintes:

pacote aprendizagem, reúne as classes relacionadas ao processo de aprendiza-


gem em lote;
pacote controller, classes responsáveis por controlar o fluxo de operações re-
alizadas pelo usuário, fazendo a ligação entre a GUI e as funcionalidades;
pacote gui, contém as classes que implementam a interface com o usuário, per-
mitindo a visualização e manuseio das redes bayesianas;
pacote io, classes responsáveis por salvar as redes bayesianas em arquivos, bem
como por construı́-las novamente a partir destes arquivos. Há atualmente
dois formatos válidos: o formato “net” e o formato “xmlbif”;
pacote montecarlo, conjunto de classes para gerar amostras aleatórias de redes
bayesianas dadas como parâmetro;
pacote prs, classes que definem a estrutura das redes bayesianas e implementam
os algoritmos de inferência sobre estas;
pacote util, classes utilitárias, utilizadas por pelo menos dois pacotes do pro-
jeto.

O projeto UnBBayes oferece algumas branches adicionais voltadas para ob-


jetivos especı́ficos, permitindo o tratamento de necessidades não resolvidas pelo
framework principal. Por exemplo:

branch UnBMiner, projeto voltado para data-mining. Fornece uma forte ferra-
menta para análise de dados no modelo CRISP-DM [2].
branch Metaphor, interface adicional para usuários comuns no tratamento de
BN. Oferece somente funcionalidades de leitura, não oferecendo funciona-
lidades de edição de redes bayesianas. Veja Seção 9.5 para a nova versão,
voltada para o projeto de identificação humana.

Segue nas próximas seções algumas funcionalidades que o UnBBayes oferece.

46
4.1.1 Diagramas de influência e redes bayesianas

A modelagem apresentada na Figura 4.2 apresenta as principais classes que


implementam as redes bayesianas e diagramas de influência no UnBBayes.

Classe Node, um nó genérico que possui estados ( String ), uma posição (x,y) e
um tamanho (largura, altura). Estes dois últimos campos são representados
pela classe SerializablePoint2D.

Classe abstrata TreeVariable, para variáveis que serão visualizadas na árvore


de nós e estados com suas respectivas probabilidades no painel de com-
pilação e inferência de redes probabilı́sticas.

Figura 4.2: Modelagem de classes para BN e ID.

As classes que representam variáveis estão diretamente dependentes de clas-


ses de representação visual. Isso é um ponto fraco na modelagem atual, que
compromete na separação de lógica com modelos visuais. Os tipos de variáveis
atualmente suportados pelo UnBBayes são as variáveis aleatórias, as variáveis de
decisão e as funções utilidade, sendo estas duas últimas utilizadas para a mode-
lagem de grafos de decisão.

Classe DecisionNode: variável de decisão.

Classe ProbabilisticNode: variável probabilı́stica.

Classe UtilityNode: função utilidade.


47
Classe Edge: representa um arco ligando dois nós.

Classe PotentialTable: tabela de potencial que possui os valores das células


como um número real entre 0 e 1 (propriedade dados que é uma coleção de
números reais representados pela classe FloatCollection).

Classe ProbabilisticTable: tabela de potencial de probabilidades.

Classe UtilityTable: tabela de potencial de utilidade.

Interface ITabledVariable: interface para variáveis com tabela para definição


dos valores associados aos estados possı́veis (as variáveis probabilı́sticas e
as de utilidade).

Classe Network: representa um grafo genérico.

Classe SingleEntityNetwork: representa uma rede que não possui


multi-entidades.

Classe ProbabilisticNetwork: representa uma rede probabilı́stica.

A classe ArrayList<Node>, classe padrão da linguagem Java, substitui a an-


tiga NodeList. Essa substituição é fruto de refatoração, que foi resultante da
análise de desempenho relatada na Seção 7.1, na tentativa de resolver problemas
de segurança na execução em multi-thread. A classe NodeList era utilizada pelas
seguintes classes:

• Network, para armazenar seus nós;

• SingleEntityNetwork, para armazenar a ordem de eliminação dos nós;

• Node, para armazenar os nós pais, filhos e adjacentes;

• PotentialTable, para armazenar as variáveis que pertencem à tabela (não


apresentada no modelo, para facilitar seu entendimento).

4.1.2 Redes bayesianas múltipla-seccionadas

A Figura 4.3 apresenta a modelagem das classes que implementam MSBN (re-
des bayesianas múltipla-seccionadas) no UnBBayes. A MSBN divide um domı́nio
modelado em rede bayesiana em sub-redes, preservando os subdomı́nios naturais
existentes. O resultado final da inferência deve ser o mesmo que seria obtido com
a rede bayesiana formada pela união das sub-redes.

Segue abaixo descrições das classes ilustradas no diagrama UML da Figura


4.3.

48
Figura 4.3: Modelagem de classes para MSBN.

Classe SubNetwork, sub-rede de uma rede múltipla seccionada.

Classe Linkage, possui os nós que ligam duas sub-redes.

Classe AbstractMSBN, define os métodos para tratar as MSBN.

Classe MultiAgentMSBN, uma rede múltipla seccionada multi-agente.

Classe SingleAgentMSBN, uma rede múltipla seccionada.

4.1.3 Modelagem geral da versão inicial do UnBBayes-


MEBN

Segue a descrição das principais classes construı́das na extensão inicial do


UnBBayes para suporte à MEBN. A Seção 4.1.3.1 seguinte apresentará as princi-
pais classes utilizadas para a representação de uma MTheory. Na Seção 4.1.3.2,
serão detalhadas as estruturas de um MFrag e os relacionamentos dos nós.

4.1.3.1 MTheory

O diagrama de classes em UML da Figura 4.4 representa a estrutura geral de


uma MTeoria tratada pelo UnBBayes-MEBN.

Classe MultiEntityBayesianNetwork: representa uma MTheory, a qual define


a ontologia do domı́nio. A teoria é composta por um ou mais MFrags.

49
Figura 4.4: Modelagem de classes para MTheory

Classe MFrag: representa um fragmento de MEBN (MFrag). MFrag é composta


virtualmente por variáveis ordinárias, nós de entrada, nós de contexto e nós
residentes.

Classe OrdinaryVariable: variáveis ordinárias são utilizadas para se referir a


entidades que entrarão como argumentos nas variáveis aleatórias (Random
Variable - RV) de MFrags. Cada argumento de uma RV em MFrag exige
um objeto da classe OrdinaryVariable, sendo que este está associado com
o tipo das entidades aceitas para preencher aquele parâmetro. Por questão
de conveniência, o UnBBayes representa OrdinaryVariable como um nó
de contexto IsA(Type) 1 , especialização de Node. Possui escopo interno a
MFrag.

Classe InputNode: classe que representa uma RV de entrada. É basicamente


uma referência para um ResidentNode, que é usado como entrada em um
MFrag. Apesar de não estar mostrada no diagrama UML, utiliza uma classe
ResidentNodePointer para desacoplar com ResidentNode.

Classe ResidentNode: classe que representa uma RV residente. Possui informações


sobre seus argumentos ( OrdinaryVariable ) e a declaração do pseudo-
código que define uma tabela de probabilidade condicional (CPT). Possui
escopo global à MTheory2 .

Classe BuiltInRV: classe que representa variáveis aleatórias nativas ao UnB-


Bayes3 , previamente construı́das para facilitar a modelagem de MEBN.
Permitem representar uma famı́lia de distribuições de probabilidade sobre
1
Já que no UnBBayes todas as entidades devem ser tipadas, e essa associação de tipos deve
ser declarada como um nó de contexto IsA, resolveu-se juntar esses dois conceitos em um só.
2
Apesar de não ser mostrada no diagrama UML, a MultiEntityBayesianNetwork referencia
os conjuntos de ResidentNode que existem na MTheory.
3
Conectivos lógicos, quantificadores e igualdade.

50
interpretações da FOL. A Tabela 4.1 apresenta as BuiltInRV que estão im-
plementadas no UnBBayes.

And EqualTo Exists ForAll


Iff Implies Not Or
Tabela 4.1: BuiltInRV implementadas no UnBBayes.

4.1.3.2 MFrag

O diagrama da Figura 4.5 ilustra os principais elementos de um MFrag.


O UnBBayes somente lida com MFrags de domı́nio4 , que funcionam como um
template para a geração de uma SSBN, baseado nas instâncias de entidades e
evidências presentes na base de conhecimento que ilustra uma situação especı́fica.

Figura 4.5: Modelagem de classes para MFrag.

Classe MFrag: representa um MFrag, utilizada como template para a instan-


ciação da SSBN de acordo com as evidências, instâncias de entidades presen-
tes e os questionamentos do usuário. Representa a modelagem do domı́nio
(através de ontologia probabilı́stica). É composta pelos nós de contexto
(ContextNode), pelos nós de entrada (InputNode) e pelos nós residentes
(ResidentNode). Para possibilitar a geração da SSBN, esse MFrag possui
uma referência para as instâncias OVInstance5 .
4
MFrags para Findings são representados por declarações em FOL.
5
Composta por um par de uma variável ordinária e uma instância de entidade, representando
um valor especı́fico que OrdinaryVariable está assumindo em um determinado momento.

51
Classe RandomVariableFinding: representa as evidências existentes para um
determinado nó. Essa informação é utilizada para a geração da SSBN.

Veja também a Seção 7.2 para as refatorações realizadas nas classes que repre-
sentam MFrag. A Figura 4.6 apresenta a hierarquia dos tipos de nós existentes
na MEBN.

Figura 4.6: Modelagem de classes para os nós de uma MEBN.

Classe MultiEntityNode representa um nó de uma MEBN, podendo ser resi-


dente, de entrada ou de contexto, conforme sua subclasse.
Classe Entity representa uma entidade.
Classe StateLink representa uma vinculação entre o DomainResidentNode e
Entity, possibilitando a definição de exclusividade global, explicado com
mais detalhes na Seção 4.1.3.3.
Classe Argument representa um argumento de um determinado MultiEntityNode.
Esta classe é utilizada apenas no processo de armazenamento e carrega-
mento de arquivos PR-OWL. O argumento pode ser complexo, através do
uso das propriedades entityTerm e argumentTerm, ou simples, através da
propriedade oVariable.
Classe ResidentNodePointer representa uma ligação do nó de entrada ou do nó
de contexto, através da propriedade node, ao nó residente correspondente,
através da propriedade residentNode.
Classe ContextNode representa os nós de contexto, que fazem restrições às enti-
dades utilizadas como argumentos nas RV de entrada e residentes do MFrag
em questão.
52
Classe InputNode representa os nós de entrada. Estes nós são apenas uma re-
ferência para DomainResidentNode já existente, que geralmente se encontra
em outro MFrag, mas em algumas situações, é definido no mesmo MFrag,
para representar recursão, por exemplo.

Classe ResidentNode representa os nós residentes geradores. Estes nós possuem


um pseudo-código, responsável por definir a regra de criação de uma CPT,
independentemente do caso especı́fico (entidades e evidências presentes). A
Seção 4.1.3.4 apresenta mais detalhes a respeito do pseudo-código e geração
de CPT. Os nós residentes podem ter como pais ou outros nós residentes6
ou nós de entrada.

4.1.3.3 Exclusividade global

Existe um conceito conhecido como exclusividade global de um determinado


estado de um nó (vide Seção 4.1.3.3), incorporado à PR-OWL na versão 1.05
(www.pr-owl.org). Essa propriedade é necessária em situações que apenas uma
evidência é permitida para um nó em um determinado estado. Por exemplo, no
MFrag Starship Data apresentada na Figura 4.7, o estado True para a variável
IsOwnStarship(st ) só é permitido para uma espaçonave st . Ou seja, o estado
True tem exclusividade global em relação à RV IsOwnStarship(st ).

4.1.3.4 Tabela de Probabilidades

A proposta original da linguagem PR-OWL apresentada em [15] não contém


uma especifição formal para fórmulas capazes de definir dinamicamente a CPT
dos nós residentes instanciados durante a geração da SSBN. Essa funcionalidade
seria essencial quando o número de pais é desconhecido. O UnBBayes-MEBN
utiliza um compilador de pseudo-código próprio para a geração dinâmica de ta-
belas. A gramática formal, definida em notação BNF, é apresentada abaixo:

table := statement | if_statement


if_statement
::=
"if" allop varsetname "have" "(" b_expression ")" statement
"else" else_statement
allop ::= "any" | "all"
varsetname ::= ident ["." ident]*
b_expression ::= b_term [ "|" b_term ]*
b_term ::= not_factor [ "&" not_factor ]*
not_factor ::= [ "~" ] b_factor
b_factor ::= ident "=" ident
else_statement ::= statement | if_statement
statement ::= "[" assignment "]"
assignment ::= ident "=" expression [ "," assignment ]*
expression ::= term [ addop term ]*
term ::= signed_factor [ mulop signed_factor ]*

6
Instâncias iguais de nós residentes - com argumentos iguais - não podem estar ligadas.

53
Figura 4.7: MFrag Starship Data.

signed_factor ::= [ addop ] factor


factor ::= number | function | "(" expression ")"
function ::= possibleVal
| "CARDINALITY" "(" varsetname ")"
| "MIN" "(" expression ";" expression ")"
| "MAX" "(" expression ";" expression ")"
possibleVal ::= ident
addop ::= "+" | "-"
mulop ::= "*" | "/"
ident ::= letter [ letter | digit ]*
number ::= [digit]+

Com base na especificação da gramática apresentada, foi projetado e desenvol-


vido um compilador com analisadores léxico, sintático e semântico. A estrutura
de classes responsável por compilar o pseudo-código apresentado está na Figura
4.8.

Interface ICompiler responsável por definir o método para compilar o pseudo-


código e para gerar a CPT.

Classe Compiler implementa a interface ICompiler para compilar o pseudo-


código através da técnica descendente recursivo e gera a CPT
(PotentialTable) para o nó a que se refere ( SSBNNode ).

Classe TempTableHeaderCell classe interna de Compiler utilizada como código


intermediário para calcular a CPT ( PotentialTable ).

54
Figura 4.8: Modelagem de classes do compilador do pseudo-código.

Classe SSBNNode classe utilizada para representar um nó residente com informações
especı́ficas para gerar um nó de uma rede bayesiana comum.

Internamente, é gerado um código intermediário usado para definir o pseudo-


código necessário para criar uma a CPT do nó na construção de uma SSBN
para um dado contexto. Na implementação do UnBBayes, esse pseudo-código é
armazenado como objeto String no nó residente. Um exemplo de pseudo-código
já foi visto na Seção 3.2. A tabela temporária é estruturada pelas classes internas
apresentadas na Figura 4.9 e organizada da maneira apresentada pela Figura 4.10.

TempTableHeaderCell: encapsula informações sobre a expressão booleana que


representa uma cláusula IF do pseudo-código. Mantém placeholders para
informações sobre os estados dos pais em situações especı́ficas, para que
seja determinado os valores a utilizar no preenchimento da CPT definitiva
durante a geração de SSBN.

TempTableProbabilityCell: encapsula as expressões matemáticas cujo resul-


tado será mapeado para a uma célula da CPT definitiva de um nó da SSBN.

As expressões matemáticas e booleanas são resolvidas usando-se classes in-


ternas que representam uma árvore de avaliação de expressões, satisfazendo o
design-pattern Composite. Esse tipo de abordagem é bastante comum em parsers
orientado-a-objeto.

A gramática incorpora três funções para manipulação de expressões: CARDI-


NALITY, MIN e MAX. Abaixo, sua semântica está descrita.

55
Figura 4.9: Diagrama de classes da tabela temporária do compilador de pseudo-
código do UnBBayes-MEBN.

CARDINALITY Retorna o número de combinações de nós pais que possuem


como argumento predominante a indicada por “varsetname”. Se o valor
“varsetname” for diferente da indicada na expressão “if”, obviamente será
retornado o valor 0. A função é útil para se ter uma idéia de quantos pais
foram conectados àquele nó.

MIN Obtém duas expressões como argumento e retorna o menor valor entre o
resultado dessas duas expressões. É útil para limitar superiormente uma
expressão.

MAX Obtém duas expressões como argumento e retorna o maior valor entre
o resultado dessas duas expressões. É útil para limitar inferiormente uma
expressão.

Quando um pseudo-código não é declarado para um nó residente, será atribuı́do


uma interpretação especial a esse nó. Nesse caso, a distribuição de probabilidades
será uniforme para todos os valores possı́veis daquele nó. Isso é particularmente
útil quando o estado possı́vel de um nó é uma entidade, cujo número de instâncias
não é conhecido a priori, seja, não se conhece quais estados o nó pode apresentar.

56
Figura 4.10: Organização das colunas e células da tabela temporária.

57
Capı́tulo 5

Implementação do
UnBBayes-MEBN

Neste capı́tulo são discutidos os aspectos da implementação da MEBN feita


no UnBBayes, mostrando as soluções técnicas para os principais problemas en-
frentados.

Na primeira seção é descrita a interface gráfica. Houve um grande esforço


para que a GUI fosse a mais intuitiva e amigável possı́vel para o usuário, pois
uma das motivações para o projeto era a dificuldade de se criar ontologias pro-
babilı́sticas utilizando os programas até então disponı́veis (como por exemplo o
Protégé). Na segunda seção é apresentado o tratamento da lógica de primeira
ordem no UnBBayes, utilizando a API do PowerLoom. Na terceira seção é des-
crita a implementação da entrada e saı́da no UnBBayes, utilizando a API do
Protégé-OWL.

5.1 Interface Gráfica

O UnBBayes é o primeiro software a oferecer suporte a edição de MEBN e de


arquivos PR-OWL de forma gráfica.

Ferramentas como o Protégé facilitam a criação de ontologias probabilı́sticas


ao permitir a importação do modelo PR-OWL, evitando que o usuário tenha que
lembrar-se de todas as informações e tags OWL. O usuário monta a ontologia
criando os diversos elementos do PR-OWL e os relacionamentos, devendo conhe-
cer o significado de termos técnicos como hasPossibleValues, isNodeFrom e
isResidentNodeIn. A montagem de ontologias é lenta e propensa a erros.

O UnBBayes facilita a modelagem ao omitir muitos termos técnicos cujo in-


teresse está vinculado apenas ao processamento interno durante as fases de con-
sistência e inferência da ontologia, os preenchendo automaticamente. As onto-
logias probabilı́sticas são criadas de forma intuitiva, não requerendo do usuário

58
Figura 5.1: Arquitetura da GUI

conhecimento da sintaxe da PR-OWL.

5.1.1 Arquitetura

A Figura 5.1 apresenta a arquitetura da GUI do UnBBayes após a imple-


mentação do suporte a MEBN. O diagrama está simplificado, mostrando apenas
as classes e relacionamentos necessários ao entendimento.

A arquitetura do UnBBayes baseia-se no padrão Model-View-Controller (MVC),


utilizando controladores para gerenciar as interações entre a interface gráfica e o
modelo. O papél de cada classe é descrito a seguir:

• Classe Main: responsável pela inicialização do UnBBayes. Cria o controla-


dor principal (MainController).

• Classe MainController: responsável por criar, abrir e salvar redes supor-


tadas pelo UnBBayes: Redes Probabilı́sticas, MEBN, e MSBN. Cria o con-
trolador e o painel da rede selecionada.

• Classe UnBBayesFrame: tela principal do programa (exibida independente-


mente do tipo de rede).

• Classe MDIDesktopPane: desktop do UnBBayesFrame. Permite a abertura e


gerenciamento de múltiplos painéis (podendo estes serem de tipos diferentes,
de acordo com o tipo de rede tratado por cada um).

59
• Classe NetworkWindow: janela da rede, possuindo o painel de edição corres-
pondente à rede e o painel que contém o grafo da rede. Cria o controlador
para a rede (NetworkController).

• Classe GraphPane: responsável por desenhar o grafo da rede na tela. Este


grafo é composto por nós e arcos, sendo que estes podem ser tanto a re-
presentação de uma rede bayesiana normal, quanto a representação dos nós
componentes de um MFrag. Trata os eventos do mouse, permitindo que o
usuário o use para editar os objetos.

• Classe NetworkController: delega funções que serão executadas em uma


SingleEntityNetwork ou MultiEntityNetwork, como por exemplo, inse-
rir nós e propagar evidências. As funções são delegadas ao controlador
associado à rede editada.

• Classe SENController: controlador das operações realizadas sobre uma


rede probabilı́stica normal.

• Classe MebnController: controlador das operações realizadas sobre uma


rede bayesiana multi-entidade.

• Classe MEBNEditionPane: painel de edição de redes bayesianas multi-entidades.

• Classe PNEdtionPane: painel de edição de redes bayesianas (probabilistic


networks).

O diagrama das figuras 5.2 e 5.3 mostra a seqüência de criação dos objetos
relacionados à GUI da MEBN.

Figura 5.2: Diagrama de sequência de criação dos objetos da GUI - parte 1

60
Figura 5.3: Diagrama de sequência de criação dos objetos da GUI - parte 2

5.1.2 Painel Principal

A Figura 5.4 ilustra os componentes da tela de edição de MEBN:

O painel de edição da MEBN (classe MEBNEditionPane) foi criado para a


edição de MTheories e de seus elementos. Todos os outros elementos gráficos
estão contidos dentro deste.

A barra de opções globais contém botões para que o usuário escolha o que
se deseja fazer (editar uma generative MTheory ou entrar com findings e queries
para gerar uma SSBN), para carregar/salvar bases de conhecimento e para con-
figurar o ambiente de trabalho.

A barra de edição da MEBN contém botões para inserir os elementos prin-


cipais de uma MTheory: MFrags, nós residentes, nós de input, nós de contexto,
variáveis ordinárias e arcos. .

A tela de edição do grafo apresenta o conteúdo do MFrag ativo e é onde


devem ser inseridos os nós e arcos.

A barra de edição do objeto selecionado e o painel de edição são al-


terados de acordo com o tipo de objeto sendo editado e juntos permitem que o
usuário edite as diversas propriedades do objeto ativo. Os painéis e barras exis-
tentes são os seguintes:

• Barra de edição de MFrag

61
Figura 5.4: Componentes do Painel Principal do UnBBayes

• Barra de edição da MTheory

• Painel de visualização dos elementos da MTheory ativa

• Painel e barra de edição do nó residente

• Painel e barra de edição do nó de input

• Painel e barra de edição do nó de contexto

• Painel e barra de edição da variável ordinária

• Painel de edição de entidades

• Painel de edição de instâncias de entidades

• Painel de edição de evidências (findings)

Alguns objetos não possuem barra de edição, enquanto outros não possuem
painel. Alguns, ainda, não aparecem no grafo, podendo ser editados apenas pelos
painéis (como por exemplo as entidades).

O painel de descricão contém a descrição do componente selecionado. Permite


que o usuário insira comentários explicativos a respeito dos objetos que compõem
a MTheory, ajudando na compreensão do dominio modelado.

62
Figura 5.5: Exibição do MFrag ativo

5.1.3 Edição de MFrags e de seus elementos

A edição de MFrag consiste em adicionar, remover, visualizar e renomear


MFrags. A seleção de MFrags é realizada através da árvore da MTheory, im-
plementada pela classe MTheoryTree, que mostra os elementos da MTheory de
forma hierárquica, apresentando os nós como filhos de seus respectivos MFrags.
O MFrag ativo terá o seu conteúdo exibido no grafo de cena conforme ilustrado
na Figura 5.5.

A edição de um nó residente permite:

• Adicionar, renomear e excluir nós (através do grafo e através da árvore da


MTheory)
• Editar os estados através do painel de edição de possı́veis valores
(PossibleValuesEditionPane).
• Editar os argumentos inserindo e retirando variáveis ordinárias através do
painel de edição de argumentos (ArgumentEditionPane).
• Editar a tabela de distribuição probabilı́stica do nó.

A edição da tabela probabilı́stica é feita através de uma popup, conforme ilus-


trada na Fig. 5.6. Neste painel, o usuário tem opções de auto-texto que o auxilia
na edição do pseudo-código: além de botões para inserir as estruturas sintáticas,
há listas para a seleção dos objetos utilizados no código (nós pais, estados e ar-
gumentos). O código da tabela é colorido, facilitando a visualização dos diversos
tokens.

63
Figura 5.6: Janela de edição da CPT

Figura 5.7: Painel de edição do nó de input

A edição de um nó de input consiste em:

• Adicionar, renomear, excluir nós (através do grafo e através da árvore da


MTheory)

• Editar a qual nó residente o nó de input se refere. O usuário faz esta escolha
selecionando o nó na árvore representada pela classe InputInstanceOfTree,
que mostra hierarquicamente os nós residentes de cada MFrag. Após a
escolha do nó residente, o usuário preenche os argumentos do nó de input,
conforme ilustrado na Figura 5.7

A edição de um nó de context permite:

• adicionar, renomear, excluir nós (através do grafo e pela árvore da MThe-


ory)

• editar a fórmula que o nó representa. A formula é editada como uma árvore,
onde um nó operador possui os operandos como nós filhos, como ilustrado
na Figura 5.8.

O objetivo deste modo de criar fórmulas é diminuir a liberdade para o de-


senvolvedor, de forma a evitar construções irregulares. Quando um operador é
64
Figura 5.8: Edição da fórmula do nó de contexto

criado, a quantidade de operandos serão fixados, de forma que a única ação que o
desenvolvedor poderá realizar será definir quais argumentos estes nós filhos pos-
suirão.

A edição de uma variável ordinária permite adicionar, renomear e excluir nós,


e alterar o tipo da variável. Apesar das variáveis ordinárias não serem nós, elas
são mostradas no grafo do MFrag através de um nó especial: o IsA, que relaciona
a variável ordinária com o seu tipo. Com esta abordagem, o usuário consegue
entender uma boa parte da modelagem apenas com os grafos dos MFrags.

5.1.4 Edição de entidades e findings

A edição de entidades (Fig. 5.9) permite a criacão, eliminacão e alteração


destas. Na edição, o usuário pode alterar o nome e definir a propriedade É
Ordenável, que indica se as instâncias da entidade possuem ordem (podendo,
portanto, serem utilizadas em construções que envolvam recursividade).

O usuário entra com as informações a respeito das situações especı́ficas através


do painel de instâncias de entidades e do painel de edição de evidências (Fig. 5.10).
Estes painéis também mostram as informações contidas na base de conhecimento
e permite que evidências ou instâncias retiradas sejam excluı́das.

5.1.5 Questionamentos e geração de SSBN

A janela de questionamentos permite que o usuário selecione qual o nó (são

65
Figura 5.9: Edição de entidades

Figura 5.10: Edição de evidências

66
Figura 5.11: Painel da rede compilada

listados todos os nós residentes) ele deseja realizar a inferência e sobre quais ar-
gumentos.

Após a inferência, a SSBN gerada será mostrada no Painel de rede compi-


lada (Fig 5.11), painel previamente implementada no UnBBayes. Através dele, o
usuário poderá visualizar a probabilidade de cada estado, além de atribuir outras
evidências e propagá-las (na SSBN gerada).

5.2 Lógica de primeira ordem utilizando Power-


Loom

Os nós de contexto são variáveis booleanas que representam condições que


devem ser satisfeitas para que a distribuição de probabilidade dos nós residentes
se aplique. Avaliar um nó de contexto corresponde a avaliar uma fórmula da
lógica de primeira ordem, tendo como premissas os fatos conhecidos. Na imple-
mentação do UnBBayes foi adotada a API PowerLoom para avaliação de fórmulas
da FOL. Na Seção 5.2.1 são apresentadas as principais caracterı́sticas do Power-
Loom. Na Seção 5.2.2 é descrita a implementação da lógica de primeira ordem
pelo PowerLoom, descrevendo os comandos utilizados para o seu uso. A seção
não detalha a sintaxe dos comandos (o leitor interessado pode consultar [11]).
Na Seção 5.2.3 são descritas a integração da API PowerLoom ao UnBBayes e o
mecanismo utilizado para a avaliação dos nós de contexto.

5.2.1 O PowerLoom

O PowerLoom é um sistema de representação de conhecimento e inferência (


KR&R ) baseado na lógica de primeira ordem que provê linguagem e ambiente

67
para a construção de aplicações baseadas em conhecimento. Foi criado por desen-
volvedores da University of Southern California, a partir do sistema Loom, sob
a liderança de Hans Chalupsky. Atualmente é distribuı́do em licença open-source
(o usuário pode escolher entre as licenças GPL, LGPL ou Mozilla).

Um sistema de KR&R permite modelar aspectos salientes de um mundo de


interesse e fazer inferências a partir do modelo. Entre os diversos paradigmas
de modelos para a implementação destes sistemas, os baseados em lógica são os
mais utilizados por apresentarem vantagens tais como: a grande quantidade de
pesquisas realizadas, sintaxes e semânticas bem conhecidas e ao grande poder de
representação.

O PowerLoom utiliza como linguagem de representação uma variante, com


expressividade total, do KIF (Knowledge Interchange Format). O KIF é uma
linguagem baseada em lógica, desenvolvida para a troca de conhecimento entre
sistemas de computadores diferentes.

O PowerLoom foi escrito em linguagem STELLA (Strongly Typed, Lisp-like


LAnguage), que foi desenvolvida especificamente para este objetivo. Baseada em
Lisp, a linguagem STELLA preserva as caracterı́sticas desta que facilitam a pro-
gramação simbólica e a rápida prototipagem, enquanto ainda permite a tradução
em código Java, Lisp e C++ eficiente e legı́vel. Por ser escrito em STELLA, o
PowerLoom é distribuı́do nas três linguagens citadas. A API do PowerLoom para
a linguagem Java é relativamente pequena, possuindo menos de 3 MB (junta-
mente com a STELLA).

O PowerLoom realiza inferência através da dedução natural, utilizando enca-


deamento forward e backward para derivar o que logicamente segue dos fatos e
regras existentes na base de conhecimento. Além do mecanismo de dedução na-
tural, o PowerLoom possui um grande número de procedimentos para reasoners
especializados que eficientemente trabalham sobre hierarquias de conceitos, rela-
cionamentos ou conjuntos. A arquitetura especialista é extensı́vel para permitir
que usuários acrescentem seus reasoners ou predicados computados. Há também
suporte para raciocı́nio hipotético, raciocı́nio sobre igualdades, aritmética e ra-
ciocı́nio sobre desigualdades. Apesar de não ser uma lógica descritiva, possui
classificadores que podem classificar hierarquias de conceitos e relacionamentos e
instâncias definidas, utilizando o poder de expressividade da lógica de primeira
ordem.

Como sistema de representação de conhecimento, o PowerLoom possui uma


grande preocupação em oferecer o máximo de expressividade e de escalabilidade.
A expressividade é vista com mais importância que a completude da inferência.
O PowerLoom é bastante escalável, possuindo mecanismos para controlar a busca
e oferecer suporte a grandes ontologias e bases de conhecimento.

Nessa pesquisa, o interesse no PowerLoom é no seu mecanismo de inferência


sobre sentenças de lógica de primeira ordem, ficando em segundo plano as suas
68
caracterı́sticas de sistema de representação de conhecimento.

5.2.2 Lógica de Primeira Ordem no PowerLoom

Uma base de conhecimento PowerLoom é construı́da com a definição da ter-


minologia para o domı́nio e pelas regras e fatos sobre este. Como os fatos podem
ser inseridos e retirados, as respostas para os questionamentos podem mudar no
tempo.

As estruturas de conhecimentos são organizadas em containers lógicos chama-


dos de módulos: os fatos não são válidos globalmente, mas apenas dentro de um
contexto especı́fico. O PowerLoom permite a montagem de uma hierarquia de
módulos, facilitando a modelagem de fatos que são válidos em diversos contextos
e permitindo a importação de conhecimentos de outros módulos. Com essa ca-
racterı́stica, uma forma conveniente de se organizar o conhecimento é colocar as
definições em módulos mais altos e os fatos em módulos mais baixos. A herança de
fatos não é monotônica: um módulo filho pode retirar ou sobrescrever fatos her-
dados de módulos antecessores. O PowerLoom mantém um ponteiro apontando
para o módulo corrente, de forma que todas as assertivas ou questionamentos são
feitos relativamente a este módulo. O PowerLoom possui alguns módulos built-in,
como por exemplo o PL-KERNEL, que contém um conjunto de definições de con-
ceitos e relacionamentos de propósito geral que coletivamente formam o suporte
lógico para construir aplicações especı́ficas baseadas em conhecimento.

As entidades do mundo são capturadas como termos (ex.: Brası́lia, 3,


Pessoa). Os termos no PowerLoom devem ter nomes distintos. São categori-
zados ou relacionados com outros por objetos chamados relacionamentos (ex.:
temIdade, maiorQue). Conceitos como Pessoa, Estado, Compania e Número são
considerados uma subcategoria de relacionamento. Uma proposição é uma sen-
tença lógica que tem um valor verdade associado, como por exemplo: “Benjamin é
uma pessoa”. A notação KIF seguida pelo PowerLoom utiliza a forma pré-fixada
para representar as preposições, como ilustrado no exemplo a seguir, utilizando
os relacionamentos Pessoa, Casados, + e =:

• (Pessoa Joao)

• (Casados Joao Maria)

• (= (+ 2 3) 6)

O cálculo predicativo constrói sentenças complexas a partir de sentenças sim-


ples usando os conectivos lógicos and, or, not, as implicações <=, =>, <=> e os
quantificadores forall e exists. Exemplos:

• (not (Homem Maria))

• (forall ?p (=>(Pessoa ?p) (exists ?m (Mae ?m ?p))))

69
A primeira sentença representa o fato “Maria não é homem”, enquanto se-
gunda, mais complexa, representa o fato “Toda pessoa tem uma mãe”.

O PowerLoom requer que relacionamentos sejam definidos antes de serem utili-


zados em assertivas e questionamentos. Os comandos defconcept, defrelation
e deffunction são utilizados para definir conceitos, relacionamentos e funções
respectivamente. O uso de referência circular é permitido em definições, porém
não em assertivas. Todos os axiomas que aparecem dentro dos limites de uma
definição são resolvidos antes da próxima ocorrência de um questionamento.

Para fazer inferência a partir das sentenças e regras da base de conhecimento,


podem ser utilizados os comandos ask e retrieve. O comando ask retorna o valor
verdade de uma assertiva, enquanto o comando retrieve retorna uma listagem
dos objetos que corretamente preenchem as variáveis. No exemplo abaixo, o
ask retornará false, enquanto o retrieve retornará ?x = Maria. Note que o
comando assert insere sentenças ou fatos na base de conhecimento.
• (assert (not(Trabalha-para Jeronimo Megasoft)))
• (assert (Trabalha-para Maria Megasoft))
• (ask (Trabalha-para Jeronimo Megasoft))
• (retrieve all(Trabalha-para ?x Megasoft))
Uma preposição PowerLoom é etiquetado com um valor verdade que pode ter
um de cinco valores diferentes: true, false, default-true, default-false ou
unknow. Os valores true e false podem ser definidos através do comando assert,
enquanto os defaults são definidos através do comando pressume. Uma pre-
posição previamente definida como default pode ser redefinida para qualquer um
dos quatro outros valores. Preposições previamente definidas como default-true
ou default-false podem ser redefinidas como true ou false, porém o inverso
não é possı́vel (apenas é possı́vel subir o grau da força da definição do valor ver-
dade, nunca descer para um grau anterior).

Um clash (contradição) ocorre quando uma preposição é redefinida de true


para false ou vice-versa. Uma clash-exception é levantada, permitindo que
as aplicações tomem a ação desejada (o comportamento padrão do PowerLoom é
não dar tratamento nenhum, fazendo com que a assertiva que causou a exceção
não seja executada). O comando retract permite retirar o atual valor-verdade
de uma proposição, permitindo que seja definido qualquer outro valor verdade
para esta.

O PowerLoom assume premissas de mundo aberto por padrão. Em uma visão


de mundo aberto é assumido que não há um modelo completo do mundo tratado:
caso não haja informações para provar a verdade ou a falsidade de um questiona-
mento, o valor será dado como unknow. A visão de premissa de mundo fechado
também é implementada no PowerLoom, permitindo que se opte por um dos dois
modos.
70
5.2.3 Uso do PowerLoom para a avaliação dos nós de con-
texto

Um MFrag representa uma distribuição de probabilidade de instâncias de seus


nós residentes, dados os valores das instâncias dos seus pais no grafo. Para que
estas distribuições se apliquem, as restrições de contexto devem ser satisfeitas. A
API PowerLoom foi utilizada para a avaliação dos nós de contexto.

O trabalho com a API é facilitado através de uma interface especial (PLI),


que evita que o usuário utilize os objetos STELLA diretamente (o que exigiria um
conhecimento profundo do processo seguido para se fazer as operações). A mai-
oria dos métodos presentes na interface PLI possuem duas versões: uma que re-
cebe como parâmetros objetos STELLA e outra que recebe como parâmetro uma
string contendo o comando PowerLoom. Ambas retornam objetos STELLA.

As classes presentes na implementação da base de conhecimento (KB) são


apresentadas na Figura 5.12.

Figura 5.12: Modelagem do uso do PowerLoom.

Interface KnowledgeBase contém os métodos que a base de conhecimento uti-


lizada pelo UnBBayes deve conter. Os métodos correspondem as operações
de inserir e retirar informações a base de conhecimento (a partir dos objetos
MEBN) e fazer questionamentos sobre informações na base de conhecimento
(a partir de nós de contexto).
Classe PowerLoomKB implementação de KnowledgeBase utilizando o PowerLoom
como base de conhecimento.
Classe Module classe do da API do PowerLoom que representa um módulo da
base de conhecimento. As inferências devem ser feitas dentro de um módulo.
71
Classe Environment classe da API do PowerLoom que representa as caracterı́sticas
do ambiente onde são executadas as operações.

Os passos para a avaliação dos nós de contexto são os seguintes:


• mapeamento da MTheory geradora na base de conhecimento;

• mapeamento da situação especı́fica para a base de conhecimento;

• avaliação dos nós de contexto.


A seguir é analisado como o PowerLoom é utilizado em cada um dos passos e
como funcionam os métodos da classe PowerLoomKB.

O mapeamento da MTheory geradora para a KB corresponde a inserir na base


de conhecimento a modelagem da MTheory geradora. Essa inserção na KB é pre-
cedida de uma tradução da modelagem em definições de entidades e de variáveis
aleatórias no PowerLoom.

Como a MTheory geradora é reaproveitada para a geração de diversas SSBN,


é possı́vel salvar um módulo PowerLoom com estas definições, de forma que ao
se gerar outra SSBN se aproveite este super-módulo e a partir deste se acres-
cente apenas as assertivas relativas a SSBN atual. Este super-módulo precisa
ser modificado apenas se o usuário fizer modificações na modelagem da MTheory
geradora. Devido a problemas de gerênciamento das modificações entre o arquivo
salvo e a ontologia com a qual o usuário está trabalhando, optamos por não salvar
o módulo generative, sendo ele gerado a partir da ontologia quando o usuário dele
necessitar (ou seja, quando fizer alguma operação que necessite que sejam feitas
inferências na base de conhecimento).

O UnBBayes implementa uma MTheory tipada, de forma que estes tipos de-
vem ser mapeados no PowerLoom. O PowerLoom possui suporte completo a
definições de tipos e subtipos, oferecendo mecanismos de inferência para traba-
lhar com eles. Ao utilizar o PowerLoom, no entanto, assumimos que o UnBBayes
já fez todas as verificações quanto a corretude dos tipos definidos na MTheory,
informando ao usuário possı́veis erros. Foi assumida essa opção porque o suporte
a tipos do PowerLoom exige que se avalie toda a base de conhecimento após a
inserção de cada assertiva, para verificar se a nova assertiva inserida possui algum
erro de tipo. A verificação de tipos na montagem das MTheories geradoras é ga-
rantida pelo UnBBayes através da própria GUI que não permite inconsistências.
O UnBBayes também deverá fazer as verificações necessárias ao receber as in-
formações do usuário para a montagem da SSBN, reportando os erros.

As funções utilizadas para a tradução da MTheory geradora para a base de


conhecimento são descritas a seguir (Figura 5.12):
• createEntityDefinition(entity: ObjectEntity): faz a tradução de
um objeto de uma entidade para a sintaxe do PowerLoom e grava a definição
na KB;
72
• createRandomVariableDefinition(resident: DomainResidentNod): faz
a tradução de um nó residente para a sintaxe do PowerLoom e grava a de-
finição na KB.

Os objetos ObjectEntity são traduzidos como conceitos na KB. A entidade


Starship, por exemplo, é traduzida para: (defconcept Starship ?st).

Os nós residentes poderiam ser traduzidos para relacionamentos ou para funções.


No UnBBayes, os nós residentes booleanos são traduzidos para relacionamentos
e todos os outros são traduzidos para funções. A justificativa para traduzi-los
para funções é porque em um dado momento, instanciado para um conjunto de
entidades, um nó residente tem apenas um possivel estado. A opção por traduzir
os nós residentes booleanos para relacionamentos é justificada por questões de
sintaxe do PowerLoom, que não permite que o comando “assert” utilize os lexe-
mas “true” e “false” como imagem das funções.

Os possı́veis estados foram mapeados utilizando-se collections no Power-


Loom, no qual um conceito é definido em termo de um conjunto enumerado
utilizando a built-in setof:

• (defconcept StarshipZoneState (?z) :<=> (member-of ?z setof


ZNBlackHoleBoundary, ZNDeepSpace, ZNPlanetarySystem))

Para a inserção da situação especı́fica na base de conhecimento são utilizados


os dois métodos:

• insertEntityInstance(entityInstance: ObjectEntityInstance): tra-


duz uma instância de uma entidade para a sintaxe do PowerLoom e a grava
na KB.

• insertRandomVariableFinding(randomVariableFinding:
RandomVariableFinding): traduz uma evidência de uma variável aleatória
e a grava na KB.

As evidências são mapeadas para a base de conhecimento via o comando


assert. Ao inserir uma instância da entidade Starship com o nome Enterprise
na KB, a tradução feita é a seguinte:

• (assert (Starship Enterprise))

Como já visto, em PR-OWL o nome de uma variável começa com ponto de
exclamação. Assim, nos exemplos a seguir o ponto de exclamação representa um
indentificador, e não a negação lógica. Em PowerLoom, variáveis não precisam
iniciar com exclamação. Ao inserir uma evidência sobre uma determinada variável
aleatória, temos duas possibilidades. Se os estados da variável aleatória forem
booleanos, por exemplo, afirmar que !Enterprise é sua própria nave, então
temos:

• (assert (IsOwnStarship Enterprise))


73
Caso contrário, ou seja, se os estados da variável aleatória não forem boolea-
nos, por exemplo, afirmar que a zona de !Enterprise é !Z2 , então temos:

• (assert (= (StarshipZone Enterprise) Z2))

As fórmulas dos nós de contexto são diretamente mapeadas para o Power-


Loom. Os built-ins implementados no UnBBayes estão presentes no PowerLoom:
and, or, not, implies, iff, equalTo, exists e forall. As variáveis ordinárias
são mapeadas para variáveis. Cada nó de contexto é traduzido para um comando
ask. Além disso, eles podem ser divididos em duas categorias: os de fórmula
simples e os de fórmula complexa. Uma fórmula simples é aquela que não possui
variáveis e que o resultado é um valor booleano. Uma fórmula complexa é aquela
que retorna uma lista de entidades que satisfazem uma determinada restrição.
No MFrag Starship (Figura 5.13), temos os dois casos.

Figura 5.13: Nós de contexto da MFrag Starship.

Para a avaliação dos nós de contexto são utilizados os dois métodos:

• evaluateContextNodeFormula(context: ContextNode, ovInstances:


List<OVInstance>): avalia um nó de contexto de fórmula simples para
verdadeiro ou falso.

• evaluateSearchContextNodeFormula(context: ContextNode,
ovInstances: List<OVInstance>): avalia um nó de contexto de fórmula
complexa, retornando uma lista com as entidades que satisfazem a restrição
definida no nó de contexto.

Uma fórmula simples, apresentada na Figura 5.13, é Exists(st), que no


UnBBayes é representada como:

• ( Exists(st) )

74
Ao ser avaliada para uma Starship !Enterprise , por exemplo, é traduzida
para o PowerLoom como:

• (ask (not( IsOwnStarship Enterprise ) ))

Uma fórmula complexa, apresentada na Figura 5.13, é z=StarshipZone(st),


que no UnBBayes é representada como:

• ( StarshipZone(st) = z )

Ao ser avaliada para uma Starship !Enterprise , por exemplo, é traduzida


para o PowerLoom como:

• (retrieve ( = ( StarshipZone Enterprise ) ?z))

Observe que ao fazer a avaliação, as variáveis ordinárias da fórmula deverão


estar corretamente substituı́das pelos valores reais da situação especı́fica. Não
pode haver variáveis ordinárias não substituı́das, a não ser aquela que se deseja
obter como resposta. Novamente cabe ao UnBBayes fazer estas verificações, pas-
sando para o PowerLoom as fórmulas corretas.

A avaliação dos nós de contexto de um MFrag é feita em cadeia até que a


primeira avaliação retorne falso. Caso isto ocorra, será utilizada a distribuição
padrão. Caso contrário, as condições estão corretamente verificadas e as variáveis
aleatórias do MFrag serão instanciadas utilizando-se as suas distribuições locais.

5.3 Entrada e Saı́da no UnBBayes

O PR-OWL foi a linguagem formal escolhida como formato de armazenamento


das MTheories no UnBBayes. Por estender a OWL, a MTheory representada
nessa linguagem reside em um arquivo texto, em esquema XML, com extensão
“.owl”. Optou-se por utilizar no UnBBayes a API do Protégé-OWL para fazer
o carregamento e o armazenamento de arquivos escritos em PR-OWL, pois esta
API possui suporte para o tratamento de arquivos OWL.

Certas informações peculiarmente tratadas pelo UnBBayes para representar


a MEBN não são armazenadas diretamente nos arquivos PR-OWL. Para o ar-
mazenamento dessas informações internas do UnBBayes, utilizamos um arquivo
próprio, chamado de UBF, com extensão “.ubf”.

As próximas seções descrevem o Protégé e sua API e o formato UBF.

5.3.1 O Protégé

O Protégé é uma plataforma flexı́vel e configurável para o desenvolvimento de


aplicações dirigidas a modelos arbitrários e componentes. O Protégé permite a

75
edição visual de ontologias por dois caminhos: via o editor Protégé-Frames e via o
editor Protégé-Owl. As ontologias podem ser salvas em uma grande variedade de
formatos, incluindo RDF, OWL e XML Schema. A Figura 5.14 ilustra a interface
gráfica do Protégé.

Figura 5.14: Tela de edição de classes/indivı́duos no Protégé.

O Protégé-OWL provê muitas facilidades de edição e navegação para modelos


OWL. Provê diferentes classes de editores para uma ontologia em OWL, sendo
os mais importantes:

Editor de classes permite a navegação, criação, remoção e edição sobre classes


OWL, incluindo edição avançada de restrições e atribuição de propriedades
padrão da OWL e RDF.
Editor de indivı́duos permite navegação sobre diferentes instâncias das classes
presentes na ontologia e edição de seus atributos.
Editor de propriedades exibe uma lista de todas as propriedades entre as clas-
ses presentes na ontologia e permite sua edição; como alteração de domı́nio
e imagem, atribuição de propriedade inversa e comentários.
Editor de formulários permite alterar o visual dos outros editores através da
alteração do esquema de formulários. Todos os editores são formados por
“blocos” de formulários com campos de entrada. Este editor permite mo-
dificar a organização desses formulários e a posição dos blocos.
Editor de meta-dados permite gerenciar ontologias importadas. Ao editar
uma ontologia PR-OWL diretamente no Protégé, um passo inicial seria
importar a biblioteca básica (pr-owl.owl) através deste editor.
76
O Protégé provê também uma série de API e possibilidade de extensão de
sua funcionalidade através de desenvolvimento de plugins (veja [19] para mais
informações).

A API Protégé-OWL, parte do pacote Protégé-OWL, é uma biblioteca Java


open source para OWL e RDF. Provê métodos para:

• abrir e salvar arquivos OWL;

• realizar queries;

• manipular modelos de dados OWL;

• realizar raciocı́nios.

A API Protégé OWL é centrada em uma coleção de interfaces Java para o


pacote model. Essas interfaces fornecem acesso ao modelo OWL e aos seus diver-
sos elementos. Desenvolvedores de aplicação não podem acessar a implementação
destas interfaces diretamente, podendo apenas operar sobre elas: o usuário não
precisa conhecer os detalhes internos sobre como o Protégé armazena suas onto-
logias.

O modelo de interface mais importante é o OWLModel, que propicı́a acesso


ao container de alto nı́vel de recursos na ontologia. Assim pode-se utilizar o
OWLModel para criar, fazer queries, e apagar recursos de vários tipos e utilizar os
objetos retornados pelo OWLModel para operações especı́ficas.

A API Protégé OWL pode ser utilizada em dois modos:

• modo de arquivos OWL (classe JenaOWLModel);

• modo de arquivos Database (classe OWLDatabaseModel).

As classes utilizadas pelo módulo de armazenamento de MEBN do UnBBayes


estão listadas abaixo:

• com.hp.hpl.jena.util.FileUtils: utilizada para especificar o formato


de armazenamento do arquivo OWL, através da constante
FileUtils.langXMLAbbrev.

• edu.stanford.smi.protegex.owl.ProtegeOWL: é a classe núcleo da API.


No UnBBayes, é utilizada como uma builder para a instanciação do
JenaOWLModel.

• edu.stanford.smi.protegex.owl.jena.JenaOWLModel: OWLModel em
modo de manipulação de arquivos OWL. Através desta classe, pode-se criar,
alterar, remover e buscar classes, indivı́duos e propriedades descritos na
ontologia.

77
• edu.stanford.smi.protegex.owl.model.OWLDatatypeProperty: classe
Java que representa uma propriedade em OWL que liga uma classe OWL
(ou indivı́duo) a um tipo simples de dado (como texto ou numerais). Foi
utilizado, no UnBBayes, para ligar classes OWL de CPT à sua declaração
em texto ou para ligar argumentos aos numerais indicando sua ordem.
• edu.stanford.smi.protegex.owl.model.OWLIndividual: classe Java
que representa um indivı́duo ou instância de uma classe OWL.
• edu.stanford.smi.protegex.owl.model.OWLNamedClass: classe Java
que representa uma classe em OWL. Como são identificadas pelo nome,
uma busca por nome pode ser feita pelo JenaOWLModel.
• edu.stanford.smi.protegex.owl.model.OWLObjectProperty: classe
Java que representa uma propriedade OWL que liga uma classe a uma outra
classe qualquer. Utilizada para declarar as propriedades da PR-OWL, que
por sua vez são propriedades OWL.
• edu.stanford.smi.protegex.owl.repository.impl.LocalFile
Repository: utilizada para criar um repositório local que armazena algu-
mas informações pertinentes da Dublin Core DL. O arquivo gerado tem
extensão “.repository”. Esta classe ainda é uma placeholder para futuras
adaptações.
Com a combinação das classes listadas acima, foi possı́vel implementar o me-
canismo de armazenamento do arquivo PR-OWL no UnBBayes.

Maiores informações sobre o uso da API Protégé-OWL podem ser encontradas


em [24].

5.3.2 Arquivo UBF - UnBBayes File

O arquivo UBF foi elaborado como um arquivo de projeto do UnBBayes, arma-


zenando informações especı́ficas utilizadas pelo UnBBayes para a representação
da MEBN. Discutiu-se se estas informações especı́ficas deveriam ser acopladas a
uma nova versão da PR-OWL, porém chegou-se a conclusão que a PR-OWL
não deveria conter informações especı́ficas de softwares utilizados para a sua
edição/visualização, pois estas não fazem parte da ontologia.

O UBF é um arquivo texto com extensão “.ubf” contendo uma lista de de-
clarações no formato: ATRIBUTO=VALOR1,VALOR2,..., onde ATRIBUTO é um nome
interno para a informação utilizada pelo UnBBayes e VALOR é o seu valor. Quando
múltiplos valores são declarados, eles são separados por vı́rgulas. Os comentários
são iniciados com o sı́mbolo % e se estendem até o final da linha.

O UBF está intimamente acoplado a um arquivo PR-OWL, pois suas de-


clarações indicam parâmetros especiais dos componentes da MTheory, armaze-
nados no arquivo PR-OWL. Para manter controle deste acoplamento, o arquivo
78
UBF contém a referência explicita de à qual arquivo PR-OWL ele se refere.

Um UBF completo é dividido em três partes (a formalização se refere ao


formato 0.03):
1. Cabeçalho contendo meta dados do UBF.

Version indica a versão do arquivo UBF.


• Version=0.03
PrOwl indica a URI relativa do arquivo PR-OWL que o arquivo UBF
descreve. Seu valor deve estar entre aspas.
• PrOwl=‘‘StarTrek27.owl’’

2. Declarações da MTheory: na versão atual, o UnBBayes presume que um


único arquivo PR-OWL tenha somente uma MTheory declarada, entre-
tanto, a estrutura do UBF já permite a declaração de diversas MTheories
em um único arquivo PR-OWL.

MTheory nome da MTheory tratada pelo UBF.


• MTheory=StarshipMTheory
NextMFrag numeral usado como sufixo para o nome do próximo MFrag
que será criado pelo UnBBayes. Este número é tipicamente impor-
tante para evitar que os nomes automaticamente gerados choquem
com nomes existentes. É armazenado o número para o próximo ob-
jeto de todos os objetos que possuem nomes automáticos gerados pelo
UnBBayes no ato de criação destes (NextResident, NextInput).
• NextMFrag=10
NextResident numeral usado como sufixo para o nome do próximo nó re-
sidente que será criado pelo UnBBayes.
• NextResident=24
NextInput numeral usado como sufixo para o nome do próximo nó de en-
trada que será criado pelo UnBBayes.
• NextInput=19
NextContext numeral usado como sufixo para o nome do próximo nó de
contexto que será criado pelo UnBBayes.
• NextContext=15
NextEntity numeral usado como sufixo para o nome da entidade que será
criada pelo UnBBayes.
• NextEntity=1

3. Lista de declaração de MFrags: declara atributos referentes a conteúdos de


MFrags. São diversos blocos de declaração que iniciam com a declaração
de nome do MFrag e terminam ou com o inı́cio do próximo bloco ou com o
fim do arquivo.
79
MFrag nome do MFrag tratado naquele bloco.
• MFrag=DangerToOthersMFrag
NextOrdinaryVar numeral usado como sufixo para o nome da variável or-
dinária que será criada pelo UnBBayes para aquele MFrag. Esta de-
claração está neste escopo, pois uma variável ordinária é declarada
localmente no MFrag.
• NextOrdinaryVar=4
Lista de declaração de nós são diversos blocos que declaram atributos
referentes a nós em particular, que podem ser residentes, de entrada,
contexto ou variáveis ordinárias.
Node nome do nó.
• Node=DangerToOthers
Type tipo do nó. Possuı́ um dos seguintes valores: ContextNode,
OrdinalVar, GenerativeInputNode, ou DomainResidentNode.
Type tipo do nó. Seu valor pode ser OrdinalVar, ContextNode,
GenerativeInputNode ou DomainResidentNode.
• Type=DomainResidentNode
Position dois numerais que representam a coordenada X,Y da posição
do nó referente no painel de visualização, separada por vı́rgulas.
• Position=165.0,280.0
Size largura e altura do nó referente no painel de visualização. Apesar
de no momento não fazer sentido para uma variável ordinária,
futuramente pode ser usada para especificar um nó de contexto
IsA.
• Size=100,20
Aquelas declarações no arquivo UBF que não forem identificadas na especi-
ficação ou que não tenham representantes no arquivo PR-OWL serão simples-
mente ignoradas. Isso permite que uma distribuição do UnBBayes que leia uma
versão antiga do UBF (ou PR-OWL) possa ler uma versão recente sem maiores
danos.

5.3.3 Implementação no UnBBayes

Para a implementação do suporte a IO de MEBN foi utilizado o modo de


arquivos OWL. Este modo é baseado na classe JenaOWLModel. O Protégé usa
a API Jena para várias tarefas, em particular para fazer o parsing de arquivos
OWL/RDF.

A Figura 5.15 mostra o diagrama das classes que compõem o suporte à aber-
tura e armazenamento de MTheories.
Pacote unbbayes.io.mebn possui as classes necessárias para abrir e salvar as
MEBN nos formatos suportados, além de sub-pacotes contendo classes de
exceção e classes resource para regionalização.
80
Figura 5.15: Modelagem de IO de MEBN

Interface MebnIO interface para classes que implementam funcionalidades de en-


trada e saı́da de MEBN no UnBBayes. As classes que a implementam devem
prover os seguintes métodos:

loadMebn reconstrói a MEBN a partir de um arquivo válido.


saveMebn salva uma MEBN em um arquivo válido.

Classe PrOwlIO classe que implementa a interface de MebnIO para abrir e salvar
arquivos no formato PR-OWL. Para tal, utiliza as classes LoaderPrOwlIO
e SaverPrOwlIO.

Classe LoaderPrOwlIO classe que concentra rotinas de carregamento da MThe-


ory descrita em PR-OWL. Utiliza a API Protege-OWL para esse fim.

Classe SaverPrOwlIO classe que concentra rotinas de armazenamento da MThe-


ory descrita em PR-OWL. Utiliza a API Protege-OWL para esse fim.

Classe UbfIO classe que implementa a interface MebnIO, adicionando funcionali-


dades de manipulação de arquivos UBF. É uma extensão da classe PrOwlIO
através da agregação no lugar de heranças.

getInstance como a visibilidade do construtor da classe é privada, exige-


se que se use este método de instanciação para a geração de objetos
desta classe. Padrão de projeto Singleton foi utilizado.
loadMebn utiliza o método loadMebn da classe PrOwlIO para a leitura do
arquivo PR-OWL e posteriormente realiza a leitura do arquivo UBF
para o ajuste de parâmetros internos do UnBBayes.
saveMebn utiliza o método saveMebn da classe PrOwlIO para o armaze-
namento do arquivo PR-OWL e posteriormente realiza a escrita de
parâmetros internos do UnBBayes no arquivo UBF.

A API do Protégé é utilizada no UnBBayes apenas para fazer o carregamento


e o salvamento das ontologias em PR-OWL. As outras funcionalidades da API não
81
foram aproveitadas. Após ser feito o carregamento, a ontologia é armazenada no
modelo de dados do UnBBayes. Para salvar, a ontologia é transferida do modelo
de dados do UnBBayes para o modelo de dados do Protégé e então salva. Esta
independência entre o UnBBayes e o Protégé possibilita que novos formatos para
a persistência de modelos MEBN sejam implementados sem grandes dificuldades.

82
Capı́tulo 6

SSBN - Algoritmos de geração

Para realizar inferência em modelos MEBN, deve-se montar uma rede bayesi-
ana especı́fica para a situação. Com a rede bayesiana montada, o uso é o mesmo
de uma rede normal. A primeira versão do algoritmo de geração de SSBN im-
plementada no UnBBayes foi descrita em [10], porém esta apresentou algumas
limitações e uma nova versão está sendo proposta neste trabalho. Neste capı́tulo
serão descritas as duas versões, detalhando as diferenças e o funcionamento do
algoritmo atual.

6.1 Bottom-Up SSBN Generation

A inferêcia em MEBN é feita através da montagem de uma rede bayesiana


especı́fica para uma dada situação. Quando um questionamento é feito, pri-
meiro procura-se pela informação na base de conhecimento. Caso ela não seja
encontrada, a base de conhecimento e a MTheory geradora são utilizadas para a
montagem da rede bayesiana.

Em [26] é descrito um primeiro algoritmo para a geração da SSBN. Para o


UnBBayes um novo algoritmo foi proposto, visando facilitar a implementação. O
algoritmo utiliza uma abordagem bottom-up para geração dos nós, criando os pais
recursivamente, a partir do nó raiz, que é o nó correspondente ao questionamento
feito.

Segue a formalização do algoritmo, adaptada de [10]:

1. Para uma dada entrada na forma NODE(ENTITY-LIST), procure pela evidência


na base de conhecimento. Se existir uma evidência, termine. Se não, vá
para o próximo passo.

2. Procure pelo nó residente que tem o nome NODE e recupere seu MFrag.
Uma vez encontrado NODE(OV-LIST), verifique se o tipo de ENTITY-LIST é
o mesmo que OV-LIST. Se for o mesmo tipo, vá para o próximo passo. Caso
contrário, retorne erro.
83
3. Monte uma lista contendo todos os nós de contexto que fazem referência
para OV-LIST e não fazem referência a nenhuma variável ordinária não
presente em OV-LIST. Substitua as variáveis de OV-LIST pelos valores de
ENTITY-LIST e avalie os nós de contexto. Caso algum nó de contexto
seja falso, marque o MFrag para utilizar a distribuição padrão. Vá para
o próximo passo.

4. Para cada pai de NODE, vá para o passo inicial (1), substituindo as OV pelas
entidades conhecidas (presentes no questionamento ou na KB).

5. Crie a CPT de NODE.

6. Fim.

A Figura 6.1 mostra a SSBN gerada para a query HarmPotential(ST4, T3) a


partir da ontologia StarTrek. Por não haver evidências para HarmPotential(ST4,
T3) na base de conhecimento (omitida aqui) e pelos nós de contexto terem sido
corretamente avaliados, obtem-se os pais de HarmPotential: DistFromOwn e
StarshipClass. Avaliando-se DistFromOwn(ST4, T3) na base de conhecimento,
verifica-se que não há evidência para ele, repetindo-se o processo, procurando
os seus nós pais. Cada caminho subirá até que seja encontrado uma evidência
ou até que o nó sendo avaliado não possua pais. Há uma evidência na base de
conhecimento para DistFromOwn(ST4, T0), justificando que este nó não tenha
sido criado.

A justificativa utilizada para não transformar os nós que são evidências em nós
da rede (que estava errada, conforme explicado na seção seguinte) é que tendo-se
que o estado do pai de um nó é conhecido, a montagem da tabela do nó filho é
facilitada através da avaliação do seu pseudo-código considerando o dado estado.
A tabela de um nó é gerada assim que a avalição de todos os seus nós pais tiver
sido concluı́da (a tabela de HarmPotential será a ultima a ser construida).

Um dos problemas enfrentados na implementação foi o tratamento dos nós


de contexto que por não conterem as entidades correspondentes as variáveis or-
dinárias, obrigavam a se utilizar todas as entidades que fossem do tipo desejado.
Conforme descrito em [10]:

Isso acontece quando todas as variáveis ordinárias no conjunto de pais


da variável aleatória residente não aparecem no próprio termo resi-
dente. Nesse caso, deve haver um número arbitrário, possivelmente
infinito, de instâncias de um pai para cada instância dada do filho. Por
exemplo, no MFrag Starship, apresentado na Figura 5.13, se a zona
onde a espaçonave está localizada é desconhecida, o número de inimi-
gos e amigos (ZoneEStarships(z) e ZoneFStarships(z)) em cada
zona onde possa estar localizada é relevante para a distribuição da
variável aleatória OpSpec(st). Se o tempo t tiver tempos anteriores,
então, mais de uma distância (DistanceFromOwn(st,tprev)) deve
ser avaliada, fazendo com que distâncias medida em todos os tempos
84
Figura 6.1: SSBN gerada para HarmPotential(ST4, T3) utilizando o Bottom-
Up

sejam relevantes para a distribuição da variável aleatória DistFromOwn


(st,tprev) no tempo t. Logo, qualquer número de instâncias das
variáveis aleatórias ZoneEShips(z), ZoneFShips(z) e
DistFromOwn(st,tprev) podem ser relevantes para a distribuição
das variáveis aleatórias OpSpec(st) e DistFromOwn (st,tprev) no
tempo t. Nesse caso, a distribuição local para a variável aleatória deve
especificar como combinar as influências de todas instâncias relevantes
de seus pais.
Ainda conforme [10], a abordagem descrita pode ter um forte impacto na per-
formance do algoritmo, especialmente em fórmulas complexas. Na implementação
do UnBBayes, optou-se por reportar erro caso a informação necessária não seja
encontrada na base de conhecimento.

O algoritmo implementado permite que sejam definidos limites de passos re-


cursivos, evitando que a criação de pais prossiga indefinidamente. Ao alcançar o
limite estabelecido, o algoritmo para, reportando erro.

O algoritmo apresentado em [27] sugeria que todos os nós de contexto do


MFrag fossem avalidados, antes de utilizá-lo. O algoritmo implementado otimiza
este processo avaliando apenas os nós de contexto referentes às variáveis ordinárias
utilizadas no momento.

6.2 Novo algoritmo de geração de SSBN

O novo algoritmo implementado resolve uma grave limitação do algoritmo an-


terior: como o algoritmo bottom-up montava a rede estritamente de baixo para
85
Figura 6.2: Classes utilizadas na geração do SSBN

cima a partir do nó de questionamento, as evidências que ficavam abaixo do nó


de questionamento não eram consideradas (assim como as evidências que ficas-
sem abaixo de algum dos outros nós criados). A distribuição probabilı́stica a
posteriori de um nó de uma rede bayesiana é influênciada tanto pelos nós pais
quanto pelos nós filhos e portanto a abordagem anterior gerava redes que deixa-
vam de considerar informações importantes para a definição das probabilidades.
Esta foi a principal motivação para o estudo e implementação do algoritmo aqui
apresentado.

6.2.1 Modelagem das classes envolvidas no algoritmo

As figuras 6.2 e 6.3 mostram as principais classes envolvidas no processo de


geração da SSBN. A modelagem foi feita de tal forma a facilitar a criação de
diversas versões do algoritmo (esta preocupação prévia facilitou a construção do
novo algoritmo com mı́nimas modificações necessárias). Segue abaixo a descrição
das interfaces e classes envolvidas.

• Interface ISSBNGenerator contém o método generateSSBN, responsável por


gerar uma rede bayesiana especı́fica a partir de um questionamento (Query).

• Classe AbstractSSBNGenerator contém métodos gerais que podem ser uti-


lizados pelo algoritmo de geração de SSBN independentemente da estratégia
adotada.

• Classe ExplosiveSSBNGenerator implementa o algoritmo de geração de


SSBN utilizando a estratégia descrita nesta seção. Explosive se refere a
forma como os nós são gerados: a rede vai crescendo em todas as direções
(em contra-posição com Bottom-Up, a abordagem anterior).

86
Figura 6.3: Classe SSBNNode e classes relacionadas

• Classe SituationSpecificBayesianNetwork encapsula o resultado da geração


da SSBN: a rede probabilı́stica gerada, a lista dos findings e a lista das que-
ries.
• Classe ContextNodeAvaliator contém os métodos necessários para intera-
gir com a base de conhecimento a fim de realizar as operações necessárias
à avaliação dos nós de contexto no algoritmo de geração de SSBN.
• Classe Query encapsula um questionamento, contendo os objetos necessários
para a inicialização do algoritmo de geração de SSBN.
• Classe SSBNNode é um nó utilizado no algoritmo de SSBN. Encapsula um
nó probabilı́stico que poderá ou não ser utilizado na rede final, dependendo
do atributo permanent, além dos objetos que deram origem a ele: o nó
Residente, juntamente com os objetos OVInstance, que representam os ar-
gumentos do nó Residente instanciado.
• Classe OVInstance representa uma variável ordinária instanciada para uma
entidade.
• Classe ContextFatherSSBNNode é um nó especial, utilizado no algoritmo do
SSBN para representar um nó de contexto que virou pai de um SSBNNode
por ter seu estado indeterminado.

6.2.2 Descrição do algoritmo

Os passos gerais do algoritmo consistem no seguinte:


Passo 1 Montar a rede probabilı́stica com todos os nós necessários para a ava-
liação
87
Passo 2 Montar as CPT para cada um dos nós criados

Passo 3 Retirar os nós não permanentes

Passo 4 Compilar a rede

Passo 5 Setar as evidências e propagá-las

No primeiro passo, para a montagem da rede probabilı́stica, para cada nó


a partir do questionamento (raiz) é feita, recursivamente, a montagem dos nós
abaixo e a seguir a montagem dos nós acima.

Apenas os caminhos abaixo que terminem em um nó de evidência são manti-


dos na rede final. Todos os outros serão eliminados no passo 3 do algoritmo. Para
trabalhar com este conceito, o SSBNNode tem um atributo chamado permanent,
que indica se o nó deverá ser eliminado ou não. As regras que definem se um nó
é permanente são as seguintes:

Regra 1 O SSBNNode correspondente a query é sempre permanente.

Regra 2 Um nó que seja pai de um nó permanente também é permanente (exceto
em casos de findings).

Regra 3 Os nós de finding são sempre permantentes.

Pela regra 2, caso tenhamos um caminho A - B - C - D, onde A é pai de B,


que é pai de C, que é pai de D, caso A seja permanente, B, C e D também o serão.
Isto funciona perfeitamente na busca de evidências abaixo: o algoritmo descerá
recursivamente até encontrar uma evidência e após encontrá-la e setar o nó como
permanente, subirá marcando todos os pais como permanentes.

Uma grande modificação foi feita em relação aos findings: eles aparecem como
nós na rede gerada e possuem uma tabela de distribuição probabilı́stica que deve
ser utilizada na compilação da rede, sendo as evidências setadas apenas poste-
riormente. Para gerar a CPT dos nós de findings, os seus pais são necessários
(o pseudo-código gera CPT considerando os conjuntos de pais do nó), sendo eles
criados temporariamente ainda no passo 1 do algoritmo (estes pais serão perma-
nentes apenas se além de serem pais do nó de finding, se encaixarem em uma das
regras descritas acima).

As CPT são geradas apenas após todos os nós probabilı́sticos terem sido cri-
ados, e não o mais cedo possı́vel, como no algoritmo anterior. No passo 3 os nós
não permanentes (nós filhos em caminhos que não terminam em evidência e pais
temporários dos nós findings) são eliminados.

88
No passo 4 a rede é compilada, com as evidências ainda não setadas como
evidências. No passo 5 estas evidências são setadas e propagadas.

A Figura 6.4 mostra a rede gerada para o questionamento HarmPotential(ST4,


T3 ) utilizando o novo algoritmo.

Figura 6.4: SSBN gerada para HarmPotential(ST4, T3 ) utilizando o novo


algoritmo

DistFromOwn(ST4,T0 ) e CloakMode(ST4 ) são evidências existentes na base


de conhecimento. Observe que enquanto a evidência DistFromOwn(ST4, T0 )
difere do algoritmo Bottom-Up por ser corretamente propagada (alterando, por-
tanto, as distribuições a posteriori dos nós da rede), a evidência CloakMode(ST4 )
nem ao menos era considerada no outro algoritmo.

89
Capı́tulo 7

Análise de qualidade e
manutenção

7.1 Profiling e Tuning

Figura 7.1: Tela de profiling do TPTP. É possı́vel analisar seqüência de execução


e gerar diagramas UML de seqüência.

90
Figura 7.2: Tela de log (esquerda) e testes (direita) do TPTP.

O plugin TPTP (Test & Performance Tools Platform Project)[3] do ambiente


de desenvolvimento Eclipse foi utilizado como ferramenta para a análise de tempo
de execução e uso de memória do UnBBayes-MEBN na geração de SSBN da on-
tologia StarTrek (vide Seção 8.1). O algoritmo utilizado para a geração de SSBN
foi a descrita na Seção 6.1.

O Eclipse TPTP, isolado, é um framework para a construção de ferramentas


de teste e análise de performance. Sua distribuição padrão é acompanhada por
um ambiente integrado de teste JUnit, analisador de desempenho (tanto local ou
remoto), mecanismo de inserção de código em bytecode e um analisador gráfico
de logs de sistemas; úteis durante todo o ciclo de vida de desenvolvimento de
sistemas. As figuras 7.1 e 7.2 mostram capturas de tela da ferramenta.

Para a coleta de informações de desempenho, uma ferramenta adicional é uti-


lizada pelo TPTP. O AgentController. Essa ferramenta gerencia um processo
daemon que interliga dois processos clientes. O TPTP, rodando no Eclipse, aces-
sará o aplicativo testado com o intermédio do AgentController. Tanto o TPTP
quanto o AgentController podem ser obtidos no site principal [3].

Basicamente, os seguinte passos foram testados na avaliação de performance


do UnBBayes-MEBN:

1. inicialização do UnBBayes;

2. abertura do arquivo UBF do StarTrek (e conseqüentemente de um arquivo


PR-OWL associado);

3. abertura da base de conhecimento PLM que incorpora evidências ao arquivo


PR-OWL aberto anteriormente;

4. execução da query de HarmPotential(ST4,T3);

91
5. propagação de evidência dos nós DistFromOwn(ST4,T3), DistFromOwn(ST4,T2)
e DistFromOwn(ST4,T1) do SSBN gerado para o estado Phaser2Range;

6. armazenamento do arquivo PLM;

7. armazenamento do arquivo UBF (PR-OWL).

O laudo foi armazenado em arquivos HTML. Os laudos da avaliação dos dez


maiores tempos de execução para o UnBBayes, antes e depois das otimizações,
estão apresentados respectivamente nas figuras 7.3 e 7.4.

A análise de memória resultou nas seguintes observações:

classe NodeList : grande uso de memória total.

classe Compiler : elevado número de instâncias, e classes internas utilizavam


elevada quantidade de memória.

Uma refatoração completa da classe NodeList foi realizada através de sua


substituição pela classe ArrayList<Node>, classe padrão da linguagem. Infe-
lizmente, tal substituição não acarretou aumento significativo de performance
(tempo ou memória); entretanto, acredita-se que a classe tenha se tornado thread-
safe.

A classe Compiler destacava-se como os dez maiores gargalos tanto no tempo


de execução quanto no uso de memória. Isso era efetivamente causado pela árvore
de expressões booleanas e matemáticas da tabela temporária. Como essa árvore
era sempre acessada duas vezes (uma durante a análise semântica do pseudo-
código e outra na geração da tabela definitiva), era possı́vel “podar” galhos cujo
valor seja estático - independente das instâncias de entidades e variáveis aleatórias
nas situações especı́ficas - durante o processo de análise semântica.

A alteração acima tornou o novo compilador até dez vezes mais eficiente do
que o seu antecessor, para pseudo-códigos suficientemente complexos. As figuras
7.3 e 7.4 mostram tal diferença. O uso de memória também tem decaı́do, graças
ao fato das expressões se tornarem mais compactas, pois sub-expressões estáticas
eram substituı́das pelo seu valor numérico.

7.2 Manutenibilidade

O UnBBayes-MEBN possui alguns pontos de extensão, onde incorporações de


diferentes tecnologias podem ser feitas. Esses pontos são particularmente úteis

92
quando ocorrem alterações de especificações ou quando tecnologias tornam-se ob-
soletas.

Alguns pontos de extensão são:

Interface ICompiler : extensão para o tratamento de CPT. É possı́vel que em


algum futuro próximo as especificações que definem a declaração de CPT
em MEBN sejam alteradas, ou mais de uma especificação esteja em vigor.
Classes que implementam ICompiler são pontos de acesso da GUI e do
algoritmo de geração de SSBN para a especificação da CPT em MEBN,
podendo ser criados novos compiladores implementando-se essa interface.
Adicionalmente, como o UnBBayes-MEBN permite o uso de instâncias di-
ferentes de compiladores para cada nó, é possı́vel que nós de uma mesma
MTheory usem declarações diferentes de CPT.

Interface ISSBNGenerator : diversos algoritmos de geração de SSBN podem


conviver no UnBBayes-MEBN pela implementação desta interface.

resources : as classes ResourceBundle permitem a seleção automática de re-


cursos de acordo com a localidade do usuário. Classes que estendem
ResourceBundle podem armazenar mensagens em diversas lı́nguas; permi-
tindo a fácil internacionalização do software.

Interface KnowledgeBase : serve de ponto de acesso do UnBBayes à engine


FOL. Podemos utilizar API diferentes de FOL utilizando uma implementação
dessa interface.

Interface MebnIO : ponto de acesso aos mecanismos de armazenamento de MThe-


ory. Atualmente, o formato PR-OWL (através da classe PrOwlIO) é uti-
lizado. Com o surgimento de novos formatos de arquivos, mais imple-
mentações de MebnIO podem se tornar necessárias.

7.2.1 Simplicidade estrutural

No presente trabalho, a estrutura geral de MFrags do UnBBayes-MEBN pas-


sou por uma série de refatorações para eliminar classes redundantes que somente
atuavam como uma camada adicional de abstração1 . A exemplo:

• Classes como GenerativeInputNode e InputNode foram integradas para


InputNode.

• Classes como ResidentNode e DomainResidentNode foram integradas para


ResidentNode.
1
Classes que não representavam funcionalidade própria e não eram generalizações de duas
classes distintas.

93
• Classes como MFrag e DomainMFrag foram integradas para MFrag.

• MEBNTableParser foi eliminada e integrada à classe Compiler.


Essas alterações diminuı́ram drasticamente a complexidade do framework,
com mı́nima perda de generalização.

7.3 Outras alterações importantes

7.3.1 Compatibilidade OWL - PR-OWL

Na versão anterior do UnBBayes-MEBN, o carregamento de arquivos PR-


OWL somente considerava as partes probabilı́sticas da ontologia, descartando
qualquer porção não-probabilı́stica. Portanto, ao salvar tal ontologia, toda a in-
formação não-probabilı́stica era perdida.

Esse tipo de problema foi resolvido através do armazenamento em memória


dos objetos OWLModel2 , oferecidos pela API do protégé. Tais objetos são ligados
à classe que representa uma MTheory3 . Para evitar o forte acoplamento entre
classes de representação com classes de persistência, foi utilizada uma combinação
parcial das design-patterns Bridge e Decorator.

O diagrama de classes que implementam essa nova funcionalidade está apre-


sentado na Figura 7.5. As figuras 7.6 e 7.7 detalham os passos de como esse me-
canismo mantém o OWLModel em memória, para que porções não-probabilı́sticas
da ontologia possam ser persistidas.
IBridgeImplementor : interface de utilidade que deve ser implementada pelas
classes que utilizam Bridge design-pattern em algum nı́vel de abstração.
MEBNStorageImplementorDecorator : classe responsável por implementar me-
canismos de persistência de dados da MTheory. Ela está responsável por
manter a OWLModel acessı́vel pela MTheory de forma indireta.

As classes que utilizam a OWLModel devem implementar a interface


IProtegeOWLModelUser. A classe PrOwlIO, que fornece uma camada de per-
sistência para arquivos PR-OWL, implementa a interface PROWLModelUser, que
é uma especialização do IProtegeOWLModelUser.

Adicionalmente, descrições/comentários da PR-OWL tornaram-se editáveis


via interface gráfica do UnBBayes.
2
O OWLModel é a classe que permite acesso a todos os elementos da ontologia em OWL
3
Seja, a classe MultiEntityBayesianNetwork

94
Figura 7.3: Laudo de tempo-base antes da otimização

95
Figura 7.4: Laudo de tempo base de execução após a otimização.

96
Figura 7.5: Diagramas de classe da compatibilidade OWL - PR-OWL

Figura 7.6: Seqüência de carregamento de arquivo PR-OWL, mantendo o OWL-


Model em memória.

97
Figura 7.7: Seqüência de armazenamento de arquivos PR-OWL mantendo OWL-
Model em memória.

98
Capı́tulo 8

Ontologias - StarTrek e
PizzaVinho

As duas ontologias apresentadas neste capı́tulo foram utilizadas para validar


a implementação de MEBN no UnBBayes. A ontologia StarTrek, apresentada em
[15] consiste em um dominio de brinquedo criado para exemplificar as construções
da PR-OWL. A ontologia Pizza e Vinho foi criada como parte dos trabalhos de
desenvolvimento do UnBBayes e baseia-se em duas ontologias bastante conhecidas
na literatura à saber: a ontologia para Pizzas e a ontologia para Vinhos e
Comidas. As seções seguintes descrevem as duas ontologias.

8.1 Ontologia StarTrek

A Figura 8.1 mostra a MTheory sugerida em [15] para modelagem do domı́nio


StarTrek.

Figura 8.1: MTheory para o domı́nio StarTrek

A MTheory implementada no UnBBayes não necessita de MFrags IsA, Entity


Type, e TimeStep. Tais MFrags são utilizados como base para algumas cons-
truções da MTheory apresentada. O UnBBayes possuı́ implementações internas
99
que fornecem a base para tais construções, eliminando a necessidade da cons-
trução de tais MFrags.

Abaixo, estão descritos os MFrags modelados no UnBBayes.

MFrag StarshipData

Figura 8.2: MFrag StarshipData

• Variáveis ordinárias:

st tipo Starship. + a espaçonave que possui os sensores.

• Nós residentes:

StarshipZone indica em que zona a espaçonava espaçonave st se encon-


tra. Os possiveis valores são as instâncias da entidade Zone existentes
na base de conhecimento (base de conhecimento aqui se refere a si-
tuação especı́fica, ou seja, as instâncias de entidades e evidências que
consituem a situação para a qual a rede bayesiana será montada).
IsOwnStarship variável booleana que indica se st é a própria espaçonave.
A princı́pio, seu condicionante deveria ser um nó de identidade (veja
Figura 8.1), mas como o UnBBayes ainda não implementa esses nós,
IsOwnStarship foi mantido sem pai.

• Nós de contexto:

Exists garante que a espaçonave st está presente na base de conheci-


mento.

MFrag SRData

• Variáveis ordinárias:

sr tipo SensorReport. Representa o relatório obtido pelo sensor.

100
Figura 8.3: MFrag SRData

• Nós residentes:

Subject tem como seu valor possı́vel todas as entidades que podem ser
objeto do relatório sr do sensor, ou seja, as instância da entidade
Starship. A distribuição de probabilidades é uniforme.

MFrag Zone

Figura 8.4: MFrag Zone

• Variáveis ordinárias:

t tipo TimeStep. Representa o tempo atual. Entidade ordenável utilizada


nesse MFrag para recursividade temporal.
tPrev tipo TimeStep. Tempo imediatamente anterior ao tempo t .
z tipo Zone. Zona onde se encontra a espaçonave st no momento t .
st tipo Starship. Espaçonave cujo CloakMode é testado.

• Nós de entrada:

101
ZoneMD representa o nó residente de mesmo nome, presente no mesmo
MFrag. Esta construção é utilizada para a modelar a recursividade
temporal.
CloakMode representa o nó residente, presente no MFrag Starship.

• Nós residentes:

ZoneNature nó sem condicionante que representa a natureza de uma zona.


Possui como possı́veis valores BlackHoleBoundary, DeepSpace e
PlanetarySystem.
ZoneMD representa o valor de distúrbio magnético na zona z no tempo t .
ZoneFShips relaciona a possibilidade de uma zona conter naves amigas ao
redor.
ZoneEShips relaciona a possibilidade de uma zona conter naves inimigas
ao redor.

• Nós de contexto:

(StarshipZone(st ) = z ) indica que para as distribuições de probabili-


dade apresentadas no MFrag sejam válidas, a zona z deve ser a zona
onde a espaçonave st se encontra.

MFrag DangerToOthers

Figura 8.5: MFrag DangerToOthers modelada no UnBBayes.

• Variáveis ordinárias:

t tipo TimeStep. Representar o tempo atual.

102
s tipo Starship. É a própria espaçonave testada.
st tipo Starship. É a espaçonave cuja distância com s é testada.

• Nós de entrada:

DistFromOwn representa o nó residente, presente no MFrag Starship.

• Nós residentes:

DangerToOthers representa a capacidade da espaçonave s de infligir perigo


a espaçonave st .

• Nós de contexto:

IsOwnStarship indica que a espaçonave s é a própria espaçonave.


(not(s = st )) garante que as duas espaçonaves s e st são distintas.

MFrag DangerToSelf

Figura 8.6: MFrag DangerToSelf

• Variáveis ordinárias:

t tipo TimeStep. Representa o tempo atual.


s tipo Starship. É a própria espaçonave testada.
st tipo Starship. É a espaçonave que representa um perigo potencial para
a espaçonave s.

• Nós de entrada:

103
HarmPotential representa o nó residente, presente no MFrag
Starship.
OpSpec representa o nó residente, presente no MFrag
Starship.

• Nós residentes:

DangerToSelf representa o perigo que a própria espaçonave s está exposta


no tempo t .

• Nós de contexto:

IsOwnStarship indica que a espaçonave s é a própria espaçonave.


(not(s = st )) garante que as duas espaçonaves s e st são distintas.

MFrag SensorReport

Figura 8.7: MFrag SensorReport

• Variáveis ordinárias:

t tipo TimeStep. Representa o tempo atual.


sr tipo SensorReport. Indica o relatório obtido pelo sensor.
st tipo Starship. Espaçonave cuja distância com a espaçonave s é tes-
tada.

• Nós de entrada:

Exists representa o nó residente, presente no MFrag


StarshipExistance.

104
CloakMode representa o nó residente, presente no MFrag Starship.
StarshipClass representa o nó residente, presente no MFrag Starship.
DistFromOwn representa o nó residente, presente no MFrag Starship.

• Nós residentes:

SRClass representa que tipo de classe de espaçonave foi reportada por sr


em um tempo t .
SRDistance representa a distância reportada entre a própria espaçonave e
a espaçonave detectada pelo relatório sr no tempo t .

• Nós de contexto:

not IsOwnStarship indica que a espaçonave s não é a própria espaçonave.


(Subject(sr ) = st ) garante que a espaçonave st é a reportada pelo sen-
sor em sr .

MFrag Starship

Figura 8.8: MFrag SRData

• Variáveis ordinárias:

t tipo TimeStep. Representa o tempo atual. É uma entidade ordenável


que será utilizada nesse MFrag para recursividade temporal.
105
tPrev tipo TimeStep. Indica o tempo imediatamente anterior a t .
st tipo Starship. Espaçonave cuja distância com a espaçonave s é tes-
tada.
z tipo Zone. Zona em que st está contida.

• Nós de entrada:

DistFromOwn representa o nó residente, presente no mesmo MFrag. Mais


um caso de recursividade.
ZoneEShip representa o nó residente, presente no MFrag Zone.
ZoneFShip representa o nó residente, presente no MFrag Zone.

• Nós residentes:

DistFromOwn representa a distância entre a própria espaçonave e a espaçonave


st. A distância é medida de acordo com o alcance das armas disponı́veis
(este nó pode ser utilizado para se fazer questionamentos sobre que tipo
de arma se deve utilizar contra uma espaçonave st). Seus possı́veis va-
lores são: OutOfRange, TorpedoRange, Phaser2Range, Phaser1Range,
PulseCanonRange e absurd.
HarmPotential representa o potencial de st em danificar a espaçonave
s no tempo t . Não representa a intenção, e sim a possibilidade de
danificar ou não.
OpSpec representa a espécie que está pilotando a espaçonave st . Seus
possı́veis valores são: Cardassian, Friend, Klingon, Romulan, Unknown
e absurd.
StarshipClass representa a classe da espaçonave st . Seus possı́veis valo-
res são WarBird, Cruiser, Explorer, Frigate, Freighter e absurd.
CloakMode variável booleana que indica se a espaçonave em questão está
em modo invisı́vel.

• Nós de contexto:

not IsOwnStarship indica que a espaçonave st não é a própria espaçonave.


Exists garante que a espaçonave st existe na situação especı́fica.
(StarshipZone(st ) = z ) indica que a zona z é onde a espaçonave st
está contida.

MFrag StarshipExistence

• Variáveis ordinárias:

z tipo Zone. Zona onde se encontra a espaçonave st no momento t .


st tipo Starship. Espaçonave cujo CloakMode é testado.
106
Figura 8.9: MFrag SRData

• Nós de entrada:

ZoneFShips representa o nó residente de mesmo nome, presente no MFrag


Zone.
ZoneEShips representa o nó residente de mesmo nome, presente no MFrag
Zone.

• Nós residentes:

Exists representa se uma espaçonave está presente em uma determinada


zona dado as chances de existência de inimigos (ou amigos) na zona.
Possui valor booleano.

• Nós de contexto:

(StarshipZone(st ) = z ) indica que a zona z é a zona onde a espaçonave


st se encontra.

8.2 Ontologia Pizza e Vinho

A ontologia Pizza e Vinho desenvolvida procura juntar duas ontologias bem


conhecidas na literatura e montar uma ontologia probabilı́stica. O objetivo de tal
ontologia é permitir que uma pessoa faça inferências a respeito de combinações
entre pizzas e vinhos, como por exemplo: “Que vinho é recomendado para acom-
panhar uma pizza Margherita”.

Não houve presença de especialista na montagem da ontologia. O resultado


obtido é uma ontologia de brinquedo, necessitando de um melhor estudo caso haja
interesse em utilizá-la em aplicações reais. Contudo, ela mostrou-se útil para criar
situações de teste para validar a implementação do UnBBayes.

107
A ontologia Pizza utilizada como base para este trabalho baseia-se na versão
apresentada em [23], que por sua vez baseia-se na ontologia utilizada em um curso
de edição de ontologias DAML+OIL em OilEd(http://oiled.man.ac.uk), realizado na
University Of Manchester.

A ontologia Comidas e Vinho utilizada, baseia-se na versão encontrada no


guia da linguagem OWL criado pelo W3C, disponı́vel no site
http://www.w3.org/TR/owl-guide/. Esta versão foi construı́da a partir da onto-
logia criada por McGuiness como um exemplo de lógica descritiva (disponı́vel no
site
http://www.w3.org/TR/2004/REC-owl-guide-20040210/#wine3).

Ainda como base para este trabalho, utilizou-se a ontologia Pizza e Vinho
descrita em [18] e exemplificada na Figura 8.10 extraı́da de [18] e reproduzida
aqui com a devida autorização dos autores.

Figura 8.10: Uma sugestão de MTheory para a ontologia Pizza e Vinho, extraı́da
de [18]

As seções seguintes descrevem os MFrags montados neste trabalho.

8.2.1 MFrag Pizza

• Variáveis ordinárias:
p tipo Pizza. Representa uma pizza.
t tipo Topping. Representa uma cobertura de pizza.
w tipo Wine. Representa um vinho.
• Nós residentes:
108
Figura 8.11: MFrag Pizza

WineBody representa o corpo do vinho w , tendo os possı́veis valores Light,


Medium e Full.
WineFlavour representa o sabor do vinho w , tendo os possı́veis valores
Delicate, Moderate e Strong.
WineColour representa a coloração do vinho w , tendo os possı́veis valores
White, Rose e Red.
WineSugar representa o nı́vel de açucar do vinho w , tendo os possı́veis
valores Sweet, Dry e OffDry.

• Nós de contexto:

ServedTogether(p,w) garante que a pizza p e o vinho w são servidos jun-


tos.
ToppedBy(p,t) garante que t é cobertura de p.

8.2.2 MFrag Served Together

• Variáveis ordinárias:

p tipo Pizza. Representa uma pizza.


t tipo Topping. Representa uma cobertura de pizza.

• Nós residentes:

109
Figura 8.12: MFrag Served Together

ServedTogether propriedade booleana que liga uma pizza a um vinho,


indicando se os dois são servidos juntos ou não.

8.2.3 MFrag Topped By

Figura 8.13: MFrag Topped By

• Variáveis ordinárias:

p tipo Pizza. Representa uma pizza.


t tipo Topping. Representa uma cobertura de pizza.

• Nós residentes:

ToppedBy propriedade booleana que indica se uma pizza p possui t como


cobertura.

110
8.2.4 MFrag Wine

Figura 8.14: MFrag Wine

• Variáveis ordinárias:

w tipo Wine. Representa um vinho.

• Nós residentes:

WineType Representa o tipo de um vinho.

• Nós de entrada:

WineBody refere-se ao nó residente no MFrag Pizza.


WineFlavour refere-se ao nó residente no MFrag Pizza.
WineColour refere-se ao nó residente no MFrag Pizza.
WineSugar refere-se ao nó residente no MFrag Pizza.

8.2.5 Algumas considerações

A ontologia apresentada utiliza como entidades apenas o vinho, a pizza e a co-


bertura da pizza. A complexidade do exemplo poderia ser facilmente aumentada
considerando outras entidades no modelo. O cliente, por exemplo, poderia ser
colocado como entidade, podendo ser considerados os seus gostos. A modelagem
das propriedades do vinho poderia incluir coisas como o tipo de uva, a safra ou a

111
região onde ele foi produzido (estas seriam outros nós residentes).

Uma forma de adicionar recursividade na ontologia proposta é ilustrada na


Figura 8.15. A idéia é levar em consideração ao se escolher um vinho para uma
pizza, o vinho indicado anteriormente para que uma pessoa possa, por exemplo,
escolher dois vinhos diferentes ao consumir uma pizza.

Figura 8.15: MFrag Wine com recursividade

8.3 Processo de modelagem de ontologias pro-


babilı́sticas

Uma modelagem qualitativa de um domı́nio poderia ser feita utilizando os


seguintes passos:

1. Identificação e delimitação do problema a ser resolvido.

2. Identificação das entidades (elementos) do dominio. Caso haja dificuldade


em se definir as entidades ou haja apenas uma entidade, é provável que
a MEBN não seja a abordagem ideal para a resolução do problema (no
segundo caso, provavelmente uma rede bayesiana normal poderá ser utili-
zada).

3. Identificar agrupamentos lógicos (entender que existem “grupos” de in-


formações que estão ou poderiam estar logicamente agrupados) para que
se possa ter uma idéia abstrata de um “conjunto” de entidades.

112
4. Identificar critérios que possam classificar de alguma maneira as entidades
identificadas, para que possa ser definido quais entidades são importantes
para a resolução do problema e quais podem ser descartadas. Este passo
pode ajudar a detectar incertezas sobre “existência” de informação ou para
identificar “contextos” em que uma determinada informação possa ser con-
siderada “válida”.

5. Identificar os atributos que as entidades/variáveis possuem (valores que uma


entidade/variável pode assumir).

6. Se um valor identificado no passo anterior for contı́nuo, decidir como deve


ser feita a discretização. Caso os valores sejam discretos, porém pertencentes
a um conjunto vasto, pode-se optar por dividı́-los em partições.

7. Identificar regras que relacionem entidades presentes em um mesmo agru-


pamento lógico e regras que relacionem entidades em grupos diferentes.

8. Avaliar se MEBN é necessário e/ou suficiente para modelar o problema.

9. Avaliar se as entidades identificadas são suficientes para a modelagem em


MEBN).

10. Mapear as entidades, agrupamentos, restrições e relações identificadas para


os elementos da MEBN (MFrag, Node).

11. Implementar o modelo no UnBBayes. Neste passo, algumas alterações po-


dem ser necessárias na modelagem original devido as singularidades do UnB-
Bayes (como por exemplo a forma como o UnBBayes modela a recursivi-
dade, ou as restrições que ele faz na definição dos possı́veis valores de uma
variável residente).

113
Capı́tulo 9

Projeto de identificação humana


baseada em raciocı́nio
probabilı́stico

A pesquisa visou estabelecer, por intermédio de procedimentos de inteligência


artificial do tipo raciocı́nio ontológico probabilı́stico, a relação entre sexo e diver-
sas variáveis perceptı́veis na face de pessoa viva. A saber:

• idade,

• proeminência da glabela1 ,

• inclinação da fronte2 ,

• forma mentoniana3 ,

• projeção mentoniana,

• forma dos dentes anteriores4 e

• forma orbitária5 .

Cada variável foi classificada, por observação direta, entre quatro alternativas.
A amostra para este estudo tem 1.401 pessoas, tendo em vista a variabilidade dos
atributos, a subjetividade das informações e a necessidade de dois grupos, um
para criação do modelo probabilı́stico e outro para validação. Os sujeitos da
pesquisa foram recrutados em vias públicas, após explanação e obtenção de Con-
sentimento Livre e Esclarecido previamente aprovado pelo Comitê de Ética em
1
Glabela é a região proeminente compreendida entre as sobrancelhas.
2
A fronte é a parte superior frontal do crânio, também conhecida como “testa”.
3
O mento é a parte inferior da face, abaixo do lábio inferior; vulgarmente conhecida como
queixo.
4
Os incisivos (dentes anteriores) são os dentes que cortam alimentos, situados na parte
anterior dos dois maxilares.
5
Órbita seria relativa à cavidade ocular.

114
Pesquisa da Universidade de Brası́lia. Não foram sujeitos deste estudo analfabe-
tos, civilmente incapazes, ou pessoas em situações de vulnerabilidade, conforme
Resolução CNS 196/96. O banco de dados obtido foi dividido aleatoriamente
em dois conjuntos, um de 934 (2/3 do total) registros destinado à criação de um
modelo probabilı́stico e o segundo, de 467 registros (1/3 do total), para validação
do modelo.

9.1 Membros da equipe de pesquisa

• Laécio Lima dos Santos - Graduando em Ciência da Computação na


UnB

• Fábio Cardoso Tristão - Prof. de Medicina Legal da UNIPLAC

• Malthus Fonseca Galvão6 - Prof. de Medicina Legal da Faculdade de


Medicina da UnB

• Marcelo Ladeira7 - Prof. Adjunto do Departamento de Ciência da Com-


putação da UnB.

• Paulo Cesar Guerreiro da Costa - Prof. da Volgenau School of Infor-


mation Technology & Engineering - George Mason University - EUA

• Rommel Novaes Carvalho - Mestrado em Informática na UnB

• Shou Matsumoto - Graduando em Ciência da Computação na UnB

9.2 Descrição do projeto

A identificação humana é tema que sempre despertou interesse pelas aplicações


tanto na pessoa viva como no cadáver. O processo de identificação humana é rea-
lizado em três etapas distintas, a identificação genérica, a especı́fica e a individual.

Identificação genérica é o processo que visa à constatação de que o anali-


sado se trata de uma pessoa, um cadáver humano ou fragmentos humanos. Na
pessoa viva pode parecer absurdo que possa restar alguma dúvida, entretanto,
em determinadas condições, como em uma filmagem de baixa qualidade, contra a
luz, um vulto pode parecer humano sem o ser e também o contrário pode ocorrer.
No cadáver, em especial na fase de putrefação, o desavisado pode confundir uma
massa pútrida humana com uma animal, ou o contrário. Ossos isolados também
6
Responsável Médico do experimento
7
Responsável em Ciência da Computação do experimento

115
podem trazer certa dificuldade na determinação da espécie. Em pequenos frag-
mentos, de tecidos moles, ossos ou dentes, nos quais a anatomia macroscópica
não seja suficiente, pode-se utilizar exames histológicos, imunológicos ou genéticos
para determinação da espécie.

Identificação especı́fica é processo que visa determinar caracterı́sticas da


pessoa ou do cadáver, como a estatura, idade, etnia, sexo, presentes em todos,
além de caracterı́sticas eventuais como malformações, cicatrizes, calos ósseos, as-
simetrias entre outros. Este processo é fundamental para a triagem preliminar
em uma identificação quando o universo de pessoas ou cadáveres ou de suspeitos
é grande. No caso de um desastre de massa, com elevado número de vı́timas
fatais a serem identificadas, recomenda-se dividir o grande problema em desafios
menores, o que se obtém pela separação em grupos.

Identificação individual é o processo pelo qual se estabelece uma corres-


pondência entre pessoas ou entre pessoa e cadáver. Este processo depende do
confronto de informações, preferencialmente únicas, imutáveis e perenes. Como
exemplo encontram-se a papiloscopia, a antropologia forense e a genética forense.
Neste processo o que se obtém é uma probabilidade de correspondência, que de-
penderá da quantidade e da qualidade dos atributos confrontados.

No processo de identificação, a determinação do sexo é de fundamental im-


portância, pois divide o universo em dois, reduzindo pela metade as dificuldades.
É certo que, em casos de cadáveres esqueletizados, vı́timas de violência, a proba-
bilidade maior é de que se trate de individuo do sexo masculino.

No esqueleto, o sexo pode ser macroscopicamente observado por diversos atri-


butos, sendo os melhores localizados na cintura pélvica, seguidos dos situados
no crânio. Muitos dos atributos cranianos podem ser facilmente observados na
pessoa viva, sem grandes distorções, o que possibilita a implementação de rotinas
computadorizadas para identificação humana.

9.2.1 Objetivo principal

O objetivo deste trabalho é verificar, por intermédio de um modelo proba-


bilı́stico, composto por uma rede bayesiana multi-entidade (MEBN) e respectiva
ontologia probabilı́stica, a probabilidade do acerto na determinação do sexo por
cada um dos atributos analisados e pelo conjunto dos mesmos.

9.2.2 Hipótese

Um sistema apoiado em ontologias e inteligência artificial (raciocı́nio proba-


bilı́stico) pode prever, probabilisticamente, o sexo por atributos faciais.

116
9.2.3 Material e método

A escolha dos atributos embasou-se na possibilidade de constatação por sim-


ples observação direta, evitando-se, por conseguinte, a necessidade de local es-
pecial para análise, desnudamento, de aparelhos especiais e de qualquer tipo de
constrangimento para os sujeitos da pesquisa. Os seis atributos selecionados,
já conhecidos da literatura como elementos do dimorfismo sexual [6][13][33], fo-
ram inicialmente classificados em quatro estados, de forma subjetiva, conforme o
formulário a seguir:

Figura 9.1: Formulário para coleta de dados

Os pesquisadores que fizeram a coleta dos dados receberam instruções e treina-


mento para homogeneizar as observações e formas de abordagem e perguntaram,
para os sujeitos da pesquisa, a idade cronológica e o sexo e observaram de forma
direta, sem uso de instrumentos clássicos de medida, os atributos cranianos acima
relacionados. Os dados foram anotados em fichas de papel. Os sujeitos da pes-
quisa não foram fotografados. Posteriormente, os dados foram digitalizados para
formação de um banco de dados.

A amostra para este estudo teve 1.401 pessoas, tendo em vista a variabilidade
dos atributos analisados, a subjetividade das informações e a necessidade de dois

117
grupos, um para criação do modelo probabilı́stico e outro para validação.

Os sujeitos da pesquisa foram recrutadas em vias públicas8 , após breve ex-


planação e obtenção de consentimento livre e esclarecido, previamente aprovado
pelo Comitê de Ética em Pesquisa da Faculdade de Medicina da Universidade de
Brası́lia.

No momento da coleta dos dados, as observações foram anotadas em fichas de


papel e, posteriormente, inseridos em um banco de dados do Microsoft Access.

Os registros foram aleatoriamente divididos em dois, observadas as proporções


populacionais para sexo e idade, na proporção de dois para um, sendo o primeiro
destinado à criação de um modelo probabilı́stico, e o segundo para validação deste
modelo.

9.2.4 Responsabilidades

A pesquisa de campo, projeto e população da base de dados ficou sob a super-


visão do Professor de Medicina Legal da Universidade de Brası́lia, Malthus Fon-
seca Galvão, e a modelagem do domı́nio probabilı́stico sob a supervisão do Pro-
fessor do Departamento de Ciência da Computação da Universidade de Brası́lia,
Marcelo Ladeira.

9.2.5 Da publicidade dos resultados

Os resultados obtidos pela pesquisa serão publicados, independentemente da


extensão das conclusões.

9.3 Análise dos resultados

Os dados coletados estão organizados da maneira descrita na Seção 9.2.3. Os


valores possı́veis podem ser observados na Figura 9.1.

9.3.1 Passos gerais para modelagem do domı́nio

Como dito na Seção 8.3, um modelador de domı́nio guiado por dados pode
passar pelas seguintes etapas9 :

8
Não foram sujeitos da pesquisa analfabetos do ponto de vista prático, pessoas civilmente
incapazes ou em situação de vulnerabilidade, conforme Resolução CNS 196/96
9
Podemos também utilizar metodologias padrões de análise de dados, como o CRISP-DM,
o que não foi feito na presente pesquisa por termos acesso a um especialista.

118
1. Identificar o(s) conjunto(s) de problema(s) que deve(m) ser resolvido(s). No
nosso exemplo, isso já foi restrito à identificação do sexo de um indivı́duo.

2. Selecionar em qual(is) problema(s) a modelagem deve focar para que o


formalismo computacional o(s) resolva(m). No nosso caso, seria identificar
o sexo de um10 indivı́duo.

3. Identificar elementos decisórios no domı́nio, de acordo com o problema que


se quer resolver. No nosso exemplo, a coleta de dados já foi guiada por esse
objetivo. Foram identificadas para os indivı́duos/pessoas as caracterı́sticas
da estrutura cranial/facial (proeminência do mento, arredondamento do
mento, fronte, incisivos superiores, órbita, glabela), a idade e o sexo como
variáveis/entidades.

4. Identificar agrupamentos lógicos - entender que existem “grupos” de in-


formações que estão ou poderiam estar logicamente agrupados - para que
possamos obter idéias abstratas de um “conjunto” de entidades/variáveis.
No nosso exemplo, dois grupos principais foram identificados: caracterı́stica
facial (mento, fronte, incisivos superiores, órbita, glabela) e não facial (idade
e sexo). Isso pode ser útil na identificação de MFrags.

5. Identificar critérios e condições que possam comprometer o sentido dos ele-


mentos identificados. Por exemplo, identificar elementos que “deixem de
existir” ou “deixem de influenciar” em determinadas configurações. Ex. Se
campos são obrigatórios, prioridade dos dados. Isso pode nos ajudar a de-
tectar incertezas sobre “existência” de informação ou descartar elementos
insignificantes; ou até para identificar “contextos” em que uma determinada
informação possa ser considerada “válida”.

6. Identificar os atributos que as entidades possuem - valores que uma enti-


dade pode assumir. A exemplo, temos a classificação de proeminência da
glabela em: pouco proeminente, nada proeminente, proeminente e muito
proeminente.

7. Se algum valor identificado no passo anterior for um valor contı́nuo ou pos-


suir muitos valores, decidir como poderı́amos discretizá-los. No nosso exem-
plo, a idade entraria nessa classe de valores.

8. Identificar regras de negócios que relacionem entidades/variáveis presentes


em um mesmo agrupamento lógico. No nosso exemplo, intuitivamente sa-
bemos que a proeminência e o arredondamento do mento estão intimamente
ligados; o mesmo ocorre com a proeminência da glabela e a inclinação da
fronte.

9. Identificar regras de negócios que relacionem entidades presentes em agrupa-


mentos lógicos diferentes. No nosso exemplo, estudos da anatomia humana
indicam que o sexo e a idade determinam o formato craniano.//
10
Foi descoberto posteriormente que esse um (1) foi um marco decisório no fracasso da mo-
delagem em MEBN.

119
Alguns dos passos acima exigem a presença de um especialista no domı́nio, ou
de pelo menos um membro que o entenda abstratamente. A partir desta etapa,
o(s) modelador(es) MEBN podem realizar os seguintes passos:

1. Avaliar se MEBN seria necessário, suficiente e plausı́vel para solucionar o


problema; verificando se as entidades identificadas são suficientes também
para a modelagem em MEBN.

2. Mapear as entidades, variáveis, agrupamentos, restrições e relações identifi-


cadas para os elementos tratados pela MEBN (MFrag, Nós). É a etapa de
modelagem propriamente dita.

3. Caso necessário, ajustar o modelo - ou a ferramenta - para que o modelo


seja computável em tempo razoável. Simplificações (ou complicações) adi-
cionais podem ser feitas.

Com isso, já podemos identificar primordialmente os seguintes fatos:

• Variável de classe (objetivo): sexo.

• Possı́veis entidades são: Pessoa e Idade.

• Possı́veis variáveis aleatórias são: Idade, sexo, fronte, glabela, arredonda-


mento do mento, proeminência do mento, órbita e incisivos superiores.

• Relações macroscópicas: o sexo e a idade (se modelado como variável) in-


fluenciam todas outras variáveis.

• Outras relações serão identificadas por análise computacional dos dados.

Infelizmente, o fato da análise do sexo ser somente para um (1) único indivı́duo
implica que todas as outras possı́veis variáveis (como idade, mento ou glabela)
estejam relacionadas uma única vez com a variável sexo; pois como cada dado
coletado representa uma única pessoa por vez e sempre sabemos que as tuplas de
variáveis são relacionadas a um único indivı́duo, o número de condicionantes será
sempre fixo11 para a de classe (sexo).

Para forçar a variação de número de condicionantes/condicionados da variável


sexo, podemos pensar no uso avançado da entidade “Pessoa”, que entraria como
argumento das variáveis aleatórias do domı́nio, para separar os nós de acordo com
a pessoa em que ele se refere (Ex. glabela da pessoa P1 e incisivo da pessoa P2).
Como é aceitável que informações de pessoas de um grupo de indivı́duos anato-
micamente similares (como famı́lia ou etnia) sejam úteis para cobrir informações
11
Note que o estado “indisponı́vel” de um nó tanto pode ser modelado como a inexistência
do nó quanto por uso de distribuição estatı́stica padrão.

120
incertas de um indivı́duo, essa abordagem poderia ser interessante. Todavia, não
foram coletadas informações de etnia ou parentesco; portanto, essa abodagem não
é viável através dados presentes no momento.

Outra possı́vel abordagem seria utilizar a idade como uma entidade, inserindo-
a como argumento das variáveis aleatórias. Com isso, seria possı́vel modelar uma
idéia similar à recursividade temporal. Isso seria aceitável em termos teóricos,
pois sabe-se que caracterı́sticas decisórias do crânio para a diferenciação de sexo
torna-se mais visı́vel no passar dos anos. No entanto, também não temos dados
da mesma pessoa em diferentes idades.

Com isso, foi concluı́do que, com os dados dispostos, o modelo se simplificaria
em uma rede bayesiana convencional. Como não vale a pena utilizar recursos
MEBN para modelar um domı́nio representável por BN comum, a ontologia de
Identificação Humana foi modelada no UnBBayes como BN convencional12 .

9.4 Modelagem do domı́nio no UnBBayes

Como foi identificado que o domı́nio poderia ser modelado em BN normal,


foi utilizado mecanismos computacionais de data-mining e aprendizagem para a
geração e validação dos modelos bayesianos.

9.4.1 Metodologia de modelagem no UnBBayes

1. Exportação da base de dados do MS-Access para formato texto aceito pelo


módulo de aprendizagem do UnBBayes (vide tabela 9.1).

2. Discretização de valores de idade.

• Pós-puberal: de 16 à 20 anos.
• Adulto: de 21 à 59 anos.
• Idoso: acima de 60 anos.

3. Uso do módulo de aprendizagem do UnBBayes para a geração automática de


BN. Dois terços dos dados foram selecionados aleatoriamente para compor
os dados de aprendizagem. Para cada algoritmo utilizado, será gerado uma
BN diferente. Os algoritmos usados foram:

• Pontuação
– K2
12
Afinal, vale a pena usar um formalismo avançado se já basta um formalismo simples?

121
– B
• IC
– CBL-A
– CBL-B
• TAN (algoritmo Chow-Liu)
• BAN/CBG
– Pontuação
∗ K2
∗ B
– IC
∗ CBL-A
∗ CBL-B
• Naive Bayes Classifier (presente no UnBMiner)

4. Uso do pré-processador do UnBMiner13 para converter o arquivo-texto que


representa um terço dos dados coletados (que são os dados restantes da
aprendizagem) para gerar um arquivo “.arff”. Um arquivo ARFF permite
melhor rastreabilidade de cada entrada de dado aos nomes das variáveis e
seus estados.

5. Uso do módulo UnBMiner para o teste das BN geradas. Relatórios de


validação são gerados.

6. A BN de melhor avaliação é selecionada para que sejam adicionadas des-


crições e explicações, que serão utilizadas pela metáfora do UnBBayes (vide
Seção 9.5).

Segue abaixo um exemplo de estrutura de um arquivo de dados manipulado


pelo módulo de aprendizagem do UnBBayes.

idadenumero sexo glabela fronte incisivos


Adulto Feminino NadaProeminente MuitoVertical Quadrado
Idoso Feminino Proeminente Inclinada Quadrado
Adulto Masculino PoucoProeminente Vertical Quadrado
PosPuberal Masculino Proeminente Inclinada Quadrado

Tabela 9.1: Formato do arquivo de entrada do módulo de aprendizagem do UnB-


Bayes.

13
UnBMiner é uma branch do projeto UnBBayes que se especializa em data-mining

122
9.4.2 Ajuste de dados

Os 934 dados (um terço dos 1401 dados totais) de 8 variáveis que possuı́am
em torno de 5 estados possı́veis não foram suficientes para gerar redes bayesianas
que fossem bem avaliadas pelo UnBMiner. Nessa condição, todos os algoritmos
testados geraram menos de 60% de ocorrências avaliadas corretamente nos testes.

Para a solução desse problema, os estados possı́veis das variáveis, com exceção
da idade, foram recategorizados em dois. O critério utilizado para essa recate-
gorização foi: quando existiam estados indicando “muito”, estes eram integrados
ao seu estado menos marcante (Ex. Muito Proeminente tornava Proeminente e
Muito Redondo se tornou Redondo). Idem para estados que se qualificavam ne-
gativamente, usando termos como “nada” ou “pouco” (Ex. Nada Proeminente e
“Pouco Proeminente” ambos se toram Não Proeminente).

9.4.3 Resultado da modelagem

Utilizando o critério de reajuste dos dados da Seção 9.4.2 anterior, o algoritmo


TAN mostrou melhor número de ocorrências classificadas corretamente pelo UnB-
Miner14 . Seguem abaixo a BN gerada e as CPT das variáveis aleatórias.

Faixa etária Adulto Adulto Pós Puberal Pós Puberal Idoso Idoso
Sexo Feminino Masculino Feminino Masculino Feminino Masculino
Arredondado 0.5504 0.6081 0.2273 0.4327 0.4483 0.3333
Quadrado 0.4496 0.3919 0.7727 0.5673 0.5517 0.6667

Tabela 9.2: Arredondamento do mento

Glabela Não Proeminente Não Proeminente Proeminente Proeminente


Sexo Feminino Masculino Feminino Masculino
Adulto 0.7852 0.7 0.708 0.7726
Pós Puberal 0.1663 0.2 0.1898 0.1671
Idoso 0.0485 0.1 0.1022 0.0603

Tabela 9.3: Faixa etária

Tabela 9.4: Fronte


Faixa etária Não Proeminente Não Proeminente Proeminente Proeminente
Sexo Feminino Masculino Feminino Masculino
Vertical 0.5301 0.4444 0.0588 0.544
Inclinada 0.4699 0.5556 0.9412 0.456

14
81% de ocorrências corretamente classificadas.

123
Figura 9.2: BN de identificação humana
Sexo Feminino Masculino
Proeminente 0.0182 0.7289
Não Proeminente 0.9818 0.2711

Tabela 9.5: Glabela

9.5 Metáfora UnBBayes

A metáfora é uma branch do projeto UnBBayes que visa prover uma inter-
face voltada para o usuário comum. Esconde as informações desnecessárias para
pessoas que não vão modelar domı́nios, acessando somente domı́nios previamente
modelados por outros.

É basicamente composta por uma tela de entrada de evidências (Figura 9.3)


e outra de leitura de resultado da inferência (Figura 9.4).

Faixa etária Adulto Adulto Pós Puberal Pós Puberal Idoso Idoso
Sexo Feminino Masculino Feminino Masculino Feminino Masculino
Quadrado 0.2882 0.3784 0.9545 0.8391 0.7471 0.9722
Redondo 0.7118 0.6216 0.0455 0.1609 0.2529 0.0278

Tabela 9.6: Incisivos superiores

124
Faixa etária Adulto Adulto Pós Puberal Pós Puberal Idoso Idoso
Sexo Feminino Masculino Feminino Masculino Feminino Masculino
Quadrado 0.2882 0.3784 0.9545 0.8391 0.7471 0.9722
Redondo 0.7118 0.6216 0.0455 0.1609 0.2529 0.0278

Tabela 9.7: Proeminência do mento


Glabela Não Proeminente Não Proeminente Proeminente Proeminente
Sexo Feminino Masculino Feminino Masculino
Angulosa 0.4074 0.2222 0.7132 0.5522
Redonda 0.5926 0.7778 0.2868 0.4478

Tabela 9.8: Órbita

9.5.1 Arquitetura da metáfora

A arquitetura da metáfora será mostrada através de diagramas UML na Fi-


gura 9.5. Como é basicamente uma interface gráfica para as funcionalidades do
UnBBayes, não provê muitos serviços especiais. Veja as figuras 9.6 e 9.7 para
descrições da seqüência de abertura de arquivos e de propagação das evidências
na metáfora, respectivamente.

AFINMetaphorFrame : JFrame principal do programa. Contém a barra de menu


e a barra de status.

AFINMetaphorMainPanel : Integra os painéis de entrada de evidência e o painel


de laudo em abas diferentes.

AFINMetaphorTree : Representa a árvore para entrada de evidências.

AFINMetaphorResult : Representa o painel para verificação de resultados (laudo)


da inferência bayesiana.

Feminino 0.4684
Masculino 0.5316

Tabela 9.9: Sexo do indivı́duo


125
Figura 9.3: Entrada de evidências pela metáfora.

Figura 9.4: Tela de laudo da metáfora.

126
127

Figura 9.5: Diagrama de classes da metáfora.


Figura 9.6: Diagrama de seqüência de abertura de BN.

Figura 9.7: Seqüência de execução de queries, propagação de evidências..

128
Capı́tulo 10

Conclusão

Acreditamos que o presente trabalho tem realizado avanços consideráveis na


ferramenta UnBBayes-MEBN, reparando falhas existentes inclusive em nı́vel de
algoritmo (vide Seção 6.2). Adicionalmente, sendo a usabilidade um fator de-
cisório na aceitação de uma ferramenta computacional, as alterações que resulta-
ram na nova GUI (capı́tulo 5) são de natureza importante na visão de engenharia
de software. A análise de performance também tem nos mostrado resultados sur-
preendentes, como o aumento da velocidade do compilador de pseudo-código em
até dez vezes, para códigos suficientemente complexos.

Apesar de termos concretizado algumas metodologias para a identificação de


domı́nio e modelagem de ontologias em MEBN/PR-OWL (vide seções 8.2 e 9.4),
percebe-se que a MEBN possui expressividade demasiadamente grande, dificul-
tando a identificação de problemas reais e coleta de dados que sejam realizáveis a
curto prazo e exercitem suficientemente as funcionalidades ofertadas pela MEBN.

De forma geral, problemas que necessitam de expressividade da MEBN têm


escopo grande, e os problemas que podem ser resolvidos em prazos razoáveis não
são complexos o suficiente para demonstrarmos a necessidade da MEBN como
formalismo bayesiano e extensão da FOL. Muitos problemas podem ainda ser de-
compostos e resolvidos individualmente por redes bayesianas convencionais, como
ocorreu no projeto de identificação humana, apresentada no capı́tulo 9.

A inexistência de mecanismo automatizado de aprendizagem em MEBN torna


a análise de dados um processo bastante repetitivo e exaustivo, necessitando
sempre de observações humanas na definição da CPT. Entretanto, apesar de todos
esses problemas, esta pesquisa tem sugerido bases para duas abordagens distintas
de modelagem: guiada por dados (projeto Identificação Humana) e guiada por
observações do modelador/especialista (ontologia Pizza e Vinho).

10.1 Trabalhos futuros ou correlatos

129
Como já apresentamos nas justificativas do projeto, há a chance da PR-OWL
ser utilizada como uma linguagem recomendada pelo W3C para representar onto-
logias na Web Semântica, portanto, aplicabilidade futura não faltará. Adicional-
mente, como a MEBN permite reutilização de fragmentos, ele permitirá agilidade
na engenharia de modelos bayesianos; logo, é possı́vel que aplicações que hoje
utilizam redes bayesianas convencionais passem a adotar o formalismo MEBN.

Entretanto, um problema identificado no momento está na alta complexidade


da MEBN, conseqüente da sua alta expressividade. A modelagem de um domı́nio
em MEBN não é uma atividade intuitiva ainda. Esperamos que a documentação
gerada no nosso projeto sirva de um consolo para futuras modelagens de domı́nios.

Como uma futura extensão do UnBBayes, podemos pensar em incorporar


modelo SOA (Service Oriented Architecture) ou interfaces Web, para que haja
armazenamento e processamento centralizado de ontologias, acessı́veis ao público
por navegadores convencionais e incorporáveis a outros sitemas através de serviços
Web.

Como trabalho correlato, existem diversos outros projetos que tentam incor-
porar incertezas às ontologias, de forma diferente da abordagem da MEBN no
UnBBayes. Podemos citar sistemas pagos como o Quiditty Suite, que integra o
formalismo de redes bayesianas com um pouco de fragmentação. Existem também
trabalhos acadêmicos como o projeto “Probabilistic Description Logic”[30], que in-
corpora probabilidades ao Description Logic. Abordagens utilizando lógica Fuzzy
também são populares [34] [31].

130
Referências

[1] Página web da série Star Trek. http://www.startrek.com/.

[2] Página web do padrão CRISP-DM. http://www.crisp-dm.org/.

[3] Página web do plugin Eclipse TPTP. http://www.eclipse.org/tptp/.

[4] Referência W3C DAML+OIL. http://www.w3.org/TR/daml+oil-reference.

[5] Resource Description Framework. http://www.w3.org/RDF/.

[6] G.O. ARBENS. Medicina Legal e Antropologia Forense. Atheneu, Rio de


Janeiro, 1988.

[7] T. BERNERS-LEE, D. CONNOLLY, S. HAWKE, I. HERMAN,


E. PRUDHOMMEAUX, and R. SWICK. W3C Semantic Web Activity.
www.w3.org/2001/sw/, 2001.

[8] T. BERNERS-LEE, J. HENDLER, and O. LASSILA. The Semantic Web.


Scientific American Magazine, 2001.

[9] R. N. CARVALHO, M. LADEIRA, and M. H. P. VIEIRA. Página web do


projeto UnBBayes. http://unbbayes.sourceforge.net/.

[10] R.N. CARVALHO. Raciocı́nio plausı́vel na web semântica através de redes


bayesianas multi-entidades - mebn. Master’s thesis, Departamento de Ciência
da Computação, Universidade de Brası́lia, 2008.

[11] H. CHALUPSKY, R.M. MAC-GREGOR, and T.A. RUSS.


Powerloom manual. http://www.isi.edu/isd/LOOM/Power-
Loom/documentation/manual.pdf, 2006. University of Southern California.

[12] E. CHARNIAK. Bayesian network without tears. American Associa-


tion for Artificial Intelligence, 1991. http://ist-socrates.berkeley.edu/ fitel-
son/269/Charniak BNWT.pdf.

[13] R. COMA. Antropologia Forense. Ministério de Justicia, Madrid, 1999.

[14] P.C.G. COSTA. Portal do PR-OWL. http://www.pr-owl.com.

[15] P.C.G. COSTA. Bayesian Semantics for the Semantic Web. PhD thesis, De-
partment of Systems Engineering and Operational Research, George Mason
University, 2005.
131
[16] P.C.G. COSTA and K.B. LASKEY. Multi-entity bayesian networks without
multi-tears. 2006.
[17] P.C.G. COSTA, K.B. LASKEY, and K.J. LASKEY. Pr-owl: A bayesian
ontology language for the semantic web. 2005.
[18] P.C.G. COSTA, K.B. LASKEY, and T. LUKASIEWICZ. Uncertainty re-
presentation and reasoning in the semantic web. In (in press) Semantic Web
Engineering in the Knowledge Society. To be published by IGI Publishing:
Hershey, PA, USA, 2008.
[19] Stanford Center for Biomedical Informatics Research. Protégé-owl.
http://protege.stanford.edu/, 2008.
[20] IBM Eclipse Foundation. Página web do eclipse, 01 2004.
http://www.eclipse.org.
[21] Z. GHAHRAMANI. Learning dynamic Bayesian networks. Lecture Notes in
Computer Science, 1387:168–197, 1998.
[22] D. HECKERMAN and E. HORVITZ. Inferring informational
goals from free-text queries: A bayesian approach. Decision
Theory and Adaptive Systems Group, Microsoft Research, 1998.
http://research.microsoft.com/research/dtg/horvitz/aw.htm.
[23] M. HORRIDGE, H. KNUBLAUCH, A. RECTOR, R. STEVENS, and
C. WROE. A Practical Guide To Building OWL Ontologies Using The
Protégé-OWL Plugin and CO-ODE Tools. University Of Manchester, 1.0
edition, 2004.
[24] H. KNUBLAUCH. Protégé-owl api programmer’s guide.
http://protege.stanford.edu/plugins/owl/api/guide.html, 2006.
[25] M. LADEIRA, D.C. SILVA, M.H.P. VIEIRA, M.S. ONISHI, R.N. CARVA-
LHO, and W.T. SILVA. Ferramenta Aberta e Independente de Plataforma
para Redes Probabilı́sticas. In Encontro Nacional de Inteligência Artificial -
ENIA, Campinas, Brazil, 2003.
[26] K. B. LASKEY. First-Order Bayesian Logic. PhD thesis, George Mason
University, 2006.
[27] K.B. LASKEY. MEBN: A Language for First-Order Bayesian Knowledge
Bases. Artificial Intelligence, 2007.
[28] K.B. LASKEY and P.C.G. COSTA. Of Klingons and Starships: Bayesian
Logic for the 23rd Century. In Proceedings of the Twenty-first Conference
Uncertainty in Artificial Intelligence (UAI -05), pages 346–353, Edinburgh,
Scotland, 2005.
[29] K.J. LASKEY, K.B. LASKEY, and P.C.G COSTA. Uncertainty Reasoning
for the World Wide Web Incubator Group Charter (W3C Incubator Acti-
vity). www.w3.org/2005/Incubator/urw3/charter, 2007.
132
[30] T. LUKASIEWICZ. Stratified probabilistic description logic programs. Te-
chnical report, Dipartimento di Informatica e Sistemistica, Universit‘ a di
Roma La Sapienza, Italy, 2005.

[31] M. MAZZIERI and A. F. DRAGONI. A fuzzy semantics for semantic web


languages. Technical report, Université Politecnica delle Marche Diparti-
mento di Elettronica, Intelligenza Artificiale e Telecomunicazioni (DEIT),
2006.

[32] P.F. PATEL-SCHNEIDER, P. HAYES, and I. HORROCKS. OWL Web On-


tology Language - Semantics and Abstract Syntax (W3C Recommendation).
www.w3.org/TR/owl-semantics/, 2004.

[33] C.B. PEREIRA and M.C. DE M. ALVIN. Manual para estudos cra-
niométricos e cranioscópicos. Imprensa Universitária, Santa Maria, 1979.

[34] G. STOILOS, G. STAMOU, V. TZOUVARAS, J. Z. PAN, and I. HOR-


ROCKS. The fuzzy description logic f-shin. Technical report, Department
of Electrical and Computer Engineering, National Technical University of
Athens, Greece. School of Computer Science, The University of Manchester,
UK, 2004.

[35] J. STUTZ, W. TAYLOR, and P. CHEESEMAN. AutoClass C - General


Information. NASA, Ames Research Center, 1998.

133
Apêndice A

Exemplos de código em OWL

Veja abaixo para um exemplo de cabeçalho OWL:

<owl:Ontology rdf:about="">
<owl:versionInfo>
webont.html, v.0.9; 2002-08-25 Exp
</owl:versionInfo>
<owl:imports rdf:resource="http://www.w3.org/2002/07/owl"/>
<dc:creator>Shou Matsumoto</dc:creator>
</owl:Ontology>

Exemplo de definição de classe e propriedade:

<owl:Class rdf:ID="Homem">
<rdfs:subClassOf rdf:resource="#Humano"/>
<owl:disjointWith rdf:resource="#Mulher"/>
</owl:Class>
<owl:ObjectProperty rdf:ID="hasChild">
<owl:inverseOf rdf:resource="#hasParent"/>
</owl:ObjectProperty>

Exemplo de definiç~
ao de indivı́duo:
<meuOwl:Estudante rdf:ID="Shou">
<owl:sameAs rdf:resource="#Shou Matsumoto"/>
< meuOwl :isAutorDe rdf:resource="#Slide Ontologia e Web
Semantica"/>
</ meuOwl : Estudante >

134
Apêndice B

Elementos da PR-OWL

B.1 Listagem das classes definidas na PR-OWL

Esta seção descreverá as classes presentes na biblioteca PR-OWL, definidas


no arquivo pr-owl.owl [14].

• pr-owl:BuiltInRV: indivı́duos desta classe representa as variáveis randômicas


dos MFrags embutidos, como conexões lógicas, quantificadores, comparador
de igualdade. Da mesma maneira que ocorre na MEBN, esses indivı́duos
permitem a PR-OWL a representar uma rica famı́lia de distribuições pro-
babilı́sticas através de interpretação da FOL.

• pr-owl:CondRelationship: representa o nó parente e seus valores possı́veis,


e indivı́duos dessa classe são utilizadas para criar PR-OWL tables. Cada
CondRelationship representa um par parente/estado, logo, a célula da ta-
bela de distribuição é condicionada por pares de CondRelationship (um por
cada nó parente).

• pr-owl:ProbDist: esta classe representa a distribuição probabilı́stica definida


em cada nó residente em um MFrag. Pode ser declarada por formatos
proprietários, como tabelas Netica ou funções Quiddity, ou utilizando uma
tabela PR-OWL, que organiza atribuições de probabilidades por células.

– pr-owl:PR-OWLTable: A tabela PR-OWL possui todas as atribuições


probabilı́sticas por cada estado da variável aleatória armazenada no
formato xsd:decimal. Este formato não pode representar casos com-
plexos de distribuição probabilı́stica e geram grandes ontologias, pois
cada célula é representada por um indivı́duo da classe ProbAssign.
Portanto, esta classe é somente recomendada em modelos simples com
máxima compatibilidade com OWL.
– pr-owl:DeclarativeDist: é aplicada usando xsd:string na propriedade
hasDeclaration. Para ser convertido em uma MEBN, um tradutor deve

135
ser exercitado para interpretar o conteúdo da string armazenada aqui.
Esta classe permite declaração de probabilidades em uma maneira bem
compacta, mas que exija um interpretador da linguagem utilizada para
a declaração.

• pr-owl:Node: parte de MFrag e pode ser um nó de contexto, nó de input ou


nó de contexto.

– pr-owl:Context: condicionante do tipo de argumento passado para RV.


Na PR-OWL, é a única classe que aceita termos compostos de RV e
seus valores possı́veis devem ser BooleanRVStates
– pr-owl:Input: cópia do nó residente que é usado como entrada para
um MFrag. Cada input deve estar ligada a algum nó residente.
∗ pr-owl:Generative input: nós de entrada convencional.
∗ pr-owl:Finding input: nós de entrada para findings.
– pr-owl:Resident: são RVs que possuem distribuições probabilı́sticas
definidas no MFrag.
∗ pr-owl:Finding res: todos os nós findings, que acrescenta novas
evidências ao sistema probabilı́stico.
∗ pr-owl:Domain Res: inclui nós residentes convencionais.

• pr-owl:MTheory: coleção de MFrags consistentes. Na PR-OWL, podem


existir mais de uma MTheory válida para representar RVs,; adicionalmente,
um MFrag pode pertencer a mais de uma MTheory.

• pr-owl:ProbAssign: representa cada célula da PR-OWL table com condici-


onantes que representam os estados dos pais

• pr-owl:MFrag: MEBN Fragments (MFrags) são a estrutura básica do mo-


delo lógico MEBN. Cada indivı́duo desta classe representa MFrags.

– pr-owl:Domain MFrag: conjunto de MFrags generativos.


– pr-owl:Finding MFrag: MFrags usados para conter informações de fin-
dings, que é o método padrão para entrada de evidências. Devem
possuir somente 2 nós: o input e o residente.

• pr-owl:Entity: MEBN trata o mundo como composto de entidades com atri-


butos e são relacionados à outras entidades. A lógica assume que conceitos
sejam únicos, logo, cada entidade deve possuir um identificador único, refe-
renciado pela propriedade hasUID.

– pr-owl:ObjectEntity: agrega entidades da MEBN com representações


da realidade. São o equivalente a objetos em modelos orientado a
objeto e frames em sistemas baseados em frames.
– pr-owl:MetaEntity: inclui entidades que definem entidades especı́ficas.
Podem servir de nome para determinados tipos da entidade.

136
– pr-owl:CategoricalRVStates: entidades que representam conceitos mu-
tualmente exclusivos.
– pr-owl:BooleanRVStates: representa valores booleanas da verdade e
são aplicadas a RVs booleanos.

• pr-owl:ArgRelationship: cada RV pode ter argumentos. Esta classe define


o número e a ordem esperada para um argumento esperado por cada RV o
tipo e uma referência para o RV que o utiliza. Esta classe pode represen-
tar argumentos complexos que vão além de simples sı́mbolos variáveis ou
constantes.

– pr-owl:SimpleArgRelationship: esta classe representa argumentos que


são simples sı́mbolos variáveis ou constantes.

• pr-owl:Skolem: os indivı́duos dessa classe representam Skolems das RVs


quantificadores na MEBN. Cada RV de quantificação é uma fórmula FOL
iniciada por quantificadores universais ou existenciais. pr-owl:Ovariable:
Variáveis ordinárias são espaços de MFrags usados para referir as entidades
não especificadas como argumentos de uma RV.

B.2 Listagem das propriedades definidas na PR-


OWL

Descrevemos aqui as propriedades definidas na PR-OWL. Descrições das pro-


priedades da famı́lia ”is”não serão tratadas, pois são somente propriedades inver-
sas da famı́lia ”has”.

Veja abaixo listagem das propriedades.

• hasArgNumber: utiliza um numeral inteiro não negativo para identificar a


ordem dos argumentos passados para RVs.

• hasArgTerm: indica ao ArgRelationship um argumento de tipo geral.

• hasArgument: indica a um nó quais argumentos ele possui.

• hasConditionant: indica ao ProbAssign o condicionante em uma célula da


PR-OWL table.

• hasContextInstance:liga nós residentes ou BuiltInRVs com os nós de con-


texto que as usam.

• hasDeclaration: xsd:string que descreve a distribuição condicional através


de linguagens como Netica e Quiditty.

• hasInnerTerm:conecta os nós com diversos termos internos possı́veis em uma


equação MEBN.

137
• hasInputInstance: liga o nó residente com os diversos nós de input possı́veis
para aquela ontologia.

• hasMFrag: liga a MTheory com MFrag componente.

• hasNode: liga MFrag com os nós que a compõe.

– hasContextNode: liga um MFrag com nós de contexto.


– hasInputNode: liga um MFrag com nós de input.
– hasResidentNode: liga um MFrag com nós residentes.

• hasOVariable: relaciona um MFrag com as variáveis ordinárias utilizadas


internamente.

• hasParent: liga um nó residente com outro nó residente ou nó de input.
Representa a RV condicionante do nó residente.

• hasParentName: liga uma CondRelationship com o respectivo pai (nó re-


sidente) que condiciona uma entrada da tabela de distribuição condicional
do tipo PR-OWL table.

• hasParentState: relaciona o CondRelationship com o estado do pai que


condiciona uma entrada da PR-OWL table.

• hasPossibleValues: indica quais são os valores que um nó pode assumir.

• hasProbAssign: liga a PR-OWL table com as suas inúmeras ProbAssign,


que representa uma célula da tabela de distribuição de probabilidade.

• hasProbDist: liga uma RV com sua respectiva tabela de distribuição con-


dicional.

• hasSkolem: liga um MFrag com constantes Skolems presentes.

• hasStateName: indica qual estado da RV que a ProbAssign (célula da PR-


OWL table) se refere.

• hasStateProb: armazena um xsd:decimal que representa a probabilidade


designada para uma determinada ProbAssign ()célula da PR-OWL table).

• hasType: ligação entre uma entidade com seu tipo (representado pela Me-
taEntity).

• hasUID: MEBN assume que entidades possuam um identificador único.


Esta propriedade armazena, em xsd:string, o identificador único de uma
entidade.

• representsOVar: liga uma constante Skolem com a variável ordinária que


ela representa em uma expressão com quantificadores.

• subsOVar: lista variáveis ordinárias que pode substituir um determinado


MetaEntity.
138
Abaixo, estão listadas propriedades inversas das propriedades já descritas.
Seus nomes já indicam quais propriedades são inversas e de quais (ex. isInpu-
tInstanceOf é inversa de hasInputInstance).

• isInputInstanceOf

• isMFragOf

• isNodeFrom

– isContextNodeIn
– isInputNodeIn
– isResidentNodeIn

• isOVariableIn

• isParentOf

• isPossibleValueOf

• isProbAssignIn

• isProbDistOf

• isRepBySkolem

• isTypeOf

• isArgTermIn

• isArgumentOf

• isConditionantOf

• isContextInstanceOf

• isDefault

• isInnerTermOf

• isRepresentedAs

• isSkolemIn

• isSubsBy

139