Arquitetura e Modularização de Ontologias

Transcrição

1 Arquitetura e Modularização de Ontologias Ricardo de Almeida Falbo Engenharia de Ontologias Departamento de Informática Universidade Federal do Espírito Santo

2 Agenda Arquitetura Ontológica Modularização de Ontologias Design e Implementação de Ontologias

3 Arquitetura Ontológica Refere-se à estruturação de (grandes) ontologias, ou de maneira mais abrangente, como ontologias podem ser organizadas em um espaço ontológico (p.ex., em uma rede de ontologias) (Obrst, 2010).

4 Modularização de Ontologias Aspecto chave para a definição da arquitetura ontológica Por que modularizar uma ontologia? Facilitar o desenvolvimento e a manutenção Facilitar o reúso de partes da ontologia Modularização realizada durante o levantamento de requisitos Melhorar o desempenho (sobretudo de inferência) Modularização realizada durante o design Como modularizar uma ontologia? Não há uma maneira universal de se modularizar uma ontologia. (d Aquin, 2012)

5 Modularização de Ontologias Refere-se à atividade de identificar um ou mais módulos em uma ontologia. O objetivo é obter um módulo ou um conjunto de módulos a partir de uma ontologia, que satisfaça uma particular aplicação ou cenário. Considera-se um módulo uma subparte de uma ontologia que seja significativa e autocontida. Há duas abordagens principais de modularização de ontologias: Particionamento de Ontologias Extração de Módulo de Ontologia (d Aquin, 2012)

6 Particionamento de Ontologias Dividir a ontologia em partes (sem sobreposição). O resultado não deve ser simplesmente uma coleção de módulos, mas deve incluir também relações de dependência entre módulos. (d Aquin, 2012)

7 Particionamento de Ontologias Relação de Dependência Um módulo M1 depende de M2 se há pelo menos uma entidade (conceito, relação, propriedade, axioma) em M1 cuja definição ou descrição depende de alguma entidade de M2. Se M1 depende de M2, então M1 deve importar M2. (d Aquin, 2012)

8 Particionamento de Ontologias A estrutura resultante não deve ser grafo direcionado arbitrário. d Aquin aponta as seguintes regras a serem respeitadas: Regras relativa à estrutura: Regra 1: Não haver ciclos (dependência bidirecional) R1 (d Aquin, 2012)

9 Particionamento de Ontologias A estrutura resultante não deve ser grafo direcionado arbitrário. d Aquin aponta as seguintes regras a serem respeitadas: Regras relativa à estrutura: Regra 1: Não haver ciclos (dependência bidirecional) Regra 2: Não haver dependência transitiva, i.e., se um módulo M1 reutiliza outro M2, M1 não deve reusar direta ou indiretamente outros módulos dependentes de M2. R2 (d Aquin, 2012)

10 Particionamento de Ontologias Regras relativas à facilidade de manipulação: Regra 3: Tamanho dos módulos Regra 4: Intraconectividade (entidades de um módulo têm de estar conectadas a outras entidades do mesmo módulo). (d Aquin, 2012)

11 Particionamento de Ontologias Alguns métodos de particionamento de ontologias são focados em aspectos relacionados a raciocínio (inferência). Método de MacCartney et al. (2003): visa melhorar a eficiência dos algoritmos de inferência, tornando o raciocínio local. Método de Cuenca Grau et al. (2005): visa preservar a completeza do raciocínio local dentro de todos os módulos criados. (d Aquin, 2012)

12 Extração de Módulo Consiste em extrair uma subparte (o módulo) que cubra um particular subvocabulário. Dada uma ontologia e um conjunto de termos da ontologia, um mecanismo de extração de módulo identifica um módulo que se supõe ser a parte relevante que cobre o subvocabulário. É uma tarefa mal definida. É muito dependente de um cenário de aplicação específico. (d Aquin, 2012)

13 Abordagem Geral para Modularização de Ontologias Ontologia Definir quais as razões para modularizar a ontologia e quais os benefícios esperados. Benefícios comumente considerados: Melhorar desempenho (raciocínio) Facilitar desenvolvimento e manutenção Facilitar reúso de partes da ontologia Facilitar a customização para aplicações particulares. (d Aquin, 2012)

14 Abordagem Geral para Modularização de Ontologias Ontologia Há duas abordagens principais para a modularização de ontologias: Particionamento de ontologias: aplicar quando o propósito da modularização está relacionado à ontologia inteira (p.ex., facilitar a manutenção). Extração de ontologias: aplicar quando o propósito estiver relacionado com a extração de partes específicas da ontologia. (d Aquin, 2012)

15 Abordagem Geral para Modularização de Ontologias Ontologia Definir as características básicas que os módulos resultantes devem apresentar. Critérios lógicos: úteis, em especial, se o propósito for melhorar o desempenho de raciocínio. Incluem correção e completeza locais. Critérios estruturais: relacionados à estrutura da ontologia modularizada. Incluem tamanho, distância intra-módulo de termos. Critérios de qualidade: relacionados à qualidade do módulo. Incluem coesão, cobertura de domínio etc. Relacionamentos entre módulos etc. A escolha dos critérios adequados para serem aplicados é fortemente dependente de uma situação particular e deve ser decidida pelo engenheiro de ontologias. (d Aquin, 2012)

16 Abordagem Geral para Modularização de Ontologias Ontologia Selecionar as técnicas mais apropriadas em função dos critérios a serem aplicados (definidos no passo anterior). (d Aquin, 2012)

17 Abordagem Geral para Modularização de Ontologias Ontologia Dependendo da técnica selecionada no passo anterior, pode haver vários parâmetros requeridos. P.ex., extração de módulos geralmente requer identificar um sub-vocabulário da ontologia original. Particionamento pode requerer indicações de tamanho mínimo e máximo dos módulos. (d Aquin, 2012)

18 Abordagem Geral para Modularização de Ontologias Ontologia Toda vez que um novo conjunto de módulos é produzido, é necessário integrá-lo com os módulos produzidos nas iterações anteriores: Se alguns módulos forem muito pequenos ou logicamente incompletos e a nova iteração produzir módulos complementares, então os resultados podem ser fundidos (merge). Se na nova iteração critérios ainda não explorados forem considerados, pode-se elaborar a parte comum de ambos os resultados. Operações para combinar módulos (interseção, união, diferença) podem ser usadas para derivar novos módulos. (d Aquin, 2012)

19 Abordagem Geral para Modularização de Ontologias Ontologia A avaliação da modularização define se uma nova iteração será necessária. A modularização pode ser avaliada de duas maneiras: Checando os critérios definidos (e eventualmente definindo novos, caso nova iteração seja necessária) Checando se a modularização obtida realmente leva às melhorias esperadas. Em diferentes iterações, apenas o propósito da modularização deve ser mantido o mesmo. (d Aquin, 2012)

20 Abordagem Geral para Modularização de Ontologias Ontologia Passo final para fazer ajustes visando a liberação da ontologia modular ou simplesmente liberar a ontologia modular. (d Aquin, 2012)

21 Arquitetura Ontológica Uma arquitetura ontológica mais robusta deve levar em conta o nível de generalidade das ontologias envolvidas, organizando o espaço ontológico em camadas: camada de fundamentação (ontologia(s) de fundamentação), camada core (core ontologies) e camada de domínio (ontologias de domínio).

22 Arquitetura Ontológica Problema: O que colocar em cada camada? EO SPO GORO SwO RSRO RRO UFO-A/B DOLCE UFO-C UFO-S Ontologia de Administração de Condomínio mais geral mais específica Ontologias de Fundamentação Core Ontologies Ontologias de Domínio

23 Arquitetura Ontológica (Obrst, 2010)

24 Arquitetura Ontológica Combinação de Camadas e Partições O que colocar em cada camada ou partição é uma decisão do engenheiro de ontologias. As diretrizes apresentadas anteriormente são um bom guia, mas requerem decisões do engenheiro de ontologias. Em domínios ricos em processos, um particionamento por processos é uma boa opção (Detoni et al., 2017).

25 SEON Versão 2016

26 SEON Versão Atual

27 Arquitetura Ontológica (Obrst, 2010)

28 SEON Versão em Discussão UFO-A UFO-B Foundational Layer UFO-C EO COM Core Layer SPO RSRO SwO RRO GORO RDPO HCIO RSMO Domain Layer

29 A Fase de Design Tem por objetivo fazer uma ponte entre os modelos conceituais das ontologias de referência e a sua codificação em uma linguagem de ontologias operacionais (p.ex., OWL). Requisitos Atividades Pré-Design: Levantamento de Requisitos Não Funcionais relativos à ontologia operacional a ser produzida Definição da Plataforma de Implementação Atividades de Design: Design da Arquitetura da Ontologia Design Detalhado

30 A Fase de Design Reference Ontology Technical Non-Functional Requirements Elicitation Ontology Engineer Ontology Designer Design Ontology Design Specification Implementation Environment Definition Architectural Design Detailed Design Ontology Programmer Implementation Operational Ontology

31 Atividades Pré-Design Avaliar usos pretendidos relativos à operacionalização da ontologia, de modo a nortear a escolha da plataforma de implementação. Levantamento de Requisitos Não Funcionais relativos à ontologia operacional: Considerar aspectos relacionados à modularização, integração e extensibilidade da ontologia operacional RNFs relativos a propriedades computacionais, tal como desempenho no raciocínio Legibilidade do Código (Usabilidade da ontologia operacional)

32 Atividades Pré-Design Definição da Plataforma de Implementação: Problema: expressividade da linguagem versus satisfação de RNFs computacionais. Muitas vezes é possível escolher a plataforma que melhor atende à combinação de expressividade e facilidade de satisfação dos RNFs identificados. Contudo, nem sempre isso é possível. Muitas vezes a plataforma de implementação é estabelecida a priori e não pode ser alterada. Neste caso, a própria plataforma de implementação vai impor um conjunto de RNFs para a ontologia operacional. Assim, as atividades pré-design são fortemente interrelacionadas e não sequenciais.

33 Atividades Pré-Design Plataforma de Implementação: Linguagens de representação de ontologias operacionais (OWL, RDF(S), F-Logics, Alloy etc.) ou eventualmente até usando outras linguagens não dedicadas a ontologias (p.ex., Java). Raciocinadores (Reasoners): p.ex., Pelet, Racer, FaCT++, HermiT, Jena etc. Armazenamento de dados (incluindo instâncias): arquivos, bancos de dados (de triplas) etc.

34 Design Detalhado Resolver problemas de diferenças de expressividade das linguagens (p.ex., OntoUML e linguagem operacional) Problemas relacionados com desempenho no raciocínio: ontologias pesadas x ontologias leves (heavyweight x lightweight ontologies) Aplicação de Ontology Design Patterns (Logical OPs e Reasoning OPs) e Ontology Idioms (relativos à linguagem operacional escolhida)

35 Implementação da Ontologia Codificação na linguagem operacional escolhida (p.ex., OWL) Em alguns aspectos, a fronteira entre o projeto detalhado e a implementação não é clara. Assim, a solução de problemas e a aplicação de ontology design patterns / idioms pode se dar no contexto da implementação.