Desenvolvimento de aplicação para etapa de especificação da metodologia de desenvolvimento de ontologias em rede NeOn.

(1)

UNIVERSIDADE FEDERAL DE SANTA CATARINA

DESENVOLVIMENTO DE APLICAÇÃO PARA A ETAPA

DE ESPECIFICAÇÃO DA METODOLOGIA DE

DESENVOLVIMENTO DE ONTOLOGIAS EM REDE NEON.

Cleiton Edgar Janke Duarte

Florianópolis – SC

2009/1

(2)

UNIVERSIDADE FEDERAL DE SANTA CATARINA

DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA

CURSO DE SISTEMAS DE INFORMAÇÃO

DESENVOLVIMENTO DE APLICAÇÃO PARA A ETAPA DE

ESPECIFICAÇÃO DA METODOLOGIA DE

DESENVOLVIMENTO DE ONTOLOGIAS EM REDE NEON.

Cleiton Edgar Janke Duarte

Trabalho de conclusão de curso

apresentado como parte dos

requisitos para obtenção do grau

de Bacharel em Sistemas de Informação.

Florianópolis – SC

2009/1

(3)

Cleiton Edgar Janke Duarte

DESENVOLVIMENTO DE APLICAÇÃO PARA A ETAPA DE

ESPECIFICAÇÃO DA METODOLOGIA DE DESENVOLVIMENTO DE

ONTOLOGIAS EM REDE NEON.

Trabalho de conclusão de curso

apresentado como parte dos

requisitos para obtenção do grau

de Bacharel em Sistemas de Informação.

Banca Examinadora:

__________________________________

Prof. Dr. José Leomar Todesco

Universidade Federal de Santa Catarina

Orientador

__________________________________

Prof. Dr. Fernando Alvaro Ostuni Gauthier

Universidade Federal de Santa Catarina

Co-orientador

__________________________________

Prof. Dr. Rogério Cid Bastos

(4)

SUMÁRIO

LISTA DE FIGURAS ...6

RESUMO ...7

1) INTRODUÇÃO...8

1.1) OBJETIVO GERAL

...8

1.2)

O

BJETIVO

E

SPECÍFICO

...8

2) ENGENHARIA DE ONTOLOGIAS ...9

2.1)

O

NTOLOGIA

...9

2.1.1) Classificação de Ontologias...11

2.1.2) Uso de Ontologias ...13

2.1.3) A Engenharia de Ontologias e suas Atividades...15

2.2) METODOLOGIAS PARA CONSTRUÇÃO DE ONTOLOGIAS...17

2.2.1) Metodologia On-to-Knowledge ...18

2.2.2) Metodologia METHONTOLOGY ...19

2.2.3) Metodologia NeOn ...20

2.3)

F

ERRAMENTAS

...23

2.3.1) Protégé ...24

2.3.2) OntoKEM...25

2.3.3) NeOn Toolkit ...26

3) A FASE DE ESPECIFICAÇÃO DE ONTOLOGIAS ...27

3.1)

C

OMO É VISTO NO

N

E

O

N

...27

3.2)

C

OMO FOI VISTO NO ONTO

KEM...30

3.3)

C

ONSIDERAÇÕES

...33

4) APLICAÇÃO PARA A FASE DE ESPECIFICAÇÃO...34

4.1) UM POUCO SOBRE O MVP ...35

4.2) ESPECIFICAÇÃO DA APLICAÇÃO

...37

4.3) O XML PARA PERSISTÊNCIA

...42

4.4)

D

ETALHAMENTO DA

E

STRUTURA DA

A

PLICAÇÃO

...46

4.4.1) O Pacote “Data”...48

4.4.2) O Pacote “Beans”...50

4.4.3) A classe “ExtractController” e a extração de termos...52

4.4.4) O Pacote “View”...53

(5)

5) CONCLUSÃO ...63

5.1) CONSIDERAÇÕES FINAIS...63

5.2)

T

RABALHOS

F

UTUROS

...64

6) REFERÊNCIAS BIBLIOGRÁFICAS ...65

ANEXO A – CÓDIGO-FONTE DA APLICAÇÃO. ...69

(6)

LISTA DE FIGURAS

FIGURA 1 – NÍVEIS DE ABSTRAÇÃO PARA ONTOLOGIAS

...11

FIGURA 2 – CLASSIFICAÇÃO DE ONTOLOGIA POR HIERARQUIA...12

FIGURA 3 – PROCESSO DE DESENVOLVIMENTO DA METODOLOGIA ON-TO-KNOWLEDGE

...18

FIGURA 4 – PROCESSO DE DESENVOLVIMENTO E CICLO DE VIDA DA METODOLOGIA

METHONTOLOGY...20

F

IGURA

5 –

E

TAPAS E CENÁRIOS PARA CONSTRUÇÃO DE ONTOLOGIAS EM REDE PRESENTES NA METODOLOGIA

N

E

O

N

...23

FIGURA 6 – TELA DE EXEMPLO DA FERRAMENTA PROTÉGÉ, USANDO A ONTOLOGIA DE EXEMPLO

WINES

...24

FIGURA 7 – TELA DE EXEMPLO DA FERRAMENTA ONTOKEM, MÓDULO “VOCABULÁRIO”...26

FIGURA 8 – TELA DE EXEMPLO DA FERRAMENTA NEON-TOOLKIT...26

F

IGURA

9 –

M

ODELO DO DOCUMENTO

OSRD,

DA METODOLOGIA

N

E

O

N

...30

F

IGURA

10 –

T

ELA DE EXEMPLO DO MÓDULO DE

“P

ROJETO

”

DO ONTO

KEM ...32

F

IGURA

11 –

T

ELA DE EXEMPLO DO MÓDULO DE

“P

ERGUNTAS DE

C

OMPETÊNCIA

”

DO ONTO

KEM...32

FIGURA 12 – REPRESENTAÇÃO DO PADRÃO DE PROJETO MVP NA ESTRUTURA

PASSIVE VIEW

...36

FIGURA 13 – DIAGRAMA DE CASOS DE USO DA APLICAÇÃO

...37

FIGURA 14 – ESTRUTURA DE CLASSES DA APLICAÇÃO COM O PADRÃO MVP...40

FIGURA 15 – SUBESTRUTURA DA APLICAÇÃO SOBRE A PARTE DE MODELAGEM DAS REGRAS DE

NEGÓCIO DA ETAPA DE ESPECIFICAÇÃO

. ...42

F

IGURA

16 –

E

STRUTURA DO ARQUIVO

XML

DE PERSISTÊNCIA

...43

F

IGURA

17 —

P

ACOTE

“B

EANS

”

E SUAS CLASSES PARA COMUNICAÇÃO ENTRE AS CAMADAS

. .51

F

IGURA

18 —

O

PACOTE

“V

IEW

”

E AS CLASSES DE REPRESENTAÇÃO E MANIPULAÇÃO DOS MÓDULOS DA APLICAÇÃO. ...54

FIGURA 19 — TELA INICIAL DA APLICAÇÃO...58

FIGURA 20 — MENU “FILE” E AS OPÇÕES DE INÍCIO DE USO DE UM PROJETO...58

F

IGURA

21 —

A

BA DO MÓDULO

“P

ROJECT

”,

NO ESTADO DE EXIBIÇÃO

(

ACIMA

)

E NO ESTADO DE EDIÇÃO

(

ABAIXO

). ...60

F

IGURA

22 —

M

ÓDULO

“C

OMPETENCE

Q

UESTIONS

”. ...61

(7)

RESUMO

O propósito das páginas que seguem é o de apresentar o

trabalho de conclusão de curso sobre “Desenvolvimento de aplicação

para a etapa de especificação da metodologia de desenvolvimento de

ontologias em rede NeOn”. Nesse trabalho os objetivos foram

conhecer e apresentar a metodologia NeOn, com foco na sua etapa de

especificação, passando na seqüencia à elaboração de um sistema

que desse suporte a esta atividade. Estruturalmente o trabalho

descreve os conceitos mais importantes do escopo de trabalho

(ontologias, engenharia de ontologias, etc.) nos quais está a

metodologia NeOn, fazendo em seguida uma análise da etapa de

especificação desta metodologia. É também apresentada a

modelagem dos requisitos da aplicação, feita com base na análise

anterior, descrevendo detalhadamente em seguida o processo de

desenvolvimento da aplicação e sua estrutura. Para finalizar,

conclusões sobre a referida aplicação bem como sobre a etapa a qual

ela se propõe a dar suporte.

Palavras-chaves: ontologia, ontologia em rede, metodologia

(8)

1) INTRODUÇÃO

O aumento gradativo do uso das ontologias tem exigido cada

vez mais ferramentas que automatizem o processo de construção

destas. Nesse sentido, surgiu na Europa o projeto NeOn. Este projeto

propôs uma metodologia que prevê o desenvolvimento de ontologias

em rede, visando o reuso e a reengenharia de ontologias já existentes

para elaboração de novas. Para suportar esta metodologia, foi

concebido o NeOn Toolkit, um plataforma que integra várias

ferramentas específicas para atender a diferentes atividades

relacionadas a metodologia NeOn.

Observando a falta de uma ferramenta que suportasse a etapa

de especificação dessa metodologia este trabalho propõe o

“Desenvolvimento de uma aplicação para a etapa de especificação da

metodologia de desenvolvimento de ontologias em rede NeOn”.

1.1) Objetivo Geral

Desenvolvimento de uma aplicação que suporte a etapa de

especificação da metodologia de desenvolvimento de ontologias em

rede NeOn.

1.2) Objetivo Específico

• Conhecer o projeto NeOn, seus objetivos e estrutura.

• Conhecer a metodologia de desenvolvimento de ontologias em

rede do NeOn.

• Elaborar uma estrutura de classes que realize o suporte à etapa

de especificação de ontologias da metodologia NeOn.

(9)

• Desenvolver uma aplicação com base na estrutura de classes

elaborada.

2) ENGENHARIA DE ONTOLOGIAS

Este capítulo aborda alguns conceitos e processos envolvidos

na Engenharia de Ontologias. Mais exatamente, discorrerá a respeito

de ontologia — seu conceito, classificações possíveis e formas de

utilização —, sobre a própria Engenharia de Ontologias —

descrevendo os estágios envolvidos no processo de desenvolvimento

de uma ontologia —, também sobre algumas metodologias existentes

para desenvolvimento de ontologias e, por fim, sobre algumas

ferramentas computacionais existentes nesse escopo.

2.1) Ontologia

O conceito de ontologia variou de definição desde seu

surgimento na Filosofia até as sua aplicação atual no âmbito da

Ciência da Computação e Engenharia do Conhecimento (KIRYAKOV,

2006). Em sua origem o conceito era de uma disciplina dedicada ao

estudo da natureza e da existência dos elementos. Já na Ciência da

Computação, trata da representação do conhecimento, a organização

e estruturação dos conhecimentos sobre um determinado domínio.

A definição inicialmente utilizada na Ciência da Computação

veio, segundo Kiryakov (2006), por Gruber (1993) que define o

conceito de ontologia como “uma especificação explícita de uma

conceitualização”. Um outro autor, Borst (1997) atribuiu mais detalhes

a definição, sendo que para ele “ontologia é uma especificação formal

(10)

Devedzic (2002) interpreta ontologia como um sistema de

conceitos e das relações existentes entre esses conceitos, sendo os

conceitos definidos e interpretados declarativamente. O sistema

modelaria um determinado domínio definindo o vocabulário de termos

do mesmo e as restrições das combinações possíveis entre esses

termos.

Segundo Hepp et al. (2007) ontologias poderiam ser definidas

como representações formais de domínios, como um entendimento

compartilhado sobre um domínio. Sua construção se daria por um

processo social entre os especialistas do domínio e os engenheiros do

conhecimento definindo assim esse entendimento comum, como um

contrato. A construção da ontologia se dá, segundo o autor, de forma

dinâmica, havendo, por parte dos participantes do processo, inclusões,

modificações e descartes de elementos da ontologia.

Kiryakov (2006) expressa formalmente ontologia como um

relacionamento de quatro elementos representando isso pela

quádrupla:

O = {C, R, I, A}

Sendo “O” a ontologia, os demais elementos são:

• C: conjunto de classes que representam os conceitos de um

determinado domínio;

• R: conjunto das relações ou associações existentes entre os

conceitos;

• I: conjunto das instâncias advindas das classes

• A: conjunto de axiomas do domínio, que definem as restrições e

regras que atuam sobre as instâncias.

Daconta et al. (2003) mencionam que ontologias inserem

definições computáveis (passíveis de processamento e interpretação

por computadores) para conceitos de um dado domínio e para os

(11)

relacionamentos entre esses conceitos. Eles acrescentam ainda que

para ser computável, três níveis de abstração são importantes ao

desenvolvimento da ontologia, como pode ser visto na Figura 1. No

nível mais alto estão os elementos da ontologia (classes, relações

entre as classes, propriedades das classes, instâncias e os axiomas),

sendo este o nível da linguagem de representação do conhecimento.

Abaixo, no nível de conceitos da ontologia, estão os conceitos do

domínio de interesse na linguagem de representação do

conhecimento. Já no último nível, de instâncias da ontologia, estão

representados os objetos do domínio, com os respectivos valores para

as propriedades.

Figura 1 – Níveis de abstração para ontologias

Fonte: Adaptado e traduzido de Daconta et al. (2003).

2.1.1) Classificação de Ontologias

Ontologias podem ser classificadas de diferentes formas,

tomando por base sua hierarquia ou então a expressividade da

mesma.

Em termos de hierarquia há três níveis de classificação

aplicáveis (GUARINO, 1998):

■ Ontologias de alto nível: nesse grupo estão as ontologias

que descrevem conceitos de aplicação geral, que são independentes

de um problema ou domínio específico, por exemplo, conceitos de

espaço, tempo, objetos, etc. Tem boa aplicação para reuso na

(12)

construção de outras ontologias, mais específicas, que envolvam

esses conceitos mais gerais.

■ Ontologias de domínio e de tarefa: as de domínio

descrevem conceitos genéricos de um domínio em particular (como no

exemplo citado em RAUTEMBERG (2009), o termo “doença” no

domínio de “Medicina”). As ontologias de tarefa descrevem o conjunto

de ações ou tarefas realizadas em um determinado domínio (exemplo,

a ação de “diagnosticar” também no domínio de “Medicina”

(RAUTEMBERG, 2009)).

■ Ontologias de aplicação: As desse nível descrevem

conceitos que integram os das ontologias do nível anterior (de domínio

e de tarefas), sendo uma especialização dessas normalmente.

Na Figura 2 é possível ter uma representação visual da

classificação acima descrita.

Figura 2 – Classificação de ontologia por hierarquia

Fonte: Adaptado e traduzido de Guarino (1998).

Na classificação por expressividade (GOMÉZ-PÉREZ;

CORCHO, 2002) tem-se dois grupos possíveis, determinados pelo tipo

(13)

de linguagem de representação aplicada e pelos elementos

constituintes da ontologia, sendo esses grupos:

■ Ontologias de menor expressividade: as que modelam

informação sobre um domínio (conceitos e taxonomia), não vinculando

os axiomas e restrições. Por justamente não apresentar uma

expressividade tão alta em relação ao domínio abordado (pela não

necessidade dos axiomas e restrições) é que a inferência

computacional sobre a mesma é dificultada.

■ Ontologias de maior expressividade: essas incorporam os

axiomas e restrições do domínio, o que requer maior expressividade,

tornando também o raciocínio, por parte dos computadores, mais fácil.

2.1.2) Uso de Ontologias

Ontologias estão geralmente associadas à informação e

conhecimento sobre domínios sendo utilizadas para a representação

desse conhecimento em aplicações computacionais. Como exemplos

de uso podem ser mencionados a integração e recuperação de

informações na web e a gestão de conhecimento sobre um domínio

(STUDER et al., 1998). Outros autores (GRUNINGER; LEE, 2002)

apresentam ainda outras aplicações para ontologias:

■ Comunicação: entre sistemas computacionais, seres

humanos, ou ainda entre ambos.

■ Inferência computacional: usadas internamente na

representação e manipulação de informações, além de também serem

usadas para análise de estruturas, algoritmos e, entradas e saídas de

sistemas.

■ Reuso e utilização do conhecimento: possibilitam definir

bibliotecas ou repositórios de informações.

(14)

Ainda no contexto do conhecimento, focando na engenharia

sobre a mesma, ontologias podem ser empregadas para (MIKA;

AKKERMANS, 2005):

■ Comunicação do conhecimento: processo no qual estão as

tarefas ligadas à compreensão dos conceitos.

■ Integração do conhecimento: processo onde estão as

atividades que definem o relacionamento entre os conceitos.

■ Raciocínio com conhecimento: processo com tarefas

relacionadas à produção de novos conhecimentos.

Quando se altera o foco no conhecimento para a gestão do

mesmo, ainda destacam-se mais aplicações para as ontologias

(GSEVIC et al., 2006):

■ Colaboração: ontologias podem servir como um “esqueleto

unificado do conhecimento” para projetos onde a equipe envolvida é

interdisciplinar, possibilitando assim uma melhor comunicação e

entendimento entre os membros sobre os conceitos relacionados ao

domínio.

■ Interoperabilidade: uma ontologia pode facilitar a integração

de diferentes fontes de dados para busca de informações, por

exemplo, desde que essas distintas fontes reconheçam a mesma

ontologia, facilitando assim a conversão de dados quando necessário,

por exemplo.

■ Educação: ontologias podem servir como fonte de referência

para estudos pesquisas e propagação do conhecimento de um

determinado domínio, isso quando a ontologia representa um

consenso comum dos conceitos desse domínio.

■ Modelagem: ontologias podem, no contexto de Sistemas

Baseados em Conhecimento, servir como um “bloco de construção

reutilizável” (RAUTEMBERG, 2009) podendo este ser utilizado em

(15)

aplicações distintas. Exemplo: uma ontologia sobre carros pode servir

a um sistema web para venda de automóveis, onde pode trazer

sugestões de carros para compras como também informações e

conhecimentos pertinentes sobre os carros vendidos.

2.1.3) A Engenharia de Ontologias e suas

Atividades

A Engenharia de Ontologias é a disciplina responsável por

administrar e se preocupar com as atividades, processos, ciclos de

vida, métodos e metodologias envolvidos no desenvolvimento de

ontologias, bem como nas ferramentas e linguagens envolvidos na

construção dessas ontologias (GÓMEZ-PÉREZ et al., 2004).

A terminologia envolvida na Engenharia de Ontologias foi

baseada na Engenharia de Software, advindo daí a semelhança nas

atividades envolvidas no desenvolvimento de ontologias com as de

desenvolvimento de software (PINTO; MARTINS, 2004 e YE et al.,

2007).

A seguir, as atividades presentes no desenvolvimento de

ontologias:

■ Especificação: etapa onde são identificados propósito e

escopo da ontologia a ser desenvolvida. Podem ser aplicadas as

perguntas “Por que a ontologia é construída?” e “Quais são as

intenções de uso e usuários da ontologia?”, pois as respostas destas

serão as definições, respectivamente, do propósito e do escopo.

■ Conceitualização: é onde se define um modelo conceitual da

ontologia, que represente os conceitos do domínio abordado e as

relações entre estes. A definição se baseia nas informações colhidas

na atividade anterior (especificação).

(16)

■ Formalização: nesta atividade o modelo conceitual

anteriormente definido é formalizado, aplicando-se restrições e

axiomas aos conceitos já estabelecidos. Dessa forma é feita a

restrição das interpretações desses termos e feita a organização

hierárquica dos mesmos (através de relações estruturais como “é-um”

ou “parte-de”).■ Implementação: a ontologia é implementada através

de uma linguagem de representação do conhecimento, que deve ser

escolhida adequadamente para cada caso.

■ Manutenção: como no desenvolvimento de softwares, é onde

são feitas correções e atualizações na ontologia, algumas vezes

provocados por novos requisitos que surgem, ou são visualizados,

durante o desenvolvimento.

Além dessas etapas pré-definidas há outras que também são

importantes, não apenas em um dado momento do desenvolvimento,

mas durante todo o ciclo de vida da ontologia (PINTO; MARTINS,

2004):

■ Aquisição do conhecimento: como o nome indica seria

adquirir conhecimento a respeito do domínio da ontologia, fazendo

isso através de especialistas nesse domínio ou então de bibliografia

sobre o mesmo. Algumas técnicas possíveis para aquisição de tal

seriam brainstorming, entrevistas, análises de textos, etc.

■ Avaliação: julgamento técnico da qualidade da ontologia, que

pode ser:

■ Avaliação técnica: é utilizado um framework de referência

para o julgamento, sendo que essa avaliação envolve as atividades

de:

● verificação, que garante a correção segundo fontes de

conhecimento especializadas;

(17)

● validação, que garante o alinhamento à finalidade

estabelecida para a ontologia, de acordo com os resultados da etapa

de especificação.

■ Avaliação de usuários: é feito o julgamento de usabilidade e

utilidade da ontologia, do ponto de vista do usuário.

■ Documentação: registro de toda a ontologia e de todo o

processo de desenvolvimento, etapa por etapa (o que, como e por que

foi feito), incluindo os documentos finais de cada etapa, a fim de gerar

um material completo para o entendimento, uso e reuso, e

manutenção da ontologia.

Essas atividades são as mais comuns no que diz respeito a

desenvolvimento de ontologias, sendo que existem outras atividades

ligadas a metodologias mais específicas da Engenharia de Ontologias.

Nesse trabalhão o foco estará concentrado na primeira etapa

apresentada: Especificação.

2.2) Metodologias para Construção de Ontologias

Ainda não há uma metodologia que tenha se definido como

padrão para desenvolvimento de ontologias (PINTO; MARTINS, 2004).

Um dos argumentos lançados para isso é que as metodologias

possuem atividades que não estão compreendidas entre si,

necessitando-se assim a combinação de metodologias para abrangir

as atividades necessárias ao desenvolvimento de uma ontologia

(FERNADEZ-LÓPEZ; GÓMEZ-PÉREZ, 2002).

Nessa sessão serão apresentadas, brevemente, algumas

metodologias comuns no desenvolvimento de ontologias — a

On-to-Knowledge e a METHONTOLOGY — e a metodologia NeOn, sobre a

qual se dará o desenvolvimento do trabalho.

(18)

2.2.1) Metodologia On-to-Knowledge

Tendo sido desenvolvida em uma cooperação entre várias

entidades européias (FENSEL; HERMELEN, 2008) a metodologia

On-to-Knowledge teve como foco de concepção a utilização em Sistemas

de Gestão do Conhecimento. Essa metodologia é dividida em cinco

fases, como pode ser visto na Figura 3, descritas a seguir (SURE;

STUDER, 2003):

Figura 3 – Processo de desenvolvimento da metodologia On-to-Knowledge

Fonte: Adaptado e traduzido de Sure e Studer (2003).

■ Estudo de viabilidade: é uma fase pré-desenvolvimento,

anterior ao real início da metodologia. O estudo realizado nessa fase

visa mapear todo o contexto envolvido no desenvolvimento,

identificando, por exemplo, os problemas ou oportunidades que a

organização envolvida no projeto tem e verificando se existe a

necessidade real de uma ontologia para a mesma. O estudo é

realizado utilizando CommonKADS como metodologia (SCHREIBER

et al., 2002).

■ Início da ontologia: aqui realmente inicia a metodologia.

Trata-se da fase de especificação descrita anteriormente na sessão

2.1.3, onde são definidos os requisitos para desenvolvimento, o

domínio abrangido, as fontes de conhecimento, os atores e cenários,

(19)

as questões de competência — que irão definir os termos envolvidos

no domínio, que passarão depois a ser os conceitos e relações de tal

— além de outros itens.

■ Refinamento: é onde é feito o desenvolvimento da ontologia,

muitas vezes juntamente com os especialistas no domínio, onde são

feitas análises sobre a ontologia a fim de evoluir e estendê-la, de

acordo com o que foi anteriormente definido. O produto final desta fase

é uma versão estável da ontologia.

■ Avaliação: aqui é feita a verificação da ontologia mediante os

requisitos estabelecidos na fase inicial do desenvolvimento. Por muitas

vezes são utilizadas as perguntas de competência como base para

analisar se a ontologia responde satisfatoriamente essas questões,

representando assim bem o domínio.

■ Manutenção e Evolução: é uma fase pós-desenvolvimento

que visa aumentar a representatividade da ontologia ou adaptá-la a

um novo requisito, por exemplo, cabendo a responsabilidade dessa

fase à organização detentora da ontologia.

2.2.2) Metodologia METHONTOLOGY

Esta metodologia nasceu em um grupo de pesquisa em

Engenharia de Ontologias da Universidade Politécnica de Madri, e tem

forte embasamento nas metodologias de Engenharia de Software e

Engenharia do Conhecimento (GOMÉZ-PÉREZ et al., 2004). Nessa

metodologia, o ciclo de vida de uma ontologia é baseado em protótipos

— a cada etapa do processo de desenvolvimento (especificação,

conceitualização e demais, veja sessão 2.1.3) é gerado um protótipo

da ontologia até aquele ponto. As atividades dessa metodologia têm

foco na gerência, desenvolvimento e suporte ao ciclo de vida, como

(20)

visto na Figura 4, tendo esta característica forte ligação com a

Engenharia de Software.

Figura 4 – Processo de desenvolvimento e ciclo de vida da metodologia

METHONTOLOGY

Fonte: Adaptado e traduzido de Gómez-Peréz et al. (2004).

As etapas do processo são as descritas anteriormente na

sessão 2.1.3, como pode ser confirmado no bloco “Atividades de

Desenvolvimento”, na Figura 4. A sua principal característica em

relação a outras metodologias é a geração de artefatos de

documentação ao final de cada etapa do processo de

desenvolvimento, gerando uma documentação bastante rica.

2.2.3) Metodologia NeOn

O projeto NeOn — acrônimo para Networked Ontologies — foi

criado a partir de um consórcio de instituições européias. O projeto

trabalha com a idéia de desenvolvimento colaborativo de ontologias,

permitindo o reuso de ontologias para construção de novas,

promovendo isso através de ontologias distribuídas em rede, em

(21)

diferentes locais e compartilhadas via web (SUÁREZ-FIGUEROA et

al., 2007). Assim não seria mais necessário construir uma ontologia

totalmente do zero, ou então replicar elementos de uma ontologia já

existente para criar uma nova, bastaria compartilhar a já existente e

estendê-la para gerar a nova criação.

Para esse novo conceito de desenvolvimento o projeto propôs

uma metodologia para tal (SUÁREZ-FIGUEROA et al., 2008). A

metodologia aplicada, porém, varia de acordo com o cenário de

construção de uma ontologia em rede que se apresenta para o caso.

São nove os cenários encontrados durante as pesquisas do projeto,

sendo eles (SUÁREZ-FIGUEROA et al., 2008):

■ Cenário 1: Construção total — a partir do zero, reuso de

ontologias já existentes — sem o reuso de recursos de conhecimento.

■ Cenário 2: Construção de ontologia em rede a partir do reuso

e reengenharia de recursos de conhecimento.

■ Cenário 3: Construção de ontologia em rede a partir do reuso

de recursos ontológicos.

■ Cenário 4: Construção de ontologia em rede a partir de reuso

e reengenharia de recursos ontológicos.

■ Cenário 5: Construção de ontologia em rede a partir do reuso

e integração de recursos ontológicos.

■ Cenário 6: Construção de ontologia em rede a partir do reuso,

integração e reengenharia de recursos ontológicos.

■ Cenário 7: Construção de ontologia em rede a partir do reuso

de padrões de design de ontologias.

■ Cenário 8: Construção de ontologia em rede a partir da

reestruturação de recursos ontológicos.

(22)

■ Cenário 9: Construção de ontologia em rede a partir da

localização de recursos ontológicos.

A partir da leitura de Suárez-Figueroa (2008) entende-se por

recursos de conhecimento (ou recursos não-ontológicos) estruturas

que representam informações de conhecimento sobre um domínio e

que não foram formalizadas através de ontologias (ex.: thesauri,

dicionários glossários, etc.). Já recursos ontológicos seriam seleções

de elementos extraídos de ontologias para resolução de um dado

problema, sendo que esses recursos podem ser: ontologias

completas, módulos de ontologias, padrões de design de ontologias ou

declarações de ontologias.

Os cenários propostos no estudo em Suárez-Figueroa (2008)

podem ser combinados em grupos. A divisão mais considerada na

metodologia NeOn é de separar os cenários onde há reuso de

recursos ontológicos daqueles onde há reuso e reengenharia de

recurso não-ontológicos (recursos de conhecimento), havendo ainda o

caso especial do cenário 7, onde há o reuso de padrões de design de

ontologias.

Na Figura 5 é possível visualizar todos os processos e

atividades envolvidos no desenvolvimento com a metodologia NeOn —

os números indicam as partes envolvidas em cada cenário de

construção de ontologias em rede, citados anteriormente. Pode-se

observar na Figura 5 também as etapas básicas presentes na

metodologia: especificação, conceitualização, formalização e

implementação (visíveis na figura como “O. Specification, O.

Conceptualization, O. Formalization, O. Implementation”). Essas

etapas são como as descritas anteriormente na sessão 2.1.3 desse

trabalho. O que muda é que, dependendo do cenário, há o acréscimo

de uma etapa, além de atividades e processos distintos entre as

etapas de já existentes, em especial conceitualização e formalização.

(23)

As etapas acrescidas são: Localização (na figura, “O. localization”),

presente no cenário 9 e, Reestruturação da Ontologia (na figura,

“Ontology Restructuring”), presente no cenário 8, onde são aplicadas

atividades de extensão, especialização, modularização, etc. sobre os

recursos ontológicos usados na construção.

Figura 5 – Etapas e cenários para construção de ontologias em rede presentes na

metodologia NeOn

Fonte: Suárez-Figueroa (2008).

2.3) Ferramentas

No desenvolvimento de ontologias é importante o uso de

ferramentas computacionais que suportam a manipulação dos

elementos da ontologia, para que esta não seja tão complexa e mais

consistente (GRAU et al., 2008).

Nesse trabalho serão apresentadas algumas dessas

ferramentas, que são: Protégé, OntoKEM e NeOn Toolkit.

(24)

2.3.1) Protégé

Dentre as mais conhecidas ferramentas para manipulação e

desenvolvimento de ontologias está o Protégé. Trata-se de uma

plataforma — um conjunto de ferramentas específicas de

manipulação, criação e visualização — baseada na política

open-source — política de código aberto que possibilita o acesso ao código

da

aplicação

para

possibilitar

alterações

evoluções

e

desenvolvimentos de novas funcionalidades — que tem por objetivo a

construção de modelos de domínios e aplicações baseadas em

conhecimento com ontologias (PROTÉGÉ, 2009). Na Figura 6 é

possível visualizar a interface gráfica da ferramenta.

Figura 6 – Tela de exemplo da ferramenta Protégé, usando a ontologia de exemplo

wines

(25)

2.3.2) OntoKEM

O ontoKEM — que significa ontology for Knowledge Engineering

and Management — é uma ferramenta web, desenvolvida em meio

acadêmico, que suporta a construção e documentação de ontologias

(RAUTEMBERG et al., 2008). Nessa ferramenta o desenvolvimento é

baseado em artefatos de documentação fundamentados nas

metodologias On-to-Knowledge e METHONTOLOGY (já vistas

anteriormente, nas seções 2.2.1 e 2.2.2 respectivamente) e também

no processo de desenvolvimento apresentado pelo guia intitulado

Ontology Development 101 (referência sobre o guia em NOY

GUINESS, 2008). Esta ferramenta será usada no próximo capítulo

como exemplo de comparação entre as formas de especificação das

metodologias On-to-Knowledge e METHONTOLOGY (aplicadas no

ontoKEM) e da metodologia NeOn (aplicada nesse trabalho). Na

Figura 7 segue uma visualização do ontoKEM na sua atual versão,

para fins ilustrativos.

(26)

Figura 7 – Tela de exemplo da ferramenta ontoKEM, módulo “Vocabulário”

2.3.3) NeOn Toolkit

Trata-se da ferramenta computacional que suporta o projeto

NeOn, já descrito anteriormente na sessão 2.2.3. O NeOn Toolkit é

uma plataforma dotada de um conjunto de ferramentas específicas

para construção de ontologias em rede, como é a proposta da

metodologia NeOn (NEON, 2008). A ferramenta foi elaborada

utilizando-se da estrutura da interface de desenvolvimento e

programação Eclipse SDK e é expansível através de plugins que

executam funções específicas das etapas de desenvolvimento da

metodologia. A plataforma ainda não está completa, pois o próprio

projeto NeOn ainda está em desenvolvimento. Na Figura 8 segue uma

visualização da interface gráfica do NeOn Toolkit.

Figura 8 – Tela de exemplo da ferramenta NeOn-Toolkit

(27)

3) A FASE DE ESPECIFICAÇÃO DE ONTOLOGIAS

O objetivo deste breve capítulo é o de apresentar

especificadamente a etapa de especificação segundo a metodologia

NeOn. É essa etapa da metodologia que a aplicação proposta nesse

trabalho visa dar suporte. De um modo geral, a especificação na

Engenharia de Ontologia já foi descrita na sessão 2.1.3, sendo que

nesse capítulo a primeira sessão trará os detalhes da etapa propostos

no projeto NeOn. Na segunda sessão será apresentado como foi

implementada a etapa mencionada na ferramenta de desenvolvimento

de ontologias ontoKEM (que usa as metodologias On-to-Knowledge e

METHONTOLOGY, como já descrito na sessão 2.3.2 desse trabalho),

afim de destacar as diferenças e similaridades entre as metodologias

já conhecidas e o NeOn.

3.1) Como é visto no NeOn

Como já mencionado anteriormente, na Engenharia de

Ontologias a etapa de especificação visa identificar o propósito e

escopo da ontologia a ser desenvolvida, respondendo respectivamente

as perguntas “Por que a ontologia é construída?” e “Quais são as

intenções de uso e usuários da ontologia?” (PINTO; MARTINS, 2004 e

YE et al., 2007) e também definir quais tipos de usuários, cenários de

usos e nível de formalização que a ontologia irá suportar e os

requisitos que a mesma deve atender (SUÁREZ-FIGUEROA, 2008).

Para a metodologia NeOn foi proposta a técnica de perguntas de

competência (GRÜNINGER; FOX, 1995) para o levantamento dos

requisitos da ontologia. Através das perguntas de competência é que

se levantará “o que” a ontologia deve responder — ao final serão

essas perguntas que a mesma deverá responder. Os termos extraídos

(28)

dessas perguntas é que passarão, na etapa seguinte da metodologia,

a formar os conceitos e relações entre conceitos da ontologia.

Como documento de resultado da etapa de especificação a

metodologia NeOn propõe o OSRD (“Ontology Requirements

Specification Document” ou “Documento de Especificação de

Requisitos da Ontologia”), um modelo padrão que apresenta os

requisitos da ontologia, sendo eles (SUÁREZ-FIGUEROA, 2008):

■ Propósito (“Ontology purpose”): aqui é onde são

detalhados os objetivos, as finalidades ao qual a ontologia se propõe.

■ Escopo (“Ontology scope”): identifica qual será a

abrangência e a granularidade da ontologia, até que profundidade a

ontologia abordará o domínio representado.

■ Nível de Formalismo (“Level of Formality”): indica qual o

grau de formalização que se pretende adotar na implementação da

ontologia. Um exemplo de descrição de Nível de Formalismo seria: “A

ontologia será implementada na linguagem OWL”.

■ Usuários desejados (“Intended Users”): o objetivo neste

item é criar as descrições dos perfis de usuários desejados para essa

ontologia. Através dessas descrições é possível, após a elaboração da

ontologia, desenvolver aplicações melhor focadas nos perfis mais

desejados, por exemplo.

■ Usos (Cenários) desejados (“Intended Uses”): este item

detalhar os cenários de uso que a ontologia deverá prover suporte ao

estar concluída. Estes cenários podem ser descritos através de

linguagem natural ou até mesmo através de diagramas UML, como

diagramas casos de uso. Também facilita o desenvolvimento de

aplicações mais focadas.

■ Grupos de Perguntas de Competência (“Groups of

(29)

competências elaboradas, bem como as suas respectivas respostas.

As perguntas devem ser categorizadas conforme a necessidade e

também deve ser atribuída a prioridade de cada uma.

A partir desses grupos, e de suas perguntas de competência, é

que serão extraídos os termos e objetos para a ontologia. No projeto

NeOn a proposta é que essa extração seja automática: é feita uma

busca nas perguntas e extraídos os termos, que então são exibidos ao

usuário desenvolvedor que, por sua vez, pode selecionar quais são

relevantes.

■ Termos (“Terms”): representam os termos extraídos das

perguntas, sendo estes normalmente conceitos ou relações entre

conceitos da ontologia. Sempre apresentam a freqüência com a qual

aparecem na listagem total de perguntas de competência e podem

também receber ordenação de prioridade.

■ Objetos (“Objects”): representam os objetos extraídos das

perguntas, sendo estes objetos normalmente instâncias da ontologia.

Possuem as mesmas características de freqüência e prioridade dos

termos.

Na Figura 9 é possível visualizar o modelo de documento OSRD

proposto no NeOn.

(30)

Figura 9 – Modelo do documento OSRD, da metodologia NeOn

Fonte: Suárez-Figueroa (2008).

3.2) Como foi visto no ontoKEM

Na ferramenta ontoKEM, desenvolvida sob as metodologias

On-to-Knowledge e METHONTOLOGY, pode-se notar algumas distinções

em relação a proposta da metodologia NeOn, mas que possuem uma

certa semelhança de objetivo. No ontoKEM (RAUTEMBERG et al.,

2008) a etapa de especificação é dividida em dois módulos: o de

“Projeto” e o de “Perguntas de Competência”.

No de “Projeto” é especificado, além do nome da ontologia, a

descrição da mesma — além da descrição da versão na qual se

encontra a mesma. Em relação ao NeOn esse campo de “descrição”

(31)

seria um equivalente aos campos descritivos de “propósito” e “escopo”

unificados. Na mesma “descrição” poderiam ser incluídos os campos

“nível de formalismo” e até “usuários desejados” e “usos (cenários)

desejados” do NeOn, que não possuem correspondentes diretos no

ontoKEM. O problema seria o de que todas essas informações seriam

repassadas juntas e na forma de texto livre.

Tanto no ontoKEM quanto no NeOn é proposta a técnica de

perguntas de competência para o levantamento de requisitos, cabendo

a gerência disto ao módulo de “Perguntas de competência”. Ali, além

dos cadastrados da perguntas, é feito o cadastro dos termos para

cada uma das perguntas. A extração destes, porém, é feita

manualmente pelo usuário desenvolvedor da ontologia — ao contrário

da proposta de extração automática do NeOn. Após o término do

cadastro das perguntas e termos é possível fazer uma visualização e

seleção dos termos, permitindo assim exportar os relevantes para a

próxima etapa do desenvolvimento da ontologia.

Na Figura 10 é possível visualizar o módulo de “Projeto” do

ontoKEM, e Figura 11 o de “Perguntas de competência”.

(32)

Figura 10 – Tela de exemplo do módulo de “Projeto” do ontoKEM

(33)

3.3) Considerações

Em relação aos procedimentos da etapa de especificação

adotados nas duas soluções, podemos fazer algumas comparações.

A divisão proposta pelo NeOn para os requisitos mais

descritivos da ontologia — propósitos, escopo, nível de formalismo —

permite uma definição mais clara de cada um por parte de quem

especifica a ontologia. Apenas um campo descritivo pode permitir uma

maior liberdade, mas com isso o desenvolvedor pode acabar

esquecendo alguma dessas informações, deixando a especificação

mais pobre.

A listagem de usuários desejados e dos cenários de uso da

ontologia, propostas estas do NeOn, permitem uma definição mais

clara dos objetivos e aplicações da ontologia, facilitando até o

desenvolvimento posterior de aplicações sobre a ontologia — podendo

estas serem focadas sobre determinados usuários ou cenários de

usos.

O uso de perguntas de competência é bem semelhante em

ambos, sendo que no NeOn também são requeridas as respostas

respectivas a cada questão. A extração dos termos é que faz a grande

diferença nesta parte — manual no ontoKEM e automática através de

técnicas de extração terminológicas (SUÁREZ-FIGUEROA, 2008) no

NeOn. A extração automática, com possibilidade de posterior seleção

dos mais relevantes, facilita bastante o levantamento dos termos da

ontologia, não havendo a necessidade de um usuário ficar analisando

cada pergunta e/ou resposta de competência para verificar quais os

termos que podem existir.

O modelo proposto pela metodologia NeOn parece interessante

e eficaz como modelo de especificação de ontologias. Observado isso,

o documento OSRD e seus itens servirão de base para o

(34)

desenvolvimento de uma aplicação para suporte da etapa de

especificação da metodologia NeOn, que é a proposta desse trabalho.

4) APLICAÇÃO PARA A FASE DE ESPECIFICAÇÃO

Em Suárez-Figueroa (2008), ao final das explicações a respeito

da etapa de especificação da metodologia NeOn, há uma sugestão de

implementação. Sugere-se o desenvolvimento de uma aplicação

acoplável — um plugin — para a plataforma de desenvolvimento de

ontologias em rede NeOn Toolkit, sendo que esta aplicação deve

seguir os processos e atividades propostas na etapa de especificação

da metodologia NeOn.

Nesse trabalho o foco não foi no desenvolvimento somente de

um plugin para o NeOn Toolkit, mas sim em uma aplicação para

especificação de ontologias baseada na metodologia NeOn e que

permitisse liberdade de acoplamento, tanto na parte visual quando na

parte de saídas resultantes — documentos que podem ser gerados ou

formas de persistência dos dados. Para isso houve a aplicação

adaptada do padrão de projeto conhecido por MVP, tanto na camada

de visualização quanto na de externalização e persistência de dados.

Neste capítulo serão apresentados os conceitos e

procedimentos adotados no desenvolvimento da aplicação proposta no

trabalho. Inicialmente será brevemente apresentado o MVP, para

melhor entendimento da estrutura e especificação da aplicação que

será o item seguinte. Como terceiro item virá a descrição do XML para

persistência dos dados, seguido de um detalhamento dos módulos e

classes usados, em “Detalhamento da Estrutura da Aplicação”. Como

última sessão comenta-se os resultados apresentados, numa forma de

considerações finais sobre o desenvolvimento.

(35)

4.1) Um pouco sobre o MVP

O MVP — acrônimo para “Model-View-Presenter” ou

“Modelo-Visualização-Apresentar”, em tradução livre — é um padrão de projeto

(FOWLER, 2009) que visa separar o desenvolvimento de uma

aplicação em três camadas principais:

■ Model: é onde ficam as regras de negócio da aplicação, onde,

por exemplo, é feita toda a manipulação dos dados conforme o

objetivo da aplicação.

■ View: é onde está toda a parte de interfaces de comunicação

(gráficas ou não) da aplicação, que realizam a interação com os

usuários da mesma (sejam estes pessoas, máquinas ou outros

sistemas).

■ Presenter: seria a camada responsável por intermediar as

ações e informações repassadas entre o as duas camadas anteriores,

executando, por exemplo, tratamento dos dados para possibilitar a

visualização (alterando o tipo do dado, sem alterar a informação

vinculada nele) e vice-versa.

Fowler (2009) propôs a divisão do padrão em duas arquiteturas

possíveis: “Supervising Controller” (“Controle Supervisionado”, em

tradução livre) e “Passive View” (“Visão Passiva”, em tradução livre).

Nesse trabalho foi adotada a estrutura “Passive View”, explicada a

seguir.

Nessa estrutura a camada “View” possui apenas o

comportamento inerente aos seus componentes, não possuindo

nenhum comportamento referente às regras de negócio da aplicação.

Exemplificando: no caso de uma interface gráfica, o View apresentará

apenas os componentes e campos para visualização e os tratamentos

e comportamentos inerentes a estes (como monitores para eventos de

botões e outros campos, por exemplo). A proposta do Passive View

(36)

com isso é separar bem os comportamentos permitindo que os testes

das regras de negócio possam ser feitos independentes da camada

visual (eliminando assim a possibilidade um erro proveniente de um

componente visual ser refletido em um teste das regras de negócio).

Outra vantagem apresentada nessa estrutura é separar

tecnologicamente as camadas de visualização e negócio, permitindo

uma troca da camada de visão sem grandes alterações (ou até

nenhuma) na camada de negócios.

No Passive View todo o comportamento que antes ficaria no

elemento (ou classe) de visualização — como recuperar um dado

específico de uma base de dados e atribuí-lo a um campo visual, por

exemplo — passa a um novo elemento chamado “Controller” (ou

“Presenter”). O Controller é que se torna responsável por recuperar os

dados necessários e repassá-los à camada visual, bem como

recuperar os dados da camada visual e tratá-los conforme o

necessário. Para manter o desacoplamento do View o Controller

acessa o mesmo através de interfaces, que o View por sua vez deve

implementar. Já o View possui acesso direto ao Controller, afim de não

complicar muito a implementação através da estrutura. Na Figura 12

segue uma visualização do padrão MVP e da estrutura Passive View.

Figura 12 – Representação do padrão de projeto MVP na estrutura Passive View

(37)

Nesse trabalho, além da camada visual, a camada de

persistência dos dados também foi abstraída sobre o conceito do

“MVP – Passive View”, sendo que a comunicação entre a aplicação e

os módulos de persistência é feita através de interfaces, como poderá

ser visto na sessão seguinte.

4.2) Especificação da Aplicação

A partir da elaboração de um diagrama de casos de uso (Figura

13) foi possível levantar os requisitos necessários para o

desenvolvimento da aplicação. O diagrama teve como ponto de partida

o processo descrito na etapa de especificação da metodologia NeOn

(ver sessão 2.2.3).

Figura 13 – Diagrama de casos de uso da aplicação

Apenas um tipo usuário foi identificado para uso da aplicação,

sendo este usuário denominado no diagrama como “usuário

(38)

desenvolvedor”. A etapa de especificação de uma ontologia conta

normalmente com a interação de várias pessoas, geralmente

especialistas do domínio abordado, e desenvolvedores de ontologias,

mas para desenvolvimento da aplicação aqui proposta basta a

abstração de um usuário, podendo este ser qualquer membro da

equipe de especificação.

A partir da definição do usuário e próximo passo foi definir

macro processo envolvidos. Três foram observados:

■ Criar o Projeto: nesse processo são informados os requisitos

gerais da especificação — o nome do projeto de especificação (nome

da ontologia), autores, propósito da ontologia, escopo, nível de

formalismo, usuários desejados e cenários de uso da ontologia. Ao

abstrair esse processo também foi definida a forma de persistência

dos dados armazenados, que seria feita em um arquivo XML, melhor

detalhado posteriormente na sessão 4.3. Ao criar o projeto já é gerada

uma versão inicial do arquivo XML, guardando os requisitos gerais

cadastrados.

■ Criação de categorias e perguntas de competência: é o

processo onde são criadas as perguntas de competência e as

categorias que as armazenam. Por padrão, ao criar o projeto já é

criada uma categoria intitulada “default” (o nome pode ser alterado)

para receber as perguntas. Mais categorias podem ser criadas

conforme a necessidade. As perguntas podem ter uma sentença

(sendo esta apenas a pergunta em si) ou então duas sentenças (a

pergunta e a sua resposta). Cada pergunta pode ser classificada a

apenas uma categoria, podendo haver mudança posterior à

classificação inicial.

■ Identificação dos termos das perguntas de competência:

este processo é mais automatizado pela própria aplicação. Nele é

realizada a extração automática dos termos das perguntas de

(39)

competência (tanto das perguntas em si quanto das respostas quando

estas existirem). A extração é feita a partir de todo o conjunto de

perguntas ou do conjunto de perguntas de uma categoria específica. O

conjunto dos termos encontrados são exibidos ao usuário

desenvolvedor para que este possa selecionar quais termos são

relevantes para o projeto. Há a possibilidade também de realizar a

combinação entre termos durante a seleção, a fim de criar um termo

composto que a extração automática não capturou nas sentenças.

Com o término da elaboração do diagrama de casos de uso o

próximo passo foi a elaboração das classes da aplicação.

Estruturalmente a aplicação segue o padrão de projeto MVP, descrito

anteriormente, permitindo distinguir claramente as classes

responsáveis pela parte de visualização (View), apresentação

(Presenter) e modelagem do negócio (Model). Na Figura 14 está

representada, sem detalhamento das classes, essa divisão.

(40)

(41)

Na parte de modelagem do negócio houve mais uma divisão

estrutural, também seguindo a linha de desenvolvimento do MVP. Esta

subestrutura é composta por:

■ Classe “Ambiente” (Environment): controla a inicialização

da aplicação e criação dos seus objetos de controle.

■ Pacote de classes de dados (Data Package): responsável

pela manipulação, em tempo de desenvolvimento, dos dados

envolvidos no processo de especificação (dados de propósito, escopo,

dados das perguntas de competência, dos termos, etc.).

■ Classe de controle de saída (OutputController): é a

responsável direta pela comunicação com as classes responsáveis por

gerarem o documento OSRD e pela persistência do XML.

■

Classe de controle da extração dos termos

(ExtractController): realiza a extração dos termos a partir das

perguntas de competência selecionadas (todas ou de uma categoria

específica).

Na Figura 15 é possível visualizar a subestrutura ainda a pouco

descrita. Na sessão 4.4 haverá um maior detalhamento dessas

classes mencionadas.

(42)

Figura 15 – Subestrutura da aplicação sobre a parte de modelagem das regras de