O uso de ontologias no processo de desenvolvimento de sistemas computacionais vem crescendo ao longo das últimas décadas. A utilidade de ontologias tem sido explorada em áreas como a IA (BOICU et al, 2001), Engenharia de Software (ES) (OLIVEIRA, 1999) e IE (GOÑI et al, 2002).
A origem do termo ontologia advém da Filosofia, correspondendo à busca da “classi- ficação exaustiva e definitiva das entidades em todas as esferas do ser” (SMITH & WELTY, 2001). Ainda segundo Smith & Welty (2001), a apropriação desse termo no contexto da Ciên- cia da Computação tem como marco a proposta de McArthy, no final da década de 70, de que a construção de ontologias seria relevante para a construção de sistemas inteligentes baseados em lógica. A partir de então, o termo ontologia vem sendo utilizado em diversas sub-áreas, tais como: Engenharia de Conhecimento em IA, modelagem conceitual em Banco de Dados e modelagem de domínio em Orientação a Objetos.
Um outro marco importante no histórico da utilização de ontologias no contexto com- putacional é o trabalho de Gruber (1993), onde uma primeira tentativa de definição do termo é proposta. Desde então diferentes tentativas de conceituação vêm sendo propostas, dentre as quais:
i) ontologia é uma especificação formal e explícita de uma conceituação compartilhada
(GRUBER, 1993);
ii) ontologia é uma descrição parcial e explícita de uma conceituação (GUARINO e GI-
ARRETA, 1995);
iii) ontologia consiste num vocabulário representacional com definições precisas dos termos
deste vocabulário mais um conjunto de axiomas que restrinjam a interpretação e o uso destes termos (CAMPBELL e SHAPIRO, 1995);
iv) ontologia é uma teoria sobre um domínio que especifica um vocabulário de entidades, classes, propriedades, predicados e funções; e um conjunto de relações que amarra este vocabulário (FIKES e FARQUHAR, 1999).
Em paralelo, alguns autores têm centrado esforços na tentativa de elaboração de classi- ficações para ontologias, bem como no desenvolvimento de metodologias para seu desenvol- vimento.
Van Heijst et al. (1997) e Van Heijst (1995) propõem uma classificação para ontologi- as baseadas em duas dimensões: a quantidade e o tipo de estrutura da conceituação e o assun- to da conceituação. Segundo esses autores, no que se refere a quantidade e o tipo de estrutura de conceituação as ontologias podem ser classificadas como:
i) Ontologias terminológicas, que especificam termos usados para representar o conheci-
mento no domínio de discurso;
ii) Ontologias de informação, que especificam a estrutura de registro de um banco de da-
dos;
iii) Ontologias de modelagem de conhecimento, que especificam a conceituação do conhe-
A partir de uma análise crítica, Van Heijst, Guarino (1997b) propôs classificar ontolo- gias de acordo com as seguintes dimensões: o nível de detalhe da ontologia e o nível de de- pendência da ontologia em relação a uma tarefa específica ou ponto de vista.
Segundo Guarino (1998), considerando a segunda dimensão e analisando o nível de generalidade, pode-se classificar as ontologias como:
i) Ontologias de alto nível, que descrevem conceitos gerais como espaço, tempo, evento,
conceitos estes independentes de um domínio específico;
ii) Ontologias de domínio, que descrevem um vocabulário particular relacionado a um do-
mínio específico envolvendo a especialização dos conceitos pré-existentes numa onto- logia de alto nível;
iii) Ontologias de tarefas, que descrevem um vocabulário para descrição de tarefas ou ati-
vidades através da especialização de uma ontologia de alto nível;
iv) Ontologias de aplicação, que se constituem nas ontologias mais específicas, onde os
conceitos das ontologias de domínio correspondem aos papéis exercidos pelas entidades na realização de uma atividade da ontologia de tarefas.
Já segundo Uschold (1996), uma ontologia pode ser classificada quanto ao propósito para o qual é definida, quanto à natureza do assunto e quanto ao grau de formalidade com que o vocabulário é criado e seu significado é definido.
Grunniger e Lee (2002) abstêm-se de buscar uma definição universal para o termo e propõem focar na tipologia de usos para ontologias, quais sejam: comunicação, inferência computacional, reuso e organização do conhecimento.
No contexto da IS, vários trabalhos vêm sendo realizados tanto na área de desenvol- vimento de ontologias como nas suas aplicações (OLIVEIRA, 1999; BONDENREIDER, 2001; MEJINO e ROSSE, 2004).
Dentre os projetos de desenvolvimento de ontologias na área de IS, destaca-se o Unifi-
ed Medical Language System (BONDENREIDER, 2001, UMLS, 2004). Desenvolvido pela
National Library of Medicine (NLM), o UMLS almeja facilitar a busca e troca de informação
A etapa de metodologia é aquela na qual se define onde e como será realizado um tra- balho de pesquisa, conforme entende Moresi (2003).
3.1 Classificação
Esta pesquisa, quanto aos fins, classifica-se como aplicada, por buscar propor uma arquitetura para a definição do módulo tutor do IACVIRTUAL, e metodológica, pois pretendemos elaborar um instrumento para captação e manipulação da realidade médica, correspondendo à ontologia para a especialidade de Cardiologia no domínio da Radiologia Torácica. Em relação aos meios, o trabalho compreende pesquisa bibliográfica e laboratorial.
3.2 MATHEMA
O modelo MATHEMA desenvolvido por Costa (1997) propõe um ambiente interativo de aprendizagem utilizando-se do enfoque multi-agentes e suportando a noção de aprendiza- gem cooperativa . A arquitetura proposta no modelo MATHEMA tem como base a integração de agentes humanos e artificiais dentro de um ambiente cooperativo.
Motivador E xterno Aprendiz Humano Sociedade Especialista Humano Sociedade de Agentes Tutores Artificiais AT AT AT AT AT AT Agente de Interface Agente De Manutenção AT AT AT
Conforme definido por Costa (1997), a arquitetura MATHEMA é composta por um conjunto de seis componentes (Figura 3):
i) AH – um aprendiz humano;
ii) SATA – a Sociedade de Agentes Tutores Artificiais;
iii) SEH – a Sociedade de Especialistas Humanos (que constituem fontes de conhecimento, envolvidas nas operações de manutenção da SATA);
iv) AI – o agente de interface, que possibilita a interação entre AH e SATA; v) AM – o agente de manutenção, que serve de interface entre SEH e SATA;
vi) ME – um motivador externo, que incorpora a possibilidade da atuação no ambiente de agentes humanos cumprindo a função de motivar o AH para a utilização do ambiente.
No contexto dessa arquitetura, existem três classes de interações possíveis:
i) as interações entre um Aprendiz Humano e a SATA, através de um agente tutor; ii) as interações entre os agentes tutores;
iii) as interações entre as duas sociedades: SATA e SEH.
Segundo Costa (1997), as interações AH-SATA surgem a partir de uma situação parti- cular de resolução de problemas. Neste caso o AT que participa da interação com o aprendiz, ele pode não ser capaz de realizar determinados objetivos isoladamente e buscará a coopera- ção com os demais agentes da SATA. Se, mesmo assim, os objetivos da interação não forem alcançados, o AT inicial poderá recorrer a um pedido de ajuda externa à SATA, isto é, à SEH.
As interações da classe SEH-SATA ocorrem quando há um pedido de ajuda de um AT à SEH ou quando a SEH, observando a interação AH-SATA através de algum mecanismo interno do sistema (ex. arquivos de log), verifica uma necessidade de manutenção sobre a SATA.
Um aspecto relevante do modelo MATHEMA é a abordagem adotada para a modela- gem do conhecimento do domínio do STI. Em MATHEMA, o conhecimento é modelado se-
gundo duas perspectivas de visualização: uma visão externa e uma visão interna (COSTA, 1997).
Na visão externa, o domínio alvo será particionado em um certo número de subdomí- nios construídos tendo em vista alcançar uma representação em três dimensões de conheci- mento:
i) Contexto, que corresponde aos diferentes contextos ou pontos de vistas relacionados ao
domínio de conhecimento;
ii) Profundidade, que constitui diferentes possibilidades/níveis de abordagem em relação a um determinado contexto
iii) Lateralidade, que corresponde aos conhecimentos afins de suporte (ex: pré-requisitos) a um objeto do domínio alvo, associado um par <Contexto, Profundidade>.
Assim, a modelagem de um domínio alvo (D) compreende as seguintes etapas. Para o domínio D, será associado um conjunto de contextos distintos D {C1, ..., Cn}, onde cada Ci
(1 i n) representa um contexto particular.
Para cada contexto Ci, definido anteriormente, será associado um conjunto de níveis
distintos de profundidades Ci {Pi1, ..., Pim}, onde cada Pij (1 j m) corresponde a j-ésima
profundidade associada ao i-ésimo contexto.
Para cada par <Ci,Pij>, será associado um conjunto de lateralidades distintas <Ci,Pij>
{Lij1, ..., Lijt}, onde Lijk (1 k m) corresponde a k-ésima lateralidade desse par.
O domínio D, submetido à partição acima, pode então ser definido como o conjunto união dos subdomínios dij que correspondem a uma visão particular de D associada a cada par
<Ci,Pij>.
O domínio D, submetido à partição acima, pode então ser definido como o conjunto união dos subdomínios dij que correspondem a uma visão particular de D associada a cada par
D =
U
d ij tal que 1 i n e 1 j m (1)A partir desta mesma partição do domínio D, obtemos um domínio complementar, o
domínio do conhecimento lateral DL, associado a uma visão de lateralidade e construído co-
mo se segue: para cada visão lateral Lijk, define-se um subdomínio externo a D, denominado
dijk, que apreende um conhecimento lateral à D, de tal modo que dijk D.
DL =
U
dijk tal que 1 i n e 1 j m e 1 k t (2)Assim, o conhecimento da sociedade de agentes relativo a D (D’) a ser disponibilizado
por esta sociedade corresponderá à união:
D’ = D DL (3)
Na Figura 4, é apresentado o corpo de conhecimento D’, formado do conhecimento D
e respectivas lateralidades.
Figura 4: Visão multidimensional do conhecimento do domínio (Costa, 1997)
Para o domínio de Cardiologia, por exemplo, poderíamos considerar: Domínio:
D = Cardiologia
Contextos:
C1: Anatomia do Aparelho Circulatório
C3: Fisiopatologia
C4: Semiologia
C5: Patologia
C6: Clínica das Doenças Cardiovasculares
Profundidades:
P11: Coração – Visão geral
P12: Pericárdio
P13: Tamanho e Posição
P14: Anatomia Válvulas Cardíacas
P15: Anatomia Interna do Átrio
P16: Anatomia Interna do Ventrículo
... Lateralidades:
...
L141 Histologia
...
A partir do processo de modelagem do domínio descrito anteriormente, a SATA pode ser definida como segue:
Para cada subdomínio dij de D, define-se um agente tutor ATij ( dij TAij);
O mesmo é feito para o subdomínio lateral dijk, levando a definição do ATijk (dijk
ATijk) que será responsável por esta visão lateral particular.
Estes agentes, assim definidos, se agrupam em dois conjuntos de agentes segundo o modelo MATHEMA:
Os agentes tutores AT relativos ao domínio D, TA =
U
ATij , 1 i n e 1 j m;Os agentes tutores ATL relativos ao domínio DL, ATL=
U
ATijk , 1 i n e 1 j m e1 k t.
Finalmente, a sociedade de agentes SATA estará definida como sendo:
3.3 PROTÉGÉ
O ambiente Protégé (PROTÉGÉ, 2004) constitui-se numa série de ferramentas inte- gradas para a modelagem e a aquisição de conhecimento voltado para o desenvolvimento de ontologias. O ambiente é independente de plataforma e foi desenvolvido pelos pesquisadores do Stanford Medical Institute (SMI). Ele oferece uma arquitetura baseada em componentes
que é passível de extensão através de sua API. Protege constitui-se num ambiente baseado em
frames para o desenvolvimento de sistemas baseados em conhecimento, sendo aderente ao
padrão Open Knowledge Base Connectivity (OKBC) (OKBC, 2004).
Figura 5: Ambiente Protégé (PROTÉGÉ, 2004)
Uma ontologia em Protégé consiste num conjunto de classes, propriedades, restrições e axiomas:
frames de classe (Class) especificam conceitos de domínio e são organizados numa hie-
rarquia que permite herança múltipla. Classes servem como templates para os frames de
instância;
Propriedades (Slot) são um tipo particular de frame que podem ser associados a uma
classe de modo a definir seus atributos, com restrições de valores específicas. Own slots
definem propriedades intrínsecas da classe ou frames individuais de instância que não
são propagados seja por herança ou instanciação. Template slots são associados à frames
de classe para definir os atributos de suas instâncias, que por sua vez definem valores específicos para propriedades;
Restrições (Facets) são propriedades dos slots, que especificam restrições nos seus valo-
res. Exemplos de facets seriam a cardinalidade de um valor de slot, seu tipo, faixa de va-
lores, valores padrão, etc.;
Axiomas (Axioms) são restrições adicionais que podem ser definidas nos frames, para,
por exemplo, relacionar os valores de um grupo de template slots ligados a uma classe.
Protégé fornece um conjunto pré-definido de predicados e funções para definir as restri- ções e provê a possibilidade de avaliar as restrições de forma a garantir que instâncias dentro da base estejam de acordo com as restrições a elas aplicáveis.
3.4 JADE
O Java Agent DEvelopment framework (JADE) (JADE, 2004; RIMASSA, 2003) é um
ambiente para desenvolvimento de aplicações baseada em agentes conforme as especificações da Foundation for Intelligent Physical Agents (FIPA) (FIPA, 2004) para interoperabilidade
entre sistemas multi-agentes. Foi desenvolvido e suportado pelo CSELT (atual TILAB) da Universidade de Parma na Itália.
O principal objetivo do JADE (JADE, 2004) é simplificar e facilitar o desenvolvimen- to de sistemas multi-agentes garantindo um padrão de interoperabilidade entre sistemas multi- agentes através de um conjunto de agentes de serviços de sistema, os quais tanto facilitam como possibilitam a comunicação entre agentes, de acordo com as especificações da FIPA.
Segundo Rimassa (2003), o objetivo de JADE é prover suporte de execução à compo- nentes de softwares que possam ser considerados agentes de acordo com a definição de Wo-
oldridge e Jennings (1995) em seus aspectos fundamentais de autonomia e sociabilidade. Segundo Bellifemini et al. (2003), o desenvolvimento de JADE se baseou nos seguin-
tes princípios:
i) Interoperabilidade. JADE é aderente ao padrão FIPA, desta forma agentes JADE po-
dem operar com quaisquer outros agentes, desde que os mesmos também apresentem conformidade ao mesmo padrão;
ii) Uniformidade e portabilidade. JADE apresenta um conjunto homogêneo de APIs que
são independentes da camada de rede e também do ambiente de execução Java. Dado que é utilizado o mesmo conjunto de APIs para J2EE, J2SE e JRE, os desenvolvedores utilizando-se da plataforma podem, em teoria, decidir pelo ambiente de execução Java em tempo de implantação;
iii) Facilidade de uso. A complexidade do middleware é ocultada através do uso de um
conjunto de APIs simples e intuitivo;
iv) Filosofia “pay-as-you-go”. Os programadores não precisam fazer uso obrigatório de to-
das os recursos providos pelo middleware. Recursos não utilizados não precisam ser
considerados pelo programador e não implicam em sobrecarga computacional.
O Modelo de Referência FIPA para Plataforma de Agentes, conforme indicado na Fi- gura 6, é composto de:
i) Agent. é o agente propriamente dito, cujas tarefas serão definidas de acordo com o obje-
tivo da aplicação. Encontra-se dentro de uma plataforma de agentes (Agent Platform) e
realiza toda sua comunicação com os demais agentes através de troca de mensagens e relaciona-se com aplicação externa (software);
ii) Agent Management System (AMS - Sistema Gerenciador de Agentes), responsável por
gerenciar o ciclo de vida dos agentes na plataforma e prover um serviço de guia de en- dereços (white pages), cabe a ele manter o diretório de identificadores de agentes (Agent IDs –AID) associando os identificadores lógicos dos agentes à informações de endere-
çamento e status;
iii) Directory Facilitator (DF- Diretório Facilitador), que funciona como um serviço de pá-
ginas amarelas com capacidades básicas de casamento. Uma instância especial deste a- gente, chamada Default DF, deve estar presente em qualquer plataforma aderente ao pa- drão FIPA;
iv) Message Transport System (MTS - Sistema de Transporte de Mensagens), também co-
nhecido como canal de comunicação dos agentes (Agent Communication Channel –
ACC), é o agente responsável por prover toda a comunicação entre agentes dentro e fora da plataforma. Todos os agentes, inclusive o AMS e o DF, utilizam esse canal para a comunicação.
Figura 6: Modelo de Referência FIPA para Platforma de Agentes (RIMASSA, 2003)
Uma das características da Plataforma JADE, conforme ilustrado pela Figura 7, é que ela pode ser distribuída por vários hosts e, ainda assim, se apresentar como uma única entida-
de para um outro sistema aderente à FIPA. Segundo esse esquema, várias máquinas virtuais Java são agregadas numa mesma plataforma. Em cada uma delas um Agent Container (AC)
será executado e este poderá, por sua vez, executar zero ou mais agentes. A plataforma será então formada por um conjunto de um ou mais AC.
Figura 7: Plataforma JADE Distribuída (JADE, 2004)
Segundo Rimassa (2003) esta arquitetura apresenta algumas características significati- vas, dentre as quais:
i) Front-end único. Apesar de distribuída, a plataforma deve ter apenas uma única instân-
cia de AMS e de Default DF. A estratégia adotada é selecionar um dos ACs para fun- cionar como Main Controller, onde estarão contidos o AMS e Default DF. Em confor-
midade com o padrão FIPA este Main Controller deverá ser inicializado em primeiro
lugar e os demais containers (ACs) poderão agregar-se a plataforma desde que tenham
acesso a localização de rede do Main Controller;
ii) Distribuição otimizada de mensagens. O padrão FIPA determina mecanismos de trans-
porte para entrega de mensagens entre múltiplas plataformas, mas define mensagens in- tra-plataforma como critério da implementação. JADE adota uma abordagem com foco em otimização: uma vez que a plataforma conhece a localização dos agentes envolvidos ela usará chamadas locais Java quando a comunicação se der no escopo de um mesmo
forma. Desta forma, alternativas mais complexas de comunicação no padrão FIPA só serão usadas se a comunicação cruzar os limites da plataforma.
Em termos do modelo de agente, JADE adere ao padrão FIPA e adota o ciclo de vida (life cicle) nele definido. O ciclo de vida em FIPA pode ser expresso através de uma máquina
de estados finitos que descreve o agente ao longo de sua existência (Figura 8).
Para cada transição de estado definida no ciclo de vida do agente FIPA, de nome XXX,
existirá um método na classe Agent um método doXXX( ) correspondente (ex. doDelete( ), doMove( )). Uma vez que um comportamento de um agente ative um destes métodos, causará
uma transição de estado no próximo ponto de verificação (checkpoint) do gerenciador de a-
gentes (agent scheduler).
Figura 8: Modelo FIPA para o Ciclo de Vida do Agente (FIPA, 2004)
Tais estados são representados em JADE através de constantes estáticas da classe A- gent:
i) AP_INIATED: o objeto da classe Agent foi instanciado, mas ainda não se registrou no
ii) AP_ACTIVE: o objeto da classe Agent está registrado no AMS, tem nome formal e en-
dereço e tem acesso a todas funcionalidades do JADE;
iii) AP_SUSPENDED: o objeto da classe Agent está no momento interrompido.Sua thread
interna está suspensa e nenhum comportamento está sendo executado;
iv) AP_WAITING: o objeto da classe Agent está bloqueado, esperando por alguma coisa.
Sua thread interna está “dormindo” (sleeping) sob um monitor Java e irá acordar quan-
do alguma condição ocorrer (geralmente quando uma mensagem chega);
v) AP_DELETED: o agente está definitivamente “deletado” ou encerrado. Sua thread in-
terna terminou sua execução e o agente não está mais registrado no MAS;
vi) AP_TRANSIT: um agente móvel entra nesse estado enquanto tiver migrando para uma
nova localização. O sistema continua a armazenar mensagens em um buffer que serão
enviadas para essa nova localização;
vii) AP_COPY: esse estado é usado internamente pelo JADE para agentes que foram clona-
dos;
viii) AP_GONE: esse estado é usando internamente pelo JADE quando um agente móvel
Neste capítulo serão descritos os produtos da dissertação, ou seja, a arquitetura propos- ta para o módulo educacional do IACVIRTUAL e a ontologia de domínio elaborada durante a formulação da arquitetura.