SlideShare uma empresa Scribd logo
1 de 70
Baixar para ler offline
ALISON ROBERTO DE OLIVEIRA CARVALHO
            CAIO FUNES NASCIMENTO




WEB SEMÂNTICA E ONTOLOGIAS: UM ESTUDO DE CASO




                      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




                   FRANCA
                     2009
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 101.. 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 101




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
                                   Cabo de fibra óptica de 125 µm, multimodo,
   Fibra Óptica Não Metálica
                                   para transmissão de dados em alta velocidade,
   Não Blindada 1
                                   imune a interferências eletromagnéticas.
   Par Trançado Metálico           Cabo par trançado de 24 AWG para aplicações
   Blindado 1                      externas, graças à malha de blindagem,
deixando-o        imune     às    interferências
                                    eletromagnéticas.
                                    Cabo par trançado de 24 AWG para aplicações
  Par Trançado Metálico Não
                                    internas,      suscetível    à    interferências
  Blindado 1
                                    eletromagnéticas.
                                    Cabo coaxial de 810 µm, geralmente utilizado
  Coaxial Metálico Blindado 1
                                    em transmissões de vídeo e som.
                                    Cabo coaxial de 810 µm, para transmissões de
  Coaxial Metálico Não
                                    alta freqüência e curtas distâncias, devido sua
  Blindado 1
                                    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 Cabos
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 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 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 Cabos 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 Cabos
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 Ontology
Specifications.           Disponível            em:            <http://www-
ksl.stanford.edu/KSL_Abstracts/KSL-92-71.html>. Acesso 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 Digitais. 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.

Mais conteúdo relacionado

Semelhante a Web Semântica: Desenvolvimento de Ontologia para Classificação de Cabos

Modelagem de Base de Conhecimentos Baseada em Ontologia Estudo de Caso em Rec...
Modelagem de Base de Conhecimentos Baseada em Ontologia Estudo de Caso em Rec...Modelagem de Base de Conhecimentos Baseada em Ontologia Estudo de Caso em Rec...
Modelagem de Base de Conhecimentos Baseada em Ontologia Estudo de Caso em Rec...Vagner Nogueira
 
REST – Desmistificando A Implementação De Web Services REST Em Java Monografia
REST – Desmistificando A Implementação De Web Services REST Em Java MonografiaREST – Desmistificando A Implementação De Web Services REST Em Java Monografia
REST – Desmistificando A Implementação De Web Services REST Em Java MonografiaCarl Edwin Antonio Nascimento
 
Monografia restful -_2013_-_desenvolvimento_v17-final-2014[1]
Monografia restful -_2013_-_desenvolvimento_v17-final-2014[1]Monografia restful -_2013_-_desenvolvimento_v17-final-2014[1]
Monografia restful -_2013_-_desenvolvimento_v17-final-2014[1]Carl Edwin
 
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS JoomlaProcesso de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS JoomlaJúlio Coutinho
 
Classificação de padrões usando redes neurais
Classificação de padrões usando redes neuraisClassificação de padrões usando redes neurais
Classificação de padrões usando redes neuraisWanderson Rocha
 
Tutorialoracleformsbuilder 140813182046-phpapp01
Tutorialoracleformsbuilder 140813182046-phpapp01Tutorialoracleformsbuilder 140813182046-phpapp01
Tutorialoracleformsbuilder 140813182046-phpapp01Audervan S
 
Tutorial oracle forms builder
Tutorial oracle forms builderTutorial oracle forms builder
Tutorial oracle forms builderValdinho Pereira
 
Conexão remota e segurança de rede
Conexão remota e segurança de redeConexão remota e segurança de rede
Conexão remota e segurança de redeSoftD Abreu
 
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocialConstruindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocialCleber Rech
 
Falhas em Cascata na Rede Brasileira de Alta Tensão
Falhas em Cascata na Rede Brasileira de Alta TensãoFalhas em Cascata na Rede Brasileira de Alta Tensão
Falhas em Cascata na Rede Brasileira de Alta TensãoWilliam Paiva
 
Proposta de Melhoria do portal do Senac/AL, Utilizando Técnicas de Usabilidad...
Proposta de Melhoria do portal do Senac/AL, Utilizando Técnicas de Usabilidad...Proposta de Melhoria do portal do Senac/AL, Utilizando Técnicas de Usabilidad...
Proposta de Melhoria do portal do Senac/AL, Utilizando Técnicas de Usabilidad...Flávio Oscar Hahn
 
Implementacao e desempenho da virtualizacao no dcomp ufs
Implementacao e desempenho da virtualizacao no dcomp ufsImplementacao e desempenho da virtualizacao no dcomp ufs
Implementacao e desempenho da virtualizacao no dcomp ufsEdward David Moreno
 
Identificando e corrigindo problemas de performance em banco de dados (2)
Identificando e corrigindo problemas de performance em banco de dados (2)Identificando e corrigindo problemas de performance em banco de dados (2)
Identificando e corrigindo problemas de performance em banco de dados (2)Vinicius Pires
 
O Processo De Bolonha Na Web Semântica
O Processo De Bolonha Na Web SemânticaO Processo De Bolonha Na Web Semântica
O Processo De Bolonha Na Web SemânticaEduardo Covelinhas
 

Semelhante a Web Semântica: Desenvolvimento de Ontologia para Classificação de Cabos (20)

Modelagem de Base de Conhecimentos Baseada em Ontologia Estudo de Caso em Rec...
Modelagem de Base de Conhecimentos Baseada em Ontologia Estudo de Caso em Rec...Modelagem de Base de Conhecimentos Baseada em Ontologia Estudo de Caso em Rec...
Modelagem de Base de Conhecimentos Baseada em Ontologia Estudo de Caso em Rec...
 
Ct java vi_2010_16
Ct java vi_2010_16Ct java vi_2010_16
Ct java vi_2010_16
 
REST – Desmistificando A Implementação De Web Services REST Em Java Monografia
REST – Desmistificando A Implementação De Web Services REST Em Java MonografiaREST – Desmistificando A Implementação De Web Services REST Em Java Monografia
REST – Desmistificando A Implementação De Web Services REST Em Java Monografia
 
Monografia restful -_2013_-_desenvolvimento_v17-final-2014[1]
Monografia restful -_2013_-_desenvolvimento_v17-final-2014[1]Monografia restful -_2013_-_desenvolvimento_v17-final-2014[1]
Monografia restful -_2013_-_desenvolvimento_v17-final-2014[1]
 
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS JoomlaProcesso de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla
 
Classificação de padrões usando redes neurais
Classificação de padrões usando redes neuraisClassificação de padrões usando redes neurais
Classificação de padrões usando redes neurais
 
Tutorialoracleformsbuilder 140813182046-phpapp01
Tutorialoracleformsbuilder 140813182046-phpapp01Tutorialoracleformsbuilder 140813182046-phpapp01
Tutorialoracleformsbuilder 140813182046-phpapp01
 
Tutorial oracle forms builder
Tutorial oracle forms builderTutorial oracle forms builder
Tutorial oracle forms builder
 
Monografia ifes-everton-bada
Monografia ifes-everton-badaMonografia ifes-everton-bada
Monografia ifes-everton-bada
 
Conexão remota e segurança de rede
Conexão remota e segurança de redeConexão remota e segurança de rede
Conexão remota e segurança de rede
 
Vpn alan-rafael
Vpn alan-rafaelVpn alan-rafael
Vpn alan-rafael
 
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocialConstruindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
 
Falhas em Cascata na Rede Brasileira de Alta Tensão
Falhas em Cascata na Rede Brasileira de Alta TensãoFalhas em Cascata na Rede Brasileira de Alta Tensão
Falhas em Cascata na Rede Brasileira de Alta Tensão
 
Proposta de Melhoria do portal do Senac/AL, Utilizando Técnicas de Usabilidad...
Proposta de Melhoria do portal do Senac/AL, Utilizando Técnicas de Usabilidad...Proposta de Melhoria do portal do Senac/AL, Utilizando Técnicas de Usabilidad...
Proposta de Melhoria do portal do Senac/AL, Utilizando Técnicas de Usabilidad...
 
Monografia IPv6
Monografia IPv6Monografia IPv6
Monografia IPv6
 
Implementacao e desempenho da virtualizacao no dcomp ufs
Implementacao e desempenho da virtualizacao no dcomp ufsImplementacao e desempenho da virtualizacao no dcomp ufs
Implementacao e desempenho da virtualizacao no dcomp ufs
 
Identificando e corrigindo problemas de performance em banco de dados (2)
Identificando e corrigindo problemas de performance em banco de dados (2)Identificando e corrigindo problemas de performance em banco de dados (2)
Identificando e corrigindo problemas de performance em banco de dados (2)
 
Servidor de Help Desk Ocomon
Servidor de Help Desk OcomonServidor de Help Desk Ocomon
Servidor de Help Desk Ocomon
 
O Processo De Bolonha Na Web Semântica
O Processo De Bolonha Na Web SemânticaO Processo De Bolonha Na Web Semântica
O Processo De Bolonha Na Web Semântica
 
Potigolcode
PotigolcodePotigolcode
Potigolcode
 

Web Semântica: Desenvolvimento de Ontologia para Classificação de Cabos

  • 1. ALISON ROBERTO DE OLIVEIRA CARVALHO CAIO FUNES NASCIMENTO WEB SEMÂNTICA E ONTOLOGIAS: UM ESTUDO DE CASO 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 FRANCA 2009
  • 2. Catalogação na fonte – Biblioteca Central da Universidade de Franca
  • 3. 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
  • 4. 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, ____ / ____ / ______
  • 5. 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.
  • 6. 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.
  • 7. 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.
  • 8. 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.
  • 9. 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
  • 10. 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
  • 11. 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 101.. 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
  • 12. 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
  • 13. 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
  • 14. 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.
  • 15. 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
  • 16. 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.
  • 17. 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.
  • 18. 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
  • 19. 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:
  • 20. 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
  • 21. 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.
  • 22. 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;
  • 23. • 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? É
  • 24. 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:
  • 25. 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);
  • 26. • 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
  • 27. 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
  • 28. 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 à
  • 29. 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
  • 30. 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.
  • 31. 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.
  • 32. 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.
  • 33. 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
  • 34. 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
  • 35. 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.
  • 36. 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:
  • 37. 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:
  • 38. 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.
  • 39. 3 DESENVOLVIMENTO DA ONTOLOGIA COM A METODOLOGIA 101 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
  • 40. 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?
  • 41. 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 Cabo de fibra óptica de 125 µm, multimodo, Fibra Óptica Não Metálica para transmissão de dados em alta velocidade, Não Blindada 1 imune a interferências eletromagnéticas. Par Trançado Metálico Cabo par trançado de 24 AWG para aplicações Blindado 1 externas, graças à malha de blindagem,
  • 42. deixando-o imune às interferências eletromagnéticas. Cabo par trançado de 24 AWG para aplicações Par Trançado Metálico Não internas, suscetível à interferências Blindado 1 eletromagnéticas. Cabo coaxial de 810 µm, geralmente utilizado Coaxial Metálico Blindado 1 em transmissões de vídeo e som. Cabo coaxial de 810 µm, para transmissões de Coaxial Metálico Não alta freqüência e curtas distâncias, devido sua Blindado 1 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:
  • 43. 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.
  • 44. • 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).
  • 45. 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.
  • 46. 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;
  • 47. - 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.
  • 48. 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.
  • 49. 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.
  • 50. 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
  • 51. • 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
  • 52. 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:
  • 53. 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:
  • 54. 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:
  • 55. 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
  • 56. 2 – Quais são as instâncias de Cabos Metálicos e Cabos 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
  • 57. 3 – Quais são as instâncias de Cabos 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 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
  • 58. 4 – Quais são as instâncias de Cabos Metálicos e Cabos 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
  • 59. 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
  • 60. 6 – Quais são as instâncias de Cabos Metálicos ou Cabos 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
  • 61. 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
  • 62. 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
  • 63. 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,
  • 64. 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.
  • 65. Essas duas API’s foram utilizadas para a implementação das sete perguntas de competência da ontologia CERCOnt.
  • 66. 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.
  • 67. 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 Ontology Specifications. Disponível em: <http://www- ksl.stanford.edu/KSL_Abstracts/KSL-92-71.html>. Acesso 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
  • 68. (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.
  • 69. 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 Digitais. 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.
  • 70. WHAT is an Ontology? Disponível em: <http://www-ksl.stanford.edu/kst/what-is-an- ontology.html>. Acesso em: 17 mar 2009.