Post on 18-Dec-2014
description
ALISON ROBERTO DE OLIVEIRA CARVALHO CAIO FUNES NASCIMENTO
WEB SEMÂNTICA E ONTOLOGIAS: UM ESTUDO DE CASO
FRANCA 2009
Trabalho de Conclusão de Curso apresentado como exigência parcial, para a obtenção do grau no curso de Ciência da Computação, da Universidade de Franca. Orientador: Prof. Dr. Daniel Facciolo Pires
Catalogação na fonte – Biblioteca Central da Universidade de Franca
Carvalho, Alison Roberto de Oliveira C321w Web semântica e ontologias : um estudo de caso / Alison Roberto de
Oliveira Carvalho, Caio Funes Nascimento ; orientador: Daniel Facciolo Pires. –
2009
78 f. : 30 cm.
Trabalho de Conclusão de Curso. – Bacharel em Ciência da Computação
1. Informática – Internet – Semântica. 2. Computação – Web semântica. 3. Web semântica – Ontologias. 4. Ontologia (CERCOnt) – Metodologia 101 (desenvolvimento). I. Nascimento, Caio Funes. II. Universidade de Franca. III. Título.
CDU – 681.324:801.54
ALISON ROBERTO DE OLIVEIRA CARVALHO CAIO FUNES NASCIMENTO
WEB SEMÂNTICA E ONTOLOGIAS: UM ESTUDO DE CASO
Orientador: __________________________________________________ Nome: Prof. Dr. Daniel Facciolo Pires. Instituição: Universidade de Franca. Examinador: _________________________________________________ Nome: Instituição: Examinador: _________________________________________________ Nome: Instituição:
Franca, ____ / ____ / ______
DEDICAMOS, aos nossos pais, pela educação e apoio sem medidas; ao nosso orientador Prof. Dr. Daniel Facciolo Pires, pela paciência e por acreditar em nós no decorrer da pesquisa, e a todas as pessoas que fizeram este trabalho tornar-se possível.
AGRADECEMOS , a Deus por dar-nos inteligência e saúde; ao nosso orientador Prof. Dr. Daniel Facciolo Pires; aos nossos pais e amigos que estiveram ao nosso lado durante o desenvolvimento deste trabalho; às pessoas que de algum modo fizeram com que o desenvolvimento deste trabalho fosse possível.
RESUMO
CARVALHO, Alison Roberto de Oliveira; NASCIMENTO, Caio Funes. Web Semântica e Ontologias: Um Estudo de Caso. 2009. 78 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) – Universidade de Franca, Franca.
Este trabalho propôs o desenvolvimento de uma ontologia baseado nos conceitos da Web Semântica. Esta Ontologia de nome CERCOnt destina-se a classificação de cabos utilizados para a construção de redes de computadores, tais como suas aplicações e propriedades. A metodologia 101 foi utilizada para o desenvolvimento da CERCOnt pela sua facilidade e simplicidade. Uma aplicação em JAVA foi desenvolvida com a API JENA para testar a eficiência da CERCOnt de modo que esta pudesse responder questões de sua competência. A ontologia foi representada computacionalmente em RDF Schema, e inferências feitas nesta em SPARQL.
Palavras-chave: Web Semântica; Ontologia; CERCOnt.
ABSTRACT
CARVALHO, Alison Roberto de Oliveira; NASCIMENTO, Caio Funes. Web Semântica e Ontologias: Um Estudo de Caso. 2009. 78 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) – Universidade de Franca, Franca.
This project aimed the development of an ontology based on Semantic Web concepts. This Ontology named CERCOnt is intended for classification of used cables for networks construction, such as it applications and properties. The methodology 101 was used for CERCOnt development for it’s facility and simplicity. An application in JAVA was developed with API JENA to test the CERCOnt efficiency, so that it could answer the questions of it’s competence. The ontology was represented computer in RDF Schema, and inferences did in ontology in SPARQL.
Keywords: Semantic Web; Ontology; CERCOnt.
LISTA DE FIGURAS
Figura 1 - Arquitetura das camadas da Web
Semântica 15 Figura 2 - Taxonomia de cabos para rede de
computadores 23 Figura 3 - Exemplo de código em HTML 24 Figura 4 - Exemplo de código em XML 24 Figura 5 - Exemplo de um documento RDF 26 Figura 6 - Exemplo de um documento em
RDFSchema 27 Figura 7 - Protégé em funcionamento 30 Figura 8 - Hierarquia e relacionamento das
interfaces. 31 Figura 9 - Exemplo de documento RDF para
consulta em SPARQL 34
Figura 10 - Protégé com SPARQL integrado
36 Figura 11 - Definição dos Tipos Semânticos da
CERCOnt 41 Figura 12 - Criação da Classe “Fibra_Optica”, no
arquivo CERCOnt.rdfs 48 Figura 13 - Definição das propriedades da Classe
Nao_Blindado 48 Figura 14 - Exemplo de instância da classe
Fibra_Optica 49 Figura 15 - Tela principal da aplicação JCERCOnt 50 Figura 16 - Implementação do botão Inferir Modelo 51
Figura 17 - Método infereModelo() da classe
CERCOnt.java 52 Figura 18 - Resposta para a questão 1 53 Figura 19 - Resposta para a questão 2 54 Figura 20 - Resposta para a questão 3 55 Figura 21 - Resposta para a questão 4 56 Figura 22 - Resposta para a questão 5 57 Figura 23 - Resposta para a questão 6 58 Figura 24 - Resposta para a questão 7 59 Figura 25 - Primeira parte da consulta SPARQL do
botão 1 60 Figura 26 - Segunda parte da consulta SPARQL do
botão 1 61 Figura 27 - Consulta SPARQL do botão 2 62
SUMÁRIO
INTRODUÇÃO .......................................................................................................... 11
1 WEB SEMÂNTICA .................................................................................... 13
1.1 CONSIDERAÇÕES INICIAIS .................................................................... 13
1.2 WEB ATUAL x WEB SEMÂNTICA ............................................................ 13
1.3 ONTOLOGIAS........................................................................................... 16
1.3.1 Tipos de Ontologias .................................................................................. 17
1.3.2 Metodologias para Construção de Ontologias .......................................... 18
1.3.2.1 Metodologia Cyc........................................................................................ 18
1.3.2.2 Metodologia Ushold ................................................................................... 19
1.3.2.3 Metodologia Methontology ........................................................................ 20
1.3.2.4 Metodologia 101 ........................................................................................ 20
1.4 EXTENSIBLE MARKUP LANGUAGE (XML) ............................................ 24
1.5 RESOURCE DESCRIPTION FRAMEWORK (RDF) E RDFSCHEMA ...... 25
1.6 ONTOLOGY WEB LANGUAGE (OWL) .................................................... 27
1.7 CONSIDERAÇÕES FINAIS ...................................................................... 28
2 FERRAMENTAS PARA A WEB SEMÂNTICA ......................................... 29
2.1 CONSIDERAÇÕES INICIAIS .................................................................... 29
2.2 PROTÉGÉ ................................................................................................. 29
2.3 API JENA .................................................................................................. 30
2.4 INFERÊNCIAS .......................................................................................... 32
2.4.1 Inferência baseada em ontologias............................................................. 32
2.4.2 Inferência baseada em regras ................................................................... 33
2.5 API SPARQL ............................................................................................. 33
2.6 CONSIDERAÇÕES FINAIS ...................................................................... 36
3 DESENVOLVIMENTO DA ONTOLOGIA COM A METODOLOGIA 10 1 .. 37
3.1 CONSIDERAÇÕES INICIAIS .................................................................... 37
3.2 ESCOLHA DA METODOLOGIA................................................................ 37
3.2.1 Determinar o Domínio e Escopo da Ontologia .......................................... 38
3.2.2 Considerar o Reuso de Outras Ontologias ................................................ 39
3.2.3 Enumerar os Termos Importantes da Ontologia ....................................... 39
3.2.4 Definir Classes e Hierarquia de Classes ................................................... 40
3.2.5 Definir as Propriedades das Classes ........................................................ 42
3.2.6 Definir os Valores das Propriedades ......................................................... 44
3.2.7 Criar Instâncias ......................................................................................... 44
3.3 CONSIDERAÇÕES FINAIS ...................................................................... 46
4 DESENVOLVIMENTO DE UMA APLICAÇÃO PARA CONSULTA À
ONTOLOGIA ............................................................................................................. 47
4.1 CONSIDERAÇÕES INICIAIS .................................................................... 47
4.2 IMPLEMENTAÇÃO DA ONTOLOGIA CERCONT COM A FERRAMENTA
PROTÉGÉ ................................................................................................................. 47
4.2.1 Entendendo o arquivo CERCOnt.rdfs ....................................................... 48
4.2.2 Entendendo o arquivo CERCOnt.rdf ......................................................... 49
4.3 DESENVOLVIMENTO DA APLICAÇÃO PARA CONSULTA JCERCOnt . 49
4.4 CONSIDERAÇÕES FINAIS ...................................................................... 62
CONCLUSÃO ........................................................................................................... 64
REFERÊNCIAS ......................................................................................................... 65
APÊNDICE A – CERCOnt.rdfs ................................................................................ 69
APÊNDICE B - CERCOnt.rdf ................................................................................... 72
APÊNDICE C - Modelo_Inferido_CERCOnt.rdf ..................................................... 74
INTRODUÇÃO
Devido à rápida popularização e crescimento da Internet, graças à
simplicidade do HTML (Hyper Text Markup Language – W3C) utilizado na criação de
páginas Web, surgiram alguns problemas estruturais, pois essas páginas não eram
padronizadas, e o HTML é uma linguagem que objetiva apenas a apresentação da
informação, tornando muito difícil a busca por informações nesse tipo de sistema, já
que as páginas estão desorganizadas, sem um padrão em sua estrutura.
A Web continua a crescer rapidamente. No entanto, grande parte das
páginas nela disponíveis, mantém muito de sua característica inicial, que é o fato de
serem direcionadas a pessoas, e não para serem processadas por algum software.
Os computadores são utilizados apenas para mostrar a informação na tela,
decodificando linguagens como HTML ou XML (eXtensible Markup Language –
W3C). A XML é uma linguagem de marcação estruturada muito flexível, permitindo
aos desenvolvedores criar seus próprios elementos de marcação, que auxiliará na
organização do conteúdo na Web, uma vez que a XML permite a comunicação entre
vários sistemas diferentes, com regras bem definidas pelo XMLSchema.
Dessa forma, a Web Semântica surge a fim de adicionar significado a
esses documentos, através de linguagens como o Resource Description Framework
(RDF – W3C) e Web Ontology Language (OWL – W3C), entre outras, para que
possam ser processados por agentes de software e não só por seres humanos, já
que essas linguagens são apenas para apresentação de informação.
A Web Semântica, no entanto, não consiste em uma Web separada,
mas sim em uma extensão da Web atual onde a informação tem significado bem
definido possibilitando pessoas e máquinas trabalharem cooperando entre si
(BERNERS-LEE; HENDLER; LASSILA; 2001).
Para tanto, há ainda o uso de ontologias, que no contexto da Web
Semântica é “uma especificação formal e explícita de uma conceitualização
compartilhada” (BREITMAN, 2005, p. 30).
Assim, fica indispensável o uso de ontologias quando o assunto é Web
Semântica, já que com elas, torna-se possível, por exemplo, distinguir entre termos
distintos com o mesmo conceito, porém com identificadores diferentes, com o uso de
um agente de software comparando essas informações.
E nos dias de hoje, com o crescimento do uso das redes locais de
computadores e a agregação de novos serviços como voz, dados, telefonia,
multimídia, surgiu a necessidade de se estabelecer critérios para ordenar e
estruturar o cabeamento dentro das empresas.
Devido à grande dificuldade de entendimento das propriedades e
aplicações dos cabos destinados ao desenvolvimento das redes de computadores,
este projeto destina-se a esclarecer algumas dúvidas sobre a aplicação de cada
cabo, tornando o processo de escolha do cabo mais simples, segundo critérios
estabelecidos pelo uso, ambiente, resistência a interferências, velocidade de
transmissão, etc.
Dessa forma, a criação de uma ontologia que auxilie no entendimento
dessas propriedades e particularidades de aplicação, irá contribuir para que
projetistas de infra-estrutura possam executar seus projetos mais rapidamente.
Este trabalho visou a pesquisa de como definir, modelar e implementar
uma ontologia sobre projetos de cabeamento estruturado em redes de
computadores, seguindo as recomendações da World Wide Web Consortium (W3C),
e a criação de regras para consultas e inferências nas instâncias desta ontologia.
Para atingir tais objetivos, foram pesquisados os conceitos sobre
ontologias relacionadas à Ciência da Computação e as especificações das
linguagens RDF, RDFSchema e OWL.
Para o desenvolvimento do software proposto neste projeto, foi criada
uma ontologia sobre propriedades e aplicações dos cabos de redes de
computadores, utilizando as ferramentas gratuitas Protégé, a API JENA, e a API
SPARQL. Foram implementados documentos em RDF e RDFSchema, uma
aplicação em JAVA para inferência nesses documentos, e estudados conceitos
sobre a Web Semântica. Foram utilizados livros, consultas ao site da W3C, aos
artigos e trabalhos sobre este assunto.
1 WEB SEMÂNTICA
1.1 CONSIDERAÇÕES INICIAIS
Neste capítulo, é feita uma introdução à Web Semântica e assuntos a
ela relacionados. É abordada a situação da Web atual e algumas justificativas para a
criação da Web Semântica. Também são apresentadas as tecnologias existentes
para o desenvolvimento da Web Semântica.
1.2 WEB ATUAL x WEB SEMÂNTICA
Os seres humanos são capazes de utilizar a WWW (World Wide Web)
ou simplesmente Web, para realizar diversas tarefas, tais como procurar resultados
para a palavra “rede de computadores”, pesquisar um preço de um livro, entre
outros. No entanto, um computador não pode realizar as mesmas tarefas, pois a
maioria das páginas da Web está codificada em HTML (Hyper Text Markup
Language), uma linguagem de marcação com o objetivo de formatar a visualização
em navegadores. Deste modo, humanos processam a informação, enquanto os
computadores apenas apresentam-na.
A Web Semântica surge com o objetivo de solucionar este problema,
adicionando significado aos dados disponíveis de modo que estes possam ser
compreendidos pelos computadores. Assim, os computadores poderiam ser
utilizados para procurar, processar e recuperar informações de forma a atender as
necessidades de seus usuários. Para que isso aconteça, é necessário construir
documentos estruturados que tenham suporte a metadados e representação
semântica do conteúdo, e por parte das máquinas, consultar, interpretar e selecionar
documentos e serviços adequadamente em uma determinada situação. Metadados
são dados que descrevem o conteúdo, a estrutura, a representação e o contexto de
algum dado ou conjunto de dados. Um exemplo é uma ficha catalográfica de um
livro, que contém diversas informações, como autor, editora, ano de lançamento, etc.
(BREITMAN, 2005)
A Web Semântica é uma extensão da Web atual, onde a informação
tem significado bem definido, permitindo máquinas e humanos trabalharem
cooperando entre si (BERNERS-LEE; HENDLER; LASSILA; 2001). Para que isso
aconteça, a Web Semântica utiliza ontologias, que servem para definir categorias
para as coisas que existem num mesmo domínio e linguagens de marcação, como o
XML, RDF e RDFSchema.
Atualmente, a XML vem sendo utilizada não somente para estruturar
documentos, mas como padrão para intercâmbio de documentos de dados na rede,
pois facilita a interoperabilidade entre sistemas de informação.
A Web Semântica propõe um novo modelo arquitetural que através de
camadas permite implementar significado em documentos da Web. Este modelo é
conhecido como “Bolo de Noiva”, e foi proposto por Tim Berners Lee em uma
conferência de XML em 2000. A idéia por trás desse modelo é, em vez de propor
uma arquitetura totalmente nova e a conseqüente reestruturação da Internet,
construí-la em cima do que já existe (BREITMAN, 2005). A iniciativa da Web
Semântica proposta pelo World Wide Web Consortium, a W3C, vem estudando e
divulgando padrões para a consolidação desta nova geração da Web. A Figura 1
demonstra a visão da W3C e as camadas que formam a Web Semântica.
Figura 1 – Arquitetura das Camadas da Web Semântica
Fonte: www.w3c.org, acesso em 09 abril de 2009
A camada mais baixa é composta pelas especificações Unicode e URI.
Unicode refere-se a caracteres universais que podem ser visualizados de forma
padronizada para visualização de documentos em diferentes idiomas (SILVA, 2005).
É um esquema padronizado de codificação dos caracteres, que diminui
consideravelmente a possibilidade de redundâncias dos dados, pois funciona
independente da plataforma utilizada. O URI (Uniform Resource Identifier) é um
padrão para identificar um recurso físico ou abstrato de maneira única e global.
Na segunda camada, encontram-se o XML (Extensible Markup
Language), NameSpace (NS) e o XMLSchema. O XML é uma linguagem de
marcação, independente de plataforma, utilizada para criação de documentos
estruturados, cujo vocabulário é definido pelo usuário. NameSpace é uma coleção
de nomes, identificados por uma referência URI, utilizados para qualificar nomes de
elementos e atributos usados em documentos XML. Assim, é possível compartilhar e
reutilizar a definição de outros esquemas XML sem que haja problemas de
ambiguidades. A linguagem XMLSchema permite a definição e a descrição de
estruturas e de conteúdos de documentos XML. Através dessa linguagem, define-se
o formato válido de um documento XML.
Na terceira camada estão o RDF (Resource Descripition Framework) e
o RDFSchema. RDF é usado para representação de informações e troca de
conhecimentos na Web (SILVA, 2005). RDFSchema é uma linguagem que define a
estrutura válida para os documentos RDF, similar ao XMLSchema.
A camada Vocabulário Ontológico refere-se às linguagens para
representação do conhecimento.
A camada de Lógica proporciona a definição de semântica formal, e é
composta, principalmente, por regras de inferência, as quais os agentes poderão
utilizar para relacionar e processar informação.
A camada Prova deve possibilitar a verificação e comprovação da
coerência lógica dos recursos. A camada de Confiança e de Assinatura Digital deve
garantir que as informações sejam representadas de modo correto, possibilitando
certo grau de confiabilidade.
1.3 ONTOLOGIAS
O termo ontologia é originário da filosofia e foi inserido por Aristóteles.
É um campo de estudo que lida com a natureza e organização do Ser tentando
responder à questão: O que é um Ser? E quais são as características comuns de
todos os Seres?
Na área de Inteligência Artificial, o termo ontologia foi tomado
emprestado da Filosofia e para os pesquisadores da web e estudiosos em
Inteligência Artificial, ontologia tem outro sentido. “É um documento que define as
relações entre termos e conceitos” (BERNERS-LEE; HENDLER; LASSILA, 2001).
O Consórcio W3C define uma ontologia como “a definição dos termos
utilizados na descrição e na representação de uma área do conhecimento” .
A literatura apresenta uma série de definições distintas, e uma destas
definições é a proposta por Fensel (Fensel 2001: apud GRUBER, 1995) “Uma
ontologia é uma especificação formal e explícita de uma conceitualização
compartilhada”.
É importante destacar o significado de algumas palavras utilizadas. A
palavra “conceitualização” refere-se a um modelo abstrato de algum fenômeno que
identifique conceitos relevantes desse fenômeno. A palavra “explícita” significa que
tipos de conceitos usados e as limitações do uso desses conceitos devem ser
definidos de forma explícita. A palavra “formal” significa que a ontologia deve ser
passível de ser processada por máquina. Por fim “compartilhada”, reflete a noção de
que a ontologia captura um movimento consensual, isto é, esse conhecimento não
deve ser restrito a alguns indivíduos, mas aceito por um grupo de pessoas (Fensel,
2001: apud GRUBER, 1995).
Uma ontologia define um domínio, ou, mais formalmente, especifica
uma conceitualização acerca dele (GRUBER, 1995).
1.3.1 Tipos de Ontologias
Diferentes tipos de ontologias, de acordo com seu grau de
generalidade, podem ser delineadas (Gómez-Perez,1999):
• Ontologias de Representação: definem as primitivas de
representação do conhecimento – frames, axiomas, atributos e outros – de forma
declarativa;
• Ontologias Gerais: trazem definições abstratas necessárias
para a compreensão de aspectos do mundo, como tempo, processos, papéis,
espaço, seres, coisas, entre outros;
• Ontologias Centrais ou Genéricas: definem os ramos de
estudos de uma área e/ou conceitos mais genéricos e abstratos desta. Por exemplo,
regras básicas do direito;
• Ontologias de Domínio: tratam de um domínio mais específico
de uma área genérica de conhecimento, como direito tributário, microbiologia, entre
outros;
• Ontologias de Aplicação: procura solucionar um problema
específico de um domínio, como identificar doenças do coração, a partir de uma
ontologia de domínio de cardiologia.
Existe ainda outra classificação para ontologias, aplicável apenas para
as duas últimas citadas anteriormente. São elas:
• Ontologias de Tarefas: descrevem tarefas de um domínio –
como processos, planos, metas, escalonamentos, etc. – com uma visão mais
funcional, embora declarativa, de um domínio;
• Ontologias de Domínio: tem uma visão mais epistemológica do
domínio, focando nos conceitos e objetos do universo discurso.
1.3.2 Metodologias para Construção de Ontologias
Os pesquisadores buscam uma metodologia mais adequada para a
construção de ontologias, e entre eles se destacam grandes grupos de pesquisa
como os da Universidade de Manchester, Stanford, Politécnico de Milão, PUC - Rio,
Massachusetts Institute of Technology (MIT), W3C, entre outros, o que culminou no
surgimento de várias metodologias, pois talvez não exista como utilizar uma única
metodologia para a construção de todas as ontologias. Com isso, algumas destas
metodologias são apresentadas a seguir, sendo aplicáveis dependendo do contexto
e necessidade da aplicação.
1.3.2.1 Metodologia Cyc
Na década de 80, a empresa Microelectronics and Computer
Technology criou o Cyc, uma base de conhecimento que conteria os termos mais
gerais da realidade consensual sobre o mundo. A linguagem de representação da
Cyc é a CycL, considerada híbrida por combinar frames com cálculos de predicado.
Tal linguagem possui uma máquina de inferência que permite herança múltipla,
classificação automática, manutenção de links inversos, verificação de restrições,
busca ordenada, detecção de contradição e módulo de resolução.
A construção dessa base de conhecimento seguiu três fases. No
primeiro passo, o conhecimento foi adquirido de diferentes fontes de forma manual,
como livros e jornais. O segundo passo foi automatizado, ou seja, utilizou-se como
apoio ferramentas computacionais de processamento de linguagem natural e
aprendizado de máquina capazes de usar conhecimento de senso comum suficiente
para investigar e descobrir novos conhecimentos. Assim, no terceiro passo, um
número maior de ferramentas computacionais foi utilizado no sentido de gerenciar a
extração de conhecimento de senso comum.
1.3.2.2 Metodologia Uschold
Baseada na prática da construção da ontologia de topo Enterprise, o
grupo do pesquisador Mike Uschold, da Universidade de Edimburgo, em cooperação
com outras empresas, propôs a primeira metodologia, também conhecida como
“skeletal methodology” para construção de ontologias. (BREITMAN, 2005).
Nesta metodologia são considerados os seguintes passos para a
construção de uma ontologia abrangente:
• Identificação do propósito da ontologia, que é o porquê da
construção da ontologia;
• Construção da Ontologia, que se divide em:
a) Captura , que é a definição da conceitualização da ontologia;
b) Codificação , onde são representados através de uma
linguagem de representação de ontologias as classes, entidades e
relacionamentos definidos anteriormente;
c) Integração , onde se questiona a reutilização de ontologias já
existentes;
• Avaliação da Ontologia, onde a ontologia é verificada segundo os
requisitos especificados; e por fim,
• Documentação, onde é descrito o processo de modelagem da
ontologia.
1.3.2.3 Metodologia Methontology
Esta metodologia foi desenvolvida no laboratório de Inteligência
Artificial do Politécnico de Madri entre 1996 e 1997. O processo de desenvolvimento
de ontologias referencia quais as atividades (plano, especificação, conceitualização,
formalização, integração, implementação, avaliação, documentação e manutenção)
devem ser cumpridas ao se construir ontologias.
A atividade plano é a tarefa de organizar e planejar as tarefas que
serão realizadas. Na especificação , é definido o escopo e o objetivo da construção
da ontologia. Na atividade de conceitualização , é feito um levantamento dos termos
da ontologia. Na etapa de formalização , o modelo conceitual é formalizado para
uma linguagem formal. A integração é usada para integrar o modelo em
desenvolvimento com outras metodologias. Implementação se refere à parte de
tornar a ontologia processável por computadores, e para isso se utiliza linguagens
de programação, como por exemplo OIL, DAML+OIL e OWL. A etapa de avaliação
é feita antes da publicação da ontologia, para garantir sua qualidade e adequação
aos padrões. A documentação é feita para garantir a evolução desta ontologia. Por
fim, a manutenção são teorias sobre o mundo ou parte do mundo (domínio).
(BREITMAN, 2005).
1.3.2.4 Metodologia 101
Esse método é um guia para criação de ontologias. A sigla 101 em
inglês é o código utilizado para a primeira de uma série de disciplinas em uma
universidade, como Física I e Cálculo I, por exemplo. Foi proposto por Natalya Noy e
Deborah McGuiness (NOY e McGUINNESS, 2001), onde é feito um resumo das
experiências das autoras com o desenvolvimento das ferramentas Protégé2000,
Ontolingua e Chimaera.
O processo de construção de uma ontologia envolve as seguintes
etapas, de forma resumida:
• Definição das classes dessa ontologia;
• Arrumação das classes em uma hierarquia taxonômica
(subclasses e superclasses);
• Definição de propriedades e valores para os mesmos;
• Preenchimento dos valores dessas propriedades para cada
instância.
Porém, não existe uma maneira correta de se modelar um domínio,
pois sempre existem várias alternativas, visto que o desenvolvimento de ontologias
não é um processo linear. Muitas iterações e refinamentos são necessários para se
chegar a um modelo adequado.
Dessa forma, o Método 101 foi dividido em sete passos para o
desenvolvimento de ontologias:
1) Determinar o domínio e o escopo da ontologia
Para determinar o domínio e o escopo, as autoras sugerem que sejam
feitas as seguintes perguntas:
- Que domínio se deseja cobrir com a ontologia?
- Com que propósito(s) será utilizada a ontologia?
- Para que informações a ontologia deve fornecer respostas?
- Quem vai utilizar e manter a ontologia?
Estas questões servirão para avaliar a ontologia quando estiver pronta.
Por enquanto, verifica-se se a ontologia contém informação suficiente para
responder a todas essas perguntas.
2) Considerar o reuso de outras ontologias
Sempre vale a pena verificar se alguém já codificou os termos em uma
ontologia ou se é possível refinar um modelo existente para o domínio de aplicação.
Segundo Breitman (2005, p. 76), atualmente, existem bibliotecas de
ontologias que disponibilizam um grande número de modelos para o reuso. As
bibliotecas do projeto Ontolingua (www.ksl.stanford.edu/software/ontolingua) e a
biblioteca pública DAML (www.daml.org/ontologies) são exemplos de bibliotecas de
ontologias para reuso.
3) Enumerar os termos importantes da ontologia
Segundo Noy e McGuiness (2001, p. 6), é importante fazer uma lista
de termos que se deseja definir ou explicar para os usuários. Quais são os termos
que você gostaria de incluir? Quais são as propriedades desses termos? É
fundamental obter uma lista inicial de termos sem a preocupação com redundâncias
ou detalhar exaustivamente seus relacionamentos.
4) Definir classes e a hierarquia de classes
Existem várias estratégias para se definir uma hierarquia, dentre elas:
• Topo-para-baixo (Top-down) : é a mais comum de todas, remetendo à
maneira cartesiana para resolução de problemas. Um exemplo quase
canônico da utilização desse tipo de hierarquia é a Análise Estruturada.
Essa decomposição se inicia quando definimos os conceitos mais gerais e
segue através do processo de decomposição, onde colocamos a seguir do
termo mais abrangente (pai ou superclasse) os termos mais específicos
(filhos ou subclasses) através de relacionamentos de especialização.
• Baixo-para-cima (Bottom up) : nessa estratégia é definido, primeiramente, o
conjunto de termos mais específicos, para depois identificarmos possíveis
agrupamentos. Os grupos são organizados segundo uma estratégia de
generalização, onde uma classe mais genérica é escolhida como superclasse
para conceitos mais específicos. Essa estratégia permite que se tenha uma
visão total do conjunto de termos da ontologia, diminuindo o risco de ter de
fazer uma escolha de decomposição muito cedo no processo, o que resulta
em ontologias mais balanceadas.
• Combinação : utiliza uma mistura das duas estratégias anteriores. Conceitos
mais salientes são identificados e escolhidos. Desse conjunto de termos,
guia-se a generalização e decomposição dos termos.
Apesar de nenhum dos enfoques ser melhor do que os outros, a combinação
torna-se a favorita dos usuários menos experientes, já que os conceitos mais
utilizados no mundo real tendem a ser os intermediários, nem os mais gerais,
nem os mais específicos, segundo Rosch (1978 apud NOY e McGUINNESS,
2001, p. 7).
Um exemplo dessa estratégia seria se uma classe A é superclasse de uma
classe B, então toda instância de B também é instância de A, como mostra a
Figura 2:
Figura 2 – Taxonomia de Cabos para Rede de Computadores
5) Definir as propriedades das classes
Sozinhas, as classes não fornecem benefícios suficientes para
responder às questões de competência do primeiro passo. Dessa forma, como no
passo anterior, já foram selecionadas as classes da lista obtida no passo 3. Os
termos restantes, provavelmente, representam características ou propriedades
dessas classes.
Segundo Breitman (2005, p. 78), para cada propriedade dessa lista
temos de determinar a que classe pertence, visto que existem vários tipos de
propriedades relativas a classes: intrínsecas, extrínsecas, partes, estrutura,
relacionamentos com outras classes, e relacionamentos com outros itens, dentre
muitas outras. Todas as subclasses de uma classe herdam as propriedades da
classe-pai.
6) Definir os valores das propriedades
Propriedades podem assumir vários valores, dependendo da
linguagem de ontologia utilizada. Como exemplo, temos a cardinalidade, já que em
alguns sistemas é permitido que propriedades assumam valores únicos, enquanto
outros permitem cardinalidade multivalorados.
Em algumas linguagens é permitido utilizar tipos de dados no
preenchimento de valores de propriedades, possuindo os mais comuns, como:
• Cadeia de caracteres;
• Número (sendo especificados por inteiros ou decimais);
• Booleanos, e
• Vetores.
7) Criar instâncias
Nesse método, criam-se as instâncias individuais para classes na
hierarquia. Definir uma instância individual, escolhendo a classe, criando a instância
e preenchendo os valores das propriedades desta classe.
1.4 EXTENSIBLE MARKUP LANGUAGE (XML)
É uma linguagem de marcação recomendada pela W3C para a criação
de documentos com dados organizados hierarquicamente. A linguagem XML é
classificada como extensível porque permite que o usuário defina os elementos de
marcação (tags).
Um documento XML pode ser representado de diversas maneiras, pois
ele é utilizado para a representação sintática da informação, portanto a forma como
sua apresentação será formatada, poderá ficar a cargo de outras linguagens.
Figura 3 – Exemplo de código em HTML
Figura 4 – Exemplo de código em XML
Nas Figuras 3 e 4 aparecem, respectivamente, exemplos de uso da
linguagem HTML e sua representação em XML. Descrevem os tipos de cabos
existentes para uso em redes de computadores. Na linha 1, existe a tag de abertura
que define que o documento a seguir é codificado em HTML. Na linha 2, é definido o
título da página. Da linha 3 à linha 7, são apresentados os textos que indicam o
material disponível. O documento HTML é finalizado nas linhas 8 e 9. Já o
documento XML é iniciado na linha 10, onde é definido o elemento raiz do
documento. Na linha 11 é definido o título do documento. Em seguida na linha 12 é
definido o tipo de cabo e da linha 13 à linha 15, estão os tipos de cabos disponíveis.
O documento se encerra nas linhas 16 e 17.
Estes exemplos mostram que um documento XML é mais apropriado
para ser processado por computadores, pois é concebido de forma que as
informações sejam de fácil extração. A partir deste exemplo, um computador poderia
concluir que “Par Trançado” é um tipo de cabo utilizado para construção de redes de
computadores.
1.5 RESOURCE DESCRIPTION FRAMEWORK (RDF) E RDFSCHEMA
A tecnologia RDF permite equivaler um significado aos dados
estruturados em XML. A cada marca (tag) é associado o seu conceito real. É uma
estrutura para processar metadados (dados sobre dados), e seu principal objetivo é
o de facilitar o intercâmbio de informações que podem ser entendidas por máquinas,
entre aplicativos via Web. Essa equivalência é realizada por uma estrutura de três
elementos: o sujeito, o predicado e o objeto. Esta tripla de elementos pode ser
comparada com a forma de organizar uma frase em linguagem natural.
A informação referida é armazenada também em XML, sendo o
conteúdo de cada elemento da tripla um URI (Uniform Resource Identifier). Um URI
é um apontador para outro recurso disponibilizado na Internet e que contém o
significado de cada um desses elementos.
Estes recursos externos referenciados pelos URI’s são a fonte onde se
deve obter o significado real da marca XML utilizada. Este método é usado em
detrimento da pesquisa num repositório de conceitos e definições para as marcas, o
que permite ao autor do documento XML ser o único responsável pelo significado
das marcas que ele próprio cria.
O uso destas tecnologias coloca sobre o controle do publicador da
informação o conceito que pretende equivaler à sua informação. A associação entre
informação e seu significado é realizada de uma forma completamente livre, sem
rigidez de regras e sem quaisquer limites. Cada tripla de URI associada a uma
marca é considerada como sendo única. Esta informação é invisível ao utilizador que
visualiza a página, mas permite ao indexador automático armazená-la de modo a
refinar as suas pesquisas. Esta forma de armazenar o significado e a estrutura do
documento permite constituir uma rede de informação relacionada, onde será
possível aos homens e às máquinas aplicar regras de inferência para criar deduções
a partir dos significados descritos nas URI’s de cada tripla de informação.
Figura 5 – Exemplo de um documento RDF
Um exemplo de documento RDF é mostrado Figura 5. Nas linhas 1 e 2
são definidos dois Namespaces (xmlns:rdf e xmlns:ex), que fazem referência às
definições relacionadas ao RDF e ao documento exemplo em questão. Neste caso,
a sintaxe xmlns:rdf demonstra que será utilizado um recurso que já foi definido em
outro local. Nas linhas 3 a 7, são definidos o sujeito, o predicado e o objeto, ou seja,
a tripla RDF. O sujeito é o valor contido no atributo rdf:about da tag <rdf:Description>
(linha 3), o predicado é o verbo que age sobre o sujeito e é definido na linha 4 (ex:),
e o objeto, que é o substantivo que dá sentido à ação do sujeito, é definido na linha
5, pelo conteúdo do atributo rdf:about da tag <ex:é>. Neste exemplo, o documento
demonstra que o par trançado (sujeito) é (predicado) um tipo de cabo (objeto).
RDFSchema (Resource Description Framework Schema – W3C) é uma
linguagem que define a estrutura válida para os documentos RDF. É semelhante à
linguagem XMLSchema e junto com o RDF são recomendações do W3C que
definem o padrão para a representação de metadados e são a base das linguagens
que expressam semântica na Web Semântica.
Figura 6 – Exemplo de um documento RDFSchema
Na Figura 6 é exibido um exemplo de um documento RDFSchema,
onde na linha 5 é definida a classe principal (Tipo_Cabo). Logo após (linhas 6 a 11)
são definidas duas outras classes, que são dois tipos de cabos para rede de
computadores (Fibra Óptica e Par Trançado), e estas são referenciadas como
subclasses da classe principal, nas linhas 7 e 10.
O RDFSchema aborda classes, propriedades e valores, dando mais
poder na definição de uma ontologia, porém, limitando-se às hierarquias entre
classes. Esta limitação foi proposital por parte da W3C, para manter a linguagem
simples, mas é ainda menos poderosa que a linguagem OWL, perfeita para
ontologias que necessitem de mais expressividade, conforme será demonstrado na
Seção 1.6.
1.6 ONTOLOGY WEB LANGUAGE (OWL)
A OWL (Web Ontology Language – W3C) é uma revisão da linguagem
DAML+OIL. Ela possui mais facilidades para expressar significados e semânticas do
que XML, RDF e RDFSchema, embora seja baseada em RDF e RDFSchema, e
utilize a sintaxe XML.
A OWL foi projetada para ser usada por aplicações que necessitem
processar o conteúdo de informações, ao invés de somente apresentar a
visualização destas informações. O W3C recomenda às pessoas que queiram
construir ontologias, que utilizem a linguagem OWL, para que assim esta linguagem
se torne um padrão.
A OWL é uma linguagem para definir e instanciar ontologias para Web.
Uma ontologia OWL pode formalizar um domínio, definindo classes e propriedades
para estas classes, definir indivíduos e afirmações sobre eles e, usando-se a
semântica formal OWL, especificar como derivar conseqüências lógicas, isto é, fatos
que não estão presentes na ontologia, mas são vinculados pela semântica.
1.7 CONSIDERAÇÕES FINAIS
Neste capítulo foi apresentada a situação da Web atual, as principais
justificativas para a criação da Web Semântica. Estudou-se as tecnologias
recomendadas pelo World Wide Web Consortium (W3C) para o desenvolvimento da
Web Semântica, como o XML, RDF, RDFSchema e OWL; bem como feita uma
explicação sobre o que é a Web Semântica e o os pré-requisitos para que ela se
torne realidade.
No Capítulo 2, serão apresentadas as ferramentas para o
desenvolvimento gráfico das ontologias, inferências e consultas nas mesmas.
2 FERRAMENTAS PARA A WEB SEMÂNTICA
2.1 CONSIDERAÇÕES INICIAIS
Neste capítulo serão abordadas algumas especificações que
propiciam adicionar informações semânticas aos dados publicados na Web, de
forma que estes se tornem suficientemente entendidos por máquinas sem que haja
necessidade de intervenção humana. São apresentadas algumas ferramentas que
facilitam a criação e manipulação de uma ontologia, tais como o sistema Protégé e
as API’s JENA e SPARQL.
2.2 PROTÉGÉ
A ferramenta Protégé (disponível em: http://protege.stanford.edu) foi
desenvolvida pelo Centro de Pesquisa de Informática Biomédica da Universidade
de Stanford, USA, num projeto liderado por Mark Musen, no ano de 1987, cujo
objeto de pesquisa era a criação de uma meta-ferramenta open-source para
sistemas baseados em conhecimento na área médica.
A ferramenta original era uma aplicação que tinha como intenção a
construção de ferramentas de aquisição de conhecimento para alguns programas
especializados em planejamento médico. Hoje, o Protégé funciona em várias
plataformas, incorpora a Conectividade de Base de Conhecimento Aberta (Open
Knowledge Base Connectivity – OKBC), possui alguns plugins (extensões de
interface de usuários customizadas), interage com vários padrões de
armazenamento como XML, RDF e OWL, além de poder ser armazenado em bases
de dados relacionais. Ele está sendo utilizado por vários grupos de pesquisa, além
de pessoas, tanto em pesquisas como em áreas comerciais.
O Protégé é um ambiente de desenvolvimento flexível, operacional e
robusto. Desenvolvedores podem construir através dele sistemas baseados em
conhecimentos, além de explorar novas idéias (inferências) geradas sobre estas
bases.
O Protégé não é um sistema especialista nem um programa que
constrói sistemas especialistas, ao contrário, ele é uma ferramenta que ajuda os
usuários a construírem outras ferramentas que são adaptadas para ajudar a
aquisição de conhecimento para sistemas especialistas em áreas de aplicações
específicas.
Figura 7 – Protégé em funcionamento
2.3 API JENA
A API JENA é uma API Java para manipulação dinâmica de modelos
RDF (grafos). Foi desenvolvida pelo Hewlett-Packard Labs Semantic Web
Research, e atualmente é disponibilizada como software livre.
Esta API de desenvolvimento procura criar mais uma camada de
abstração para a criação e navegação em documentos RDF e OWL, que são as
bases para o desenvolvimento da Web Semântica. Sendo que, ao se desenvolver
aplicações utilizando a JENA, o usuário desta API não necessita deter
conhecimentos aprofundados sobre as linguagens RDF e OWL, apenas ser
familiarizado com XML e Java.
Há ainda uma API específica para o tratamento de ontologias, a API
JENA 2 Ontology. Esta API transforma uma dada ontologia em um modelo abstrato
de dados orientado a objetos, possibilitando que seus termos possam ser
manipulados como objetos, o que torna fácil o uso de linguagens de programação
orientadas a objetos, como Java, por exemplo.
A JENA caracteriza-se pela criação e manipulação de grafos RDF,
representados pelos recursos (resources), propriedades (properties) e literais
(literals), formando as tuplas que darão origem aos objetos criados pelo Java. O
exemplo de um grafo criado pela JENA pode ser observado na Figura 8:
Figura 8 – Hierarquia e relacionamento das interfaces. Fonte : http://www.xml.com/pub/a/2001/05/23/jena.html
2.4 INFERÊNCIAS
Inferências são deduções de uma informação através de outras, ou
seja, com base em regras pré-definidas, ou bases de conhecimento, torna-se
possível descobrir se um determinado tipo de cabo é uma fibra óptica ou um par
trançado, por exemplo.
O subsistema de inferência da API Jena é projetado para permitir uma
variedade de máquinas de inferência, que são usadas para derivar grafos RDF
adicionais (REYNOLDS, 2009). Esses novos grafos são baseados em uma fonte de
dados RDF que, opcionalmente, pode estar associada ou a alguma ontologia, ou a
um conjunto de regras.
Consultas a esse novo modelo retornarão não apenas aquelas
declarações RDF que constavam nos dados originais, mas também declarações
adicionais que foram derivadas desses dados originais, quer seja por meio de
regras, quer seja pode meio de inferência baseada em ontologias exclusivamente.
Nesta seção, são apresentados os dois tipos de inferência que podem ser utilizados
por aplicações a partir do subsistema de inferência da API JENA: a inferência
baseada em ontologias e a inferência baseada em regras .
2.4.1 Inferência baseada em ontologias
Em um processo de inferência baseado em ontologias, novos grafos
RDF são deduzidos a partir da combinação da semântica definida pelos construtores
da linguagem em que a ontologia foi construída, e de um conjunto de grafos
instanciados de tal ontologia. Assim, podem-se inferir (deduzir com raciocínio) novos
dados, baseando-se em relações de generalização, especialização, transitividade,
simetria, inversão, negação, etc.
2.4.2 Inferência baseada em regras
Para utilizar o mecanismo de inferência baseado em regras, estas
devem ser expressas por usuários ou desenvolvedores na forma de conjunções de
predicados dispostos em premissas e conclusão. Para isso, é utilizada a sintaxe de
construção de regras adotada pelo subsistema de inferência da API (REYNOLDS,
2009).
É importante destacar que a máquina de inferência para regras é
diferente daquelas utilizadas para inferência baseada em ontologias. Seus
parâmetros de configuração incluem, dentre outros, a descrição das regras em
questão e o tipo de encadeamento de regras. Este último parâmetro determina duas
maneiras que um desenvolvedor pode escolher para processar regras: progressivo
(forward) e regressivo (backward).
No encadeamento progressivo, a máquina de inferência investiga se
uma conjunção de predicados declarada como premissa da regra é encontrada em
um repositório de informações de contexto. Caso seja verdadeiro, consegue-se
inferir um novo grafo, declarado como conclusão da regra.
No encadeamento regressivo, o processamento é inverso: se o
predicado declarado na conclusão é encontrado, então a máquina de inferência
adiciona ao grafo resultante de inferência a conjunção de predicados declarados
nas premissas.
2.5 API SPARQL
A API SPARQL (Simple Protocol and RDF Query Language – W3C)
assemelha-se à linguagem SQL, sendo uma linguagem de consulta e protocolo de
acesso a dados em RDF.
Permite que arquivos RDF sejam consultados através da linguagem
SQL, podendo combinar dados de diferentes arquivos RDF, provenientes de
diferentes fontes. É uma linguagem orientada a dados, que recupera os dados
armazenados em arquivos RDF.
A SPARQL tem a mesma estrutura de construção de arquivos em
RDF, uma estrutura de três elementos: o sujeito, o predicado e o objeto.
A vantagem da utilização da SPARQL, é que a semelhança com a
linguagem SQL diminui a curva de aprendizado da linguagem.
Alguns exemplos de comandos em SPARQL, semelhantes ao SQL:
• SELECT [DISTINCT];
• FROM (opcional);
• WHERE (opcional);
• ORDER BY (opcional).
• LIMIT: limita a quantidade de linhas recuperadas da consulta;
A seguir, são mostrados comandos específicos da SPARQL:
• BASE : define a URI base de um recurso;
• FILTER: aplica um filtro sobre as linhas recuperadas pela consulta;
• OFFSET: permite que seja aplicado um deslocamento sobre o
conjunto de linhas recuperadas pela consulta;
• OPTIONAL : permite que uma linha seja recuperada mesmo que não
exista o valor de uma propriedade do RDF;
• PREFIX: cria um “apelido” para a URI de um arquivo RDF/OWL.
Variáveis são identificadas com os símbolos “?” ou “$”.
Figura 9 – Exemplo de documento RDF para consulta em SPARQL Fonte: http://www.daml.org/2003/01/periodictable/PeriodicTable
Exemplo de código SPARQL para uma consulta simples ao
documento anterior:
1 PREFIX table:<http://www.daml.org/2003/01/periodictable/PeriodicTable#>
2 SELECT ?name
3 FROM http://www.daml.org/2003/01/periodictable/PeriodicTable.rdf
4 WHERE { ?element table:name ?name. }
Retornaria a seguinte tabela de resultados:
Name
"sodium"^^<http://www.w3.org/2001/XMLSchema#string>
"copper"^^<http://www.w3.org/2001/XMLSchema#string>
"bismuth"^^<http://www.w3.org/2001/XMLSchema#string>
Tabela 1 – Resultados para consulta simples em uma ontologia. Fonte: BESTTETI, 2009.
Onde, em PREFIX table (linha 1), é dado um apelido ao endereço
onde será feita a consulta. SELECT ?name (linha 2), seleciona todos os nomes do
documento em questão. Na linha 3, através do comando FROM, seleciona-se o
documento OWL onde serão efetuadas as consultas, com a restrição apresentada
pela tripla sujeito (element), predicado (table:name) e objeto (variável ?name), na
linha 4.
Nesse exemplo, podemos observar a semelhança dos comandos da
SPARQL com o SQL.
O Protégé possui o SPARQL integrado ao seu ambiente de
desenvolvimento, como mostra a Figura 10:
Figura 10 – Protégé com SPARQL integrado
2.6 CONSIDERAÇÕES FINAIS
Neste capítulo foram estudadas as principais ferramentas que auxiliam
no desenvolvimento de ontologias, de acordo com as especificações da W3C.
Dentre elas, citou-se as API’s JENA e SPARQL, a ferramenta para representação
gráfica de ontologias Protégé, e conceitos sobre inferências.
No Capítulo 3, será apresentada a criação da ontologia CERCOnt, com
a metodologia 101, citada no Capítulo 1.
3 DESENVOLVIMENTO DA ONTOLOGIA COM A METODOLOGIA 10 1
3.1 CONSIDERAÇÕES INICIAIS
Com base em pesquisas existentes na literatura, viu-se a necessidade
de um conjunto de tipos semânticos que facilite a criação de uma estrutura que
auxilie no compartilhamento e na recuperação de bases de conhecimento utilizadas
por projetistas na execução de projetos de cabeamento estruturado de redes de
computadores. Dessa forma, este trabalho de conclusão de curso propõe-se a criar
uma ontologia que defina tais tipos semânticos.
Neste capítulo será apresentada a ontologia CERCOnt (Ontologia de
Cabeamento Estruturado de Redes de Computares) e, ainda, expor seu processo de
desenvolvimento.
3.2 ESCOLHA DA METODOLOGIA
Hoje, existem várias metodologias com a função de guiar a construção
e desenvolvimento de ontologias, das quais podemos citar a TOVE (Gruninger e
Fox, 2002), Uschold (Osterwalder e Pigneur, 2002) e a Metodologia 101 (Noy e
McGuinness, 2001), já citada no Capítulo 1.
Tais metodologias não são uma “receita de bolo” a serem seguidas à
risca. São modelos empíricos baseados na experiência dos projetos, onde foram
criadas e definidas pelos seus criadores. Dentre as metodologias pesquisadas, a
metodologia 101 mostrou-se a mais prática, objetiva, didática e capaz de atender e
satisfazer as características da ontologia CERCOnt.
Como mencionado no Capítulo 1, a metodologia 101 define sete
passos a serem seguidos para se construir uma ontologia. Os resultados da
execução dos sete passos desta metodologia para a construção da CERCOnt são
apresentados a seguir.
3.2.1 Determinar o Domínio e Escopo da Ontologia
Neste passo, define-se que a CERCOnt possui o domínio e o escopo
de tipos de cabos de rede, para o desenvolvimento de projetos de cabeamento
estruturado para redes de computadores, segundo o programa FCP (Furukawa
Certified Professional). Afirma-se ainda, que a CERCOnt será utilizada para auxiliar
projetistas de cabeamento estruturado de redes de computadores a escolher os
melhores tipos de cabo, de acordo com as normas ABNT, para determinada
aplicação.
Dessa forma, a CERCOnt fornecerá respostas para perguntas do tipo:
• Quais são os cabos metálicos?
• Quais são os cabos blindados?
• Quais são os cabos não metálicos?
• Quais são os cabos não blindados?
• Quais são os cabos metálicos e blindados?
• Quais são os cabos metálicos e não blindados?
• Quais são os cabos não metálicos e não blindados?
• Coaxial é um tipo de cabo de rede de computadores?
• Par Trançado é um tipo de cabo de rede de computadores?
• Fibra óptica é um tipo de cabo de rede de computadores?
• Qual o cabo com a maior velocidade de transmissão?
• Qual o cabo com a menor atenuação?
• Quais os cabos que podem ter blindagem?
• Quais são os cabos que não podem ter blindagem?
• Qual o cabo com o maior alcance de transmissão?
E o último aspecto do Passo 1, é discutir quem utilizará e manterá a
CERCOnt, onde viu-se que os possíveis usuários da CERCOnt são projetistas de
redes de computadores que estão iniciando a carreira, bem como os mais
experientes, que desejam compartilhar suas experiências com os demais usuários
da ontologia. Assim, alunos de redes de computadores também poderão fazer uso
da CERCOnt durante estudos sobre tipos de cabos de redes.
3.2.2 Considerar o Reuso de Outras Ontologias
Pesquisou-se em bibliotecas de ontologias, para encontrar ontologias
para reuso durante o desenvolvimento da CERCOnt nas bibliotecas públicas do
projeto Ontolingua (www.ksl.stanford.edu/software/ontolingua) e DAML
(www.daml.org/ontologies), e também no site SchemaWeb – RDFSchemas Directory
(http://www.schemaweb.info), porém nada foi encontrado para reuso na CERCOnt.
3.2.3 Enumerar os Termos Importantes da Ontologia
O primeiro conjunto de termos utilizados na criação da CERCOnt
refere-se a termos relacionados à classificação dos cabos para rede de
computadores. A tabela a seguir mostra exemplos de termos do primeiro conjunto
presentes na CERCOnt:
Termo Descrição Textual
Fibra Óptica Não Metálica
Não Blindada 1
Cabo de fibra óptica de 125 µm, multimodo,
para transmissão de dados em alta velocidade,
imune a interferências eletromagnéticas.
Par Trançado Metálico
Blindado 1
Cabo par trançado de 24 AWG para aplicações
externas, graças à malha de blindagem,
deixando-o imune às interferências
eletromagnéticas.
Par Trançado Metálico Não
Blindado 1
Cabo par trançado de 24 AWG para aplicações
internas, suscetível à interferências
eletromagnéticas.
Coaxial Metálico Blindado 1 Cabo coaxial de 810 µm, geralmente utilizado
em transmissões de vídeo e som.
Coaxial Metálico Não
Blindado 1
Cabo coaxial de 810 µm, para transmissões de
alta freqüência e curtas distâncias, devido sua
alta atenuação.
Tabela 2 – Termos do primeiro conjunto presentes na CERCOnt
3.2.4 Definir Classes e Hierarquia de Classes
A CERCOnt é composta basicamente por oito tipos semânticos
relacionados, como mostra a Figura 11:
Figura 11 – Definição dos Tipos Semânticos da CERCOnt
• Tipo do Cabo : É a especificação da sua estrutura e da sua finalidade
de uso.
• Metálico: Cabo fabricado com elementos metálicos, sendo o elemento
mais comum, o Cobre.
• Não Metálico: Cabo fabricado sem elementos metálicos, sendo o mais
comum, a Fibra Óptica.
• Blindado: Cabo fabricado com uma proteção contra interferências
eletromagnéticas, diminuindo sua atenuação em ambientes onde há
muita interferência, sendo uma opção mais viável que a Fibra Óptica,
onde muitas vezes sua implantação não é economicamente viável.
• Não Blindado: Cabo fabricado sem proteção a interferências
eletromagnéticas.
• Coaxial : Tipo de cabo condutor de sinais elétricos, constituído por um
fio de cobre, revestido por material isolante dielétrico, rodeado de
uma blindagem.
• Par Trançado : Tipo de cabo condutor de sinais elétricos, constituído
por um conjunto de oito fios trançados em pares, para cancelar
interferências eletromagnéticas.
• Fibra Óptica : Filamento de vidro ou de materiais poliméricos com
capacidade de transmitir luz podendo apresentar diversos diâmetros.
Não sofrem interferências eletromagnéticas por transmitirem sinais
luminosos.
3.2.5 Definir as Propriedades das Classes
De acordo com a Figura 11, as propriedades das subclasses seguem
listadas a seguir:
1) Propriedades do tipo semântico Tipo do Cabo:
• Aplicação : Ambiente onde o tipo de cabo será aplicado no
desenvolvimento do projeto de cabeamento estruturado.
• Bitola do Cabo : Medida do diâmetro externo final do cabo.
• Distância Máxima de Transmissão : Distância máxima permitida
pela norma ABNT para transmissão segura dos dados.
• Resistência Física : Resistência do cabo relacionada à aplicação
deste no meio ambiente.
• Tipo do Conector : Um conector é um dispositivo que efetua a
ligação entre uma porta de saída de um determinado equipamento
e a porta de entrada de outro.
• Velocidade de Transmissão : Medida do tempo gasto para uma
informação chegar ao seu destino. É medida em bits por segundo
(bps).
2) Propriedades do tipo semântico Metálico:
• Tipo do Isolante: Material que reveste o cabo.
3) Propriedades do tipo semântico Não Metálico:
• Meio de Transmissão: Canal onde são transmitidos os dados.
4) Propriedades do tipo semântico Blindado:
• Tipo da Blindagem: Material adicionado na fabricação do cabo,
que auxilia a anulação de interferências eletromagnéticas.
5) Propriedades do tipo semântico Não Blindado:
• Atenuação: Perda excessiva na potência do sinal transmitido, de
modo que o sinal original chegue ao destino com falhas ou até
mesmo que este não seja reconhecido.
6) Propriedades do tipo semântico Coaxial:
• Impedância : Resistência que o cabo oferece à transmissão de um
sinal elétrico.
7) Propriedades do tipo semântico Par Trançado:
• Categoria : São padrões definidos pela norma EIA/TIA 568-B para
cabos de par trançado que leva em consideração o nível de
segurança e o diâmetro do cabo;
8) Propriedades do tipo semântico Fibra Óptica:
• Tipo de Fabricação : Refere-se ao tipo da fibra óptica: multimodo
(MM) ou monomodo (SM).
• Fonte Geradora de Sinal: Diodos semicondutores modulados
diretamente pela variação da corrente de entrada.
3.2.6 Definir os Valores das Propriedades
Logo a seguir, seguem relacionados os valores das propriedades
descritas no passo 5:
• Aplicação : identificador único de uma string.
• Atenuação : identificador único de um float.
• Bitola do Cabo : identificador único de um float.
• Categoria : identificador único de uma string.
• Distância Máxima de Transmissão : identificador único de um
float.
• Fonte Geradora de Sinal: identificador único de uma string.
• Impedância: identificador único de um float.
• Meio de Transmissão: identificador único de uma string.
• Resistência Física : identificador único de uma string.
• Tipo da Blindagem : identificador único de uma string.
• Tipo do Conector : identificador único de uma string.
• Tipo de Fabricação : identificador único de uma string.
• Tipo do Isolante : identificador único de uma string.
• Velocidade de Transmissão : identificador único de um float.
3.2.7 Criar Instâncias
No sétimo e último passo da metodologia 101, são criadas instâncias
dos tipos semânticos da CERCOnt. Sendo assim, seguem abaixo algumas
instâncias criadas:
Fibra Óptica Não Metálica Não Blindada 1:
- Bitola do Cabo: 125 µm;
- Distância Máxima de Transmissão: até 2 Km;
- Velocidade de Transmissão: 622 Mbps;
- Aplicação: rápida transmissão de dados;
- Resistência Física: Baixa emissão de fumaça, livre de halogênio;
- Tipo do Conector: VJ-45;
- Meio de Transmissão: Feixe de luz;
- Atenuação: 0,7 dB / Km;
- Tipo de Fabricação: Multimodo;
- Fonte Geradora de Sinal: LED.
Par Trançado Metálico Não Blindado 1:
- Bitola do Cabo: 24 AWG;
- Distância Máxima de Transmissão: até 100 m;
- Velocidade de Transmissão: 100 Mbps;
- Aplicação: interna, redes com tráfego normal de dados;
- Resistência Física: Baixa emissão de fumaça, livre de halogênio;
- Tipo do Conector: RJ-45;
- Tipo do Isolante: Polietileno;
- Atenuação: 22 dB;
- Categoria: CAT 5e.
Par Trançado Metálico Blindado 1:
- Bitola do Cabo: 24 AWG;
- Distância Máxima de Transmissão: até 100 m;
- Velocidade de Transmissão: 1 Gbps;
- Aplicação: externa, redes com tráfego normal de dados, que sofrem
muita interferência eletromagnética;
- Resistência Física: Baixa emissão de fumaça, livre de halogênio;
- Tipo do Conector: RJ-45;
- Tipo do Isolante: Polietileno;
- Tipo de Blindagem: Malha;
- Categoria: CAT 6.
Coaxial Metálico Não Blindado 1:
- Bitola do Cabo: 810 µm
- Distância Máxima de Transmissão: até 90 m;
- Velocidade de Transmissão: 10 Mbps;
- Aplicação: Circuitos fechados de TV;
- Resistência Física: Baixa emissão de fumaça, livre de halogênio;
- Tipo do Conector: Coaxial Tipo F;
- Tipo do Isolante: PVC;
- Atenuação: 34 dB;
- Impedância: 75 Ohms.
Coaxial Metálico Blindado 1:
- Bitola do Cabo: 810 µm
- Distância Máxima de Transmissão: até 90 m;
- Velocidade de Transmissão: 10 Mbps;
- Aplicação: Circuitos fechados de TV;
- Resistência Física: Baixa emissão de fumaça, livre de halogênio;
- Tipo do Conector: Coaxial Tipo F;
- Tipo do Isolante: Teflon;
- Tipo da Blindagem: Malha de Faraday;
- Impedância: 75 Ohms.
3.3 CONSIDERAÇÕES FINAIS
Neste capítulo foi desenvolvida a CERCOnt, um estudo de caso sobre
ontologia, e apresentados seus resultados, de acordo com a metodologia 101.
No capítulo seguinte são apresentados os resultados obtidos com a
pesquisa sobre a ontologia, o desenvolvimento da aplicação JCERCOnt, que foi
utilizada para efetuar inferências na CERCOnt, a criação da ontologia com a
ferramenta Protégé e, ainda, as telas da aplicação.
4 DESENVOLVIMENTO DE UMA APLICAÇÃO PARA CONSULTA À ONTOLOGIA
4.1 CONSIDERAÇÕES INICIAIS
Este Capítulo descreve a implementação da aplicação JCERCOnt, que
responde à perguntas de competência da ontologia CERCOnt, que foi apresentada
no Capítulo 3 deste trabalho, tendo sua implementação explicada na Seção 4.2.
4.2 IMPLEMENTAÇÃO DA ONTOLOGIA CERCONT COM A FERRAMENTA
PROTÉGÉ
Depois de descritos os passos da metodologia 101 no Capítulo 3 deste
trabalho, a ontologia CERCOnt foi implementada com o auxílio da ferramenta
Protégé, que foi escolhida devido à sua grande utilização pela comunidade
acadêmica.
Nesta ferramenta, foram criadas as classes correspondentes ao passo
4 da metodologia 101, descrito na Seção 3.2.4. A seguir, foram seguidos os passos
5 e 6 da metodologia, descritos nas Seções 3.2.5 e 3.2.6, adicionando propriedades
e seus tipos. Com as propriedades definidas, foram criadas algumas instâncias na
ontologia, conforme o passo 7 da metodologia, descrito na Seção 3.2.7.
Em seguida, foi executada a opção de exportação da ontologia para o
formato RDFS, que gerou o arquivo CERCOnt.rdfs. Foi exportado ainda, o conteúdo
das instâncias geradas a partir da ontologia CERCOnt, para o formato RDF, que
gerou o arquivo CERCOnt.rdf. Tais arquivos encontram-se disponíveis no
APÊNDICE A e no APÊNDICE B, ao final deste trabalho.
4.2.1 Entendendo o arquivo CERCOnt.rdfs
Na Figura 12, é apresentada uma parte do arquivo CERCOnt.rdfs, que
cria a classe “Fibra_Optica”.
Figura 12 – Criação da Classe “Fibra_Optica”, no arquivo CERCOnt.rdfs
Na Figura 12, é possível observar que o conceito Fibra_Optica está
relacionado com a especialização dos conceitos Nao_Blindado, Nao_Metalico e
Tipo_do_Cabo, sendo este um exemplo de herança múltipla possível de ser
implementado pela especificação RDFS. Dessa forma podemos afirmar que:
• Fibra_Optica é um Nao_Blindado;
• Fibra_Optica é um Nao_Metalico; e
• Fibra_Optica é um Tipo_do_Cabo.
Sendo assim, quando for implementada, a classe Fibra_Optica trará
todas as propriedades que foram definidas nas classes Nao_Blindado, Nao_Metalico
e Tipo_do_Cabo.
Figura 13 – Definição das propriedades da Classe Nao_Blindado
Analisando a Figura 13, observa-se a definição do elemento domain,
apontando para a classe Nao_Blindado, onde a faixa de valores possíveis são
valores literais. Assim, podemos afirmar que:
• Fibra_Optica é um Não_Blindado, portanto toda instância de
Fibra_Optica possui a propriedade atenuacao
• Todo Nao_Blindado possui a propriedade atenuacao.
Do mesmo modo apresentado anteriormente, foram criadas as demais
classes e suas respectivas propriedades da ontologia CERCOnt.
4.2.2 Entendendo o arquivo CERCOnt.rdf
A Figura 14, ilustra um trecho do arquivo CERCOnt.rdf, onde foi criada
uma instância para a classe Fibra_Optica:
Figura 14 – Exemplo de instância da classe Fibra_Optica
A instância criada é identificada com o atributo “rdf:about”, indicando o
nome do recurso que representará essa instância. Entre as linhas 23 e 32 são
definidos os valores para cada propriedade relacionada à classe em questão. Todas
as demais instâncias da ontologia foram criadas dessa mesma forma.
4.3 DESENVOLVIMENTO DA APLICAÇÃO PARA CONSULTA JCERCOnt
Nesta Seção, será apresentado o desenvolvimento da aplicação
JCERCOnt, que foi implementada em JAVA, após a criação da ontologia CERCOnt,
que consulta os dados modelados nesta ontologia.
Para desenvolvimento desta aplicação, foi utilizada a API JENA, citada
na Seção 2.3 deste trabalho, para a criação de uma máquina de inferência
possibilitando assim as consultas à ontologia, e respostas às questões de
competência da CERCOnt.
Foi utilizada também, a API SPARQL, citada na Seção 2.5 deste
trabalho, para consulta no modelo após sua passagem pela máquina de inferência
implementada pela API JENA.
A Figura 15 ilustra a interface principal da aplicação JCERCOnt:
Figura 15 – Tela principal da aplicação JCERCOnt
Observa-se dois conjuntos de elementos com ações distintas, que são
explicadas a seguir:
1) Abrir Arquivo - RDF Schema (Ontologia): neste campo de texto é
inserido o caminho onde está salvo o arquivo do modelo da ontologia, cuja cópia do
arquivo é apresentada no APÊNDICE A deste trabalho;
2) Abrir Arquivo – RDF (Instâncias): neste campo de texto é
inserido o caminho onde está salvo o arquivo que contém as instâncias da ontologia,
cuja cópia é apresentada no APÊNDICE B deste trabalho;
3) Salvar Arquivo – RDF (Instâncias do Modelo Inferido): neste
campo de texto é inserido o local onde será salvo o modelo já inferido, utilizando a
máquina de inferências implementada com o auxílio da API JENA, cuja cópia do
arquivo é apresentada no APÊNDICE C deste trabalho
4) Inferir Modelo: neste botão de ação está implementado o método
que cria a máquina de inferência e salva o modelo inferido no arquivo inserido no
campo de texto do item 3 desta explicação, onde a implementação pode ser
observada na Figura 16:
Figura 16 – Implementação do botão Inferir Modelo
Na linha 253 é criado o modelo de inferência no objeto infModelo , com
a chamada do método JCERCOnt.InfereModelo() implementado na classe
CERCOnt.java, para o encapsulamento deste método. A seguir, é apresentado o
método implementado na classe CERCOnt.java:
Figura 17 – Método infereModelo() da classe CERCOnt.java
Na linha 82 é criado um recurso vazio, de nome infere , e logo a seguir,
alterado o nível de compilação deste em Simples. Na linha 88, é criada uma
máquina de inferência com o recurso anterior passado como parâmetro, criando
assim um modelo usando a marcação “simple” neste. E finalmente, na linha 91, é
criado um modelo de inferência, através do método createInfModel(), onde são
passados como parâmetros a máquina de inferência (parâmetro reasoner), a
ontologia (parâmetro rdfs) e as instâncias (parâmetro rdf).
A seguir, são apresentadas as ações de cada um dos sete botões
referentes às perguntas de competência da ontologia CERCOnt:
1 – Quais são as instâncias de Cabos Metálicos? Ao acionar este
botão, a área de respostas deve receber as instâncias de classes que são
subclasses de Metálico. O resultado dessa questão é apresentado na Figura 18:
Figura 18 – Resposta para a questão 1
2 – Quais são as instâncias de Cabos Metálicos e Ca bos
Blindados? Ao acionar este botão, a área de respostas deve receber as instâncias
de classes que são subclasses de Metálico e também de Blindado. O resultado
dessa questão é apresentado na Figura 19:
Figura 19 – Resposta para a questão 2
3 – Quais são as instâncias de Cabos Blindados e Ca bos Não-
Blindados? Ao acionar este botão, a área de respostas deve receber as instâncias
de classes que são subclasses de Blindado e também de Não-Blindado. O resultado
dessa questão é apresentado na Figura 20:
Figura 20 – Resposta para a questão 3
4 – Quais são as instâncias de Cabos Metálicos e Ca bos Não-
Metálicos? Ao acionar este botão, a área de respostas deve receber as instâncias
de classes que são subclasses de Metálico e também de Não-Metálico. O resultado
dessa questão é apresentado na Figura 21:
Figura 21 – Resposta para a questão 4
5 – Quais são as instâncias de Cabos Não-Metálicos ou Cabos
Blindados? Ao acionar este botão, a área de respostas deve receber as instâncias
de classes que são subclasses de Não-Metálico ou de Blindado. O resultado dessa
questão é apresentado na Figura 22:
Figura 22 – Resposta para a questão 5
6 – Quais são as instâncias de Cabos Metálicos ou C abos
Blindados e Cabos Não-Blindados? Ao acionar este botão, a área de respostas
deve receber as instâncias de classes que são subclasses de Metálico ou Blindado e
Não-Blindado. O resultado dessa questão é apresentado na Figura 23:
Figura 23 – Resposta para a questão 6
7 – Quais são as instâncias de Cabos Não-Metálicos e Cabos Não-
Blindados? Ao acionar este botão, a área de respostas deve receber as instâncias
de classes que são subclasses de Blindado e Não-Blindado. O resultado dessa
questão é apresentado na Figura 24:
Figura 24 – Resposta para a questão 7
Após apresentadas as respostas para as ações dos botões, faz-se
necessário demonstrar e explicar a codificação de dois dos botões para apresentar a
utilização da SPARQL. Para isso, foi utilizada a codificação do botão que responde à
pergunta 1.
A execução da ação deste botão pode ser dividida em duas partes. A
primeira consulta mostra o procedimento de recuperação das subclasses da classe
Metálico usando a consulta SPARQL como mostra a Figura 25.
Nas linhas 278 a 288, é criada uma string de consulta SPARQL onde
na clausula WHERE, são vistas as restrições que serão aplicadas ao conjunto de
tripla RDF. Assim, serão retornadas as triplas que satisfizerem os seguintes critérios:
Predicado igual a rdfs:subClassOf, Objeto igual a cercont:Metalico. Dessa forma, a
variável ?X recebe todos os sujeitos que satisfizerem o critério de consulta destas
linhas. Nas linhas 290 a 292, configura-se a Engine de consulta da SPARQL. Na
linha 293, a variável results recebe uma lista contendo os elementos de retorno da
consulta efetuada na linha 292. Com o comando de repetição FOR da linha 295, é
percorrida essa lista de resultados, onde na linha 297, recupera-se o sujeito da tripla
através da variável X.
Figura 25 – Primeira parte da consulta SPARQL do botão 1
Feita esta consulta, o vetor vet da classe Vector(), conterá todas as
classes que são subclasses de Metálico. Sendo assim, para recuperar as instâncias
dessas classes, percorreu-se na linha 310 onde é feita uma nova consulta a cada
item que foi adicionado ao vetor vet. Este processo é apresentado na Figura 26,
onde nas linhas 315 a 324 é configurada uma nova consulta aos elementos deste
vetor. Na clausula WHERE (linha 320), são vistas as restrições que deverão ser
aplicadas ao conjunto de tripla RDF, que retornarão as triplas que satisfazem os
seguintes critérios: Predicado igual a rdf:type e Objeto igual a subclasse de Metálico.
Assim, a variável ?X receberá todos os sujeitos que satisfizerem o critério de
consulta desta linha. Nas linhas 326 a 328, configura-se novamente a Engine da
SPARQL. Na linha 329, a variável results, recebe agora uma lista contendo os
elementos de retorno da consulta efetuada na linha 328. Com o comando de
repetição FOR da linha 331, é percorrida essa lista de resultados, onde na linha 333,
recupera-se o sujeito da tripla através da variável X. Esta variável agora contém uma
instância de Metálico.
Figura 26 – Segunda parte da consulta SPARQL do botão 1
Na Figura 27, é apresentada a consulta para o botão que responde à
pergunta 2. A diferença entre a pergunta 1 e as demais perguntas está no operador
relacional E ou OU, que aparece nas perguntas de 2 a 7. Para solucionar esse
problema, nas linhas 371 a 373, as instâncias encontradas pela clausula WHERE,
do mesmo modo explicado anteriormente, são adicionadas somente as instâncias
das classes que satisfazem a condição descrita na linha 371.
Figura 27 – Consulta SPARQL do botão 2
Dessa mesma forma, foram implementadas as outras respostas de
competência da CERCOnt.
4.4 CONSIDERAÇÕES FINAIS
Neste capítulo, foi apresentado o desenvolvimento da ontologia
CERCOnt, explicados os arquivos gerados pela ferramenta Protégé, cujos arquivos
estão disponíveis nos apêndices, no final desse trabalho.
Foi apresentada ainda, o desenvolvimento da aplicação JCERCOnt
que responde às questões de competência desta ontologia, que faz uso da API
JENA para representação da CERCOnt, e a SPARQL como linguagem de consultas.
Essas duas API’s foram utilizadas para a implementação das sete perguntas de
competência da ontologia CERCOnt.
CONCLUSÃO
O objetivo deste trabalho foi a criação de uma ontologia que aborda as
especificações dos tipos de cabos para construção de redes de computadores. Para
que isso fosse possível, foram estudadas as tecnologias utilizadas para a criação de
uma ontologia, seguindo o contexto da Web Semântica.
Uma ontologia de nome CERCOnt foi construída utilizando a
especificação RDF Schema e seguindo os critérios estabelecidos pela metodologia
101. Criou-se uma aplicação em JAVA utilizando a API JENA para que ocorresse a
interação com a ontologia e, para isso, utilizou-se uma máquina de inferência,
implementada com o auxílio desta API. Após os modelos terem passado pela
máquina de inferência, utilizou-se a linguagem SPARQL para efetuar consultas em
seus resultados.
Com base no propósito deste trabalho, o objetivo foi alcançado com o
desenvolvimento da ontologia CERCOnt e da aplicação para consultas JCERCOnt.
O estudo de caso apresentado neste trabalho, através da ontologia
CERCOnt, pode receber diversas melhorias, como a adição de um maior número de
propriedades para os diversos tipos de cabos, a fim de aumentar a expressividade
desta ontologia.
REFERÊNCIAS
ABOUT The World Wide Web. Disponível em: <http://www.w3.org/WWW/>. Acesso em: 9 out 2008. AN e-Business Model Ontology for Modeling e-Business. Disponível em: <http://inforge.unil.ch/aosterwa/Documents/eBusinessModels/Publications/ Bled02.htm>. Acesso em: 17 jun 2009. BESTTETI, Anderson. INTRODUÇÃO ao SPARQL. Disponível em: <www.inf.pucrs.br/~linatural/Docs/IntroducaoSPARQL.ppt>. Acesso em: 09 mai 2009. BERNERS-LEE, T.; HENDLER, J.; LASSILA, O. The semantic web. Scientific American, Maio 2001. Disponível em: <http://www.sciam.com/article.cfm?id=the-semantic-web>. Acesso em: 9 abr 2009. BREITMAN, Karin Koogan. Web Semântica: A internet do futuro. Rio de Janeiro: LTC, 2005. DAML Ontology Library. Disponível em: <http://www.daml.org/ontologies/>. Acesso em: 10 abr 2009. EXTENSIBLE Markup Language (XML). Disponível em: <http://www.w3.org/XML/>. Acesso em: 20 abr 2009. FCP – FURUKAWA CERTIFIED PROFESSIONAL, MF 101, 102, 103 e 104; 5ª Edição.
GRUBER, T.R. A Translation Approach to Portable Ont ology Specifications. Disponível em: <http://www-ksl.stanford.edu/KSL_Abstracts/KSL-92-71.html>. Ace sso em: 28 mar 2009. NASCIMENTO, L. E. TÓRTORO do. ObrigaOnt: Um Estudo de Caso para a Construção de Ontologias . 2006. 105 f. Trabalho de Conclusão de Curso
(Graduação em Ciência da Computação) – União de Cursos Superiores COC, Ribeirão Preto. NOY, N.F.; McGUINESS, D.L.. Ontology Development 101: A Guide to Creating Your First Ontology, 2001. ONTOLINGUA Home Page. Disponível em: <http://www.ksl.stanford.edu/software/ontolingua/>. Acesso em: 10 abr 2009. ONTOLOGY. Disponível em: <http://semanticweb.org/wiki/Ontology>. Acesso em: 9 out 2008. ONTOLOGY Web Language OWL. Disponível em: <http://www.w3.org/2004/OWL/>. Acesso em: 20 abr 2009. OPEN Knowledge Base Connectivity Working Group. Disponível em: <http://www.ai.sri.com/~okbc/>. Acesso em: 9 abr 2009. OWL Web Ontology Language Guide. Disponível em: <http://www.w3.org/TR/2004/REC-owl-guide-20040210/>. Acesso em: 17 mar 2009. RESOURCE Description Framework (RDF). Disponível em: <http://www.w3.org/RDF/>. Acesso em: 20 abr 2009. RESOURCE Description Framework (RDF) Schema. Disponível em: <http://www.w3.org/TR/rdf-schema/>. Acesso em: 20 abr 2009. RDF/XML Syntax Spcification (Revised). Disponível em: <http://www.w3.org/TR/rdf-syntax-grammar/>. Acesso em: 09 out 2008. REYNOLDS, Dave. Jena 2 Inference Support. Disponível em: <http://jena.sourceforge.net/inference/#api>. Acesso em: 21 ago 2009. ROSA, Paulo Augusto. Web Semântica . 2002. Trabalho Tópicos em Ciência da Computação – Instituto de Matemática e Estatítica – Universidade de São Paulo SCHEMAWEB – RDF Schemas Directory. Disponível em: <http://www.schemaweb.info/>. Acesso em: 29 ago 2009.
SEMANTIC Web Research at HP Labs. Disponível em: <http://www.hpl.hp.com/semweb/>. Acesso em: 9 abr 2009. SILVA, R. L. Repositório semântico de objetos de aprendizagem, Dezembro 2005. Anais do 3º Simpósio Internacional de Bibliotecas D igitais. Disponível em: <http://bibliotecas-cruesp.usp.br/3sibd/docs/silva522.pdf>. Acesso em: 9 abr 2009. SPARQL Query Language for RDF. Disponível em: <http://www.w3.org/TR/rdf-sparql-query/>. Acesso em: 9 abr 2009. STANFORD Center for Biomedical Informatics. Disponível em: <http://bmir.stanford.edu/>. Acesso em: 9 abr 2009. SUZUKI, Érika; SUZIKI, Vanessa, ABREU, Aline França de, SOUZA, Wilton. Sistemas de Conhecimento com o Uso de Commonkads e Ontologias – Um Alinhamento entre Negócios e Desenvolvimento. 2007. THE Jena Ontology API. Disponível em: <http://jena.sourceforge.net/ontology/>. Acesso em: 9 abr 2009. THE Protégé Ontology Editor and Knowledge Acquisition System. Disponível em: <http://protege.stanford.edu/>. Acesso em: 09 out 2008. THE Semantic Web. Disponível em: <http://www.w3.org/2002/03/semweb/>. Acesso em: 9 out 2008. TOVE Ontology Project. Disponível em: <http://www.eil.utoronto.ca/enterprise-modelling/tove/>. Acesso em: 17 jun 2009. W3C HTML. Disponível em: <http://w3.org/html/>. Acesso em: 9 out 2008. W3C Consortium. Disponível em: <http://www.w3.org/2001/12/semweb-fin/swlevels.png>. Acesso em: 9 abr 2009. WEB Ontology Language (OWL). Disponível em: <http://www.w3.org/2004/OWL/>. Acesso em: 9 out 2008.
WHAT is an Ontology? Disponível em: <http://www-ksl.stanford.edu/kst/what-is-an-ontology.html>. Acesso em: 17 mar 2009.