Carolina Howard Felicíssimojulio/CAROL.pdf · Felicíssimo, Carolina Howard; Leite, Julio Cesar Sampaio do Prado; Breitman, Karin Koogan. Interoperabilidade Semântica na Web: Uma

Carolina Howard Felicíssimo

Interoperabilidade Semântica na Web: Uma Estratégia para o Alinhamento Taxonômico de Ontologias

Dissertação de Mestrado

Dissertação apresentada ao Programa de Pós-Graduação em Informática do Departamento de Informática da PUC-Rio como parte dos requisitos parciais para obtenção do título de Mestre em Informática.

Orientadores: Julio Cesar Sampaio do Prado Leite Karin Koogan Breitman

Rio de Janeiro

Agosto de 2004


Interoperabilidade Semântica na Web:

Uma Estratégia para o Alinhamento Taxonômico de Ontologias

Dissertação apresentada como requisito

parcial para a obtenção do grau de Mestre pelo Programa de Pós-graduação em Informática do Departamento de Informática do Centro Técnico e Científico da PUC-Rio. Aprovada pela Comissão Examinadora abaixo assinada.

Prof. Julio Cesar Sampaio do Prado Leite Orientador

Departamento de Informática – PUC-Rio

Profª. Karin Koogan Breitman Co-orientadora

Departamento de Informática – PUC-Rio

Prof. Carlos José Pereira de Lucena Departamento de Informática – PUC-Rio

Profª Simone Diniz Junqueira Barbosa Departamento de Informática – PUC-Rio

Prof. Ricardo Choren Noya Depto de Engenharia de Computação – IME

Prof. José Eugênio Leal Coordenador Setorial do Centro

Técnico Científico – PUC-Rio

Rio de janeiro, 19 de agosto de 2004

Todos os direitos reservados. É proibida a reprodução total ou parcial do trabalho sem autorização da universidade, do autor e dos orientadores.


Graduou-se em Engenharia de Computação na PUC-Rio em 2001. É pesquisadora associada ao Laboratório de Engenharia de Software (LES) da PUC-Rio, atuando na área de Web Semântica da Engenharia de Software.

Ficha Catalográfica CDD: 004

Felicíssimo, Carolina Howard Interoperabilidade semântica na Web : uma estratégia para o alinhamento taxonômico de ontologias / Carolina Howard Felicíssimo ; orientadores: Julio Cesar Sampaio do Prado Leite, Karin Koogan Breitman. – Rio de Janeiro : PUC, Departamento de Informática, 2004. 180 f. : il. ; 30 cm Dissertação (mestrado) – Pontifícia Universidade Católica do Rio de Janeiro, Departamento de Informática. Inclui referências bibliográficas. 1. Informática – Teses. 2. Web semântica. 3. Interoperabilidade semântica. 4. Ontologias. 5. Interoperabilidade de ontologias. 6. Alinhamento. 7. Agentes de software. 8. Engenharia de software. I. Leite, Julio Cesar Sampaio do Prado. II. Breitman, Karin Koogan. III. Pontifícia Universidade Católica do Rio de Janeiro. Departamento de Informática. IV. Título.

A todos aqueles que, de uma forma ou de outra, ajudaram a fazer este trabalho.

Agradecimentos

A Deus, por todos os caminhos iluminados decisivos na minha vida.

À minha família pelo apoio, carinho, suporte e encorajamento. Em especial, aos

meus pais e irmã, à Izalea, ao meu afilhado Jordan e a sua irmã Giulia.

Ao meu orientador, Professor Julio Cesar Sampaio do Prado Leite que, mesmo

quando eu ainda estava na graduação, me ofereceu a oportunidade de fazer

mestrado sob sua orientação. Sua preocupação com os detalhes ajudou muito para

a qualidade deste trabalho.

À minha co-orientadora, Professora Karin Koogan Breitman que me apresentou

ao tema de pesquisa da dissertação e teve certeza, desde o início, deste tratar-se de

um bom tema. Sua paciência, apoio, atenção e didática contribuíram para que,

com o tempo, eu conseguisse caminhar sozinha no desenvolvimento do trabalho

com tranqüilidade e confiança.

À minha amiga Karin, por me propiciar tantos momentos de descontração com

sua família e amigos. Pelo otimismo e confiança na minha capacidade.

Aos meus amigos, em especial, Gustavo Robichez, Miriam Sayão, Lyrene

Fernandes e Roberto Martins por todos os ensinamentos profissionais e pessoais, e

por estarem sempre presentes em tantos momentos difíceis e bons da minha vida.

Aos Professores Carlos José Pereira de Lucena, Simone Barbosa e Ricardo

Choren por participarem da Comissão Examinadora. Ao professor Ulf Bergmann

pela ajuda e por todos os recursos disponibilizados, essenciais para a execução do

trabalho no período devido. A todos os professores e funcionários do

Departamento pela ajuda. Ao Luís Fernando pelo seu suporte.

À CAPES, à FAPERJ e ao Departamento de Informática da PUC-Rio, pelos

auxílios concedidos, sem os quais este trabalho não poderia ter sido realizado.

Resumo Felicíssimo, Carolina Howard; Leite, Julio Cesar Sampaio do Prado; Breitman, Karin Koogan. Interoperabilidade Semântica na Web: Uma Estratégia para o Alinhamento Taxonômico de Ontologias. Rio de Janeiro, 2004. 180p. Dissertação de Mestrado - Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro.

Com a evolução da Web atual para a Web Semântica, acredita-se que as

informações disponíveis estarão estruturadas de forma a permitir o processamento

automático de seu conteúdo por máquinas. Além do processamento individual,

deseja-se uma melhor troca de informações entre aplicações Web. Para estes

propósitos, são necessários mecanismos que garantam a interoperabilidade

semântica, i.e., identificação e compatibilidade de informações. Neste sentido,

ontologias são utilizadas como um recurso para disponibilizar um vocabulário

estruturado e livre de ambigüidades. Ontologias fornecem um padrão bem

definido para a estruturação da informação e promovem um formalismo passível

de processamento automático. Neste trabalho, propomos uma estratégia para

interoperabilidade de ontologias. O Componente para Alinhamento Taxonômico

de Ontologias – CATO, resultado da implementação desta estratégia proposta,

alinha automaticamente as taxonomias de ontologias comparadas. O alinhamento

realizado é obtido em três etapas executadas seqüencialmente. A primeira etapa

compara lexicalmente os conceitos das ontologias entradas e usa um mecanismo

de poda estrutural dos conceitos associados como condição de parada. A segunda

etapa compara estruturalmente as hierarquias das ontologias identificando as

similaridades entre suas sub-árvores comuns. A terceira etapa refina os resultados

da etapa anterior classificando os conceitos identificados como similares em bem

similares ou pouco similares, de acordo com um percentual de similaridade pré-

definido.

Palavras-chave

Web Semântica, Interoperabilidade Semântica, Ontologias,

Interoperabilidade de Ontologias, Alinhamento, Agentes de Software, Engenharia

de Software.

Abstract Felicíssimo, Carolina Howard; Leite, Julio Cesar Sampaio do Prado; Breitman, Karin Koogan. Semantic Web Interoperability: One strategy for the Taxonomic Ontology Alignment. Rio de Janeiro, 2004. 180p. Master Dissertation - Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro.

With the Web evolving towards a Semantic Web, it is believed that the

available information will be presented in a meaningful way to allow machines to

automatically process its content. Besides the individual processing, a better

information exchange among Web applications is desired. For this purpose,

mechanisms are called for guarantee the semantic interoperability, that is, the

identification and compatibility of information. In this direction, ontologies are

used as one resource to make available a structured vocabulary, free of

ambiguities. Ontologies provide a well-defined standard to structure the

information and to promote formalism for automatic processing. In this work, we

propose one strategy for ontology interoperability. The Ontology Taxonomic

Alignment Component – CATO, which is the result of the implementation of this

proposed strategy, provides an automatic taxonomic ontologies alignment. In this

way, the alignment is obtained by a three-step process. The first step is the lexical

comparison between the concepts from the entries ontologies. It uses a trimming

mechanism of the related associated concepts as a stop condition. The second step

is the structural comparison of the ontologies structures used to identify the

similarities between common sub-trees. The third step refines the results of the

previous step, classifying the similar identified concepts as very similar or little

similar, according to a pre-defined similarity measurement.

Keywords

Semantic Web, Semantic Interoperability, Ontologies, Ontologies

Interoperability, Alignment, Software Agents, Software Engineering.

Sumário

1 Introdução 14

1.1. A Web Semântica 14

1.2. Interoperabilidade Semântica 16

1.3. Ontologia 17

1.4. Guia do Leitor 20

2 Interoperabilidade de Ontologias 21

2.1. Mecanismos 21

2.2. Alinhamento de Ontologias 24

2.2.1. Compatibilidade de Termos 25

2.2.2. Requisitos 26

2.2.3. Resultados Considerados Satisfatórios 27

2.3. Revisão da Literatura 28

3 A Estratégia 33

3.1. Um Exemplo Simplificado 35

3.2. Primeira Etapa: Comparação Lexical com Uso de Sinônimos e

Mecanismo de Poda Estrutural como Condição de Parada 37

3.2.1. Revendo o Exemplo 39

3.3. Segunda Etapa: Comparação Estrutural Usando uma Implementação

do Algoritmo TreeDiff 40

3.3.1. Informações de equivalência 43

3.3.2. Grupos de Equivalência 44


3.4. Terceira Etapa: Uso de Medidas de Similaridades para os Ajustes

Finos 46


3.5. A Implementação 49

3.5.1. Características da linguagem Java 49

3.5.2. A API Jena 50

3.5.3. A linguagem OWL 50

3.5.4. O CATO 51

4 Estudo de Caso 58

4.1. Introdução 58

4.2. Estratégia de Seleção das Ontologias 59

4.3. Primeiro Estudo de Caso 61

4.3.1. Resultado da Primeira Etapa 64

4.3.2. Resultados das Etapas sem Ordenação Alfabética 64

4.3.3. Resultados das Etapas com Ordenação Alfabética 67

4.3.4. Avaliação dos Resultados 70

4.3.5. Problemas Encontrados 71

4.4. Segundo Estudo de Caso 72






4.5. Terceiro Estudo de Caso 79






5 Conclusões 88

5.1. Contribuições 88

5.1.1. Comparação com outras soluções 89

5.2. Avaliação da Estratégia 90

5.3. Trabalhos Futuros 94

6 Referências Bibliográficas 101

Anexo A – Código em OWL das Ontologias do Primeiro Estudo de Caso108

Ontologia de saída do módulo sem ordenação alfabética 108

Ontologia de saída do módulo com ordenação alfabética 108

Primeira Ontologia de entrada 108

Segunda Ontologia de entrada 115

Anexo B – Código em OWL das Ontologias do Segundo Estudo de Caso

137





Anexo C – Código em OWL das Ontologias do Terceiro Estudo de Caso138





Anexo D – Informações dos Métodos do CATO 139

Anexo E – Código em Java da Implementação do CATO 144

SolCombSinonimos.java e SolCombSinonimosWithOrderNodes.java 144

BDQuery.java 163

DOMComparatorViewWithoutInterface.java 165

LastStepSolCombSinonimos.java 168

Lista de figuras

Figura 1 – Arquitetura definida para a Web Semântica em (Berners-Lee, 2000b)15

Figura 2 – Combinação de ontologias, adaptado de (Noy, 1999b) 22

Figura 3 – Alinhamento de ontologias, adaptado de (Noy, 1999b) 22

Figura 4 – Mapeamento de ontologias, adaptado de (Noy, 1999b) 23

Figura 5 – Integração de ontologias 23

Figura 6 – Interseção de mercadorias de aplicações complementares 24

Figura 7 – O conjunto de ferramentas PROMPT de (Noy e Musen, 2003) 29

Figura 8 – Estratégia para o alinhamento taxonômico de ontologias 34

Figura 9 – Exemplo de ontologias a serem alinhadas 36

Figura 10 – Informações cadastradas no banco de sinônimos criado 37

Figura 11 – Sinônimos identificados dos conceitos das ontologias analisadas 39

Figura 12 – Informações identificadas na primeira etapa da estratégia 40

Figura 13 – Uso do algoritmo do TreeDiff de (Bergmann, 2002) 42

Figura 14 – Transformação da estrutura de ontologias para a estrutura em XML 43

Figura 15 – Grupos de equivalência identificados no módulo sem ordenação

alfabética 45

Figura 16 – Grupos de equivalência identificados no módulo com ordenação

alfabética 45

Figura 17 – Valores calculados de similaridade entre os termos 47

Figura 18 – Informações identificadas na terceira etapa da estratégia 49

Figura 19 – Classes dos módulos principais do CATO, com seus métodos 53

Figura 20 – Arquitetura do CATO 54

Figura 21 – Entradas e saídas das etapas de alinhamento do CATO 55

Figura 22 – Representações da ontologia de publicações escolhida 61

Figura 23 – Gerenciamento de Conhecimento no ITM 62

Figura 24 – Ontologias comparadas 63

Figura 25 – Sinônimos cadastrados identificados 64

Figura 26 – Grupos de equivalência identificados no módulo sem ordenação 66

Figura 27 – Percentuais de similaridade calculados 66

Figura 28 – Informação adicionada, resultado do alinhamento com o CATO 67


alfabética 68





Figura 34 – Grupos de equivalência identificados no módulo sem ordenação 74




alfabética 77





Figura 42 – Informação adicionada, resultado do alinhamento com o uso de

sinônimos na primeira etapa do CATO 82

Figura 43 – Estruturas hierárquicas das ontologias comparadas 83


alfabética 85



Figura 47 – Sinônimos do termo carro, ordenados por estimativa de freqüência 96

Figura 48 – Hiperonímia de carro significando veículo automotor (carro é um

tipo de ...) 96

Figura 49 – Hiponímia de carro significando veículo automotor (... é um tipo de

carro) 97

Figura 50 – Holonímia de carro (carro é parte de ...) 97

Figura 51 – Meronímia de carro significando veículo automotor (... é parte de

carro) 97

Figura 52 – Termos do domínio de carro significando veículo automotor 97

Figura 53 – Representação em árvore de relacionamentos de composição 98

Lista de Abreviaturas

API – Application Programming Interface

ATLAS – Agent Transaction Language for Advertising Services

CATO – Componente para Alinhamento Taxonômico de Ontologias

CMU – Carnegie Mellon University

DAML – Darpa Agent Markup Language

OIL – Ontology Inference Layer

DAML+OIL – Darpa Agent Markup Language + Ontology Inference Layer

DOM – Document Object Model

HTML – HyperText Markup Language

IEEE – Institute of Electrical and Electronics Engineers

ITM – Intelligent Topic Manager

LAL – Léxico Ampliado da Linguagem

OWL – OWL Web Ontology Language

PUC-RIO – Pontifícia Universidade Católica do Rio de Janeiro

RDF – Resource Description Framework

RDF Schema – RDF Vocabulary Description Language

SUMO – Suggested Upper Merged Ontology

UdI – Universo de Informação

URI – Uniform Resource Identifier

URL – Uniform Resource Locator

XML – Extensible Markup Language

W3C – World Wide Web Consortium

Web – World Wide Web

1 Introdução

Atualmente na World Wide Web tem-se um grande volume de informações

disponibilizado sem uma forma estruturada de representação de conhecimento.

Desta maneira, seu conteúdo é processado apenas por humanos; máquinas não

obtêm suporte explícito para este tipo de tarefa.

Para fornecer suporte ao processamento por máquinas das informações

disponíveis na Web – World Wide Web, ontologias vêm sendo utilizadas. Nas

ontologias, informações são estruturadas em um vocabulário livre de

ambigüidades e com um formalismo passível de processamento automático.

No entanto, além do processamento é desejável também que máquinas

troquem informações. Para satisfazer esta necessidade, o problema de

interoperabilidade semântica precisa ser resolvido. Parte deste problema, a

interoperabilidade semântica na Web, é tratada ao longo do texto.

Questões relativas à evolução da Web para a Web Semântica, à

interoperabilidade semântica e às ontologias são tratadas nos próximos tópicos

deste capítulo. Por fim, um guia do leitor também é apresentado.

1.1. A Web Semântica

Pesquisadores da indústria e da academia vêm explorando a possibilidade de

criar uma Web Semântica. Nesta nova Web, informações estarão organizadas de

forma que máquinas processem e integrem seus recursos de maneira inteligente,

possibilitando, por exemplo, buscas de informações mais rápidas e precisas, e

facilitando a comunicação entre seus dispositivos heterogêneos. Além disso,

através da estruturação e conjuntos de regras de inferência, informações poderão

ser deduzidas automaticamente. Desta maneira, ao contrário da Web atual, o

conteúdo da Web Semântica não será processado apenas por humanos, mas

também por máquinas (Berners-Lee et al., 2001).

A Web Semântica não é uma nova Web desconectada da Web atual, mas

sim, sua extensão. Seu desenvolvimento é um esforço colaborativo da W3C –

Introdução 15

World Wide Web Consortium – (SemanticWeb, 2004) com a participação de um

grande número de pesquisadores e parceiros da indústria.

A arquitetura da Web Semântica é definida como ilustrado na Figura 1

(Berners-Lee, 2000b). Nesta arquitetura, cada camada estende a funcionalidade e

expressividade de suas camadas inferiores. A camada base refere-se ao uso de

identificadores únicos para nomeação dos recursos Web, os URIs – Uniform

Resource Identifiers. As camadas referentes às linguagens XML – Extensible

Markup Language – (XML, 2004) e RDF – Resource Description Framework –

(Miller et al., 2004) desempenham papéis fundamentais (Decker et al., 2000). A

camada XML é responsável pela estruturação de documentos e a RDF pelo

modelo de seus dados. No entanto, essas camadas são elementares e, por isso, são

necessárias outras camadas de suporte às ontologias e à lógica para fornecer a

semântica esperada para a evolução da Web atual.

Ontologias disponibilizam um vocabulário estruturado para explicar as

relações entre seus diferentes termos e permitir as interpretações destes, livres de

ambigüidades. A camada de ontologias na arquitetura da Web Semântica fornece

um padrão bem definido para a estruturação de informação. A camada lógica é

necessária para prover o formalismo passível de processamento automático

(Fensel, 2001) como, por exemplo, permitir serviços de raciocínio por máquinas.

Por fim, a última camada trata-se da “Web da Confiança”, onde as assinaturas

digitais funcionam como um mecanismo de prevenção de inconsistências nessa

Web Semântica (Berners-Lee, 2000a).

Figura 1 – Arquitetura definida para a Web Semântica em (Berners-Lee, 2000b)

Introdução 16

De acordo com esta arquitetura definida, a Web Semântica pode ser

entendida como uma reengenharia da Web atual, onde não só a linguagem HTML

– HyperText Markup Language – (HTML, 2004) é utilizada para dar a formatação

da informação disponível, mas também, haverá o uso de outras linguagens que

garantam o entendimento comum de tal informação, agora estruturada de acordo

com um padrão formal e bem definido. Desta maneira, não só humanos, mas

principalmente as máquinas, poderão processar a informação de forma muito mais

eficaz e eficiente. Essa evolução possibilitará tanto uma maior comunicação, i.e.,

troca de informações, entre as aplicações dessa nova Web quanto,

conseqüentemente, a interoperabilidade semântica entre elas.

1.2. Interoperabilidade Semântica

Entende-se por interoperabilidade semântica a capacidade de dois ou mais

sistemas heterogêneos e distribuídos trabalharem em conjunto, compartilhando as

informações entre eles com entendimento comum de seu significado (Buranarach,

2001).

Para que as informações disponíveis sejam utilizadas pelos diferentes

sistemas é necessário, em um primeiro momento, que estas sejam localizadas,

acessadas e processadas por tais sistemas. Em um segundo momento, devido a sua

heterogeneidade estrutural e semântica, a compatibilidade de seu conteúdo deve

ser realizada (Moreira, 2003). Para auxiliar a satisfazer essas necessidades, com

um esforço computacional reduzido, acredita-se que uma possível solução seja o

uso de padrões, i.e., convenções (Buranarach, 2001).

Para convenções serem adotadas na solução de problemas é necessário,

sobretudo, que estas sejam expressivas, inequívocas (sem ambigüidade) e bem

aceitas, além de extensíveis. Mesmo satisfazendo esses requisitos, o processo de

aceitação de uma convenção é demorado e, conseqüentemente, custoso. Desta

maneira, as novas extensões procuram ser as extensões de convenções já adotadas.

Estas extensões devem ser sucessivas e progressivas, fazendo uso, por exemplo,

de soluções com arquitetura em camadas.

Soluções tradicionais com arquitetura em camadas, dadas para tentar

garantir a compatibilidade de informações, são conhecidas na área de banco de

dados como, por exemplo, soluções que fazem uso de mediadores e conversores.

Introdução 17

No entanto, essas soluções funcionam bem apenas em um universo onde existam

os mesmos tipos de estruturas para o armazenamento de informações e estas

sejam previamente conhecidas. Assim, novas soluções com arquitetura em

camadas para a compatibilidade de informações são desejadas.

Limitando os sistemas heterogêneos e distribuídos às diversas aplicações

existentes na Web Semântica, a interoperabilidade semântica limita-se à

interoperabilidade semântica de aplicações desta Web Semântica.

O uso de ontologias é uma das possibilidades mais promissoras para garantir

a interoperabilidade semântica de aplicações Web. Isto porque é a convenção

adotada para expressar as informações explícitas e implícitas destas aplicações de

forma estruturada, além de fornecer um vocabulário comum com uma semântica

bem definida.

1.3. Ontologia

Ontologia é um termo originário da filosofia usado para representar uma

visão do mundo em um sistema de categorias. Como descrito em (Sowa, 2003), o

assunto ontologias é o estudo das categorias de coisas que existem ou podem

existir em algum domínio. O resultado deste estudo, denominado uma ontologia, é

um catálogo dos tipos de coisas supostas a existir em um domínio de interesse, na

perspectiva de uma pessoa. Esse catálogo é expresso por linguagens para

ontologias. Em Ciência da Computação, a definição mais comum de ontologia é a

proposta em (Gruber, 1993), onde uma ontologia é definida como a

“especificação explícita e formal de um conceito compartilhado”.

Neste trabalho, é adotada a estrutura para descrição de ontologias

apresentada em (Maedche, 2002), por estar em conformidade com a linguagem

padrão atual para ontologias, a linguagem OWL – OWL Web Ontology Language

– (Dean et al., 2004a). Esta estrutura é representada pela tupla O:= {C, R, HC, rel,

AO},onde:

− C (conceitos) e R (relações) são dois conjuntos disjuntos;

− HC é uma relação direcionada HC ⊆ C x C que é chamada hierarquia de

conceitos ou taxonomia. Por exemplo, HC (C1, C2) significa que C1 é um

subconjunto de C2;

Introdução 18

− rel é uma função rel : R C x C que relaciona não taxonomicamente

conceitos;

− AO é um conjunto de axiomas expresso em linguagem lógica apropriada.

Conceitos de um domínio com relacionamentos de especialização, i.e.,

relacionamentos do tipo é-um, são descritos em ontologias utilizando uma

organização taxonômica. Aspectos de composição, i.e., relacionamentos do tipo

parte-de/todo, são ortogonais às ontologias e devem ser representados por meio de

funções não taxonômicas, por exemplo, propriedades.

Em um futuro próximo, acredita-se que ontologias serão utilizadas pela

maioria das páginas da Web Semântica (Hendler, 2001). As principais razões para

esta utilização, como citado em (Noy, 2001b), são:

• Compartilhar o entendimento da estrutura da informação entre pessoas e

agentes de software;

• Possibilitar o reuso de conhecimento do domínio;

• Tornar as verdades absolutas do domínio explícitas;

• Separar o conhecimento do domínio do conhecimento operacional; e

• Analisar o conhecimento do domínio.

Ontologias podem possuir descrições mais gerais, utilizadas nas chamadas

ontologias genéricas (também conhecidas como as upper ontologies) ou mais

específicas, utilizadas nas chamadas ontologias de domínio de aplicação Web

(também conhecidas como as web ontologies).

Como descrito em (SUOWG, 2004), uma ontologia mais genérica (upper

ontology) limita-se aos conceitos que são meta, genéricos, abstratos e filosóficos.

Conceitos específicos de um dado domínio não são incluídos nas ontologias

genéricas. Assim, estas ontologias fornecem uma estrutura, i.e., como os conceitos

estão organizados, e conceitos genéricos o suficiente para serem utilizados, em um

nível elevado, na construção de outras ontologias de várias áreas de domínio.

As ontologias genéricas SUMO – Suggested Upper Merged Ontology –

(SUMO, 2004) e OpenCyc (OpenCYC, 2004) são os exemplos mais conhecidos

de ontologias genéricas (upper ontologies). Tais ontologias são padrões do grupo

de trabalho de ontologias genéricas da IEEE – Institute of Electrical and

Electronics Engineers – (SUOWG, 2004).

Introdução 19

Apesar da quantidade de informações conseguida com o uso das ontologias

genéricas, este trabalho trata sempre de ontologias específicas de domínios de

aplicação. Isto porque prioriza o alinhamento das ontologias utilizadas para

descrever as aplicações da Web Semântica, na visão da Engenharia de Software.

Estas ontologias, parciais e contextualizadas, são as de aplicações Web, i.e., as

web ontologies (Hendler, 2001).

Acredita-se que ontologias devem ser desenvolvidas localmente por

engenheiros de software e não por especialistas em ontologias. Sendo assim,

Breitman e Leite em (Breitman e Leite, 2004) defendem que a ontologia é um

produto da engenharia de requisitos. Entende-se que é responsabilidade do

engenheiro de requisitos modelá-la: primeiro, porque é durante o processo de

definição do produto que o conhecimento do Universo de Informação1 – UdI – é

descoberto, i.e., elicitado; e segundo, porque a engenharia de requisitos tem um

núcleo de conhecimento sobre os processos para captura, modelagem e análise de

informações relevantes que pode auxiliar na tarefa de construção de ontologias.

A tarefa de desenvolvimento ou de reutilização de partes das ontologias

existentes deve ser simples o suficiente de modo a permitir que tanto o engenheiro

de software quanto as pessoas que não são especialistas em ontologias possam

realizá-la.

Com este enfoque, um processo para construção de ontologias, centrado em

uma estratégia de elicitação denominada Léxico Ampliado da Linguagem – LAL –

(Leite e Franco, 1993), é proposto em (Breitman e Leite, 2003). Tal processo

automatiza um grande número das tarefas de geração de ontologias, guiando o

usuário a executar apenas aquelas em que sua intervenção é necessária. Uma

instância deste processo foi implementada e é descrita em (Felicíssimo et al.,

2003a).

No entanto, mesmo que uma ontologia seja criada segundo os preceitos da

Engenharia de Requisitos ou dos conhecimentos de Modelagem Conceitual, ou

tendo sua construção suportada por metodologias e métodos para criação de

ontologias, como a metodologia de Grüninger e Fox, a METHONTOLOGY, entre

tantas outras encontradas, por exemplo, em (Gómez-Pérez et al., 2004), persiste o

1 Neste trabalho, entende-se por Universo de Informação, o local onde as informações ou

fontes de informações sobre uma aplicação, que se deseja elicitar, são encontradas.

Introdução 20

problema de como compatibilizar seus termos com os termos de outras diferentes

ontologias. Neste cenário, a interoperabilidade de ontologias se torna

fundamental.

1.4. Guia do Leitor

O segundo capítulo desta dissertação trata o problema de interoperabilidade

de ontologias. Apresenta seus mecanismos, em especial, o mecanismo de

alinhamento, que foi escolhido para este trabalho. As identificações priorizadas no

alinhamento para a compatibilidade dos termos das ontologias comparadas são

numeradas. Ainda neste capítulo, os requisitos para o alinhamento no contexto da

Web Semântica e seus resultados considerados satisfatórios são apresentados. Em

seguida, alguns trabalhos da literatura revisados sobre interoperabilidade de

ontologias são descritos.

O terceiro capítulo apresenta a estratégia elaborada para o alinhamento

taxonômico de ontologias, com suas três etapas de execução e sua implementação,

o Componente para Alinhamento Taxonômico de Ontologias – CATO. Um

exemplo simplificado foi criado para auxiliar o entendimento do alinhamento

realizado pela estratégia.

O quarto capítulo apresenta três diferentes estudos de caso realizados para

demonstrar o funcionamento da estratégia elaborada. O CATO alinhou as

ontologias escolhidas em todos estes estudos de caso. A estratégia de seleção

dessas ontologias e os resultados conseguidos com o alinhamento também são

apresentados neste capítulo.

No quinto capítulo, as conclusões, as contribuições e algumas avaliações da

estratégia são apresentadas. Também neste capítulo, os trabalhos futuros são

discutidos.

2 Interoperabilidade de Ontologias

Ontologias representam entidades importantes, também chamadas de

conceitos, com suas relações taxonômicas e não-taxonômicas, e as restrições

aplicadas nestas entidades de domínio. Em algumas representações, pode-se até

usar axiomas para declarar as verdades que são válidas no Universo de Discurso

de uma ontologia, i.e., o contexto onde uma ontologia está inserida.

Na Web Semântica, onde as informações são heterogêneas e distribuídas, o

uso de ontologias, além de prover uma teoria do domínio, provê também uma

representação comum para a troca das informações. Desta maneira, diferentes

agentes de software que atuam neste ambiente obtêm suporte no processamento

automático de informações. No entanto, para que trabalhem em conjunto,

trocando automaticamente as informações representadas em ontologias, são

necessários mecanismos que garantam a interoperabilidade de ontologias. 2.1. Mecanismos

Atualmente existem algumas aproximações para o processo de

compatibilidade de ontologias na Web Semântica, entre elas: (1) combinação de

ontologias (Noy e Musen, 1999a), (2) alinhamento de ontologias (Noy e Musen,

1999a), (3) mapeamento de ontologias (Noy e Musen, 2003), (4) integração de

ontologias (Pinto et al., 1999), entre outras. Tais mecanismos são descritos a

seguir:

Combinação de Ontologias – Na combinação de ontologias tem-se como

resultado a versão das ontologias originais combinadas em uma ontologia única,

com todos seus termos juntos e sem a definição clara de suas origens.

Normalmente as ontologias originais descrevem domínios similares2 ou de

2 Neste trabalho, entende-se por domínios similares aqueles domínios que tratam do mesmo

assunto.

Interoperabilidade de Ontologias 22

sobreposição3. A Figura 2 ilustra um exemplo de combinação de ontologias, onde

os dois conceitos compatíveis, carro da ontologia O1 e veículo da ontologia O2,

são combinados, i.e., unidos, na ontologia única O.

O1 O2

carroveículo

carroveículo

( O = O1 + O2 )

O

O1 O2O2

carroveículo

carroveículo

( O = O1 + O2 )

O

Figura 2 – Combinação de ontologias, adaptado de (Noy, 1999b)

Alinhamento de Ontologias – No alinhamento de ontologias tem-se como

resultado as duas ontologias originais separadas, mas nestas são adicionadas às

ligações entre seus termos equivalentes. Estas ligações permitem que as

ontologias alinhadas reusem as informações umas das outras. O alinhamento

normalmente é realizado quando as ontologias são de domínios complementares4.

A Figura 3 ilustra um exemplo de alinhamento de ontologias, onde o conceito

carro de O1 é alinhado, i.e., ligado, ao conceito veículo de O2.

veículoveículo

carrocarro

O1

O1

O2

O2

veículoveículo

carrocarro

O1

O1

O2

O2

Figura 3 – Alinhamento de ontologias, adaptado de (Noy, 1999b)

3 Neste trabalho, entende-se que um domínio A qualquer é de sobreposição a um domínio B

qualquer, quando A além de possuir as informações contidas em B também possui informações adicionais sobre o mesmo assunto de B.

4 Neste trabalho, entende-se que um domínio A qualquer é complementar a um domínio B qualquer, quando A adiciona informações a B. Normalmente, domínios complementares tratam de assuntos diferentes, mas suas partes comuns tratam de um mesmo assunto.


Mapeamento de Ontologias – No mapeamento de ontologias tem-se como

resultado uma estrutura formal com expressões que ligam os termos de uma

ontologia nos termos de uma outra ontologia. Este mapeamento pode ser usado

para transferir instâncias de dados, esquemas de integração e de combinação, e

outras tarefas similares. A Figura 4 ilustra um exemplo de mapeamento de

ontologias, onde os conceitos carro de O1 e veículo de O2 são mapeados em

expressões formais.

veículoveículocarrocarro

O1 O2

O1 O2

veículoveículocarrocarro

O1O1 O2O2

O1O1 O2

Figura 4 – Mapeamento de ontologias, adaptado de (Noy, 1999b)

Integração de Ontologias – Na integração de ontologias tem-se como

resultado uma ontologia única criada pela montagem, extensão, especialização ou

adaptação de outras ontologias de assuntos diferentes. Na integração de ontologias

é possível identificar as regiões que foram criadas a partir das ontologias originais.

A Figura 5 ilustra um exemplo de integração de ontologias, onde os conceitos

carro de O1, veículo de O2, automóvel de O3 e meio de transporte terrestre

de O4 são integrados, i.e., unidos, na ontologia única O.

O2

carroveículo

automóvelmeio de transporte terrestre

carroveículo


( O = O1 + O2 + O3 + O4 )

O

O1 O3 O4O2O2

carroveículo


carroveículo


( O = O1 + O2 + O3 + O4 )

O( O = O1 + O2

+ O3 + O4 )

O

O1O1 O3O3 O4O4

Figura 5 – Integração de ontologias

Apesar do resultado final tanto da combinação quanto da integração de

ontologias ser uma ontologia única, constituída pela união dos termos das


ontologias originais, a principal diferença entre estes dois mecanismo é que no

primeiro as ontologias tratam do mesmo assunto, o que não acontece

necessariamente no segundo.

Neste trabalho busca-se a identificação dos termos equivalentes de

aplicações complementares e o endereçamento destes termos de forma a permitir a

negociação de suas informações. Por estas razões, o mecanismo de alinhamento

de ontologias é o escolhido.

2.2. Alinhamento de Ontologias

Entende-se por alinhamento de ontologias o processo a que as diversas

aplicações de sistemas abertos, com suas diferentes ontologias, terão que se

submeter para garantir uma representação intermediária da informação que poderá

ser compartilhada entre elas. O resultado deste processo é um modelo persistente

que estabelece a ligação entre as ontologias alinhadas, permitindo o

compartilhamento e a reutilização de suas informações.

Para exemplificar, suponha que dois agentes de software, de dois sites

específicos de aplicações complementares, desejam realizar uma negociação. Um

agente refere-se a uma aplicação do domínio Fast Food e o outro a uma aplicação

do domínio de Bebidas. Na aplicação do domínio Fast Food só existem bebidas

não-alcoólicas, mas na do domínio de Bebidas existem tanto bebidas não-

alcoólicas como alcoólicas. O processo de alinhamento deverá garantir que não

haverá a inclusão de bebidas alcoólicas na negociação entre as aplicações dos

domínios de Fast Food e Bebidas, ou seja, que só as informações comuns,

interseção ilustrada na Figura 6, serão as informações compartilhadas entre elas.

Figura 6 – Interseção de mercadorias de aplicações complementares

Para a identificação dos termos a serem alinhados em ontologias

comparadas, bons algoritmos de identificação são necessários de forma a

minimizarem possíveis problemas como: presença de inconsistências encontradas

nas comparações dos termos de ontologias; falta de completude no alinhamento de


todos seus possíveis termos; e risco de inviabilidade da estratégia frente às

inconsistências existentes. Aspectos que devem ser tratados para evitar possíveis

inconsistências no processo de alinhamento são apresentados a seguir. Os demais

problemas são avaliados no tópico 5.2. deste texto.

2.2.1. Compatibilidade de Termos

Para alinhar diferentes ontologias é necessário listar as diferenças entre seus

termos, perceber as similaridades entre estes, detectar tanto possíveis

inconsistências quanto a falta de informação (completeza). Preocupa-se, em

particular, com a identificação de:

1. Conceitos com um mesmo significado, mas rotulados com nomes diferentes;

2. Conceitos rotulados com o mesmo nome, mas com significados diferentes;

3. Diferenças na escrita dos termos das ontologias como, por exemplo: um termo

no plural e outro no singular, um no feminino e outro no masculino, e em

diferentes tempos verbais;

4. Propriedades com um mesmo significado, mas rotuladas com diferentes

nomes;

5. Propriedades rotuladas com o mesmo nome, mas com significados diferentes;

6. Diferenças nas restrições e nas propriedades utilizadas;

7. Diferenças nas propriedades utilizadas em restrições – conceitos relacionados

que são similares;

8. Diferenças nos conceitos relacionados utilizados em restrições – propriedades

que são similares;

9. Diferenças no número de restrições; (diferenças nos casos onde exista uma

interseção de restrições);

10. Verificação se todos os conceitos a que as propriedades se relacionam são

equivalentes em ambas as ontologias comparadas;

11. Verificação se todos os conceitos que utilizam uma propriedade são

consistentes em ambas as ontologias comparadas.

A realização de cada identificação numerada acima refina a qualidade do

resultado obtido com o alinhamento, funcionando como um medidor de

inconsistência entre as ontologias pesquisadas. Uma vez identificadas as

inconsistências existentes, é preciso decidir qual ação será tomada. Como


apresentado em Nuseibeh et al. (2000), as três estratégias seguintes são possíveis:

ignorar, tolerar ou resolver.

Não é desejado que inconsistências sejam simplesmente ignoradas, pois é

preciso realizar o alinhamento de ontologias com confiabilidade mas, por outro

lado, não é desejado resolver todas as inconsistências existentes, pois isto

aumentaria a complexidade da solução e, conseqüentemente, seu tempo de

execução. Por estas razões, a existência de algumas inconsistências, de acordo

com um percentual pré-definido de aceitação, é tolerável.

Realizando uma série de experimentos para alinhamento e analisando seus

resultados obtidos, pode se chegar, empiricamente, a uma região com os valores

para um percentual de similaridade razoável. O percentual de similaridade

escolhido deve ser utilizado como medida de tolerância para as inconsistências

detectadas. Uma estratégia de escolha de onde o percentual de similaridade será

aplicado deve ser elaborada para definir quais serão as inconsistências toleradas.

A seguir, são apresentados os requisitos e os resultados considerados

satisfatórios para o alinhamento de ontologias no contexto da Web Semântica.

2.2.2. Requisitos

O processo de alinhamento de ontologias pode ser realizado de forma

automática, semi-automática, onde há a necessidade de intervenção humana em

algumas etapas para a tomada de decisão, ou até mesmo manual. Hoje, a Internet

possui mais de oito bilhões de páginas, segundo a ferramenta de busca Google5.

Supondo que na Web Semântica a maioria de suas páginas terá sua própria

ontologia, o alinhamento manual, ou até mesmo o semi-automático, passa a ser

tedioso, sujeito a erros e difícil na escala desta Web.

Na visão da Engenharia de Software, é desejável que o processo de

alinhamento seja automático e, se possível, rápido (executado em poucos

segundos) e confiável (mínima margem de erro nos alinhamentos realizados).

Desta forma, sistemas multi-agentes (OMG, 2000), por exemplo, têm alguns de

seus requisitos de interoperabilidade satisfeitos (Haendchen et al., 2003).

O alinhamento rápido se faz necessário pela própria natureza dinâmica da

Web. Entende-se que, ao ser disparado o pedido de alinhamento pelos agentes de

5 http://www.google.com


software, a resposta deve ser, se possível, imediatamente depois da execução do

alinhamento. Também, intervenções durante o processo de alinhamento não são

desejadas porque atrasariam este processo. Além do mais, acredita-se que usuários

e agentes de software são especialistas em aplicações Web e não,

necessariamente, no domínio onde estas estão inseridas. Desta forma não

interviriam com informações relevantes no processo decisivo de alinhamento.

O alinhamento total é desejado, porém, desnecessário. Prefere-se manter um

critério de alinhamento confiável, que pode resultar em alguns termos não

alinhados, mas que, por outro lado, apresente um baixo percentual de erro na

identificação dos termos comuns, com um tempo de execução razoável. Soluções

complexas para o alinhamento total, que requerem elevado tempo de execução,

não parecem ter sucesso neste contexto e, conseqüentemente, perdem sua

justificativa de uso.

Escolhas sobre os recursos a serem utilizados para o alinhamento são

decididas balanceando suas contribuições com seus impactos. Qualquer nova

escolha que faça com que um dos requisitos de alinhamento na visão da

Engenharia de Software não seja satisfeito é descartada.

2.2.3. Resultados Considerados Satisfatórios

O alinhamento automático, realizado em um tempo finito de execução, é

considerado como uma boa resposta, desde que se respeitando os limites pré-

definidos de confiabilidade. Neste caso, os resultados de alinhamentos realizados

não precisam ser armazenados, porque alinhamentos são realizados sempre que

necessários. Seus resultados podem ser descartáveis e, portanto, não persistentes.

Existe um custo associado caso as informações conseguidas com o

alinhamento sejam armazenadas. Este custo deve ser analisado balanceando a

razão de uso do armazenamento com seus possíveis resultados obtidos. Em Doan

et al. (2003), por exemplo, as informações obtidas com o mapeamento de

ontologias são armazenadas para que técnicas de aprendizado possam ser

aplicadas. Tais técnicas não devem resultar em melhorias para o processo de

alinhamento automático das ontologias de aplicações Web. Isto ocorre porque

neste processo o alinhamento das mesmas ontologias deve acontecer

ocasionalmente, impedindo que a informação seja “aprendida” e,


conseqüentemente, utilizada. Além do mais, a informação precisa ser interpretada

para ser “aprendida”. Esta necessidade não é nada trivial quando satisfeita de

forma automática.

2.3. Revisão da Literatura

A interoperabilidade de ontologias vem sendo estudada por diferentes

pesquisadores. Naturalmente, algumas abordagens distintas têm sido exploradas.

Existe, por exemplo, a abordagem de uso de ontologias preferenciais em que

seus termos são aceitos por uma determinada comunidade (domínio); uso de

dicionários, thesauri, léxicos para o casamento sintático; transformação; entre

outros.

Em Bouquet et al. (2003) é proposto um algoritmo para descoberta de

mapeamentos semânticos, cruzando classificações hierárquicas, baseado em uma

nova aproximação para a coordenação semântica, i.e., alinhamento. Esta

aproximação traz o problema de coordenação semântica do problema da

lingüística computacional ou similaridades estruturais para o problema de dedução

de relações entre conjuntos de fórmulas lógicas, que representam o significado

dos conceitos dos diferentes modelos. São combinadas as informações do nível do

conhecimento léxico (conhecimento sobre as palavras utilizadas), do nível do

conhecimento do domínio (conhecimento sobre as relações entre os sentidos das

palavras) e do nível do conhecimento estrutural (conhecimento vindo de como as

palavras estão organizadas na árvore de representação) para a construção de uma

nova representação do problema. Nesta, o significado de cada nó é codificado

como uma fórmula lógica e os conhecimentos relevantes do domínio e das

relações estruturais entre os nós são adicionados aos nós como conjuntos de

axiomas. Assim, o problema de descoberta da relação semântica entre estes nós

passa a ser traduzido não como um problema de mapeamento, mas sim como um

simples problema de dedução lógica.

Para o trabalho com múltiplas e extensas ontologias, é apresentado em Noy

e Musen (2003) o conjunto de ferramentas PROMPT. Dentre as ferramentas deste

conjunto, citamos: iPROMPT, uma ferramenta interativa para combinação de

ontologias; AnchorPROMPT, uma ferramenta automática baseada em grafos para

alinhamento de ontologias; PROMPTFactor, uma ferramenta para extração de


partes de ontologias e PROMPTDiff, uma ferramenta para identificação de

diferenças entre duas versões da mesma ontologia. O conjunto de ferramentas

PROMPT e como estas estão relacionadas são ilustrados na Figura 7.

Figura 7 – O conjunto de ferramentas PROMPT de (Noy e Musen, 2003)

A ferramenta iPROMPT é uma ferramenta semi-automática de combinação

de ontologias. Esta ferramenta guia o usuário, apresentando sugestões para os

termos das ontologias que devem ser combinados, e identifica inconsistências e

problemas potenciais, sugerindo estratégias para resolvê-los. Seu algoritmo faz

uso tanto da informação da estrutura dos conceitos na ontologia e relações entre

eles quanto da informação obtida do usuário. No entanto, as informações

analisadas entre os conceitos são limitadas ao contexto local, ou seja, apenas são

analisadas as informações das relações entre os conceitos ligados diretamente e

aqueles que são referenciados nas restrições destas relações.

A ferramenta Anchor_PROMPT é uma ferramenta para o alinhamento de

ontologias que encontra automaticamente termos semanticamente similares. Esta

ferramenta tem como entrada um conjunto de âncoras, i.e., pares de termos

relacionados, definidos pelo usuário ou por identificação automática de

combinação lexical, e trata uma ontologia como um grafo. Neste grafo, os

conceitos das ontologias são seus nós e suas relações são seus links, i.e., ligações.

Os caminhos do sub-grafo limitado pelas âncoras são analisados e são

determinados quais os conceitos que freqüentemente aparecem nas mesmas


posições dos caminhos similares. Com estas análises e determinações, além do

contexto local, o contexto não-local também é analisado. Além disto, utiliza na

detecção de termos similares, a relação estrutural dos termos de ontologias

comparadas, medidas de similaridades pré-definidas e grupos de equivalência.

A ferramenta PROMPTFactor é uma ferramenta para separação de sub-

ontologias, semanticamente independentes, de ontologias extensas. Esta

ferramenta é de grande auxílio para autores de ontologias que desejam criá-las

reutilizando partes de ontologias extensas já criadas. Isto porque, tal ferramenta

trata-se de uma possível solução para o problema de reutilização de termos de

ontologias extensas sem ter que importá-las em sua totalidade. É conhecido que,

ao importar uma ontologia, há a adição de todos os termos da ontologia importada

na que faz uso da importação. Para as ontologias que utilizam apenas um conjunto

de termos de ontologias importadas, o modelo fica desnecessariamente robusto

com o excesso de informação acrescido. Este problema é agravado quando a

ontologia importada é extensa.

A ferramenta PROMPTDiff é uma ferramenta para identificação

automática de diferenças entre duas versões da mesma ontologia. Nesta

ferramenta, a comparação não é feita apenas por comparação de textos, como

tradicionalmente é realizado em comparação de versões de programas, mas

também, por comparação estrutural. O PROMPTDiff compara as estruturas de

duas versões da mesma ontologia identificando as partes que não tiveram

alteração alguma, aquelas que tiveram alterações apenas em suas propriedades e

aquelas que tiveram alterações nos nomes e/ou estruturas tanto de seus conceitos

quanto de suas propriedades, entre outras partes.

O sistema GLUE (Doan et al., 2003) faz uso de estratégias de

aprendizagem múltiplas para encontrar os mapeamentos semânticos entre duas

ontologias. Neste sistema, dadas duas taxonomias e suas instâncias associadas,

para cada nó, i.e., conceito de uma taxonomia, o sistema encontra o nó mais

similar na outra taxonomia, dada uma medida de similaridade pré-definida. É

previsto no sistema a utilização da maioria das medidas práticas de similaridades

conhecidas. Trata-se de uma ferramenta de suporte automático que disponibiliza

seus resultados para uma outra ferramenta qualquer de interoperabilidade

semântica, não necessariamente automática, que fará uso destes resultados.


Contudo, existe uma redução significativa no esforço requerido pelo usuário que,

em alguns casos, é resumido à validação, eliminando a fase de construção.

Na comunidade de Banco de Dados, o problema de mapeamento dos

diferentes esquemas de bancos é antigo e possui soluções bem sucedidas, como o

uso de conversores, mediadores e técnicas de mapeamento. Além disso, soluções

específicas para ontologias já estão sendo dadas pela comunidade de banco de

dados. Em (Moreira, 2003), por exemplo, é proposta uma arquitetura geral para

integração semântica de sistemas de informação baseados na linguagem de

ontologia OWL, onde as formas de obtenção e extração de ontologias são

identificadas com ênfase em sistemas de banco de dados.

O serviço Articulation Service disponibilizado on-line em (Articulation

Service, 2004) realiza o mapeamento de duas ontologias. A primeira ontologia é

a chamada de ontologia de assunto e a segunda de ontologia objeto. O

mapeamento é realizado de forma assimétrica da ontologia de assunto para a

ontologia objeto.

A ferramenta de mapeamento de ontologias baseada em léxico

disponibilizada para download em (Teknowledge, 2004) é uma ferramenta

automática desenvolvida e acessada em SWI-Prolog (SWI-Prolog, 2004). Esta

ferramenta realiza tanto o mapeamento de uma única ontologia quanto o de duas

ontologias, este último de forma unidirecional e bidirecional.

O serviço OntoMerge - Ontology Translation by Merging Ontologies

disponibilizado on-line em (OntoMerge, 2004) realiza a combinação de

ontologias pela união de seus axiomas. É um serviço semi-automático que dá

suporte a humanos e a agentes de software na tarefa de encontrar diferenças de

notação entre duas ontologias de áreas de sobreposição.

Apesar dos trabalhos realizados para garantir mecanismos que suportem a

interoperabilidade de ontologias, não foi encontrada solução alguma para o

alinhamento de ontologias, prioridade deste trabalho, que esteja de acordo com os

requisitos da Web Semântica, apresentados no tópico 2.2.2.. No entanto, boas

idéias surgiram para elaborar uma estratégia que esteja em conformidade com tais

requisitos.

O Componente para Alinhamento Taxonômico de Ontologias – CATO,

resultado da implementação da estratégia elaborada, alinha automaticamente as

taxonomias das ontologias de entrada, além de ser rápido e confiável. O CATO é


automático porque não é permitida a intervenção do usuário para tomada de

decisão no alinhamento; Rápido porque prioriza o alinhamento de conceitos das

ontologias comparadas. Quando o alinhamento é disparado pelos pedidos de

agentes de software, espera-se alguma resposta em um tempo finito, se possível,

imediatamente depois de sua execução; Confiável porque o alinhamento é tratado

em etapas, onde cada etapa possui condições a serem satisfeitas que garantam um

baixo percentual de erros.

O CATO é uma aproximação de algumas soluções da Ciência da

Computação para comparação lexical e estrutural, e uso de medidas de

similaridades para os ajustes finos de seus resultados. Estas soluções, apresentadas

a seguir, são customizadas para o problema de alinhamento de ontologias.

3 A Estratégia

Apesar dos esforços descritos no capítulo anterior, alinhar os termos de

diferentes ontologias continua um problema em aberto e que precisa ser resolvido

para viabilizar uma série de promessas da Web Semântica. Por exemplo,

permanece a necessidade de como garantir a possibilidade de comunicação

automática entre os agentes de software de aplicações semânticas permitindo a

cooperação, i.e., compartilhamento e reutilização, das informações

disponibilizadas nestas aplicações semânticas.

Neste trabalho, uma estratégia para o alinhamento taxonômico de ontologias

é proposta. Como descrito em Doan (2003), o componente central em uma

ontologia é sua taxonomia. Desta maneira, em um primeiro momento, apenas os

conceitos com relacionamentos de especialização entre eles, i.e., relacionamentos

do tipo “é-um”, de duas ontologias6 de entrada são investigados. Nesta estratégia

proposta, ilustrada na Figura 8, o alinhamento é obtido em três etapas, executadas

seqüencialmente.

A primeira etapa da estratégia, explicada em detalhes no tópico 3.2. deste

trabalho, faz uso de comparação lexical entre os conceitos das ontologias de

entrada e mecanismo de poda estrutural dos conceitos associados como condição

de parada. Seus resultados são as ontologias entradas enriquecidas com os

alinhamentos conseguidos nesta etapa da estratégia. Estas ontologias são

transformadas em arquivos do tipo XML, onde apenas suas hierarquias são

representadas.

A segunda etapa da estratégia, explicada em detalhes no tópico 3.3. deste

trabalho, compara estruturalmente as hierarquias das ontologias resultantes da

primeira etapa da estratégia, identificando as similaridades entre suas sub-árvores

comuns. Os conceitos destas sub-árvores são classificados como similares.

6 A estratégia proposta tem como entradas pares de ontologias. Caso seja necessário o

alinhamento de mais de duas ontologias, este pode ser realizado em passos seqüenciais, sempre alinhando as ontologias duas a duas.

A Estratégia 34

A terceira etapa da estratégia, explicada em detalhes no tópico 3.4. deste

trabalho, refina os resultados da etapa anterior classificando aqueles conceitos

identificados como similares em bem similares ou pouco similares, de acordo

com um percentual de similaridade pré-fixado. Os resultados desta etapa são os

conceitos classificados como bem similares.

Primeira ontologia enriquecida escrita em OWL


Segunda ontologia enriquecida escrita em OWL


Conceitos classificados como similares

Primeira ontologia escrita em OWLPrimeira ontologia escrita em OWL Segunda ontologia escrita em OWLSegunda ontologia escrita em OWL

1 Etapa

2a Etapa

3a Etapa

Transformação de OWL para XML

Comparação Léxica(sem e com sinônimos) Poda Estrutural

Comparação Estrutural

Medidas de Similaridades


Primeira ontologia enriquecida escrita em OWL Segunda ontologia enriquecida

escrita em OWL




a

a

Comparação Léxica(sem e com sinônimos)



Segunda ontologia enriquecidaescrita em OWL

Primeira e Segunda ontologias alinhadas escritas em OWL

Primeira ontologia enriquecidaescrita em OWL

Conceitos classificados como bem similares

Primeira ontologia enriquecidaescrita em XML

Segunda ontologia enriquecidaescrita em XML







1 Etapa

2a Etapa

3a Etapa

Transformação de OWL para XML

Comparação Léxica(sem e com sinônimos) Poda Estrutural




Primeira ontologia enriquecida escrita em OWL Segunda ontologia enriquecida

escrita em OWL




a

a

Comparação Léxica(sem e com sinônimos)



Segunda ontologia enriquecidaescrita em OWLSegunda ontologia enriquecidaescrita em OWL

Primeira e Segunda ontologias alinhadas escritas em OWLPrimeira e Segunda ontologias alinhadas escritas em OWL

Primeira ontologia enriquecidaescrita em OWLPrimeira ontologia enriquecidaescrita em OWL

Conceitos classificados como bem similaresConceitos classificados como bem similares

Primeira ontologia enriquecidaescrita em XMLPrimeira ontologia enriquecidaescrita em XML

Segunda ontologia enriquecidaescrita em XMLSegunda ontologia enriquecidaescrita em XML

Figura 8 – Estratégia para o alinhamento taxonômico de ontologias

No final da execução das três etapas da estratégia, as informações de

equivalência de conceitos bem similares são adicionadas nas ontologias

resultantes da primeira etapa. Após esta adição, as ontologias alinhadas são unidas

em uma ontologia única. Esta ontologia única é o resultado final da estratégia.

O fato do resultado final da estratégia ser uma ontologia única foi uma

decisão de implementação. As ontologias alinhadas pela estratégia continuam

sendo reconhecidas pela identificação de seus namespaces e existe a ligação entre

os conceitos equivalentes na ontologia única, permitindo a reutilização e o

compartilhamento de suas informações comuns, características do mecanismo de

alinhamento de ontologias.

Para a estratégia elaborada ser confiável, deve-se minimizar a possibilidade

de erros nos alinhamentos realizados. Para isto, cada uma de suas etapas possui

condições que precisam ser satisfeitas para efetivarem os alinhamentos. Estas

condições precisam ser bem escolhidas para que não inviabilizem qualquer

A Estratégia 35

solução dada. Deve-se permitir, contudo, a possibilidade de refinamentos e

melhorias incrementais dos resultados encontrados.

Na estratégia proposta, as entradas de cada uma de suas etapas são os

produtos da etapa anterior com, possivelmente, as informações dos alinhamentos

realizados adicionadas. Desta maneira, o resultado é refinado a cada nova etapa.

Por exemplo, os conceitos não alinhados na comparação lexical da primeira etapa

da estratégia podem ser alinhados com a identificação de sub-árvores comuns na

comparação estrutural da segunda etapa e uso de medidas de similaridade da

terceira etapa.

Todos os conceitos das ontologias a serem alinhadas são comparados,

exceto os possíveis conceitos existentes originais de ontologias importadas. Estes

conceitos não são utilizados em nenhuma das etapas da estratégia porque foi

verificado que não trazem melhorias significativas que ajudem na decisão do

alinhamento. Além disto, tornam qualquer comparação bem mais lenta pela

quantidade de informação adicionada que precisa ser analisada.

Quando uma ontologia importa outras ontologias, todos os termos

importados são adicionados nela. No entanto, os termos importados são

diferenciados dos termos da ontologia que os importa pelo seu namespace. O

namespace de um termo indica a localização de sua ontologia original, i.e., onde

este termo foi criado. A análise do namespace de um termo revela se este termo é

importado ou não. Termos importados em uma ontologia possuem seu namespace

diferente do namespace da ontologia onde se encontram importados.

3.1. Um Exemplo Simplificado

Para exemplificar o alinhamento realizado pela estratégia descrita, duas

ontologias simplificadas, ilustradas na Figura 9, foram criadas. A primeira

ontologia, O17, encontra-se no lado esquerdo da figura e refere-se a uma

simplificação de uma ontologia exemplo do Departamento de Informática da

Pontifícia Universidade Católica do Rio de Janeiro – PUC-RIO. A segunda

7 A abreviação O1 é utilizada ao longo do texto para facilitar a referência à primeira

ontologia descrita.

A Estratégia 36

ontologia, O28, encontra-se no lado direito da mesma figura e refere-se a uma

ontologia de publicação.

Ontologia de Publicações (O2)

Ontologia do depto. de Info. da PUC-RIO (O1)

Ontologia de Publicações (O2)

Ontologia do depto. de Info. da PUC-RIO (O1)

Figura 9 – Exemplo de ontologias a serem alinhadas

Deseja-se alinhar os conceitos equivalentes das duas ontologias criadas, ou

seja, que após a execução da estratégia de alinhamento, os seguintes conceitos

equivalentes sejam identificados: “Publicação”, “Artigo”, “Artigo_em_Anais” e

“Artigo_em_Periodicos”, de ambas as ontologias, “Dissertacao_de_Mestrado” de

O1 e “Dissertacao” de O2, “Tese_de_Doutorado” de O1 e “Tese” de O2, entre

outros.

Ao fornecer os conceitos equivalentes das ontologias alinhadas, é

disponibilizado para os agentes de software de aplicações semânticas um

indicativo do caminho para a recuperação das instâncias desses conceitos.

8 A abreviação O2 é utilizada ao longo do texto para facilitar a referência à segunda

ontologia descrita.

A Estratégia 37

3.2. Primeira Etapa: Comparação Lexical com Uso de Sinônimos e Mecanismo de Poda Estrutural como Condição de Parada

A etapa inicial da estratégia tem como suas entradas duas ontologias a serem

alinhadas. Estas ontologias são transformadas9 em modelos de forma que seus

termos sejam manipulados como objetos.

O objetivo desta etapa é realizar a comparação lexical dos conceitos de

ontologias de forma “mais inteligente”, com o enriquecimento de informações, a

procura de conceitos iguais lexicalmente e com o mesmo significado, i.e.,

conceitos equivalentes.

Quanto mais informações apuradas (e.g. sinônimos, gêneros, números, etc.)

estiverem disponíveis para a comparação lexical, mais precisa é a identificação de

equivalência entre conceitos. Adições de informações dos conceitos analisados

como seus sinônimos, gêneros, concordâncias nominais e verbais,

relacionamentos, entre outras, são valiosas.

Para enriquecer os conceitos de ontologias é preciso que exista algum

mecanismo de extração de informações de fonte de dados, como dicionários e

thesauri. Esta necessidade torna-se um desafio quando realizada de forma

automática. Isto porque a maioria das fontes de dados não disponibilizam meios

para acesso automático às suas informações e a identificação do significado de um

conceito não é uma tarefa trivial, quando realizada sem a intervenção humana.

Um banco de sinônimos com acesso automático disponibilizado foi criado.

Nele, novos sinônimos são adicionados, manualmente e sistematicamente, ao

longo de seu uso, de forma a diluir seu custo de construção. A Figura 10 ilustra o

banco de sinônimos utilizado com algumas informações cadastradas.

Banco de SinônimosBanco de Sinônimos

Figura 10 – Informações cadastradas no banco de sinônimos criado

9 A transformação de ontologias em modelos orientados a objetos é descrita no tópico 3.5.2.

deste trabalho.

A Estratégia 38

Em um primeiro momento, há apenas o enriquecimento dos conceitos das

ontologias comparadas com as informações de seus sinônimos. Além disso, a

qualidade deste enriquecimento é diretamente proporcional à qualidade do banco

de sinônimos criado. Quanto mais conceitos conhecidos com seus respectivos

sinônimos existirem cadastrados nele, maiores são as chances do enriquecimento

de informações entre conceitos e, conseqüentemente, dos alinhamentos.

Na comparação lexical, cada conceito da primeira ontologia é comparado,

um a um, com cada conceito da segunda ontologia à procura da igualdade de seus

nomes. Também, todos os sinônimos identificados dos conceitos de um modelo

são comparados com todos os conceitos do outro modelo.

Encontrada a igualdade lexical entre dois conceitos ou entre um conceito e

seu sinônimo nas ontologias comparadas, é preciso também comparar suas sub-

árvores como indicativo semântico. Adota-se como critério de investigação a

seguinte poda da árvore dos conceitos analisados:

• Generalização: poda até o conceito avô, i.e., conceitos com nomes iguais

em seus dois níveis hierárquicos acima;

• Especialização: poda até as instâncias, i.e., instâncias com nomes iguais.

Apesar de uma instância ser identificada pelo par nome e namespace da

ontologia a que pertence, a condição de poda de especialização só utiliza a

igualdade de nomes. Isto porque, como as instâncias comparadas são de

ontologias diferentes, então, estas instâncias possuem namespaces são diferentes.

Vale ressaltar que apenas as instâncias dos conceitos equivalentes,

lexicalmente identificados, são investigadas para responderem à condição de poda

de especialização. Estas instâncias devem estar cadastradas nas ontologias. Caso

não estejam, não são investigadas.

Quando as instâncias não são armazenadas na própria ontologia, estas

podem estar armazenadas em arquivos, em banco de dados, ou em outras

estruturas de dados. A escolha do tipo de armazenamento de dados utilizado faz

parte do projeto de uma aplicação e, como cada aplicação tem um propósito

diferente, não dá para deduzir o tipo escolhido.

A busca pelas instâncias e seus alinhamentos aumentariam, razoavelmente,

a complexidade de qualquer estratégia e, conseqüentemente, seu tempo de

execução. Na estratégia elaborada, é realizado apenas o alinhamento das

instâncias dos conceitos equivalentes identificados nas ontologias comparadas.

A Estratégia 39

Conceitos equivalentes, identificados pela comparação lexical, que

satisfazem tanto a condição de poda de generalização quanto a de especialização,

são alinhados já na primeira etapa da estratégia. Os resultados desta etapa da

estratégia de alinhamento são os modelos das duas ontologias entradas com as

ligações estabelecidas entre seus conceitos equivalentes.

Para adicionar ligações entre os conceitos equivalentes identificados em

ontologias comparadas, deve-se incluir as informações de equivalência em ambos

os modelos dessas ontologias. No entanto, não se pode alterar os modelos dessas

ontologias quando estes estão sendo analisados e percorridos. Isto porque,

iterações são realizadas nesses modelos e novas inclusões nestes, fazem com que

as iterações em execução percam suas numerações e seus limites corretos. A

solução para este problema é trabalhar com uma estrutura de dados auxiliar para

armazenar as equivalências identificadas dos conceitos e no final das iterações no

modelo da ontologia analisada, adicionar as equivalências neste modelo.

3.2.1. Revendo o Exemplo

Para exemplificar a primeira etapa da estratégia, o exemplo descrito no

tópico 3.1. é revisto.

Ao executar a primeira etapa da estratégia, todos os sinônimos dos conceitos

das duas ontologias de entrada cadastrados no banco de sinônimos são

identificados. A Figura 11 ilustra estas identificações. O namespace da ontologia

O1 é “file:firstOnto.owl” e o da O2 é “file:secondOnto.owl”. As informações

depois da string “#” referem-se aos nomes dos conceitos e seus sinônimos

identificados estão entre colchetes. Por exemplo, a informação que o conceito

“Aluno” da segunda ontologia (“file:secondOnto.owl#Aluno”) possui o termo

“Estudante” como sinônimo é identificada.

Figura 11 – Sinônimos identificados dos conceitos das ontologias analisadas

Apesar de a sinonímia ser uma relação reflexiva, a relação entre suas

informações cadastradas no banco de sinônimos criado não é reflexiva, ou seja, se

lá existe a informação cadastrada que o conceito “Aluno” é sinônimo do conceito

A Estratégia 40

“Estudante”, por exemplo, isto não significa, necessariamente, que o conceito

“Estudante” é sinônimo do conceito “Aluno”. Nenhum sinônimo é deduzido

automaticamente. Todos os conceitos e seus respectivos sinônimos precisam estar

cadastrados no banco de sinônimos como entradas únicas para poderem ser

utilizados.

A Figura 12 ilustra as informações identificadas na primeira etapa da

estratégia para o exemplo escolhido. Os conceitos “Artigo_em_Anais”, de ambas

ontologias, são alinhados pela igualdade lexical e porque satisfazem as condições

de poda desta etapa da estratégia. No entanto, os conceitos “Estudante” de O1 e

“Aluno” de O2 não são alinhados porque apesar do sinônimo “Estudante” do

conceito “Aluno” ser identificado, aqueles conceitos não satisfazem à condição de

poda porque possuem conceitos pais, i.e., um nível hierárquico acima, diferentes.

Informação

Informação

Informação

Informação

InformaçãoIdentificada

Informação Informação Identificada

Satisfazem a condição de poda:

Não satisfazem a condição de poda:

Informação

Informação

Informação

Informação





Informação

Informação

Informação

Informação





Figura 12 – Informações identificadas na primeira etapa da estratégia

Quando dois conceitos são alinhados, as equivalências são adicionadas nas

duas ontologias comparadas. Por exemplo, a informação que o conceito alinhado

“Artigo_em_Anais” da primeira ontologia é equivalente ao conceito

“Artigo_em_Anais” da segunda ontologia é adicionada em ambas as ontologias.

3.3. Segunda Etapa: Comparação Estrutural Usando uma Implementação do Algoritmo TreeDiff

O segundo passo da estratégia compara as estruturas hierárquicas de

ontologias com o objetivo de identificar suas sub-árvores comuns. Esta

comparação é baseada nos relacionamentos de especialização, i.e.,

relacionamentos do tipo “é-um”, entre os conceitos de uma ontologia. Outros

A Estratégia 41

termos das ontologias, como as propriedades e axiomas, não são comparados

atualmente pela estratégia.

Para comparação de árvores, existem algoritmos de busca de similaridades

estruturais, tais como: TreeDiff (Wang, 1998), TreeToTree (Tai, 1979),

TreeMatcher (TreeMatcher, 2004), entre outros.

O algoritmo do TreeDiff (Wang, 1998) descrito em (Bergmann, 2002) é o

escolhido por satisfazer os requisitos para a busca de similaridades estruturais e

possuir sua implementação disponibilizada.

O objetivo do TreeDiff é encontrar a maior subestrutura comum entre duas

árvores descritas de acordo com o modelo Document Object Model – DOM –

(DOM, 2004). A ordem dos filhos de cada nó é levada em consideração. A

aplicação do algoritmo resulta em um conjunto de operações de edição, como

renomear, remover ou inserir um nó, que deve ser aplicado na primeira árvore de

maneira a obter-se a segunda árvore. Cada operação possui um custo associado e

o cômputo da subestrutura comum é realizado procurando-se minimizar o custo de

edição. A aplicação deste algoritmo pode ser utilizada para identificar tanto as

similaridades quanto as diferenças entre as árvores comparadas.

No contexto do alinhamento de ontologias deste trabalho, apenas as

informações resultantes de similaridades identificadas são utilizadas. As

informações das diferenças entre as árvores são descartadas.

Com poucas modificações na implementação disponibilizada do algoritmo

do TreeDiff em (Bergmann, 2002), é possível fazer com que todas as operações de

edição sejam de renomeação e não mais de inserção, exclusão e renomeação como

era originalmente. Estas modificações são necessárias porque uma ontologia não é

a evolução da outra na comparação entre ontologias complementares, mas

possuem termos comuns que precisam ser identificados e alinhados.

A disponibilidade da implementação dada em (Bergmann, 2002) tornou-se

um importante recurso, porém, foi necessária a customização desta solução para o

problema de alinhamento a ser tratado por ela. Para uso da implementação com

ontologias, uma customização seria ter seus arquivos de entrada escritos nas

linguagens para ontologias, como DAML+Oil (Connolly et al., 2001) ou OWL, e

não mais em XML como era originalmente.

No entanto, o parser, i.e., interpretador, DOM que utiliza a visão de árvore a

partir do modelo DOM de um documento, é implementado apenas para

A Estratégia 42

documentos do tipo XML. Um parser DOM para documentos escritos nas

linguagens de ontologias não foi encontrado e nem existe como padrão da W3C

(DOM, 2004).

Como para a comparação entre árvores é preciso apenas a representação das

estruturas taxonômicas de ontologias, a transformação da linguagem de ontologias

para XML, respeitando as hierarquias das ontologias comparadas, é aceitável. Isto

porque é possível representar em XML a hierarquia dos conceitos de uma

ontologia, sem perder qualquer informação.

A Figura 13 ilustra como o TreeDiff realiza o cômputo das diferenças e

similaridades entre dois arquivos XML. Inicialmente estes arquivos são lidos e

transformados nas duas árvores correspondentes, DOMTree 1 e DOMTree 2 pelo

parser DOM. Sobre estas árvores é aplicado o algoritmo TreeDiff, obtendo-se

como resultado o conjunto das operações a serem aplicadas na primeira árvore de

forma a obter a segunda. Por fim, o conjunto de diferenças é processado de

maneira a gerar uma lista de diferenças e um conjunto de fatos observados sobre

as duas versões. Este conjunto de fatos é utilizado em (Bergmann, 2002) na

procura de qual plano caracteriza as ações realizadas pelo desenvolvedor.

Figura 13 – Uso do algoritmo do TreeDiff de (Bergmann, 2002)

A Figura 14 ilustra a transformação da estrutura de ontologias para a

estrutura em XML. Tais estruturas são bem semelhantes salvo o fato de na última

existirem as tags (rótulos escondidos com anotações) específicas de Classes

(<Classe> nomeDaClasse </Classe>) e Subclasses (<subClasse>

nomeDaSubClasse </subClasse>).

A Estratégia 43

Figura 14 – Transformação da estrutura de ontologias para a estrutura em XML

3.3.1. Informações de equivalência

A comparação estrutural da segunda etapa da estratégia utiliza apenas a

igualdade de nomes. As equivalências lexicais dos sinônimos, identificadas na

primeira etapa da estratégia, não são interpretadas por esta comparação.

Para que os sinônimos identificados como equivalentes aos conceitos sejam

utilizados na comparação estrutural, é preciso antes da transformação das

ontologias em estruturas hierárquicas, escolher entre o nome do conceito ou o de

seu sinônimo identificado a ser utilizado.

A informação de equivalência entre o conceito e seu sinônimo pode ser

encontrada nas duas ontologias ou em apenas uma delas. Por exemplo, pode-se ter

tanto a informação que o conceito “Aluno” da ontologia O2 é equivalente ao

conceito “Estudante” da ontologia O1 e o conceito “Estudante” de O1 é

equivalente ao conceito “Aluno” de O2, quanto apenas a informação que o

conceito “Aluno” de O2 é equivalente ao conceito “Estudante” de O1.

Se a informação de equivalência existir nas duas ontologias analisadas,

escolhe-se o nome do conceito ou o de seu sinônimo a ser utilizado na

comparação estrutural. No primeiro caso do exemplo acima, tanto o nome do

conceito “Aluno” quanto o do conceito “Estudante” podem ser escolhidos.

Caso a informação de equivalência só exista em uma ontologia, então, o

nome do conceito que possui a informação de equivalência é substituído. No

A Estratégia 44

segundo caso do exemplo acima, o nome do conceito “Aluno” de O2 é substituído

pelo nome do conceito “Estudante” de O1.

No entanto, existe a possibilidade de existência de inconsistências nas

substituições de nomes por seus sinônimos. Isto porque, o sinônimo de um

conceito de uma ontologia pode estar sendo utilizado como o nome de um

conceito da outra ontologia comparada e, talvez, com um significado diferente.

Caso isto ocorra, a substituição não será realizada pela estratégia para evitar a

existência da inconsistência detectada e a equivalência lexical identificada do

nome e de seu sinônimo não será utilizada na comparação estrutural.

3.3.2. Grupos de Equivalência

Como em (Noy e Musen, 2001a), a utilização de grupos de equivalência de

conceitos também é utilizada na comparação estrutural implementada. Nesta

implementação, os grupos de equivalência são identificados tanto pela

comparação lexical quanto pela comparação estrutural. Primeiro, os conceitos

comparados com o mesmo nome são identificados pela comparação lexical e, em

seguida, as informações da quantidade de filhos (sub-conceitos) e os conceitos

equivalentes que estes filhos possuem são analisadas pela comparação estrutural.

Foi verificado na implementação da estratégia que, quando há pouca

similaridade estrutural entre as árvores dos conceitos comparados, a organização

estrutural dos filhos destes conceitos também influencia na identificação dos

grupos de equivalência.

Para investigar a influência da organização dos conceitos nas árvores

comparadas, dois módulos de geração de arquivos para a comparação estrutural

foram implementados. São eles: um módulo que fornece os conceitos das

ontologias estruturados com sua ordem original de criação e um módulo que

fornece os conceitos ordenados alfabeticamente. As Figura 15 e Figura 16

ilustram os dois respectivos módulos, com os grupos de equivalência identificados

pelos círculos em cada um deles. Estes grupos de equivalência são identificados

nas ontologias O1 e O2, que foram apresentadas no tópico 3.1. deste trabalho.

A Estratégia 45

O1 O2

Figura 15 – Grupos de equivalência identificados no módulo sem ordenação alfabética

O1

O2

O1

O2

Figura 16 – Grupos de equivalência identificados no módulo com ordenação alfabética


Na Figura 15, pela comparação lexical, os conceitos “Publicacao”, de ambas

as ontologias, são identificados como similares nas duas árvores analisadas.

Depois, pela comparação estrutural, seus conceitos filhos são investigados. Como

estes três primeiros conceitos, em ambas as ontologias, não possuem filhos então,

são identificados como similares e os primeiros grupos de equivalência,

identificados pelos círculos superiores da Figura 15, são definidos. Em seguida,

novamente pela igualdade estrutural, tanto os conceitos filhos “Pos_Graduacao”

em O1 e “Artigo” em O2 quanto suas sub-árvores são igualados em novos grupos

de equivalência, identificados pelos círculos inferiores da Figura 15.

Na Figura 16, também pela comparação lexical, os conceitos “Publicacao”,

de ambas as ontologias, são identificados como similares nas duas árvores

analisadas. Depois, pela comparação estrutural, seus conceitos filhos são

investigados. Como estes são idênticos lexicalmente e, pela ordenação alfabética

estão no mesmo nível hierárquico, em ambas as ontologias, então, são

A Estratégia 46

identificados como similares e os primeiros grupos de equivalência, identificados

pelos círculos superiores da Figura 16, são definidos. Como as informações dos

sinônimos identificados não são utilizadas porque estes não satisfazem as

condições de poda da primeira etapa da estratégia, então, os novos grupos de

equivalência, identificados pelos círculos inferiores da Figura 16, são definidos

levando-se em consideração apenas as subestruturas hierárquicas dos conceitos

comparados.

Percebe-se que para as ontologias comparadas com os conceitos

equivalentes descritos com o mesmo nome, a ordenação alfabética traz uma

melhoria sensível. Isto porque, após esta ordenação, os conceitos de mesmo nome

comparados nos grupos de equivalência estarão próximos estruturalmente. No

entanto, para os conceitos equivalentes que usam nomes diferentes ou sinônimos,

a ordenação alfabética não traz melhorias e, em alguns casos, pode piorar a

solução quando esta distancia estruturalmente os conceitos equivalentes.

O uso do algoritmo do TreeDiff fornece as equivalências que não foram

descobertas com a comparação lexical da primeira etapa da estratégia porque,

possivelmente, os conceitos ali identificados não satisfizeram as condições de

poda. No entanto, é na terceira etapa da estratégia, descrita no próximo tópico, que

os conceitos identificados como similares, pela comparação estrutural, são

classificados como bem similares ou pouco similares. Esta classificação é

realizada de acordo com um percentual de similaridade pré-definido. Apenas os

conceitos bem similares são alinhados no final da estratégia.

Desta maneira, os conceitos “Pos_Graduacao” em O1 e “Artigo” em O2,

identificados como similares pela comparação estrutural do módulo sem

ordenação alfabética, não serão alinhados no final da estratégia porque serão

classificados como pouco similares pelo uso de medidas de similaridades.

3.4. Terceira Etapa: Uso de Medidas de Similaridades para os Ajustes Finos

A terceira, e última, etapa da estratégia corresponde ao uso de medidas de

similaridade para os ajustes finos dos resultados conseguidos na etapa anterior.

Tais medidas classificam termos como bem similares ou pouco similares. A

classificação é realizada baseada em um percentual de similaridade previamente

escolhido. Apenas os conceitos similares da segunda etapa da estratégia e

A Estratégia 47

classificados como bem similares, nesta etapa, são alinhados no final da

estratégia.

Existe na literatura uma rica bibliografia sobre similaridades e

relacionamentos semânticos entre os termos, como: Conceptual Relations from

Text (Maedche, 2000), Knowledge maintenance (Resnik, 1995), Semantic

Similarity between Words (Richardson, 1994), entre outros.

Em Richardson et al. (1994), por exemplo, é utilizada a combinação da

distância conceitual dos termos e a informação de aproximação baseada na

estimativa de similaridade semântica. Lá, chegou-se a seguinte expressão para

similaridade entre conceitos:

onde {Ci} é o conjunto de conceitos entre

C1 e C2, P(Ci) é a probabilidade do conceito Ci e log 1/P(Ci) é o índice da

informação do conceito Ci.

Para exemplificar esta medida de similaridade, a Figura 17 ilustra alguns de

seus valores calculados. Com o uso da expressão de similaridade é descoberto, por

exemplo, que os conceitos “carro” (car, em inglês) e “garfo” (fork, em inglês) são

mais similares que os conceitos “carro” e “banana” (banana, em inglês). Isto

porque “carro” e “garfo” são sub-conceitos de artefato (artifact, em inglês), e o

conceito “banana” é apenas subconceito de um conceito mais geral chamado

“objeto” (object, em inglês). Os conceitos “carro” e “garfo” são 1.338 similares,

enquanto “carro” e “banana” são 0.763 similares. A maior similaridade entre

conceitos é traduzida em um valor calculado mais alto.

Figura 17 – Valores calculados de similaridade entre os termos

Apesar do material levantado com a pesquisa bibliográfica realizada sobre

medidas de similaridade, a implementação de tais medidas escolhida também foi a

utilizada em (Bergmann, 2002). Esta implementação é escolhida porque fornece

os resultados esperados para a tomada de decisão do alinhamento e leva em conta

tanto a estrutura hierárquica dos nós das árvores comparadas, distanciamento dos

conceitos comparados às raízes de suas árvores, quanto a quantidade de nós filhos,

A Estratégia 48

i.e., sub-conceitos, similares. Ou seja, implementa o uso de medidas de

similaridade aplicadas nos grupos de equivalência identificados na etapa de

comparação estrutural da estratégia elaborada. Tais preocupações são indicativos

essenciais para o alinhamento de ontologias e, conseqüentemente, foram decisivas

para a escolha das medidas de similaridade implementadas em (Bergmann, 2002).

Para a definição do percentual de similaridade, o mais razoável possível, é

preciso realizar alguns experimentos. Nestes, as medidas de similaridade são

aplicadas no problema com ontologias e, posteriormente, são refinadas.

Atualmente, o percentual de similaridade escolhido é igual a setenta e cinco

por cento (75%). Este valor foi obtido empiricamente, através da análise e

refinamento de resultados obtidos em experimentos prévios de alinhamento de

ontologias. Conceitos com percentual de similaridade igual ou maior que 75% são

classificados como bem similares e conceitos com percentual de similaridade

menor que 75% são classificados como pouco similares.

Apenas os conceitos bem similares são alinhados no final da estratégia. As

novas informações de equivalência são adicionadas nos modelos das ontologias

resultantes da primeira etapa da estratégia. Estes modelos com as novas

informações são persistidos em uma ontologia única formada pelas ontologias

originais, agora, alinhadas.


Para exemplificar a terceira etapa da estratégia, o exemplo descrito no

tópico 3.1. é revisto.

Os conceitos nomeados “Artigo”, em as ambas as ontologias comparadas,

não foram alinhados na primeira etapa porque não satisfizeram à condição de

poda de generalização, i.e., não há as informações dos conceitos avôs (dois níveis

hierárquicos acima) cadastrados, em ambas as ontologias, para a verificação da

condição de poda. No entanto, estes conceitos são identificados como similares

pela comparação estrutural, porque possuem igualdade lexical entre eles e

igualdade estrutural de seus sub-conceitos, e são identificados como bem similares

pelo uso de medidas de similaridades. Por estas razões, são alinhados no final da

estratégia.

A Estratégia 49

A Figura 18 ilustra as informações identificadas na terceira etapa para o

exemplo escolhido.

Informação

Informação


Informação InformaçãoIdentificada

Informação

Informação


Informação InformaçãoIdentificada

Figura 18 – Informações identificadas na terceira etapa da estratégia

3.5. A Implementação

A estratégia elaborada para o alinhamento taxonômico de ontologias foi

implementada em (Felicíssimo, 2003b). A linguagem de programação orientada a

objetos Java (Java, 2000) é utilizada em toda esta implementação por possuir

finalidades gerais e boas características que foram decisivas para sua escolha.

Algumas de tais características são descritas no próximo tópico. A API –

Application Programming Interface – específica para manipulação de ontologias,

a API Jena, a linguagem de ontologias OWL e o resultado da implementação

realizada são apresentados nos tópicos seguintes.

3.5.1. Características da linguagem Java

Um programa escrito em Java é multi-plataforma, portável e escalável.

Multi-plataforma e portável porque é compilado para um único bytecode Java,

independente do sistema operacional onde é executado. O bytecode Java, como

explicado em (Sikora, 2003), é um código intermediário entre o código-fonte do

programa Java e o código de máquina necessário para sua compilação. Este

bytecode pode ser executado por qualquer interpretador Java, sendo este

específico de sistema operacional, que esteja de acordo com as especificações da

Máquina Virtual Java (Java, 1999). Escalável, quando executado em um servidor

Web, porque Java é uma linguagem multithread.

Uma grande quantidade de bibliotecas programadas para a linguagem Java é

disponibilizada na Web. Por esta razão, o reuso de códigos já implementados é

facilitado, o que minimiza o tempo de programação nesta linguagem.

Java pode ser estendida com adições de novas APIs em sua hierarquia. Isto

possibilita a utilização de APIs específicas para as soluções programadas nesta

linguagem. Por exemplo, a API Jena (Jena, 2004b) específica para o tratamento de

A Estratégia 50

ontologias, descrita a seguir, é utilizada na implementação realizada para a

estratégia elaborada de alinhamento.

3.5.2. A API Jena

Jena é um framework em Java para construção de aplicativos para a Web

Semântica que provê um ambiente de programação para as linguagens de

ontologias RDF (Miller, 2004), RDF Schema – RDF Vocabulary Description

Language – (Brickley, 2004) e OWL (Dean et al., 2004a), incluindo um

mecanismo ou motor de inferências baseado em regras (Jena, 2004a). Trata-se de

um projeto iniciado nos laboratórios de pesquisa para a Web Semântica da

empresa HP (HP, 2004), mas que hoje é parte integrante dos projetos da

comunidade de software livre (Open Source, 2004).

Jena possui uma API específica para o tratamento de ontologias (Jena,

2004b). Esta API transforma uma dada ontologia em um modelo abstrato de dados

orientado a objetos e, com isto, seus termos passam a ser manipulados como

objetos. Este modelo é baseado na linguagem em que a ontologia é escrita. Por

exemplo, existem modelos específicos para OWL, DAML+OIL – Darpa Agent

Markup Language + Ontology Inference Layer – (Connolly et al., 2001), RDF,

entre outros. Isto porque, a API em questão recupera as informações das tags das

ontologias, que são específicas para cada uma das linguagens de ontologias.

Nenhuma informação é deduzida, porque a API não é um mecanismo de

inferência.

A grande vantagem em transformar ontologias em modelos orientados a

objetos é que, com esta transformação, os termos de ontologias são tratados como

objetos e a programação orientada a objetos pode ser utilizada. Desta maneira, as

manipulações nestes modelos tornam-se transparentes e comuns para os

programadores Java, por exemplo.

3.5.3. A linguagem OWL

O grupo de trabalho de Ontologias no contexto da W3C

(W3CSemanticWeb, 2004) vem desenvolvendo e evoluindo uma série de

linguagens para ontologias tendo como padrão, atualmente, a linguagem OWL

(Dean et al., 2004a). Esta linguagem é influenciada por formalismos

A Estratégia 51

estabelecidos, por paradigmas de representação do conhecimento e pela existência

de outras linguagens para ontologias e para a Web Semântica (Horrocks et al.,

2003). Satisfaz, sobretudo, seus requisitos definidos em (Dean, 2004b).

A linguagem OWL é uma nova linguagem para ontologias. Porém, esta

linguagem respeita a arquitetura da Web Semântica, ilustrada na Figura 1 deste

trabalho, evoluindo suas linguagens bases: XML (XML, 2004), RDF e RDF

Schema, além de ser uma revisão da linguagem DAML+OIL, com suas lições

aprendidas de projeto e aplicação.

A sintaxe da linguagem OWL é fornecida pelo XML, com o esquema de

tags, i.e., rótulos escondidos com anotações; o framework para a representação de

informação na Web através da modelagem de seus meta-dados10 e das relações

entre eles é fornecido pelo RDF; o vocabulário para descrição dos conceitos e

relações dos recursos, com semântica para as hierarquias de especialização das

relações e dos conceitos, é fornecido pelo RDF Schema.

A linguagem OWL é mais sofisticada que suas linguagens bases porque, por

exemplo, seus conceitos podem ser especificados por combinações lógicas como

interseção, união, ou complementos de outros conceitos, ou por enumerações de

objetos especiais. OWL pode indicar que uma propriedade é transitiva, simétrica,

funcional ou inversa, em relação a uma outra propriedade, quais indivíduos, i.e.,

instâncias, pertencem à quais conceitos, que conceitos e propriedades podem usar

indicações de equivalência e disjunção, que indicações de igualdade e diferença

podem ser utilizadas entre indivíduos, entre outras informações fundamentais para

fornecer o suporte semântico necessário para os primeiros passos da Web

Semântica.

3.5.4. O CATO

O Componente para Alinhamento Taxonômico de Ontologias (CATO) é o

resultado da implementação realizada em (Felicíssimo, 2003b) da estratégia

elaborada para o alinhamento automático de ontologias.

10 Os meta-dados expressam informações sobre os dados que representam. Por exemplo,

assunto, autores, editora e data de publicação são informações adicionais ou os meta-dados de um livro. Essas informações podem ser utilizadas, por exemplo, na procura de livros em uma biblioteca.

A Estratégia 52

Este componente pode ser utilizado em aplicações que precisam que suas

informações compartilhadas sejam interpretadas automaticamente como, por

exemplo, no framework proposto em (Haendchen et al., 2003). Neste framework,

o alinhamento permitiria uma representação comum das informações dos serviços

de agentes de software, o que facilitaria a interpretação automática dessas

informações por estes dispositivos de software.

O CATO recebe duas ontologias como suas entradas. Estas ontologias

devem estar descritas na linguagem padrão atual para ontologias adotada pela

W3C, a linguagem OWL (Dean et al., 2004a), e construídas de acordo com as

regras de construção desta linguagem (Smith et al., 2004).

Devido a uma decisão de implementação, a saída do CATO é uma ontologia

única, também escrita em OWL, constituída por todos os termos originais das duas

ontologias entradas mais as informações das equivalências identificadas com o

alinhamento adicionadas. Os termos nesta ontologia final continuam com seu

namespace original, o que facilita a identificação de suas origens e,

conseqüentemente, sua rastreabilidade.

O fato do resultado do CATO ser uma ontologia única foi exclusivamente

devido a uma decisão de implementação. No entanto, as ontologias originais são

reconhecidas pela identificação de seus namespaces e existe a ligação entre os

conceitos equivalentes nesta ontologia única, permitindo a reutilização e o

compartilhamento de suas informações. Por estas razões, o mecanismo de

alinhamento continua sendo caracterizado.

A implementação do CATO é modular. Alguns de seus módulos principais

com seus métodos são representados pelas classes ilustradas na Figura 19. A

descrição, os parâmetros de entrada e os valores retornados dos métodos destes

módulos são descritos no Anexo D deste documento. Os códigos-fonte da

implementação do CATO estão disponíveis no Anexo E.

O componente ilustrado nomeado “CATO.bat” é o responsável pelo disparo

da execução dos três módulos principais referentes às três etapas da estratégia

implementadas pelo CATO.

A classe ilustrada nomeada “SolCombSinonimos” é a responsável pelo

primeiro módulo de execução do CATO. Esta classe recebe como entradas as duas

ontologias a serem alinhadas e tem como saídas estas ontologias enriquecidas com

os alinhamentos realizados. Realizados os possíveis alinhamentos, as hierarquias

A Estratégia 53

das ontologias resultantes são representadas por essa classe em arquivos do tipo

XML.

Figura 19 – Classes dos módulos principais do CATO, com seus métodos

A classe “SolCombSinonimos” possui alguns métodos. O nomeado

“leOnto” lê uma ontologia e a transforma em um modelo orientado a objetos. O

nomeado “comparacaoSintaticaEUsoDeSinonimos” realiza a comparação lexical

de cada conceito do primeiro modelo com os conceitos do segundo modelo. Os

sinônimos são investigados pela ligação desta classe com a classe nomeada

“BDQuery”, que estabelece a conexão com o banco de dados utilizado. O método

“equivalentClassInformation” fornece as informações do alinhamento desta etapa

para que o nomeado “LastUpdateEquivalentClass” persista estas informações nos

modelos originais das ontologias. Os métodos “buildTagsXML” e

“buildSubClassTags” são os responsáveis pela representação das hierarquias das

ontologias em arquivos XML.

O método “buildTagsXML” é o único método que difere nas duas versões

implementadas do CATO, sem e com ordenação alfabética, devido a função de

ordenação chamada sort da linguagem Java.

Antes da síntese das ontologias em suas hierarquias, o método nomeado

“hashTableForSuperClassInformationEquivalentClassReplaced” substitui o

conceito ou o sinônimo identificado como equivalente na comparação lexical da

primeira etapa da estratégia para que esta informação de alinhamento possa ser

utilizada nas próximas etapas de execução.

A Estratégia 54

A classe ilustrada “trace.view.DOMComparatorViewWithoutInterface” é a

classe principal responsável pelos segundo e terceiro módulos de execução do

CATO. Esta classe dispara a execução de outras classes específicas da

implementação realizada em (Bergmann, 2002) para a comparação estrutural e

uso de medidas de similaridades. O seu método nomeado “showSimilarities” é o

responsável por passar os alinhamentos destas etapas de execução para serem

escritos na ontologia final.

A classe ilustrada nomeada “LastStepSolCombSinonimos” é a responsável

pelo módulo que persiste as informações do alinhamento dos três módulos do

CATO na ontologia final. Seu método “leOnto”, lê as ontologias resultantes do

primeiro módulo e as transforma em modelos orientados a objetos. Nestes

modelos são adicionados os alinhamentos realizados nos outros dois módulos. Os

dois modelos são unidos e, em seguida, são persistidos em um único arquivo do

tipo OWL pela função de escrita chamada write da linguagem Java. Este arquivo

OWL é a ontologia que representa o resultado final do CATO.

A arquitetura do CATO é em camadas, como ilustrado na Figura 20. A

camada da linguagem Java é a que dá suporte a programação orientada a objetos.

A camada da API Jena transforma uma ontologia em um modelo orientado a

objetos. A camada do CATO é a responsável pelo alinhamento de ontologias.

JENA

CATO JAVAJENA

CATO JAVA

Figura 20 – Arquitetura do CATO

3.5.4.1. Estratégia de Aplicação

Toda a execução do CATO é automática, ou seja, sem intervenção alguma

de usuário, precisando apenas ser iniciada com as duas ontologias a serem

alinhadas como suas entradas. Estas ontologias, escritas em OWL, são ilustradas

na Figura 21 pelos arquivos nomeados “firstOnto.owl” e “secondOnto.owl”.

As possíveis informações dos alinhamentos da primeira etapa de execução

do CATO (comparação lexical com o uso de sinônimos e mecanismo de poda

A Estratégia 55

estrutural como condição de parada) são adicionadas nas ontologias originais

(“firstOnto.owl” e “secondOnto.owl”) após a conclusão desta etapa. As ontologias

resultantes são ilustradas na Figura 21 pelos arquivos nomeados

“newFirstOnto.owl” e “newSecondOnto.owl”.

conceitos bem similares

newSecondOntoForTreeDiff.xml

firstOnto.owl

newFirstOnto.owl

Transformação: OWL XML

newFirstOntoForTreeDiff.xml

Parser DOM

secondOnto.owl

newSecondOnto.owl

TreeDiff

Comparação léxica com o uso de sinônimos 1a Etapa

2a e 3a

Etapas

newSecondOnto.owl newFirstOnto.owl

solCombPropFinalFile.owl

conceitos bem similares

newSecondOntoForTreeDiff.xml

firstOnto.owl firstOnto.owl

newFirstOnto.owl

Transformação: OWL XMLTransformação: OWL XML

newFirstOntoForTreeDiff.xml

Parser DOMParser DOM

secondOnto.owl secondOnto.owl

newSecondOnto.owl

TreeDiff

Comparação léxica com o uso de sinônimos 1a EtapaComparação léxica com o uso de sinônimosComparação léxica com o uso de sinônimos 1a Etapa1a Etapa

2a e 3a

Etapas2a e 3a

Etapas

newSecondOnto.owl newSecondOnto.owl newFirstOnto.owl newFirstOnto.owl

solCombPropFinalFile.owlsolCombPropFinalFile.owl Figura 21 – Entradas e saídas das etapas de alinhamento do CATO

As ontologias “newFirstOnto.owl” e “newSecondOnto.owl” são

transformadas em arquivos do tipo XML, onde há apenas as representações de

suas estruturas taxonômicas (hierarquia de conceitos e sub-conceitos). Os

arquivos “newFirstOntoForTreeDiff.xml” e “newSecondOntoForTreeDiff.xml”

ilustrados na Figura 21, são os resultados desta transformação de OWL para XML.

A Estratégia 56

Os arquivos em XML são interpretados pelo parser DOM que cria as visões

de árvores a partir das informações conseguidas com a leitura destes arquivos.

Estas visões de árvores, ilustradas na Figura 21 pelas mini-árvores nomeadas

“DOMTree1” e “DOMTree2”, são as entradas para a execução do algoritmo do

TreeDiff.

A execução do algoritmo do TreeDiff, além de comparar estruturalmente as

árvores (segunda etapa de execução do CATO), faz o cálculo das similaridades

das sub-árvores identificadas como similares (terceira etapa de execução). O

arquivo de saída de sua execução, ilustrado na Figura 21, possui os conceitos

identificados como bem similares.

Nas ontologias resultantes da primeira etapa do CATO são adicionadas as

informações dos conceitos classificados como bem similares. Após esta adição, as

ontologias são unidas em uma ontologia única, ilustrada na Figura 21 pelo arquivo

“solCombPropFinalFile.owl”. Nesta ontologia estão os resultados conseguidos

com o alinhamento, representados pelas ligações entre os conceitos equivalentes

identificados das ontologias comparadas.

A ligação entre os conceitos equivalentes é representada na linguagem de

ontologias OWL pela tag equivalentClass e não pela tag sameAs. No entanto, esta

dúvida é razoável e clarificada a seguir.

A tag equivalentClass é utilizada para indicar que dois conceitos são

equivalentes se, e somente se, possuem, precisamente, as mesmas instâncias

(Smith et al., 2004). Nas tags exemplo abaixo, o conceito Wine utilizado em uma

ontologia local é equivalente, i.e., possui as mesmas instâncias que o conceito

Wine da ontologia importada referenciada por “vin”. <owl:Class rdf:ID="Wine"> <owl:equivalentClass rdf:resource="&vin;Wine"/> </owl:Class> A tag sameAs é utilizada em OWL para declarar a igualdade de indivíduos.

Apenas em OWL Full esta tag também pode ser utilizada para representar a

igualdade de conceitos (Dean et al., 2004a). Nas tags exemplo abaixo, a tag

sameAs indica que o indivíduo vinho denominado MikesFavoriteWine é o mesmo

que o conceito denominado StGenevieveTexasWhite. <Wine rdf:ID="MikesFavoriteWine"> <owl:sameAs rdf:resource="#StGenevieveTexasWhite" /> </Wine>

A Estratégia 57

Como o alinhamento realizado no CATO é dos conceitos equivalentes das

ontologias comparadas, escritas em qualquer um dos tipos de OWL (OWL Full,

DL ou Lite), e não de suas instâncias, então, a tag equivalentClass é a tag

escolhida. Esta tag estabelece as ligações entre os conceitos equivalentes na

ontologia final, resultado do alinhamento do CATO.

4 Estudo de Caso

4.1. Introdução

Para demonstrar a estratégia implementada no Componente para

Alinhamento Taxonômico de Ontologias (CATO), são detalhados três estudos de

caso. Para cada um destes estudos de caso apresentados existe um par de

ontologias complementares a ser alinhado pelo CATO. O primeiro par trata-se de

ontologias específicas de domínios de aplicação. O segundo par trata-se de parte

de uma ontologia genérica alinhada com uma ontologia específica de aplicação. O

terceiro par trata-se de partes específicas de um mesmo assunto de ontologias

genéricas.

Apesar do objetivo do CATO ser alinhar ontologias específicas de domínios

de aplicação, os segundo e terceiro estudos de caso foram realizados com o intuito

de avaliar o seu comportamento frente ao processamento de ontologias com um

grande número de termos e estruturas hierárquicas bem diferentes.

As seis ontologias dos estudos de caso foram escolhidas depois de alguma

pesquisa na Internet. Algumas localizações foram visitadas como: o site de

ontologias publicadas do Google (Google, 2004) com aproximadamente dez links

para novas fontes de ontologias, o diretório de pesquisa do SchemaWeb

(SchemaWeb, 2004a) com aproximadamente cento e cinqüenta ontologias, a

biblioteca de ontologias DAML - Darpa Agent Markup Language, (DAML

ontology library, 2004) com aproximadamente duzentos e oitenta ontologias, entre

outros.

Apesar da quantidade de ontologias disponibilizadas nas localizações

visitadas, poucas ontologias puderam ser analisadas por não serem de fontes

conhecidas ou por apresentarem problemas em sua construção e,

conseqüentemente, não ser possível sua utilização nos editores de ontologias ou

por outros fatores como: links quebrados, repetições da mesma ontologia em mais

Estudo de Caso 59

de uma localização, qualidade da ontologia, entre outros. A estratégia de seleção

das ontologias é explicada no próximo tópico.

Neste capítulo sobre o estudo de caso, a palavra classe será utilizada como

sinônimo da palavra conceito, que é utilizada ao longo deste trabalho, devido ao

fato das nomenclaturas das tags em OWL utilizarem esta primeira palavra e, desta

maneira, o entendimento do texto ser facilitado.

4.2. Estratégia de Seleção das Ontologias

A escolha das ontologias utilizadas nos estudos de caso não envolveu

interesse específico algum, fora o de pesquisa. Foram priorizadas ontologias

disponibilizadas na linguagem de ontologias OWL, de instituições conhecidas e

contextualizadas em domínios específicos de aplicações, as Web Ontologies.

Escolhida uma ontologia de um domínio específico de aplicação, era preciso

escolher uma outra ontologia, de domínio complementar ao da primeira, com

classes equivalentes entre elas a serem alinhadas. As duas ontologias escolhidas

também não deveriam ser criadas pelos mesmos autores. Com estas restrições, o

número de possibilidades diminuía com cada requisito de escolha a ser satisfeito.

Por exemplo, as ontologias organizadas por palavras-chaves do diretório de

ontologias do DAML (DAML ontology library, 2004) foram analisadas. Neste

momento, o interesse de pesquisa era encontrar duas ontologias de aplicações

complementares, disponibilizadas por grupos diferentes e, se possível, já escritas

em OWL, pois, se estivessem escritas em DAML, a transformação para OWL seria

necessária. A ontologia CMU RI Employment Categories (CMU, 2004e) da

Universidade Carnegie Mellon foi encontrada referenciada pela palavra-chave

Academic Positions e escolhida como a segunda ontologia do segundo estudo de

caso. Feita esta escolha, a próxima ontologia a ser escolhida deveria ser de um

domínio complementar ao domínio de categorias de empregos. A ontologia

formada pelas classes do tipo pessoa cadastradas no thesaurus WordNet

(Fellbaum, 2004) encontrada no diretório de pesquisa do SchemaWeb

(SchemaWeb, 2004a) foi a ontologia complementar escolhida. A escolha destas

duas ontologias baseou-se na vontade de analisar os resultados do alinhamento de

parte de uma ontologia genérica, constituída por muitas classes, com uma

ontologia específica.

Estudo de Caso 60

Já no primeiro estudo de caso, o alinhamento foi realizado com duas

ontologias específicas. A primeira ontologia escolhida, a CMU RI Publications

(CMU, 2004d), também da Universidade Carnegie Mellon, é alinhada com a

segunda ontologia escolhida, a General University Ontology (Mondeca, 2004c),

de uma empresa comercial pertencente ao grupo de trabalho da Web-Ontology da

W3C (W3CWebOntWorkingGroup, 2004).

No terceiro estudo de caso, partes específicas de um mesmo assunto foram

extraídas de duas ontologias genéricas e estas partes foram comparadas na

tentativa do alinhamento. As classes referentes à classe “Meio de Transporte” das

ontologias genéricas SUMO (SUMO, 2004) e OpenCYC (OpenCYC, 2004)

constituem as ontologias comparadas a serem alinhadas. Estas ontologias possuem

estruturas hierárquicas bem diferentes.

Para cada um dos três estudos de caso escolhidos é utilizada a seguinte

ordem de apresentação:

1. Resultado da Primeira Etapa;

2. Resultados das Etapas sem Ordenação Alfabética;

2.1. Resultado da Segunda Etapa;

2.2. Resultado da Terceira Etapa;

2.3. Resultado do Alinhamento;

3. Resultados das Etapas com Ordenação Alfabética;

3.1. Resultado da Segunda Etapa;

3.2. Resultado da Terceira Etapa;

3.3. Resultado do Alinhamento;

4. Avaliação dos Resultados;

5. Problemas Encontrados.

Vale ressaltar que os resultados das segunda e terceira etapas e do

alinhamento propriamente dito são influenciados pelos dois módulos

implementados do CATO, o sem ordenação alfabética, i.e., as classes e subclasses

das ontologias comparadas são estruturadas com sua ordem original de criação, e

o com ordenação alfabética, i.e., as classes e subclasses das ontologias

comparadas são estruturadas ordenadas alfabeticamente. Devido a possíveis

diferenças encontradas nos dois módulos implementados, os resultados são

apresentados tanto no tópico dos resultados sem ordenação alfabética quanto no

tópico dos resultados com ordenação alfabética.

Estudo de Caso 61

4.3. Primeiro Estudo de Caso

Duas ontologias independentes, criadas por diferentes grupos, foram

escolhidas como exemplo para o primeiro estudo de caso.

O primeiro grupo escolhido é o do projeto Agent Transaction Language for

Advertising Services – ATLAS (ATLAS, 2004). O ATLAS é um projeto de

pesquisa do grupo de agentes de software (CMU, 2004c) do Instituto de Robótica

(CMU, 2004b) da Universidade Carnegie Mellon (CMU, 2004a), com a

colaboração do Centro de Pesquisa da empresa Nokia (Nokia, 2004) e do Centro

de Pesquisa Alemão para Inteligência Artificial (DFKI, 2004).

A ontologia de publicações do ATLAS, a CMU RI Publications (CMU,

2004d), é a primeira ontologia escolhida. A Figura 22 ilustra suas hierarquias em

DAML (árvore da esquerda da figura) 11 e em OWL (árvore da direita da figura).

[CMUPUBLICATIONSONTOLOGY]em DAML

[CMUPUBLICATIONSONTOLOGY]em OWL

[CMUPUBLICATIONSONTOLOGY]em DAML[CMUPUBLICATIONSONTOLOGY]em DAML

[CMUPUBLICATIONSONTOLOGY]em OWL[CMUPUBLICATIONSONTOLOGY]em OWL

Figura 22 – Representações da ontologia de publicações escolhida

As ontologias do ATLAS são escritas na linguagem DAML. Por esta razão,

a conversão de suas ontologias de DAML para OWL é necessária porque o CATO

11 Os ícones das classes “Bibtex_Publication_Type” e “Conference” estão assinalados

diferentemente na hierarquia em DAML da Figura 22 porque o editor de ontologias OilEd faz essa distinção como indicativo de classes iguais (SameClassAs, em DAML) cadastradas na ontologia.

Estudo de Caso 62

recebe como entradas ontologias escritas em OWL. Tal conversão pode ser

realizada por editores de ontologias que tenham esta funcionalidade, como o

editor OilEd (OilEd, 2004) utilizado.

O endereço do código OWL dessa ontologia de publicações escolhida é

disponibilizado no Anexo A deste documento. O código original em DAML é

disponibilizado em (CMU, 2004d).

O segundo grupo escolhido para este primeiro estudo de caso é o da

empresa francesa Mondeca SA (Mondeca, 2004a), uma das empresas do grupo de

trabalho da Web-Ontology da W3C (W3CWebOntWorkingGroup, 2004).

No ano de 2003, a empresa foi uma das ganhadoras do prêmio European

Information Society Technologies (IST-PRIZE, 2004). Este prêmio é o mais

distinto para produtos e serviços inovadores no campo de tecnologias da

sociedade de informação. O prêmio está aberto às companhias ou às organizações

que apresentam um produto de tecnologia inovadora com um mercado potencial

promissor.

Um dos produtos para gerência da semântica do conhecimento da empresa

Mondeca, o ITM – Intelligent Topic Manager – (Mondeca, 2004b), ilustrado na

Figura 23, faz uso de ontologias. Estas ontologias incluem definições de classes,

tipos associados, relações, tipos de dados e restrições que garantem a coerência de

seus termos.

Figura 23 – Gerenciamento de Conhecimento no ITM

Uma das ontologias utilizada no ITM, a General University Ontology

(Mondeca, 2004c), é a segunda ontologia escolhida para este estudo de caso. O

endereço de seu código OWL é disponibilizado no Anexo A deste documento.

Estudo de Caso 63

As ontologias comparadas neste primeiro estudo de caso podem ser

classificadas como ontologias complementares específicas do domínio de

publicação. A Figura 24 ilustra parte das hierarquias destas ontologias

comparadas.

O1 O2O1 O2

Figura 24 – Ontologias comparadas

Como as ontologias foram criadas por grupos distintos, é de se esperar que

possuam diferenças tanto lexicais quanto estruturais. Por exemplo, a classe

“PhdThesis” da primeira ontologia escolhida (árvore da esquerda na Figura 24)

tem diferenças lexical e estrutural em relação à classe “DoctoralThesis” da

segunda ontologia escolhida (árvore da direita na Figura 24). A diferença lexical é

porque as classes são escritas com diferentes nomes e a diferença estrutural é

porque possuem diferentes superclasses como, por exemplo, sua classe pai (um

nível hierárquico acima). No entanto, a análise destas diferenças por um usuário

classificaria, facilmente, as classes exemplificadas como equivalentes.

Estudo de Caso 64

4.3.1. Resultado da Primeira Etapa

Inicialmente, como não existem cadastrados os sinônimos das classes das

ontologias comparadas e as classes iguais lexicalmente possuem diferenças

estruturais, portanto, não satisfazem a condição de poda da primeira etapa, a

conclusão da primeira etapa de execução do CATO não resulta em alinhamento

algum.

Para tentar algum alinhamento, os sinônimos ilustrados entre colchetes na

Figura 25 foram cadastrados no banco de dados utilizado e a primeira etapa do

CATO foi executada novamente. Nesta nova execução, as classes “TechReport”

de O1 e “TechnicalReport” de O2 foram identificadas como sinônimos e, por

isso, são comparadas. Como estas classes não satisfazem a condição de poda

porque possuem classes pais diferentes, um nível hierárquico acima, não são

alinhadas. O mesmo acontece com as classes “PhdThesis” de O1 e

“DoctoralThesis” de O2. Assim, a conclusão da primeira etapa de execução do

CATO com o uso de sinônimos também não resulta em alinhamento algum.

Figura 25 – Sinônimos cadastrados identificados

Vale lembrar que as informações dos sinônimos identificados só são

propagadas para as demais etapas de execução do CATO se satisfizerem às

condições de alinhamento da primeira etapa. Como nesse estudo de caso elas não

satisfazem tais condições, os sinônimos não são utilizados e, conseqüentemente,

seu uso não resulta impacto algum no alinhamento final das ontologias.

4.3.2. Resultados das Etapas sem Ordenação Alfabética

Os sub-tópicos a seguir mostram os resultados das etapas executadas no

CATO com as hierarquias das árvores comparadas sem ordenação alfabética, onde

as classes e subclasses das ontologias são estruturadas com sua ordem original de

criação.

Estudo de Caso 65

4.3.2.1. Resultado da Segunda Etapa (sem ordenação)

A Figura 26 ilustra as hierarquias das duas ontologias comparadas e seus

grupos de equivalência identificados.

As classes “Bibtex_Publication_Type” de O1 e “Publication” de O2 são

identificadas como similares porque suas subclasses “Proceedings” possuem

igualdade lexical e similaridade estrutural. Assim, os grupos de equivalência,

identificados pelos círculos superiores na Figura 26, são limitados por estas

respectivas classes. Fechados os grupos de equivalência, todas as classes dentro

destes, iguais lexicalmente e estruturalmente, são identificadas como similares.

Isto acontece com as classes “Proceedings”, “Book” e “Manual”, de ambas as

ontologias.

No entanto, algumas classes idênticas lexicalmente como, por exemplo, as

classes “MastersThesis”, de ambas ontologias, pertencentes aos grupos de

equivalência superiores na Figura 26, não são identificadas como similares porque

possuem diferenças estruturais entre elas e próximas a elas, o que dificulta tanto a

identificação de sua similaridade lexical quanto a formação de novos grupos de

equivalência. Em O1, a classe “MastersThesis” é subclasse de

“Bibtex_Publication_Type” e em O2, é subclasse de “Thesis” que, por sua vez, é

subclasse de “Publication”. Como as classes “Bibtex_Publication_Type” de O1 e

“Publication” de O2 foram identificadas como similares, então, existe a diferença

de um nível hierárquico entre as classes “MastersThesis” em O1 e em O2 e, por

isso, não há a identificação de similaridade destas classes.

Pela igualdade lexical das classes “Conference”, em ambas as ontologias, e

sua similaridade estrutural, indicada pela nova classe em O1 e pela nova subclasse

em O2, os próximos grupos de equivalência, representados pelos círculos

inferiores na Figura 26, são identificados e suas classes são classificadas como

similares.

O resultado final desta etapa de execução são as seguintes classes

identificadas como similares: “Proceedings”, “Book”, “Manual” e “Conference”,

de ambas as ontologias, e “Bibtex_Publication_Type” de O1 similar à classe

“Publication” de O2.

Estudo de Caso 66

O1

O2

O1

O2


4.3.2.2. Resultado da Terceira Etapa (sem ordenação)

A terceira etapa de execução do CATO calcula os percentuais de

similaridade das classes identificadas como similares na etapa anterior. A Figura

27 ilustra os resultados de tais cálculos.

Figura 27 – Percentuais de similaridade calculados

4.3.2.3. Resultado do Alinhamento (sem ordenação)

Ao concluir as três etapas de execução, o CATO identifica as classes

equivalentes, i.e., aquelas que satisfazem todas as condições de cada uma de suas

etapas, e realiza o alinhamento. Neste estudo de caso, com as árvores estruturadas

na sua ordem original de criação, as classes “Conference”, ”Proceedings”, “Book”

e “Manual” são as classes alinhadas pelo CATO. Isto porque são identificadas

como similares pela sua segunda etapa de execução e classificadas como bem

Estudo de Caso 67

similares, com um percentual de similaridade maior ou igual a 75%, pela sua

terceira etapa de execução.

A Figura 28 ilustra parte da ontologia final do CATO com a classe “Book”,

original da primeira ontologia, identificada pelo namespace “file:firstOnto.owl”,

com a informação adicionada da classe equivalente identificada, a classe “Book”,

original da segunda ontologia, identificada pelo namespace

“file:secondOnto.owl”.

Informação AdicionadaInformação AdicionadaInformação Adicionada

Figura 28 – Informação adicionada, resultado do alinhamento com o CATO

4.3.3. Resultados das Etapas com Ordenação Alfabética


CATO com as hierarquias das árvores comparadas estruturadas com ordenação

alfabética, i.e., as classes e subclasses das ontologias são estruturadas ordenadas

alfabeticamente.

4.3.3.1. Resultado da Segunda Etapa (com ordenação alfabética)



As classes “Bibtex_Publication_Type” de O1 e “Publication” de O2 são

identificadas como similares porque suas subclasses “Book” possuem igualdade

Estudo de Caso 68

lexical e similaridade estrutural. Assim, os grupos de equivalência, identificados

pelos círculos superiores na Figura 29, são limitados por estas respectivas classes.

Fechados os grupos de equivalência, todas as classes dentro destes, iguais

lexicalmente e estruturalmente, são identificadas como similares. Isto acontece

com as classes “Book” e “Proceedings”, de ambas as ontologias.

O2

O1

O2O2

O1O1


Algumas classes idênticas lexicalmente como, por exemplo, as classes

“MastersThesis” de ambas ontologias, pertencentes aos grupos de equivalência

superiores na Figura 29, não são identificadas como similares porque possuem

diferenças estruturais entre elas e próximas à elas, o que dificulta tanto a

identificação de sua similaridade lexical quanto a formação de novos grupos de

equivalência. Em O1, a classe “MastersThesis” é subclasse de

“Bibtex_Publication_Type” e em O2, é subclasse de “Thesis” que, por sua vez, é

subclasse de “Publication”. Como as classes “Bibtex_Publication_Type” de O1 e

“Publication” de O2 foram identificadas como similares, então, existe a diferença

de um nível hierárquico entre as classes “MastersThesis” em O1 e em O2 e, por

isso, não há a identificação de similaridade destas classes.

Estudo de Caso 69

As classes “Manual”, de ambas as ontologias, também não são identificadas

como similares porque com a ordenação alfabética existem diferenças estruturais

entre elas. Em O1, existe a classe “Booklet” logo abaixo da classe “Manual”, e em

O2, existe a sub-árvore com a classe “Periodical” representando sua raiz e as

subclasses “Journal”, “Magazine”, “Newsletter” e “Newspaper” representando

suas folhas.

Pela igualdade lexical das classes “Conference”, em ambas as ontologias, e

sua similaridade estrutural, indicada pela nova classe em O1 e pela nova subclasse

em O2, os próximos grupos de equivalência, representados pelos círculos

inferiores na Figura 29, são identificados e suas classes são classificadas como

similares.

O resultado final desta etapa de execução são as seguintes classes

identificadas como similares: “Proceedings”, “Book” e “Conference”, de ambas

as ontologias, e “Bibtex_Publication_Type” de O1 similar à classe “Publication”

de O2.

4.3.3.2. Resultado da Terceira Etapa (com ordenação alfabética)





4.3.3.3. Resultado do Alinhamento (com ordenação alfabética)



etapas, e realiza o alinhamento. Neste estudo de caso, com as árvores ordenadas

alfabeticamente, as classes “Conference”, “Book” e ”Proceedings” são as classes

alinhadas pelo CATO. Isto porque são identificadas como similares pela sua

segunda etapa de execução e classificadas como bem similares, com um

Estudo de Caso 70

percentual de similaridade maior ou igual a 75%, pela sua terceira etapa de

execução.

A Figura 31 ilustra parte da ontologia final do CATO com a classe “Book”,

original da primeira ontologia, identificada pelo namespace “file:firstOnto.owl”,

com a informação adicionada da classe equivalente identificada, a classe “Book”,

original da segunda ontologia, identificada pelo namespace

“file:secondOnto.owl”.



4.3.4. Avaliação dos Resultados

Das treze classes da primeira ontologia (O1) e das vinte e três classes da

segunda ontologia (O2) referentes ao domínio de publicação, oito classes no total

(“Conference”, “Manual”, “Book” e ”Proceedings”, de ambas as ontologias) são

alinhadas automaticamente pelo CATO, no módulo sem ordenação e seis classes

no total (“Conference”, “Book” e ”Proceedings”, de ambas as ontologias) no

módulo com ordenação alfabética. Oito novas classes poderiam ser facilmente

alinhadas se fosse permitida a intervenção do usuário (as classes “Article” e

“MastersThesis”, de ambas ontologias e “PhdThesis” de O1 com

“DoctoralThesis” de O2 e “TechReport” de O1 com “TechnicalReport” de O2).

Estudo de Caso 71

Visto que as ontologias comparadas foram desenvolvidas sem um propósito

comum entre elas e por grupos totalmente independentes, o resultado encontrado

pelo CATO é satisfatório.

Neste estudo de caso, os resultados finais dos módulos sem e com

ordenação alfabética, para o processo de alinhamento, foram diferentes. As seis

classes equivalentes, “Conference”, “Book” e ”Proceedings”, de ambas as

ontologias, são alinhadas nos dois módulos. Porém, as classes equivalentes

“Manual”, de ambas as ontologias, não são alinhadas no módulo com ordenação

alfabética porque possuem diferenças estruturais próximas a elas neste módulo.

Além disso, os percentuais de similaridade entres as classes raízes do primeiro

grupo de equivalência identificado (“Bibtex_Publication_Type” de O1 e

“Publication” de O2) são diferentes em ambos os módulos, comprovando que seu

cálculo também é influenciado pelos percentuais de similaridade de suas

subclasses.

4.3.5. Problemas Encontrados

A qualidade do alinhamento poderia ser sensivelmente melhorada se os

sinônimos das classes já estivessem cadastrados no banco de dados ou se

houvesse o uso de um banco de sinônimos melhor. No entanto, como foi visto, se

existem diferenças nos nomes das classes pais (um nível hierárquico acima) ou

avôs (dois níveis hierárquicos acima) de uma classe e seu sinônimo, a informação

identificada do sinônimo não é utilizada no processo de alinhamento. Este fato é

um problema que merece melhor análise para minimizar a falta de completude do

alinhamento realizado pelo CATO.

Neste exemplo de estudo de caso, o uso de sinônimos possibilitaria o CATO

alinhar automaticamente as oito classes facilmente alinhadas por um usuário (as

classes “Article” e “MastersThesis”, de ambas ontologias, e a classe “PhdThesis”

de O1 com a classe “DoctoralThesis” de O2 e a classe “TechReport” de O1 com a

classe “TechnicalReport” de O2) se suas classes pais e avôs fossem descritas com

os mesmos nomes ou se existisse outra condição de poda a ser satisfeita (por

exemplo, além da igualdade dos nomes destas classes também a igualdade dos

nomes com seus sinônimos para as classes pais e avôs, como é feito para as

classes que dispararam a análise da condição de poda).

Estudo de Caso 72

Em relação à execução do CATO, nenhum problema foi encontrado com

este estudo de caso escolhido. As ontologias de entrada foram alinhadas

automaticamente, sem erro algum.

4.4. Segundo Estudo de Caso

Este estudo de caso compara parte de uma ontologia genérica com uma

ontologia específica onde, além do nível de abstração das classes, também as

estruturas hierárquicas das ontologias comparadas são bem diferentes. A Figura

32 ilustra estas diferentes hierarquias. Os endereços das ontologias escritas em

OWL estão disponíveis no Anexo B deste documento.

O1 O2O1O1O1 O2O2O2


A primeira ontologia escolhida é formada pelas classes do tipo pessoa

cadastradas no thesaurus WordNet (Fellbaum, 2004). Esta ontologia é

Estudo de Caso 73

disponibilizada no diretório de pesquisa do SchemaWeb em (SchemaWeb,

2004b).

A segunda ontologia escolhida, a CMU RI Employment Categories (CMU,

2004e), é sobre as categorias de empregos do Instituto de Robótica da

Universidade Carnegie Mellon, também do grupo de pesquisa ATLAS (ATLAS,

2004), de onde a primeira ontologia do primeiro estudo de caso foi escolhida.

Esta experiência foi interessante porque permitiu a avaliação do CATO

frente ao alinhamento de ontologias formadas por um grande número de termos.

Como a primeira ontologia (O1) é formada pelas classes do WordNet e este trata-

se de um thesaurus, é esperado que existam várias classes descritas e estas sejam

mais genéricas que as criadas na segunda ontologia (O2), que é constituída por

classes específicas do domínio de tipos de empregos.






algum.



CATO foi executada novamente. Nesta nova execução, as classes “Technologist”

(subclasse de “Person”) de O1 e “Research_Programmer” (subclasse de

“Research_Staff”) de O2 foram identificadas como sinônimos e, por isso, são

comparadas. Como estas classes não satisfazem a condição de poda porque

possuem classes pais diferentes, um nível hierárquico acima, não são alinhadas. O

mesmo acontece com as classes “Scholar” e “Learner” (subclasses de “Person”)

de O1 identificadas como sinônimos da classe “Student” (subclasse de

“RI_Employment_Categories”) de O2. Assim, a conclusão da primeira etapa de

execução do CATO com o uso de sinônimos também não resulta em alinhamento

algum.

Estudo de Caso 74


Como as informações dos sinônimos identificadas não satisfazem as

condições de alinhamento da primeira etapa de execução do CATO, então, não

são propagadas para as demais etapas de execução e, conseqüentemente, o uso dos

sinônimos não resulta impacto algum no alinhamento final das ontologias, neste

estudo de caso.





criação.




O1 O2O1 O2


Estudo de Caso 75

Em O1, só existe uma classe raiz, a classe “Person”, e todas as demais

classes da ontologia são subclasses desta classe raiz. Em O2, existem classes tanto

sem subclasses como, por exemplo a classe “Engineer”, quanto com subclasses

como, por exemplo, a classe “RI_Employment_Categories”. Como em O2 não

existe uma classe raiz única cadastrada, como a classe “Person” de O1, então, o

CATO vai formando os grupos de equivalência sempre com uma das subclasses

de O1 com as classes sem subclasses de O2. Assim, as únicas classes

equivalentes, as classes “Engineer”, de ambas as ontologias, são identificadas

como similares pelos grupos de equivalências formados por suas classes.










na sua ordem original de criação, as classes “Engineer”, de ambas as ontologias,

são as classes alinhadas pelo CATO. Isto porque, são identificados como

similares pela sua segunda etapa de execução e classificados como bem similares,

com um percentual de similaridade maior ou igual a 75%, pela sua terceira etapa

de execução.

A Figura 36 ilustra parte da ontologia final do CATO com a classe

“Engineer”, original da segunda ontologia, identificada pelo namespace

“file:secondOnto.owl”, com a informação adicionada da classe equivalente

identificada, a classe “Engineer”, original da primeira ontologia, identificada pelo

namespace “file:firstOnto.owl”.

Estudo de Caso 76







alfabeticamente.




Em O1, só existe uma classe raiz, a classe “Person”, e todas as demais

classes da ontologia são subclasses desta classe raiz. Em O2, existem classes tanto

sem subclasses como, por exemplo, a classe “Engineer”, quanto com subclasses

como, por exemplo, a classe “RI_Employment_Categories”. Como em O2 não

existe uma classe raiz única cadastrada, como a classe “Person” de O1, então, o

CATO vai formando os grupos de equivalência sempre com uma das subclasses

de O1 com as classes sem subclasses de O2. Assim, as únicas classes

equivalentes, as classes “Engineer”, de ambas as ontologias, são identificadas

como similares pelos grupos de equivalências formados por suas classes.

Estudo de Caso 77

O1 O2O1 O2











ordenadas alfabeticamente, as classes “Engineer”, de ambas as ontologias, são as

classes alinhadas pelo CATO. Isto porque são identificadas como similares pela

sua segunda etapa de execução e classificadas como bem similares, com um

percentual de similaridade maior ou igual a 75%, pela sua terceira etapa de

execução.

Estudo de Caso 78


“Engineer”, original da segunda ontologia, identificada pelo namespace

“file:secondOnto.owl”, com a informação adicionada da classe equivalente

identificada, a classe “Engineer”, original da primeira ontologia, identificada pelo

namespace “file:firstOnto.owl”.




Neste exemplo de estudo de caso, das mais de quinhentas e setenta classes

da primeira ontologia (O1) e das aproximadamente trinta classes da segunda

ontologia (O2), as classes equivalentes “Engineer”, de ambas as ontologias, foram

as alinhadas pelo CATO, nos seus módulos sem e com ordenação alfabética.

Visto que as ontologias comparadas foram desenvolvidas sem um propósito

comum entre elas e por grupos totalmente independentes, além de serem de tipos

diferentes (O1 é parte de uma ontologia genérica e O2 é uma ontologia

específica), o resultado encontrado pelo CATO é satisfatório. Isto porque o CATO

traz a automação necessária para o alinhamento destas ontologias, pois, o

alinhamento manual seria bastante trabalhoso, devido à grande quantidade de

classes existentes a serem comparadas. Vale lembrar que as mais de quinhentas e

setenta classes de O1, originalmente, não estão organizadas alfabeticamente como

Estudo de Caso 79

ilustradas na Figura 37, de modo a facilitar a comparação. Esta organização foi

realizada pelo CATO.

Neste estudo de caso, os resultados finais dos módulos sem e com

ordenação alfabética, para o processo de alinhamento, não foram diferentes. As

duas classes equivalentes ”Engineer”, de ambas as ontologias, são alinhadas

nestes dois módulos. Além disso, a classe raiz “Person” de O1 teve os mesmos

valores de percentuais de similaridade calculados nos dois módulos, confirmando

que a ordenação das classes neste estudo de caso não teve influência no

alinhamento final do CATO.


Para ontologias modeladas com estruturas diferentes como, por exemplo,

uma ontologia com poucas classes gerais e muitas classes específicas, comparada

com uma outra ontologia, com muitas classes gerais e poucas classes específicas,

a identificação dos grupos de equivalência é difícil porque existe pouca

similaridade estrutural entre as classes. Conseqüentemente, o número de classes

alinhadas é bastante reduzido. Este número resume-se às classes alinhadas na

primeira etapa de execução do CATO ou, talvez, às identificadas como iguais

lexicalmente nos grupos de equivalência da segunda etapa.



automaticamente, sem erro algum. No entanto, houve uma maior demora em

comparação ao tempo de execução dos demais estudos de caso devido ao maior

número de classes a serem comparadas neste estudo de caso.

4.5. Terceiro Estudo de Caso

Este estudo de caso trata de ontologias criadas com as classes referentes à

classe “Meio de Transporte”. Para a comparação, as partes específicas ao assunto

foram extraídas das ontologias genéricas SUMO (SUMO, 2004) e OpenCYC

(OpenCYC, 2004). Os endereços das ontologias resumidas escritas em OWL estão

disponíveis no Anexo C deste documento.

Esta experiência de alinhamento foi interessante porque, como as ontologias

comparadas são genéricas, suas classes estão organizadas segundo uma hierarquia

Estudo de Caso 80

de classes bem gerais, algumas delas ilustradas na Figura 40. Por exemplo, nas

duas ontologias existem as classes “Ambulance” cadastradas. No entanto, na

primeira ontologia (O1), esta classe é subclasse das seguintes classes:

“EmergencyRoadVehicle”, que é subclasse de “RoadVehicle”, que é subclasse de

“LandVehicle”, que, finalmente, é subclasse da raiz “Vehicle”. Na segunda

ontologia (O2), a classe “Ambulance” é subclasse das seguintes classes:

“EmergencyVehicle”, que é subclasse de “Vehicle”, que é subclasse de

“TransportationDevice”, que é subclasse de “SelfPoweredDevice”, que, por fim, é

subclasse de “MechanicalDevice”.

O1O2

O1O2


O alinhamento realizado pelo CATO neste estudo de caso é bastante

limitado porque, apesar da igualdade lexical de algumas de suas classes, estas não

possuem similaridades estruturais. Assim, além das condições de poda da

primeira etapa de execução do CATO não serem satisfeitas, resultando no não

alinhamento das classes iguais lexicalmente, a identificação dos grupos de

equivalência também é dificultada, o que faz com que a comparação estrutural,

segunda etapa de execução, e o cálculo de medidas de similaridades, terceira etapa

de execução, resultem em poucas classes alinhadas.

Estudo de Caso 81






algum.



CATO foi executada novamente. Nesta nova execução, as classes

“MilitaryAircraft” de O1 e “MilitaryVehicle” de O2 foram identificadas como

sendo sinônimos e, por isso, são comparadas. Como estas classes não satisfazem a

condição de poda porque possuem classes pais diferentes, um nível hierárquico

acima, não são alinhadas. O mesmo acontece com as classes “LandVehicle” de

O1 e “LandTransportationDevide” de O2, “Aircraft” de O1 e

“FixedWingAircraft” de O2 e, por fim, as classes comparadas “Bus” de O1 e

“Bus-RoadVehicle” de O2. Assim, a conclusão da primeira etapa de execução do

CATO com o uso de sinônimos também não resulta em alinhamento algum.


Neste estudo de caso, para exemplificar o uso dos sinônimos identificados, a

classe “LandTransportationDevide” de O2 foi renomeada para “LandVehicle”

(facilmente identificada por um usuário como equivalente à classe “LandVehicle”

de O1) e a primeira etapa do CATO executada mais uma vez. Agora, as condições

de poda das seguintes classes são satisfeitas e, conseqüentemente, seus

alinhamentos são realizados: a classe “Bus” de O1 é alinhada com a classe “Bus-

RoadVehicle” de O2, e as classes “RoadVehicle”, “Motorcycle” e “Automobile”,

de ambas ontologias, são alinhadas.

Estudo de Caso 82

Figura 42 – Informação adicionada, resultado do alinhamento com o uso de sinônimos

na primeira etapa do CATO

A Figura 42 ilustra as informações de equivalência identificadas pelo CATO

da classe “RoadVehicle” de O1 com a classe “RoadVehicle” de O2, tanto na

resposta das informações existentes nesta classe após o término de execução da

primeira etapa quanto em seu código resultado em OWL.

Com a renomeação realizada, as informações dos sinônimos identificados

satisfazem as condições de alinhamento da primeira etapa de execução do CATO

e, por isso, estas seriam propagadas para as demais etapas de execução.

Conseqüentemente, o uso dos sinônimos impactaria no alinhamento final das

ontologias.

No entanto, a apresentação deste estudo de caso continuará com as

ontologias originais escolhidas sem qualquer modificação. Assim, a renomeação

da classe “LandTransportationDevice” de O2, utilizada apenas para exemplificar

o uso dos sinônimos, é desfeita e os alinhamentos resultantes desta renomeação (a

classe “Bus” de O1 alinhada com a classe “Bus-RoadVehicle” de O2, e as classes

alinhadas “RoadVehicle”, “Motorcycle” e “Automobile”, de ambas ontologias)

serão desconsiderados porque não mais satisfazem a condição de poda.





criação.


A Figura 43 ilustra as estruturas hierárquicas das ontologias comparadas.

Devido ao fato das poucas classes iguais lexicalmente possuírem diferenças

estruturais entre elas, a execução do CATO, neste módulo, não identificou

Estudo de Caso 83

qualquer grupo de equivalência e, conseqüentemente, nenhuma classe foi

identificada como similar nesta etapa de execução. O1

O2

O1O1

O2O2

Figura 43 – Estruturas hierárquicas das ontologias comparadas



similaridade das classes identificadas como similares na etapa anterior.

Como nenhuma classe foi identificada como similar na etapa anterior deste

módulo, então, nenhum cálculo de percentual de similaridade é realizado.





na sua ordem original de criação, nenhuma classe foi alinhada. Tal resultado é

aceitável porque as ontologias comparadas são extraídas de ontologias genéricas

e, por isso, possuem além de classes bem abstratas, identificadas por diferentes

nomes, também modelagens conceituais bastante distintas.

Estudo de Caso 84





alfabeticamente.




Neste exemplo, como as duas ontologias comparadas possuem uma relação

fraca entre elas, então, os muitos grupos de equivalência identificados resumem-

se, praticamente, aos formados pelas classes equivalentes com alguma

similaridade entre elas. Essa identificação é influenciada tanto pela igualdade

lexical quanto pela organização estrutural dessas classes equivalentes. Por

exemplo, as classes “RoadVehicle”, de ambas ontologias, são identificadas como

similares e seus grupos de equivalência definidos porque são iguais lexicalmente e

cada uma delas possui exatamente três subclasses.

Já as classes “LandVehicle” de O1 e “Vehicle” de O2 são identificadas

como similares porque possuem uma grande quantidade de subclasses

organizadas com similaridades estruturais. Com estas identificações e

similaridades estruturais das classes superiores a “LandVehicle” de O1 e

“Vehicle” de O2, outros grupos de equivalência são fechados. Nestes grupos, as

classes raízes "Aircraft" de O1 e "AirTransportationDevice” de O2 são

identificadas como similares.

As seguintes outras classes são identificadas como similares, devido à

igualdade lexical e similaridade estrutural: “Vehicle”, “Airplane” e “Truck”, de

ambas as ontologias comparadas.

Estudo de Caso 85

O2

O1

O2

O1







Estudo de Caso 86





ordenadas alfabeticamente, as classes “Airplane”, de ambas as ontologias

comparadas, são as classes alinhadas pelo CATO. Isto porque são identificadas

como similares pela sua segunda etapa de execução e classificadas como bem

similares, com um percentual de similaridade maior ou igual a 75%, pela sua

terceira etapa de execução.


“Airplane”, original da primeira ontologia identificada pelo namespace

“file:firstOnto.owl”, com a informação adicionada da classe equivalente

identificada, a classe “Airplane”, original da segunda ontologia identificada pelo

namespace “file:secondOnto.owl”.




Apesar de ser utilizado para um propósito diferente do que foi

implementado, i.e., comparação de ontologias genéricas em vez de comparação de

ontologias específicas, o CATO trouxe resultado com seu alinhamento neste

Estudo de Caso 87

exemplo de estudo de caso. Claro que este resultado não é tão bom como o

conseguido na comparação de ontologias complementares, onde estas ontologias

são de domínios específicos com classes relacionadas entre elas, mas por outro

lado, é bem melhor do que o resultado conseguido com o alinhamento semi-

automático ou manual, levando em consideração o tempo de resposta destes. Isto

porque, as ontologias comparadas são genéricas e possuem um grande número de

classes a serem comparadas sem uma organização hierárquica intuitiva. Assim, a

comparação semi-automática ou manual demoraria um tempo razoável para ser

concluída, ao passo que o CATO retorna a resposta em poucos minutos.




automaticamente, sem erro algum.

5 Conclusões

Neste trabalho, o problema de interoperabilidade de ontologias é explorado

desde seu estudo até a definição de uma estratégia para sua resolução parcial.

A estratégia definida proposta prioriza o alinhamento taxonômico de

ontologias utilizando soluções simples para comparação lexical e estrutural, e uso

de medidas de similaridades para tomada de decisão. Estas soluções, vindas da

Ciência da Computação, foram estudadas, experimentadas e analisadas para a

customização do tratamento com ontologias. Basicamente, a customização

realizada foi a aplicação das soluções escolhidas à representação OWL para a

detecção de similaridades.

A estratégia é demonstrada com sua implementação onde, após a conclusão

de suas três etapas de execução, as ontologias de entrada são alinhadas

automaticamente. Cada etapa de execução possui condições a serem satisfeitas

que refinam os resultados conseguidos e garantam a confiabilidade da solução.

Os limites desta estratégia implementada podem ser expandidos com as

adições de mais termos a serem comparados nas ontologias e de novos recursos

para estas comparações.

5.1. Contribuições

Espera-se que o trabalho apresentado contribua para o entendimento do

processo de alinhamento taxonômico de ontologias. Desta maneira, possibilite um

maior envolvimento da comunidade acadêmica neste tipo de processo.

O trabalho contém os resultados alcançados com a aplicação da estratégia de

alinhamento proposta e sua implementação, tornando-se, assim, uma possível

referência para os que pretendem usar os ajustes sugeridos em um caso prático.

O texto apresentado possibilita um melhor entendimento da Web Semântica

e o papel fundamental do uso de ontologias neste ambiente; um melhor

entendimento do problema da interoperabilidade de ontologias existente na Web

Semântica; e um melhor entendimento dos diversos mecanismos que contribuam

Conclusões 89

para a interoperabilidade de ontologias, em especial, o mecanismo de

alinhamento.

As seguintes contribuições conseguidas com a realização do trabalho para o

alinhamento de ontologias podem ser pontuadas:

• Elaboração de uma estratégia automática para o alinhamento taxonômico

de ontologias;

• Elaboração de uma arquitetura para a estratégia proposta em que são

previstas novas expansões de seus limites;

• Implementação do Componente para Alinhamento Taxonômico de

Ontologias – o CATO;

• Análise e estudo dos resultados conseguidos com os experimentos do

alinhamento taxonômico.

5.1.1. Comparação com outras soluções

A estratégia elaborada e implementada tem como característica ser uma

solução para um problema específico, o de alinhamento taxonômico de

ontologias. Tal solução é automática (sem a intervenção do usuário) e de certa

maneira é rápida (a resposta é fornecida em poucos segundos, imediatamente após

sua execução) e é confiável (com baixo percentual de erro, devido às condições

que devem ser satisfeitas para a efetivação dos alinhamentos identificados).

O CATO ainda possui pontos a serem tratados, descritos no tópico 5.2. deste

texto sobre a avaliação da estratégia, no entanto, é uma ferramenta pública

funcional para o alinhamento taxonômico de ontologias. Não foi encontrada

nenhuma outra ferramenta disponibilizada que resolvesse o problema de

alinhamento de ontologias, mesmo que apenas o alinhamento taxonômico, de

acordo com os requisitos da solução dada.

A busca por outras soluções para o alinhamento de ontologias concentrou-se

no site de ferramentas do programa DARPA (DAML Tools, 2004) e no site de

plug-ins do projeto Protégé (Protege, 2004b). Ambas as localizações são bem

conhecidas pela comunidade de trabalho de ontologias na Web devido ao

pioneirismo de seus trabalhos desenvolvidos e à boa qualidade dos resultados

disponibilizados.

Conclusões 90

O programa DARPA Agent Markup Language - DAML (DAML, 2004) foi

iniciado oficialmente em Agosto de 2000 e tem como objetivo prover o

fundamento da Web Semântica através do desenvolvimento de linguagens e

ferramentas para esta Web. O programa disponibiliza em (DAML Tools, 2004)

mais de duzentas ferramentas distribuídas em categorias diferentes. A categoria

específica Ontology Translation, referente à interoperabilidade, foi investigada a

procura de ferramentas para o alinhamento de ontologias. Nesta categoria, as

seguintes três ferramentas foram encontradas: Articulation Service, Lexicon-Based

Ontology Mapping Tool e OntoMerge. Destas três ferramentas, as duas primeiras

tratam de ferramentas para o mapeamento de ontologias e a última para a

combinação de ontologias. Nenhuma ferramenta específica para o alinhamento de

ontologias foi encontrada.

O projeto Protégé (Protege, 2004a) não se resume apenas a um dos editores

de ontologias e base de conhecimento mais conhecido atualmente, mas também, a

uma comunidade de pesquisa com mais de dezoito mil usuários registrados, listas

de discussão, workshops, publicações e documentações variadas (e.g. perguntas

mais freqüentes, guia do usuário, tutoriais, entre outras). O projeto disponibiliza

em (Protege, 2004b) uma série de plug-ins. No tópico específico a gerência de

projeto, o plug-in PROMPT (Protege, 2004c) foi encontrado. Este plug-in permite

ao usuário a gerência de múltiplas ontologias, de forma a: comparar as versões de

mesmas ontologias, combinar duas ontologias quaisquer em uma única ontologia,

extrair partes de uma ontologia, entre outras funcionalidades. No entanto, a

funcionalidade de alinhamento não foi encontrada e, além disso, o uso do

PROMPT requer a intervenção do usuário, ou seja, trata-se de uma ferramenta de

suporte semi-automático. As demais ferramentas do conjunto PROMPT descritas

no tópico 2.3. deste texto, sobre a revisão da literatura, não foram encontradas

disponibilizadas.

5.2. Avaliação da Estratégia

Na estratégia elaborada para o alinhamento taxonômico de ontologias foram

realizadas as seguintes avaliações:

Conclusões 91

Falta de Completude

A estratégia prioriza a identificação da semântica dos conceitos das

ontologias comparadas, de forma a descobrir aqueles que são semanticamente

equivalentes. Propriedades, restrições, axiomas, entre outros indicativos

semânticos não são analisados atualmente.

A falta de completude da estratégia existe tanto no não alinhamento de

termos não investigados nas ontologias comparadas quanto nos conceitos

investigados, mas que não são alinhados por não satisfazerem as condições

estabelecidas de alinhamento das etapas da estratégia.

No entanto, a abordagem adotada, onde o alinhamento é tratado em etapas

distintas, prevê novas comparações de termos das ontologias e melhorias para as

condições de alinhamento, de forma a minimizar a falta de completude da

estratégia.

Frente à possibilidade de falta de completude no alinhamento, o pior

resultado encontrado pelo CATO é não ter alinhado conceito equivalente algum

das ontologias comparadas. Isto acontece, normalmente, quando estas ontologias

possuem uma relação fraca entre elas. Neste caso, existem poucos conceitos

comuns e estes estão afastados estruturalmente, o que dificulta a identificação

automática das equivalências.

Possibilidade de Existência de Inconsistências

No tópico 2.2.1. deste trabalho, sobre compatibilidade de termos, são

numerados alguns pontos a serem tratados para minimizar a presença de

inconsistências no processo de interoperabilidade de ontologias.

A estratégia elaborada trata apenas os três primeiros pontos listados (itens

um, dois e três). A análise automática das demais inconsistências, mesmo quando

aplicada a um conjunto pequeno de termos, aumentaria razoavelmente a

complexidade de qualquer estratégia proposta e, conseqüentemente, seu tempo de

execução. Como se deseja o alinhamento de ontologias em um tempo de execução

da solução reduzido, optou-se por deixar de lado o tratamento direto das

inconsistências restantes (itens quatro a onze).

Porém, a execução das etapas dois e três da estratégia, descritas nos tópicos

3.3. e 3.4. deste texto, contornam parte do problema de existência de

Conclusões 92

inconsistências através da comparação estrutural dos termos e da utilização de

medidas de similaridade, em um tempo de execução reduzido.

Frente à presença de inconsistências no alinhamento, o pior resultado

possível encontrado pelo CATO é o alinhamento de dois conceitos que usam o

mesmo nome ou um nome e seu sinônimo, mas que são semanticamente

diferentes. Tais conceitos precisam ser idênticos lexicalmente e possuir

similaridade estrutural. No entanto, isto não deve acontecer se as ontologias de

entrada são modeladas corretamente de acordo com as regras sugeridas em (Smith

et al., 2004), (Uschold, 1996), entre outras para boas práticas de construção de

ontologias.

Risco de Inviabilidade Frente às Inconsistências

O risco de inviabilidade da solução existe tanto devido à presença de

inconsistências quanto à possibilidade de falta de completude no alinhamento. Tal

risco é minimizado à medida que novos avanços são adicionados à solução de

forma a suavizar a atuação de seus responsáveis.

Reduzindo o Efeito dos Resultados Negativos

A adição de novos recursos na implementação da estratégia elaborada

possibilita o alinhamento com maior precisão de mais termos das ontologias

comparadas. Isto porque fontes de dados diferentes adicionadas para a busca de

informação possibilitam o uso de critérios melhores para a identificação de termos

iguais semanticamente.

Na comparação lexical, além do uso de dicionário de sinônimos, pode-se

também pensar no uso de thesauri e de ontologias preferenciais como bases de

conhecimento. Um termo e seu sinônimo para serem alinhados precisariam

também ter suas informações identificadas nestes novos recursos a serem

utilizados. Desta maneira, consegue-se mais um critério para garantir a precisão

nos resultados encontrados pela estratégia de alinhamento.

Na comparação estrutural, a atual implementação do algoritmo TreeDiff,

que foi evoluída do problema base de rastreabilidade12, ou seja, leva em conta a

12 Entende-se por rastreabilidade a habilidade de descrever e acompanhar as alterações em

ambas as direções, avante e reversa, isto é, desde as origens, passando pelo desenvolvimento e especificação, até subseqüente distribuição e utilização, através de refinamentos e interações contínuas em qualquer destas fases. Adaptado de (Bergmann, 2002).

Conclusões 93

ordem de suas entradas, deveria ser executada pelo menos duas vezes para a

efetivação das respostas no alinhamento. As respostas destas duas execuções

seriam cruzadas e apenas as respostas comuns, i.e., os termos identificados como

similares em ambas as execuções realizadas, seriam consideradas.

Por exemplo, se a resposta da primeira execução (rastreabilidade de O1 para

O2) identificou que o conceito exemplo “C1” da ontologia O1 é similar ao

conceito exemplo “C2” da ontologia O2 e a resposta da segunda execução

(rastreabilidade de O2 para O1) identificou que o conceito “C2” da ontologia O2

é similar ao conceito “C1” da ontologia O1, então, a informação de similaridade é

considerada. Caso contrário, não. De novo, tem-se mais um critério para garantir a

precisão nos resultados encontrados pela estratégia de alinhamento.

Além disso, uma possível melhoria no algoritmo do TreeDiff seria alterá-lo

de forma que a comparação estrutural só fosse aplicada depois que todas as

identificações lexicais fossem encontradas. Desta maneira, os grupos de

equivalência seriam formados priorizando os termos iguais lexicalmente em maior

quantidade. Atualmente, a comparação estrutural é realizada assim que a

igualdade lexical é identificada e seus grupos de equivalências são formados.

Limitações

O CATO traz bons resultados quando aplicado em ontologias de domínios

complementares, similares e de sobreposição. Nestas ontologias, normalmente, os

conceitos equivalentes estão próximos estruturalmente e são identificados com os

mesmos nomes ou com seus sinônimos. Nestes casos, a identificação dos grupos

de equivalência é mais precisa e, conseqüentemente, o alinhamento também.

Para ontologias com relação fraca entre elas, i.e., possuem poucos conceitos

equivalentes e estes separados estruturalmente, o CATO pode demorar mais para

ser executado que o alinhamento manual (quando este é viável, devido à

quantidade de conceitos a serem comparados das ontologias de entrada) e trazer

menos conceitos alinhados que este.

Em ontologias com conceitos semanticamente diferentes, mas estes

identificados com os mesmos nomes ou com seus sinônimos e próximos

estruturalmente, o CATO pode resultar em um alinhamento errôneo destes

conceitos. Isto porque, o alinhamento será realizado sempre que as condições da

Conclusões 94

estratégia (igualdade lexical satisfazendo o mecanismo de poda, e classificação do

conceito como bem similar) são satisfeitas.

5.3. Trabalhos Futuros

Como trabalhos futuros, propõem-se a realização de análises mais

detalhadas das soluções de cada uma das etapas da estratégia implementada

visando à identificação de melhorias necessárias. Algumas possíveis evoluções

são apresentadas a seguir:

Utilização da Estratégia para Versionamento de Ontologias

A implementação do algoritmo TreeDiff dada em (Bergmann, 2002) tem

como objetivo a rastreabilidade da evolução de cenários. Desta implementação

obtêm-se, originalmente, como resultados da comparação de duas árvores, tanto as

informações de suas similaridades quanto de suas diferenças detectadas.

A estratégia elaborada para o alinhamento taxonômico de ontologias,

atualmente, não leva em consideração as informações das diferenças detectadas

entre as árvores comparadas. Adicionado tais informações na estratégia e tendo

como suas entradas ontologias de versões diferentes e, não ontologias de domínios

complementares, esta poderia ser utilizada também para o tratamento de

versionamento de ontologias.

Acredita-se que com tal mudança a estratégia teria uma ótima aplicabilidade

nas identificações de similaridades e diferenças, realizadas em ontologias de

versões diferentes. Isto porque, estas ontologias são evoluções umas das outras,

onde as principais mudanças na edição costumam ser novas adições ou exclusões

de termos e, além disso, os termos originais continuam com o mesmo nome e no

mesmo nível hierárquico. Neste caso, a identificação dos grupos de equivalências

é facilitada e, conseqüentemente, os resultados da estratégia para o versionamento

de ontologias (diferenças e similaridades detectadas) são mais precisos.

Melhoria dos Recursos para a Comparação Lexical

Como mostrado no capítulo do estudo de caso, o uso de um banco de

sinônimos que contenha uma grande quantidade de conceitos cadastrados e seus

respectivos sinônimos pode aumentar, razoavelmente, a quantidade de conceitos

Conclusões 95

alinhados. Por esta razão, a qualidade do banco de sinônimos deve ser melhorada

sempre que possível.

O uso dos sinônimos identificados também poderia ser, razoavelmente,

melhorado caso a condição de poda de generalização da primeira etapa da

estratégia, que decide sobre este uso, fosse mais flexível. Deveria ser permitido o

uso de sinônimos na comparação lexical dos conceitos pai (um nível hierárquico

acima) e avô (dois níveis hierárquicos acima) nesta condição de poda de

generalização. No entanto, vale lembrar que a estratégia é automática e que a

confiabilidade de sua resposta deve ser sempre levada em conta. Para que

sinônimos sejam utilizados em maior escala é necessário, antes, a realização de

alguns experimentos e análise de seus resultados.

A adição de novos recursos na comparação lexical de forma a enriquecer os

conceitos das ontologias comparadas com as informações de seus relacionamentos

com outros conceitos deve ser considerada. Tais informações podem ser

conseguidas com o uso de thesauri como, por exemplo, o WordNet (Fellbaum,

1998). O uso deste thesaurus disponibiliza uma lista de conceitos relacionados e

informações de generalização e especialização, como:

• Hiperonímia (Hypernyms, em inglês) do conceito: o conceito é um tipo

de... (lista de conceitos);

• Hiponímia (Hyponyms, em inglês) do conceito: ... (lista de conceitos) é

um tipo do conceito;

• Holonímia (Holonyms, em inglês) do conceito: o conceito é parte de...

(lista de conceitos);

• Meronímia (Meronyms, em inglês) do conceito: ... (lista de conceitos) é

parte do conceito.

Tais informações dependem do sentido do conceito. O conceito carro (car,

em inglês) é utilizado como entrada no WordNet para exemplificar as informações

pontuadas acima. A Figura 47 ilustra seus sentidos semânticos cadastrados. Para o

conceito carro significando veículo automotor (primeiro sentido semântico

cadastrado no WordNet), são obtidas as seguintes respostas:

• A hiperonímia do conceito, ilustrada na Figura 48. Exemplo: o conceito

carro é hiperônimo do conceito container (container, em inglês), ou

seja, carro é um tipo de container;

Conclusões 96

Figura 47 – Sinônimos do termo carro, ordenados por estimativa de freqüência

Figura 48 – Hiperonímia de carro significando veículo automotor (carro é um tipo de ...)

• A hiponímia do conceito, ilustrada na Figura 49. Exemplo: o conceito

ambulância (ambulance, em inglês) é hipônimo do conceito carro, ou

seja, ambulância é um tipo de carro;

• A meronímia do conceito, ilustrada na Figura 51. Exemplo: o conceito

buzina (horn, em inglês) é merônimo do conceito carro, ou seja, buzina

é parte do carro;

• Os termos do domínio, ilustrados na Figura 52. Exemplo: aluguel (rent,

em inglês), mapa de estradas (road map, em inglês), passageiros

(passenger, em inglês), etc., são termos do domínio do conceito carro.

A holonímia para o conceito carro significando veículo automotor não é

cadastrada no WordNet. Por esta razão, as informações dos demais sentidos são

ilustradas na Figura 50. Exemplo: O conceito carro é parte do conceito elevador

Conclusões 97

(elevator, em inglês) quando carro tem o sentido semântico de carro de elevador

(elevator car, em inglês).

Figura 49 – Hiponímia de carro significando veículo automotor (... é um tipo de carro)

Figura 50 – Holonímia de carro (carro é parte de ...)

Figura 51 – Meronímia de carro significando veículo automotor (... é parte de carro)

Figura 52 – Termos do domínio de carro significando veículo automotor

Conclusões 98

Utilização de Relacionamentos de Composição na Comparação Estrutural

Os relacionamentos de composição entre conceitos, i.e., relacionamentos do

tipo “parte-de”, podem ser representados estruturalmente por árvores. Nesta

representação, a raiz é o conceito mais geral e os conceitos de composição são

suas folhas, todos no mesmo nível hierárquico, ou são suas sub-árvores, caso

tenham conceitos de composição também cadastrados.

Ao contrário dos relacionamentos do tipo “é-um” (relacionamentos de

especialização), não existe uma tag específica para a representação de

relacionamentos de composição na linguagem padrão atual para ontologias

adotada pela W3C, a linguagem OWL (Dean et al., 2004a). Devido à esta falta de

padronização, fica a cargo do autor de ontologias o nome a ser dado para este

relacionamento. Normalmente, o nome “tem” é escolhido. “Bicicleta tem roda” é

um exemplo do relacionamento de composição entre os conceitos “bicicleta” e

“roda” (“roda” faz parte de “bicicleta”).

Na representação em árvore do relacionamento “bicicleta tem roda”, o

conceito “bicicleta” é representado como a raiz e o conceito “roda” como sua

folha. No entanto, se existir o conceito “parafuso”, que faz parte do conceito

“roda”, este seria representado como a folha da, agora, subárvore “roda”. Como

nos relacionamentos de especialização, nesta representação também existe a

propriedade de transitividade, ou seja, se o conceito “parafuso” faz parte do

conceito “roda” e este faz parte do conceito “bicicleta”, então, “parafuso” também

faz parte do conceito “bicicleta”. A Figura 53 ilustra os relacionamentos de

composição do exemplo dado.

bicicleta

roda câmbio

aro

selim

parafuso

pedal

bicicletabicicleta

rodaroda câmbiocâmbio

aroaro

selimselim

parafusoparafuso

pedalpedal

Figura 53 – Representação em árvore de relacionamentos de composição

Por não haver, atualmente, uma tag específica para a representação de

relacionamentos de composição em OWL e por seu nome não ser padronizado, a

Conclusões 99

possível árvore representada por este relacionamento não é utilizada na

comparação estrutural da estratégia elaborada para o alinhamento taxonômico de

ontologias. Isto porque sua representação automática não é trivial.

Uma implementação com heurísticas para a identificação de

relacionamentos de composição nas propriedades de uma ontologia deve ser

realizada para que estes relacionamentos possam ser utilizados na estratégia atual.

Tais heurísticas devem ser baseadas nas palavras comumente utilizadas por este

relacionamento como: “possui”, “tem”, “têm”, entre outras.

Utilização de Grafo na Comparação Estrutural

A abordagem adotada na estratégia apresentada neste trabalho é mais restrita

do que a apresentada em Noy e Musen (2001a) porque os relacionamentos entre

conceitos diferentes do tipo “é-um” não são investigados. Em Noy e Musen

(2001a), a estrutura de uma ontologia é representada como um grafo, ao passo que

na estratégia apresentada tem-se a representação como um grafo simplificado na

forma de uma árvore, representando apenas a taxonomia das ontologias a serem

alinhadas.

A substituição na comparação estrutural da estratégia da representação por

árvore pela representação por grafo possibilitaria novos alinhamentos de

relacionamentos não contemplados na estratégia atual e o uso dos resultados

conseguidos com estes alinhamentos como novos indicativos semânticos. No

entanto, esta substituição causaria um aumento razoável da complexidade da

estratégia devido ao maior número de ligações entre os conceitos a serem

analisadas.

Utilização de Axiomas

A análise da expressividade semântica das verdades das ontologias expressa

nos axiomas seria útil, por exemplo, no processo decisório de alinhamento como

mais uma condição a ser satisfeita.

Por exemplo, se existir na ontologia O1 o axioma O1A1: “todo carro

transporta pelo menos duas pessoas” e na ontologia O2 o axioma O2A1: “todo

veículo automotor transporta pelo menos duas pessoas” e os conceitos carro e

veículo automotor foram identificados como equivalentes nas etapas anteriores da

estratégia, então, a análise destes axiomas poderia confirmar a equivalência destes

conceitos.

Conclusões 100

No entanto, se na ontologia O2 também existir o axioma O2A2: “todo

veículo automotor tem velocidade média de deslocamento de 10 km/hora”, então,

a análise deste axioma poderia não confirmar a equivalência dos conceitos carro e

veículo automotor. Isto porque pode não haver equivalência do axioma O2A2

com axioma algum de O1 ou existir a informação em um axioma qualquer de O1

que carros possuem velocidade média de deslocamento superior a 10 km/hora.

Utilização da Estratégia em Sistemas Multi-Agentes

A estratégia apresentada neste trabalho poderia ser exposta a casos reais de

sistemas multi-agentes para: analisar seus resultados, identificar novos problemas

e necessidades, tentar resolver as lacunas da implementação da solução de forma a

torná-la mais genérica possível e explorar algumas das oportunidades de pesquisa

já identificadas.

O plano inicial para explorar a estratégia em casos reais de sistemas multi-

agentes é a criação de uma solução mais apurada, com o uso de ontologias, para o

problema tratado em (Magalhães, 2002). O trabalho em questão implementa um

sistema multi-agentes para a busca e classificação de documentos textuais de um

domínio específico. Tal busca e classificação baseiam-se em palavras-chave como

a maioria dos mecanismos de buscas da Internet, não tirando proveito, por

exemplo, do poder semântico que se tem com o uso de ontologias. Acredita-se ter

aí uma oportunidade de melhoria significativa na solução do problema com o uso

do CATO. Com o uso deste componente, nem a busca nem a classificação seriam

apenas por palavras-chave, mas sim, também pelas equivalências encontradas na

ontologia local e nas ontologias onde as buscas e classificações são realizadas.

Dependendo de quão equivalentes duas ontologias sejam, resultado conseguido

com a aplicação do CATO, tem-se a classificação dos documentos em categorias

específicas.

6 Referências Bibliográficas

ARTICULATION SERVICE. Articulation Service, Version 0.2. Disponível em: <http://codip.grci.com/Tools/ArtiServicePage.html>. Acesso em Junho de 2004.

ATLAS. Agent Transaction Language for Advertising Services. Disponível em: <http://www.daml.ri.cmu.edu>. Acesso em Junho de 2004.

BERGMANN, U. Evolução de Cenários Através de um Mecanismo de Rastreamento Baseado em Transformações. Tese de Doutorado do Departamento de Informática da PUC-Rio, 2002.

BERNERS-LEE, T. B. Rules and Facts: Inference engines vs Web. Nota [On-line]. Última modificação: Janeiro de 2000a. Disponível em: <http://www.w3.org/DesignIssues/Rules.html>. Acesso em Junho de 2004.

BERNERS-LEE, T. B. Building the future. Disponível em: <http://www.w3.org/2000/Talks/0906-xmlweb-tbl/slide9-6.html>. Apresentação titulada: XML and the Web, realizada no ano de 2000b. Acesso em Junho de 2004.

BERNERS-LEE, T.; HENDLER, J.; LASSILA, O. The Semantic Web. Scientific American 284(5), p. 34-43, Maio de 2001. Disponível em: <http://www.sciam.com/article.cfm?articleID=00048144-10D2-1C70-84A9809EC588EF21>. Acesso em Junho de 2004.

BOUQUET, P.; SERAFINI, L.; ZANOBINI, S. Semantic Coordination: A New Approach and an Application. In: INTERNATIONAL SEMANTIC WEB CONFERENCE, 2.2003, Florida. Anais do International Semantic Web Conference. Florida, 2003. p. 130-143.

BREITMAN, K. K.; Leite, J.C.S.P. Lexicon Based Ontology Construction. In: C. Lucena, C.; Garcia, A.; Romanovsky, A.; Castro, J.; Alencar, P.S.C. (Eds), Software Engineering for Multi-Agent Systems II. Springer-Verlag, LNCS 2940, Janeiro, 2004, ISBN: 3-540-21182-9, p. 19-34.

BRICKLEY, D. Resource Description Framework (RDF) Vocabulary Description Language 1.0: RDF Schema. Recomendação da W3C a partir de 10 de Fevereiro de 2004. Disponível em: <http://www.w3.org/TR/rdf-schema/>. Acesso em Junho de 2004.

BURANARACH, M. The Foundation for Semantic Interoperability on the World Wide Web. PhD Thesis. Department of Information Science and Telecommunications School of Information Sciences, University of Pittsburgh, Novembro, 2001.

CMU. Carnegie Mellon University. Disponível em: <http://www.cmu.edu/>. Acesso em Junho de 2004a.

Referências Bibliográficas 102

CMU. The Robotics Institute. Disponível em: <http://www.ri.cmu.edu/>. Acesso em Junho de 2004b.

CMU. The Intelligent Software Agents Lab. Disponível em: <http://www-2.cs.cmu.edu/~softagents/>. Acesso em Junho de 2004c.

CMU. CMU RI Publications Ontology, Id: cmu-ri-publications-ont.daml, version 0.1, 2001/08/27. Disponível em <http://www.daml.ri.cmu.edu/ont/homework/cmu-ri-publications-ont.daml>. Acesso em Junho de 2004d.

CMU. CMU RI Employment Categories Ontology. Id: cmu-ri-employmenttypes-ont.daml, version 0.1, 2001/08/27. Disponível em <http://www.daml.ri.cmu.edu/ont/homework/cmu-ri-employmenttypes-ont.daml>. Acesso em Junho de 2004e.

CONNOLLY, D.; HARMELEN, F. v.; HORROCKS, I.; MCGUINNESS, D. L.; PATEL-SCHNEIDER, P. F.; STEIN, L. A. DAML+OIL (March 2001) Reference Description. 2001. Disponível em: <http://www.w3.org/TR/daml+oil-reference>. Acesso em Junho de 2004.

DAML. The DARPA Agent Markup Language Homepage. Disponível em: <http://www.daml.org/>. Acesso em Junho de 2004.

DAML ONTOLOGY LIBRARY. Version from April, 2004. Disponível em: <http://www.daml.org/ontologies/>. Acesso em Junho de 2004.

DAML TOOLS. Version 1.257. Disponível em: <http://www.daml.org/tools/>. Acesso em Junho de 2004.

DEAN, M.; SCHREIBER, G.; BECHHOFER, S.; HARMELEN, F. v.; HENDLER, J.; HORROCKS, I.; MCGUINNESS, D. L.; PATEL-SCHNEIDER, P. F.; STEIN, L. A. OWL Web Ontology Language Reference. Recomendação da W3C a partir de 10 de Fevereiro de 2004. Disponível em: <http://www.w3.org/TR/owl-ref/>. Acesso em Maio de 2004a.

DEAN. OWL Web Ontology Language Use Cases and Requirements. Disponível em: <http://www.w3.org/TR/webont-req/>. Acesso em Junho de 2004b.

DECKER, S., MELNIK, S.; HARMELEN, F. v.; FENSEL, D.; KLEIN, M.; BROEKSTRA, J.; ERDMANN, M.; HORROCKS, I. The Semantic Web: The roles of XML and RDF. IEEE Internet Computing, 4, p. 63-73, 2000. Disponível em: <http://www.ida.liu.se/~asmpa/courses/sweb/rdf/roles_of_xml_and_rdf.pdf>. Acesso em Julho de 2004.

DFKI. German Research Center for Artificial Intelligence. Disponível em: <http://www.dfki.de/relaunch/>. Acesso em Junho de 2004.

DOAN, A., MADHAVAN, J.; DHAMANKAR, R.; DOMINGOS, P.; HALEVY, A. Learning to match ontologies on the Semantic Web. In: The VLDB Journal — The International Journal on Very Large Data Bases, v. 12, n. 4, p. 303–319, ISSN:1066-8888, Novembro de 2003.

DOM. W3C Document Object Model (DOM). Disponível em: <http://www.w3.org/DOM/>. Acesso em Junho de 2004.


FELICÍSSIMO, C. H; SILVA, L. F. S.; BREITMAN, K. K.; LEITE, J. C. S. P. Geração de Ontologias subsidiada pela Engenharia de Requisitos. In: WORKSHOP EM ENGENHARIA DE REQUISITOS, 6. 2003a, Piracicaba. Anais do Workshop em Engenharia de Requisitos. Piracicaba, São Paulo, 2003a. p. 255-269.

FELICÍSSIMO, C. H. Projeto de Programação para o Curso de Mestrado do Programa de Pós-Graduação do Departamento de Informática da PUC-Rio. Dezembro de 2003b.

FELLBAUM, C. WordNet: An electronic Lexical Database. Cambridge, MA, MIT Press, 1998. Versão para download do WordNet disponível em: <http://www.cogsci.princeton.edu/~wn/>. Acesso em Julho de 2004.

FELLBAUM. Person in WordNet. Disponível em: <http://xmlns.com/wordnet/1.6/Person>. Acesso em Junho de 2004.

FENSEL, D. Ontologies: A Silver Bullet for Knowledge Management and Electronic Commerce. Springer Verlag, 2001.

GOMEZ-PEREZ, A.; FERNÁNDEZ-LÓPEZ, M.; CORCHO, O. Ontological Engineering with examples from the areas of Knowledge Management, e-Commerce and the Semantic Web. Series: Advanced Information and Knowledge Processing, 2004, XII, 403 p. 159 illus., Hardcover ISBN: 1-85233-551-3.

GOOGLE. Google Directory, Published Ontologies. Disponível em: <http://directory.google.com/Top/Reference/Knowledge_Management/Knowledge_Representation/Ontologies/Published_Ontologies/>. Acesso em Junho de 2004.

GRUBER, T. R. A translation approach to portable ontology specifications. Knowledge Acquisition, v. 5, n. 2, p. 199-220, ISSN:1042-8143, Junho de 1993.

HAENDCHEN, F. A.; STAA, A. v.; LUCENA, C. P. A Component-Based Model for Building Reliable Multi-Agent Systems. In: SEW - NASA/IEEE SOFTWARE ENGINEERING WORKSHOP, 28. 2003, Los Alamitos. Anais do SEW - NASA/IEEE Software Engineering Workshop. Los Alamitos, 2003.

HENDLER, J. Agents and the Semantic Web. In: IEEE Intelligent Systems, v. 16, n. 2, Março/Abril, 2001, p.30-37.

HORROCKS, I.; PATEL-SCHNEIDER, P. F.; HARMELEN, F. v. From SHIQ and RDF to OWL: The Making of a Web Ontology Language. In: Journal of Web Semantics, 1(1), 2003. p. 7-26.

HP. HP Labs Semantic Web Research. Disponível em: <http://www.hpl.hp.com/semweb/>. Acesso em Junho de 2004.

HTML. HyperText Markup Language (HTML) Home Page. Disponível em: <http://www.w3.org/MarkUp/>. Acesso em Junho de 2004.

IST-PRIZE. The European IST Prize, Information Society Technologies. Disponível em: <http://www.ist-prize.org/>. Acesso em Junho de 2004.

JAVA. The JavaTM Virtual Machine Specification. Second Edition. LINDHOLM, T., YELLIN, F. 1999. Disponível em: <http://java.sun.com/docs/books/vmspec/2nd-edition/html/VMSpecTOC.doc.html>. Acesso em Junho de 2004.


JAVA. The Java Language Specification. Second Edition. GOSLING, J.; JOY, B.; STEELE, G.; BRACHA, G. 2000. Disponível em: <http://java.sun.com/docs/books/jls/second_edition/html/j.title.doc.html>. Acesso em Junho de 2004.

JENA. Jena - A Semantic Web Framework for Java. Disponível em: <http://jena.sourceforge.net/>. Acesso em Junho de 2004a.

JENA. Jena 2 Ontology API. Disponível em: <http://jena.sourceforge.net/ontology/>. Acesso em Junho de 2004b.

LEITE, J.C.S.P., FRANCO, A.P.M. A Strategy for Conceptual Model Acquisition. In: INTERNATIONAL SYMPOSIUM ON REQUIREMENTS ENGINEERING, 1. 1993. Anais do International Symposium on Requirements Engineering, IEEE Computer Society Press, 1993. p. 243-246.

MAEDCHE, A. S. Discovering Conceptual Relations from Text. Techical Report 400, University of Karlsruhe, Institute AIFB, 76128 Karlsruhe, Germany. Fevereiro de 2000. Disponível em <http://www.aifb.uni-karlsruhe.de/Publikationen/showPublikationen?id_db=50> Acesso em Maio de 2004.

MAEDCHE, A. Ontology Learning for the Sematic Web. Livro, Kluwer Academic Publishers, 2002, ISBN: 0792376560.

MAGALHÃES, J. Um Framework Multi-Agentes para Busca e Flexibilização de Algoritmos de Classsificação de Documentos. Dissertação de Mestrado, PUC-Rio, 2002.

MILLER, E.; MANOLA, F.; MCBRIDE, B. Resource Description Framework (RDF) Primer. Recomendação da W3C a partir de 10 de Fevereiro de 2004. Disponível em: <http://www.w3.org/TR/rdf-primer/>. Acesso em Junho de 2004.

MONDECA. A Semantic Knowledge Company. Disponível em: <http://www.mondeca.com>. Acesso em Junho de 2004a.

MONDECA. ITM - Intelligent Topic Manager. Disponível em: <http://www.mondeca.com/technologie.htm>. Acesso em Junho de 2004b.

MONDECA. General University Ontology, version 1.2. Disponível em: <http://www.mondeca.com/owl/moses/univ.owl>. Acesso em Junho de 2004c.

MOREIRA, M. M. Integração Semântica de Sistemas de Informação. Dissertação de Mestrado, PUC-Rio, 2003.

NOKIA. Nokia Research Center. Disponível em: <http://www.nokia.com/nokia/0,8764,50249,00.html>. Acesso em Junho de 2004.

NOY, N. F., MUSEN, M. A. SMART: Automated Support for Ontology Merging and Alignment. In: WORKSHOP ON KNOWLEDGE ACQUISITION, MODELING AND MANAGEMENT, 12. 1999a, Banff. Anais do Workshop on Knowledge Acquisition, Modeling and Management. Banff, 1999a. Disponível como relatório técnico da SMI em <http://smi-web.stanford.edu/pubs/SMI_Abstracts/SMI-1999-0813.html>. Acesso em Julho de 2004.


NOY, N. F. Presentation: Ontologies and tools. 1999b. Disponível em: <http://protege.stanford.edu/publications/OntologiesAndTools/OntologiesAndTools.ppt>. Acesso em Junho de 2004.

NOY, N. F., MUSEN, M. A. Anchor-PROMPT: Using Non-Local Context for Semantic Matching. In: WORKSHOP ON ONTOLOGIES AND INFORMATION SHARING AT THE INTERNATIONAL JOINT CONFERENCE ON ARTIFICIAL INTELLIGENCE, 17. 2001a, Seattle. Anais do Workshop on Ontologies and Information Sharing at the Seventeenth International Joint Conference on Artificial Intelligence (IJCAI-2001), Seattle, 2001a. Disponível como relatório técnico da SMI em <http://smi-web.stanford.edu/pubs/SMI_Abstracts/SMI-2001-0889.html>. Acesso em Julho de 2004.

NOY, N.; MCGUINNESS, D. Ontology Development 101 – A guide to creating your first ontology. KSL Technical Report, Standford University, 2001b. Disponível em: <http://www.ksl.stanford.edu/people/dlm/papers/ontology-tutorial-noy-mcguinness-abstract.html>. Acesso em Junho de 2004.

NOY, N. F., MUSEN, M. A. The PROMPT Suite: Interactive Tools For Ontology Merging And Mapping. In: International Journal of Human-Computer Studies, 59/6. p. 983-1024. 2003. Disponível como relatório técnico da SMI em <http://smi-web.stanford.edu/pubs/SMI_Abstracts/SMI-2003-0973.html>. Acesso em Julho de 2004.

NUSEIBEH, B.; EASTERBROOK, S.; RUSSO, A. Leveraging Inconsistency in Software Development. In: IEEE Computer Society Press, v. 33, n. 4, 2000. p. 26-29.

OILED. An Ontology Editor. Disponível em: <http://oiled.man.ac.uk/>. Acesso em Junho de 2004.

OMG. Object Management Group – Agent Platform Special Interest Group: Agent Technology – Green Paper, Version 1.0, 2000. Disponível em: <http://www.objs.com/agent/agents_Green_Paper_v100.doc>. Acesso em Junho de 2004.

ONTOMERGE. OntoMerge - Ontology Translation by Merging Ontologies. Disponível em: <http://onto.cs.yale.edu:4040/ontoMerge.html>. Acesso em Junho de 2004.

OPEN SOURCE. Open Source Initiative - OSI. Disponível em: <http://www.opensource.org/>. Acesso em Junho de 2004.

OPENCYC. Open source version of the Cyc technology. Disponível em: <http://www.opencyc.org/>. Acesso em Junho de 2004.

PINTO, S. H.; GOMEZ-PEREZ, A. G.; MARTINS, J. P. Some Issues on Ontology Integration. In: WORKSHOP ON ONTOLOGIES AND PROBLEM SOLVING METHODS: LESSONS LEARNED AND FUTURE TRENDS. 1999. Anais do Workshop on Ontologies and Problem Solving Methods: Lessons Learned and Future Trends (IJCAI99's), 1999.

PROTEGE. Protégé Project. Disponível em: <http://protege.stanford.edu/>. Acesso em Junho de 2004a.


PROTEGE. Protégé Contributions Library. Disponível em: <http://protege.stanford.edu/plugins.html/>. Acesso em Junho de 2004b.

PROTEGE. Protégé PROMPT Plug-In. Disponível em: <http://protege.stanford.edu/plugins/prompt/prompt.html/>. Acesso em Junho de 2004c.

RESNIK, P. Knowledge maintenance: The state of the art. In Proceedings of IJCAI, p. 448-453, Montreal, Canada, 1995.

RICHARDSON, R.; SMEATON, A. F.; MURPHY, J. Using WordNet as Knowledge Base for Measuring Semantic Similarity between Words. Technical Report CA-1294, Dublin City University, School of Computer Applications, 1994.

SCHEMAWEB. Browse SchemaWeb Directory. Disponível em: <http://www.schemaweb.info/schema/BrowseSchema.aspx>. Acesso em Junho de 2004a.

SCHEMAWEB. SchemaWeb - Schema Details :: Wordnet Person. Disponível em: <http://www.schemaweb.info/schema/SchemaDetails.aspx?id=25>. Acesso em Junho de 2004b.

SEMANTICWEB. Semantic Web Activity. Disponível em: <http://www.w3.org/2001/sw>. Acesso em Junho de 2004.

SIKORA, Z. M. <JAVA> GUIA PRÁTICO PARA PROGRAMADORES. Editora Campus Ltda. 2003.

SMITH, M. K.; WELTY, C.; MCGUINNESS, D. L. OWL Web Ontology Language Guide. Recomendação da W3C a partir de 10 de Fevereiro de 2004. Disponível em: <http://www.w3.org/TR/owl-guide/>. Acesso em Maio de 2004.

SOWA, J. Ontology. Última atualização do Web Site em Julho de 2003. Disponível em: <http://www.jfsowa.com/ontology/index.htm>. Acesso em Junho de 2004.

SUMO. Suggested Upper Merged Ontology. Disponível em: <http://ontology.teknowledge.com/>. Acesso em Junho de 2004.

SUOWG. Standard Upper Ontology Working Group. Disponível em: <http://suo.ieee.org/>. Acesso em Junho de 2004.

SWI-Prolog. What is SWI-Prolog?. Disponível em: <http://www.swi-prolog.org/>. Acesso em Junho de 2004.

TAI, K.,C. The tree-to-tree correction problem. Journal of the ACM, v. 26, n. 3, 1979, p. 422-433.

TEKNOWLEDGE. An Ontology Mapping Tool from Teknowledge Company. Disponível em: <http://einstein.teknowledge.com:8080/DAML/DAML_register.jsp?fileType=.zip&fileName=ont_mapping.zip>. Acesso em Junho de 2004.

TREEMATCHER. TreeMatcher toolkit for comparing two ordered or unordered trees. Disponível em: <http://www.cis.njit.edu/~discdb/treematcher.html>. Acesso em Junho de 2004.


USCHOLD, M. Building Ontologies: Towards a Unified Methodology. In: ANNUAL CONFERENCE OF EXPERTS SYSTEMS, 16. 1996, Cambridge. Anais do Conference of Experts Systems. Cambridge, 1996.

XML. Extensible Markup Language (XML). Disponível em: <http://www.w3.org/XML/>. Acesso em Junho de 2004.

W3CSEMANTICWEB. W3C Semantic Web Activity. Disponível em: <http://www.w3.org/2001/sw/>. Acesso em Junho de 2004.

W3CWEBONTWORKINGGROUP. W3C Web Ontology (WebOnt) Working Group. Disponível em: <http://www.w3.org/2001/sw/WebOnt/>. Acesso em Junho de 2004.

WANG, J. An Algorithm for Finding the Largest Approximately Common Substructures of Two Trees, In: IEEE Transactions on Pattern Analysis and Machine Intelligence, v. 20, n. 8. , 1998, p. 889-895.

Anexo A – Código em OWL das Ontologias do Primeiro Estudo de Caso 108

Anexo A – Código em OWL das Ontologias do Primeiro Estudo de Caso

Os códigos-fonte das ontologias de entrada do CATO deste estudo de caso

encontram-se nas próximas páginas. Os códigos-fonte das ontologias de saída,

dos módulos sem e com ordenação alfabética, podem ser obtidos nos seguintes

endereços eletrônicos:

Ontologia de saída do módulo sem ordenação alfabética

http://www.inf.puc-rio.br/~cfelicissimo/frstSolCombPropFinalFile.owl

Ontologia de saída do módulo com ordenação alfabética

http://www.inf.puc-rio.br/~cfelicissimo/frstSolCombPropFinalFileOd.owl

Primeira Ontologia de entrada

<rdf:RDF xmlns:owl="http://www.w3.org/2002/07/owl#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:xsd="http://www.w3.org/2001/XMLSchema#"> <owl:Ontology rdf:about=""/> <owl:Class rdf:ID="Bibtex_Publication_Type"/> <owl:Class rdf:ID="misc"> <rdfs:subClassOf rdf:resource="#Bibtex_Publication_Type"/> </owl:Class> <owl:Class rdf:ID="Center"/> <owl:Class rdf:ID="InConference"> <owl:disjointWith> <owl:Class rdf:about="#TechReport"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Misc"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Unpublished" rdf:type="http://www.w3.org/2002/07/owl#Class"/> <owl:disjointWith> <owl:Class rdf:about="#MastersThesis"/> </owl:disjointWith>


<owl:disjointWith> <owl:Class rdf:about="#Manual"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Proceedings"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#PhdThesis"/> </owl:disjointWith> </owl:Class> <owl:Class rdf:ID="Misc"> <owl:disjointWith> <owl:Class rdf:about="#TechReport"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Unpublished"/> <owl:disjointWith> <owl:Class rdf:about="#Proceedings"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#PhdThesis"/> </owl:disjointWith> </owl:Class> <owl:Class rdf:ID="MastersThesis"> <owl:disjointWith> <owl:Class rdf:about="#TechReport"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Misc"/> <owl:disjointWith rdf:resource="#Unpublished"/> <owl:disjointWith> <owl:Class rdf:about="#Proceedings"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#PhdThesis"/> </owl:disjointWith> <rdfs:subClassOf rdf:resource="#Bibtex_Publication_Type"/> </owl:Class> <owl:Class rdf:ID="Conference"> <owl:disjointWith> <owl:Class rdf:about="#TechReport"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Misc"/> <owl:disjointWith rdf:resource="#Unpublished"/> <owl:disjointWith> <owl:Class rdf:about="#InBook"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#MastersThesis"/> <owl:disjointWith rdf:resource="#InConference"/> <owl:disjointWith> <owl:Class rdf:about="#Manual"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Proceedings"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#PhdThesis"/> </owl:disjointWith> </owl:Class>


<owl:Class rdf:ID="Article"> <owl:disjointWith> <owl:Class rdf:about="#TechReport"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Conference"/> <owl:disjointWith rdf:resource="#Misc"/> <owl:disjointWith rdf:resource="#Unpublished"/> <owl:disjointWith> <owl:Class rdf:about="#InBook"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#MastersThesis"/> <owl:disjointWith rdf:resource="#InConference"/> <owl:disjointWith> <owl:Class rdf:about="#Manual"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Proceedings"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#PhdThesis"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Book"/> </owl:disjointWith> <rdfs:subClassOf rdf:resource="#Bibtex_Publication_Type"/> <owl:disjointWith> <owl:Class rdf:about="#Booklet"/> </owl:disjointWith> </owl:Class> <owl:Class rdf:ID="CMU_Publication_Entry"/> <owl:Class rdf:ID="TechReport"> <owl:disjointWith rdf:resource="#Unpublished"/> <rdfs:subClassOf rdf:resource="#Bibtex_Publication_Type"/> </owl:Class> <owl:Class rdf:ID="Bibtex_Entry"/> <owl:Class rdf:ID="InBook"> <owl:disjointWith rdf:resource="#TechReport"/> <owl:disjointWith rdf:resource="#Misc"/> <owl:disjointWith rdf:resource="#Unpublished"/> <owl:disjointWith rdf:resource="#MastersThesis"/> <owl:disjointWith rdf:resource="#InConference"/> <owl:disjointWith> <owl:Class rdf:about="#Manual"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Proceedings"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#PhdThesis"/> </owl:disjointWith> <rdfs:subClassOf rdf:resource="#Bibtex_Publication_Type"/> </owl:Class> <owl:Class rdf:ID="BibtexEntry"/> <owl:Class rdf:ID="Booklet"> <owl:disjointWith rdf:resource="#TechReport"/>


<owl:disjointWith rdf:resource="#Conference"/> <owl:disjointWith rdf:resource="#Misc"/> <owl:disjointWith rdf:resource="#Unpublished"/> <owl:disjointWith rdf:resource="#InBook"/> <owl:disjointWith rdf:resource="#MastersThesis"/> <owl:disjointWith rdf:resource="#InConference"/> <owl:disjointWith> <owl:Class rdf:about="#Manual"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Proceedings"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#PhdThesis"/> </owl:disjointWith> <rdfs:subClassOf rdf:resource="#Bibtex_Publication_Type"/> </owl:Class> <owl:Class rdf:ID="Lab"/> <owl:Class rdf:ID="unpublished"> <rdfs:subClassOf rdf:resource="#Bibtex_Publication_Type"/> </owl:Class> <owl:Class rdf:ID="Literal"/> <owl:Class rdf:ID="InCollection"> <rdfs:subClassOf rdf:resource="#Bibtex_Publication_Type"/> </owl:Class> <owl:Class rdf:ID="PhdThesis"> <owl:disjointWith rdf:resource="#TechReport"/> <owl:disjointWith rdf:resource="#Unpublished"/> <owl:disjointWith> <owl:Class rdf:about="#Proceedings"/> </owl:disjointWith> <rdfs:subClassOf rdf:resource="#Bibtex_Publication_Type"/> </owl:Class> <owl:Class rdf:ID="Project"/> <owl:Class rdf:ID="Book"> <owl:disjointWith rdf:resource="#TechReport"/> <owl:disjointWith rdf:resource="#Conference"/> <owl:disjointWith rdf:resource="#Misc"/> <owl:disjointWith rdf:resource="#Unpublished"/> <owl:disjointWith rdf:resource="#InBook"/> <owl:disjointWith rdf:resource="#MastersThesis"/> <owl:disjointWith rdf:resource="#InConference"/> <owl:disjointWith> <owl:Class rdf:about="#Manual"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Proceedings"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#PhdThesis"/> <rdfs:subClassOf rdf:resource="#Bibtex_Publication_Type"/> <owl:disjointWith rdf:resource="#Booklet"/> </owl:Class> <owl:Class rdf:ID="CMU_Publictaion_Entry"/>


<owl:Class rdf:ID="Manual"> <owl:disjointWith rdf:resource="#TechReport"/> <owl:disjointWith rdf:resource="#Misc"/> <owl:disjointWith rdf:resource="#Unpublished"/> <owl:disjointWith rdf:resource="#MastersThesis"/> <owl:disjointWith> <owl:Class rdf:about="#Proceedings"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#PhdThesis"/> <rdfs:subClassOf rdf:resource="#Bibtex_Publication_Type"/> </owl:Class> <owl:Class rdf:ID="Proceedings"> <owl:disjointWith rdf:resource="#TechReport"/> <owl:disjointWith rdf:resource="#Unpublished"/> <rdfs:subClassOf rdf:resource="#Bibtex_Publication_Type"/> </owl:Class> <owl:ObjectProperty rdf:ID="hasBibtexEntry"> <rdfs:range rdf:resource="#BibtexEntry"/> <rdfs:domain rdf:resource="#CMU_Publictaion_Entry"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasSeries"> <rdfs:domain rdf:resource="#Bibtex_Publication_Type"/> <rdfs:range rdf:resource="#Literal"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasPages"> <rdfs:domain rdf:resource="#Bibtex_Publication_Type"/> <rdfs:range rdf:resource="#Literal"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasOrganization"> <rdfs:domain rdf:resource="#Bibtex_Publication_Type"/> <rdfs:range rdf:resource="#Literal"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasNote"> <rdfs:domain rdf:resource="#Bibtex_Publication_Type"/> <rdfs:range rdf:resource="#Literal"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasPublication_Type"> <rdfs:domain rdf:resource="#Bibtex_Entry"/> <rdfs:range rdf:resource="#Bibtex_Publication_Type"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasVolume"> <rdfs:domain rdf:resource="#Bibtex_Publication_Type"/> <rdfs:range rdf:resource="#Literal"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasMonth"> <rdfs:domain rdf:resource="#Bibtex_Publication_Type"/> <rdfs:range rdf:resource="#Literal"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasType"> <rdfs:domain rdf:resource="#Bibtex_Publication_Type"/>


<rdfs:range rdf:resource="#Literal"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasAuthor"> <rdfs:domain rdf:resource="#Bibtex_Publication_Type"/> <rdfs:range rdf:resource="#Literal"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasURL"> <rdfs:domain rdf:resource="#CMU_Publictaion_Entry"/> <rdfs:range rdf:resource="#Literal"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasGrantID"> <rdfs:domain rdf:resource="#CMU_Publictaion_Entry"/> <rdfs:range rdf:resource="#Literal"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasSchool"> <rdfs:domain rdf:resource="#Bibtex_Publication_Type"/> <rdfs:range rdf:resource="#Literal"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasChapter"> <rdfs:domain rdf:resource="#Bibtex_Publication_Type"/> <rdfs:range rdf:resource="#Literal"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasYear"> <rdfs:domain rdf:resource="#Bibtex_Publication_Type"/> <rdfs:range rdf:resource="#Literal"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasKey"> <rdfs:domain rdf:resource="#Bibtex_Publication_Type"/> <rdfs:range rdf:resource="#Literal"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasAnnote"> <rdfs:domain rdf:resource="#Bibtex_Publication_Type"/> <rdfs:range rdf:resource="#Literal"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasInstitution"> <rdfs:domain rdf:resource="#Bibtex_Publication_Type"/> <rdfs:range rdf:resource="#Literal"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasJournal"> <rdfs:domain rdf:resource="#Bibtex_Publication_Type"/> <rdfs:range rdf:resource="#Literal"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasNumber"> <rdfs:domain rdf:resource="#Bibtex_Publication_Type"/> <rdfs:range rdf:resource="#Literal"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasAssociatedLabGroup"> <rdfs:range rdf:resource="#Lab"/> <rdfs:domain rdf:resource="#CMU_Publictaion_Entry"/>


<rdfs:range rdf:resource="#Literal"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasPublisher"> <rdfs:domain rdf:resource="#Bibtex_Publication_Type"/> <rdfs:range rdf:resource="#Literal"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasHowpublished"> <rdfs:domain rdf:resource="#Bibtex_Publication_Type"/> <rdfs:range rdf:resource="#Literal"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasEditor"> <rdfs:domain rdf:resource="#Bibtex_Publication_Type"/> <rdfs:range rdf:resource="#Literal"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasAddress"> <rdfs:domain rdf:resource="#Bibtex_Publication_Type"/> <rdfs:range rdf:resource="#Literal"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasAssociatedProject"> <rdfs:range rdf:resource="#Project"/> <rdfs:domain rdf:resource="#CMU_Publictaion_Entry"/> <rdfs:range rdf:resource="#Literal"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasBooktitle"> <rdfs:domain rdf:resource="#Bibtex_Publication_Type"/> <rdfs:range rdf:resource="#Literal"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasAssociatedCenter"> <rdfs:domain rdf:resource="#CMU_Publictaion_Entry"/> <rdfs:range rdf:resource="#Center"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasEdition"> <rdfs:domain rdf:resource="#Bibtex_Publication_Type"/> <rdfs:range rdf:resource="#Literal"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasSponsor"> <rdfs:domain rdf:resource="#CMU_Publictaion_Entry"/> <rdfs:range rdf:resource="#Literal"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasCiteKey"> <rdfs:domain rdf:resource="#Bibtex_Entry"/> <rdfs:range rdf:resource="#Literal"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasCrossref"> <rdfs:domain rdf:resource="#Bibtex_Publication_Type"/> <rdfs:range rdf:resource="#Literal"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasTitle"> <rdfs:domain rdf:resource="#Bibtex_Publication_Type"/>


<rdfs:range rdf:resource="#Literal"/> </owl:ObjectProperty> </rdf:RDF> Segunda Ontologia de entrada

<rdf:RDF xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:owl="http://www.w3.org/2002/07/owl#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"> <owl:Ontology dc:date="2003-10-20" dc:format="text/xml" dc:language="en" dc:publisher="Mondeca" rdf:about="http://www.mondeca.com/owl/moses/univ.owl"> <owl:versionInfo>version 1.2</owl:versionInfo> <owl:priorVersion rdf:resource="http://www.mondeca.com/owl/univ1_1.xml"/> <dc:title>General University Ontology</dc:title> <dc:creator>Bernard Vatant</dc:creator> <dc:description>General and University Ontology</dc:description> <dc:identifier>http://www.mondeca.com/owl/moses/univ.owl</dc:identifier> <dc:source>http://www.cs.umd.edu/projects/plus/DAML/onts/univ1.0.daml</dc:source> </owl:Ontology> <owl:Class rdf:ID="Director"> <rdfs:subClassOf> <owl:Class rdf:about="#AdministrativeStaff"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Discussion"> <rdfs:subClassOf> <owl:Class rdf:about="#Correspondence"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="researchProject"> <rdfs:subClassOf rdf:resource="#Association" rdf:type="http://www.w3.org/2002/07/owl#Class"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#researchProjectSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#ResearchGroup"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#researchProjectObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Research"/> </owl:allValuesFrom>


</owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Article"> <rdfs:subClassOf> <owl:Class rdf:about="#Publication"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="workAddress"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#workAddressSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Person"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#workAddressObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Address"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="AssociateProfessor"> <rdfs:subClassOf> <owl:Class rdf:about="#Professor"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="orgAddress"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#orgAddressSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Organization"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#orgAddressObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Address"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Individual"> <owl:sameAs rdf:resource="http://www.mondeca.com/owl/otm.xml#Individual"/> <rdfs:subClassOf> <owl:Class rdf:about="#Subject"/> </rdfs:subClassOf>


</owl:Class> <owl:Class rdf:ID="isLocated"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#isLocatedSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Organization"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#isLocatedObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Location"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="PhysicalObject"> <rdfs:subClassOf rdf:resource="#Individual"/> </owl:Class> <owl:Class rdf:ID="Specification"> <rdfs:subClassOf> <owl:Class rdf:about="#Publication"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="communicator"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#communicatorSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Communication"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#communicatorObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Agent"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Lexicalization"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#occuring" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Subject"/> </owl:allValuesFrom>


</owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#inDocument" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Document"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#form" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Lexical"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="WebPage"> <rdfs:subClassOf> <owl:Class rdf:about="#WebResource"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Email"> <rdfs:subClassOf> <owl:Class rdf:about="#Correspondence"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="NonprofitOrganization"> <rdfs:subClassOf> <owl:Class rdf:about="#Organization"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Video"> <rdfs:subClassOf> <owl:Class rdf:about="#WebResource"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Minutes"> <rdfs:subClassOf> <owl:Class rdf:about="#Document"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="listedCourse"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#listedCourseSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Schedule"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction>


<owl:onProperty rdf:resource="#listedCourseObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Course"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Schedule"> <rdfs:subClassOf rdf:resource="#Individual"/> </owl:Class> <owl:Class rdf:ID="DocumentRepresentation"> <rdfs:subClassOf> <owl:Class rdf:about="#Artifact"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Correspondence"> <rdfs:subClassOf> <owl:Class rdf:about="#Document"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Professor"> <rdfs:subClassOf> <owl:Class rdf:about="#Faculty"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Manuscript"> <rdfs:subClassOf> <owl:Class rdf:about="#Document"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="TechnicalReport"> <rdfs:subClassOf> <owl:Class rdf:about="#Publication"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="advisor"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#advisorSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Student"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#advisorObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom rdf:resource="#Professor"/> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="recipient"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#recipientSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/>


<owl:allValuesFrom> <owl:Class rdf:about="#Communication"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#recipientObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Agent"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Work"> <rdfs:subClassOf> <owl:Class rdf:about="#Activity"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="researchInterest"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#researchInterestSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Person"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#researchInterestObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Research"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="authorOrg"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#authorOrgSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Document"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#authorOrgObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Organization"/> </owl:allValuesFrom>


</owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Recreation"> <rdfs:subClassOf> <owl:Class rdf:about="#Activity"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="affiliateOf"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#affiliateOfSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Organization"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#affiliateOfObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Person"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="participant"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#participantSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Event"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#participantObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Agent"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="ResearchAssistant"> <rdfs:subClassOf> <owl:Class rdf:about="#Assistant"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Department"> <rdfs:subClassOf> <owl:Class rdf:about="#EducationOrganization"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Guideline">


<rdfs:subClassOf> <owl:Class rdf:about="#Document"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Dean"> <rdfs:subClassOf rdf:resource="#Professor"/> <rdfs:subClassOf> <owl:Class rdf:about="#AdministrativeStaff"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="AdministrativeStaff"> <rdfs:subClassOf> <owl:Class rdf:about="#Employee"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="teachingAssistantOf"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#teachingAssistantOfSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#TeachingAssistant"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#teachingAssistantOfObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Course"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="affiliatedOrganization"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#affiliatedOrganizationSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Organization"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#affiliatedOrganizationObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Organization"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> </owl:Class>


<owl:Class rdf:ID="Institute"> <rdfs:subClassOf> <owl:Class rdf:about="#EducationOrganization"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Subject"> <owl:sameAs rdf:resource="http://www.mondeca.com/owl/otm.xml#Subject"/> </owl:Class> <owl:Class rdf:ID="University"> <rdfs:subClassOf> <owl:Class rdf:about="#EducationOrganization"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Program"> <rdfs:subClassOf> <owl:Class rdf:about="#EducationOrganization"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Index"> <rdfs:subClassOf> <owl:Class rdf:about="#Document"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="School"> <rdfs:subClassOf> <owl:Class rdf:about="#EducationOrganization"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Regulation"> <rdfs:subClassOf> <owl:Class rdf:about="#Publication"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Event"> <rdfs:subClassOf rdf:resource="#Individual"/> </owl:Class> <owl:Class rdf:ID="Review"> <rdfs:subClassOf> <owl:Class rdf:about="#Document"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Activity"> <rdfs:subClassOf rdf:resource="#Individual"/> </owl:Class> <owl:Class rdf:ID="MastersThesis"> <rdfs:subClassOf> <owl:Class rdf:about="#Thesis"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="PostDoc"> <rdfs:subClassOf> <owl:Class rdf:about="#Faculty"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="GraduateStudent"> <rdfs:subClassOf> <owl:Class rdf:about="#Student"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="FullProfessor">


<rdfs:subClassOf rdf:resource="#Professor"/> </owl:Class> <owl:Class rdf:ID="Image"> <rdfs:subClassOf> <owl:Class rdf:about="#WebResource"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Editorial"> <rdfs:subClassOf> <owl:Class rdf:about="#Publication"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Periodical"> <rdfs:subClassOf> <owl:Class rdf:about="#Publication"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="eventLocation"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#eventLocationSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom rdf:resource="#Event"/> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#eventLocationObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Location"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="ElectronicDocument"> <rdfs:subClassOf rdf:resource="#DocumentRepresentation"/> </owl:Class> <owl:Class rdf:ID="offersCourse"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#offersCourseSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom rdf:resource="#University"/> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#offersCourseObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Course"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> </owl:Class>


<owl:Class rdf:ID="ResearchGroup"> <rdfs:subClassOf> <owl:Class rdf:about="#EducationOrganization"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="ArtificialAgent"> <rdfs:subClassOf> <owl:Class rdf:about="#Agent"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Abstract"> <rdfs:subClassOf> <owl:Class rdf:about="#Document"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="WebResource"> <rdfs:subClassOf> <owl:Class rdf:about="#Document"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Publication"> <rdfs:subClassOf> <owl:Class rdf:about="#Document"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Comment"> <rdfs:subClassOf> <owl:Class rdf:about="#Document"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Student"> <rdfs:subClassOf> <owl:Class rdf:about="#Person"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Preprint"> <rdfs:subClassOf> <owl:Class rdf:about="#Document"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="JournalArticle"> <rdfs:subClassOf rdf:resource="#Article"/> </owl:Class> <owl:Class rdf:ID="Journal"> <rdfs:subClassOf rdf:resource="#Periodical"/> </owl:Class> <owl:Class rdf:ID="mastersDegreeFrom"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#mastersDegreeFromSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Person"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction>


<owl:onProperty rdf:resource="#mastersDegreeFromObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom rdf:resource="#University"/> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Universal"> <owl:sameAs rdf:resource="http://www.mondeca.com/owl/otm.xml#Universal"/> <rdfs:subClassOf rdf:resource="#Subject"/> </owl:Class> <owl:Class rdf:ID="Location"> <rdfs:subClassOf rdf:resource="#Individual"/> </owl:Class> <owl:Class rdf:ID="OrganizationHomepage"> <rdfs:subClassOf> <owl:Class rdf:about="#HomePage"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="documentSubject"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#documentSubjectSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Document"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#documentSubjectObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom rdf:resource="#Subject"/> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="borders"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#bordersSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom rdf:resource="#Location"/> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#bordersObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom rdf:resource="#Location"/> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Proceedings"> <rdfs:subClassOf rdf:resource="#Publication"/> </owl:Class>


<owl:Class rdf:ID="HomePage"> <rdfs:subClassOf rdf:resource="#WebPage"/> </owl:Class> <owl:Class rdf:ID="PhoneCall"> <rdfs:subClassOf> <owl:Class rdf:about="#Communication"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Conference"> <rdfs:subClassOf rdf:resource="#Event"/> </owl:Class> <owl:Class rdf:ID="Software"> <rdfs:subClassOf> <owl:Class rdf:about="#Artifact"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Letter"> <rdfs:subClassOf rdf:resource="#Correspondence"/> </owl:Class> <owl:Class rdf:ID="Document"> <owl:sameAs rdf:resource="http://www.mondeca.com/owl/otm.xml#Document"/> </owl:Class> <owl:Class rdf:ID="alumnus"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#alumnusSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Organization"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#alumnusObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Person"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Speech"> <rdfs:subClassOf> <owl:Class rdf:about="#Communication"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Postcard"> <rdfs:subClassOf rdf:resource="#Correspondence"/> </owl:Class> <owl:Class rdf:ID="Research"> <rdfs:subClassOf rdf:resource="#Work"/> </owl:Class> <owl:Class rdf:ID="publicationResearch"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction>


<owl:onProperty rdf:resource="#publicationResearchSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom rdf:resource="#Publication"/> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#publicationResearchObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom rdf:resource="#Research"/> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="containedIn"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#containedInSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom rdf:resource="#Document"/> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#containedInObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom rdf:resource="#Document"/> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="TeachingAssistant"> <rdfs:subClassOf> <owl:Class rdf:about="#Assistant"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="performs"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#performsSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Person"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#performsObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom rdf:resource="#Work"/> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Magazine"> <rdfs:subClassOf rdf:resource="#Periodical"/> </owl:Class> <owl:Class rdf:ID="Lexical"> <rdfs:subClassOf rdf:resource="#Individual"/>


</owl:Class> <owl:Class rdf:ID="encloses"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#enclosesSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom rdf:resource="#Location"/> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#enclosesObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom rdf:resource="#Location"/> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Person"> <rdfs:subClassOf rdf:resource="#Individual"/> <rdfs:subClassOf> <owl:Class rdf:about="#Agent"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Communication"> <rdfs:subClassOf rdf:resource="#Event"/> </owl:Class> <owl:Class rdf:ID="Lecture"> <rdfs:subClassOf rdf:resource="#Document"/> </owl:Class> <owl:Class rdf:ID="Dictionary"> <rdfs:subClassOf rdf:resource="#Publication"/> </owl:Class> <owl:Class rdf:ID="BookArticle"> <rdfs:subClassOf rdf:resource="#Article"/> </owl:Class> <owl:Class rdf:ID="ConferencePaper"> <rdfs:subClassOf rdf:resource="#Article"/> </owl:Class> <owl:Class rdf:ID="engagesIn"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#engagesInSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Agent"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#engagesInObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom rdf:resource="#Activity"/> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="PaperDocument"> <rdfs:subClassOf rdf:resource="#DocumentRepresentation"/> </owl:Class>


<owl:Class rdf:ID="Agent"> <rdfs:subClassOf rdf:resource="#Individual"/> </owl:Class> <owl:Class rdf:ID="Lecturer"> <rdfs:subClassOf> <owl:Class rdf:about="#Faculty"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Manual"> <rdfs:subClassOf rdf:resource="#Publication"/> </owl:Class> <owl:Class rdf:ID="Newsletter"> <rdfs:subClassOf rdf:resource="#Periodical"/> </owl:Class> <owl:Class rdf:ID="Course"> <rdfs:subClassOf rdf:resource="#Work"/> </owl:Class> <owl:Class rdf:ID="AssistantProfessor"> <rdfs:subClassOf rdf:resource="#Professor"/> </owl:Class> <owl:Class rdf:ID="publisher"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#publisherSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom rdf:resource="#Document"/> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#publisherObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Organization"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Audio"> <rdfs:subClassOf rdf:resource="#WebResource"/> </owl:Class> <owl:Class rdf:ID="worksFor"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#worksForSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Employee"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#worksForObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Organization"/> </owl:allValuesFrom> </owl:Restriction>


</rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Address"> <rdfs:subClassOf rdf:resource="#Individual"/> </owl:Class> <owl:Class rdf:ID="undergraduateDegreeFrom"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#undergraduateDegreeFromSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom rdf:resource="#Person"/> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#undergraduateDegreeFromObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom rdf:resource="#University"/> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Advertisement"> <rdfs:subClassOf rdf:resource="#Publication"/> </owl:Class> <owl:Class rdf:ID="teacherOf"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#teacherOfSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Faculty"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#teacherOfObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom rdf:resource="#Course"/> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Employee"> <rdfs:subClassOf rdf:resource="#Person"/> </owl:Class> <owl:Class rdf:ID="Organism"> <rdfs:subClassOf rdf:resource="#PhysicalObject"/> </owl:Class> <owl:Class rdf:ID="head"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#headSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Organization"/> </owl:allValuesFrom>


</owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#headObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom rdf:resource="#Person"/> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="WorkshopPaper"> <rdfs:subClassOf rdf:resource="#Article"/> </owl:Class> <owl:Class rdf:ID="SocialGroup"> <rdfs:subClassOf rdf:resource="#Agent"/> </owl:Class> <owl:Class rdf:ID="CommercialOrganization"> <rdfs:subClassOf> <owl:Class rdf:about="#Organization"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Faculty"> <rdfs:subClassOf rdf:resource="#Employee"/> </owl:Class> <owl:Class rdf:ID="author"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#authorSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom rdf:resource="#Document"/> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#authorObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom rdf:resource="#Person"/> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="PersonalHomepage"> <rdfs:subClassOf rdf:resource="#HomePage"/> </owl:Class> <owl:Class rdf:ID="Artifact"> <rdfs:subClassOf rdf:resource="#PhysicalObject"/> </owl:Class> <owl:Class rdf:ID="member"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#memberSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom rdf:resource="#SocialGroup"/> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#memberObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom rdf:resource="#Person"/>


</owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Process"> <rdfs:subClassOf rdf:resource="#Activity"/> </owl:Class> <owl:Class rdf:ID="Assistant"> <rdfs:subClassOf rdf:resource="#Employee"/> </owl:Class> <owl:Class rdf:ID="subOrganizationOf"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#subOrganizationOfSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Organization"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#subOrganizationOfObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom> <owl:Class rdf:about="#Organization"/> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="EducationOrganization"> <rdfs:subClassOf> <owl:Class rdf:about="#Organization"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="DoctoralThesis"> <rdfs:subClassOf> <owl:Class rdf:about="#Thesis"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Form"> <rdfs:subClassOf rdf:resource="#Document"/> </owl:Class> <owl:Class rdf:ID="VisitingProfessor"> <rdfs:subClassOf rdf:resource="#Professor"/> </owl:Class> <owl:Class rdf:ID="Organization"> <rdfs:subClassOf rdf:resource="#SocialGroup"/> <rdfs:subClassOf rdf:resource="#Individual"/> </owl:Class> <owl:Class rdf:ID="softwareDocumentation"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#softwareDocumentationSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom rdf:resource="#Software"/> </owl:Restriction>


</rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#softwareDocumentationObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom rdf:resource="#Publication"/> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Chair"> <rdfs:subClassOf rdf:resource="#AdministrativeStaff"/> <rdfs:subClassOf rdf:resource="#Professor"/> </owl:Class> <owl:Class rdf:ID="Newspaper"> <rdfs:subClassOf rdf:resource="#Periodical"/> </owl:Class> <owl:Class rdf:ID="ClericalStaff"> <rdfs:subClassOf rdf:resource="#AdministrativeStaff"/> </owl:Class> <owl:Class rdf:ID="Promotion"> <rdfs:subClassOf rdf:resource="#Document"/> </owl:Class> <owl:Class rdf:ID="GovernmentOrganization"> <rdfs:subClassOf rdf:resource="#Organization"/> </owl:Class> <owl:Class rdf:ID="homeAddress"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#homeAddressSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom rdf:resource="#Document"/> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#homeAddressObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom rdf:resource="#Organization"/> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="SystemsStaff"> <rdfs:subClassOf rdf:resource="#AdministrativeStaff"/> </owl:Class> <owl:Class rdf:ID="Thesis"> <rdfs:subClassOf rdf:resource="#Publication"/> </owl:Class> <owl:Class rdf:ID="takesCourse"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#takesCourseSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom rdf:resource="#Student"/> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction>


<owl:onProperty rdf:resource="#takesCourseObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom rdf:resource="#Course"/> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Book"> <rdfs:subClassOf rdf:resource="#Publication"/> </owl:Class> <owl:Class rdf:ID="doctoralDegreeFrom"> <rdfs:subClassOf rdf:resource="#Association"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#doctoralDegreeFromSubject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom rdf:resource="#Person"/> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#doctoralDegreeFromObject" rdf:type="http://www.w3.org/2002/07/owl#ObjectProperty"/> <owl:allValuesFrom rdf:resource="#University"/> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="UndergraduateStudent"> <rdfs:subClassOf rdf:resource="#Student"/> </owl:Class> <owl:DatatypeProperty rdf:ID="orgPhone"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Organization"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="tenured"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Professor"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="publishDate" rdf:type="http://www.w3.org/2002/07/owl#FunctionalProperty"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Document"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="addressCity" rdf:type="http://www.w3.org/2002/07/owl#FunctionalProperty"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Address"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="eventStart" rdf:type="http://www.w3.org/2002/07/owl#FunctionalProperty"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Event"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="addressState" rdf:type="http://www.w3.org/2002/07/owl#FunctionalProperty">


<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Address"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="workPhone"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Person"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="value" rdf:type="http://www.w3.org/2002/07/owl#FunctionalProperty"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Lexical"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="homePhone"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Person"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="addressZip" rdf:type="http://www.w3.org/2002/07/owl#FunctionalProperty"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Address"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="softwareVersion"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Software"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="addressStreet" rdf:type="http://www.w3.org/2002/07/owl#FunctionalProperty"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Address"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="title" rdf:type="http://www.w3.org/2002/07/owl#FunctionalProperty"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Document"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="volume" rdf:type="http://www.w3.org/2002/07/owl#FunctionalProperty"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Periodical"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="emailAddress"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Person"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="eventEnd" rdf:type="http://www.w3.org/2002/07/owl#FunctionalProperty"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Event"/> </owl:DatatypeProperty> </rdf:RDF>

Anexo B – Código em OWL das Ontologias do Segundo Estudo de Caso 137

Anexo B – Código em OWL das Ontologias do Segundo Estudo de Caso

Os códigos-fonte das ontologias de entrada do CATO deste estudo de caso e

os de sua ontologia de saída, dos módulos sem e com ordenação alfabética, podem

ser obtidos nos seguintes endereços eletrônicos:


http://www.inf.puc-rio.br/~cfelicissimo/person_WordNet_FirstOnto.owl

Segunda Ontologia de entrada

http://www.inf.puc-rio.br/~cfelicissimo/CMUSecondOnto.owl


http://www.inf.puc-rio.br/~cfelicissimo/scdSolCombPropFinalFile.owl


http://www.inf.puc-rio.br/~cfelicissimo/scdSolCombPropFinalFileOd.owl

Anexo C – Código em OWL das Ontologias do Terceiro Estudo de Caso

Anexo C – Código em OWL das Ontologias do Terceiro Estudo de Caso

Os códigos-fonte das ontologias de entrada do CATO deste estudo de caso e

os de sua ontologia de saída, dos módulos sem e com ordenação alfabética, podem

ser obtidos nos seguintes endereços eletrônicos:


http://www.inf.puc-rio.br/~cfelicissimo/vehicle_SUMO_firstOnto.owl

Segunda Ontologia de entrada

http://www.inf.puc-rio.br/~cfelicissimo/vehicle_CYC_secondOnto.owl


http://www.inf.puc-rio.br/~cfelicissimo/thdSolCombPropFinalFile.owl


http://www.inf.puc-rio.br/~cfelicissimo/thdSolCombPropFinalFileOd.owl

Anexo D – Informações dos Métodos do CATO

Anexo D – Informações dos Métodos do CATO

Os métodos implementados no CATO são apresentado a seguir. Os métodos

específicos da implementação utilizada do algoritmo TreeDiff podem ser

encontrados em (Bergmann, 2002).

1. Método “leOnto”. É encontrado nas classes nomeadas “SolCombSinonimos”,

“SolCombSinonimosWithOrderNodes” e “LastStepSolCombSinonimos”.

• Descrição: responsável pela criação de um modelo orientado a

objetos do tipo OWL a partir de uma ontologia escrita nesta

linguagem.

• Parâmetro de entrada:

o String ontoFileName: nome do arquivo da ontologia escrita

na linguagem OWL.

• Valor retornado:

o OntModel ontModelObj: modelo da ontologia

2. Método “comparacaoSintaticaEUsoDeSinonimos”. É encontrado nas classes

nomeadas “SolCombSinonimos” e “SolCombSinonimosWithOrderNodes”.

• Descrição: responsável pela comparação lexical de cada conceito e

de seu respectivo sinônimo de uma dada ontologia com cada

conceito de uma outra dada ontologia. Em um primeiro momento,

compara-se os nomes de conceitos; em um segundo momento,

compara-se seus sinônimos, caso estes estejam cadastrados no banco

de dados utilizado.

• Parâmetros de entrada:

o OntModel ontModelObjFirstOntology: modelo da primeira

ontologia.

o OntModel ontModelObjSecondOntology: modelo da segunda

ontologia.

o String nameSpaceOnt1: namespace da primeira ontologia.

o String nameSpaceOnt2: namespace da segunda ontologia.



o OntModel ontModelObjAux: modelo da ontologia não

analisada acrescentado com as ligações para os conceitos

equivalentes da ontologia analisada.

3. Método “hashTableForSuperClassInformationEquivalentClassReplaced”. É

encontrado nas classes nomeadas “SolCombSinonimos”,

“SolCombSinonimosWithOrderNodes” e “LastStepSolCombSinonimos”.

• Descrição: responsável pela inserção de conceitos de uma dada

ontologia em uma estrutura de dados auxiliar. Substitui, caso haja,

os nomes de conceitos equivalentes por seus sinônimos para facilitar

a comparação hierárquica. Caso os conceitos equivalentes

encontram-se nas duas ontologias, após a substituição de um dos

conceitos equivalente por seu sinônimo, os conceitos equivalentes

são removidos da estrutura de dados auxiliar utilizada.


o OntModel ontModelObj: modelo da ontologia.

o String nameSpaceOnt: namespace da ontologia.


o hashTableForSuperClassInformation: estrutura de dados do

tipo tabela Hash que armazena conceitos e seus respectivos

conceitos pais (um nível hierárquico acima) nos seus campos

chaves e conteúdos, respectivamente.

4. Método “equivalentClassInformation”. É encontrado nas classes nomeadas

“SolCombSinonimos”, “SolCombSinonimosWithOrderNodes” e

“LastStepSolCombSinonimos”.

• Descrição: responsável pela inserção de conceitos de uma ontologia

e de seus conceitos equivalentes, encontrados em uma outra

ontologia, em uma estrutura de dados auxiliar.


o OntModel ontModelObj: modelo da ontologia.


o HashTable hashTableForEquivalentClassInformation:

estrutura de dados do tipo tabela Hash que armazena


conceitos e seus conceitos equivalentes nos seus campos

chaves e conteúdos, respectivamente.

5. Método “buildTagsXML”. É encontrado nas classes nomeadas

“SolCombSinonimos” e “SolCombSinonimosWithOrderNodes”.

• Descrição: responsável pela representação da estrutura hierárquica

de uma dada ontologia em arquivo do tipo XML.



na linguagem OWL.



o String result: variável auxiliar que armazena em tags XML a

estrutura hierárquica de uma ontologia analisada.

6. Método “buildSubClassTags”. É encontrado nas classes nomeadas

“SolCombSinonimos” e “SolCombSinonimosWithOrderNodes”.

• Descrição: responsável pela representação da estrutura hierárquica

dos sub-conceitos de um conceito analisado de uma ontologia. A

criação desta estrutura hierárquica é recursiva, ou seja, continua até

quando nenhum sub-conceito é mais encontrado.


o String className: nome do conceito a ter seus sub-conceitos

armazenados em tags XML.

o String bufferString: variável auxiliar que armazena as tags

XML já criadas.


na linguagem OWL.



o String result: variável auxiliar que armazena em tags XML a

estrutura hierárquica da ontologia analisada.

7. Método “mostraInfoDaOnto”. É encontrado nas classes nomeadas




• Descrição: responsável pela exibição de cada uma das seguintes

informações de uma dada ontologia: URI de seu conceito, URI de

seu conceito pai (um nível hierárquico acima), URI de seu conceito

avô (dois níveis hierárquicos acima), instâncias, URI do conceito

equivalente, URI do conceito pai do conceito equivalente, URI do

avô do conceito equivalente.


o OntModel ontModelObj: modelo de uma dada ontologia.


o Informação na tela.

8. Método “compare”. É encontrado na classe nomeada

“trace.view.DOMComparatorViewWithoutInterface”.

• Descrição: responsável pela comparação estrutural das hierarquias

de duas árvores dadas.




9. Método “showSimilarities”. É encontrado na classe nomeada

“trace.view.DOMComparatorViewWithoutInterface”.

• Descrição: responsável pela exibição dos conceitos identificados

como similares.




10. Método “LastUpdateEquivalentClass”. É encontrado nas classes nomeadas



• Descrição: responsável pela inserção de novos conceitos

equivalentes nos arquivos “congelados” da primeira etapa da

estratégia e pela geração da ontologia de saída, resultado do CATO.


o OntModel ontModelObjVar1: modelo da primeira ontologia.

o OntModel ontModelObjVar2: modelo da segunda ontologia.


o String nameSpaceFirstOnt: namespace da primeira

ontologia.

o String nameSpaceSecondOnt: namespace da segunda

ontologia.


o OntModel ontModelObjVar2.union(ontModelObjVar1):

união dos modelos das duas ontologias.

11. Método “open”. É encontrado na classe nomeada “BDQuery”.

• Descrição: responsável pela conexão com o banco de dados

utilizado.



o Booleano true ou false: retorna verdadeiro se a conexão foi

aberta com o banco de dados com sucesso e falso, caso

contrário.

12. Método “close”. É encontrado na classe nomeada “BDQuery”.

• Descrição: responsável por fechar a conexão com o banco de dados.



13. Método “show”. É encontrado na classe nomeada “BDQuery”.

• Descrição: responsável pela identificação dos sinônimos cadastrados

no banco de dados utilizado.


o String tabela: nome da tabela do banco de dados a ser

investigada.

o String result: nome da coluna a ser investigada.

o String conceito: nome do valor da coluna a ser investigado.


o Vetor vetor: vetor com todos os sinônimos encontrados

cadastrados no banco de dados do parâmetro conceito.


Anexo E – Código em Java da Implementação do CATO

Os códigos-fonte do CATO são disponibilizados a seguir. Os códigos-fonte

específicos da implementação utilizada do algoritmo TreeDiff podem ser

encontrados em (Bergmann, 2002).

Para utilização do componente CATO e replicação dos resultados

apresentados nesta dissertação, deve-se criar um projeto em Java com as classes

descritas abaixo e executar o método “main” das classes SolCombSinonimos.java

ou SolCombSinonimosWithOrderNodes.java. Os códigos em OWL das

ontologias a serem alinhadas devem ser copiados para os arquivos “firstOnto.owl”

e “secondOnto.owl”, encontrados no mesmo diretório do projeto do CATO.

SolCombSinonimos.java e SolCombSinonimosWithOrderNodes.java

Estas duas classes só diferem pelo método nomeado “builtTagsXML”. Na

segunda classe há a função de ordenação chamada sort da linguagem Java que não

existe na primeira classe. Por isso, apenas o código-fonte da segunda classe é

disponibilizado no documento. O código-fonte da primeira classe é idêntico a este

salvo a exclusão da função sort do método “builtTagsXML”.

package cato; import java.io.BufferedReader; import java.io.File; import java.io.FileOutputStream; import java.io.FileReader; import java.io.FileWriter; import java.io.IOException; import java.util.Collections; import java.util.Enumeration; import java.util.Hashtable; import java.util.Iterator; import java.util.Vector; import com.hp.hpl.jena.ontology.OntClass; import com.hp.hpl.jena.ontology.OntModel; import com.hp.hpl.jena.ontology.OntModelSpec; import com.hp.hpl.jena.ontology.impl.OntClassImpl; import com.hp.hpl.jena.rdf.model.Model; import com.hp.hpl.jena.rdf.model.ModelFactory;


public class SolCombSinonimosVDefesaMestrado { private static String sourceDir = "file:"; private static OntModel ontModelObjAux = ModelFactory.createOntologyModel(OntModelSpec.OWL_MEM, null); private static OntModel ontModelObjAuxFirst = ModelFactory.createOntologyModel(OntModelSpec.OWL_MEM, null); private static OntModel ontModelObjAuxSecond = ModelFactory.createOntologyModel(OntModelSpec.OWL_MEM, null); //ESTRUTURA DE DADOS AUXILIAR PARA ARMAZENAR AS CLASSES EQUIVALENTES DAS DUAS ONTOLOGIAS. private static Hashtable hashTableForEquivalentClassInformation = new Hashtable(); public static OntModel leOnto(String ontoFileName) { OntModel ontModelObj = ModelFactory.createOntologyModel(OntModelSpec.OWL_MEM, null); ontModelObj.getDocumentManager().addAltEntry(sourceDir + ontoFileName, sourceDir + ontoFileName); ontModelObj.read(sourceDir + ontoFileName); return ontModelObj; } public static OntModel comparacaoSintaticaEUsoDeSinonimos(OntModel ontModelObjFirstOntology, OntModel ontModelObjSecondOntology, String nameSpaceOnt1, String nameSpaceOnt2) { if (BDQuery.open() == false) { System.out.println("Erro abrindo conexao"); } else { //CONSEGUIU ABRIR A CONEXAO COM O BANCO DE DADOS. //***INICIO: INICIALIZACAO DAS VARIAVEIS UTILIZADAS NA FUNCAO:*** OntClass aClass = null; String nameSpaceObj = null; String nameSpaceObjSynonym = null; Hashtable hashTableForSecondOntologyNames = new Hashtable(); Hashtable hashTableForSecondOntologySuperClassNames = new Hashtable(); Hashtable hashTableForSecondOntologySuperSuperClassNames = new Hashtable(); Hashtable hashTableForSecondOntologyInstances = new Hashtable(); boolean allConditionsForEquivalentClasses = false; Iterator iteratorB = ontModelObjSecondOntology.listClasses(); while ( iteratorB.hasNext() ) {


OntClassImpl ontObjSecondOntology = (OntClassImpl) iteratorB.next(); if ((ontObjSecondOntology.getNameSpace() != null) && (ontObjSecondOntology.getNameSpace()).equals(nameSpaceOnt2)) { if (ontObjSecondOntology.getLocalName() != null) { String ontObjSecondOntologyName = ontObjSecondOntology.getLocalName().trim(); hashTableForSecondOntologyNames.put(ontObjSecondOntologyName, ontObjSecondOntologyName); if (ontObjSecondOntology.getSuperClass() != null) { String ontObjSecondOntologySuperClassName = ontObjSecondOntology.getSuperClass().getLocalName(); if (ontObjSecondOntologySuperClassName != null) { ontObjSecondOntologySuperClassName = ontObjSecondOntologySuperClassName.trim(); hashTableForSecondOntologySuperClassNames.put(ontObjSecondOntologyName,ontObjSecondOntologySuperClassName); if (ontObjSecondOntology.getSuperClass().getSuperClass()!= null) { String ontObjSecondOntologySuperSuperClassName = ontObjSecondOntology.getSuperClass().getSuperClass().getLocalName(); if (ontObjSecondOntologySuperSuperClassName!= null) { ontObjSecondOntologySuperSuperClassName = ontObjSecondOntologySuperSuperClassName.trim(); hashTableForSecondOntologySuperSuperClassNames.put(ontObjSecondOntologyName, ontObjSecondOntologySuperSuperClassName); } else { hashTableForSecondOntologySuperSuperClassNames.put(ontObjSecondOntologyName,"***semAvo***"); } } } } else { hashTableForSecondOntologySuperClassNames.put(ontObjSecondOntologyName, "***semPai***"); hashTableForSecondOntologySuperSuperClassNames.put(ontObjSecondOntologyName, "***semAvo***"); }


if (ontObjSecondOntology.listInstances() != null) { for (Iterator iteratorI = ontObjSecondOntology.listInstances(); iteratorI.hasNext();) { Object secondOntologyInstance = (Object) iteratorI.next(); int aux = secondOntologyInstance.toString().indexOf("#"); if (aux >= 0) { String secondOntologyInstanceName = (secondOntologyInstance.toString().substring(aux)).trim(); hashTableForSecondOntologyInstances.put(secondOntologyInstanceName, ontObjSecondOntologyName); } } } } } } Iterator iteratorA = ontModelObjFirstOntology.listClasses(); while (iteratorA.hasNext()) { OntClassImpl ontObjFirstOntology = (OntClassImpl) iteratorA.next(); if ( (ontObjFirstOntology.getNameSpace() != null) && (ontObjFirstOntology.getNameSpace()).equals(nameSpaceOnt1) ) { if (ontObjFirstOntology.getLocalName() != null) { String ontObjFirstOntologyName = ontObjFirstOntology.getLocalName(); ontObjFirstOntologyName = ontObjFirstOntologyName.trim(); if (hashTableForSecondOntologyNames.get(ontObjFirstOntologyName) != null) { nameSpaceObj = ontObjFirstOntology.getNameSpace(); if ( (nameSpaceObj != null) && (nameSpaceObj.equals(nameSpaceOnt1)) ) { nameSpaceObjSynonym = nameSpaceOnt2; } else { nameSpaceObjSynonym = nameSpaceOnt1; } if ( (ontObjFirstOntology.getSuperClass() != null) && (hashTableForSecondOntologySuperClassNames.get(ontObjFirstOntologyName) != "***semPai***") ) {


String ontObjFirstOntologySuperClassName = ontObjFirstOntology.getSuperClass().getLocalName(); if (ontObjFirstOntologySuperClassName != null) { ontObjFirstOntologySuperClassName = ontObjFirstOntologySuperClassName.trim(); if ( (ontObjFirstOntology.getSuperClass().getSuperClass() != null) && (hashTableForSecondOntologySuperSuperClassNames.get(ontObjFirstOntologyName) != "***semAvo***") ) { String ontObjFirstOntologySuperSuperClassName = ontObjFirstOntology.getSuperClass().getSuperClass().getLocalName(); if (ontObjFirstOntologySuperSuperClassName != null) { ontObjFirstOntologySuperSuperClassName = ontObjFirstOntologySuperSuperClassName.trim(); if ( (hashTableForSecondOntologySuperClassNames.get(ontObjFirstOntologyName) != null) && (hashTableForSecondOntologySuperClassNames.get(ontObjFirstOntologyName).equals(ontObjFirstOntologySuperClassName)) ) { if ( (hashTableForSecondOntologySuperSuperClassNames.get(ontObjFirstOntologyName) != null) && (hashTableForSecondOntologySuperSuperClassNames.get(ontObjFirstOntologyName).equals(ontObjFirstOntologySuperSuperClassName)) ) { for (Iterator iteratorI = ontObjFirstOntology.listInstances();iteratorI.hasNext();) { Object firstOntologyInstance = (Object) iteratorI.next(); int aux = firstOntologyInstance.toString().indexOf("#"); if (aux >= 0) { String firstOntologyInstanceName = (firstOntologyInstance.toString().substring(aux)).trim(); if (hashTableForSecondOntologyInstances.get(firstOntologyInstanceName) == null)


{ allConditionsForEquivalentClasses = false; } else { allConditionsForEquivalentClasses = true; } } if (allConditionsForEquivalentClasses) { aClass = ontModelObjSecondOntology.createClass(nameSpaceObjSynonym + ontObjFirstOntologyName); aClass.addEquivalentClass(ontObjFirstOntology); } } if (allConditionsForEquivalentClasses) { aClass = ontModelObjSecondOntology.createClass(nameSpaceObjSynonym + ontObjFirstOntologyName); aClass.addEquivalentClass(ontObjFirstOntology); } } } } } } } } Vector result = BDQuery.show("Sinonimo", "tblSinonimos", ontObjFirstOntologyName); try { if (!result.isEmpty()) { System.out.println("Sinonimos de " + ontObjFirstOntology.getURI() + ": " + result); Iterator syn = result.iterator(); while (syn.hasNext()) { String sinonimoTermo = (String) syn.next(); if (sinonimoTermo != null) {


sinonimoTermo = sinonimoTermo.trim(); if (hashTableForSecondOntologyNames.get(sinonimoTermo) != null) { nameSpaceObj = ontObjFirstOntology.getNameSpace(); if ( (nameSpaceObj != null) && (nameSpaceObj.equals(nameSpaceOnt1)) ) { nameSpaceObjSynonym = nameSpaceOnt2; } else { nameSpaceObjSynonym = nameSpaceOnt1; } if ( (ontObjFirstOntology.getSuperClass() != null) && (hashTableForSecondOntologySuperClassNames.get(sinonimoTermo) != "***semPai***") ) { String ontObjFirstOntologySuperClassName = ontObjFirstOntology.getSuperClass().getLocalName(); if (ontObjFirstOntologySuperClassName != null) { ontObjFirstOntologySuperClassName = ontObjFirstOntologySuperClassName.trim(); if ( (ontObjFirstOntology.getSuperClass().getSuperClass() != null ) && (hashTableForSecondOntologySuperSuperClassNames.get(sinonimoTermo) != "***semAvo***") ) { String ontObjFirstOntologySuperSuperClassName = ontObjFirstOntology.getSuperClass().getSuperClass().getLocalName(); if (ontObjFirstOntologySuperSuperClassName != null) { ontObjFirstOntologySuperSuperClassName = ontObjFirstOntologySuperSuperClassName.trim(); if ( (hashTableForSecondOntologySuperClassNames.get(sinonimoTermo) != null) && (hashTableForSecondOntologySuperClassNames.get(sinonimoTermo).equals(ontObjFirstOntologySuperClassName)) ) { if (


(hashTableForSecondOntologySuperSuperClassNames.get(sinonimoTermo) != null) && (hashTableForSecondOntologySuperSuperClassNames.get(sinonimoTermo).equals(ontObjFirstOntologySuperSuperClassName)) ) { for (Iterator iteratorI = ontObjFirstOntology.listInstances(); iteratorI.hasNext();) { Object firstOntologyInstance = (Object) iteratorI.next(); int aux = firstOntologyInstance.toString().indexOf("#"); if (aux >= 0) { String firstOntologyInstanceName = firstOntologyInstance.toString().substring(aux); if (hashTableForSecondOntologyInstances.get(firstOntologyInstanceName) == null) { allConditionsForEquivalentClasses = false; } else { allConditionsForEquivalentClasses = true; } } if (allConditionsForEquivalentClasses) { aClass = ontModelObjSecondOntology.createClass(nameSpaceObjSynonym + sinonimoTermo); aClass.addEquivalentClass(ontObjFirstOntology); } } if (allConditionsForEquivalentClasses) { aClass =


ontModelObjSecondOntology.createClass(nameSpaceObjSynonym + sinonimoTermo); aClass.addEquivalentClass(ontObjFirstOntology); } } } } } } } } } } } } catch (Exception e) { System.out.println(e.toString()); e.printStackTrace(); } } } } BDQuery.close(); ontModelObjAux = (OntModel) ontModelObjSecondOntology; } return ontModelObjAux; } public static Hashtable hashTableForSuperClassInformationEquivalentClassReplaced(OntModel ontModelObj, String nameSpaceOnt) { Hashtable hashTableForSuperClassInformation = new Hashtable(); for (Iterator iteratorA = ontModelObj.listClasses();iteratorA.hasNext();) { OntClassImpl ont = (OntClassImpl) iteratorA.next(); if ( (ont.getNameSpace() != null) && (ont.getNameSpace()).equals(nameSpaceOnt)) { if (ont.getLocalName() != null) { String classNameAndURI = (String) ont.getURI().trim(); String className = (String) ont.getLocalName().trim(); if (ont.getSuperClass() != null) { if (ont.getSuperClass().getLocalName() != null) {


String superClassNameAndURI = (String) ont.getSuperClass().getURI().trim(); String superClassName = (String) ont.getSuperClass().getLocalName().trim(); if (hashTableForEquivalentClassInformation.get(classNameAndURI) == null) { if (hashTableForEquivalentClassInformation.get(superClassNameAndURI) != null) { int auxSuperClassName = hashTableForEquivalentClassInformation.get(superClassNameAndURI).toString().indexOf("#") + 1; if (auxSuperClassName >= 0) { String contentSuperClassName = (hashTableForEquivalentClassInformation.get(superClassNameAndURI)).toString().substring(auxSuperClassName); contentSuperClassName.trim(); hashTableForSuperClassInformation.put(className, contentSuperClassName); } } else { //NAO TEM A INFORMACAO DE CLASSE EQUIVALENTE PARA A SUPER CLASSE hashTableForSuperClassInformation.put(className, superClassName); } } else { //TEM A INFORMACAO DE CLASSE EQUIVALENTE if ( hashTableForEquivalentClassInformation.get(hashTableForEquivalentClassInformation.get(classNameAndURI)) != null ) { //TEM A INFORMACAO DE CLASSE EQUIVALENTE NAS DUAS ONTOLOGIAS //Removendo as informacaos da URI e pegando apenas o nome "cru" da Classe . int auxClassName = hashTableForEquivalentClassInformation.get(classNameAndURI).toString().indexOf("#") + 1; if (auxClassName >= 0) { String contentName =(hashTableForEquivalentClassInformation.get(classNameAndURI)).toString().substring(auxClassName); contentName.trim(); //SUBSTITUI O NOME DA CLASSE PELO NOME DA SUA CLASSE EQUIVALENTE


hashTableForSuperClassInformation.put(contentName, superClassName); } hashTableForEquivalentClassInformation.remove(hashTableForEquivalentClassInformation.get(classNameAndURI)); //hashTableForEquivalentClassInformation.remove(classeAndURI); } else { //TEM A INFORMACAO DE CLASSE EQUIVALENTE EM UMA SO ONTOLOGIA if (hashTableForEquivalentClassInformation.get(superClassNameAndURI) != null) { //TEM A INFORMACAO DE CLASSE EQUIVALENTE PARA A SUPER CLASSE int auxSuperClassName = hashTableForEquivalentClassInformation.get(superClassNameAndURI).toString().indexOf("#") + 1; if (auxSuperClassName >= 0) { String contentSuperClassName = (hashTableForEquivalentClassInformation.get(superClassNameAndURI)).toString().substring(auxSuperClassName); contentSuperClassName.trim(); hashTableForSuperClassInformation.put(className, contentSuperClassName); } } else { //TEM A INFORMACAO DE CLASSE EQUIVALENTE EM UMA SO ONTOLOGIA E NAO TEM A INFORMACAO DE CLASSE EQUIVALENTE PARA A SUPER CLASSE int auxClassName = hashTableForEquivalentClassInformation.get(classNameAndURI).toString().indexOf("#") + 1; if (auxClassName >= 0) { String contentName = (hashTableForEquivalentClassInformation.get(classNameAndURI)).toString().substring(auxClassName); contentName.trim(); //SUBSTITUI O NOME DA CLASSE PELO NOME DA SUA CLASSE EQUIVALENTE hashTableForSuperClassInformation.put(contentName, superClassName); }


} } } //NAO TEM A INFORMACAO DO NOME DA SUPERCLASSE } else if ( hashTableForEquivalentClassInformation.get(classNameAndURI) == null) { hashTableForSuperClassInformation.put(className, "***semPai***"); //TEM A INFORMACAO DE CLASSE EQUIVALENTE } else { int auxClassName = (hashTableForEquivalentClassInformation.get(classNameAndURI)).toString().indexOf("#") + 1; if (auxClassName >= 0) { String contentName = (hashTableForEquivalentClassInformation.get(classNameAndURI)).toString().substring(auxClassName); contentName.trim(); //SUBSTITUI O NOME DA CLASSE PELO NOME DA SUA CLASSE EQUIVALENTE hashTableForSuperClassInformation.put(contentName, "***semPai***"); } } } else if ( hashTableForEquivalentClassInformation.get(className) == null) { hashTableForSuperClassInformation.put(className, "***semPai***"); } else { int auxClassName = (hashTableForEquivalentClassInformation.get(classNameAndURI)).toString().indexOf("#") + 1; if (auxClassName >= 0) { String contentName = (hashTableForEquivalentClassInformation.get(classNameAndURI)).toString().substring(auxClassName); contentName.trim(); //SUBSTITUI O NOME DA CLASSE PELO NOME DA SUA CLASSE EQUIVALENTE hashTableForSuperClassInformation.put(contentName, "***semPai***"); } } } } } return hashTableForSuperClassInformation;


} public static Hashtable equivalentClassInformation(OntModel ontModelObj) { Hashtable hashTableForEquivalentClassInformation = new Hashtable(); String classNameAndURI = new String(); String equivalentClassNameAndURI = new String(); for (Iterator iteratorA = ontModelObj.listClasses();iteratorA.hasNext();) { OntClassImpl ont = (OntClassImpl) iteratorA.next(); if (ont.getLocalName() != null) { classNameAndURI = ont.getURI(); classNameAndURI.trim(); } if (ont.getEquivalentClass() != null) { equivalentClassNameAndURI = ont.getEquivalentClass().getURI(); equivalentClassNameAndURI.trim(); hashTableForEquivalentClassInformation.put(classNameAndURI, equivalentClassNameAndURI); } } return hashTableForEquivalentClassInformation; } public static String buildTagsXML(String ontoFileName, String nameSpaceOnt) { String result = new String(); Vector vetorOrdenadoSubClasses = new Vector(); Vector vetorOrdenadoSubClassesNEW = new Vector(); boolean classeImportada = false; Hashtable showSecondOntoSuperClassInformation = hashTableForSuperClassInformationEquivalentClassReplaced(leOnto(ontoFileName), nameSpaceOnt); Enumeration contentSecondOnto = showSecondOntoSuperClassInformation.elements(); Enumeration keysSecondOnto = showSecondOntoSuperClassInformation.keys(); System.out.println(""); System.out.println(""); System.out.println("***CLASSES E SUPER CLASSES COM UM DOS NOMES DE CLASSE EQUIVALENTE SUBSTITUIDOS:***"); while (contentSecondOnto.hasMoreElements() && keysSecondOnto.hasMoreElements()) { String contentSecondOntoValue = (String) contentSecondOnto.nextElement(); String keySecondOntoValue = (String) keysSecondOnto.nextElement();


System.out.println("Class: " + keySecondOntoValue + " SuperClass: " + contentSecondOntoValue); if (contentSecondOntoValue.equals("***semPai***")) { vetorOrdenadoSubClasses.add(keySecondOntoValue); } else if ( !(contentSecondOntoValue.equals("***semPai***")) && (showSecondOntoSuperClassInformation.get(contentSecondOntoValue) == null) ) { vetorOrdenadoSubClassesNEW.add(keySecondOntoValue); classeImportada = true; } } if (classeImportada) { Collections.sort(vetorOrdenadoSubClassesNEW); for (Enumeration e = vetorOrdenadoSubClassesNEW.elements(); e.hasMoreElements();) { //Pega os valores das classes ordenados alfabeticamente. String newOrderKeyValue = (String) e.nextElement(); //Precisa novamente percorrer a tabela para pegar o nome das classes pais importadas. Hashtable auxShowSecondOntoSuperClassInformation = hashTableForSuperClassInformationEquivalentClassReplaced(leOnto(ontoFileName), nameSpaceOnt); Enumeration auxContentSecondOnto = auxShowSecondOntoSuperClassInformation.elements(); Enumeration auxKeysSecondOnto = auxShowSecondOntoSuperClassInformation.keys(); while ( auxContentSecondOnto.hasMoreElements() && auxKeysSecondOnto.hasMoreElements() ) { String contentSecondOntoValue = (String) auxContentSecondOnto.nextElement(); String keySecondOntoValue = (String) auxKeysSecondOnto.nextElement(); //Achou a classe que tem a superclasse importada. Recupera o nome da superclasse da Tabela com informacoes de SuperClasses. if ( newOrderKeyValue.equals(keySecondOntoValue) ) { result = result + buildSubClassTags(newOrderKeyValue, "<Classe>" + contentSecondOntoValue + "<subClasse>" + newOrderKeyValue, ontoFileName, nameSpaceOnt) + "</subClasse>" + "</Classe>"; } } } } else { //Nao tem classes importadas.


Collections.sort(vetorOrdenadoSubClasses); for (Enumeration e = vetorOrdenadoSubClasses.elements(); e.hasMoreElements();) { String newOrderKeyValue = (String) e.nextElement(); result = result + buildSubClassTags(newOrderKeyValue, "<Classe>" + newOrderKeyValue, ontoFileName, nameSpaceOnt) + "</Classe>"; } } result = "<ontoInXML>" + result + "</ontoInXML>"; System.out.println(""); System.out.println("***ESTRUTURA HIERARQUICA DA ONTOLOGIA EXPRESSA EM TAGS DO TIPO XML:***"); System.out.println(result); return result; } public static String buildSubClassTags(String className, String bufferString, String ontoFileName, String nameSpaceOnt) { Hashtable showSuperClassInformation = new Hashtable(); Vector vetorOrdenadoSubClasses = new Vector(); showSuperClassInformation = hashTableForSuperClassInformationEquivalentClassReplaced(leOnto(ontoFileName), nameSpaceOnt); Enumeration content = showSuperClassInformation.elements(); Enumeration key = showSuperClassInformation.keys(); //Com o valor da Chave, busca os conteudos while ( content.hasMoreElements() && key.hasMoreElements() ) { String newContentValue = (String) content.nextElement(); String newKeyValue = (String) key.nextElement(); if (newContentValue.equals(className)) { vetorOrdenadoSubClasses.add(newKeyValue); } } //Ordena alfabeticamente os nos Collections.sort(vetorOrdenadoSubClasses); for (Enumeration e = vetorOrdenadoSubClasses.elements(); e.hasMoreElements();) { String newOrderKeyValue = (String) e.nextElement(); bufferString = bufferString + "<subClasse>" + newOrderKeyValue;


bufferString = buildSubClassTags(newOrderKeyValue, bufferString, ontoFileName, nameSpaceOnt); bufferString = bufferString + "</subClasse>"; } return bufferString; } public static Model LastUpdateEquivalentClass(OntModel ontModelObjVar1, OntModel ontModelObjVar2, String nameSpaceFirstOnt, String nameSpaceSecondOnt) { String auxLine = ""; String className; String equivalentClassName; try { BufferedReader auxFile = new BufferedReader(new FileReader("treeDiffResults.txt")); auxLine = auxFile.readLine(); while (auxLine != null) { int auxLineNumber = auxLine.indexOf("-"); if (auxLineNumber >= 0) { className = auxLine.substring(0, auxLineNumber); equivalentClassName = auxLine.substring(auxLineNumber + 1); System.out.println("className: " + className + " --- equivalentClassName: " + equivalentClassName); System.out.println(""); //A CLASSE NAO FOI IDENTIFICADA COMO EQUIVALENTE NAS ETAPAS ANTERIORES if ( (hashTableForEquivalentClassInformation.get(nameSpaceFirstOnt + className) == null) || (hashTableForEquivalentClassInformation.get(nameSpaceSecondOnt + className) == null) ) { OntClass aClass = null; //PERCORRE A PRIMEIRA ONTOLOGIA PARA SABER SE A CLASSE EQUIVALENTE A PERTENCE Iterator iteratorA = ontModelObjVar1.listClasses(); while (iteratorA.hasNext()) { //PERCORRE CADA CLASSE DA PRIMEIRA ONTOLOGIA OntClassImpl ontObjFirstOntology = (OntClassImpl) iteratorA.next(); if ( (ontObjFirstOntology.getNameSpace() != null) && (ontObjFirstOntology.getNameSpace()).equals(nameSpaceFirstOnt) ) { //HA A NECESSIDADE DESSA VERIFICACAO PARA ONTOLOGIAS QUE IMPORTAM OUTRAS. if ( (ontObjFirstOntology.getLocalName() != null) && (ontObjFirstOntology.getLocalName().equals(className)) ) {


aClass = ontModelObjVar2.createClass(nameSpaceSecondOnt + equivalentClassName); aClass.addEquivalentClass(ontObjFirstOntology); } } } //PERCORRE A SEGUNDA ONTOLOGIA PARA SABER SE A CLASSE EQUIVALENTE A PERTENCE Iterator iteratorB = ontModelObjVar2.listClasses(); while (iteratorB.hasNext()) { //PERCORRE CADA CLASSE DA PRIMEIRA ONTOLOGIA OntClassImpl ontObjSecondOntology = (OntClassImpl) iteratorB.next(); if ( (ontObjSecondOntology.getNameSpace() != null) && (ontObjSecondOntology.getNameSpace()).equals(nameSpaceSecondOnt) ) { if ( (ontObjSecondOntology.getLocalName() != null) && (ontObjSecondOntology.getLocalName().equals(className)) ) { aClass = ontModelObjVar1.createClass(nameSpaceFirstOnt + equivalentClassName); aClass.addEquivalentClass(ontObjSecondOntology); } } } } } auxLine = auxFile.readLine(); } auxFile.close(); } catch (IOException e) { e.printStackTrace(); } return ontModelObjVar2.union(ontModelObjVar1); } public static void mostraInfoDaOnto(OntModel ontModelObj) { System.out.println(""); System.out.println(""); System.out.println("***INFORMACOES DAS CLASSES DAS ONTOLOGIAS:***"); for (Iterator iteratorA = ontModelObj.listClasses();iteratorA.hasNext();) { OntClassImpl ont = (OntClassImpl) iteratorA.next(); if (ont.getLocalName() != null) { System.out.println(""); System.out.println("URI da Classe:" + ont.getURI());


if (ont.getSuperClass() != null) { if (ont.getSuperClass().getLocalName() != null) { System.out.println("URI da Classe Pai: " + ont.getSuperClass().getURI()); if (ont.getSuperClass().getSuperClass() != null) { if (ont.getSuperClass().getSuperClass().getLocalName() != null) { System.out.println("URI da Classe Avo: " + ont.getSuperClass().getSuperClass().getURI()); } } } } } if (ont.listInstances() != null) { for (Iterator iteratorI = ont.listInstances(); iteratorI.hasNext();) { Object intances = (Object) iteratorI.next(); //System.out.println( "Instancias: " + intances ); int aux = intances.toString().indexOf("#"); if (aux >= 0) { String instanceName = intances.toString().substring(aux); System.out.println(" Instancias: " + instanceName); } } } if (ont.getEquivalentClass() != null) { System.out.println("URI da Classe Equivalente: " + ont.getEquivalentClass()); } } } public static void main(String[] args) throws IOException { OntModel ontModelObjVar1 = leOnto("firstOnto.owl"); OntModel ontModelObjVar2 = leOnto("secondOnto.owl"); ontModelObjAuxFirst = comparacaoSintaticaEUsoDeSinonimos(ontModelObjVar1, ontModelObjVar2, "file:firstOnto.owl#", "file:secondOnto.owl#"); File saidaFirstOnto = new File("newSecondOnto.owl"); FileWriter outFirstOnto = new FileWriter(saidaFirstOnto); ontModelObjAuxFirst.write(outFirstOnto, "RDF/XML-ABBREV"); ontModelObjAuxSecond = comparacaoSintaticaEUsoDeSinonimos(ontModelObjVar2, ontModelObjVar1, "file:secondOnto.owl#", "file:firstOnto.owl#"); File saidaSecondOnto = new File("newFirstOnto.owl");


FileWriter outSecondOnto = new FileWriter(saidaSecondOnto); ontModelObjAuxSecond.write(outSecondOnto, "RDF/XML-ABBREV"); Model ontModelObjAuxFinal = ontModelObjAuxFirst.union(ontModelObjAuxSecond); File saidaThirdOnto = new File("mappingOnto.owl"); saidaThirdOnto.createNewFile(); FileWriter out1 = new FileWriter(saidaThirdOnto); ontModelObjAuxFinal.write(out1, "RDF/XML-ABBREV"); mostraInfoDaOnto(leOnto("mappingOnto.owl")); System.out.println(""); System.out.println(""); System.out.println("***FIM DA PRIMEIRA ETAPA DA SOLUCAO COMBINADA PROPOSTA***"); System.out.println(""); hashTableForEquivalentClassInformation = equivalentClassInformation(leOnto("mappingOnto.owl")); String firstResult = buildTagsXML("firstOnto.owl", "file:firstOnto.owl#"); File firstForTreeDiff = new File("newFirstOntoForTreeDiff.xml"); FileOutputStream newFirstOntoForTreeDiff = new FileOutputStream(firstForTreeDiff); newFirstOntoForTreeDiff.write(firstResult.getBytes()); newFirstOntoForTreeDiff.close(); String secondResult = buildTagsXML("secondOnto.owl", "file:secondOnto.owl#"); File secondForTreeDiff = new File("newSecondOntoForTreeDiff.xml"); FileOutputStream newSecondOntoForTreeDiff = new FileOutputStream(secondForTreeDiff); newSecondOntoForTreeDiff.write(secondResult.getBytes()); newSecondOntoForTreeDiff.close(); System.out.println(""); System.out.println(""); System.out.println("***FIM DA ETAPA INTERMEDIARIA (PRIMEIRA ETAPA -> SEGUNDA ETAPA)***"); System.out.println(""); System.out.println(""); } }


BDQuery.java

package cato; import java.sql.Connection; import java.sql.DriverManager; import java.sql.ResultSet; import java.sql.SQLException; import java.sql.Statement; import java.util.Vector; public class BDQuery { private static Connection bdAccess; public static boolean open() { // Register jdbc driver: try { Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); } catch (ClassNotFoundException e) { e.printStackTrace(); return false; } // Connect to DB: try { bdAccess = DriverManager.getConnection("jdbc:odbc:CATO", "", ""); } catch (SQLException se) { se.printStackTrace(); return false; } return true; } public static void close() { try { bdAccess.close(); } catch (SQLException se) { se.printStackTrace(); } } public static Vector show(String result, String tabela, String termo) { // Do the Query: Vector vetor = new Vector(); try { String selectSQL = "select " + result + " from " + tabela + " where conceito = '" + termo + "' order by " + result; Statement stmt = bdAccess.createStatement(); ResultSet rset = stmt.executeQuery(selectSQL); while (rset.next()) { String resultado = rset.getString(1); if (resultado != null) { //Retorna resultados linha a linha: //System.out.println(resultado); vetor.add(resultado);


} } stmt.close(); } catch (SQLException se) { se.printStackTrace(); } return vetor; } // public static void main( String[] args ) { // BDQuery bdqueryobj = new BDQuery(); // System.out.println( "Sinonimos: " + ( bdqueryobj.show( "Sinonimos", "tblSinonimos", "car" ) ) ); // System.out.println( "Termos Relacionados: " + ( bdqueryobj.show( "TermosRelacionados", "tblTermosRelacionados", "car" ) ) ); // } } /*OUTRA MANEIRA PARA CONEXAO COM O BD: try { // Step 1. Load the Type 1 database driver: Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); // Step 2. Create a connection to the database // using pre-defined Data Source: Connection con = DriverManager.getConnection ("jdbc:odbc:PreDefinedDB",userid,password); // Step 3. Create a Statement object: Statement stmt = con.createStatement(); // Step 4. Build and send the database SQL query: String query = "SELECT * FROM DataTable"; // Step 5. Get the resultset from the database: ResultSet rs = stmt.executeQuery(query); // Step 6. Process the data: // ... } */


DOMComparatorViewWithoutInterface.java

package trace.view; import java.io.*; import java.util.Iterator; import java.util.Vector; import org.w3c.dom.*; import trace.delta.dom.*; import trace.result.Similarity; public class DOMComparatorViewWithoutInterface { DOMChangeManager changeManager = null; String dir = "D:/Carol/eclipse-SDK-3.0-win32/workspace/CATO/"; String left = dir + "newFirstOntoForTreeDiff.xml"; String right = dir + "newSecondOntoForTreeDiff.xml"; public void compare() { org.w3c.dom.Document aFirstDoc = null; try { ulf.dom.UlfDOMParserWrapper aux = new ulf.dom.UlfDOMParserWrapper(); aFirstDoc = aux.parse(left); ulf.dom.DOMUtilities.normalize(aFirstDoc); } catch(Exception e) { e.printStackTrace(); } org.w3c.dom.Document aSecDoc = null; try { ulf.dom.UlfDOMParserWrapper aux = new ulf.dom.UlfDOMParserWrapper(); aSecDoc = aux.parse(right); ulf.dom.DOMUtilities.normalize(aSecDoc); } catch(Exception e) { e.printStackTrace(); } FindDOMDifferenceStrategy aStrategy = new trace.delta.dom.LargestApproximatelyCommonTraceSubTree(); DOMComparator aComp = new DOMComparator(); aStrategy.setComparator(aComp); trace.delta.dom.similarity.FindAtomicSimilarity aSimStrategy = new trace.delta.dom.similarity.FindAtomicSimilarity(aComp); changeManager = new DOMChangeManager(aFirstDoc, aSecDoc, aStrategy, aSimStrategy); changeManager.findChanges(); // Adicionado changeManager.computeSimilarity(); showSimilarities();


} public void showSimilarities() { try { File saidaAuxOnto = new File(dir + "treeDiffResults.txt"); saidaAuxOnto.createNewFile(); BufferedWriter auxFile = new BufferedWriter(new FileWriter(saidaAuxOnto)); Vector armazenaSim = new Vector(); armazenaSim = changeManager.getSimilarities(); Node originalNodeName = null; System.out.println(""); System.out.println("Similarities Level:"); for (Iterator iter = armazenaSim.iterator(); iter.hasNext();) { Similarity sim = (Similarity) iter.next(); NodeList newTreeNodeList = sim.getNewTreeNode().getChildNodes(); NodeList originalTreeNodeList = sim.getOriginalTreeNode().getChildNodes(); for (int i = 0; i < newTreeNodeList.getLength(); i++) { Node originalTreeNode = (Node) originalTreeNodeList.item(i); Node newTreeNode = (Node) newTreeNodeList.item(i); if ( (originalTreeNode != null) && (newTreeNode != null) ){ if ( (originalTreeNode.getNodeValue() != null) && (newTreeNode.getNodeValue() != null) ) { System.out.println(originalTreeNode.getNodeValue() + " -> " + newTreeNode.getNodeValue() + " *** Similarity Level: " + sim.getLevel()*100 + "%"); if ( (sim.getLevel()*100) >= 75) { //ESCREVE A INFORMACAO EM UM ARQUIVO DO TIPO TEXTO PARA PASSAGEM DE INFORMACAO auxFile.write( (originalTreeNode.getNodeValue()) + "-" + (newTreeNode.getNodeValue()) ); auxFile.newLine(); } } } } } auxFile.close();


} catch (IOException e) { e.printStackTrace(); } } public static void main(java.lang.String[] args) { try { TreeDiff aDOMComparatorView = new TreeDiff(); aDOMComparatorView.compare(); } catch (Throwable exception) { exception.printStackTrace(System.out); } } }


LastStepSolCombSinonimos.java

package cato;

import java.io.BufferedReader;

import java.io.File;

import java.io.FileReader;

import java.io.FileWriter;

import java.io.IOException;

import java.util.Hashtable;

import java.util.Iterator;

import com.hp.hpl.jena.ontology.OntClass;

import com.hp.hpl.jena.ontology.OntModel;

import com.hp.hpl.jena.ontology.OntModelSpec;

import com.hp.hpl.jena.ontology.impl.OntClassImpl;

import com.hp.hpl.jena.rdf.model.Model;

import com.hp.hpl.jena.rdf.model.ModelFactory;

public class LastStepSolCombSinonimos {

private static String sourceDir = "file:";

//CRIANDO AS VARIAVEIS PARA OS MODELOS DAS ONTOLOGIAS. A

API JENA TRANSFORMA CADA ONTOLOGIA EXPRESSA EM

//UM ARQUIVO DO TIPO OWL, POR EXEMPLO, EM UM MODELO E

TRABALHA NELE. PRECISA-SE DESTA TRANSFORMACAO.

private static OntModel ontModelObjAux =

ModelFactory.createOntologyModel(OntModelSpec.OWL_MEM, null);

private static OntModel ontModelObjAuxFirst =


private static OntModel ontModelObjAuxSecond =


//ESTRUTURA DE DADOS AUXILIAR PARA ARMAZENAR AS CLASSES

EQUIVALENTES DAS DUAS ONTOLOGIAS.

private static Hashtable

hashTableForEquivalentClassInformation = new Hashtable();


//FUNCAO QUE TRANSFORMA UM ONTOLOGIA EXPRESSA EM UM ARQUIVO

DO TIPO OWL EM UM MODELO ONTOLOGICO.

//LE O ARQUIVO E RETORNA O SEU MODELO.

public static OntModel leOnto(String address) {

OntModel ontModelObj =


ontModelObj.getDocumentManager().addAltEntry(address,

address);

ontModelObj.read(sourceDir + address);

return ontModelObj;

}

//FUNCAO QUE CADASTRA EM UMA TABELA HASH NO CAMPO CHAVE O

NOME DA CLASSE E NO CAMPO CONTEUDO O NOME

//DA SUPER CLASSE. SUBSTITUI, CASO HAJA, OS NOMES DE

CLASSES EQUIVALENTES PARA FACILITAR A COMPARACAO HIERARQUICA.

public static Hashtable

hashTableForSuperClassInformationEquivalentClassReplaced(OntModel

ontModelObj, String nameSpaceOnt)

{

Hashtable hashTableForSuperClassInformation = new

Hashtable();

String classURI = new String();

String className = new String();

String superClassURI = new String();

String superClassName = new String();

for (Iterator iteratorA =

ontModelObj.listClasses();iteratorA.hasNext();)

{

OntClassImpl ont = (OntClassImpl)

iteratorA.next();

if ( (ont.getNameSpace() != null) &&

(ont.getNameSpace()).equals(nameSpaceOnt) )

{

//HA A NECESSIDADE DESSA VERIFICACAO PARA

ONTOLOGIAS QUE IMPORTAM OUTRAS.

if (ont.getLocalName() != null)

{


classURI = (String)

ont.getURI().trim();

className = (String)

ont.getLocalName().trim();

if ( (ont.getSuperClass() != null)

&& (ont.getSuperClass().getLocalName() != null) )

{

for (Iterator iteratorB =

ont.listSuperClasses(); iteratorB.hasNext();)

{

OntClassImpl ontPai =

(OntClassImpl) iteratorB.next();

if ( (ontPai != null) &&

(ontPai.getLocalName() != null) ) {

superClassURI =

(String) ontPai.getURI().trim();

superClassName =

(String) ontPai.getLocalName().trim();

if

(hashTableForEquivalentClassInformation.get(classURI) == null)

{

//NAO TEM A

INFORMACAO DE CLASSE EQUIVALENTE

if (

hashTableForEquivalentClassInformation.get(superClassURI) != null

)

{

//TEM

A INFORMACAO DE CLASSE EQUIVALENTE PARA A SUPER CLASSE

int

auxSuperClassName =

hashTableForEquivalentClassInformation.get(superClassURI).toString

().indexOf("#") + 1;

if

(auxSuperClassName >= 0)

{

String contentSuperClassName =


(hashTableForEquivalentClassInformation.get(superClassURI)).toStri

ng().substring(auxSuperClassName);

contentSuperClassName.trim();

hashTableForSuperClassInformation.put(contentSuperClassName

+ "***superClasse***" + className, contentSuperClassName);

}

} else {

//NAO

TEM A INFORMACAO DE CLASSE EQUIVALENTE PARA A SUPER CLASSE

hashTableForSuperClassInformation.put(superClassName +

"***superClasse***" + className, superClassName);

}

} else {

//TEM A

INFORMACAO DE CLASSE EQUIVALENTE

if

(hashTableForEquivalentClassInformation.get(hashTableForEquivalent

ClassInformation.get(classURI))!= null)

{

//TEM

A INFORMACAO DE CLASSE EQUIVALENTE NAS DUAS ONTOLOGIAS

//Removendo as informacaos da URI e pegando apenas o nome

"cru" da Classe .

int

auxClassName =

hashTableForEquivalentClassInformation.get(classURI).toString().in

dexOf("#") + 1;

if

(auxClassName >= 0)

{

String equivalentClassName =

(hashTableForEquivalentClassInformation.get(classURI)).toString().

substring(auxClassName);

equivalentClassName.trim();


//SUBSTITUI O NOME DA CLASSE PELO NOME DA SUA CLASSE

EQUIVALENTE


"***superClasse***" + equivalentClassName, superClassName);

}

hashTableForEquivalentClassInformation.remove(hashTableForEq

uivalentClassInformation.get(classURI));

//hashTableForEquivalentClassInformation.remove(classeAndURI

);

} else {

//TEM

A INFORMACAO DE CLASSE EQUIVALENTE EM UMA SO ONTOLOGIA

if

(hashTableForEquivalentClassInformation.get(superClassURI)!= null)

{

//TEM A INFORMACAO DE CLASSE EQUIVALENTE PARA A SUPER CLASSE

int auxSuperClassName =

hashTableForEquivalentClassInformation.get(superClassURI).toString

().indexOf("#") + 1;

if (auxSuperClassName >= 0)

{

String contentSuperClassName =

(hashTableForEquivalentClassInformation.get(superClassURI)).toStri

ng().substring(auxSuperClassName);

contentSuperClassName.trim();

hashTableForSuperClassInformation.put(contentSuperClassName

+ "***superClasse***" + className, contentSuperClassName);

}


} else

{

//TEM A INFORMACAO DE CLASSE EQUIVALENTE EM UMA SO ONTOLOGIA

E NAO TEM A INFORMACAO DE CLASSE EQUIVALENTE PARA A SUPER CLASSE

int auxClassName =

hashTableForEquivalentClassInformation.get(classURI).toString().in

dexOf("#") + 1;

if (auxClassName >= 0)

{

String contentName =



contentName.trim();

//SUBSTITUI O NOME DA CLASSE PELO NOME DA SUA CLASSE

EQUIVALENTE


"***superClasse***" + contentName, superClassName);

}

}

}

}

//NAO TEM A

INFORMACAO DO NOME DA SUPERCLASSE

} else if

(hashTableForEquivalentClassInformation.get(classURI) == null)

{

hashTableForSuperClassInformation.put("***semPai***" +

"***superClasse***" + className, "***semPai***");


//TEM A INFORMACAO

DE CLASSE EQUIVALENTE

} else

{

int auxClassName =


indexOf("#") + 1;

if (auxClassName

>= 0)

{

String

contentName =



contentName.trim();

//SUBSTITUI

O NOME DA CLASSE PELO NOME DA SUA CLASSE EQUIVALENTE


"***superClasse***" + contentName, "***semPai***");

}

}

}

} else if (

hashTableForEquivalentClassInformation.get(className) == null )

//Classe nao tem nome da SuperClasse

e nao tem classe equivalente cadastrada

{


"***superClasse***" + className, "***semPai***");

} else {

int auxClassName =


indexOf("#") + 1;

if (auxClassName >= 0)

{


String contentName =



contentName.trim();

//SUBSTITUI O NOME DA

CLASSE PELO NOME DA SUA CLASSE EQUIVALENTE


"***superClasse***" + contentName, "***semPai***");

}

}

}

}

}

return hashTableForSuperClassInformation;

}

//Funcao responsável pela inserção em uma estrutura de dados

auxiliar as informações de classes e

//classes equivalentes de uma dada ontologia. Armazena os

namespaces e os nomes das classes.

public static Hashtable equivalentClassInformation(OntModel

ontModelObj) {

Hashtable hashTableForEquivalentClassInformation = new

Hashtable();

String classNameAndURI = new String();

String equivalentClassNameAndURI = new String();

for (Iterator iteratorA = ontModelObj.listClasses();

iteratorA.hasNext();)

{


iteratorA.next();

//Recuperando as classes que possuem a

informacao de classe equivalente

if (ont.getLocalName() != null)

{

classNameAndURI = ont.getURI();


classNameAndURI.trim();

}

if (ont.getEquivalentClass() != null) {

equivalentClassNameAndURI =

ont.getEquivalentClass().getURI();

equivalentClassNameAndURI.trim();

hashTableForEquivalentClassInformation.put(classNameAndURI,

equivalentClassNameAndURI);

}

}

return hashTableForEquivalentClassInformation;

}

//FUNCAO QUE ADICIONARA AS ULTIMAS INFORMACOES DE CLASSES

EQUIVALENTES, CASO ESTAS, AINDA NAO FORAM INCLUIDAS.

public static Model LastUpdateEquivalentClass(OntModel

ontModelObjVar1, OntModel ontModelObjVar2, String

nameSpaceFirstOnt, String nameSpaceSecondOnt)

{

String auxLine = new String();

String className = new String();

String equivalentClassName = new String();

System.out.println("*** ALINHAMENTOS DO TREEDIFF:

***");

try {

BufferedReader auxFile = new BufferedReader(new

FileReader("treeDiffResults.txt"));

auxLine = auxFile.readLine();

while (auxLine != null)

{

int auxLineNumber = auxLine.indexOf("-");

if (auxLineNumber >= 0)

{

className = auxLine.substring(0,

auxLineNumber);


equivalentClassName =

auxLine.substring(auxLineNumber + 1);

System.out.println("className: " +

className + "--- equivalentClassName: " + equivalentClassName);

//A CLASSE NAO FOI IDENTIFICADA COMO

EQUIVALENTE NAS ETAPAS ANTERIORES

if (

(hashTableForEquivalentClassInformation.get(nameSpaceFirstOnt +

className) == null) ||

(hashTableForEquivalentClassInformation.get(nameSpaceSecondOnt +

className) == null) )

{

OntClass aClass = null;

//PERCORRE A PRIMEIRA

ONTOLOGIA PARA SABER SE A CLASSE EQUIVALENTE A PERTENCE

Iterator iteratorA =

ontModelObjVar1.listClasses();

while (iteratorA.hasNext())

{

//PERCORRE CADA CLASSE

DA PRIMEIRA ONTOLOGIA

OntClassImpl

ontObjFirstOntology = (OntClassImpl) iteratorA.next();

if (

(ontObjFirstOntology.getNameSpace() != null) &&

(ontObjFirstOntology.getNameSpace()).equals(nameSpaceFirstOnt) )

{

//HA A NECESSIDADE

DESSA VERIFICACAO PARA ONTOLOGIAS QUE IMPORTAM OUTRAS.

if (

(ontObjFirstOntology.getLocalName()!= null) &&

(

(ontObjFirstOntology.getLocalName().trim()).equals(className) ) )

{


aClass =

ontModelObjVar2.createClass(nameSpaceSecondOnt +

equivalentClassName);

aClass.addEquivalentClass(ontObjFirstOntology);

}

}

}

//PERCORRE A SEGUNDA ONTOLOGIA

PARA SABER SE A CLASSE EQUIVALENTE A PERTENCE

Iterator iteratorB =

ontModelObjVar2.listClasses();

while (iteratorB.hasNext())

{

//PERCORRE CADA CLASSE

DA PRIMEIRA ONTOLOGIA

OntClassImpl

ontObjSecondOntology = (OntClassImpl) iteratorB.next();

if

((ontObjSecondOntology.getNameSpace() != null) &&

(ontObjSecondOntology.getNameSpace()).equals(nameSpaceSecondOnt))

{

if (

(ontObjSecondOntology.getLocalName()!= null) &&

(

(ontObjSecondOntology.getLocalName().trim()).equals(className) ) )

{

aClass =

ontModelObjVar1.createClass(nameSpaceFirstOnt +

equivalentClassName);

aClass.addEquivalentClass(ontObjSecondOntology);

}

}

}

}

}

auxLine = auxFile.readLine();

}

auxFile.close();


} catch (IOException e)

{

e.printStackTrace();

}

return ontModelObjVar2.union(ontModelObjVar1);

}

//FUNCAO QUE IMPRIMI ALGUMAS INFORMACOES DAS DUAS ONTOLOGIAS

NA CONSOLE DO AMBIENTE

public static void mostraInfoDaOnto(OntModel ontModelObj) {

System.out.println("");


System.out.println("***INFORMACOES DAS CLASSES

EQUIVALENTES DAS ONTOLOGIAS:***");

for (Iterator iteratorA =

ontModelObj.listClasses();iteratorA.hasNext();)

{


iteratorA.next();

if (ont.getEquivalentClass() != null) {

System.out.println("URI da Classe

Equivalente: " + ont.getEquivalentClass());

if (ont.getLocalName() != null) {

System.out.println("URI da Classe:"

+ ont.getURI());


}

}

}

}

public static void main(String[] args) throws IOException {

//TEM QUE CHAMAR NOVAMENTE PORQUE AO CONSTRUIR A

ESTRUTURA HIERARQUICA EM XML, ALGUM NOME DE CLASSE


//EQUIVALENTE QUE EXISTIA NAS DUAS ONTOLOGIAS PODE TER

SIDO APAGADO.

hashTableForEquivalentClassInformation = null;

hashTableForEquivalentClassInformation =

equivalentClassInformation(leOnto("mappingOnto.owl"));

//RECUPERA OS ARQUIVOS "CONGELADOS" DA PRIMEIRA ETAPA.

Model ontModelObjFinalResult =

LastUpdateEquivalentClass(leOnto("newFirstOnto.owl"),

leOnto("newSecondOnto.owl"), "file:firstOnto.owl#",

"file:secondOnto.owl#");

//ARMAZENA A INFORMACAO DOS DOIS MODELOS DAS DUAS

ONTOLOGIAS DE ENTRADA.

//ADICIONA AS IMPORTACOES NECESSARIAS PARA EFETIVAR O

ALINHAMENTO. SEM ISSO, SO TEM OS NAMESPACES SEM A IDENTIFICACAO

DO SEU RECURSO (ARQUIVO OU HTTP).

Model modelAux = leOnto("cabecalho.owl");

ontModelObjFinalResult =

ontModelObjFinalResult.add(modelAux);

//Escreve um arquivo do tipo *.owl das duas ontologia

com seus nós Enriquecidos;

File saidaFinalOnto = new

File("solCombPropFinalFile.owl");

saidaFinalOnto.createNewFile();

FileWriter outFinal = new FileWriter(saidaFinalOnto);

ontModelObjFinalResult.write(outFinal, "RDF/XML-

ABBREV");

mostraInfoDaOnto(leOnto("solCombPropFinalFile.owl"));

}

}

Documents

Carolina Howard Felicíssimojulio/CAROL.pdf · Felicíssimo, Carolina Howard; Leite, Julio Cesar Sampaio do Prado; Breitman, Karin Koogan. Interoperabilidade Semântica na Web: Uma