Metodologia de construção de ontologias

Uma metodologia de construção de ontologias compreende um conjunto de princípios, processos, práticas, métodos e atividades estabelecidas, usado para projetar, construir, avaliar e distribuir ontologias (DEVEDŽIĆ, 2006). Segundo Devedžić (2006) e Goméz-Pérez et al. (2003) as propostas de metodologias de desenvolvimento de ontologia focam, em sua maioria, na construção de ontologias, especialmente em sua conceituação e desenvolvimento. Entretanto, aspectos importantes como atividades de gerenciamento, aprendizagem, fusão, integração, evolução e avaliação de ontologias, são deixados de lado (DEVEDŽIĆ, 2006). Algumas das metodologias que focam na construção de ontologia são gerais e simplesmente oferecem passos a serem seguidos. Algumas outras metodologias propõem métodos para fusão, reengenharia, manutenção e amadurecimento de ontologias. Outras aplicam processos e práticas de desenvolvimento de software. De acordo com Devedžić (2006), metodologias de desenvolvimento de ontologias recorrem à análise e projetos de software orientado a objeto. Isto pode ser percebido, uma vez que ontologias representam classes, suas propriedades, valores das propriedades e eventos. Ontologias também abrangem hierarquia, e a maioria suporta generalização, herança, agregação e relações entre seus conceitos (DEVEDŽIĆ, 2006). Além do mais, segundo Devedžić (2006), os processos que a engenharia de ontologia usa para o

desenvolvimento de ontologias quase coincidem com alguns dos processos estabelecidos de análise e projeto orientado a objetos.

Como exemplo de metodologia, pode-se citar de forma breve Uschold e King (apud GOMÉZ-PÉREZ et al., 2003), que propõem os seguintes processos para a construção de ontologias: identificar a proposta da ontologia, construí-la, avaliá-la e documentá-la. Durante o processo de construção, os autores propõem a captura do conhecimento, codificação do conhecimento e integração de outras ontologias dentro da ontologia corrente. Já a metodologia de Grüninger e Fox (apud GOMÉZ-PÉREZ et al., 2003) propõe identificar de forma intuitiva as possíveis aplicações que integrarão a ontologia. Nesta metodologia são usadas questões em linguagem natural, denominadas questões de competência, para determinar o escopo da ontologia. Com base nessas questões e em suas respostas, os principais conceitos (classes) e suas propriedades são identificados, bem como as relações e axiomas da ontologia. Segundo Goméz-Pérez et al. (2003), essa metodologia tem um alto grau de formalidade, mas o ciclo de vida da ontologia, assim como a de Uschold e King, não é completamente especificado.

Metodologias mais abrangentes vão além do princípio de construir ontologias. Um exemplo é a metodologia METHONTOLOGY (GOMÉZ- PÉREZ et al., 2003). De modo geral, essa metodologia parte do princípio que a engenharia de ontologia requer padronização e definição de todo ciclo de vida da ontologia – desde a especificação dos requisitos até a manutenção - bem como os métodos e técnicas que guiam o desenvolvimento de ontologia durante o ciclo de vida (DEVEDŽIĆ, 2006). Segundo Goméz-Pérez et al. (2003), METHONTOLOGY inclui: a identificação do processo de desenvolvimento de ontologia, um ciclo de vida baseado no desenvolvimento de protótipos, técnicas para realizar atividades de gerenciamento, de desenvolvimento e de suporte de ontologia. A Figura 8 ilustra cada uma das atividades de gerenciamento, desenvolvimento e suporte de ontologias. É possível notar a semelhança de muitas dessas atividades com as atividades dos processos de desenvolvimento de software, uma vez que a proposta dessa metodologia foi baseada, segundo Goméz-Pérez et al. (2003), no padrão para

desenvolvimento de software do IEEE22 (Institute of Electrical and

Electr oni cs Engineer s).

Figura 8: Processo de desenvolvimento de ontologia (GOMÉZ-PÉREZ et al., 2003).

Uma breve explicação dessas atividades foi extraída de (GOMÉZ- PÉREZ et al., 2003) e são expostas nos parágrafos a seguir.

As atividades de gerenciamento incluem cronograma, controle e garantia de qualidade. O cronograma engloba a identificação e distribuição das tarefas a serem realizadas, além de definir o tempo e os recursos necessários para a execução dessas tarefas. As atividades de controle visam o cumprimento do cronograma e as atividades de garantia de qualidade buscam assegurar que os produtos, tais como ontologia, software e documentação, sejam satisfatórios quanto a sua qualidade.

As atividades orientadas ao desenvolvimento da ontologia são agrupadas em atividades de pré-desenvolvimento, desenvolvimento e pós- desenvolvimento. Durante o pré-desenvolvimento são realizados estudos para conhecer onde a ontologia será usada, as aplicações onde a ontologia será integrada, etc. No pré-desenvolvimento também é verificada a viabilidade da construção da ontologia. No desenvolvimento, a atividade de especificação busca definir o porquê da construção da ontologia, o uso pretendido e os usuários finais da ontologia. Já na atividade de conceituação, procura-se

modelar de maneira conceitual o conhecimento do domínio especificado. Em seguida, na atividade de formalização, o modelo conceitual do conhecimento é passado para um modelo formal ou semi-computável. Encerrando o desenvolvimento, a atividade de implementação busca construir um modelo computável em uma linguagem de ontologia. No pós-desenvolvimento, por sua vez, são realizadas as atividades de manutenção da ontologia, que procura atualizar e corrigir a ontologia quando necessário, e o uso (e reuso) da ontologia por outras ontologias ou aplicações.

Por último, as atividades de suporte da ontologia são constituídas por atividades realizadas em paralelo às atividades orientadas ao desenvolvimento. A atividade de aquisição de conhecimento tem o objetivo de adquirir conhecimento do especialista do domínio ou por meio de algum tipo de processo automático. A atividade de avaliação faz um julgamento técnico, não só das ontologias, mas também de seus ambientes, de softwares associados e da documentação. A atividade de integração é necessária quando a nova ontologia será construída reusando uma outra ontologia já disponível. A atividade de fusão consiste em obter uma nova ontologia a partir de duas ou mais ontologias de um mesmo domínio. Já atividade de alinhamento consiste em estabelecer um mapeamento entre as ontologias envolvidas, preservando a ontologia corrente, isto é, não realiza a fusão das ontologias. Na atividade de documentação são detalhados de forma clara e exaustiva todos os estágios completados e os produtos gerados. Finalmente, a atividade de gerenciamento de configuração registra todas as versões de documentação e de códigos para o controle de mudanças.

Noy e McGuiness (2001) propõem o método 101 para desenvolvimento de ontologias. Este método é na realidade um resumo das experiências das autoras no desenvolvimento com ferramentas como, por exemplo, o Protégé, na forma de um guia para auxiliar na construção de ontologias ou “guia para a criação da sua primeira ontologia” como sugere o título do relatório técnico. Assim sendo, o método 101 não vai além da construção de ontologias (DEVEDŽIĆ, 2006). A seguir, são apresentados os passos sugeridos em (NOY e McGUINESS, 2001) para construção da ontologia:

• Passo 1: determinar o domínio e o escopo da ontologia. Para

isso, Noy e McGuiness sugerem que as seguintes questões sejam respondidas:

o Qual é o domínio que se deseja cobrir com a ontologia? o Com que propósito a ontologia será utilizada?

o Para que tipos de questões a ontologia deverá responder? o Quem usará e manterá a ontologia?

As autoras sugerem ainda, a elaboração das questões de competência, propostas por Grüninger e Fox (apud GOMÉZ-PÉREZ et al., 2003), comentadas anteriormente nesta seção, como uma maneira de levantar o escopo da ontologia. Note que as questões sugeridas pelas autoras são versões informais das questões de competência e com características menos específicas. Segundo Noy e McGuiness (2001), as questões de competência não precisam ser elaboradas de forma exaustiva, devem ajudar a especificar alguns requisitos e a levantar termos da ontologia, como classes e propriedades, por exemplo. Dessa forma é possível verificar se a ontologia possui informações suficientes para responder as questões, qual o nível o detalhamento necessário ou se existe a necessidade de representação de alguma área de conhecimento em particular.

• Passo 2: considerar a reutilização de ontologias existentes.

Após determinar o escopo e o domínio da ontologia, vale a pena verificar a existência de uma ontologia já construída que atenda esse domínio ou que possa ser refinada e estendida para o domínio e tarefas específicos. A reutilização de ontologias existentes pode ser um requisito caso o novo sistema interaja com outras aplicações comprometidas com determinadas ontologias e vocabulários controlados.

• Passo 3: enumerar os termos importantes da ontologia.

Segundo Noy e McGuiness (2001), é importante listar os termos que se deseja definir ou explicar aos usuários, juntamente com suas propriedades e comentários. Entretanto, o objetivo é uma lista inicial e ampla de termos, sem uma preocupação excessiva quanto à redundância dos conceitos que eles representam, as relações entre os termos, suas propriedades, se um termo é uma

classe ou propriedade e outras características que serão refinadas nos passos seguintes.

• Passo 4: definir classes e hierarquia de classe. Os processos

sugeridos para definir uma hierarquia de classe pelas autoras são:

o Topo para baixo (top-down): esse processo é iniciado com a

identificação dos conceitos mais abrangentes do domínio e a subseqüente especialização dos conceitos.

o Baixo-para-cima (botton-up): esse processo de

desenvolvimento começa com a definição das classes mais específicas e, em seguida, são identificados os agrupamentos dessas classes em termos mais abrangentes.

o Combinação: esse processo é uma combinação dos dois

processos anteriores. Primeiramente, são identificados os conceitos mais notáveis, para, então, generalizá-los e especializá-los de maneira apropriada.

• Passo 5: definir as propriedades das classes – slots. As classes

sozinhas não fornecem informação suficiente para responder as questões de competência elaboradas no Passo 1. Quando algumas classes forem definidas, deve-se descrever a estrutura interna de seus conceitos. No passo anterior, são selecionadas as classes da lista de termos definidas no Passo 3. Muitos dos termos restantes são provavelmente propriedades dessas classes e para cada uma delas deve-se determinar a qual classe pertence. De modo geral há vários tipos de propriedades relativas a classes. Dentre os tipos de propriedades estão: intrínsecas, extrínsecas, partes (física ou abstrata), relacionamentos com outras classes e relacionamentos com outros itens.

• Passo 6: definir os aspectos (facets) das propriedades. As

propriedades podem assumir diferentes valores ou aspectos que descrevem as características do valor ou dos valores que serão atribuídos a ela, como por exemplo, o tipo do valor e a quantidade de valores permitidos (cardinalidade). A

cardinalidade, por exemplo, é distinguida em alguns sistemas

Outros sistemas permitem definir o número mínimo e o número máximo de valores a serem atribuídos a uma propriedade. Quanto aos tipos de dados, os mais comuns encontrados nas linguagens para ontologia são: cadeia de caracteres (string), números (às vezes tipos mais específicos como inteiro ou ponto flutuante), lógicos (booleans), listas de elementos enumerados (enumerated) e instâncias de classes (que permitem definir relações entre indivíduos). As classes permitidas para uma propriedade do tipo instância são chamadas de range (abrangência) da propriedade. Alguns sistemas permitem restringir a abrangência de uma propriedade, quando ela é ligada a uma classe particular. A classe a qual uma propriedade é ligada ou descreve é chamada de

domínio da propriedade.

• Passo 7: criar instâncias. Este último passo é dedicado à criação

de instâncias individuais para classes na hierarquia. Definir uma instância individual requer escolher uma classe, criar a instância individual dessa classe e preencher os valores das propriedades desta classe.

Não há uma única maneira “correta” de modelar um domínio de conhecimento e, portanto, não há uma metodologia que possa ser considerada a melhor (DEVEDŽIĆ, 2006).