marcos magalhães moreira integração semântica de …

Marcos Magalhães Moreira

Integração Semântica de Sistemas de

Informação

Dissertação de Mestrado

Dissertação apresentada como requisito parcial para obtenção do título de Mestre pelo Programa de Pós-Graduação em Informática da PUC-Rio.

Orientador: Prof. Marco Antonio Casanova

Rio de Janeiro, agosto de 2003


Integração Semântica de Sistemas de

Informação

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. Marco Antonio Casanova Orientador

Departartamento de Informática - PUC-Rio

Prof. Daniel Schwabe Departartamento de Informática - PUC-Rio

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

Prof. Ney Dumont Coordenador Setorial do Centro

Técnico Científico - PUC-Rio

Rio de Janeiro, 8 de agosto de 2003

Todos os direitos reservados. É proibida a reprodução total

ou parcial do trabalho sem autorização da universidade, do autor e do orientador.


Graduou-se em Engenharia Civil pela Escola de Engenharia da Universidade Federal do Rio de Janeiro em 1986. Ingressou na Petrobras em 1989, onde participou do Curso de Formação de Analista de Sistemas. Desde então, tem atuado como analista de sistemas, participando de vários projetos de desenvolvimento e integração de sistemas de informação na área de E&P – Exploração de Produção de Petróleo. Em 2001, ingressou no presente programa de Mestrado em Informática, que se encontra agora em conclusão.

Ficha Catalográfica

Moreira, Marcos Magalhães

descrição...

informação técnica...

natureza...

Incluí referências bibliográficas.

Integração; Sistemas de Informação; Ontologia; Interoperabilidade; Semântica

Dedico a todos os meus familiares e, em

especial, ao meu filho Mateus.

Agradecimentos

À Petrobras, ao meu Orientador, aos meus familiares, aos amigos, aos colegas e a

todos aqueles que direta ou indiretamente contribuíram para o desenvolvimento

deste trabalho, meus sinceros agradecimentos.

Resumo

Moreira, Marcos Magalhães. Integração Semântica de Sistemas de Informação. Rio de Janeiro, 2003. 128p. Dissertação de Mestrado - Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro.

Propõe-se neste trabalho uma abordagem para a integração semântica de

informações baseada na linguagem de ontologia OWL, utilizada como linguagem

padrão para tornar compatíveis as diversas fontes de informação. Inicialmente,

apresenta-se o problema de integração de informações e discute-se a aplicação de

ontologia para resolvê-lo. Em seguida, identificam-se as formas de obtenção e

extração de ontologias, com ênfase em sistemas de banco de dados. Da mesma

forma, propõem-se alternativas para mapeamento entre classes, propriedades e

instâncias das ontologias obtidas. Finalmente, desenvolve-se um estudo de caso

para aplicação e validação das idéias apresentadas. Como resultado, propõe-se

uma arquitetura de um sistema integrador e discute-se a implementação de alguns

dos seus componentes.

Palavras-chave

Integração de Informação; Integração Semântica; Sistemas de Informação;

Ontologias; Interoperabilidade Semântica.

Abstract

Moreira, Marcos Magalhães. Semantic Integration of Information Systems. Rio de Janeiro, 2003. 128p. MSc. Dissertation - Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro

This work presents a semantic approach to information integration based on

the OWL ontology language, proposed as a standard language to facilitate the

integration of different information sources. The information integration problem

is first presented and then the use of ontologies to solve it is addressed. Then,

strategies to obtain and extract ontologies are identified, emphasizing database

systems. Alternative mappings between classes, properties and instances of the

resulting ontologies are also proposed. Finally, a case study is developed to apply

and validate the strategies presented. As a result, an integrator system architecture

is proposed and the implementation of some of its components is discussed.

Keywords

Information Integration; Semantic Integration; Information Systems;

Ontology; Semantic Interoperability.

Sumário

1 Introdução 11

2 Preliminares 15

2.1. Integração de Sistemas 15

2.2. Ontologias 18

2.3. Linguagens de Ontologias 20

2.3.1. DAML e OIL 21

2.3.2. DAML+OIL 22

3 OWL – Web Ontology Language 25

3.1. Introdução 25

3.2. Estrutura das Ontologias OWL 27

3.3. Definições Básicas 31

3.3.1. Definindo Hierarquia de Classes 31

3.3.2. Definindo Indivíduos 34

3.3.3. Definindo Propriedades 35

4 Explicitando Ontologias de Sistemas 40

4.1. Fontes de Ontologias 40

4.2. Modelos Baseados em Classes 42

4.2.1. Discussão 42

4.2.2. Do Modelo UML 44

4.2.3. Do Modelo Entidade-Relacionamento 45

4.2.4. Do Modelo Relacional 45

4.3. Documentos Semi-estruturados 47

4.4. Documentos Não Estruturados 48

5 Interconectando Ontologias 49

5.1. Interoperabilidade Semântica 49

5.2. Princípios para o Mapeamento de Conceitos 54

5.3. Criando Articulações entre Ontologias 56

5.4. Mapeando Ontologias em OWL 57

5.5. Expressões de Classes em OWL 60

5.6. Categorias de Mapeamento 63

6 Estudo de Caso 69

6.1. Introdução 69

6.2. Mapeamento das Instalações 70

6.3. Mapeamento das Atividades 72

6.4. Mapeamento dos Equipamentos 75

6.5. Avaliação 77

7 Arquitetura de Implementação 79

7.1. Visão Geral 79

7.2. Modelo Wrapper/Mediator 81

7.3. Editor OWL 82

7.4. Wrapper Oracle 84

8 Conclusão 86

8.1. Contribuições 86

8.2. Trabalhos Futuros 87

9 Referências Bibliográficas 88

Anexo A – Norma N-1710 96

Anexo B – Modulo de Anormalidade em Poços do SIP 113

Anexo C – Mapeamento entre a N-1710 e o SIP 123

Lista de figuras

Figura 1 – Construtores de classe em DAML+OIL 22

Figura 2 - Axiomas em DAML+OIL 23

Figura 3 – Explicitando ontologias de sistemas de informação 42

Figura 4 – Interconectando ontologias de sistemas de informação 52

Figura 5 – Agregação e Generalização de Conceitos 55

Figura 6 – Similaridade entre conceitos e relações 56

Figura 7 – Mapeamento de Instalações 71

Figura 8 – Mapeamento de Atividades 75

Figura 9 – Mapeamento de Equipamentos 76

Figura 10 – Arquitetura padrão de integração 79

Figura 11 – Arquitetura para interconexão de sistemas de informação 80

Figura 12 – Modelo Wrapper/Mediator 81

Figura 13 – Editor OWL 83

Figura 14 – Wrapper Oracle 84

Introdução 11

1 Introdução

Nos últimos anos, a disseminação dos mais variados sistemas de informação

tornou de importância crucial o conhecimento do significado real das informações

disponibilizadas. Neste cenário, para possibilitar acesso à semântica destas

informações, a aplicação de ontologias é cada vez mais considerada como

mecanismo chave. Muitas aplicações fazem uso desta abordagem, como por

exemplo: sistemas de gerência do conhecimento, sistemas de integração de

informações, sistemas baseados em agentes, etc. Especialmente depois que a idéia

de Web Semântica foi introduzida por Tim Berners-Lee (Berners-Lee, 1998a 1999

2001 2002ab), na qual o conteúdo das páginas passa a ser marcado com

metadados baseados em ontologias, o interesse no desenvolvimento de aplicações

relacionadas a ontologia cresceu significativamente.

Muitas linguagens de ontologia tem sido desenvolvidas, cada qual buscando

resolver um aspecto particular da modelagem conceitual. Algumas delas, como

RDF (Resource Description Framework) (W3C, 2003abcd), são linguagens

simples que oferecem suporte elementar na modelagem de ontologias para a Web

Semântica. Outras são linguagens mais complexas, baseadas em lógica formal,

focadas em inferência, que permitem a dedução de fatos que não estejam

explicitamente presentes no modelo, como F-logic (Kifer, 1990). Por outro lado,

vários tipos de linguagens baseadas em Description Logics, por exemplo, OIL –

Ontology Inference Layer, concentram-se em um subconjunto apropriado de

sentenças da lógica de primeira ordem (Fensel, 2001).

Apesar da intensa pesquisa sobre ontologias, funcionalidades padronizadas e

amplamente utilizadas pela comunidade de sistemas de banco de dados devem ser

adaptadas e reimplementadas para sistemas baseados em lógica como, por

exemplo, crescimento em escala, confiabilidade, concorrência e controle de

transações.

Introdução 12

Por outro lado, a tecnologia de banco de dados, por si só, não é apropriada

para manipular informações baseadas em ontologias. Isto se deve principalmente

ao fato da modelagem conceitual de banco de dados ser transformada num modelo

lógico durante a fase de implantação. Após esta transformação, a estrutura e a

intenção do modelo original deixam de ser óbvias. Deste modo, os modelos

conceitual e lógico tendem a divergir. Além disto, operações naturais sobre o

modelo conceitual, como navegação entre entidades, não são tão imediatas no

modelo lógico (Motik, 2002).

Em algumas situações, o termo ontologia é somente uma outra forma para

denotar o resultado de atividades como analise conceitual e modelagem de

domínio, executadas por meio de metodologias padronizadas. Contudo, em muitos

casos, as denominadas ontologias apresentam suas próprias peculiaridades quanto

à metodologia e arquitetura. No aspecto metodológico, a principal peculiaridade

está na adoção de uma abordagem altamente interdisciplinar, onde filosofia e

lingüística desempenham um papel fundamental na análise da estrutura de uma

dada realidade, num nível elevado de generalização e na formulação de um

vocabulário limpo e rigoroso. Do lado arquitetural, o aspecto mais interessante

está no papel central que uma ontologia pode ter num sistema de informação,

levando a perspectiva de sistemas de informações orientados a ontologias

(Guarino, 1998).

Este trabalho propõe uma abordagem para a integração semântica de

sistemas de informação baseada na linguagem de ontologia OWL, utilizada como

linguagem padrão para tornar compatíveis as diversas fontes de informação. As

formas de obtenção e extração de ontologias são identificadas, com ênfase em

sistemas de banco de dados. Da mesma forma, alternativas para mapeamento entre

classes, propriedades e instâncias das ontologias obtidas são propostas. Ao final,

uma arquitetura para um sistema integrador é apresentada e a implementação de

alguns dos seus componentes é discutida.

Vários trabalhos relacionados com a integração de dados de fontes

heterogêneas têm sido desenvolvidos nos últimos anos. O Stanford-IBM Manager

Introdução 13

of Multiple Information Sources (TSIMMIS) (Chawathe, 1994) é um sistema

federativo baseado numa arquitetura mediated-wrapper estruturado sobre um

modelo de troca de objetos (OEM – Object Exchange Model) que não oferece

uma camada de ontologia (Papakonstantinou, 1995). O Information Manifold

System da AT&T Bell (Levy, 1996b), por sua vez, utiliza o modelo entidade-

relacionamento estendido com características de orientação a objeto (hierarquia de

conceitos) para representação de ontologias, que são codificadas através de

cláusulas de Horn e da description logic CLASSIC (Kirk, 1995). Da mesma

forma, o Services and Information Management for Decision System (SIMS)

(Arens, 1993) baseia-se em uma ontologia global, onde termos, atributos e

propriedades são definidos e representados na forma de uma description logic

denominada LOOM. O Ontology Based System Enhanced with Relationships for

Vocabulary heterogeneity Resolution (OBSERVER) é um sistema integrador de

múltiplas ontologias também definidas em CLASSIC (Mena, 1998).

Outros projetos correlatos também são citados ao longo deste trabalho: o

Meditor envirOnment for Multiple Information Sources (MOMIS) (Bergamaschi,

1998) baseia-se na criação de um esquema global definido em description logic

proprietária; o KArlsruhe ONtology (KAON) (Motik, 2002) é uma infra-estrutura

aberta de ferramentas baseadas em RDF para gerência e integração de ontologias;

o Domain Ontology Management Environment (DOME) (Cui, 2000) também é

um ambiente de ferramentas para integração de fontes heterogêneas baseado em

ontologias definidas a partir de CLASSIC; o ONtology compositION (ONION)

(Mitra, 200) utiliza uma representação orientada a grafos estendida por uma

álgebra de ontologias proprietária; o Bremen University Semantic Translator for

Enhanced Retrieval (BUSTER) (Stuckenschmidt, 2000), por sua vez, utiliza a

linguagem OIL para representar suas ontologias.

Os demais capítulos deste trabalho estão estruturados conforme se segue. O

capítulo 2 aborda os tópicos preliminares relativos à integração de sistemas,

ontologias e algumas de suas linguagens de definição. O capítulo 3 é reservado ao

estudo da linguagem OWL que está em desenvolvimento pelo consórcio W3C. Os

capítulos 4 e 5 tratam respectivamente das formas de explicitação e de

mapeamento entre ontologias. Nestes, são definidos padrões para o mapeamento

Introdução 14

de conceitos entre ontologias e é proposta uma notação gráfica de representação,

de modo a tornar simples e fácil sua identificação e seu entendimento.O capítulo 6

apresenta um estudo de caso onde são validadas as idéias aqui apresentadas. O

capítulo 7 propõe uma arquitetura para implementação de sistema integrador.

Enquanto o último capítulo contém as conclusões finais e sugestões para trabalhos

futuros.

Preliminares 15

2 Preliminares

2.1. Integração de Sistemas

A integração de informações tem por objetivo proporcionar uma visão

coerente de dados armazenados em múltiplas, e possivelmente não homogêneas,

fontes de informação. Este é um dos problemas centrais em banco de dados

distribuídos, sistemas de informação cooperativos e data warehousing, que são

algumas das principais áreas da indústria de desenvolvimento de software.

Muitos trabalhos em integração de informações têm sido desenvolvidos no

contexto de projeto de banco de dados, com ênfase no assim denominado

problema de integração de esquema (schema integration problem), ou seja, na

criação de esquema global unificado a partir de vários sub-esquemas, cada qual

produzido de forma independente. Esforços mais recentes têm levado em

consideração o próprio dado em si. Neste caso, a entrada do processo de

integração é uma coleção de fontes de dados, cada qual constituída por um

esquema e dados reais e o objetivo é proporcionar uma visão integrada e

reconciliada dos dados presentes em cada fonte (Calvanese, 1998).

O sistema integrado pode, em princípio, ser usado tanto para consulta como

para atualização dos dados armazenados. Contudo, para efetuar atualizações das

informações integradas se faz necessária a modificação dos dados em cada fonte

de informação. Assim, é preciso um alto nível de coordenação entre o sistema

integrado e as diversas fontes de dados. Esta forma de integração é típica dos

bancos de dados federativos.

Recentemente, uma forma mais leve de integração tem sido considerada,

onde a autonomia das fontes é uma premissa básica, e o sistema integrado é visto

como um cliente das fontes de dados, sem interferir com a operação das mesmas.

Preliminares 16

Assim, a visão reconciliada é utilizada apenas para responder a consultas, não

considerando a necessidade de atualizações das fontes de forma integrada. Por

esta razão, este tipo de integração é normalmente denomina de read-only

integration.

A integração de informação pode ser virtual ou materializada. No primeiro

caso, o sistema integrado age como uma interface entre o usuário e as fontes, o

que é típico de banco de dados múltiplos, banco de dados distribuídos e, de forma

mais geral, sistemas abertos. Na integração virtual, a resposta a consultas é de alto

custo, por necessitar acessar os dados nas fontes de origem. No segundo caso, o

sistema mantém uma visão replicada dos dados das fontes como, por exemplo, em

data warehousing. Na integração materializada, a resposta a consultas é

geralmente mais eficiente, pois não há necessidade do acesso às fontes, por outro

lado, a manutenção da visão materializada é de alto custo, especialmente quando

estas devem refletir as alterações efetuadas nas fontes de forma imediata.

Há duas abordagens básicas para o problema de integração de informações,

que são conhecidas como procedimental e declarativa. Na abordagem

procedimental, os dados são integrados de uma maneira ad-hoc com respeito ao

conjunto predefinido de informações necessárias. Neste caso, o problema básico é

projetar um módulo de software para atender à necessidade de informação sem a

existência explicita da noção de um esquema (Chawathe, 1994) (Ullman, 1997).

Na abordagem declarativa, o objetivo é modelar os dados das fontes por

meio de uma linguagem adequada, de modo a construir uma representação

unificada, servindo de referência para consultas ao sistema global e para a

construção de respostas com o uso de mecanismos próprios para acesso às fontes

e/ou visões materializadas (Kirk, 1995).

O papel e a importância da modelagem conceitual nas arquiteturas e no

projeto dos sistemas de informação são bem conhecidos. Porém, nem sempre é

considerada nos frameworks de integração de informações, onde o foco da

atenção tem sido, principalmente, nos níveis físico e lógico. Contudo, o modelo

conceitual deveria ser capaz de representar as relações entre dados de diferentes

Preliminares 17

fontes de informação proporcionando, desta forma, uma linguagem de

representação e formalização dos relacionamentos entre os respectivos modelos.

As vantagens da modelagem conceitual relevantes tanto no nível de projeto,

quanto no nível de operação, são as seguintes (Calvanese, 1998):

Abordagem declarativa, independente de sistema – em termos gerais,

pode-se dizer que a utilização do nível conceitual de arquitetura é o meio natural

para se obter uma abordagem declarativa de integração de informações. Como

conseqüência, obtém-se todas as vantagens de se explicitar os vários aspectos dos

sistemas, proporcionando que a especificação dos relacionamentos entre as fontes,

e das fontes com o modelo organizacional, seja independente de sistema;

Alto nível de abstração com relação à interface de usuário – um dos

efeitos mais tangíveis da modelagem conceitual tem sido a quebra da barreira

entre usuário e sistema por permitir um nível mais elevado de abstração durante a

fase de projeto. Além disto, modelos conceituais são normalmente expressos na

forma gráfica e ferramentas gráficas que apresentem adequadamente a visão geral

do sistema são fatores chaves na interface de usuário;

Abordagem incremental – uma crítica que freqüentemente surge nas

abordagens declarativas de integração de informações é a necessidade de uma

visão reconciliada de todos os dados, que pode representar um custo muito

elevado para ser obtida. Contudo, construir um modelo conceitual não obriga o

seu desenvolvimento completo de uma só vez. Novas fontes ou elementos podem

ser incorporados quando se tornam disponíveis ou necessários, amortizando,

assim, o custo da integração. Deste modo, o projeto como um todo pode ser visto

como um processo incremental de entendimento e representação dos

relacionamentos entre as diferentes fontes de dados;

Documentação – enquanto na abordagem procedimental a informação a

respeito dos relacionamentos entre as fontes fica codificada em módulos de

aplicações, na abordagem declarativa estes são registrados de forma explicita. A

importância disto surge de forma clara em grandes organizações, onde as

informações sobre os dados ficam espalhadas em vários documentos que não

Preliminares 18

necessariamente obedecem a padrões comuns. Assim, a modelagem conceitual

pode ser vista como um meio comum para a documentação das fontes de dados e

pode fornecer uma especificação formal para construção de módulos de

aplicações de acessos a essas fontes. Com a representação explicita há um ganho

de re-usabilidade do conhecimento adquirido, que não é alcançado na abordagem

procedimental;

Facilidade de manutenção – as vantagens do nível conceitual na fase de

projeto são refletidas em vantagens também na fase de manutenção, decorrentes

das freqüentes alterações necessárias ao longo da vida útil dos sistemas de

integração de informações.

Um outro conjunto de facilidades que pode ser obtido a partir da introdução

do nível conceitual está relacionado com a capacidade de dedução sobre a

representação conceitual. Esta possibilidade pode ser utilizada para execução de

várias atividades relacionadas ao projeto e à operação dos sistemas. Por exemplo,

a capacidade de inferência pode ser usada: para verificar a representação

conceitual quanto a consistências e redundâncias; para auxiliar na manutenção do

sistema em resposta a alterações nas necessidades de informação; e para avaliar o

desempenho do sistema como um todo.

2.2. Ontologias

No sentido filosófico, pode-se entender ontologia como um sistema de

categorias de uma determinada visão do mundo. Assim sendo, este sistema não

depende de uma linguagem particular. Por outro lado, em seu uso mais freqüente

em IA (Inteligência Artificial), ontologia faz referência a um artefato de

engenharia, constituído de vocabulário específico usado para descrever uma certa

realidade, acrescida de um conjunto de suposições com respeito ao significado

esperado das palavras do vocabulário. Este conjunto de suposições fica

normalmente na forma de lógica de primeira ordem, onde as expressões do

vocabulário aparecem como predicados unários ou binários, chamados

Preliminares 19

respectivamente de conceitos e relações. No caso mais simples, uma ontologia

descreve uma hierarquia de conceitos relacionados por meio de regras, enquanto

que, em casos mais sofisticados, são adicionados axiomas adequados para

expressar relacionamentos mais complexos e para restringir a interpretação

desejada de seus conceitos (Guarino, 1998).

As duas formas de ontologias descritas acima estão intrinsecamente

relacionadas mas para resolver o impasse terminológico, é preciso escolher uma

delas, fazendo uso de um termo adicional para a outra. Dando preferência à

descrição utilizada em IA e escolhendo “conceituação” para o sentido filosófico,

pode-se dizer que duas ontologias podem ser diferentes com relação ao

vocabulário utilizado (como no caso de diferenças de idioma), enquanto

compartilham a mesma conceituação.

Guardadas as devidas proporções, podem-se enumerar algumas formas

antecessoras das ontologias: dicionários definindo termos a partir de outros

termos; esquemas de bancos de dados e seus modelos entidade-relacionamento;

classes definidas na orientação a objetos.

O desenvolvimento de uma ontologia abrangente é de elevado custo. A

validação de uma ontologia requer a classificação de uma quantidade

representativa de objetos. O processamento de consultas sobre os objetos com o

uso de ontologias é extremamente útil na descoberta de inconsistências e erros nas

mesmas. Isto pode ser realizado comparando-se os resultados obtidos com a

expectativa de especialistas do domínio em questão.

Uma vez desenvolvida com sucesso para um determinado contexto, é de se

esperar que a ontologia possa ser reutilizada e estendida para outros contextos.

Ontologias extensas e desenvolvidas para vários propósitos tendem a se tornar

grandes redes, cujo tratamento e manutenção são difíceis e onerosos.

Grande parte do foco no desenvolvimento de ontologias tem sido na

construção de ontologias abrangentes e estáticas, sem uma limitação explicita de

contexto, apesar de, na maioria dos casos, terem sido iniciadas num domínio

Preliminares 20

específico de aplicação. Visto que dificilmente pode ser alcançado um consenso

global sobre seus conceitos e que o significado destes pode mudar com o passar

do tempo, o esforço necessário para manter estas ontologias atualizadas e

consistentes consome praticamente a totalidade dos recursos alocados para o seu

desenvolvimento (Wiederhold, 1999).

Desta forma, uma abordagem baseada na composição de pequenas

ontologias de domínio específico proporciona maior facilidade de manutenção e

de crescimento em escala. Quando uma ontologia é amplamente utilizada como

base de um sistema de informação, seu conteúdo e escopo se tornam altamente

confiáveis, podendo ser reutilizada em seu próprio domínio ou por aplicações que

sejam capazes de construir um novo contexto baseado na composição de

ontologias. A capacidade de composição de ontologias reduz significativamente o

custo global de construção e manutenção das mesmas.

2.3. Linguagens de Ontologias

O reconhecimento do papel chave que as ontologias devem ter no futuro da

Internet levou à expansão das linguagens de marcação de modo a facilitar a

descrição de conteúdo e ao desenvolvimento de ontologias para a Web. Exemplos

são XML Schema (W3C, 2003abcd), RDF (Resource Description Framework) e

RDF Schema (W3C, 2001ab). Esta última, em particular, é reconhecida como uma

linguagem de representação de conhecimento e de ontologias, descrevendo classes

e propriedades (relações binárias), restrições de domínio e contra-domínios de

propriedades, e relações de subclasse e sub-propriedade.

Contudo, RDFS é uma linguagem muito primitiva, que necessita claramente

de um maior poder de expressão para descrever recursos num nível de detalhe

suficiente (Horrocks, 2002). Além disto, tal descrição deve ser passível de

processamento automático por mecanismos de dedução possibilitando, por

exemplo, a determinação do relacionamento semântico entre termos

sintaticamente distintos.

Preliminares 21

2.3.1. DAML e OIL

Com o objetivo de prover o fundamento da Web semântica, foi iniciado em

1999 o programa DARPA Agent Markup Language (DAML). Como primeiro

passo, uma nova linguagem chamada DAML-ONT (DAML, 2000) foi

desenvolvida para estender RDF com construtores semelhantes aos utilizados em

linguagens de orientação a objeto e de representação do conhecimento baseada em

frames. Contudo, como RDFS, DAML-ONT não possuía uma forte especificação

semântica, levando a divergências no entendimento preciso dos termos das

ontologias.

Aproximadamente no mesmo período, um grupo de pesquisadores europeus

com objetivos similares aos do DAML, desenvolveu uma outra linguagem

orientada para Web denominada OIL (Ontology Inference Layer) (OIL, 2000). Da

mesma forma que DAML-ONT, OIL teve sua sintaxe baseada em RDFS e um

conjunto de construtores semelhantes aos das linguagens baseadas em frames

(Stuckenschmidt, 2000). Porém, em OIL foi dada ênfase a um rigor formal, e a

linguagem foi explicitamente projetada de modo que sua semântica pudesse ser

especificada por meio de um mapeamento para SHIQ (Horrocks, 1999), uma

linguagem da família de Description Logics, que possui elevado poder de

expressividade.

Tornou-se óbvio que os esforços de ambos os grupos deveriam ser unidos

num único objetivo. Desta junção resultou a linguagem DAML+OIL

(DAML+OIL, 2001), possuindo alto formalismo semântico e construtores

provenientes da reconciliação entre as duas linguagens. Para dar prosseguimento

ao desenvolvimento de DAML+OIL, foi formado um comitê com membros das

duas equipes originais (Joint EU/US Committee on Agent Markup Language).

Recentemente, a linguagem foi submetida ao W3C (World Wide Web

Consortium) para servir de base para o desenvolvimento da OWL - Web Ontology

Language.

Preliminares 22

2.3.2. DAML+OIL

DAML+OIL é uma linguagem de ontologia projetada para descrever a

estrutura de um domínio. Tendo por base uma abordagem de orientação a objeto,

a estrutura de um domínio é descrita em termos de classes e propriedades. A

definição de que recursos são instâncias de classes ou propriedades em

DAML+OIL é deixada para RDF. Classes de DAML+OIL podem ser nomes ou

expressões, que podem ser construídas a partir de uma variedade de construtores

(Horrocks, 2002):

Construtor Sintaxe DL Exemplo

intersectionOf C1…Cn Humano Masculino

unionOf C1 … Cn Medico Advogado

complementOf ¬C ¬ Masculino

oneOf {X1… Xn} {João, Maria}

toClass P.C temFilho.Medico

hasClass P.C temFilho.Advogado

hasValue P.{X} cidadaoDe.{USA}

minCardinalityQ nP.C 2 temFilho.Advogado

maxCardinalityQ nP.C 1 temFilho.Masculino

cardinalityQ = nP.C = 1 temPais.Feminino

Figura 1 – Construtores de classe em DAML+OIL

A sintaxe DL (Description Logics) foi adotada por ser mais compacta. Em

notação RDF/XML teríamos no exemplo do intersectionOf:

<daml:Class>

<daml:intersectionOf rdf:parseType=”daml:collection”>

<daml:class rdf:about=”#Humano”/>

<daml:class rdf:about=”#Masculino”/>

Preliminares 23

</daml:intersectionOf>

</daml:Class>

Como veremos no capítulo seguinte, a linguagem OWL possui construtores

análogos aos acima apresentados. Naquele capítulo, apresentaremos exemplos

mais detalhados e discutiremos a forma de utilização de cada um destes

construtores.

Como mencionado anteriormente, além do conjunto de construtores, um

outro aspecto de uma linguagem que determina sua expressividade é o tipo de

axioma suportado. Os seguintes axiomas permitem definir relações de subclasse e

equivalência de classes e propriedades, disjunção de classes, equivalência ou não

entre indivíduos, assim como várias características de propriedades.

Axioma Sintaxe DL Exemplo

subClassOf C1 C2 Humano Animal Bipede

sameClassAs C1 C2 Homem Humano Masculino

subPropertyOf P1 P2 temFilha temFilhos

samePropertyAs P1 P2 preco custo

disjointWith C1 ¬C2 Masculino ¬Feminino

sameIndividualAs {X1}{X2} {Luis_Inacio}{Lula}

DifferentIndividualFrom {X1} ¬{X2} {João} ¬{Pedro}

inverseOf P1 P2¯ temFilho temPais¯

transitiveProperty P+ P ancestral+

ancestral

uniqueProperty T 1P T 1 temMae

UnambiguousProperty T 1P ¯ T 1 ehMaeDe

Figura 2 - Axiomas em DAML+OIL

DAML+OIL suporta todos os tipos de dados de XML Schema. Isto é

facilitado pela separação explicita entre elementos de classes de objeto, definidas

Preliminares 24

pela linguagem de ontologia, e valores de tipos de dado, definidas pelo sistema

de tipos de XML Schema. Em particular, é assumido que o domínio de

interpretação das classes de objeto é disjunto do domínio de interpretação dos

tipos de dado. Assim, um elemento de uma classe de objeto não pode nunca ter a

mesma interpretação que um valor de um tipo de dado. Da mesma forma, o

conjunto de propriedades de objeto, que representam relacionamentos entre

elementos de classes de objeto, é disjunto do conjunto de propriedades de tipo

de dado, que associam elementos com valores de tipo de dado.

OWL – Web Ontology Language 25

3 OWL – Web Ontology Language

3.1. Introdução

A linguagem OWL (W3C, 2003efgh) tem como objetivo a definição de

ontologias para a Web e bases de conhecimento associadas. Nela, uma ontologia é

um conjunto de definições de classes, propriedades e restrições no modo como

podem ser utilizadas. Uma ontologia OWL pode incluir os seguintes elementos:

relações de taxonomia entre classes;

propriedades de tipo de dado, ou seja, descrições de atributos dos

elementos de classes;

propriedades de objeto, ou seja, descrições de relações entre

elementos de classes;

e, em menor grau:

instâncias de classes;

instâncias de propriedades.

Propriedades de tipo de dado e propriedades de objeto são, em conjunto, as

propriedades de uma classe.

Um conjunto de sentenças OWL em um sistema de dedução forma uma base

de conhecimento. Essas sentenças ou regras podem incluir fatos sobre indivíduos

que são membros de classes, assim como diversos fatos derivados, que não estão

presentes explicitamente no texto da representação original da ontologia, mas

vinculados, por meio de implicação lógica, na semântica da linguagem OWL.

Estas regras podem estar baseadas numa ontologia simples ou em múltiplas

ontologias distribuídas, que podem ser combinadas através dos mecanismos

definidos em OWL.


Enquanto as ontologias em sua maioria não incluem instâncias de classes

(em oposição às bases de conhecimento), é freqüente o caso em que algumas

instâncias são necessárias para definição de certas classes de uma ontologia. Por

exemplo, se considerarmos Instalacao e Unidade como representando,

respectivamente, as classes das instalações e das unidades organizacionais da

Petrobras, e EP-BC como instância da classe Unidade, então a classe

InstalacaoEPBC das instalações da unidade EP-BC necessitaria desta instância

como parte de sua definição e, assim, como elemento da ontologia.

Comparando-se com outros padrões, uma ontologia OWL diverge de um

XMLSchema (W3C, 2001ab) por se tratar de uma representação do conhecimento

e não um formato de mensagem. A maioria dos padrões de indústria para Web

consiste de uma combinação de especificações de formatos de mensagens e de

protocolos. A estes formatos é dada uma semântica operacional. Mas a

especificação não é planejada para suportar decisões fora do contexto de suas

transações. Por exemplo, no geral, não há um mecanismo para concluir que uma

instalação do tipo InstalacaoEPBC deve também ser do tipo InstalacaoEP-PRO,

posto que InstalacaoEPBC é uma especialização de InstalacaoEP-PRO.

Outra vantagem será a maior disponibilidade de máquinas de inferência para

OWL. Estas ferramentas proporcionarão suporte genérico, não específico a um

domínio particular, o que seria o caso de se desenvolver um sistema de inferência

sobre um esquema XML de um padrão de indústria específico. A construção de

um sistema inteligente robusto não é um esforço simples. A construção de uma

ontologia é muito mais tratável, gerando grande expectativa de que muitos grupos

se dedicarão e esta tarefa. Estes serão beneficiados por ferramentas de terceiros,

baseadas nas propriedades formais da linguagem OWL, que disponibilizarão um

conjunto variado de funcionalidades.

De fato, OWL é um conjunto de três linguagens de complexidade crescente:

OWL Lite – definida com a intenção de criar uma linguagem simples para

atender a usuários que necessitem basicamente de uma hierarquia de

classificação e recursos simples de restrição. Por exemplo, permite


restrições de cardinalidade, porém somente para valores 0 e 1. Por estas

razões, será mais simples fornecer ferramentas de suporte para OWL Lite,

em comparação com as versões mais complexas;

OWL DL – inclui o vocabulário completo da linguagem, interpretado sob

um número de restrições simples. Como primeira destas está a separação

de tipos. Identificadores de classe não podem ser simultaneamente

propriedades e indivíduos. De forma análoga, propriedades não podem ser

indivíduos. OWL DL é assim denominada devido à sua correspondência

com Description Logics;

OWL Full – inclui o vocabulário completo da linguagem, interpretado

mais amplamente que na OWL DL, com a liberdade proporcionada por

RDF. OWL Full não obriga a separação rigorosa entre classes,

propriedades, instâncias e valores de dados. Outra diferença significativa é

que uma propriedade de tipo de dado (DatatypeProperty) pode ser

marcada como invertida (InverseFunctionalProperty). Estas características

são do interesse dos usuários mais avançados.

3.2. Estrutura das Ontologias OWL

Como o objetivo principal de OWL é tratar conteúdo Web, ela é

inerentemente distribuída. Uma conseqüência disto é que OWL geralmente

assume a hipótese de mundo aberto, ou seja, as descrições de recursos não ficam

confinadas num único arquivo ou escopo. Uma classe C1 originalmente definida

em uma ontologia O1 pode ser estendida em outras ontologias, porém,

proposições adicionais sobre C1 não podem negar informações prévias. Fatos e

vínculos podem ser apenas acrescentados, nunca eliminados.

OWL permite que a negação de uma informação seja explicitamente

estabelecida. Como resultado, contradições podem ser geradas com relativa

simplicidade. Também podem ocorrer contradições implícitas. Portanto, para que

este tipo de problema seja evitado, a construção de ontologias deve ser

extremamente cuidadosa.


OWL atende a requisitos de formalismo sintático e semântico, permitindo a

elaboração de ontologias que possam ser utilizadas por agentes de software e

interpretadas sem ambigüidades.

Um componente inicial padrão de uma ontologia OWL inclui um conjunto

de declarações de namespaces dentro de um elemento rdf:RDF. Este mecanismo

provê meios de evitar que identificadores sejam interpretados de forma ambígua e

torna toda a ontologia muito mais legível. No geral, uma ontologia começa com

uma declaração de namespaces similar à seguinte:

<rdf:RDF

xmlns =“http://ti.petrobras.com.br/map#”

xmlns:map =“http://ti.petrobras.com.br/map#”

xmlns:n1710 =”http://nortec.engenharia.petrobras.com.br/N-1710#”

xmlns:sip =“http://ti.petrobras.com.br/SIP#”

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/2000/10/XMLSchema#”

xmlns:dt =“http://ti.petrobras.com.br/dt#” >

…

As duas primeiras declarações identificam o namespace associado com a

ontologia para o mapeamento. A primeira é definida como default, estabelecendo

que elementos não prefixados e referências URI (Uniform Resource Identifier)

(Berners-Lee, 1998b) (W3C, 2003j) vazias referenciam a ontologia corrente. A

segunda associa o prefixo map: com o mesmo namespace. A terceira linha

identifica o namespace da ontologia relativa à norma de documentos de

Engenharia da Petrobras N-1710 com o prefixo n1710:. Do mesmo modo, sip: faz

referência à ontologia do Sistema de Informação da Petrobras em

=“http://ti.petrobras.com.br/SIP#”.


A quinta declaração de namespace determina que, neste documento,

elementos prefixados com owl: devem ser entendidos como referenciando o

namespace ”http://www.w3.org/2002/07/owl#”. Esta é uma declaração OWL

convencional, necessária para introduzir o vocabulário OWL.

OWL depende de construções definidas por RDF e RDFS. Neste

documento, o prefixo rdf: faz referência ao namespace chamado

”http://www.w3.org/1999/02/22-rdf-syntax-ns#”. Os dois seguintes fazem

declarações similares com relação a RDF Schema (rdfs:) e XML Schema (xsd:).

Este exemplo de documento OWL está relacionado com um outro

documento contendo definição de tipos de dados. A declaração final estabelece

que elementos prefixados por dt: devem ser entendidos como referências ao

namespace “http://ti.petrobras.com.br/dt#”.

Como auxílio para descrever referências a URLs extensas, um conjunto de

definições pode ser estabelecido na declaração do tipo de documento

(DOCTYPE) que precede as definições da ontologia. Os nomes definidos pelas

declarações de namespace somente têm significado como parte de elementos

XML. Valores de atributos não são sensíveis às definições de namespace. Porém,

em OWL é freqüente o uso de valores de atributos fazendo referência a

identificadores de ontologias. Estes valores podem ser descritos na forma

expandida, como por exemplo “http://ti.petrobras.com.br/SIP#Campo”. De outra

forma, podem ser definidas abreviações com a utilização da definição de

ENTITY, por exemplo:

<!DOCTYPE owl (

<!ENTITY n1710 “http://nortec.engenharia.petrobras.com.br/N-1710#”>

<!ENTITY sip “http://ti.petrobras.com.br/SIP#”> ) >

Após estas declarações, pode ser escrito o valor “&sip;Campo”, que

corresponde em sua forma expandida a “http://ti.petrobras.com.br/SIP#Campo”.


Uma vez definidos os namespaces, o passo seguinte estabelece o começo da

ontologia propriamente dita:

<owl:Ontology rdf:about=“ http://ti.petrobras.com.br/map”>

O valor do atributo about é normalmente a URL do arquivo corrente,

indicando que o objeto da declaração é o próprio documento.

O conjunto de elementos a seguir resolve tarefas do tipo definição de

comentários, controle de versão e inclusão de outras ontologias.

<owl:Ontology rdf:about=“http://ti.petrobras.com.br/map”>

<rdfs:comment>

Ontologia para mapeamento N1710 x SIP

</rdfs:comment>

<owl:versionInfo>

$Id: /map.html,v 1.2 30/05/2003 16:42:25 Marcos $

</owl:versionInfo>

<owl:imports rdf:resource=“http://ti.petrobras.com.br/sip.owl” />

…

O elemento <rdfs:comment> proporciona que sejam incluídos comentários

na ontologia.

O elemento <owl:versionInfo> é um elemento padrão que estabelece, de

forma consistente, um gancho para um sistema de controle de versão de

ontologias. OWL não especifica a estrutura de seu conteúdo.

O elemento <owl:imports> fornece um mecanismo de inclusão de outros

recursos. Possui um único argumento, identificado pelo atributo rdf:resource.

Importar uma outra ontologia significa trazer todo o seu conjunto de

definições para a base de conhecimento corrente. De modo a fazer o melhor uso

da ontologia importada, este mecanismo deve ser utilizado em coordenação com a


declaração de namespaces. Esta proporciona meios convenientes para referência a

termos de outras ontologias. Por outro lado, owl:imports tem a intenção explicita

de incluir todas as declarações da ontologia alvo, permitindo que sejam feitas

inferências sobre seus termos.

3.3. Definições Básicas

Muitos usos de uma ontologia dependem da capacidade de se tirar

conclusões sobre seus indivíduos. Para tal, é necessário um mecanismo para

descrição de classes, indivíduos e propriedades. Estas podem ser herdadas por

classes ou ser atribuídas especificamente a indivíduos. O maior potencial das

ontologias está na capacidade de inferência baseada em classes.

3.3.1. Definindo Hierarquia de Classes

Os conceitos mais básicos de um domínio devem corresponder a classes que

são as raízes de várias árvores de taxonomias. Cada indivíduo do mundo OWL é

um membro da classe owl:Thing. Assim, cada classe definida pelo usuário é

implicitamente uma subclasse de owl:Thing. As classes raízes de um domínio são

definidas através da simples declaração de um nome de classe.

Seguindo o exemplo do domínio da norma N-1710 (ver Anexo A para os

detalhes), as seguintes raízes podem ser criadas:

<owl:Class rdf:ID=”Instalacao”/>

<owl:Class rdf:ID=”Atividade”/>

<owl:Class rdf:ID=”Equipamento”/>

Formalmente, após estas definições de classes, nada mais é conhecido além

de sua existência e seus nomes. Até este momento não faria diferença caso seus

nomes fossem Classe1, Classe2 e Classe3.


A sintaxe atributo/valor rdf:ID=”Instalacao” é utilizada para introduzir um

nome, como parte de sua definição. Este é o atributo rdf:ID semelhante ao

atributo ID definido em XML. No escopo deste documento, a classe Instalacao

pode agora ser referenciada com o uso de rdf:resource=”#Instalacao”. Outras

ontologias podem fazer referência a ela pela forma completa “URI do

documento#Instalacao”. A forma mais razoável para isto seria definindo o

documento como um recurso fonte através da declaração de namespace e entity:

...

<!ENTITY n1710 “http://nortec.engenharia.petrobras.com.br/N-1710#” >

...

<rdf:RDF xmlns:n1710=“http://nortec.engenharia.petrobras.com.br/N-1710#”

...

Estabelecidas estas definições, a classe Instalacao pode ser referenciada

com o uso do elemento XML n1710:Instalacao ou do valor de atributo

&n1710;Instalacao. De qualquer modo, também é sempre possível o uso da URI

na sua forma completa “http://nortec.engenharia.petrobras.com.br/N-1710

#Instalacao”.

Uma outra forma de referência utiliza a sintaxe rdf:about=”#Instalacao”

para estender a definição de um recurso. Este uso é um elemento crítico na criação

de uma ontologia distribuída. Ela permite que uma definição importada possa ser

estendida sem a necessidade de alteração do documento original, dando suporte à

construção incremental de uma ontologia de maior abrangência. No exemplo a

seguir, é adicionado um rótulo à classe Instalação sem a necessidade de alteração

no documento da ontologia original, referenciado por n1710:

<owl:Class rdf:about=”&n1710;Instalacao”>

<rdfs:label xml:lang=”pt”>Instalação Petrobras</rdfs:label>

</owl:Class>


O construtor fundamental na taxonomia de classes é subClassOf (subclasse

de). Ele é transitivo, ou seja, se X é uma subclasse de Y e Y é uma subclasse de Z

então X é uma subclasse de Z. Por exemplo:

<owl:Class rdf:ID=”Maquina”>

<rdfs:subClassOf drf:resource=”#Equipamento” />

...

</owl:Class>

Desta forma, Maquina fica definida como subclasse de Equipamento.

A definição de classes tem duas partes: a introdução de um nome ou

referência e uma lista de restrições. Cada uma das expressões seguintes à

definição de uma classe, e nela contidas, representam restrições adicionais aos

indivíduos pertencentes à classe. Os elementos de uma classe são membros da

interseção de todas as suas restrições.

Neste ponto é possível definir a classe InstalacaoEP, como sendo, de forma

simples, uma subclasse de Instalacao.

<owl:Class rdf:ID=” InstalacaoEP”>

<rdfs:subClassOf rdf:resource=”#Instalacao” />

<rdfs:label xml:lang=”pt”>Instalação do EP</rdfs:label>

...

</owl:Class>

Os elementos rdfs:label provêem nomes opcionais para a classe, permitindo

uma maior legibilidade e o seu uso por ferramentas de apresentação. O atributo

lang fornece suporte para múltiplas linguagens. Um label funciona como um

comentário e não contribui para a interpretação lógica da ontologia.


3.3.2. Definindo Indivíduos

Além de classes, é preciso descrever seus membros. Um indivíduo é

minimamente definido como um membro de uma classe.

<Plataforma rdf:ID=”Petrobras40” />

A seguinte forma possui significado idêntico à anterior:

<owl:Thing rdf:ID=”Petrobras40” />

<owl:Thing rdf:about=”#Petrobras40” />

<rdf:type rdf:resource=”#Plataforma” />

</owl:Thing>

O elemento rdf:type é uma propriedade RDF que vincula um indivíduo à

classe da qual ele é membro.

Como exemplo adicional, é apresentada a definição da instalação móvel de

produção PPMoraes.

<owl:Class rdf:ID=”InstalacaoProducao”>

<rdfs:subClassOf rdf:resourse=”#Instalacao” />

</owl:Class>

<owl:Class rdf:ID=”InstalacaoMovelProducao”>

<rdfs:subClassOf rdf:resourse=”#InstalacaoProducao” />

</owl:Class>

<InstalacaoMovelProducao rdf:ID=”PPMoraes” />

Existem importantes considerações com respeito à distinção entre classes e

indivíduos em OWL. Uma classe é simplesmente um nome e uma coleção de

propriedades que descrevem um conjunto de indivíduos. Estes, por sua vez, são os

membros deste conjunto. Assim, classes devem corresponder a conjuntos de


coisas que ocorrem naturalmente num domínio de interesse, enquanto indivíduos

devem corresponder a entidades reais que podem ser agrupadas nestas classes.

3.3.3. Definindo Propriedades

Uma propriedade é uma relação binária, podendo ser de dois tipos distintos:

propriedade de tipo de dado - relação entre elemento de classe e

tipo de dado XML;

propriedade de objeto – relação entre elementos de duas classes.

Quando uma propriedade é definida, podem ser especificados seu domínio e

contra-domínio. Uma propriedade pode ser definida como especialização de outra

propriedade existente.

<owl:ObjectProperty rdf:ID=”temMetodoElevacao”>

<rdfs:domain rdf:resource=”Coluna”/>

<rdfs:range rdf:resource=”MetodoElevacao”/>

</owl:ObjectProperty>

Em OWL, uma seqüência de sentenças sem um operador explícito

representa uma conjunção implícita aplicada ao elemento que a contém. A

propriedade temMetodoElevacao tem como domínio Coluna e como contra-

domínio MetodoElevacao, ou seja, relaciona elementos da primeira classe com

elementos da segunda.

As propriedades, como as classes, podem ser organizadas de forma

hierárquica. Por exemplo, temos:

<owl:Class rdf:ID="Local" />

<owl:Class rdf:ID="Campo">

<rdfs:subClassOf rdf:resource="#Local" />


...

</owl:Class>

<owl:ObjectProperty rdf:ID="temLocal">

<rdfs:domain rdf:resource="#Instalacao" />

<rdfs:range rdf:resource="#Local" />


<owl:ObjectProperty rdf:ID="temCampo">

<rdfs:subPropertyOf rdf:resource="#temLocal" />

<rdfs:range rdf:resource="#Campo" />


As propriedades de Local relacionam os locais das instalações, sendo

Campo um destes locais. Assim, pode-se definir temCampo como uma sub-

propriedade de temLocal, sendo seus valores restritos por Campo.

Propriedades de tipo de dado podem assumir valores do tipo String ou

podem fazer referência a um tipo de dado definidos em esquemas XML.

<owl:Class rdf:ID="DataInicioOperacao" />

<owl:DataTypeProperty rdf:ID="valorDataInicio">

<rdfs:domain rdf:resource="#DataInicioOperacao" />

<rdfs:range rdf:resource ="&dt;dataInicio" />

</owl:DataTypeProperty>

onde "&dt;dataInicio" é definido em um esquema XML separado.

Considerando as classes MetodoElevacao, Fluido e Coluna previamente

definidas, propriedades podem ser atribuídas a indivíduos da seguinte forma:

<MetodoElevacao rdf:ID="GLC" />

<Fluido rdf:ID="Oleo" />

<Coluna rdf:ID="RJS332U" >

<temMetodoElevacao rdf:resource="#GLC"/>

<produzFluido rdf:resource="#Oleo" />


</Coluna>

Também é possível especificar características de propriedades, ampliando

ainda mais a expressividade da linguagem:

TransitiveProperty - P(x, y) e P(y, z) -> P(x, z)

<owl:ObjectProperty rdf:ID="temLocal">

<rdf:type rdf:resource="&owlTransitiveProperty" />

<rdfs:domain rdf:resource="&owl;Thing" />

<rdfs:range rdf:resource="#Local" />


<Local rdf:ID="Badejo">

<temLocal rdf:resource="#AreaNorteBC" />

</Local >

<Local rdf:ID="AreaNorteBC">

<temLocal rdf:resource="#EP-BC" />

</Local>

Badejo está localizado em AreaNorteBC e esta, por sua vez, em EP-BC.

Como temLocal é transitiva, Badejo também está localizada em EP-BC.

As demais características de propriedades são:

SymmetricProperty - P(x, y) iff P(y, x)

FunctionalProperty - P(x, y) e P(x, z) -> y = z

InverseOf - P1(x, y) iff P2(y, x)

InverseFunctionalProperty - P(y, x) e P(z, x) -> y = z

Além disto, há vários modos para se restringir ainda mais os valores de

propriedades em determinados contextos:


cardinality

<owl:Class rdf:ID="Coluna">

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="#temMetodoElevacao"/>

<owl:cardinality>1</owl:cardinality>

</owl:Restriction>

</rdfs:subClassOf>

</owl:Class>

O elemento cardinality permite especificar o número exato de elementos de

uma relação. Enquanto minCardinality e maxCardinality são utilizados para

definir o limite inferior e o superior respectivamente.

hasValue

<owl:Class rdf:ID="ColunaGas">

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="#produzFluido" />

<owl:hasValue rdf:resource="#Gas" />

</owl:Restriction>

</rdfs:subClassOf>

...

</owl:Class>

O elemento hasValue permite a definição de classes baseadas na existência

de determinado valor de propriedade. Assim, um indivíduo será membro da classe

se, pelo menos, um dos valores da propriedade for igual ao da restrição.

allValuesFrom e someValuesFrom


<owl:Class rdf:ID="PlataformaGas">

<rdfs:subClassOf rdf:resource="Plataforma" />

...

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="#temColuna" />

<owl:allValuesFrom rdf:resource="#ColunaGas" />

</owl:Restriction>

</rdfs:subClassOf>

...

</owl:Class>

As colunas (temColuna) de uma plataforma de gás (PlataformaGas)

devem ser colunas de gás (ColunaGas). A restrição allValuesFrom se aplica

somente na propriedade da classe PlataformaGas. Colunas de quaisquer outras

plataformas não são afetadas por esta restrição. A restrição someValuesFrom é

definida de forma similar, porém menos restritiva. Caso se utilizasse no exemplo

anterior someValuesFrom, a restrição seria satisfeita se, pelo menos, uma coluna

fizesse referência a uma instância de ColunaGas.

Explicitando Ontologias de Sistemas 40

4 Explicitando Ontologias de Sistemas

4.1. Fontes de Ontologias

Todo sistema de informação tem sua própria ontologia, visto que, atribui

significado aos símbolos utilizados para uma dada visão particular do mundo. A

maioria dos sistemas de informação consiste de três diferentes tipos de

componentes: programas de aplicação; fontes de informação e interfaces de

usuário. Estes componentes são integrados de modo a alcançar um propósito

concreto de atendimento a necessidades de informação do usuário (Guarino,

1998). Para discutir a forma de utilização de ontologias em sistemas de

informação, é preciso considerar como cada um de seus componentes é afetado,

assim como, a fase em que o sistema faz uso da ontologia, ou seja, se durante o

desenvolvimento ou se em tempo de execução.

Na fase de desenvolvimento, podem ser distinguidos dois cenários

principais, correspondentes à existência de uma biblioteca organizada contendo

um conjunto de ontologias reutilizáveis, ou à existência de uma ontologia genérica

de mais alto nível, portanto, de reaproveitamento mais limitado. No primeiro

cenário, o conteúdo semântico pode ser “traduzido” para um componente do

sistema de informação, reduzindo a necessidade de análise e garantindo melhor

adequação do sistema. Quanto ao segundo cenário, que normalmente é o mais

freqüente, o papel da ontologia não é o de ser adaptada e reutilizada, mas por

outro lado, participar como ferramenta para o aumento de qualidade do processo

de análise, servindo como ponto de partida de mais alto nível para o

desenvolvimento de uma ontologia da aplicação.

Um ponto importante a ser destacado é que as ontologias podem ser não

apenas utilizadas na construção de novos sistemas (sistemas de informação


baseados em ontologias), mas também podem fazer parte de um processo de

reengenharia de sistemas legados, aumentando seu reuso e facilitando sua

manutenção.

Em tempo de execução dos sistemas, o uso de ontologias possibilita que

agentes de software se comuniquem via mensagens formuladas em termos de

ontologias. Através do compartilhamento de ontologias comuns, os agentes

podem “entender” o significado das mensagens trocadas.

Com respeito ao impacto do uso de ontologias em cada um dos

componentes de um sistema, podem ser feitas as seguintes considerações.

O uso mais óbvio de uma ontologia está em sua conexão com o componente

de fonte de informação. De fato, uma ontologia pode ser comparada ao esquema

de banco de dados. Na fase de desenvolvimento, o uso de ontologias pode

desempenhar um papel importante na análise de requisitos e modelagem

conceitual, podendo ser utilizada para mapear a especificação conceitual em

esquemas de vários tipos de bancos (relacional, orientado a objetos e outros).

Outro uso típico está na integração de informações, através do mapeamento de

esquemas conceituais heterogêneos numa ontologia comum de alto nível.

O primeiro papel que uma ontologia pode ter com relação ao componente

de interface de usuário é servindo de alvo de consulta pelo próprio usuário. Neste

caso, o usuário tem consciência da ontologia, que faz parte do procedimento de

uso normal do sistema. Além deste, outro uso interessante está no usuário poder

configurar seu próprio vocabulário (sua própria ontologia), relacionando termos

do sistema com os seus.

Os programas de aplicação são componentes importantes da maioria dos

sistemas de informação. Neles está contida grande parte do conhecimento do

domínio que, por vários motivos, não foi armazenada de forma separada do

próprio código. Uma parcela deste conhecimento fica codificada na parte estática

dos programas na forma de declarações de classes e tipos de dados. Outra parcela,

de regras de negócio, é mantida implicitamente no código dos procedimentos das


aplicações. Durante o desenvolvimento, o uso de ontologia pode ajudar na geração

da parte estática dos programas. Após a entrada em execução, grandes benefícios

do ponto de vista de flexibilidade, facilidade de manutenção e extensão podem ser

alcançados, através da representação explícita do conhecimento embutido nos

programas de aplicação, construindo desta forma, sistemas orientados ao

conhecimento.

Figura 3 – Explicitando ontologias de sistemas de informação

Contudo, se por alguma razão, não for possível ou de interesse tornar

explícito todo o conhecimento contido nos componentes de um sistema de

informação, ainda assim, o comprometimento deste com uma ontologia de mais

alto nível pode ser explicitado, aumentando significativamente a transparência e a

qualidade do software das aplicações.

4.2. Modelos Baseados em Classes

4.2.1. Discussão

A representação de modelos de objetos e classes é encontrada em vários

campos da Ciência da Computação. De modo geral, um objeto denota um

elemento de um domínio de interesse, enquanto uma classe significa um conjunto

Código

Dados

Ontologia

Sistema de Informação

Sistemas de Informação Externos


de objetos com características comuns. Através destes modelos podem ser

expressos vários tipos de relacionamentos e restrições existentes entre as classes

de um determinado conjunto de aplicações ou sistemas. Deste modo, a

formalização destes modelos faz uso da estrutura de classes para proporcionar

várias informações como, por exemplo, se uma classe é consistente (ou seja,

admite pelo menos um objeto), se uma classe é subclasse de outra ou, de forma

mais geral, se uma dada restrição se aplica a um conjunto de classes.

Três famílias principais de formalismos baseados em classes podem ser

identificadas. A primeira vem da área de representação do conhecimento, em

particular, do trabalho em redes semânticas e frames. A segunda é proveniente da

área de banco de dados, em particular, do trabalho relacionado à modelagem

semântica de dados. A terceira, da área de sistemas orientados a objeto e do

trabalho relacionado à definição de tipos em linguagens de programação.

Em Description Logics, a estrutura do conhecimento é representada por

meio de conceitos e papéis, que denotam predicados unários e binários

respectivamente. Formalmente, conceitos são representados como subconjuntos

de um domínio, enquanto os papeis como relações binárias sobre este domínio.

Expressões complexas de conceitos e papeis podem ser construídas a partir de um

conjunto de símbolos atômicos, através da aplicação adequada dos construtores de

uma determinada linguagem de Description Logics.

Em (Calvanese, 1999) é proposta uma linguagem de Description Logics

denominada ALUNI, que possui uma combinação de construtores, incluindo

restrições de número, papeis inversos e sem restrições de assertivas com ciclos.

Esta linguagem apresenta recursos suficientes para proporcionar um framework

unificado para sistemas baseados em frames, linguagens orientadas a objeto e

modelagem semântica de dados. Como os construtores de ALUNI representam

um subconjunto dos construtores de OWL-DL, esta também possui poder de

representação para expressar os modelos acima citados, possibilitando assim o

mapeamento dos modelos entidade relacionamento e dos modelos de classes de

objetos para ontologias definidas em OWL.


4.2.2. Do Modelo UML

Unified Modeling Language (UML) é um padrão do Object Management

Group (OMG), sendo amplamente utilizado por companhias e instituições

envolvidas com a área de engenharia de software. Existem várias ferramentas

disponíveis para criação e edição de modelos em UML, através de manipulação de

sua representação gráfica. Vários tipos de diagramas são definidos em UML para

modelagem dos comportamentos estático e dinâmico de um sistema. Dois tipos

são os mais relevantes para aplicação na representação do conhecimento

(Cranefield, 2001):

diagramas de classes – representam classes, seus atributos e

relacionamentos;

diagramas de objetos – representam os objetos (instâncias das classes),

os valores de seus atributos e suas ligações com outros objetos.

A especificação OMG do formato XML Metadata Interchange (XMI)

(OMG, 2003) define um mecanismo para serialização de um modelo UML como

um documento XML. O mapeamento de diagramas de classes UML para

esquemas RDF-Schema (RDFS) pode ser implementado através da utilização da

linguagem de transformação XSLT (W3C, 2003i), tendo como entrada o

documento XMI exportado por alguma ferramenta CASE disponível. Alguns

problemas ocorrem nesta abordagem como, por exemplo, o fato das propriedades

serem globais em RDF. Desta forma, uma dada propriedade não pode ser definida

como tendo diferentes contradomínios quando aplicada a objetos de classes

distintas. Uma forma de contornar tal problema é através da definição de

propriedades com nomes na forma nomeClasse.nomePropriedade, tornando as

propriedades únicas para cada classe.

A abordagem baseada na utilização de transformações XSLT pode ser

estendida para criação de documentos OWL e também para utilizar como entrada

documentos XML gerados a partir de outras linguagens de modelagem de classes.


Um resumo comparativo entre UML e RDFS pode ser obtido em (W3C,

1998) e uma ferramenta para tradução automática de UML/XMI para RDFS foi

disponibilizada em (Melnik, 2000).

4.2.3. Do Modelo Entidade-Relacionamento

O modelo Entidade-Relacionamento (ER) é o mais difundido modelo

semântico de dados, amplamente utilizado na fase de projeto das aplicações

comerciais, tornando-se um padrão de mercado. Desde sua introdução por P. Chen

em 1976, inúmeras extensões e variações foram propostas, as quais diferem em

pequenos aspectos quanto à notação e expressividade (Calvanese, 1999). Os

elementos básicos do modelo ER são entidades, relacionamento e atributos. Numa

visão simplificada, as entidades representam um conjunto de objetos, ou

instâncias, que possuem propriedades comuns. As propriedades elementares são

modeladas como atributos, cujos valores possuem domínios predefinidos, como

Integer, String e Boolean. Propriedades que são devidas a ralações entre entidades

são modeladas como relacionamentos.

Ferramentas de modelagem ER como, por exemplo, o Cool:Biz (CA, 2003),

disponibilizam mecanismos para exportação dos diagramas ER para documentos

em formato não proprietário, tornando possível a tranformação automática de

modelos ER para ontologias em OWL, de forma análoga ao item anterior.

4.2.4. Do Modelo Relacional

A razão para se utilizar uma abordagem baseada no modelo lógico de banco

de dados é que freqüentemente nenhum modelo conceitual está disponível quando

os sistemas de banco de dados encontram-se em produção. Naturalmente, o

mapeamento a partir destes modelos não preserva tanta informação quanto o

realizado a partir dos modelos conceituais, resultando em ontologias mais pobres.


Uma alternativa para obtenção da ontologia é através de engenharia reversa,

a partir do esquema físico do banco de dados, com posterior conversão em OWL.

Ferramentas de modelagem, como por exemplo, o ERWIN (Erwin, 2003),

disponibilizam mecanismos para exportação dos diagramas relacionais para

documentos textuais ou HTML, sendo permitida a configuração do formato e do

conteúdo a ser exportado, permitindo, de forma análoga ao visto anteriormente, a

conversão automática do modelo relacional para RDFS ou OWL.

Outra forma seria a utilização de extratores diretamente sobre o catálogo do

gerenciador do banco de dados. Neste caso, a extração seria feita quando

necessária e de forma dinâmica.

Algumas regras para este mapeamento podem ser definidas de modo a tentar

restaurar a semântica do modelo conceitual original. Estas regras podem ser

divididas nos seguintes grupos (Stojanovic, 2002).

Regras de conceitos

o C1 – toda relação (tabela) é convertida num conceito, com exceção

das regras C2 e C3;

o C2 – relações contendo apenas um par de chaves primárias não

geram conceitos, mas geram propriedades conforma P1;

o C3 – relações com chave primária comum são integradas num

único conceito, ou geram uma especialização conforme regras H1;

Regras de herança

o H1 – especialização da regra C3, em geral dependente de decisão

do usuário;

Regras de propriedades

o P1 – relacionamentos (n : m) derivada de C2, gerando propriedades

inversas nos conceitos correspondentes;

o P2 – relacionamentos (1 : n), gera o mesmo resultado de P1;

o P3 – decorrente de C3, propriedades são integradas num único

conceito;

o P4 – relacionamentos (1:1), gera o mesmo resultado de P1;


o P5 – relacionamentos de grau > 2, geram um conceito adicional e

um conjunto de propriedades correspondentes a P2;

o P6 – todo atributo relacional é convertido em propriedade, com

exceção das regras anteriores.

Neste trabalho, como veremos em capítulo seguinte, desenvolvemos uma

ferramenta para extração de ontologias a partir do catálogo do banco de dados

relacional Oracle. Esta ferramenta implementa algumas das regras mencionadas

acima, gerando um documento OWL com classes e propriedades.

4.3. Documentos Semi-estruturados

No caso de documentos que não possuam estrutura rígida, a construção de

um procedimento genérico para extração automática da ontologia se torna mais

complexo. Neste caso, de modo a aproveitar o máximo possível da estrutura

existente, parece mais razoável o tratamento individualizado da cada tipo de

documento. No estudo de caso, apresentado em capítulo à frente, uma ferramenta

para criação da taxonomia relativa a norma N-1710 (N-1710) seria de construção

relativamente simples, tendo em vista a numeração de seções e a formatação

existente para alinhamento do conteúdo apresentado.

Vários trabalhos e ferramentas têm sido desenvolvidos para geração de

conteúdo estruturado de forma semi-automática a partir de páginas HTML

(Laender, 2002). Nesta linha, estes trabalhos poderiam ser estendidos ou

utilizados como ponto de partida para ferramentas de criação de ontologias.

Outra abordagem interessante é a proposta no processo de construção de

ontologias a partir da transformação do LAL (Léxico Ampliado da Linguagem),

que procura preservar a semântica obtida na etapa de elicitação de sistema

(Breitman, 2003).


4.4. Documentos Não Estruturados

Vários trabalhos para aquisição de ontologias de forma semi-automática a

partir de documentos textuais e de páginas da Internet tem sido desenvolvidos no

meio acadêmico. Podem ser citados, por exemplo, os trabalhos relacionados ao

framework TEXT-TO-ONTO (Maedche, 2000 2001) (Kietz, 2000) (Erdmann,

2000). Algumas ferramentas como CYC-NL (CYC, 2003) e CORPORUM-

OntoBuild (Corporum, 2003) encontram-se disponíveis comercialmente.

Interconectando Ontologias 49

5 Interconectando Ontologias

5.1. Interoperabilidade Semântica

Com o objetivo de estabelecer o compartilhamento eficiente de dados,

muitos problemas técnicos devem ser enfrentados. Primeiramente, fontes

apropriadas de dados devem ler localizadas. Em seguida, os dados contidos nestas

fontes, normalmente heterogêneos, devem ser acessados de forma consistente. Isto

significa dizer que, de alguma forma, cada fonte de dado deve trabalhar em

conjunto com o sistema que está demandando por dados. O problema de se

colocar sistemas heterogêneos e distribuídos em funcionamento conjunto é

conhecido como problema de interoperabilidade.

A interoperabilidade deve ser atingida tanto no nível técnico quanto no nível

da informação propriamente dita. De modo resumido, o compartilhamento de

dados não necessita apenas que os estes sejam acessados, mas também que os

mesmos possam ser processados e integrados por outros sistemas. Os problemas

que podem surgir devido à heterogeneidade dos dados são bem conhecidos pela

comunidade de sistemas de banco de dados distribuídos: heterogeneidade

estrutural e heterogeneidade semântica.

Heterogeneidade estrutural significa que diferentes sistemas de informação

armazenam seus dados em estruturas com esquemas distintos. Heterogeneidade

semântica, por sua vez, considera o conteúdo dos dados e seu significado

desejado.

De modo a proporcionar interoperabilidade semântica, o significado dos

dados trocados entre os sistemas deve ser entendido de forma comum. Quando a

interpretação dos dados não é a mesma ocorrem os chamados conflitos semânticos

(Wache, 2001):


diferenças na estrutura de nomes, devido à presença de homônimos

ou sinônimos.

diferenças de referências usadas em valores de medições como, por

exemplo, no uso de diferentes moedas;

diferenças quanto ao contexto temporal, apesar das informações

aparentarem o mesmo significado;

O uso de ontologias para descrever o conhecimento implícito das fontes de

dados é uma aplicação chave para resolver os problemas de heterogeneidade

semântica. Muitas aplicações têm sido desenvolvidas neste sentido, entre elas:

BUSTER (Bremen University Semantic Translator for Enhanced Retrieval)

(Stuckenschmidt, 2000), OBSERVER (Ontology Based System Enhanced with

Relationship for Vocabulary hEterogeneity) (Mena, 1998), TSIMMIS (The

Stanford-IBM Manager of Multiple Information Sources) (Chawathe, 1994),

ONION (ONtology compositION) (Mitra, 2000) e KAON (Karlsruhe Ontology)

(Motik, 2002) (Maedche, 2002 2003).

Em praticamente todas as abordagens de integração baseadas em ontologias,

estas têm sido usadas para explicitar o conteúdo semântico das fontes de dados.

Contudo, as maneiras como as ontologias são empregadas podem ser diferentes.

Em geral, podem ser identificadas três abordagens principais: ontologia única,

ontologias múltiplas e ontologias híbridas (Wache, 2001).

Na abordagem de ontologia única, o vocabulário compartilhado para a

especificação da semântica é global. Todas as fontes de dados estão relacionadas

com uma única ontologia global. A ontologia global também pode ser uma

combinação de várias ontologias especializadas. Uma razão para tal pode ser a

composição de uma ontologia potencialmente mais abrangente obtida através de

mecanismos de importação de módulos de ontologias. A abordagem de ontologia

única pode ser aplicada na integração de fontes de dados que compartilhem

basicamente a mesma visão de um domínio. Porém, se uma das fontes tem uma

visão diferente como, por exemplo, um outro nível de detalhamento, torna-se

bastante difícil encontrar um comprometimento ontológico mínimo. Além disto,


esta abordagem é suscetível a modificações nas fontes de dados que possam afetar

a conceituação do domínio representado pela ontologia.

Na abordagem de ontologias múltiplas, cada fonte de informação é descrita

por sua própria ontologia. A princípio, uma “ontologia fonte” pode ser a

combinação de várias outras ontologias, mas não pode ser assumido que

diferentes ontologias fontes compartilhem o mesmo vocabulário. A vantagem

desta abordagem é que não é necessário um comprometimento mínimo comum

com uma ontologia global. Cada ontologia fonte pode ser desenvolvida sem levar

em consideração outras fontes e suas ontologias. Esta arquitetura de ontologias

pode simplificar a tarefa de integração e permite alterações, acrescentando ou

removendo fontes. Por outro lado, a falta de um vocabulário comum torna difícil a

comparação de diferentes ontologias fontes. Para superar este problema, um

formalismo adicional de representação para definição de mapeamento entre

ontologias é necessário. O mapeamento entre ontologias identifica termos com

correspondência semântica entre as ontologias fontes como, por exemplo, termos

que são semanticamente iguais ou semelhantes. Contudo, o mapeamento deve

considerar também diferentes visões de domínio, como é o caso de diferenças no

nível de agregação e detalhamento de conceitos.

As abordagens híbridas foram desenvolvidas com o objetivo de superar os

problemas encontrados nas abordagens anteriores. De forma semelhante à

abordagem de ontologias múltiplas, a semântica de cada fonte de dados é descrita

por ontologia própria. Mas, para tornar as ontologias locais comparáveis umas

com as outras, elas são construídas a partir de um vocabulário global

compartilhado. Este vocabulário contém os termos básicos de um domínio, que

são combinados nas ontologias locais de modo a descrever uma semântica mais

complexa. Algumas vezes, o vocabulário compartilhado é também uma ontologia.

A vantagem da abordagem híbrida é que novas fontes de dados podem ser

facilmente adicionadas sem necessidade de alteração global. Ela também suporta a

evolução das ontologias. O uso de um vocabulário compartilhado torna as

ontologias fontes comparáveis e evita as desvantagens da abordagem de

ontologias múltiplas. Contudo, a desvantagem das abordagens híbridas está no

fato das ontologias existentes não serem facilmente reutilizadas, devendo passar


por uma adequação de modo a garantir o comprometimento com o vocabulário

comun.

Si : sistemas de informação

Oi : representação das ontologias locais dos sistemas de informação

OG: ontologia global composta sobre as ontologias Oi

O’i : representação da participação de Oi na ontologia global

Figura 4 – Interconectando ontologias de sistemas de informação

Outro aspecto relevante a ser considerado é o da evolução das ontologias. A

dinâmica de negócio, assim como as mudanças no ambiente das aplicações, levam

a alterações continuadas nos requisitos das aplicações. Como conseqüência, de

modo a satisfazer esta necessidade, as ontologias destas aplicações também devem

sofrer evolução.

A evolução das ontologias é uma adaptação das mesmas ao longo do tempo

com relação aos requisitos de negócio, às tendências observadas nas ontologias,

aos padrões na utilização das aplicações baseadas em ontologia, assim como na

propagação de modificações para elementos de ontologias dependentes. A

modificação de parte de uma ontologia pode gerar inconsistências em outras

partes da mesma ontologia ou em ontologias e aplicações dependentes. Esta

variedade de causas e conseqüências torna a evolução das ontologias uma

operação complexa e delicada que requer uma análise cuidadosa dos tipos de

modificações possíveis e de todo o processo relacionados com a mesma. Apesar

desta evolução contínua ser um requisito essencial para o sucesso na utilização

S1

. . .

...

S3

OG

O’1 ...

O’n

O1

On

...


das ontologias, métodos e ferramentas para dar suporte completo a esta tarefa

complexa ainda não estão disponíveis (Ljiljana, 2002). Este nível de

gerenciamento de ontologias é necessário, não apenas no desenvolvimento inicial

e manutenção das ontologias, mas é essencial durante a implantação e operação

das aplicações, quando confiabilidade, disponibilidade, desempenho e facilidade

de crescimento em escala são requisitos absolutamente críticos.

A utilização de mecanismos de software para encapsulamento das

ontologias permite que elas sejam mantidas e evoluam com certa independência.

Estes mecanismos são conhecidos como wrappers (Sheth, 1999) (Schwarz, 1997)

(Papakonstantinou, 1995). Os wrappers são utilizados para o estabelecimento de

um canal de comunicação que seja independente do formato e da forma de

implementação das fontes de dados. São necessários wrappers para cada tipo de

organização de dados, mas o mesmo wrapper pode ser usado para acessar

diferentes repositórios com o mesmo tipo de organização. Por exemplo, wrappers

genéricos podem existir para fontes de dados ODBC ou arquivos tipo XML.

Para prover acesso uniforme e integrado às informações obtidas através dos

wrappers, são utilizados outros mecanismos denominados mediators

(Wiederhold, 1992 1995 1997) (Fensel, 2001). Um mediator é um sistema que

executa o papel de articulador das diversas fontes de informação. Pode ser visto

como uma fonte de dados secundária, que provê uma interface uniforme para as

diversas fontes de dados subjacentes (Tzitzikas, 2002). O mediator possui um

conjunto de articulações que representam as relações entre os seus termos

(ontologia global) e os termos de suas fontes (ontologias locais). O mediator

utiliza essas articulações para “traduzir” consultas na sua ontologia para consultas

decompostas em termos das ontologias de suas fontes articuladas. Da mesma

forma, o mediator deve combinar as respostas de cada fontes e retornar um

resultado consolidado para o sistema solicitante.

É importante observar que a ontologia global não precisa ser

necessariamente uma entidade física, mas somente as articulações entre as

ontologias locais devem ser fisicamente armazenadas. Desta forma, ficam

estabelecidas duas camadas estruturais: a primeira trata de uma coleção de


ontologias tradicionais, relativamente estáticas, mantidas localmente; a segunda,

uma estrutura dinâmica para articulação de ontologias relacionadas ao contexto de

composição de aplicações. Como a composição é uma operação inerentemente

dinâmica, a estrutura de articulações pode ser mantida e evoluir conforme

necessidades e requisitos de negócio. Desta forma, a ontologia unificada

resultante tem uma estrutura limpa e flexível, com relativa independência entre as

fontes de informação e com grande facilidade de adaptação e evolução no nível

global (Wiederhold, 1999).

5.2. Princípios para o Mapeamento de Conceitos

Os princípios para o mapeamento entre ontologias podem ser classificados

de forma análoga à utilizada para consolidação de visões de banco de dados,

através da definição de três conceitos básicos: identidade, agregação e

generalização. Os tipos de inter-relacionamentos são formados a partir das várias

possibilidades de composição destes conceitos (Teorey, 1982).

Identidade é o mais simples e imediato dos três conceitos. Dois ou mais

elementos são ditos idênticos se possuem o mesmo significado semântico.

Contudo, não é necessário que elementos idênticos tenham a mesma representação

sintática. Uma outra forma de descrever uma relação de identidade é afirmando

que dois ou mais elementos são sinônimos.

Apesar do conceito de identidade ser bastante simples, a determinação de

instâncias sinônimas não é de fácil reconhecimento. Devido aos métodos de

representação inadequados, o conhecimento semântico dos dados é muito

limitado. Normalmente, um profundo conhecimento do ambiente do usuário é

necessário para determinar se existe alguma identidade semântica. As instâncias

de dois conceitos candidatas a uma relação de identidade podem formar uma

interseção ao invés de uma união. É difícil decidir se um ou ambos os conceitos

são capazes de cobrir a união de todas as instâncias.


O conceito de agregação é também bastante freqüente. Agregação refere-se

à idéia na qual um relacionamento entre elementos é considerado como sendo um

outro elemento de mais alto nível. A maior parte das agregações é de fácil

identificação, pois a maioria dos modelos de dados incorpora sintaxe que

representam a agregação.

Generalização é normalmente o princípio mais complexo de capturar, sendo

muitas vezes confundido com agregação. Enquanto a agregação pode ser pensada

como partes constituintes de um todo, a generalização diz respeito somente aos

conceitos que por si só representam o todo. Generalização faz referência ao

processo de abstração no qual um grupo de elementos é imaginado como um

elemento genérico suprimindo-se as diferenças entre os mesmos. Em muitos

casos, elementos similares não devem ser enquadrados num relacionamento de

identidade, mas de outro modo, devem ser representados como uma forma de

generalização.

Figura 5 – Agregação e Generalização de Conceitos

Uma outra abordagem para o mapeamento entre ontologias baseia-se em

encontrar similaridades ou diferenças entre os termos definidos em duas ou mais

ontologias (Hakimpour, 2001). Quatro níveis de similaridades entre definições de

conceitos podem ser identificados:

Definições disjuntas – este é o nível mais baixo de similaridade.

Dois conceitos ou relações são disjuntos se a conjunção de suas

A

C

B A

C

B

Agregação Generalização


definições implica em falso, ou seja, a interseção de suas extensões

(instâncias do conceito) resulta num conjunto vazio.

Definições sobrepostas – quando a conjunção das suas definições

intencionais não pode ser provada como sendo falsa. Isto é, uma

instância de um conceito pode ser instância do outro conceito,

implicando que as extensões dos respectivos conceitos apresentam

interseção.

Definições especializadas (sub-conceito ou sub-relação) – quando a

definição intencional do conceito de uma ontologia é uma

implicação da definição intencional do conceito da outra ontologia.

Assim, se um conceito é especialização de outro, todas as instâncias

do primeiro também são instâncias do segundo.

Definições iguais – este é o nível mais elevado de similaridade. É

estabelecido quando as definições intencionais de dois conceitos são

equivalentes. Deste modo, todas as instâncias de um conceito são

instâncias do outro e vice-versa. Assim sendo, cada conceito

representa uma especialização do outro e suas extensões são iguais.

O quadro seguinte representa os níveis de similaridade entre dois conceitos

A e B de ontologias distintas.

Figura 6 – Similaridade entre conceitos e relações

5.3. Criando Articulações entre Ontologias

A interoperabilidade semântica tem sido amplamente estudada em trabalhos

da área de sistemas de banco de dados heterogêneos e em sistemas de banco de

A AA A

B B B B

Disjunção Sobreposição Especialização Igualdade


dados múltiplos. Uma das estratégias utilizadas é o mapeamento de todos os

esquemas de sistemas num único sistema global de referência. Tal estratégia sofre

das mesmas desvantagens da abordagem utilizada na integração de informações.

Além disto, confiar nos usuários para resolver todos os relacionamentos

semânticos entre todas as informações dos mais variados sistemas, pressupõe

implicitamente que estes usuários sejam especialistas no domínio. Em

contrapartida, as lacunas semânticas podem ser resolvidas por um mecanismo de

articulações que tratem somente da interseção entre as fontes de informação que

sejam relevantes para cada aplicação (Mitra, 2000).

Desta forma, ontologias de mapeamento podem ser definidas contendo as

articulações entre os elementos (classes, propriedades e instâncias) das ontologias

das fontes de informação. Estas articulações são representadas por novos

elementos que fazem referência às URI’s dos elementos das ontologias fontes,

sem a necessidade de importação destas ontologias ou da redefinição dos

elementos originais. O exemplo a seguir, conforme será visto com mais detalhe na

próxima seção, define em OWL a articulação Plataforma, que relaciona a classe

de mesmo nome da ontologia referenciada por &sip como subclasse de

Instalação da ontologia referenciada por &n1710.

<owl:Class rdf:ID="Plataforma">

<rdfs:subClassOf rdf:resource="&n1710;Instalacao" />

<owl:sameClassAs rdf:resource="&sip;Plataforma" />

</owl:Class>

5.4. Mapeando Ontologias em OWL

Com o objetivo de permitir a composição de ontologias a partir de outras já

existentes, deve ser possível indicar que uma classe ou propriedade de uma

determinada ontologia é equivalente a uma classe (sameClassAs) ou propriedade

(samePropertyAs) de uma segunda ontologia. Esta capacidade deve ser utilizada

com cuidado, de modo a evitar a ocorrência de contradições do tipo “(todo A é B)


e (todo A é não B)” que levaria a um conjunto vazio, pois não há elementos que

possam satisfazer as duas sentenças simultaneamente.

O exemplo a seguir, que poderia ser utilizado numa ontologia de

equipamentos, define uma classe idêntica à classe Bomba da ontologia da norma

N-1710:

<owl:Class rdf:ID="Bomba">

<owl:sameClassAs rdf:resource="&n1710; Bomba "/>

</owl:Class>

Expressões de classes podem fazer parte da declaração sameClassAs, da

mesma forma que o utilizado em subClassOf:

<owl:Class rdf:ID="InstalacaoCampo">

<owl:sameClassAs>

<owl:Restriction>

<owl:onProperty rdf:resource="#temCampo" />

<owl:allValuesFrom rdf:resource="&sip;Campo" />

</owl:Restriction>

</owl:sameClassAs>

</owl:Class>

Desta forma, InstalacaoCampo corresponde exatamente às instalações

localizadas nos campos de produção de petróleo. A diferença entre este uso e o de

subClassOf está na distinção entre condição necessária e condição suficiente.

Com subClassOf, instalações localizadas nos campos não são necessariamente

InstalacaoCampo, que seria verdadeiro no caso de uso de sameClassOf.

subClassOf : InstalacaoCampo(x) -> temCampo(x,y) & Campo(y)

sameClassAs : InstalacaoCampo(x) -> temCampo(x,y) & Campo(y)

temCampo(x,y) & Campo(y) -> InstalacaoCampo(x)


O mecanismo sameIndividualAs, de forma semelhante ao empregado para

classes, define indivíduos idênticos:

<Plataforma rdf:ID="P-40">

<owl:sameIndividualAs rdf:resource="#PETROBRAS-40" />

</ Plataforma >

OWL não adota a suposição de nomes únicos. Apesar de dois nomes serem

diferentes, não significa dizer que fazem referência a indivíduos diferentes. O

exemplo a seguir, considerando-se a propriedade temCampo funcional, não

necessariamente representaria um conflito:

<owl:Thing rdf:about="#InstalaçãoBadejo">

< temCampo rdf:resource="#BD" />

< temCampo rdf:resource="#Badejo" />

</owl:Thing>

Simplesmente, significa que BD = Badejo, ou seja, representam o mesmo

objeto.

O mecanismo differentIndividualFrom tem o efeito oposto ao

sameIndividualAs:

<MetodoElevacao rdf:ID="GLC" />

< MetodoElevacao rdf:ID="GLI">

<owl:differentIndividualFrom rdf:about="#GLC "/>

</ MetodoElevacao >

< MetodoElevacao rdf:ID="GLP">

<owl:differentIndividualFrom rdf:about="#GLC"/>

<owl:differentIndividualFrom rdf:about="#GLI"/>

</ MetodoElevacao >

Esta é uma forma de garantir que os três valores sejam distintos. De outra

forma, mesmo definindo que um elemento Coluna possua apenas um valor para a


propriedade temMetodoElevacao, este poderia ter GLC e GLI ao mesmo tempo,

implicando nestes elementos serem idênticos.

5.5. Expressões de Classes em OWL

OWL fornece construtores adicionais para criação de classes. Estes

construtores são utilizados nas chamadas expressões de classes. OWL suporta as

operações básicas de conjuntos: interseção (intersectionOf), união (unionOf) e

complemento (complementOf). Além disto, classes podem ser definidas por

enumeração por meio do construtor oneOf. Também é possível definir que classes

são disjuntas.

Expressões de classes podem ser aninhadas sem necessidade da definição de

nomes para as classes intermediárias. Isto permite o uso de operações de

conjuntos para construir classes complexas a partir de classes anônimas ou classes

com restrições de valores.

Classes construídas com o uso de operações de conjunto são “fechadas”. Os

membros da classe ficam especificados de forma precisa.

<owl:Class rdf:ID="ColunaOleo">

<owl:intersectionOf rdf:parseType="Collection">

<owl:Class rdf:about="#Coluna" />

<owl:Restriction>

<owl:onProperty rdf:resource="#produzFluido" />

<owl:hasValue rdf:resource="#Oleo" />

</owl:Restriction>

</owl:intersectionOf>

</owl:Class>

Neste exemplo, ColunaOleo é exatamente a interseção da classe Coluna e

o conjunto de coisas que produzem Oleo. Isto significa que se alguma coisa é


Coluna e produz Oleo, então é um elemento de ColunaOleo. Caso não fosse um

conjunto fechado, pode-se dizer que elementos de ColunaOleo são Coluna e

produzem Oleo, mas não vice-versa.

O exemplo seguinte demonstra o uso do construtor unionOf. Este é

utilizado de forma análoga ao construtor intersectionOf:


<owl:unionOf rdf:parseType="Collection">

<owl:Class rdf:about="#PlataformaFixa" />

<owl:Class rdf:about="#PlataformaMovel" />

</owl:unionOf>

</owl:Class>

A classe Plataforma inclui ambos os elementos de PlataformaFixa como

os de PlataformaMovel. O exemplo abaixo é totalmente distinto:


<rdfs:subClassOf rdf:resource="#PlataformaFixa" />

<rdfs:subClassOf rdf:resource="#PlataformaMovel" />

</owl:Class>

Neste os elementos de Plataforma são um subconjunto da interseção de

PlataformaFixa com PlataformaMovel, o que é de se esperar que seja um

conjunto vazio.

O construtor complementOf seleciona todos os elementos de um domínio

que não pertencem a uma determinada classe:

<owl:Class rdf:ID="PlataformaFixa" />

<owl:Class rdf:ID="PlataformaMovel">

<owl:complementOf rdf:resource="#PlataformaFixa" />

</owl:Class>


A classe PlataformaMovel tem como membros todos os indivíduos que

não pertencem ao conjunto de PlataformaFixa. Representa a diferença entre

owl:Thing e PlataformaFixa, incluindo elementos de qualquer outra classe,

como Coluna e Campo. Portanto, o uso típico deste construtor é combinado com

outras operações:

<owl:Class rdf:ID="PlataformaMovel">

<owl:intersectionOf rdf:parseType="Collection">

<owl:Class rdf:about="#Plataforma"/>

<owl:Class>

<owl:complementOf rdf:resource="#PlataformaFixa" />

</owl:Class>

</owl:intersectionOf>

</owl:Class>

Deste modo, a classe PlataformaMovel é definida como sendo a interseção

de Plataforma com o conjunto de tudo que não é PlataformaFixa.

OWL fornece meios para definir uma classe via enumeração direta de seus

membros. Isto é feito com o construtor oneOf. Esta definição limita os elementos

da classe, de modo que nenhum outro pode ser declarado como pertencente à

mesma.

A próxima declaração define a classe Bombeio, cujos membros são os

indivíduos BCP, BCS, BH, BHJ, BM, BMP.

<owl:Class rdf:ID="Bombeio">

<rdfs:subClassOf rdf:resource="#MetodoElevacao"/>

<owl:oneOf rdf:parseType="Collection">

<owl:Thing rdf:about="#BCP"/>

<owl:Thing rdf:about="#BCS"/>

<owl:Thing rdf:about="#BH"/>

<owl:Thing rdf:about="#BHJ"/>

<owl:Thing rdf:about="#BM"/>


<owl:Thing rdf:about="#BMP"/>

</owl:oneOf>

</owl:Class>

A disjunção de um conjunto de classes pode ser expressa através do

construtor owl:disjointWith. Este garante que um indivíduo membro de uma

classe não pode ser simultaneamente um elemento de uma outra classe:

<owl:Class rdf:ID="Bombeio">

<rdfs:subClassOf rdf:resource="#MetodoElevacao"/>

<owl:disjointWith rdf:resource="#GasLift"/>

<owl:disjointWith rdf:resource="#PlungerLift"/>

</owl:Class>

O exemplo acima demonstra o uso de disjunção múltipla. Pode-se observar

que a classe Bombeio é disjunta de todos as outras. Porém, não se pode afirmar

que, por exemplo, GasLift e PlungerLift também sejam disjuntas entre si. Para

tal, deveria existir uma declaração owl:disjointWith para o par específico.

5.6. Categorias de Mapeamento

Tomando por base os princípios de identidade, agregação e

generalização/especialização e considerando as classes (C), propriedades (P) e

instâncias (I) de duas ontologias distintas A e B, podemos enumerar as formas

mais freqüentes de mapeamento, através da criação de articulações M e da

definição de propriedades por meio de restrições, nas seguintes categorias:


Articulações entre classes

Categoria Representação OWL

C1 - Identidade de classes

- as classes CA e CB são mapeadas como idênticas, por meio de CM

<owl:Class rdf:ID="CM "> <owl:sameClassAs rdf:resource="#CA"/> <owl:sameClassAs rdf:resource="#CB"/>

</owl:Class>

C2 - Agregação de classes

- CM possui propriedades restritas por CA e CB

<owl:Class rdf:ID="CM"> <rdfs:subClassOf>

<owl:Restriction> <owl:onProperty rdf:resource="#temCA"/> <owl:allValueFrom rdf:resource="#CA"/>

</owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf>

<owl:Restriction> <owl:onProperty rdf:resource="#temCB"/> <owl:allValueFrom rdf:resource="#CB"/>

</owl:Restriction> </rdfs:subClassOf>

</owl:Class> C3 - Generalização de classes - CM é um conceito mais geral que CA e CB

<owl:Class rdf:ID="CM "> <owl:UnionOf rdf:parseType=”Collection”>

<owl:Class rdf:about="#CA"/> <owl:Class rdf:about="#CB"/> </owl:UnionOf>

</owl:Class>

C4 - Especialização de classes - a articulação CM representa uma especialização de CA e CB

<owl:Class rdf:ID="CM "> < rdfs:subClassOf rdf:resource="#CA"/> < rdfs:subClassOf rdf:resource="#CB"/>

</owl:Class>

CA

CM

CB

CA

CM

CB

CA

CM

CB

CA

CM

CB


C5 - Agregação entre classes com restrição - CB é mapeada como tendo uma propriedade restrita por CA, por meio da articulação CM

<owl:Class rdf:ID="CM"> <rdfs:subClassOf>

<owl:Restriction> <owl:onProperty rdf:resource="#temCA"/> <owl:allValueFrom rdf:resource="#CA"/>

</owl:Restriction> </rdfs:subClassOf> <owl:sameClassAs rdf:resource="#CB"/>

</owl:Class>

C6 - Especialização/generalização entre classes - CA é mapeada como subclasse de CB, por meio da articulação CM

<owl:Class rdf:ID="CM"> <owl:sameClassAs rdf:resource="#CA"/> <rdfs:subClassOf rdf:resource="#CB"/>

</owl:Class>

C7 - Especialização de classes com restrição - CM é mapeada como especialização de CA e tendo uma propriedade restrita por CB

<owl:Class rdf:ID="CM"> <rdfs:subClassOf rdf:resource="#CA"/> <rdfs:subClassOf>

<owl:Restriction> <owl:onProperty rdf:resource="#temCB"/> <owl:allValueFrom rdf:resource="#CB"/>


</owl:Class>

CA

CM

CB

CA

CM

CB

CA

CM

CB


Articulações entre propriedades

P1 - Identidade de propriedades - as propriedades PA e RB são mapeadas como idênticas, por meio de PM

<owl:ObjectProperty rdf:ID="PM "> <owl:samePropertyAs rdf:resource="#PA"/> <owl:samePropertyAs rdf:resource="#PB"/>


P2 - Especialização/generalização entre propriedades - PA é mapeada como sub-propriedade de PB, por meio de PM

<owl:ObjectProperty rdf:ID="PM "> <owl:samePropertyAs rdf:resource="#PA"/> <rdfs:subPropertyOf rdf:resource="#PB"/>


Articulações entre instância/classe

I1 - Identidade de instâncias - IA e IB são mapeadas como idênticas, por meio da instância IM

<owl:Thing rdf:ID="IM "> <owl:sameIndividualAs rdf:resource="#IA"/> <owl:sameIndividualAs rdf:resource="#IB"/>

</owl:Thing>

I2 - Generalização de instâncias - IA e IB são mapeadas como instâncias da mesma classe CM

<owl:Thing rdf:about="#IA"> <rdf:type rdf:resource="#CM"/> </owl:Thing> <owl:Thing rdf:about="#IB"> <rdf:type rdf:resource="#CM"/> </owl:Thing>

IA

IM

IB

IA

CM

IB

PA

PM

PB

PA

PM

PB


I3 - Especialização classe/instância - IA é mapeada como instância de CB, por meio de IM

<owl:Thing rdf:about="#IM"> <owl:sameIndividualAs rdf:resource="#IA"/> <rdf:type rdf:resource="#CB"/>

</owl:Thing>

I4 - Restrição classe/instância - CA é mapeada como tendo uma propriedade restrita por IB, por meio de CM

<owl:Class rdf:ID="CM"> <owl:sameClassAs rdf:resource="#CA"/> <rdfs:subClassOf>

<owl:Restriction> <owl:onProperty rdf:resource="#temCB"/> <owl:hasValue rdf:resource="#IB"/>


</owl:Class>

I5 - Especialização classe/instância com restrição - CM é mapeada como sendo subclasse de CA e tendo uma propriedade restrita por IB

<owl:Class rdf:ID="CM"> <rdfs:subClassOf rdf:resource="#CA"/> <rdfs:subClassOf>

<owl:Restriction> <owl:onProperty rdf:resource="#temCB"/> <owl:hasValue rdf:resource="#IB"/>


</owl:Class>

As articulações entre instância/classe podem ser desconsideradas se a

linguagem de ontologia permitir o tratamento de instâncias como classes, como no

caso de OWL Full.

Além disto, em OWL, como em outras linguagens de ontologia, classes e

propriedades são definidas com escopo global, estando todos os seus elementos

declarados num mesmo nível. Desta forma, o mapeamento pode ser realizado sem

levar em consideração a estrutura interna dos elementos, não havendo a

necessidade da utilização de expressões de caminho. Deste modo, qualquer

Identidade Instância

IA

IM

CB

Subclasse

Restrição

CA

CM

IB

CA

CM

IB


referência a um conceito, uma propriedade ou mesmo uma instância pode ser feita

diretamente a partir de sua URI, não sendo necessário qualquer tipo de

qualificação adicional. Em contrapartida, fica clara a necessidade de identificação

única dos elementos de uma ontologia, assim, um método adequado para

estabelecimento das URI’s deve ser cuidadosamente estabelecido. Neste trabalho

não serão feitas maiores considerações a este respeito, sendo apenas ressaltado

este ponto como de interesse para um estudo mais detalho em trabalhos futuros.

As combinações das categorias acima relacionadas cobrem os casos mais

comuns das possibilidades de mapeamentos entre conceitos, relações e instâncias

de ontologias diversas. Contudo, ainda há necessidade do mapeamento no que diz

respeito às diferenças quanto a tipo de atributo e nível de agregação (Visser,

1997). Nestes casos, faz-se necessária a introdução de funções de conversão e

manipulação de tipo e formatos, assim como funções de agregação semelhantes às

utilizadas em banco de dados (SUM, COUNT, MAX, MIN, AVG). Vários

trabalhos tem sido realizados no sentido de estender Description Logics para

incorporar este tipo de funcionalidade (Ross, 1994) (Levy, 1996) (Baader, 1998).

Por outro lado, linguagens de consulta como RQL (Karvounarakis, 2002) também

poderiam ser utilizadas, em conjunto com as linguagens de ontologia, para

atendimento destas necessidades. Uma alternativa, com aplicabilidade mais

imediata, seria resolver este tipo de conflito no nível da origem da informação,

deixando assim o problema para a camada correspondente aos wrappers, que

poderiam disponibilizar uma ontologia mais “adaptada” para o ambiente externo à

fonte de informação. No entanto, esta não seria a solução mais adequada, por

haver necessidade de manutenção das ontologias fontes em função de

necessidades externas, além de ser uma solução pouco flexível no contexto global.

Estudo de Caso 69

6 Estudo de Caso

6.1. Introdução

Duas fontes de informação, apresentando diferentes tipos de estrutura,

foram escolhidas como exemplo para o estudo de caso:

N1710 – Norma de Codificação de Documentos Técnicos da

Petrobras (N-1710);

SIP – Sistema de Informação da Petrobras – Módulo de

Acompanhamento de Anormalidade em Poços (SIP).

A norma N1710 tem como objetivo uniformizar e sistematizar a codificação

dos documentos técnicos de engenharia da Petrobras, padronizando a terminologia

utilizada para identificação das instalações, áreas de atividades, classes de

serviços e equipamentos, categorias e origens dos documentos. Esta norma está

organizada num manual na forma de documento textual, encontrando-se também

disponível em formato pdf na intranet corporativa.

O Módulo de Acompanhamento de Anormalidade em Poços do SIP busca o

acompanhamento de problemas que afetam a produção dos poços produtores de

óleo e gás, registrando para tal informações sobre falhas relativas aos sistemas e

equipamentos, condições de operação de poços, como mecanismo de elevação,

plataforma e campo de produção. Este sistema encontra-se disponível na rede

Petrobrás e possui uma arquitetura cliente/servidor. Seus dados encontram-se

armazenados em um banco de dados Oracle.

A ontologia relativa à N1710 (Anexo A) foi obtida de forma manual,

limitando-se aos conceitos necessários ao exemplo em questão (uma abordagem

Estudo de Caso 70

interessante seria a manutenção de toda a ontologia em OWL, a partir da qual

seria gerado, de forma automática, o documento textual correspondente).

No caso da ontologia do SIP (Anexo B), utilizamos o modelo entidade-

relacionamento do referido módulo mas, caso este não estivesse disponível,

poderíamos ter gerado sua ontologia com a ferramenta de extração (ver capítulo 7)

a partir do catálogo Oracle. Para obtenção das instâncias é necessária a construção

de um wrapper, que faça o mapeamento de SQL para OWL.

Para facilidade de entendimento, o exemplo foi dividido em três partes,

correspondentes ao mapeamento das instalações, das atividades e dos

equipamentos, conforme descrito a seguir. Os anexos A, B e C apresentam trechos

das ontologias geradas e o mapeamento em mais detalhes.

6.2. Mapeamento das Instalações

O mapeamento das instalações (Plataforma e Campo) permite o

cruzamento de informações relativas a poços e dados de produção com a

documentação técnica correspondente destas instalações.

Como algumas unidades móveis (N-1710) correspondem a plataformas

(SIP), mas nem todas as plataformas são unidades móveis, o mapeamento

representa a interseção dos dois conjuntos, podendo ser descrito em OWL da

seguinte forma:


<rdfs:subClassOf rdf:resource="&sip;Plataforma" />

<rdfs:subClassOf rdf:resource="&n1710;EP_PRO" />

</owl:Class>

Para possibilitar o cruzamento das instâncias, faz-se necessário o

mapeamento individualizado das mesmas, conforme o exemplo abaixo:

Estudo de Caso 71

<Plataforma rdf:ID="P-40">

<owl:sameAs rdf:resource="&n1710;B3010.57" />

<owl:sameAs rdf:resource="&sip;P-40" />

</owl:Class>

Figura 7 – Mapeamento de Instalações

Com relação ao mapeamento dos campos, os conceitos da norma N-1710

correspondem a classes de instalações localizadas num determinado campo de

produção de petróleo, enquanto no SIP estes representam instâncias de um

conceito. Desta forma, o mapeamento deve relacionar conceitos de uma ontologia

com instâncias da outra. Isto pode ser feito em OWL através do uso de restrições:

Estudo de Caso 72

<owl:Class rdf:ID="InstalacaoCampo">

<rdfs:subClassOf rdf:resource="&n1710;EP_PRO" />

</owl:Class>

<owl:ObjectProperty rdf:ID="temCampo">

<rdfs:domain rdf:resource="#InstalacaoCampo" />

<rdfs:range rdf:resource="&sip;Campo" />


<owl:Class rdf:ID="InstalacaoBadejo">

<owl:sameAs rdf:resource="&n1710;Badejo" />

<rdfs:subClassOf rdf:resource="InstalacaoCampo" />

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="#temCampo" />

<owl:hasValue rdf:resource="&sip;BD" />

</owl:Restriction>

</rdfs:subClassOf>

</owl:Class>

6.3. Mapeamento das Atividades

Com o mapeamento das atividades (Elevação artificial e Sistema de

equipamento) pode-se relacionar a documentação correspondente aos processos

relativos a estas atividades utilizados na produção.

O mapeamento das atividades pode ser realizado de forma semelhante ao

feito para os campos. Neste caso, as classes de atividades da N-1710 devem ser

mapeadas para instâncias de sistema de equipamentos do SIP. No que diz respeito

aos conceitos mais gerais, AreaAtividade e SistemaEquipamento, a

Estudo de Caso 73

correspondência pode ser feita por meio de uma subclasse de AreaAtividade que

tenha uma restrição com relação a SistemaEquipamento:

<owl:Class rdf:ID="AtividadeSistema">

<rdfs:subClassOf rdf:resource="&n1710;AreaAtividade" />

</owl:Class>

<owl:ObjectProperty rdf:ID="temSistemaEquipamento">

<rdfs:domain rdf:resource="#AtividadeSistema" />

<rdfs:range rdf:resource="&sip;SistemaEquipamento" />


<owl:Class rdf:ID="InjecaoQuimica">

<rdfs:subClassOf rdf:resource="AtividadeSistema" />

<owl:sameAs rdf:resource="&n1710;InjecaoQuimica" />

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="#temSistemaEquipamento" />

<owl:hasValue rdf:resource="&sip;IQ" />

</owl:Restriction>

</rdfs:subClassOf>

</owl:Class>

No caso da atividade de elevação artificial, o mapeamento é um pouco mais

complexo, pois as instâncias da classe ElevacaoArtificial da N-1710

correspondem a um conjunto de instâncias da classe MetodoElevacao do SIP.

Assim, faz-se necessária a criação de classes de mapeamento para enumerar as

instâncias da última que correspondam a cada instância da primeira:

<owl:Class rdf:ID="AtividadeElevacao">

</owl:Class>

<owl:ObjectProperty rdf:ID="temElevacaoArtificial">

Estudo de Caso 74

<rdfs:domain rdf:resource="#AtividadeElevacao" />

<rdfs:range rdf:resource="&n1710;ElevacaoArtificial" />


<owl:ObjectProperty rdf:ID="temMetodoElevacao">

<rdfs:domain rdf:resource="#AtividadeElevacao" />

<rdfs:range rdf:resource="&sip;MetodoElevacao" />


<owl:Class rdf:ID="GasLift">

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="#temElevacaoArtificial" />

<owl:hasValue rdf:resource="&n1710;GasLift" />

</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="#temMetodoElevacao" />

<owl:allValuesFrom>

<owl:Class>

<owl:oneOf rdf:parseType="Collection">

<owl:Item rdf:resource="&sip;AGL" />

<owl:Item rdf:resource="&sip;GFC" />

<owl:Item rdf:resource="&sip;GFI" />

<owl:Item rdf:resource="&sip;GLC" />

<owl:Item rdf:resource="&sip;GLI" />

<owl:Item rdf:resource="&sip;GLP" />

</owl:oneOf>

</owl:Class>

</owl:allValuesFrom>

</owl:Restriction>

</rdfs:subClassOf>

</owl:Class>

Estudo de Caso 75

Figura 8 – Mapeamento de Atividades

6.4. Mapeamento dos Equipamentos

Finalmente, o mapeamento dos equipamentos possibilita a correlação das

classes de equipamento da N-1710 com a classe de componente do SIP.

De forma semelhante aos anteriores, o mapeamento pode ser feito em dois

níveis. O primeiro relaciona os conceitos mais gerais, enquanto no segundo são

criadas classes para mapear as instâncias dos componentes com cada classe de

equipamento:

Estudo de Caso 76

<owl:Class rdf:ID="Equipamento">

<rdfs:subClassOf rdf:resource="&n1710;ServEquipMat" />

</owl:Class>

<owl:ObjectProperty rdf:ID="temClasseComponente">

<rdfs:domain rdf:resource="#Equipamento" />

<rdfs:range rdf:resource="&sip;Componente" />


<owl:Class rdf:ID="Bomba">

<rdfs:subClassOf rdf:resource="Equipamento" />

<owl:sameAs rdf:resource="&n1710;Bomba" />

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="#temClasseComponente" />

<owl:hasValue rdf:resource="&sip;BB" />

</owl:Restriction>

</rdfs:subClassOf>

</owl:Class>

Figura 9 – Mapeamento de Equipamentos

Estudo de Caso 77

A partir deste mapeamento podem ser realizadas consultas e/ou

desenvolvidas aplicações que possibilitem a visualização integrada das

informações disponíveis em ambas as fontes de informação. Por exemplo,

relatórios que mostrem os problemas ocorridos em plataformas com os

documentos associados ao tipo de atividade afetada, ou ainda, um estudo

relacionando documentação de equipamentos de um conjunto de instalações e os

volumes de produção perdidos em função dos motivos de falhas ocorridos, etc.

6.5. Avaliação

Analisando-se as formas de mapeamento utilizados neste estudo de caso,

podemos constatar que, com exceção das articulações correspondentes ao

mapeamento da atividade GasLift, todas as demais se enquadram nas catagorias

de mapeamento definidas na seção 5.3, conforme apresentado na seguinte tabela:

Articulação Categoria

Map.Plataforma C4

Map.P-40 I1

Map.InstalacaoCampo C7

Map.InstalacaoBadejo I4

Map.AtividadeSistema C7

Map.InjecaoQuimica I4

Map.AtividadeElevacao C2

Map.GasLift -

Map.Equipamento C7

Map.Bomba I4

O caso do Map.GasLift também poderia ser enquadrado na categoria I5 se

considerarmos a classe intermediária Map.owlOneOf como parte integrante de

Estudo de Caso 78

uma única articulação, visto que pode ser definida como uma expressão de classe

interna à definição de Map.GasLift.

Desta forma, pode-se esperar que, apesar de relativamente simples, as

categorias aqui discutidas atendam a maioria das situações encontradas na prática.

Arquitetura de Implementação 79

7 Arquitetura de Implementação

7.1. Visão Geral

A maioria das abordagens recentes integração de informações se baseia na

arquitetura de mediadores (Mediator Architecture) proposta por Wiederhold

(Wiederhold, 1992). Nesta arquitetura, várias fontes de informações são

encapsuladas por módulos de softwares conhecidos como wrappers. Estes são

responsáveis pela tradução entre as linguagens, modelos e conceitos das fontes

locais para a visão global. Outros componentes de sistema, denominados

mediators, obtém informação de um ou mais componentes do nível abaixo, que

podem ser wrappers de fontes locais ou outros mediators. Esta arquitetura pode

ser esquematizada na seguinte forma (Ullman, 1997):

Figura 10 – Arquitetura padrão de integração

Mediator

Mediator

Wrapper Wrapper

Fonte Fonte

Sistema Externo


Alguns exemplos, onde esta arquitetura foi seguida, são os projetos Information

Manifold (Kirk, 1995), TSIMMIS (Chawathe, 1994), KRAFT (Wache, 2001),

OBSERVER (Mena, 1998), BUSTER (Stuckenschmidt, 2000), ONION (Mitra, 2000),

DOME (Cui, 2000) e MOMIS (Bergamaschi, 1998) entre outros.

Esta arquitetura também pode ser utilizada no contexto aqui apresentado.

Desta forma, os wrappers seriam responsáveis pela tradução do conteúdo de cada

fonte de informação para a visão global representada por meio de ontologias. Por

sua vez, os mediators ficariam encarregados pela coordenação dos wrappers e na

disponibilização de uma visão integrada das ontologias para os sistemas externos.

Si : sistemas de informação distribuídos

Di : fontes de dados dos sistemas de informação

Oi : ontologias locais dos sistemas de informação

Wi : wrappers para padronização do acesso às fontes

M : mediator para articulação das fontes

OG: ontologia global composta sobre as ontologias Oi

O’i : representação da participação de Oi na ontologia global

ED : editor de ontologias OWL

NV : navegador para consultas às ontologias

SOi : sistemas de informação orientados a ontologia.

Figura 11 – Arquitetura para interconexão de sistemas de informação

S1

O1 D1 W1

M

OG

O’1 ...

O’n

...

... ...

Sn

On Dn Wn

NV ED

SOn

.

...

SO1 ....


De um modo geral, os wrappers devem ser capazes de fornecer as

informações sobre o esquema (classes e propriedades) e também próprios dados

(instâncias). Enquanto os mediators devem responder sobre a visão global como,

por exemplo, através do uso de mecanismos de inferência.

Sobre a visão global podem ser construídos os sistemas orientados a

ontologias desenvolvidos, deste modo, com total independência quanto às fontes

de informações. Da mesma forma, podem ser utilizadas ferramentas gerais para

consulta, edição e mapeamento entre ontologias.

7.2. Modelo Wrapper/Mediator

Tendo em vista a necessidade de distribuição da arquitetura proposta, o

seguinte modelo de classe é apresentado como uma alternativa de solução para

atendimento desta característica:

Figura 12 – Modelo Wrapper/Mediator


Nesta proposta, é introduzido um wrapper remoto (WrapperRemote) com o

objetivo de efetuar a comunicação entre ontologias armazenadas em servidores

distribuídos. Várias alternativas de middleware e protocolos podem ser utilizados

para prover esta comunicação, bastando para isto, o desenvolvimento de um

wrapper especializado.

Da mesma forma que wrappers gerais para acesso a base de dados

relacionais ou arquivo convencionais OWL, podem ser desenvolvidos wrappers

específicos (WrapperX) para cada um dos sistemas de informação que faça parte

da solução integrada. Estes wrappers possibilitariam que a semântica destes

sistemas, contida no código, interface e modelo conceitual, seja retrata de forma

mais fiel em sua ontologia correpondente.

7.3. Editor OWL

Um editor de ontologias em OWL é o mais imediato dos componentes

“externos” a ser pensado. Este editor seria o responsável pela criação e

manutenção das ontologias das fontes de informação, assim como pela edição da

ontologia da visão global contendo o mapeamento entre as locais. Podemos

enumerar alguns dos principais requisitos deste editor:

criar, modificar e salvar localmente as ontologias de usuários;

visualizar ontologias remotas de outros usuários ou sistemas;

permitir que os elementos sejam arrastados e/ou copiados entre as

janelas de visualização de ontologias (Drag & Drop / Copy & Paste);

possibilitar que a linguagem OWL seja modificada e estendida sem a

necessidade de maiores restruturações no nível de programação;

permitir visualizar a hierarquia de conceitos da ontologia;

permitir a visualização das propriedades de cada um dos conceitos;

possibilitar a visualização das intâncias dos conceitos de forma

independente dos conceitos e propriedades;


facilitar o mapeamento entre ontologias, por exemplo, com a criação

automática de namespaces quando forem feitas referências a elementos

externos;

Figura 13 – Editor OWL

No protótipo desenvolvido neste trabalho, foi possível avaliar algumas

alternativas de modelagem para o editor OWL, tendo em vista principalmente o

requisito de possibitar e extensão da linguagem da forma mais transparente

possível. A versão inicial do modelo implementa uma classe para cada um dos

elementos da linguagem, tornando a alteração do código necessária a cada

evolução da especificação OWL. Uma alternativa seria a utilização de um arquivo

externo definido, por exemplo, em XMLSchema, para configuração do editor.

Porém, esta opção somente permite a configuração da estrutura sintática da

linguagem, não sendo possível o tratamento semântico de seus elementos.


Desta forma, uma hipótese em que a modelagem interna do editor seja

independente da linguagem OWL nos parece mais interessante. Neste caso, a

correspondência semântica, entre este modelo interno e os elementos OWL, deve

ser mapeada em um arquivo externo de configuração. Mesmo assim, ainda haverá

a necessidade da alteração do código quando da inclusão de algum elemento da

linguagem OWL que não possua correspondente semântico no modelo interno do

editor. Esta alternativa foi parcialmente testada e será avaliada mais

detalhadamente em trabalho futuro.

7.4. Wrapper Oracle

Outra ferramenta relevante no contexto de integração de sistemas legados

seria um extrator que criasse uma ontologia básica a partir de uma banco de dados

relacional. Com esse objetivo, foi desenvolvido no presente trabalho um wrapper

especializado para a criação de uma ontologia a partir do catálogo de uma base

Oracle. Foram utilizadas algumas das regras descritas no capítulo de explicitação

de ontologias para definição dos conceitos e propriedades a partir de tabelas,

atributos e chaves estrangeiras.

Figura 14 – Wrapper Oracle


Outra funcionalidade interessante de um wrapper para bases relacionais

seria a possibilidade de dar persistência às ontologias criadas pelos usuários.

Neste caso, regras para criação automática do esquema relacional a partir da

definição em OWL devem ser cuidadosamente investigadas. Este também

pretende ser um de nossos pontos de interesse para trabalhos futuros.

Conclusão 86

8 Conclusão

8.1. Contribuições

Este trabalho busca discutir alguns pontos relacionados com o problema da

interoperabilidade dos sistemas de informação. São apresentados os conceitos

relacionados à integração semântica, através do uso de ontologias associadas às

fontes de informação e da composição destas numa ontologia global. Também

aborda o uso de componentes básicos, como wrappers e mediators, para a

construção de uma arquitetura geral de integração. Assim como, apresenta a

linguagem OWL, que pretende ser o padrão W3C para definição de ontologias,

em especial para sistemas no ambiente Web.

Como contribuição pode ser destacada a definição de padrões básicos para

mapeamento de conceitos entre ontologias. Estes padrões devidamente

combinados permitem resolvar a grande maioria das situações de mapeamento

encontradas na prática. Outro ponto a se destacar é a utilização de uma notação

gráfica, baseada em UML, para representação do mapeamento de forma simples e

compacta.

Como resultado, é apresentado o protótipo inicial de uma arquitetura para

tratar da integração dos sistemas de informação em ambientes heterogêneos e

distribuídos, freqüentemente encontrados em grandes corporações.

Com o objetivo de validar as principais idéias apresentadas, está sendo

implementado um editor de ontologias baseado na linguagem OWL. Este

permitirá a criação de novas ontologias, assim como, a composição a partir de

ontologias fontes preexistentes. Também foi construída uma versão simplificada

de um extrator de ontologia para banco de dados Oracle, que serve como gerador

de ontologias fontes a serem utilizadas pelo Editor.

Conclusão 87

8.2. Trabalhos Futuros

Como prosseguimento do presente trabalho, serão desenvolvidas as

seguintes atividades:

conclusão do editor OWL – atualização de sintaxe da linguagem com

relação à última liberação prevista para final de junho/2003 e

melhorias na interface de usuário;

implementação de regras adicionais no extrator OWL para banco de

dados Oracle;

avaliação de bibliotecas disponíveis, que possuam recursos de

inferência, para desenvolvimento do módulo mediator;

análise das alternativas de middleware para implementação da

arquitetura, ou seja, escolha entre Web Services, J2EE ou CORBA;

implementação de um protótipo de integração correspondente ao

estudo de caso avaliado;

Referências Bibliográficas 88

9 Referências Bibliográficas

Arens, Y.; Chee, C.; Hsu C.; Knoblock, C. Retrieving and Integrating Data

from Multiple Information Sources. In Journal of Intelligent and

Cooperative Information Systems, Vol. 2, June 1993. Disponível em

http://citeseer.nj.nec.com/arens93retrieving.html

Baader F.; Sattler U. Description logics with concrete domains and

aggregation. In H. Prade, editor, Proceedings of the Thirteenth European

Conference on Articial Intelligence ECAI-98, Brighton, August 23-28,

1998. John Wiley & Sons, New York, 1998. Disponível em

http://citeseer.nj.nec.com/article/baader98description.html.

Bergamaschi, S.; Castano, S.; De Capitani di Vimercati; Montanari S.; Vincini,

M. A Semantic Approach to Information Integration: the MOMIS

project. Sesto Convegno della Associazione Italiana per l'Intelligenza

Artificiale, AI*IA 98, Padova IT, Settembre 1998. Disponível em

http://citeseer.nj.nec.com/bergamaschi98semantic.html .

Berners-Lee, T.; What the Semantic Web can represent, 1998. Disponível em

http://www.w3.org/DesignIssues/RDFnot.html.

Berners-Lee, T.; Fielding, R.; Masinter, L. Uniform Resource Identifiers (URI):

Generic Syntax. Internet Draft Standard RFC 2396, August 1998.

Disponível em http://www.ietf.org/rfc/rfc2396.txt.

Berners-Lee, T.; Connolly, D.; Swick, R. Web Architecture: Describing and

Exchanging Data, W3C Note 7 June 1999. Disponível em

http://www.w3.org/1999/04/WebData.

Berners-Lee, T.; Hendler, J.; Lassila, Ora. The Semantic Web. Scientific

American, May 2001. Disponível em http://www.scientificamerican.com

/article.cfm?articleID=00048144-10D2-1C70-84A9809EC588EF21&c.

Berners-Lee, T.; Hendler, James; Miller, Eric. Integrating Applications on the

Semantic Web. Journal of the Institute of Electrical Engineers of Japan,


Vol 122(10), October, 2002, p. 676-680. Disponível em

http://www.w3.org/2002/07/swint.

Berners-Lee, T.; Miller, Eric. The Semantic Web lifts off. W3C. ERCIM News

No. 51, October 2002. Disponível em http://www.ercim.org/

publication/Ercim_News/enw51/berners-lee.html.

Breitman, Karin; Leite, Julio Cesar. Lexicon Based Ontology Construction. In

2nd International Workshop on Software Engineering for Large-Scale Multi-

Agent Systems(SELMAS), 2003.

CA. Cool Biz. Computer Associates International, Inc. http://support.ca.com/

public/ cool/biz/bizsupp.html.

Calvanese, Diego; Giacomo, Giuseppe De; Lenzerini, Maurizio; Nardi, Daniele;

Rosati, Riccardo. Information integration: Conceptual modeling and

reasoning support. In Proceedings of the 6th International Conference on

Cooperative Information Systems (CoopIS'98), pages 280--291,1998.

Disponível em http://citeseer.nj.nec.com/calvanese98 information. html

Calvanese, D.; Lenzerini M.; Nardi, D. Unifying class-based representation

formalisms. Journal of Artificial Intelligence Research, 1999. Disponível

em http://citeseer.nj.nec.com/calvanese99 unifying.html

Chawathe, S.; Garcia-Molina, H.; Hammer, J.; Ireland, K.; Papakonstantinou, Y.;

Ullman, J.; Widom, J. The TSIMMIS Project: Integration of

Heterogeneous Information Sources. In Proc. of IPSJ Conference, pages

7--18, 1994. Disponível em http://citeseer.nj.nec.com/

chawathe94tsimmis.html

CORPORUM. OntoBuild. Cognit. Disponível em http://ontoserver.cognit.no/

about.asp.

Cranefield, S. Networked Knowledge Representation and Exchange using

UML and RDF. Journal of Digital information, volume 1 issue 8, Febr.

2001, Disponível em http://jodi.ecs.soton.ac.uk/Articles/v01/i08/

Cranefield/.

Cui, Zhan; O'Brien, Paul. Domain Ontology Management Environment. 33rd

Hawaii International Conference on System Sciences-Volume 8 HICSS

2000 p. 8015 January 04 - 07, 2000 Maui, Hawaii.

Cyc. CYC-NL Natural Language Processing. CYCORP. Disponível em

http://www.cyc.com/products2.html.


DAML. DAML-ONT initial release. Disponível em http://www.daml.org/

2000/10/daml-ont.html

DAML+OIL. DAML+OIL (March 2001). Disponível em http://www.daml.org/

2001/03/daml+oil-index.html.

Erdmann, M.; Maedche, A.; Schnurr P.; Steffen Staab. From manual to semi-

automatic semantic annotation: About ontology-based text annotation

tools. In P. Buitelaar & K. Hasida (eds). Proceedings of the COLING 2000

Workshop on Semantic Annotation and Intelligent Content, Luxembourg,

August 2000. Disponível em http://citeseer.nj.nec.com/

erdmann00from.html.

Erwin. Computer Associates International. AllFusion ERwin Data Modeler.

2003. Disponível em http://www3.ca.com/Solutions/Product.asp? ID=260.

Fensel, Dieter. Ontologies: Silver Bullet for Knowledge Management and

Electronic Commerce. Springer Verlag; 1st edition August 15, 2001.

Guarino, N. Formal Ontology and Information Systems. In N. Guarino, editor,

Proceedings of the 1st International Conference on Formal Ontologies in

Information Systems, FOIS'98, Trento, Italy, pages 3-- 15. IOS Press, June

1998. Disponível em http://citeseer.nj.nec.com/ guarino98formal.html.

Hakimpour, Farshad; Geppert, Andreas. Resolving semantic heterogeneity in

schema integration: An ontology base approach. In Chris Welty and

Barry Smith, editors, Proceedings of International conference on Formal

Ontologies in Information Systems FOIS'01. ACM Press, October 2001.

Disponível em http://citeseer.nj.nec.com/ hakimpour01resolving.html

Horrocks, I.; Sattler, U.; Tobies, S. Practical reasoning for expressive

description logics. In Proceedings of LPAR'99, LNCS, Tbilisi, Georgia,

1999. Disponível em http://citeseer.nj.nec.com/article/horrocks99

practical.html.

Horrocks, Ian. DAML+OIL: a Reason-able Web Ontology Language.

Presented at EDBT 2002. Disponível em http://www.cs.man.ac.uk/

~horrocks/Publications/download/2002/ edbt02.pdf.

Karvounarakis, G.; Alexaki, S.; Christophides, V.; Plexousakis, D.; Scholl, M.

RQL: A Declarative Query Language for RDF. In The 11th Intl. World

Wide Web Conference WWW2002. Disponível em

http://citeseer.nj.nec.com/556066.html.


Kietz, U.; Volz, R.; Maedche, A. A method for semi-automatic ontology

acquisition from a corporate intranet. In EKAW. Disponível em

http://citeseer.nj.nec.com/kietz00method.html.

Kifer, Michael; Lausen, Georg ; Wu, James. Foundations of Object-Oriented

and Frame-Based Languages. Technical Report 90/14, Department of

Computer Science, State University of New York at Stony Brook (SUNY),

June 1990. Disponível em http://citeseer.nj.nec.com/ kifer90logical.html.

Kirk, T.; Levy, A. Y.; Sagiv, Y.; Srivastava, D. The Information Manifold. In

Proc. of the AAAI Spring Symposium on Information Gathering in

Distributed Heterogeneous Environments. Disponível em

http://citeseer.nj.nec.com/16242.html.

Laender, A.; Ribeiro-Neto, B.; Silva, A.; Teixeira, J. A Brief Survey of Web

Data Extraction Tools. In SIGMOD Record, Volume 31, Number 2, June

2002. Disponível em http://citeseer.nj.nec.com/ laender02brief.html.

Levy, Alon Y.; Mumick, Inderpal Singh. Reasoning with aggregation

constraints. In Proceedings of the Conference on Extending Database

Technology, EDBT-96, (March 1996). Disponível em

http://citeseer.nj.nec.com/levy96reasoning.html.

Levy, Alon Y.; Rajaraman, Anand; Ordille, Joann J. Querying Heterogeneous

Information Sources Using Source Descriptions. Proc. VLDB 1996, pp.

251--262.

Ljiljana, Stojanovic; Maedche, Alexander; Motik, Boris, Stojanovic, Nenad.

User-driven Ontology Evolution Management. Proc. of the 13th

International Conference Knowledge Engineering and Knowledge

Management (EKAW2002),pp.213-218, Sigüenza, Spain, October 1-4,

2002.

Maedche, A.; Staab; S. Semi-automatic engineering of ontologies from text. In

Proceedings of the 12th Internal Conference on Software and Knowledge

Engineering. Chicago, USA. KSI, (2000). Disponível em

http://citeseer.nj.nec.com/maedche00semiautomatic.html

Maedche, Alexander; Volz, Raphael. The Ontology Extraction Maintenance

Framework Text-To-Onto. Workshop on Integrating Data Mining and

Knowledge Management November 29, 2001, Disponível em

http://citeseer.nj.nec.com/464749.html


Maedche, A.; Motik, B.; Silva, N.; Volz, R.. (2002). MAFRA - A MApping

FRAmework for Distributed Ontologies in the Semantic Web. Presented

at Workshop on Knowledge Transformation for the Semantic Web.

Disponível em http://www.cs.vu.nl/~borys /events/ktsw2002.pdf.

Maedche, A.; Motik, B.; Stojanovic, L.; Studer, R.; Volz, R. Ontologies for

Enterprise Knowledge Management. In IEEE Intelligent Systems,

Volume 18, Number 2, pp. 26-33, March/April 2003

Melnik, S.; Representing UML in RDF. 2000. Disponível em http://www-

db.stanford.edu/~melnik/rdf/uml/.

Mena, E.; Kashyap, V.; Sheth, A; Illarramendi, A. Domain Specific Ontologies

for Semantic Information Brokering on the Global Information

Infrastructure. In Proceedings of the First International Conference on

Formal Ontologies in Information Systems. Trento, Italy. June 1998.

Disponível em http://citeseer.nj.nec.com/mena98domain.html.

Mitra, P.; Wiederhold, G.; Kersten, M. A Graph-Oriented Model for

Articulation of Ontology Interdependencies. In Proceedings Conference

on Extending Database Technology 2000 (EDBT'2000), Konstanz,

Germany, 2000. Disponível em http://citeseer.nj.nec.com/

mitra00graphoriented.html.

Motik, Boris; Maedche, Alexander; Volz, Raphael. A Conceptual Modeling

Approach for Semantics-Driven Enterprise Applications.

CoopIS/DOA/ODBASE 2002: 1082-1099.

NORTEC. N-1710 : Normalização Técnica Petrobras. Disponível na intranet da

Petrobras em http://nortec.engenharia.petrobras.com.br/frame.asp?cod=N-

1710

OIL. Homepage. Disponível em http://oil.semanticweb.org/

OMG. XML Metadata Interchange (XMI), v2.0. Object Management Group.

Disponível em http://www.omg.org/technology/documents/formal/

xmi.htm.

Ozsu, M.T.; Valduriez, P.; Principles of Distributed Database Systems. (Second

Edition). Prentice-Hall, 1999.

Papakonstantinou, Y.; Garcia-Molina, H.; Widom, J.;. Object Exchange across

Heterogeneous Information Sources. In Proc. ICDE Conference, 251--


260, 1995. Disponível em

http://citeseer.nj.nec.com/papakonstantinou95object.html.

Ross, Kenneth; Srivastava, Divesh; Stuckey, Peter; Sudarshan, S. Foundations of

aggregation constraints. In Alan Borning, editor, Principles and Practice

of Constraint Programming. Lecture Notes in Computer Science, 874.

Springer Verlag, 1994. Disponível em http://citeseer.nj.nec.com/

77561.html.

Schwarz, P. M.; Roth, M. T. Don't scrap it, wrap it! A wrapper architecture

for legacy data sources. 1997. In Proceedings of the 23rd VLDB

Conference (pp.266-275). Athens, Greece.

Sheth, Amit. Changing Focus on Interoperability in Information Systems:

From System, Syn-tax,Structure to Semantics. Interoperating

Geographic Information Systems. Edited by Good-child M. & Egenhofer,

M. & Fegeas, R. & Kottman, C. Kluwer Academic Publishers 1999, pp. 5-

29.

SIP. Sistema de Informação da Produção. Disponível na intranet da Petrobras em

\\epfs01\producao\ Sip\SIP_ORACLE\Loader.exe SIP_HMG.

Stojanovic, L.; Stojanovic, N.; Volz, R. Migrating data-intensive web sites into

the semantic web. In Proceedings of the ACM Symposium on Applied

Computing SAC-02, Madrid, Disponível em

http://citeseer.nj.nec.com/517976.html..

Stuckenschmidt, H. Using OIL for Intelligent Information Integration. In V.

Benjamins, A. Gomez-Perez, and N. Guarino, editors, Proceedings of the

Workshop on Applications of Ontologies and Problem-solving Methods,

14th European Conference on Artificial Intelligence ECAI 2000, Berlin,

Germany, Aug. 21 -- 22, 2000. 478. Disponível em

http://citeseer.nj.nec.com/stuckenschmidt00using.html

Teorey, T.J., Fry, J.P.Design of Database Structures, Prentice Hall Inc.,

Englewood Cliffs, NJ, 1982.

Tzitzikas, Yannis; Spyratos, Nicolas; Constantopoulos, Panos. Query

Translation for Mediators over Ontology-based Information Sources.

In Second Hellenic Conference on Artificial Intelligence, SETN-2002.

Disponível em http://citeseer.nj.nec.com/tzitzikas02query.html


Ullman, Jeffrey D. Information integration using logical views. In Proc. of the

6th Int. Conf. on Database Theory (ICDT-97), Lecture Notes in Computer

Science, pages 19--40. Springer-Verlag, 1997. Disponível em

http://citeseer.nj.nec.com/ullman97information.html

Visser, P.R.S.; Jones, D.M.; Bench-Capon, T.J.M; Shave, M.J.R.. An Analysis of

Ontology Mismatches; Heterogeneity versus Interoperability. Working

notes of the AAAI 1997 Spring Symposium on Ontological Engineering,

Stanford University, California, USA, pp.164-172. Disponível em

http://citeseer.nj.nec.com/visser97analysis.html

W3C. A Discussion of the Relationship Between RDF-Schema and UML.

W3C Note 04-Aug-1998. Disponível em http://www.w3.org/TR/NOTE-rdf-

uml/.

W3C. XML Schema Part 1: Structures. W3C Recommendation 2 May 2001.

Disponível em http://www.w3.org/TR/xmlschema-1

W3C. XML Schema Part 2: Datatypes. W3C Recommendation 2 May 2001.

Disponível em http://www.w3.org/TR/xmlschema-2

W3C. RDF Primer. W3C Working Draft 23 January 2003, work in progress.

Disponível em http://www.w3.org/TR/2003/WD-rdf-primer-20030123/.

W3C. Resource Description Framework (RDF):Concepts and Abstract

Syntax. W3C Working Draft 23 January 2003, work in progress.

Disponível em http://www.w3.org/TR/2003/WD-rdf-concepts-20030123/.

W3C. RDF Vocabulary Description Language 1.0: RDF Schema. W3C

Working Draft 23 January 2003, work in progress. Disponível em

http://www.w3.org/TR/2003/WD-rdf-schema-20030123/.

W3C. RDF/XML Syntax Specification (Revised), W3C Working Draft 23

January 2003, work in progress. Disponível em

http://www.w3.org/TR/2003/WD-rdf-syntax-grammar-20030123/.

W3C. Web Ontology Language (OWL), Guide Version 1.0. W3C Working

Draft 10 February 2003, work in progress. Disponível em

http://www.w3.org/TR/2003/WD-owl-guide-20030210/

W3C. Web Ontology Language (OWL), Use Cases and Requirements. W3C

Working Draft 03 February 2003, work in progress. Disponível em

http://www.w3.org/TR/2003/WD-webont-req-20030203/


W3C. Web Ontology Language (OWL): Overview. W3C Working Draft 10

February 2003, work in progress. Disponível em

http://www.w3.org/TR/2003/WD-owl-features-20030210/

W3C. Web Ontology Language (OWL) Reference Version 1.0. W3C Working

Draft 21 February 2003, work in progress. Disponível em

http://www.w3.org/TR/2003/WD-owl-ref-20030221/

W3C. XSL Tranformations (XSLT) 1.0. W3C Recomendation 16 November

1999, Disponível em http://www.w3.org/TR/1999/REC-xslt-19991116.

W3C. Uniform Resource Identifier (URI) Activity Statement. Naming and

Addressing: URIs, URLs, ...Disponível em http://www.w3.org/Addressing/

Wache, H.; Vogele, T.; Visser, U.; Stuckenschmidt, H.; Schuster, G.; Neumann,

H.; Hubner, S. Ontology-based integration of information - a survey of

existing approaches. In Stuckenschmidt, H., ed., IJCAI-01 Workshop:

Ontologies and Information Sharing, 108--117. 2001. Disponível em

http://citeseer.nj.nec.com/article/wache01 ontologybased.html

Wiederhold, G. Mediators in the architecture of future information systems.

IEEE Computer 25, 3 (March, 1992), 38--49. Disponível em

http://citeseer.nj.nec.com/wiederhold92mediators.html

Wiederhold, Gio; Genesereth, Michael. Basis for Mediation; Proc. COOPIS'95

Conference, Vienna Austria, available from US West, Boulder CO, May

1995. http://citeseer.nj.nec.com/ wiederhold95basis.html

Wiederhold G.; Genesereth, M. The conceptual basis for mediation services.

IEEE Intelligent Systems, pages 38--47, September/October 1997.

http://citeseer.nj.nec.com/wiederhold96 conceptual.html

Wiederhold, Gio; Janninck, Jan. Composing diverse ontologies. Proc. 8 th IFIP

working group on databases working conference on database semantics,

Rotorua (NZ), 1999. Disponível em http://www-

db.stanford.edu/SKC/publications/ifip99.html


Anexo A – Norma N-1710

Esta norma tem por objetivo:

Uniformizar e sistematizar a Codificação de Documentos Técnicos de

Engenharia emitidos em papel ou meio eletrônico relativos às

instalações da PETROBRAS de forma a permitir seu arquivamento

ordenado e facilitar a recuperação de informações;

Possibilitar a obtenção de elementos para a apropriação de custos;

Possibilitar a determinação de índices para a previsão e

acompanhamento orçamentários;

Padronizar a terminologia das áreas de atividade.

Esta Norma se aplica aos documentos técnicos de engenharia relativos a

instalações, emitidos nas fases de projeto, construção, montagem,

condicionamento e operação, a partir da data de sua edição.

Para identificar os documentos é utilizado um código alfanumérico que é

obtido pela associação ordenada dos códigos representativos dos seguintes grupos

básicos:

grupo 0 – identificação do idioma; grupo 1 – categoria do documento; grupo 2 – identificação da instalação; grupo 3 – area de atividade; grupo 4 – classe de serviços, materiais e equipamentos; grupo 5 – origem do documento; grupo 6 – seqüencial cronológico.

A seguir são apresentados alguns exemplos do conteúdo dos grupos de

interesse para o estudo de caso discutido.


Grupo 1 - Categoria do Documento.

Código do Documento

Descrição Comentário para Utilização e Exemplos

CE Certificado Certificados de inspeção, de conclusão de montagem, de aferição de instrumentos, de auditoria, entre outros

CR Cronograma Diagramas de barras, de caminho crítico e assemelhado

DE Desenho Planta, curvas de níveis, tabela, ábaco, gráfico, croqui, diagrama, fluxograma, anteprojeto e símbolos.

ET Especificação

Técnica

Critérios de projeto, especificação de materiais, sistemas e equipamentos, especificação de processo ou instalações

FD Folha de Dados

De equipamento, de sistemas, de material a granel (válvulas, conexões), de processo, de instrumento, de tubulação (lista de linhas)

IM Imagem Fotos, ortofotos, mosaico, hipsométrico, vídeos, entre Outros

IS Isométrico Específico para desenhos em axometria ou em perspectiva cavaleira de sistemas de tubulações

LA Laudo Parecer envolvendo aspectos de engenharia emitidos para fios legais do tipo: processo formal de partilha, de perícia ou avaliação, perícia ambiental e assemelhada

LD Lista de

Documentos Documentos Sem comentários (auto-explicativo)

LI Lista Relação de equipamentos, de instrumentos, de materiais, de suportes, de cabos (não se aplica a lista de linhas, que utiliza o código FD)

MA Manual De operação, de manutenção, da garantia de qualidade e outros

MC Memória de

Cálculo Cálculo Sem comentários (auto-explicativo)

MD Memorial Descritivo

Documento que descreve um conjunto de atividades, serviços ou processos, e outros

PT Parecer Técnico

Parecer para aquisição de sistemas, equipamentos e Materiais

RL Relatório De resultados, de estudo técnico, de levantamento de Campo

RM Requisição de

Material Documento para aquisição de sistema, equipamentos e materiais


Grupo 2 – Identificação da Instalação.

0000.00 - GERAL 0100.00 - SEDES ADMINISTRATIVAS

0100.00 - Documentos Padronizados para Instalações Não Definidas 0101.00 - EDISE - Edifício Sede da PETROBRAS 0102.00 - Instalações na Av. Cidade de Lima ...

0200.00 - CENTRO DE PESQUISA E DESENVOLVIMENTO LEOPOLDO A. MIGUEZ DE MELLO - CENPES

0201.00 - Instalações da Ilha do Fundão 0202.00 - Setor de Ensino do Rio de Janeiro - CEN-SUD ...

0300.00 - EDISP (ANTIGO GEASP; ANTIGO ESPAL) 0301.00 - Edifício Braz Cubas (Santos - SP) 0302.00 - Edifício Duarte da Costa (Campinas - SP)

...

1000.00 - E&P - ÁREA DE EXPLORAÇÃO (ANTIGO DEPEX) - GERAL 1100.00 - E&P - AM (ANTIGO DISTRITO DE EXPLORAÇÃO DA

AMAZÔNIA OCIDENTAL - DENOC) 1200.00 - E&P - AM (ANTIGO DISTRITO DE EXPLORAÇÃO DO

NORTE -DENOR) 1300.00 - E&P - RNCE (ANTIGO DISTRITO DE EXPLORAÇÃO DA

BACIA POTIGUAR - DEBAR) 1301.00 - Sede Administrativa - Natal 1302.00 - Sede Administrativa – Mossoró

...

2000.00 - E&P - ÁREA DE PERFURAÇÃO (ANTIGO DEPER) - GERAL 2010.00 - SEDES ADMINISTRATIVAS 2011.00 - E&P - BA (ANTIGO DISTRITO DE PERFURAÇÃO DA

BAHIA - DPBA) 2011.01 - Catu (Cancelado, usar 3101.03) 2011.02 - Taquipe (Cancelado, usar 3101.06)

2012.00 - E&P - SEAL (ANTIGO DISTRITO DE PERFURAÇÃO DO NORDESTE - DPNE)

2012.01 - Estação de Fluidos de Perfuração do Terminal Portuário de Sergipe

...

3000.00 - E&P - ÁREA DE PRODUÇÃO (ANTIGO DEPRO) - GERAL 3010.00 - INSTALAÇÕES EM UNIDADES MÓVEIS/UNIDADES

MARÍTIMAS DE PRODUÇÃO 3010.01 - PETROBRAS 34, P-34, PP Moraes (Ex NP-01) 3010.02 - Instalação para Produção na Penrod-62 (PA-06)

3010.03 - Instalação para Produção na PETROBRAS III, P-III

...


Grupo 3 – Área de Atividade.

1000 - PERFURAÇÃO, PRODUÇÃO E TRATAMENTO DE ÓLEO 1100 - PERFURAÇÃO

1110 - UNIDADE DE PERFURAÇÃO (SONDA DE PERFURAÇÃO) 1120 - ESTAÇÃO DE LAMA (FLUIDO DE PERFURAÇÃO)

1200 - PRODUÇÃO 1210 - POÇO

1211 - Coletora Satélite (“Manifold” Terrestre) 1212 - Estação de Transferência e Medição de Óleo e Gás

1220 - UNIDADES DE PROCESSO 1221 - Estação Coletora 1222 - Estação de Tratamento de Óleo ...

1230 - UNIDADES DE GÁS NATURAL 1231 - Unidade de Processamento e Manuseio (Compressão,

Distribuição e Outros) 1232 - Unidade de Liquefação ...

1240 - ELEVAÇÃO ARTIFICIAL (RECUPERAÇÃO PRIMÁRIA) 1241 - Sistema de Bombeamento Mecânico 1242 - Sistema de Bombeamento Hidráulico ...

1400 - INSTALAÇÕES MODULADAS (VER ITEM 7.4.4.2 DO TEXTO) 1500 - INSTALAÇÕES SUBMARINAS

1510 - UNIDADES DE PRODUÇÃO 1511 - Gabarito Submarino (“Template”) e suas Estacas 1512 - “Manifold” Submarino (PLEM) 1513 - Torres Articuladas (de Processo ou Carregamento) ...

1600 - EXTRAÇÃO 1610 - MINERAÇÃO 1620 - PREPARAÇÃO DE SÓLIDOS

1621 - Unidade de Britagem 1622 - Unidade de Aproveitamento de Finos (Sinterização, Briquetagem,

Peletização) ...

2000 - UNIDADES DE PROCESSO - REFINAÇÃO 2100 - PROCESSOS DE FRACIONAMENTO

2110 - PROCESSOS DE FRACIONAMENTO DE PETRÓLEO 2111 - Unidade de Destilação Atmosférica 2112 - Unidade de Destilação a Vácuo 2113 - Unidade de Asfalto

2120 - PROCESSOS DE FRACIONAMENTO DE DERIVADOS 2121 - Unidade de Recuperação de Gases 2122 - Unidade de Estabilização de Nafta ...

2200 - PROCESSOS DE CONVERSÃO ...


Grupo 4 – Classe de Serviços, Materiais e Equipamentos.

100 - CONSTRUÇÃO CIVIL, ARQUITETURA E URBANISMO 110 - TERRENO

111 - Topografia 112 - Levantamento Aerofotogramétricos ...

120 - FUNDAÇÕES 121 - Estaqueamento 122 - Infra-Estrutura

130 - ESTRUTURAS NÃO METÁLICAS 131 - Estruturas de Concreto 132 - Estruturas de Madeira 133 - Grades Fixas

140 - ESTRUTURAS METÁLICAS 141 - Chapas 142 - Tubos Estruturais ...

200 - TUBULAÇÃO 210 - TUBOS RÍGIDOS (Condução, Produção, Revestimento, Perfuração)

211 - Tubos de Aço Carbono e Carbono-Molibdênio 212 - Tubos de Ferro Fundido ...

220 - VÁLVULAS 221 - Válvulas Gaveta 222 - Válvulas Globo ...

300 - MÁQUINAS 310 - BOMBAS

311 - Bombas Centrífugas (Radiais, Fluxo Misto e Axiais) 312 - Bombas Alternativas (Pistão, Êmbolo e Diafragma) ...

320 - COMPRESSORES, SOPRADORES E VENTILADORES 321 - Compressores Centrífugos (Axiais e Radiais) 322 - Compressores Alternativos (Pistão e Diafragma) ...

330 - ACIONADORES MECÂNICOS 331 - Turbinas a Vapor 332 - Turbinas a Gás e de Expansão ...

400 - TRANSFERÊNCIA DE CALOR 410 - GERADORES DE VAPOR

411 - Caldeiras Aquotubulares 412 - Caldeiras Flamotubulares ...


Diagrama da Estrutura de Codificação de Documentos Técnicos.


Diagrama do Grupo Identificação da Instalação.


Diagrama do Grupo Área de Atividade.


Diagrama do Grupo Classe de Serviços, Materiais e Equipamentos.


Exemplo do documento OWL correspondente ao grupo Categoria de Documentos.

<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE owl ( <!ENTITY owl "http://www.w3.org/2002/7/owl#" > <!ENTITY xsd "http://www.w3.org/2000/10/XMLSchema#" > )> <rdf:RDF xmlns = "http://nortec.engenharia.petrobras.com.br/N-1710/ANEXO_A#" xmlns:owl = "http://www.w3.org/2002/7/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/2000/10/XMLSchema#"> <owl:Ontology rdf:about=

"http://nortec.engenharia.petrobras.com.br/N-1710/ANEXO_A.owl"> <rdfs:comment>

Ontologia gerada a partir da norma Petrobras:N-1710 REV.G NOV/2001 http://nortec.engenharia.petrobras.com.br/anexo_N-1710/ANEXO_A.pdf

</rdfs:comment> </owl:Ontology> <owl:Class rdf:ID="CategoriaDocumento"> <rdfs:label xml:lang="pt">Categoria de Documento</rdfs:label> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#temCodigo" /> <owl:cardinality>1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#temDescricao" /> <owl:cardinality>1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#temComentario" /> <owl:cardinality>1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:DatatypeProperty rdf:ID="temCodigo"> <rdfs:label xml:lang="pt">Código da Categoria</rdfs:label> <rdfs:range rdf:resource="&xsd;string"/>


</owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="temDescricao"> <rdfs:label xml:lang="pt">Descrição</rdfs:label> <rdfs:range rdf:resource="&xsd;string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="temComentario"> <rdfs:label xml:lang="pt">Comentário para Utilização e Exemplos

</rdfs:label> <rdfs:range rdf:resource="&xsd;string"/> </owl:DatatypeProperty> <CategoriaDocumento rdf:ID="CE"> <temCodigo rdf:datatype="&xsd;string">CE</temCodigo> <temDescricao rdf:datatype="&xsd;string">Certificado</temDescricao>

<temComentario rdf:datatype="&xsd;string">Certificados de inspeção, de conclusão de montagem, de aferição de instrumentos, de auditoria, entre outros.</temComentario>

</CategoriaDocumento > <CategoriaDocumento rdf:ID="CR"> <temCodigo rdf:datatype="&xsd;string">CR</temCodigo> <temDescricao rdf:datatype="&xsd;string">Cronograma

</temDescricao> <temComentario rdf:datatype="&xsd;string">Diagramas de barras, de

caminho crítico e assemelhado.</temComentario> </CategoriaDocumento > <CategoriaDocumento rdf:ID="DE"> <temCodigo rdf:datatype="&xsd;string">DE</temCodigo> <temDescricao rdf:datatype="&xsd;string">Desenho</temDescricao>

<temComentario rdf:datatype="&xsd;string">Planta, curvas de níveis, tabela, ábaco, gráfico, croqui, diagrama, fluxograma, anteprojeto e símbolos.</temComentario>

</CategoriaDocumento > <CategoriaDocumento rdf:ID="ET"> <temCodigo rdf:datatype="&xsd;string">ET</temCodigo> <temDescricao rdf:datatype="&xsd;string">Especificação Técnica

</temDescricao> <temComentario rdf:datatype="&xsd;string">Critérios de projeto,

especificação de materiais, sistemas e equipamentos, especificação de processo ou instalações.</temComentario>

</CategoriaDocumento> ... </rdf:RDF>


Exemplo do documento OWL correspondente ao grupo Identificação da Instalação. <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE owl ( <!ENTITY owl "http://www.w3.org/2002/7/owl#" > <!ENTITY xsd "http://www.w3.org/2000/10/XMLSchema#" > )> <rdf:RDF xmlns = "http://nortec.engenharia.petrobras.com.br/N-1710/ANEXO_B#" xmlns:owl = "http://www.w3.org/2002/7/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/2000/10/XMLSchema#"> <owl:Ontology rdf:about=

"http://nortec.engenharia.petrobras.com.br/N-1710/ANEXO_B.owl"> <rdfs:comment>

Ontologia gerada a partir da norma Petrobras: N-1710 rev.G NOV/2001 http://nortec.engenharia.petrobras.com.br/anexo_N-1710/ANEXO B.pdf

</rdfs:comment> </owl:Ontology> <owl:Class rdf:ID="Instalacao"> <rdfs:label xml:lang="pt">Identificação das Instalações</rdfs:label> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#temCodigo" /> <owl:cardinality>1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#temDescricao" /> <owl:cardinality>1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:DatatypeProperty rdf:ID="temCodigo"> <rdfs:label xml:lang="pt">Código da Instalação</rdfs:label> <rdfs:range rdf:resource="&xsd;string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="temDescricao"> <rdfs:label xml:lang="pt">Descrição</rdfs:label> <rdfs:range rdf:resource="&xsd;string"/> </owl:DatatypeProperty>


<owl:Class rdf:ID="AdmCentral"> <rdfs:label xml:lang="pt">Geral</rdfs:label> <rdfs:subClassOf rdf:resource="#Instalacao" /> </owl:Class> <owl:Class rdf:ID="EP_EXP">

<rdfs:label xml:lang="pt">E&P - ÁREA DE EXPLORAÇÃO (ANTIGO DEPEX) - GERAL</rdfs:label>

<rdfs:subClassOf rdf:resource="#Instalacao" /> </owl:Class> <owl:Class rdf:ID="EP_PERF">

<rdfs:label xml:lang="pt">E&P - ÁREA DE PERFURAÇÃO (ANTIGO DEPER) - GERAL</rdfs:label>

<rdfs:subClassOf rdf:resource="#Instalacao" /> </owl:Class> <owl:Class rdf:ID="EP_PRO">

<rdfs:label xml:lang="pt">E&P - ÁREA DE PRODUÇÃO (ANTIGO DEPRO) - GERAL</rdfs:label>

<rdfs:subClassOf rdf:resource="#Instalacao" /> </owl:Class> <owl:Class rdf:ID="AbastLog">

<rdfs:label xml:lang="pt">ABAST-LOG/GGO-TRAN (ANTIGO ABAST-TRAN)</rdfs:label>

<rdfs:subClassOf rdf:resource="#Instalacao" /> </owl:Class> <owl:Class rdf:ID="AbastRef">

<rdfs:label xml:lang="pt">ABAST-REF (ÁREA DE REFINO - ANTIGO DEPIN)</rdfs:label>

<rdfs:subClassOf rdf:resource="#Instalacao" /> </owl:Class> <owl:Class rdf:ID="EmprSubsidiaria">

<rdfs:label xml:lang="pt">SUBSIDIÁRIAS, CONTROLADAS E COLIGADAS</rdfs:label>

<rdfs:subClassOf rdf:resource="#Instalacao" /> </owl:Class> <owl:Class rdf:ID="EmprExterior">

<rdfs:label xml:lang="pt">EMPREENDIMENTOS NO EXTERIOR</rdfs:label>

<rdfs:subClassOf rdf:resource="#Instalacao" /> </owl:Class> <owl:Class rdf:ID="EmprPais">


<rdfs:label xml:lang="pt">EMPREENDIMENTO NO PAÍS, FORA DO SISTEMA PETROBRAS</rdfs:label>

<rdfs:subClassOf rdf:resource="#Instalacao" /> </owl:Class> <owl:Class rdf:ID="SedeAdministrativa"> <rdfs:label xml:lang="pt">SEDE ADMINISTRATIVA</rdfs:label> <rdfs:subClassOf rdf:resource="#AdmCentral" /> </owl:Class> <owl:Class rdf:ID="CENPES">

<rdfs:label xml:lang="pt">CENTRO DE PESQUISA E DESENVOLVIMENTO LEOPOLDO A. MIGUEZ DE MELLO - CENPES</rdfs:label>

<rdfs:subClassOf rdf:resource="#AdmCentral" /> </owl:Class> <SedeAdministrativa rdf:ID="EDISE"> <temCodigo rdf:datatype="&xsd;string">0101.00</temCodigo>

<temDescricao rdf:datatype="&xsd;string">EDISE - Edifício Sede da PETROBRAS</temDescricao>

</SedeAdministrativa> <SedeAdministrativa rdf:ID="CIDADE_LIMA"> <temCodigo rdf:datatype="&xsd;string">0102.00</temCodigo>

<temDescricao rdf:datatype="&xsd;string">Instalações na Av. Cidade de Lima</temDescricao>

</SedeAdministrativa> ... </rdf:RDF>


Exemplo do documento OWL correspondente ao grupo Área de Atividade.

<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE owl ( <!ENTITY owl "http://www.w3.org/2002/7/owl#" > <!ENTITY xsd "http://www.w3.org/2000/10/XMLSchema#" > )> <rdf:RDF xmlns = "http://nortec.engenharia.petrobras.com.br/N-1710/ANEXO_C#" xmlns:owl = "http://www.w3.org/2002/7/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/2000/10/XMLSchema#"> <owl:Ontology rdf:about=

"http://nortec.engenharia.petrobras.com.br/N-1710/ANEXO_C.owl"> <rdfs:comment>

Ontologia gerada a partir da norma Petrobras: N-1710 rev.G NOV/2001 http://nortec.engenharia.petrobras.com.br/anexo_N-1710/ANEXO C.pdf

</rdfs:comment> </owl:Ontology> <owl:Class rdf:ID="AreaAtividade"> <rdfs:label xml:lang="pt">Identificação das Instalações</rdfs:label> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#temCodigo" /> <owl:cardinality>1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#temDescricao" /> <owl:cardinality>1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:DatatypeProperty rdf:ID="temCodigo"> <rdfs:label xml:lang="pt">Código da Atividade</rdfs:label> <rdfs:range rdf:resource="&xsd;string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="temDescricao"> <rdfs:label xml:lang="pt">Descrição da Atividade</rdfs:label> <rdfs:range rdf:resource="&xsd;string"/> </owl:DatatypeProperty>


<owl:Class rdf:ID="Quimica"> <rdfs:label xml:lang="pt">Química</rdfs:label> <rdfs:subClassOf rdf:resource="#AreaAtividade" /> </owl:Class> <owl:Class rdf:ID="Refinacao">

<rdfs:label xml:lang="pt">Refinação</rdfs:label> <rdfs:subClassOf rdf:resource="#AreaAtividade" /> </owl:Class> <owl:Class rdf:ID="PerfProdTrat">

<rdfs:label xml:lang="pt">Perfuração, Produção e Tratamento</rdfs:label> <rdfs:subClassOf rdf:resource="#AreaAtividade" /> </owl:Class> <owl:Class rdf:ID="Distribuicao">

<rdfs:label xml:lang="pt">Distribuição</rdfs:label> <rdfs:subClassOf rdf:resource="#AreaAtividade" /> </owl:Class> <owl:Class rdf:ID="TransporteTancagem">

<rdfs:label xml:lang="pt">Transporte, Transferência e Tancagem </rdfs:label>

<rdfs:subClassOf rdf:resource="#AreaAtividade" /> </owl:Class> <owl:Class rdf:ID="Producao">

<rdfs:label xml:lang="pt">Produção</rdfs:label> <rdfs:subClassOf rdf:resource="#PerfProdTrat" /> </owl:Class> <owl:Class rdf:ID="Perfuracao">

<rdfs:label xml:lang="pt">Perfuração</rdfs:label> <rdfs:subClassOf rdf:resource="#PerfProdTrat" /> </owl:Class> <owl:Class rdf:ID="ElevacaoArtificial">

<rdfs:label xml:lang="pt">Elevação Artifcial</rdfs:label> <rdfs:subClassOf rdf:resource="#Producao" /> </owl:Class> <owl:Class rdf:ID="InjecaoQuimica"> <rdfs:label xml:lang="pt">Injeção Química</rdfs:label> <rdfs:subClassOf rdf:resource="#Producao" /> </owl:Class> <ElevacaoArtificial rdf:ID="BombMecanico"> <temCodigo rdf:datatype="&xsd;string">1241</temCodigo>


<temDescricao rdf:datatype="&xsd;string">Sistema de Bombeamento Mecânico</temDescricao>

</ElevacaoArtificial> <ElevacaoArtificial rdf:ID="BombHidraulico"> <temCodigo rdf:datatype="&xsd;string">1242</temCodigo>

<temDescricao rdf:datatype="&xsd;string">Sistema de Bombeamento Hidráulico</temDescricao>

</ElevacaoArtificial> <ElevacaoArtificial rdf:ID="Gas-Lift"> <temCodigo rdf:datatype="&xsd;string">1244</temCodigo>

<temDescricao rdf:datatype="&xsd;string">Sistema de Gás-Lift </temDescricao>

</ElevacaoArtificial> <InjecaoQuimica rdf:ID="InjOleoGas"> <temCodigo rdf:datatype="&xsd;string">1261</temCodigo>

<temDescricao rdf:datatype="&xsd;string">Injeção química de Óleo e Gás </temDescricao>

</InjecaoQuimica> <InjecaoQuimica rdf:ID="InjAguaOleosa"> <temCodigo rdf:datatype="&xsd;string">1244</temCodigo>

<temDescricao rdf:datatype="&xsd;string">Injeção química de Água Oleosa </temDescricao>

</InjecaoQuimica> <InjecaoQuimica rdf:ID="InjAguaCapt"> <temCodigo rdf:datatype="&xsd;string">1244</temCodigo>

<temDescricao rdf:datatype="&xsd;string"> Injeção química de Água de Captação</temDescricao>

</InjecaoQuimica > ... </rdf:RDF>


Anexo B – Modulo de Anormalidade em Poços do SIP

As tabelas do SIP de interesse para o mapeamento são as seguintes:

Tabela de Componentes de Sistemas

Código Descrição

AC SISTEMA DE ANCORAGEM

AN ÁRVORE NATAL/CAB PROD.

AQ AQUEC./RECUP./TROCADOR

AS VÁLVULA ASSV

BB BOMBA

BC CONJUNTO BCS

BR BATERIA/RETIF./INVERSOR

C1 PCH-1

C2 PCH-2

CC PAINEL CCM ELÉTRICO

CE CABO ELÉTRICO

CK CHOKE/BEAN PLATAFORMA

CM CABO MULTIPLEXADO

CO COMPRESSOR

CP COLUNA DE PRODUÇÃO

CS CHOKE/BEAN SUBMARINO

CT CONTROLADOR ELETRÔNICO

DH DHSV/SSSV

DR DISJUNTOR / RELÉ / BOTOEIRA

DS DESAERADOR

EN PCE-1

ES ESPF

FG SENSOR DE FOGO / GÁS

... ...


Tabela de Métodos de Elevação

Código Descrição

AGL AUTO GAS LIFT

BCP BOMBEIO CAVIDADE PROGRESSIVA

BCS BOMBEIO CENTRIFUGO SUBMERSO

BH BOMBEIO HIDRAULICO

BHJ BOMBEIO HIDRAULICO A JATO

BM BOMBEIO MECANICO

BMP BOMBEIO MOTO-PROGRESSIVO

GFC GAS LIFT CONTINUO COM FLEXITUBE

GFI GAS LIFT INTERMITENTE COM FLEXITUBE

GLC GAS LIFT CONTINUO

GLI GAS LIFT INTERMITENTE

GLP GAS LIFT INTERMITENTE COM PLUNGER

P PISTONEIO

PIG PIG LIFT

PLG PLUNGER LIFT ASSISTIDO

PLU PLUNGER LIFT CONVENCIONAL

S SURGENTE


Tabela de Sistemas de Equipamentos

Código Descrição

AF ÁGUA DE RESFRIAMENTO

AM CAPTAÇÃO DE ÁGUA

AO ÓLEO RECUPERADO / ÁGUA OLEOSA

AQ SISTEMA DE AQUECIMENTO

CA COMPRESSÃO DE GÁS ALTA PRESSÃO

CB COMPRESSÃO BOOSTER DE GÁS

CC CORRENTE CONTÍNUA

CG COMPRESSÃO EXCLUSIVAMENTE P/ GL

CH COMANDO HIDRÁULICO

CI COMBATE A INCÊNDIO

CO COLETA DA PRODUÇÃO

CP CONTROLE DE PROCESSO

CS ELEVAÇÃO ARTIFICIAL BCS

DE DISTRIBUIÇÃO DE ENERGIA

DG DESIDRATAÇÃO DE GÁS

EO EXPORTAÇÃO DE ÓLEO

FG DETECÇÃO DE FOGO / GÁS

FI DISTRIBUIÇÃO FLUIDO INJ. NO RESERVAT.

FL FLARE / TOCHA ALTA / BAIXA PRESSÃO

GA TRANSFERÊNCIA DE GÁS DE ALTA

GB TRANSFERÊNCIA DE GÁS DE BAIXA

GC GÁS COMBUSTÍVEL

GL ELEVAÇÃO ARTIFICIAL GÁS-LIFT

GO SEPARAÇÃO GÁS / ÓLEO

GP GERAÇÃO PRINCIPAL

GS GERAÇÃO AUXILIAR

GV GERAÇÃO DE VAPOR

HJ ELEVAÇÃO ARTIFICIAL BHJ

... ...


Tabela de Plataformas

Código Descrição

ESPF ESPADARTE FPSO

FPBR FPSO BRASIL

FPSO2 FPSO-2 MARLIM SUL

P-03 PETROBRAS III

P-07 PETROBRAS VII

P-08 PETROBRAS VIII

P-09 PETROBRAS IX

P-12 PETROBRAS XII

P-13 PETROBRAS XIII

P-14 PETROBRAS XIV (SS21)

P-15 PETROBRAS XV

P-18 PETROBRAS XVIII

P-19 PETROBRAS XIX

P-20 PETROBRAS XX

P-21 PETROBRAS XXI

P-22 PETROBRAS XXII

P-24 PETROBRAS XXIV

P-25 PETROBRAS XXV

P-26 PETROBRAS XXVI

P-27 PETROBRAS XXVII

P-31 PETROBRAS XXXI

P-33 PETROBRAS XXXIII

P-34 PETROBRAS XXXIV

P-35 PETROBRAS XXXV

P-36 PETROBRAS XXXVI

P-37 PETROBRAS XXXVII

P-40 PETROBRAS XL

P-45 PETROBRAS XLV

PA-06 PENROD 62

PCE-1 PLATAFORMA DE ENCHOVA

... ...


Tabela de Campos

Código Descrição

AB ALBACORA

ABL ALBACORA LESTE

ANQ ANEQUIM

BB BARRA BONITA

BD BADEJO

BG BAGRE

BI BICUDO

BJ BIJUPIRA

BO BONITO

BR BARRACUDA

CG CONGRO

CH CHERNE

CO CORVINA

CRL CORAL

CRP CARAPEBA

CRT CARATINGA

CRV CARAVELA

CVS CARAVELA SUL

EM ESTRELA DO MAR

EN ENCHOVA

ENO ENCHOVA OESTE

ESP ESPADARTE

FR FRADE

GP GAROUPA

GPN GAROUPINHA

GRJ GUARAJUBA

LI LINGUADO

MA MARIMBA

MLH MALHADO

MLL MARLIM LESTE

MLS MARLIM SUL

MLZ MERLUZA

MO MOREIA

MR MATO RICO

... ...


Diagrama do Módulo de Anormalidades em Poços do Sistema de Informação da Produção.


Exemplo do documento OWL correspondente ao Módulo de Acompanhamento de Anormalidade em Poços do SIP.

<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE owl ( <!ENTITY owl "http://www.w3.org/2002/7/owl#" > <!ENTITY xsd "http://www.w3.org/2000/10/XMLSchema#" > )> <rdf:RDF xmlns = "http://ti.petrobras.com.br/SIP#" xmlns:owl = "http://www.w3.org/2002/7/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/2000/10/XMLSchema#"> <owl:Ontology rdf:about="http://ti.petrobras.com.br/SIP/sip.owl">

<rdfs:comment> Ontologia gerada a partir do modelo Entidade-Relacionamento do Módulo de Acompanhamento de Anormalidades em Poços do Sistema de Informação da Produção.

</rdfs:comment> </owl:Ontology> <owl:DatatypeProperty rdf:ID="temCodigo"> <rdfs:label xml:lang="pt">Código</rdfs:label> <rdfs:range rdf:resource="&xsd;string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="temDescricao"> <rdfs:label xml:lang="pt">Descrição</rdfs:label> <rdfs:range rdf:resource="&xsd;string"/> </owl:DatatypeProperty> <owl:ObjectProperty rdf:ID="temPoco" /> <owl:ObjectProperty rdf:ID="temColuna" /> <owl:ObjectProperty rdf:ID="temMetodoElevacao" /> <owl:ObjectProperty rdf:ID="produzFluido" /> <owl:ObjectProperty rdf:ID="temTipoOperacao" /> <owl:ObjectProperty rdf:ID="temComponente" /> <owl:ObjectProperty rdf:ID="temSistemaEquipamento" /> <owl:Class rdf:ID="Componente”>


<rdfs:label xml:lang="pt">Componente</rdfs:label> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#temCodigo" /> <owl:cardinality>1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#temDescricao" /> <owl:cardinality>1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="MetodoElevacao”> <rdfs:label xml:lang="pt">Metodo de Elevação</rdfs:label> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#temCodigo" /> <owl:cardinality>1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#temDescricao" /> <owl:cardinality>1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="SistemaEquipamento”> <rdfs:label xml:lang="pt">Sistema de Equipamento</rdfs:label> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#temCodigo" /> <owl:cardinality>1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#temDescricao" /> <owl:cardinality>1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Plataforma"> <rdfs:label xml:lang="pt">Plataforma</rdfs:label> <rdfs:subClassOf>


<owl:Restriction> <owl:onProperty rdf:resource="#temCodigo" /> <owl:cardinality>1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#temDescricao" /> <owl:cardinality>1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#temColuna" /> <owl:allValuesFrom rdf:resource="#Coluna" /> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Campo"> <rdfs:label xml:lang="pt">Campo de produção</rdfs:label> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#temCodigo" /> <owl:cardinality>1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#temDescricao" /> <owl:cardinality>1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#temPoco" /> <owl:allValuesFrom rdf:resource="#Poco" /> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Coluna"> <rdfs:label xml:lang="pt">Coluna</rdfs:label> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#temCodigo" /> <owl:cardinality>1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf>


<owl:Restriction> <owl:onProperty rdf:resource="#temMetodoElevacao" /> <owl:allValuesFrom rdf:resource="#MetodoElevacao" /> </owl:Restriction> </rdfs:subClassOf>

<rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#temTipoOperacao" /> <owl:allValuesFrom rdf:resource="#TipoOperacao" /> </owl:Restriction> </rdfs:subClassOf>

<rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#ProduzFluido" /> <owl:allValuesFrom rdf:resource="#Fluido" /> </owl:Restriction> </rdfs:subClassOf> </owl:Class> ... </rdf:RDF>


Anexo C – Mapeamento entre a N-1710 e o SIP

Exemplo do documento OWL correspondente ao Mapeamento entre a norma N-1710 e o Módulo de Acompanhamento de Anormalidade em Poços do SIP.

Mapeamento relativo ao grupo Identificação da Instalação:

<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE owl ( <!ENTITY sip "http://ti.petrobras.com.br/SIP#" > <!ENTITY n1710 "http://nortec.engenharia.petrobras.com.br/N-1710#" > <!ENTITY owl "http://www.w3.org/2002/7/owl#" > <!ENTITY xsd "http://www.w3.org/2000/10/XMLSchema#" > )> <rdf:RDF xmlns = "http://ti.petrobras.com.br/map#" xmlns:sip = "http://ti.petrobras.com.br/SIP#" xmlns:n1710 = "http://nortec.engenharia.petrobras.com.br/N-1710#" xmlns:owl = "http://www.w3.org/2002/7/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/2000/10/XMLSchema#"> <owl:Ontology rdf:about=

"http://nortec.engenharia.petrobras.com.br/map/map1.owl"> <rdfs:comment> Ontologia para mapeamento entre a norma Petrobras:

N-1710 REV.G NOV/2001 e o Sistema de Informação da Producao - SIP </rdfs:comment> </owl:Ontology> <owl:Class rdf:ID="Plataforma"> <rdfs:subClassOf rdf:resource="sip;Plataforma" /> <rdfs:subClassOf rdf:resource="&n1710;EP_PRO" /> </owl:Class> <Plataforma rdf:ID="P-40"> <owl:sameAs rdf:resource="&n1710;B3010.57" /> <owl:sameAs rdf:resource="&sip;P-40" /> </owl:Class>


<owl:Class rdf:ID="InstalacaoCampo"> <rdfs:subClassOf rdf:resource="&n1710;EP_PRO" /> </owl:Class> <owl:ObjectProperty rdf:ID="temCampo"> <rdfs:domain rdf:resource="#InstalacaoCampo" /> <rdfs:range rdf:resource="&sip;Campo" /> </owl:ObjectProperty> <owl:Class rdf:ID="InstalacaoBadejo"> <owl:sameAs rdf:resource="&n1710;Badejo" /> <rdfs:subClassOf rdf:resource="InstalacaoCampo" /> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#temCampo" /> <owl:hasValue rdf:resource="&sip;BD" /> </owl:Restriction> </rdfs:subClassOf> </owl:Class> </rdf:RDF>


Mapeamento relativo ao grupo Área de Atividade:


"http://nortec.engenharia.petrobras.com.br/map/map.owl"> <rdfs:comment> Ontologia para mapeamento entre a norma Petrobras:

N-1710 REV.G NOV/2001 e o Sistema de Informação da Producao - SIP </rdfs:comment> </owl:Ontology> <owl:Class rdf:ID="AtividadeSistema"> <rdfs:subClassOf rdf:resource="&n1710;AreaAtividade" /> </owl:Class> <owl:ObjectProperty rdf:ID="temSistemaEquipamento"> <rdfs:domain rdf:resource="#AtividadeSistema" /> <rdfs:range rdf:resource="&sip;SistemaEquipamento" /> </owl:ObjectProperty> <owl:Class rdf:ID="InjecaoQuimica"> <rdfs:subClassOf rdf:resource="AtividadeSistema" /> <owl:sameAs rdf:resource="&n1710;InjecaoQuimica" /> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#temSistemaEquipamento" /> <owl:hasValue rdf:resource="&sip;IQ" /> </owl:Restriction> </rdfs:subClassOf> </owl:Class>


<owl:Class rdf:ID="AtividadeElevacao"> </owl:Class> <owl:ObjectProperty rdf:ID="temElevacaoArtificial"> <rdfs:domain rdf:resource="#AtividadeElevacao" /> <rdfs:range rdf:resource="&n1710;ElevacaoArtificial" /> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="temMetodoElevacao"> <rdfs:domain rdf:resource="#AtividadeElevacao" /> <rdfs:range rdf:resource="&sip;MetodoElevacao" /> </owl:ObjectProperty> <owl:Class rdf:ID="GasLift"> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#temElevacaoArtificial" /> <owl:hasValue rdf:resource="&n1710;GasLift" /> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#temMetodoElevacao" /> <owl:allValuesFrom> <owl:Class> <owl:oneOf rdf:parseType="Collection"> <owl:Item rdf:resource="&sip;AGL" /> <owl:Item rdf:resource="&sip;GFC" /> <owl:Item rdf:resource="&sip;GFI" /> <owl:Item rdf:resource="&sip;GLC" /> <owl:Item rdf:resource="&sip;GLI" /> <owl:Item rdf:resource="&sip;GLP" /> </owl:oneOf> </owl:Class> </owl:allValuesFrom> </owl:Restriction> </rdfs:subClassOf> </owl:Class> </rdf:RDF>


Mapeamento relativo ao grupo Serviços, Materiais e Equipamentos:


"http://nortec.engenharia.petrobras.com.br/map/map.owl"> <rdfs:comment> Ontologia para mapeamento entre a norma Petrobras:

N-1710 REV.G NOV/2001 e o Sistema de Informação da Producao - SIP </rdfs:comment> </owl:Ontology> <owl:Class rdf:ID="Equipamento"> <rdfs:subClassOf rdf:resource="&n1710;ServEquipMat" /> </owl:Class> <owl:ObjectProperty rdf:ID="temClasseComponente"> <rdfs:domain rdf:resource="#Equipamento" /> <rdfs:range rdf:resource="&sip;Componente" /> </owl:ObjectProperty> <owl:Class rdf:ID="Bomba"> <rdfs:subClassOf rdf:resource="Equipamento" /> <owl:sameAs rdf:resource="&n1710;Bomba" /> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#temClasseComponente" /> <owl:hasValue rdf:resource="&sip;BB" /> </owl:Restriction> </rdfs:subClassOf> </owl:Class> </rdf:RDF>

marcos magalhães moreira integração semântica de …

Documents