• Nenhum resultado encontrado

Arquitetura e Modularização de Ontologias

N/A
N/A
Protected

Academic year: 2021

Share "Arquitetura e Modularização de Ontologias"

Copied!
35
0
0

Texto

(1)

Arquitetura e

Modularização de

Ontologias

Ricardo de Almeida Falbo

Engenharia de Ontologias Departamento de Informática

(2)

Agenda

• Arquitetura Ontológica

Modularizaçã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

– Melhorar o desempenho (sobretudo de inferência)

• Como modularizar uma ontologia?

– Não há uma maneira universal de se modularizar uma ontologia. Modularização realizada durante o levantamento de requisitos Modularização realizada durante o design (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

(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.

(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.

(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)

(d’ Aquin, 2012) R1

(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.

(d’ Aquin, 2012) R2

(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).

(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.

(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 sub-vocabulário.

• É uma tarefa mal definida. É muito dependente de um

cenário de aplicação específico.

(13)

Abordagem Geral para Modularização de

Ontologias

(d’ Aquin, 2012)

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.

(14)

Abordagem Geral para Modularização de

Ontologias

(d’ Aquin, 2012)

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.

(15)

Abordagem Geral para Modularização de

Ontologias

(d’ Aquin, 2012)

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

(16)

Abordagem Geral para Modularização de

Ontologias

(d’ Aquin, 2012)

Ontologia

Selecionar as técnicas mais apropriadas em função dos critérios a serem aplicados

(17)

Abordagem Geral para Modularização de

Ontologias

(d’ Aquin, 2012)

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.

(18)

Abordagem Geral para Modularização de

Ontologias

(d’ Aquin, 2012)

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.

(19)

Abordagem Geral para Modularização de

Ontologias

(d’ Aquin, 2012)

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

(20)

Abordagem Geral para Modularização de

Ontologias

(d’ Aquin, 2012)

Ontologia

Passo final para fazer ajustes visando a liberação da ontologia modular ou

(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?

Ontologias de Fundamentação

mais geral mais específica

Ontologias de Domínio UFO-A/B DOLCE Ontologia de Administração de Condomínio Core Ontologies UFO-C UFO-S SPO

EO SwO RSRO RRO GORO

(23)

Arquitetura Ontológica

(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

(25)
(26)
(27)

Arquitetura Ontológica

(28)

Core Layer

Foundational Layer

SEON – Versão em Discussão

UFO-A UFO-B UFO-C EO COM SPO Domain Layer SwO RSRO GORO

(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

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

(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

(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

(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.

Referências

Documentos relacionados

Na faixa de mW, cuidado deverá ser tomado para que o dispositivo de medição não seja afetado por fluxos de ar, vibrações, e mudanças termais (o recipiente deverá ser o menos

Em adição, tratamos leucócitos humanos de origem feminina e masculina in vitro com estradiol e progesterona, a fim de investigar o possível impacto desses

Posto isso, analisa-se que no quesito barreiras arquitetônicas dos Edifícios 4, 5 e 6, dos 12 entrevistados, 06 destacaram que já encontraram barreiras arquitetônicas nos prédios;

CBAt Nome DN Fase UF Clube Local Data 100 metros.. Col

HISTÓRIA DA ARTE: Para a releitura é importante, ter conhecimentos sobre qual período o artista fez parte, sua relevância para a época e, principalmente, como a obra em questão passou

Para se alcançar aos objetivos propostos, foi realizada pesquisa bibliográfica sobre os principais temas, como: reforma agrária, a região do Brejo Paraibano, a produção de

Devido à intermitência do escoamento bifásico na entrada do sistema de distribuição, ora como padrão de bolhas dispersas e ora como bolhas do tipo capa esférica,