Desenvolvimento de um Sistema Utilizando a Tecnologia JSP para

Transcrição

EDEILSON MILHOMEM DA SILVA
DESENVOLVIMENTO DE UM SISTEMA UTILIZANDO A
TECNOLOGIA JSP PARA A MANIPULAÇÃO E RECUPERAÇÃO
DE FOTOS DOCUMENTADAS EM RDF
Palmas
2004
ii
DESENVOLVIMENTO DE UM SISTEMA UTILIZANDO A
TECNOLOGIA JSP PARA A MANIPULAÇÃO E RECUPERAÇÃO
DE FOTOS DOCUMENTADAS EM RDF
“Relatório
apresentado
como
requisito parcial da disciplina de
Prática de Sistemas de Informação I
(Estágio) do curso de Sistemas de
Informação, orientado pela Profª.
Parcilene Fernandes de Brito”
Palmas
2004
iii
Desenvolvimento de um sistema utilizando a tecnologia JSP para
a manipulação e recuperação de fotos documentadas em RDF
“Relatório
apresentado
como
requisito parcial da disciplina de
Prática de Sistemas de Informação I
(Estágio) do curso de Sistemas de
Informação, orientado pelo Profª.
Parcilene Fernandes de Brito”
BANCA EXAMINADORA
_____________________________________________
Profª. Parcilene Fernandes de Brito
Centro Universitário Luterano de Palmas
_____________________________________________
Prof. Fabiano Fagundes
_____________________________________________
Prof. Jackson Gomes de Souza
Palmas
2004
iv
“Ensina-me,
Senhor
o
teu
caminho, e andarei na tua verdade, une o
meu coração ao temor do teu nome.”
(Salmos 86:16)
“Os problemas significativos com
os quais nos deparamos não podem ser
resolvidos no mesmo nível de pensamento
em que estávamos quando eles foram
criados.”
(Albert Einsten)
v
AGRADECIMENTOS
No total de 8(oito) degraus, graças a meu bom e amado Pai (Deus), cheguei ao fim
do sétimo. Obrigado Deus, por ter me dado forças durante esse percurso, por ter colocado
as pessoas certas em minha vida para que pudessem me dar o apoio moral e psicológico
que precisava para continuar a acreditar em mim mesmo.
Agradeço a você, mamãe querida, por, em muitos momentos, ter me compreendido
(pra não dizer suportado) e me dado o apoio necessário para continuar a luta, por me fazer
acreditar que eu sempre posso e poderei bem mais do que minha mente possa imaginar.
Enfim, por depositar confiança em mim. Ah..., Dna. Maria, obrigado por ter me fornecido
a base necessária pra eu estar aqui hoje, agradecendo-a. Amo muito a senhora, mesmo que
às vezes não demonstre isso expressivamente.
Agradeço a vocês maninhas, Katá e Nicky. A Katá por sempre ter demonstrado tão
intensamente o seu imenso amor por mim, por sempre ter feito esforço em me
compreender, onde em muitos momentos nem eu mesmo conseguia. Lembra como a gente
ia de mãos dadas pra escola?! Isso foi o princípio de tudo, mas você não imagina o quanto
esses anos juntos, na escola, me deram o sustento necessário para prosseguir em frente,
sozinho. Nicky, mesmo que às vezes transpareça que eu tenha maior afinidade, carinho,
atenção e amor pela Katá, isso é uma inverdade e você sabe disso. Te amo tanto quanto a
Katá, e você sempre será uma pessoa muito importante pra mim. Conte comigo sempre que
precisar, pois estarei lá para te estender a mão.
Agradeço a você, meu melhor cunhado, segundo você: “o cara agregado à família”.
Obrigado negão, por ser uma pessoa amiga, companheira e ter sempre as palavras certas no
momento oportuno. Como já dizia você...: “cada um sabe a dor e delícia de ser o que é”,
então negão, seja feliz. Ah! Quando tiver rico, não esquece do cunhadão aqui, hein!
Agradeço a você Parcilene, orientadora, psicóloga e amiga querida, que um dia me
fez enxergar que não valia a pena desistir da guerra. Ainda que eu acreditasse nisso não
encontrava forças para continuar. Continuei, e hoje estou aqui, preste a vencer a primeira
batalha, prestando-te meus sinceros agradecimentos.
A você Fabigundes (Fabiano) que sempre tentou trazer ânimo, incentivo e que
também sempre deu as velhas e boas “porradas” na tentativa de fazer com que nós, alunos,
nos tornássemos pessoas melhores. Ainda que essas “porradas”, na grande maioria das
vezes, causassem algum transtorno, você nunca exitou em dá-las e pode ter certeza que eu
vi
tirei muito proveito disso tudo e confesso também que, em alguns momentos, fiquei
chateado e magoado, mas acredito que isso “faz parte”.
Agradeço também ao grupo batizado como “Amaleros”, formado por: André
(Rincon ou Dedé), Carlos(Kaká ou Careli), Fernando (Óculos) Leandro (Mamá ou
Macieira), Lucas (Skywalker ou Luquinha), Jorge (Ginho), Fabiano (Fabigundes) e Victor
(Narizinho - o ladrão de oxigênio mesmo sem perceberem, me forneceram subsídios para
continuar em frente.
Enfim, mesmo que indiretamente, são muitas as pessoas que, de alguma forma,
contribuíram para a conclusão do referido trabalho, por isso, minha sincera gratidão a
todos.
vii
SUMÁRIO
LISTA DE FIGURAS............................................................................................. ix
LISTA DE TABELAS.............................................................................................xii
LISTA DE ABREVIATURAS ...............................................................................xiii
RESUMO ................................................................................................................ 12
ABSTRACT............................................................................................................. 13
1
Introdução....................................................................................................... 14
2
Revisão de Literatura...................................................................................... 17
2.1
2.1.1
2.2
Funcionamento de um Servlet........................................................... 18
Java Server Pages ................................................................................... 20
2.2.1
Objetos Pré-definidos para a Criação de Páginas JSP......................... 22
2.2.2
Expressões e Declarações.................................................................... 24
2.2.3
Diretivas .............................................................................................. 26
2.3
2.3.1
2.4
3
Servlet...................................................................................................... 17
XML........................................................................................................ 28
Namespaces ......................................................................................... 30
Resource Description Framework ....................................................... 31
2.4.1
Modelo Básico RDF ............................................................................ 32
2.4.2
Primitivas do modelo........................................................................... 38
2.4.3
RDF Schema........................................................................................ 47
2.5
API Jena ................................................................................................. 58
2.6
Considerações ........................................................................................ 62
Materiais e Métodos........................................................................................ 63
3.1
Local e Período ...................................................................................... 63
3.2
Materiais................................................................................................. 63
3.2.1
Hardware ............................................................................................. 64
3.2.2
Software............................................................................................... 64
viii
3.2.3
3.3
4
Fontes Bibliográficas........................................................................... 64
Metodologia............................................................................................ 64
Resultados e Discussão................................................................................... 67
4.1
O Sistema................................................................................................ 67
4.2
RDF Schema na Criação de um Conjunto de Regras para Descrição
das Imagens 69
4.3
Representação do Vocabulário em uma Classe Java ......................... 71
4.4
Utilizando o Vocabulário representado em uma Classe Java para
Criação de um Documento RDF. ................................................................................. 73
4.5
Processo de Armazenamento das Descrições das Imagens................ 75
4.6
Classe Criada para Implementação do Sistema ................................. 77
4.6.1
Método verificarArquivoExiste(String) .............................................. 78
4.6.2
Método gravarArquivo(String, Model) ............................................... 79
4.6.3
Método gravarArquivo (String, RDFWriter, Model) .......................... 79
4.6.4
Método carregarArquivo(String)......................................................... 80
4.6.5
Método pegarNovoArquivo (String) ................................................... 80
4.6.6
Método pegarConjuntoArquivos(String)............................................. 81
4.7
Utilizando o Sistema para Descrição de uma Imagem....................... 81
4.8
Considerações ........................................................................................ 85
5
Considerações finais....................................................................................... 86
6
Referência Bibliográfica ................................................................................ 88
ANEXO.................................................................................................................... 90
APÊNDICE............................................................................................................. 96
ix
LISTA DE FIGURAS
Figura 1 - Arquitetura proposta para a Web Semântica (Berners-Lee, 2001)................... 14
Figura 2: A arquitetura de aplicativo servlet (KUMIAWAN, 2002) .................................. 17
Figura 3: Como funciona um Servlet.................................................................................. 18
Figura 4: Exemplo de um código Servlet............................................................................ 19
Figura 5: Etapas da primeira execução de uma página JSP (OLIVEIRA, 2001) .............. 21
Figura 6: Exemplo simples de uma página JSP ................................................................. 21
Figura 7: Código HTML retornado para o cliente e a Servlet gerada a partir da
requisição do documento JSP demonstrado na Figura 6 ................................................... 22
Figura 8: Comparação entre a utilização de uma expressão e o método println() da classe
JspWriter ............................................................................................................................. 25
Figura 9: Exemplo de declaração de uma variável inteira tanto no escopo de um scriptlet,
quanto como atributo da classe Servlet............................................................................... 26
Figura 10: Sintaxe de definição de diretivas (HALL,?)...................................................... 27
Figura 11: Sintaxe para utilização da diretiva include................................................. 28
Figura 12: Exemplo de um DTD três elementos e um atributo. ......................................... 29
Figura 13: Exemplo de um arquivo XML válido e bem formado de acordo com o DTD da
Figura 12. ............................................................................................................................ 29
Figura 14: Exemplo de declaração de um namespace ....................................................... 30
Figura 15: Esquema de utilização de um namespace em um documento XML. ................ 31
Figura 16: Documento XML que utiliza os elementos pré-definidos em um namespace... 31
Figura 17: Representação de uma sentença: grafo e tripla ............................................... 34
Figura 19: Propriedade com valor estruturado usando um nó vazio ................................ 35
Figura 20: Propriedade com valor estruturado ................................................................. 35
Figura 21: Formato de representação de dados em RDF.................................................. 36
Figura 22: Sentença em forma de tripla ............................................................................. 36
Figura 24: Serialização em XML de um recurso RDF de forma abreviada ...................... 37
Figura 25: Representação de uma sentença sem o elemento <rdf:RDF>....................... 38
Figura 26: Representação do elemento <rdf:Description> .................................... 39
Figura 28: Representação do atributo <rdf:ID> ........................................................... 40
Figura 29: Grafo da definição de um tipo .......................................................................... 41
Figura 30: Representação do atributo <rdf:type>....................................................... 41
x
Figura 31: Representação do atributo <rdf:type> como atributo do elemento
<rdf:Description> .................................................................................................... 41
Figura 32: Representação do atributo <rdf:type> com o mecanismo de namespace 42
Figura 33: Representação do elemento bag ....................................................................... 43
Figura 34: Representação do elemento Sequence.............................................................. 43
Figura 35: Representação do elemento Alternative ........................................................... 44
Ordenação .............................................................................................................................. 44
Figura 36: Representação de um código RDF reificado.................................................... 45
Figura 37: Representação gráfica de uma esquema e sua utilização em um documento
RDF ..................................................................................................................................... 47
Figura 38: Hierarquia de classes do modelo RDF Schema (BRICKLEY, 2000). .............. 48
Figura 39: Modelo RDF/XML utilizado para definição de classes e propriedades........... 48
Figura 40: Processo de definição de classes ...................................................................... 49
Figura 41: Representação gráfica de um esquema............................................................. 50
Figura 42: Parte do esquema da Figura 41 serializado em XML....................................... 50
Figura 43: Sintaxes da criação de uma classe.................................................................... 51
Figura 44: Sintaxes de definição de uma propriedade e seu relacionamento com uma
classe ................................................................................................................................... 52
Figura 45: Definição de Propriedade................................................................................. 53
Figura 46: Exemplo do elemento <rdfs:subClassOf> .............................................. 54
Figura 47: Hierarquia de propriedades a partir da utilização do elemento
<rdfs:subPropertyOf> ............................................................................................. 55
Figura 48: Representação do elemento <rdfs:range>................................................. 56
Figura 49: Representação do elemento <rdfs:domain> .............................................. 56
Figura 49: Representação de uma taxionomia em RDF/XML............................................ 57
Figura 50: Exemplo de criação de um documento RDF simples ....................................... 59
Figura 52: Exemplo de definição de tipagem para um dado recurso ............................... 60
Figura 53: Resultado obtido a partir da execução do código demonstrado na Figura 52.60
Figura 54: Criação um recurso com uma propriedade tendo como valor um outro recurso
............................................................................................................................................. 61
Figura 55: Resultado obtido a partir da execução do código demonstrado na Figura 54.61
Figura 56: Etapas possíveis para descrição das imagens.................................................. 68
Figura 57: Esquema que representa as imagens referentes ao domínio “Instituição de
xi
Ensino Superior”................................................................................................................. 69
Figura 58: Grafo do esquema da Figura 57....................................................................... 71
Figura 59: Criação de um vocabulário em uma classe Java: utilizando a API Jena. ....... 72
Figura 60: Código Java de criação de um documento RDF a partir do esquema
representado na seção 4.3................................................................................................... 74
Figura 61: Documento RDF gerado a partir da execução do código Java demonstrado na
Figura 60. ............................................................................................................................ 75
Figura 62: Estrutura hierárquica de armazenamento dos documentos RDF. ................... 76
Figura 63: Documento que armazena o nome dos arquivos RDF que descrevem as
imagens: de acordo com a posição ocupada pelos mesmos no esquema. .......................... 77
Figura 64: Código Java que implementa o método verificarArquivoExiste
(String) .......................................................................................................................... 79
Figura 65: Código Java que implementa o método gravarArquivo (String,
Model)............................................................................................................................... 79
RDFWriter, Model) .................................................................................................... 80
Figura 67: Código Java que implementa o método carregarArquivo(String).... 80
Figura 68: Código Java que implementa o método pegarNovoArquivo (String)81
Figura 69: Código Java que implementa o método pegarConjuntoArquivos
(String) .......................................................................................................................... 81
Figura 70: Tela Principal do Sistema................................................................................. 82
Figura 71: Formulário que possibilita a submissão das informações sobre uma dada
imagem. ............................................................................................................................... 83
Figura 72: Documento RDF gerado................................................................................... 84
xii
LISTA DE TABELAS
Tabela 1: Objetos implícitos de uma página JSP (BROGDEN, 2002)
23
Tabela 2: Atributos da diretiva page.
27
Tabela 3: Sentença dividida em partes
33
Tabela 4: Comparação entre os tipos de Coleções providas pelo modelo RDF
(BRAGANHOLO, 2001).
44
Tabela 5: Resultado da sentença utilizando uma reificação
45
Tabela 6: Cronograma de atividades
66
Tabela 7: Relação dos métodos da classe Arquivo.
78
Tabela 8: Métodos da classe HttpServletRequest (BROGDEN, 2002)
91
Tabela 9: Métodos da classe HttpServletResponse (BROGDEN, 2002)
92
Tabela 10: Métodos da classe JspWriter (BROGDEN, 2002)
93
Tabela 11: Métodos da classe HttpSession (BROGDEN, 2002)
93
Tabela 12: Métodos da classe ServletContext (BROGDEN, 2002)
94
Tabela 13: Métodos da classe PageContext
95
xiii
LISTA DE ABREVIATURAS
API = Application Programmer Interface
DTD = Document Type Definition
HP = Hewlett-Packard Compan
HTML = HyperText Markup Language
HTTP = HyperText Transfer Protocol
JSP = Java Server Pages
RDF = Resource Description Framework
RDQL = Query language for RDF
URI = Uniform Resoucer Identifier
W3C = World Wide Web Consortium
XML = eXtensible Markup Language
12
RESUMO
As páginas dispostas na web não obedecem a uma estrutura padrão, ou seja, são
geradas de acordo com a estrutura definida pelos desenvolvedores (webmasters). Devido a
essa heterogeneidade (falta de padronização) as pesquisas realizadas pelos sites
tradicionais de busca são possíveis apenas por palavra-chave. Esse é um dos motivos pelos
quais, quando um usuário faz uma busca em um desses sites, muitas páginas irrelevantes
para pesquisa são retornadas, tendo o mesmo que fazer uma filtragem manual dessas
informações. Um dos passos para tornar essas pesquisas eficientes é a estruturação das
páginas segundo um padrão. Dessa forma, foi proposto pela W3C o modelo RDF, que
dentre os recursos oferecidos, dispõe de mecanismo que possibilita a estruturação das
páginas de forma homogênea. Tendo como base esse modelo, o presente trabalho discorre
sobre o desenvolvimento de um sistema que possibilita a estruturação de informações
referentes ao domínio “imagens da instituição de ensino superior CEULP/ULBRA”. Para o
desenvolvimento desse trabalho foi utilizada a tecnologia JSP (tecnologia que permite o
desenvolvimento de páginas web a partir da linguagem Java), isso porque a linguagem Java
dispõe de uma API (Jena) que possibilita a interação com documentos RDF.
Palavras-chaves: RDF, RDF Schema, API Jena e JSP.
13
ABSTRACT
The web pages do not obey to a standard structure, or either, they are generated in
accordance with the structure defined by the developers (webmasters). Because this
heterogeneity (standardization lack) the searches made by traditional search engines are
possible only through keywords. This is one of the reasons for which when an user makes
a search in one of these sites many pages irrelevant for the search are returned, of this
form the user has that manual filtering the information. One of the steps to become these
searchs efficient is the definition of the pages according to a standard. Of this form, model
RDF was considered by the W3C, that amongst the resources offered for exactly, makes
use of mechanism that makes possible the organization of the pages of homogeneous form.
Following this model, the present work discourses about the development of a system that
makes possible to structuralize the information according the domain "images of the
superior education institute CEULP/ULBRA". For development of this work the
technology JSP was used (technology that allows the development of web pages from the
Java language), this because the Java language makes use of an API (Jena) that makes
possible the interaction with RDF documents.
Keywords: RDF, RDF Schema, API Jena e JSP
14
1 INTRODUÇÃO
A web semântica representa a evolução da web atual. Ela visa fornecer estruturas e
dar significados ao conteúdo das páginas web, criando um ambiente onde agente de
software e usuários possam trabalhar de forma cooperativa (BERNERS-LEE, 2001). Desta
forma, vários trabalhos estão sendo desenvolvidos com o intuito de se criar um ambiente
propício para a existência de uma web com significado. Na arquitetura proposta para a web
semântica de Berners-Lee (2001) (Figura 1) é possível visualizar uma sistematização das
etapas de construção desse ambiente.
Figura 1 - Arquitetura proposta para a Web Semântica (Berners-Lee, 2001)
De acordo com a arquitetura proposta por (Berners-Lee, 2001) (Figura 1), a camada
15
de estrutura representa o primeiro passo para a definição da web semântica, pois nesse
momento em que as informações são sistematizadas, ou seja, é dado significado os dados.
A camada de esquema, a ontologia, fornece um conjunto de regras que define
hierarquia, relacionamentos e restrições entre termos, ou seja, permite a representação de
um conjunto de regras mediante a especificação de um dado domínio e, para isso são
utilizadas linguagens para ontologia. (LUSTOSA, 2003).
“E, por fim, a camada lógica tem a função de definir um conjunto de regras de
inferências, além dos próprios mecanismos que as realizarão, atribuindo-as aos
documentos que contém dados. As regras de inferência oferecem aos agentes
computacionais o poder de raciocinar sobre as estruturas de dados que estão expressas na
camada de estrutura, a partir das relações entre esses dados definidas na camada de
esquema” (LUSTOSA, 2003).
O presente trabalho está vinculado à camada de estrutura da web semântica, desta
forma, é construído um ambiente que utilize tecnologias capazes de propiciar uma
sistematização das informações, de forma que elas venham a ter um significado para a
máquina.
No referido trabalho será utilizado o padrão RDF, recomendado pela W3C. De uma
forma simples, o RDF pode ser entendido como um padrão que tem como funcionalidade
prover metadados na web através da aplicação da linguagem XML. Sua padronização
estabelece um modelo de dados e sintaxe para codificar, representar e transmitir metadados
(CIUFFO, 2002).
Para o desenvolvimento do ambiente, escolheu-se o domínio “imagens da
instituição de ensino superior CEULP/ULBRA”. Dessa forma, foi desenvolvido um
sistema web que permite o armazenamento de imagens e a descrição da mesma a partir do
modelo RDF.
Para o desenvolvimento do ambiente foi utilizada a tecnologia JSP, pois a mesma
além de ser uma tecnologia voltada para a web, também trabalha com a linguagem Java.
Isso é um fator positivo, levando-se em consideração que há uma API (Application
Programing Interface) Java, desenvolvida pela HP, que dispõe de várias classes que
permitem a interação com um documento RDF.
Este trabalho está organizado da seguinte forma: na seção 2.1 são apresentados os
conceitos teóricos que fundamentam a tecnologia Servlet, já que a mesma é a base de
funcionamento da tecnologia JSP, apresentada na seção 2.2. Na seção 2.3 é feita uma breve
16
explanação da linguagem de marcação XML, pois a mesma além de serializar o modelo
RDF, também dispõe de um recurso (seção 2.3.1) que possibilita o compartilhamento de
vocabulários: namespace. A seção 2.4 apresenta o modelo RDF, logo em seguida é
demonstrado na seção 2.4.1 o modelo RDF básico, caracterizado como um padrão para
descrição de recursos (universo de objetos que podem ser descritos) com propriedades
(atributos dos recursos). E, na seção 2.4.3 é feita uma explanação a respeito do RDF
Schema, utilizado para representação de esquemas, ou seja, fornece descrição de grupos de
recursos e os relacionamentos existentes entre eles. A seção 2.5 apresenta alguns dos
recursos disponibilizados pela API Jena para criação e manipulação de documentos RDF.
A seção 2.6 apresenta breves considerações a respeito dos conceitos que fundamentam
teoricamente o trabalho.
Os materiais e a metodologia utilizados para o desenvolvimento do presente
trabalho são apresentados na seção 3. E, logo a seguir (seção 4) são demonstrados os
resultados obtidos a partir do desenvolvimento do sistema e quais foram os passos
seguidos para o seu desenvolvimento. E, para finalizar, são apresentadas as considerações
finais, seguido das referências utilizadas para o desenvolvimento do trabalho.
17
2 REVISÃO DE LITERATURA
2.1 Servlet
Servlet é uma tecnologia para internet baseada na plataforma Java que possibilita a
criação de página web de forma dinâmica (JCP - SERVLET SPECIFICATION, 2003). Ou
seja, as páginas web podem ser geradas dinamicamente diante da ação de um determinado
usuário.
Essa interação com o usuário é baseada na arquitetura cliente-servidor em que o
cliente faz uma requisição via HTTP ou HTTPS (protocolo de comunicação web), o
servidor processa a solicitação e por fim envia a resposta ao solicitante. A Figura 2
demonstra a arquitetura de um aplicativo Servlet.
Figura 2: A arquitetura de aplicativo servlet (KUMIAWAN, 2002)
Ainda segundo a representação da Figura 2 um aplicativo Servlet também pode
incluir conteúdos estáticos, tais como: uma página HTML ou um arquivo imagem.
18
2.1.1 Funcionamento de um Servlet
Quando o servidor recebe uma solicitação de um cliente para processar uma página
pela primeira vez, o mesmo efetua o carregamento do Servlet, carrega-o na memória e por
fim envia a resposta ao cliente. Depois que o Servlet foi carregado permanecerá na
memória aguardando outras solicitação. A Figura 3 demonstra como é o funcionamento de
um Servlet.
Figura 3: Como funciona um Servlet
Caso a página não mais esteja sendo requerida pela primeira vez, o servidor verifica
se o Servlet sofreu alguma alteração. Caso tenha sido alterado, o servidor carrega o Servlet
novamente na memória e envia a resposta ao cliente.
19
Esse processo de envio do Servlet para a memória tem o intuito de agilizar o
processamento para uma suposta nova solicitação feita por um cliente de uma página web.
Figura 4: Exemplo de um código Servlet.
Conforme pode ser observado na Figura 4, não é uma tarefa muito simples e rápida
desenvolver uma página web utilizando a tecnologia Servlet, pois o código HTML das
páginas devem ser criados a partir da sintaxe Java, utilizando strings para definição dos
elementos HTML. Isso dificulta bastante o trabalho do desenvolvedor porque além de se
preocupar em como as informações estarão expostas na parte gráfica da página, tem que se
preocupar também com a parte lógica (implementação das classes propriamente dita).
20
2.2
Java Server Pages
Como forma de sanar o problema da tecnologia Servlet no que diz respeito a
dificuldade de edição de páginas web surgiu a tecnologia JSP, que não veio para substituíla, mas sim estender a sua potencialidade. Dessa forma, JSP oferece uma maior facilidade
de codificação, além de permitir também uma programação separada em camadas: camada
lógica (parte dinâmica) e camada de apresentação (parte estática), e através disso facilitar
tanto a elaboração quanto a manutenção de uma aplicação.
Segundo (JCP, 2003), JSP é uma tecnologia para desenvolvimento de aplicações
web que utiliza a linguagem Java. Uma página JSP é um documento que descreve como
criar uma resposta para uma solicitação em um determinado protocolo. O protocolo
utilizado como padrão para essas solicitações e respostas é o HTTP. Como se trata de uma
tecnologia baseada em Java, ela herda todas suas características como: linguagem baseada
nos conceitos da orientação a objetos, multiplataforma, além do gerenciamento automático
de memória.
Quando uma página JSP é carregada pela primeira vez o código Java é compilado
gerando uma Servlet que é executado. Após o carregamento dessa Servlet, uma página
HTML é enviada para o browser (navegador) do cliente. As próximas requisições são
enviadas diretamente a Servlet que foi gerada na primeira vez em que a página foi
carregada, não ocorrendo mais as etapas de geração e compilação. A Figura 5 mostra o
esquema de execução de uma página JSP na primeira vez em que é requisitada.
21
Figura 5: Etapas da primeira execução de uma página JSP (OLIVEIRA, 2001)
Conforme representação da Figura 5, quando uma página web é solicitada é enviada
uma requisição ao servidor web, sendo que o mesmo a encaminha para o contentor
Servlet/JSP, e com isso (passo 3) o contentor verificará que não há uma instância de
Servlet correspondente à página JSP. Dessa forma, a página JSP é traduzida para o código
fonte de uma classe Servlet que será usada na resposta à requisição. No passo (4) o código
fonte do Servlet é compilado, no passo (5) é criada uma instância da classe, e por fim,
(passo 6), é gerada a resposta à requisição feita pelo cliente. A Figura 6 mostra um
exemplo simples de uma página JSP.
Figura 6: Exemplo simples de uma página JSP
22
Conforme representação da Figura 6, uma página JSP pode ser formada tanto por
conteúdo estático (HTML), quanto por código dinâmico (processado do lado do servidor),
sendo que o código processado pelo servidor é delimitado respectivamente pelas tags de
abertura e fechamento “<%” e “%>”. Quando uma página JSP é requisitada, processada e
carregada é retornado ao cliente apenas o código HTML, escondendo assim o código fonte
que a originou. A parte 1 da Figura 7, tendo como base o documento JSP apresentado na
Figura 6, exibe o código HTML retornado para o cliente e, a parte 2 demonstra o Servlet
gerado após o carregamento da página JSP..
Figura 7: Código HTML retornado para o cliente e a Servlet gerada a partir da requisição
do documento JSP demonstrado na Figura 6
2.2.1 Objetos Pré-definidos para a Criação de Páginas JSP
Uma característica importante da tecnologia JSP é que a mesma disponibiliza
objetos implícitos (o desenvolvedor não precisa instanciá-los), que são sempre criados
quando uma página JSP é carregada, formando assim o Servlet equivalente. A Tabela 1
23
demonstra quais são esses objetos.
Tabela 1: Objetos implícitos de uma página JSP (BROGDEN, 2002)
Objeto
Tipo
request
javax.servlet.ServletRequest
response
javax.servlet.ServletResponse
pagecontext
javax.servlet.jsp.PageContext
session
javax.servlet.http.HttpSession
application
javax.servlet.ServletContext
out
javax.servlet.jsp.JspWriater
config
javax.servlet.ServletConfig
Uma referência de objeto apontando para
page
“this”
exception
Exceções (throwable)
Conforme pode ser observado na Tabela 1, são nove os objetos pré-definidos que
podem ser utilizados durante o desenvolvimento de uma aplicação JSP. Dentre as quais 6
destacam-se:
HttpServletRequest,
HttpServletResponse,
JspWriter,
HttpSession,
ServletContext e PageContext, pois são utilizadas com maior freqüência. A seguir é feita
uma explanação a respeito das classes às quais esses objetos pertencem e em anexo segue
alguns de seus métodos e suas respectivas descrições.
•
Classe HttpServletRequest: o objeto request tem a responsabilidade de
representar todas as solicitações feitas pelos usuários, como por exemplo:
fornecer meio de acesso a cookies, acesso a parâmetros advindos de uma
página e, até mesmo a URL que fez a solicitação.
•
Classe
HttpServletResponse:
HttpServletResponse
é
segundo
uma
(BROGDEN,
extensão
da
2002),
interface
ServletResponse, que acrescenta métodos específicos para as
transações HTTP. Essa classe fornece métodos que permitem representar as
24
respostas que serão dadas ao cliente mediante a requisição de uma página.
•
Classe JspWriter: a finalidade dessa classe é proporcionar funcionalidades
de fluxos de saídas para o conteúdo de uma página, ou seja, disponibiliza
métodos para enviar informações para o navegador (browser) do cliente.
•
Classe HttpSession: essa interface permite trabalhar com as variáveis
específicas pertencentes à sessão de cada usuário e é de fundamental
importância, pois informações pertencentes a uma dada sessão podem ser
utilizadas em páginas distintas, desde que a sessão seja a mesma.
•
Classe ServletContext: quando uma Servlet é gerada, uma instância da
interface ServletContext é criada. Esse objeto representa a aplicação a
qual a página JSP pertence. Segundo (BROGDEN, 2002), esse é o caminho
primário para a comunicação entre uma Servlet e o contentor Servlet. Cada
aplicativo web, que pode conter várias Servlets ou páginas JSP, compartilha
um ServletContext.
•
Classe PageContext: essa classe fornece métodos para gerenciar os
recursos oferecidos pelas Servlets (BROGDEN, 2002). Ou seja, é ela quem
define os objetos que podem ser utilizados de forma implícita dentro de uma
página JSP.
2.2.2 Expressões e Declarações
Além dos scriptlets (código Java inserido entre os elementos “<%” e “%>”), a
tecnologia JSP permite também que o código Java seja colocado numa página usando
expressões e declarações (HUNTER, 2002). Uma expressão é determinada pelos
elementos “<%=” e “%>”, em que o elemento “<%=” determina seu início e o elemento
“%>” determina o fim. Expressão é um meio alternativo e rápido de se enviar um valor
(dado de saída) para o navegador do cliente, pois o outro meio para postar dados de saída é
utilizar o método println() do objeto implícito out. Dessa forma, o uso de expressões o
25
torna trabalho do desenvolvedor menos dispendioso. A Figura 8 mostra um exemplo de
utilização de expressão em que uma mensagem é enviada para o cliente e sua
representação equivalente utilizando o método println().
Figura 8: Comparação entre a utilização de uma expressão e o método println() da classe
JspWriter
Segundo (HALL,?) uma declaração permite a definição tanto de métodos quanto de
variáveis que passam a fazer parte da classe Servlet, ou seja, não faz parte do método
_jspService (método invocado sempre que uma página JSP é requerida),
diferentemente das variáveis que são declaradas nos scriptlets. Uma declaração de um
objeto feita dentro do escopo de um scriptlets é local ao método _jspService, dessa
forma o objeto é instanciado sempre que uma página JSP for requerida, o que não acontece
se a variável for declarada como atributo da classe Servlet, e para isso a sintaxe utilizada é:
<%! declaração %>. A Figura 9, dividida em partes, demonstra uma declaração de uma
variável tanto local ao método _jspService quanto como atributo da classe Servlet.
26
Figura 9: Exemplo de declaração de uma variável inteira tanto no escopo de um scriptlet,
quanto como atributo da classe Servlet.
Como a declaração da variável inteira contAcesso demonstrada na parte 1 da
Figura 9 pertence somente ao scriptlet em questão, trata-se então de uma variável local ao
método _jspService, ou seja, essa variável será declarada, inicializada e incrementada
sempre que a página JSP for requerida. Dessa forma, a mesma terá sempre o valor 1.
Diferentemente da declaração demonstrada na parte 2, pois, como ela é declarada dentro
dos elementos “<%!” e “%>”, a variável passa a ser então atributo da classe Servlet e o
método jspService apenas modifica o valor da variável, incrementando-a.
2.2.3 Diretivas
De acordo com (HUNTER, 2002), uma diretiva JSP permite que uma página JSP
controle certos aspectos de seu Servlet, ou seja, permite ajustar instruções no nível da
página, como: inserir arquivos estáticos em um documento JSP e importar um determinado
pacote ou classe. Elas são definidas entre as tags “<%@” e “%>”. Na Figura 10 é
demonstrada a sintaxe para definição de uma ou várias diretivas.
27
Figura 10: Sintaxe de definição de diretivas (HALL,?).
Conforme representação na Figura 10, o processo de definição de uma diretiva
resume-se em: definir o nome da diretiva que será representada, juntamente com o atributo
disponibilizado pela mesma e seu respectivo valor. As principais diretivas são: page e
include.
A diretiva page permite que sejam definidos atributos que serão aplicados a todo o
documento JSP e inclusive a todos os arquivos incluídos estaticamente a essa página. A
seguir são demonstrados na Tabela 2 os atributos que podem ser utilizados por essa
diretiva
Tabela 2: Atributos da diretiva page.
Exemplo (admita que os
Atributo
atributos abaixo representados
Descrição
estão dentro dos elementos
“<%@ “ e “ %>” ).
Permite
import
especificar
importados
para
os
serem
pacotes
que
são
utilizados
no
page import=”java.util.*”
decorrer da página JSP
Permite definir como as informações serão
contentType
enviadas para o cliente, ou seja, se as
informações
estarão
dispostas
em
texto
page contentType=”text/plain”
plano ou texto HTML.
O valor padrão para essa propriedade é true
que
indica
o
processamento
normal
do
Servlet, em que múltiplas requisições são
isThreadSafe processadas simultaneamente. Se o valor for
false indica que o processamento deve ser
feito por instâncias separadas do Servlet
ou serialmente.
page IsThreadSafe=”false”
28
O valor padrão true indica que a variável
pré-definida session deve ser associada a
Session
sessão.Se
esse
atributo
tiver
com
valor
page session=false
falso é indicado que nenhuma sessão será
utilizada.
Especifica o tamanho do buffer para escrita
Buffer
utilizado pelo objeto da classe jspWriter.
page buffer=”15”
O tamanho padrão é inferior a 8k.
Esse atributo tem a função de indicar se o
autoflush
buffer
deve
ser
esvaziado
ou
não
quando
estiver cheio. Para isso o mesmo recebe um
page Autoflush=”true”
valor true ou false.
Especifica
errorPage
executada
qual
caso
página
uma
de
erro
exceção
deve
seja
ser
gerada
page errorPage=”url”
durante o processamento da página JSP.
Indica se a página corrente pode atuar como
isErrorPage
página de erro para uma outra página JSP.
page isErrorPage=”true”
Tem como valor padrão false.
Especifica a linguagem que será utilizada.
Language
Ainda
que
a
única
possível
por
enquanto
page language=”Java”
seja a Java.
A diretiva include permite a inclusão de arquivos estáticos em uma página JSP. A
sintaxe para utilização da mesma pode ser visualizada na Figura 11.
Figura 11: Sintaxe para utilização da diretiva include.
2.3
XML
XML é uma linguagem de marcação recomendada pela W3C devido à facilidade de
manipulação, criação e estruturação de documentos, além de ser portável, pois um
documento XML baseia-se em um documento texto (BRAY, 2004).
“Linguagens de marcação são linguagens que descrevem a estrutura de um
documento, ou seja, como as informações estão organizadas. As linguagens de marcação
determinam a forma como o documento está estruturado, e de acordo com essa estrutura,
29
determinam como ele será apresentado. Regras explícitas determinam onde estas estruturas
começam e terminam através de marcas (tags) que são colocadas antes e depois do
conteúdo associado, respectivamente tag de início e tag de fim” (LIMA et al, 2003).
“Os documentos descritos em XML baseiam-se em três componentes distintos:
estrutura, conteúdo e apresentação. A estrutura é definida através de um DTD, onde estão
contidas as regras que regerão os documentos XML, ou seja, é na definição do tipo do
documento que serão especificadas as marcações da linguagem que está sendo
desenvolvida” (LIMA et al, 2003). Um exemplo de DTD pode ser visto na Figura 12.
Figura 12: Exemplo de um DTD três elementos e um atributo.
O conteúdo é onde estão representados os dados, de acordo com a estrutura definida
em um DTD ou não. Para definir que um documento XML está correto existem dois
conceitos: o de documento bem formado e o de documento válido. Um documento bem
formado é aquele em que todas as tags que foram iniciadas foram também finalizadas
seguindo uma seqüência lógica. E um documento válido é aquele em que, além de bem
formado, também segue corretamente a estrutura definida no DTD. A Figura 13 demonstra
um arquivo XML validado de acordo com o DTD da Figura 12.
Figura 13: Exemplo de um arquivo XML válido e bem formado de acordo com o DTD da
Figura 12.
A primeira linha da Figura 13 indica a versão da linguagem XML que será utilizada
no documento. Na linha 2, a instrução <DOCTYPE> referencia o DTD responsável pela
Verificar
possibilidade de alteração
30
validação do documento XML. Da linha 3 a linha 5 há a representação da estrutura do
documento propriamente dita, onde uma turma é formada por um atributo de valor a1 e
dois elementos, ano e semestre, com respectivos valores 2004 e 1. Estabelecendo assim
uma estrutura hierárquica entre os elementos.
Uma outra característica importante da linguagem de marcação XML está no
mecanismo de namespace que tem como objetivo possibilitar o compartilhamento de
esquemas ou vocabulários.
2.3.1
Namespaces
Namespaces têm como objetivo identificar um conjunto de elementos (esquema),
usando prefixos que formam uma nova sintaxe a ser utilizada ao longo de um outro
documento qualquer (BRAY, 1999). Com isso, torna-se possível a reutilização desse
conjunto de elementos na representação de novos domínios. Essa identificação é feita
através do um atributo URI que funciona como um identificador único.
Um namespace é declarado usando uma família de atributos reservados (BRAY,
1999). O nome do atributo deve ser xmlns ou ter xmlns: como prefixo. A Figura 14
demonstra um exemplo de declaração de namespace.
Figura 14: Exemplo de declaração de um namespace
Conforme a representação da Figura 14, na linha 1 é declarado o namespace através
da variável (prefixo) <ep> que terá como valor a sintaxe do esquema representado no
namespace e há também a representação do atributo <xmlns> seguido de um URI que
identifica a localização da sintaxe. Dessa forma, é possível fazer qualquer associação em
um determinado documento a um elemento qualquer representado em uma outra
localidade, através da variável que recebeu como valor do namespace em questão. A
Figura 15 demonstra como seria essa associação.
31
Figura 15: Esquema de utilização de um namespace em um documento XML.
A Figura 16 mostra como o elemento de um esquema pré-definido pode ser
utilizado em um documento XML.
Figura 16: Documento XML que utiliza os elementos pré-definidos em um namespace.
Na
linha
1
da
Figura
16
todos
os
elementos
<http://www.ulbra-to.br/XML/esquemas/produto#>
contidos
no
poderão
URI
ser
referenciados ao longo de todo o documento XML através do atributo <ep>. As linhas 3 e
4 referenciam os elementos <descricao> e <valor>, contidos no namespace associado ao
prefixo <ep>.
As seções subseqüentes apresentarão a utilização de namespace declarando e
utilizando sintaxe de modelos já estruturados e disponíveis na web.
2.4 Resource Description Framework
RDF é uma recomendação da W3C (World Wide Web Consortion) que apresenta
uma nova forma de descrição dos dados na web. Para que o modelo de dados RDF possa
32
ser representado, foi adotado o conceito de metadados, de forma a possibilitar a descrição
de recursos e, com isso, propiciar uma semântica aos mesmos.
Esse modelo teve grande aceitação dentre as ferramentas que proporcionam a
resolução da interoperabilidade em diversas plataformas devido a sua arquitetura genérica
de metadados, permitindo, assim, a descrição dos recursos no contexto web através de
padrões de metadados (LASSILA 1999).
Como o RDF é um modelo, há a necessidade de utilização de uma linguagem para
que o mesmo possa ser representado. Para isso, foi adotada pela W3C a linguagem XML,
pois a mesma demonstra algumas facilidades. Dentre elas destaca-se: a facilidade de
estruturação dos documentos, pois os elementos que compõem so documentos XML
podem ser criados de acordo com que seja necessidade.
O modelo RDF encontra-se definido em dois documentos: Resource Description
Framework (RDF) Model and Syntax Specification (LASSILA, 1999), que descreve o
modelo de dados RDF e Resource Description Framework (RDF) Schema Specification
(BRICKLEY, 2000), que descreve as primitivas de modelagem utilizadas para a descrição
de um domínio particular de interesse. Estas especificações são descritas na próxima seção.
2.4.1 Modelo Básico RDF
O modelo RDF básico destaca-se pela simplicidade com que busca estruturar o
conteúdo de uma página web.
Para que o modelo possa ser visualizado e representado,
são utilizados grafos rotulados que são construídos com a utilização de três objetos. Esses
objetos são descritos a seguir:
•
Resources (recursos): Os recursos representam o universo de objetos que
podem ser descritos pelo modelo RDF. Uma página inteira da web ou uma
parte dela; uma coleção de páginas; ou um objeto que não é diretamente
acessível via web, por exemplo, um livro impresso. Para cada recurso é
associado um identificador único (URI) de forma a poder identificá-lo
posteriormente.
•
Properties (propriedade): representam os aspectos do recurso a serem
33
descritos.
Propriedades
podem
ser
visualizadas
como
atributos
(características) de recursos. Também são utilizadas para descrever
relacionamento entre recursos. Neste sentido, o modelo de dados RDF
assemelha-se ao modelo Entidade-Relacionamento. Cada propriedade tem um
significado específico, definem seus valores permitidos, os tipos de recursos
que podem descrever, e seus relacionamentos com outras propriedades.
•
Statements (sentenças): representam a relação entre um recurso, uma de suas
propriedades e o valor que essa propriedade pode assumir, ou seja, é uma
espécie de declaração de um recurso contendo um nome, uma propriedade e
um valor agregado. Estas três partes da sentença (tripla) são chamadas
respectivamente de predicate (propriedade), subject (recurso) e object (valor
de uma propriedade). E a notação utilizada para representação dessa tripla é:
(predicate, [subject], [object]). “Com isso, as sentenças conseguem
representar essa interligação entre o recurso, suas propriedades e seus valores
(NOLETO, 2003)” .
A Tabela 3 ilustra a construção de uma sentença que descreve que o recurso, um
documento da web e de URI http://www.ulbra-to.br/exemplos/, possui uma propriedade
http://purl.org/dc/elements/1.1/creator, cujo valor é uma string (literal) "Priscilla de
Mello".
Tabela 3: Sentença dividida em partes
Subject (Resource)
http://www.ulbra-to.br/exemplos
Predicate (Property)
http://purl.org/dc/elements/1.1/creator
Object / Literal
"Priscilla de
Mello"
As sentenças também conferem ao modelo de dados RDF a qualidade de ser
compreendida tanto por seres humanos, uma vez que a sentença da Tabela 3 pode ser
interpretada como “Priscilla de Mello é a criadora do recurso http://www.ulbrato.br/exemplos”, bem como por máquinas, que têm acesso a uma representação formal
deste modelo.
Além do formato de tripla, conforme ilustra a Tabela 3, o modelo de dados também
34
pode ser visualizado na forma de um grafo, que consiste de um conjunto de nós conectados
por arcos rotulados, onde os nós representam os recursos web, os arcos representam as
propriedades destes recursos e os retângulos representam os literais (String) (MANOLA,
2004). A Figura 17 demonstra a sentença da Tabela 3 nas formas de um grafo e de uma
tripla respectivamente na parte 1 e 2.
Figura 17: Representação de uma sentença: grafo e tripla
Agora, considerando o caso em que há a necessidade de representar características
mais específicas sobre o criador desse recurso.
O indivíduo cujo nome é Priscilla de Mello com email <[email protected]> é a
criadora do recurso http://www.ulbra-to.br/exemplo/.
A intenção dessa sentença é fazer com que o valor da propriedade Creator seja uma
entidade estruturada. Em RDF uma entidade é representada por outro recurso. A sentença
acima não nomeia o recurso, portanto a Figura 18 demonstra um diagrama tendo um
recurso representado por uma elipse vazia.
35
Figura 19: Propriedade com valor estruturado usando um nó vazio
Para que possa ser associado um URI ao recurso anônimo ramificado poderia ser
utilizado um atributo identificador <ID> advindo de uma base conforme exemplificado
na Figura 20.
Figura 20: Propriedade com valor estruturado
Com isso, o modelo RDF permite que um dado recurso possa abrir novas
ramificações, especificando o modelo num contexto geral de forma mais detalhada. Ou
seja, a indicação do arco criador aponta para um novo recurso que, representado por um
36
URI, faz junção através de novos arcos de propriedades com os seus respectivos objetos.
2.4.1.1
XML como linguagem de Especificação da Sintaxe RDF
Como RDF é um modelo, faz-se necessário o uso de uma linguagem para sua
representação A Figura 21 exemplifica o padrão utilizado para descrição do formato
RDF.
Figura 21: Formato de representação de dados em RDF
De acordo com a Figura 21 inicialmente (linha 1) define-se o tipo da classe que será
descrita. Depois é atribuído um valor ao atributo <rdf:ID> como forma de identificação
do recurso e, após isso (linha 5 a 7), são inseridas as propriedades e os respectivos valores,
descrevendo, dessa forma, as características do recurso.
Para que o modelo possa ser representado, a XML dispõe de duas sintaxes:
serializada e abreviada.
Os exemplos utilizados nos tópicos 2.4.1.1.1 e 2.4.1.1.2 são baseados na sentença
da Figura 22.
Figura 22: Sentença em forma de tripla
2.4.1.1.1 Sintaxe Serializada
37
Essa forma de representação permite expressar toda a potencialidade do modelo
RDF. A Figura 23 ilustra como a sentença pode ser representada de forma serializada em
XML.
Figura 23: Serialização em XML de um recurso RDF
Nas linhas 2 e 3 são declaradas as variáveis de namespaces “RDF:” e “dc”,
que utilizadas no documento XML especificarão a localização de um novo vocabulário. Na
linha 6 há a declaração do atributo <about> com valor
“http://www.ulbra-
to.br/exemplo/2010” que determina o URI do recurso a ser descrito. Em seguida
na linha 7 há a declaração da tag de abertura “dc:creator”, que indica quem é o
criador do recurso, ou seja, uma String de valor “Priscilla de Mello”. Com isso,
tem-se a descrição de um recurso com algumas informações relevantes para o
entendimento de sua semântica.
2.4.1.1.2 Sintaxe Abreviada
Já essa forma de representação inclui construtores adicionais de tal forma que o
modelo RDF possa ser representado de maneira mais compacta. A Figura 24 ilustra a
representação da sentença utilizando a serialização em XML de forma abreviada.
Figura 24: Serialização em XML de um recurso RDF de forma abreviada
38
A sentença descrita na Figura 24 é equivalente à representada na Figura 23, pois
mesmo que sejam descritas de maneiras diferentes, ao final provocarão o mesmo resultado
a uma aplicação.
2.4.2 Primitivas do modelo
As propriedades de um objeto têm a responsabilidade de descrever características
adicionais sobre o mesmo, ou seja, são qualificados valores às propriedades, nomeando-as
com unidade de medidas de um vocabulário qualquer (MARINO, 2001).
Para que os recursos do modelo de dados RDF possam ser descritos de forma clara
e objetiva, foram criadas algumas definições que serão abordadas nos tópicos seguintes.
2.4.2.1
O Elemento <rdf:RDF>
Para que um documento RDF com mais de uma sentença seja descrito, é
obrigatória a utilização do elemento <rdf:RDF>. A Figura 25 mostra um exemplo de um
documento RDF com apenas uma sentença, dessa forma o elemento <rdf:RDF> se torna
opcional.
Figura 25: Representação de uma sentença sem o elemento <rdf:RDF>
2.4.2.2
Descrição (atributo Description / <rdf:Description>)
O atributo <rdf:Description> identifica o sujeito (subject) de uma sentença.
Esse elemento pode conter alguns elementos e/ou atributos: URI do recurso que está sendo
descrito, representação das propriedades, sentenças aninhadas, além de atributos e recursos
39
anônimos (AHMED, 2004). Dentre os atributos existentes para descrição do elemento
<rdf:Description>, os mais importantes são: <rdf:about>, <rdf:ID>,
<rdf:type>. A Figura 26 demonstra a representação desse elemento.
Figura 26: Representação do elemento <rdf:Description>
Conforme pode ser visualizado na linha 07, o elemento <dc:Creator> pode ser
entendido como um atributo de <rdf:Description> ou seu elemento filho, de acordo
com a representação hierárquica de um documento XML.
2.4.2.3
Identificação sobre (atributo about / <rdf:about>)
O atributo <rdf:about> tem como conteúdo um URI que é utilizado como um
identificador único de recursos e propriedades. Quando em um dado recurso diz-se que o
atributo <rdf:about> possui um determinado URI, isso não implica dizer que o
recurso ou propriedade esteja naquela localidade. Os URIs para as sentenças podem ser
relativos ao documento que contém as sentenças, ou seja, um recurso pode ser referenciado
mesmo que esteja contido em outro documento.
Figura 27: Representação do elemento <rdf:about>
40
2.4.2.4
Identificação (atributo ID / <rdf:ID>)
Assim como o atributo <rdf:about>, o atributo <rdf:ID> tem a função de
identificar um recurso. Com a diferença que o atributo <rdf:ID> permite a criação de
um recurso local sobre o qual podem ser feitas novas sentenças, além de permitir também a
utilização da sintaxe abreviada, ou seja, permite utilizar URI abreviado caso o recurso que
esteja sendo referenciado faça parte do documento que contém o metadado. É importante
ressaltar que, os atributos <rdf:about> e o <rdf:ID> são mutuamente exclusivos,
ou seja, somente um pode ser utilizado no elemento <rdf:Description>.
Figura 28: Representação do atributo <rdf:ID>
2.4.2.5
Tipo (atributo type / <rdf:type>)
Esse atributo permite indicar que o referido recurso é de um tipo específico. Os
tipos permitidos são: numérico, texto ou um tipo de um recurso já existente.
Quando o atributo <rdf:type> é utilizado, uma relação binária entre dois
elementos é estabelecida. Essa relação é análoga ao mecanismo de instanciação da
orientação a objetos. A Figura 29 mostra essa relação.
41
Figura 29: Grafo da definição de um tipo
A Figura 30 ilustra a representação do atributo <rdf:type> serializada em XML.
Figura 30: Representação do atributo <rdf:type>
Na linha 6 é utilizado o caractere “#”, que funciona como um delineador ou
indicador de fragmento e, segundo (MARINO, 2001), tem como função referenciar o
aparecimento de um componente dentro do recurso. Com isso, todas as propriedades que
referenciam o recurso estabelecem um relacionamento com a parte referenciada.
Uma segunda forma de representação do atributo <rdf:type> é utilizá-lo como
atributo do elemento <rdf:Description>. A Figura 31 ilustra como seria essa
representação.
Figura 31: Representação do atributo <rdf:type> como atributo do elemento
<rdf:Description>
42
Além das duas formas de representação supracitadas, há uma terceira, essa utiliza o
mecanismo de namespace. A Figura 32 demonstra como é essa representação.
Figura 32: Representação do atributo <rdf:type> com o mecanismo de namespace
2.4.2.6
Conjunto ou lista (Containers)
Os containers são coleções utilizadas para representar conjunto de recursos ou
literais. Por exemplo, para demonstrar que um determinado trabalho foi criado por mais de
uma pessoa, ou então dizer que uma lista de estudantes pertence a um curso. Para que essas
listas possam ser representadas, o modelo RDF provê três tipos de coleções: bag, sequence
e alternative.
2.4.2.6.1 Coleção Bag (<rdf:Bag>)
A coleção Bag é utilizada para declarar propriedades com múltiplos valores, não
importando a ordem em que os valores são apresentados. A Figura 33 demonstra a
representação de uma coleção utilizando a lista Bag.
43
Figura 33: Representação do elemento bag
Nas linhas 8, 9 e 10 é utilizado o elemento <rdf:li> que é responsável por
representar os membros da coleção correspondente.
2.4.2.6.2 Coleção Sequence (<rdf:Seq>)
Essa coleção possui as mesmas funções do elemento Bag no que diz respeito à
representação de múltiplos valores para uma determinada propriedade e diante da
possibilidade de a coleção assumir valores duplicados. A diferença é que os elementos
representados na lista devem estar representados em ordem ascendente. A Figura 34 ilustra
a representação do elemento Sequence.
Figura 34: Representação do elemento Sequence
2.4.2.6.3 Coleção Alternative (<rdf:Alt>)
44
Assim como as demais listas acima, a coleção alternative permite a representação
de objetos ou recursos. As diferenças são que: essa permite declarar apenas um valor a uma
propriedade e não permite valores duplicados. A Figura 35 ilustra a representação do
elemento Alternative.
Figura 35: Representação do elemento Alternative
2.4.2.6.4 Comparação entre as Coleções
Após a explanação das coleções que o modelo RDF dispõe pode ser realizada uma
breve comparação entre as mesmas, conforme a Tabela 4 ilustra.
Tabela 4: Comparação entre os tipos de Coleções providas pelo modelo RDF
(BRAGANHOLO, 2001).
Ordenação
Duplicação
Propriedade Multivalorada
Bag
Não
Sim
Sim
Sequence
Sim
Sim
Sim
Alternative
Não
Não
Não
2.4.2.7
O Mecanismo de Reificação
Para que as características de um determinado recurso possam ser descritas,
baseadas na arquitetura RDF, sempre é estabelecida uma relação binária (propriedadevalor). Esse valor pode ser tanto um literal quanto um outro recurso. Quando esse valor se
45
trata de um recurso obtém-se então o mecanismo de reificação, já que a descrição final do
recurso terá como resultado uma sentença sobre outra sentença.
Para que a reificação possa ser representada, o modelo RDF provê quatro
propriedades:
•
subject: identifica o recurso que está sendo descrito pela sentença modelada;
•
predicate: identifica a propriedade que está sendo descrita pela sentença
modelada;
•
object: identifica o valor da propriedade na sentença modelada;
•
type: descreve o tipo do novo recurso. Todas as sentenças reificadas são
instâncias de <rdf:statement>.
A Figura 36 ilustra a reificação de uma sentença RDF.
Figura 36: Representação de um código RDF reificado
A Tabela 5 apresenta o resultado obtido através do código demonstrado na Figura
36. Duas sentenças são demonstradas: a segunda, que apresenta a reificação, é representada
por <http://www.ulbra-to.br/exemplos/2010>, que possui o predicado
<creator>
e
um
objeto
<http://www.ulbra-
to.br/exemplos/pessoalPage.htm>) (primeira sentença),
que possui duas
propriedades nome e email, cujo os valores são respectivamente Priscilla de
Mello e [email protected]
Tabela 5: Resultado da sentença utilizando uma reificação
Sentença
Sujeito
Predicado
Objeto
46
1
2
http://www.ulbrato.br/exemplos/pessoalPage.htm
http://www.ulbra-to.br/exemplos/2010
Nome
creator
“Priscilla de Mello”
http://www.ulbrato.br/exemplos/pessoalPage.htm
47
2.4.3 RDF Schema
RDF Schema estende a potencialidade do modelo RDF básico, através do uso de
propriedades que proporcionam formas de interligar os recursos que estão sendo descritos
e, com isso, propiciar uma semântica ao esquema representado (BRICKLEY, 2000). A
partir disso, é permitida a criação de vocabulários representados por classes e propriedades
que tornam possível o seu reaproveitamento em outros modelos. A parte 1 da Figura 37
demonstra a representação de um esquema RDF no formato gráfico.
Figura 37: Representação gráfica de uma esquema e sua utilização em um documento
RDF
Conforme a ilustração da parte 2 da Figura 37, um documento RDF qualquer pode
ser originado tendo como base a estrutura representada no esquema pré-definido na parte 1.
Nesse caso, foi gerado um documento que descreve as características de um cachorro cujo
nome é Bellone que tem como cor e raça os valores Preta e Pastor Belga, respectivamente.
Para que haja um entendimento de como um esquema RDF possa ser representado,
nas próximas seções serão feitas explanações dos principais elementos que compõem um
48
esquema RDF (classes e propriedades) e das normas que os regem. A Figura 38 representa
a hierarquia de classes do esquema RDF.
Figura 38: Hierarquia de classes do modelo RDF Schema (BRICKLEY, 2000).
Para a definição de classes e propriedades em um esquema RDF é utilizado o
modelo padrão RDF/XML. Esse modelo é demonstrado na Figura 39.
Figura 39: Modelo RDF/XML utilizado para definição de classes e propriedades
Na linha 2, através do atributo <rdf:ID>, é definida a classe que estará sendo
descrita. Na linha 3 é declarada a variável que conterá a namespace com a definição do
modelo RDF, enquanto na linha 4 é definido o URI do esquema representado. Nas linhas 5
e 6 são definidas as propriedades da classe que está sendo descrita, sendo que as
propriedades podem ser tanto um recurso quanto um literal, linhas 5 e 6, respectivamente.
49
2.4.3.1
Classes
Classe é um modelo que pode ser originado a partir de uma descrição genérica de
recursos individuais pertencente a um dado universo. Após a definição de uma classe, com
a utilização do conceito de heranças, subclasses podem ser geradas, que passarão a conter
todas as características referentes à superclasse, além das características inerentes a ela.
Devido a isso, uma hierarquia é criada entre as classes representadas no esquema,
possibilitando assim um reuso de definições já existentes. A Figura 40 demonstra o
processo de definição de classes.
Figura 40: Processo de definição de classes
Conforme representação na parte 1 da Figura 40, um conjunto de classes e
propriedades, ou seja, o esquema propriamente dito, é definido dentro do elemento
<rdf:RDF>. Nas partes 3 e 4 são definidas as classes que estarão sendo descritas,
cachorro e vertebrados respectivamente, através do elemento <rdfs:Class>. E
por fim, na parte 5 o elemento <rdfs:subClassOf> determina que a classe cachorro
herda todas as características da classe dos “vertebrados”. Esses elementos serão abordados
de forma mais clara nas seções subseqüentes.
2.4.3.1.1 <rdfs:resouce>
50
Um esquema RDF corresponde a um conjunto de recursos oriundos de um domínio
específico. E para que esse conjunto possa ser representado, tem-se que partir de uma
classe genérica, de forma que a mesma comporte todas as outras classes e subclasses
definidas no esquema.
Figura 41: Representação gráfica de um esquema
A Figura 41 representa um esquema hierárquico de uma turma onde a mesma
possui um professor em um dado ano e semestre. Nesse caso o recurso que herdará todas
as características da classe <rdfs:resource> seria a turma, pois a mesma é entendida
como o recurso genérico do esquema em questão. A Figura 42 representa parte do
esquema da Figura 41 serializado em XML.
Figura 42: Parte do esquema da Figura 41 serializado em XML
2.4.3.1.2 <rdfs:Class>
O elemento <rdfs:Class> é utilizado para definição de classes. Ele possui um
atributo <rdf:ID> que tem a função de identificar a classe que está sendo descrita. Para a
51
descrição de uma classe podem ser utilizadas duas sintaxes diferentes, ressaltando que
essas sintaxes, mesmo sendo descritas de formas diferentes, provocam ao final o mesmo
resultado. A Figura 43 representa essas sintaxes.
Figura 43: Sintaxes da criação de uma classe
Conforme pode ser observado na pate 2 da Figura 43, uma classe pode ser definida
através
da
utilização
do
elemento
<rdf:type>
com
valor
<http://w3.org/2000/01/rdf-schema#Class>, que indica que o recurso que
está sendo descrito é uma classe.
2.4.3.1.3 <rdfs:Property>
Esse é o elemento utilizado para definir propriedades, ou seja, representa os
recursos que são propriedades RDF de um outro recurso. Duas sintaxes diferentes podem
ser utilizadas para que as mesmas possam ser descritas e só assim interligadas a uma
classe. A Figura 44 representa essas sintaxes.
52
Figura 44: Sintaxes de definição de uma propriedade e seu relacionamento com uma
classe
Em ambas definições é utilizado o elemento <rdf:ID> como forma de identificar
a propriedade que está sendo descrita. Na sintaxe demonstrada na parte 1 da Figura 44 é
dito que uma propriedade estará sendo descrita através da classe <rdf:Property>,
enquanto a sintaxe representada na parte 2 demonstra que a mesma propriedade pode ser
criada através de um recurso, onde o elemento <rdf:type> tem a responsabilidade de
representar o que está sendo descrito, que pode ser tanto uma propriedade (parte 2 da
Figura 44) quanto uma classe (parte 1 da Figura 44)
2.4.3.2
Propriedades
As propriedades expressam características ou aspectos que uma dada classe pode
assumir, além de utilizarem também mecanismo para expressar relacionamentos entre as
classes. A Figura 45 representa o processo de definição de uma propriedade.
53
Figura 45: Definição de Propriedade
O modelo RDF básico provê do elemento <rdf:Property> como forma de
representar uma propriedade, enquanto que o RDF Schema dispõe de dois elementos
<rdfs:domain> e <rdfs:range> como forma de interligar uma propriedade a uma
referida classe. Com isso, conforme representação na Figura 45 da linha 5 a 8, uma
propriedade raça do tipo literal é definida como característica da classe Cachorro.
2.4.3.2.1 <rdfs:subClassOf>
Esse elemento determina a relação entre classes (subclasse e superclasse). Se for
definido um elemento <rdfs:subClassOf> em uma classe subtende-se que um
relacionamento é estabelecido entre uma subclasse e uma superclasse (herança simples).
Agora, caso mais de um elemento <rdfs:subClassOf> esteja definido em
determinada classe, é estabelecido o conceito de herança múltipla. A Figura 46 está
dividida em 2 partes. Na primeira parte é estabelecido o conceito de herança simples, na
segunda, é demonstrado o de herança múltipla.
54
Figura 46: Exemplo do elemento <rdfs:subClassOf>
Na parte 1 da Figura 46, é dito que a classe Cachorro além de possuir as
características inerentes a ela, também possui as características da classe dos
Vertebrados. A parte 2 da figura mostra o conceito de herança múltipla, pois a classe
Cachorro herda as características tanto da classe Vertebrados quanto dos
Mamíferos, ou seja, um Cachorro se enquadra em ambas as classes.
2.4.3.2.2 <rdfs:subPropertyOf>
55
O elemento <rdfs:subPropertyOf> determina que uma propriedade é uma
especialização de uma outra. Isso implica dizer que é estabelecida uma relação hierárquica
entre as propriedades. Para demonstração desse elemento será utilizado o seguinte
exemplo: a distância oficial entre a cidade de Palmas e Paraíso é de 62km, enquanto a
estimada é de 59km. Para o exemplo em questão, a unidade km se trata de uma
propriedade, assim como o valor oficial e o estimado, sendo que essas distâncias (oficial e
estimada) herdarão as características da propriedade km. A Figura 47, dividida em partes,
demonstra essa relação hierárquica entre as propriedades tanto graficamente quanto
serializada em RDF/XML.
Figura 47: Hierarquia de propriedades a partir da utilização do elemento
<rdfs:subPropertyOf>
2.4.3.2.3 <rdfs:range>
O
elemento
<rdfs:range>
é
uma
instância
da
classe
<rdfs:ConstraintProperty> que tem como funcionalidade especificar que valores
uma propriedade pode assumir. Uma propriedade admite apenas um <rdfs:range>,
pois a mesma pode ser de apenas um tipo, ou seja, não pode ser multivalorada, por
exemplo, não pode assumir valores tipo inteiro e literal simultaneamente. Para
56
representação desse elemento, considerando o exemplo em que se deseja representar uma
propriedade km que terá como valor um objeto do tipo inteiro.
Figura 48: Representação do elemento <rdfs:range>
2.4.3.2.4 <rdfs:domain>
Assim como o <rdfs:range>, o <rdfs:domain> também é instância da
classe <rdfs:ConstraingProperty>, pois também tem a função de restringir, só
que nesse caso especifica a qual classe uma propriedade está agregada, diferentemente do
<rdfs:range> que identifica que valor uma propriedade pode assumir. Para
exemplificação desse elemento a Figura 48 representa o exemplo em que uma propriedade
km do tipo inteiro relaciona-se com a classe distância.
Figura 49: Representação do elemento <rdfs:domain>
2.4.3.3
Representação de uma taxionomia serializada em RDF/XML
Após ter sido feita uma explanação a respeito dos principais elementos que
compõem o modelo RDF Schema, uma taxionomia pode ser representada a partir da
escolha de um domínio. A Figura 49 representa a criação de uma taxionomia serializada
em RDF/XML tendo como base o domínio “Reino Animal” representado na Figura 37.
57
Figura 49: Representação de uma taxionomia em RDF/XML
A partir do esquema serializado em RDF/XML, representado na Figura 49, que
descreve um domínio referente ao reino animal, é possível a criação de sentenças que
descrevam recursos pertencentes a esse domínio.
58
2.5 API Jena
Jena é uma API (conjunto de classes) Java, desenvolvida pela HP, que possibilita a
construção de aplicações para web semântica. Essa API propicia um ambiente para
trabalhar com RDF, RDFS e OWL (MCBRIDE, 2004).
Dentre todos os recursos oferecidos, serão mostrados aqui somente alguns
conceitos fundamentais para a criação e manipulação de grafos RDF. Para isso a API
disponibiliza algumas classes que tornam possível a manipulação de
recursos,
propriedades e literais. As interfaces que representam os recursos, propriedades e literais
são respectivamente chamadas de: Resource, Property e Literal. Na Jena um
grafo é chamado de “modelo”, representado pela interface Model.
O processo de geração de documentos RDF a partir da utilização da API Jena é
feito da seguinte forma:
Passo 1: Inicialmente instancia-se um objeto da classe ModelMem, que conterá um
grafo vazio e que estará disponível apenas em memória, ou seja, existirá
apenas durante o processo de execução do programa.
Passo 2: Conforme citado no Passo 1, o grafo criado, ainda vazio, precisa de
recursos para que seja possível a manipulação do modelo RDF. Para isso
o mesmo pode ser feito através do método createResource
disponibilizado pela classe ModelMem.
Passo 3: Após a criação do recurso, faz-se necessária a inserção de propriedade(s)
no mesmo, e com isso é(são) propiciada(s) característica(s) ao recurso
criado.
Seguindo os passos (1, 2 e 3) anteriormente mostrados, serão feitas demonstrações
de exemplos de códigos Java, que terão sempre ao final de sua execução a geração de um
documento RDF.
59
Figura 50: Exemplo de criação de um documento RDF simples
Da linha 01 até a linha 03 são importadas as classes que serão utilizadas no decorrer
da implementação (código Java). Na linha 16 é criado um modelo vazio, que passará a não
ser vazio a partir das linhas 17, 18 e 19, onde são criados e adicionados ao modelo: um
recurso <http://www.ulbra-to.br/exemplo/2010>
e
uma propriedade
<nome>, cujo valor é um literal “Priscilla de Mello”. Ao final, na linha 20, o
modelo criado foi impresso a partir da utilização do método write do objeto
objModelo.
Figura 51: Resultado obtido a partir da execução do código demonstrado na Figura 50.
No exemplo demonstrado na Figura 50, foi criada uma tripla: recurso, propriedade
com seu respectivo valor (um literal). Agora, considerando que a sentença criada seja de
um tipo específico, o código da Figura 52 mostra qual seria o procedimento necessário
para definição de tipagem.
60
Figura 52: Exemplo de definição de tipagem para um dado recurso
A diferença do código apresentado na Figura 50 para o demonstrado na Figura 53, é
que no primeiro (Figura 50) durante a criação do recurso, linha 17, é passada uma String
por parâmetro, determinando assim o URI do mesmo, enquanto o segundo (Figura 52) é
passado por parâmetro um outro recurso, dessa forma é dito que o recurso que está sendo
criado é do tipo do que foi passado por parâmetro, nesse caso em específico, tipo pessoa.
A Figura 53 mostra o documento RDF gerado a partir da execução do código demonstrado
na Figura 52.
No exemplo subseqüente, Figura 54, é demonstrado um código Java que cria um
documento RDF contendo um recurso que, além de possuir uma propriedade com um valor
61
literal, possui também uma segunda propriedade (endereco) contendo um recurso como
valor. Dessa forma o resultado final obtido será uma sentença sobre outra sentença.
Figura 54: Criação um recurso com uma propriedade tendo como valor um outro recurso
A Figura 55 demonstra o documento RDF gerado a partir da execução do
documento Java demonstrado na Figura 54.
62
Tendo como base os exemplos demonstrados anteriormente, torna-se possível então
a criação de documentos RDF a partir de quaisquer dados de entrada. É importante
ressaltar que os documentos criados estão armazenados apenas na memória e, caso haja
necessidade de guardar esses documentos, os mesmo devem ser armazenados fisicamente.
2.6 Considerações
Para que pudesse haver um melhor entendimento a respeito da tecnologia JSP, foi
mostrado inicialmente na seção 2.1, o que é, e como é o funcionamento de um Servlet, que
é o fundamento básico para a tecnologia JSP, já que JSP é uma extensão da tecnologia
Servlet.
Logo em seguida, na seção 2.2, foram mostrados alguns conceitos da tecnologia
JSP, que vão desde a sua importância, funcionamento básico, demonstração de expressões,
declarações e diretivas, até a demonstração dos objetos pré-definidos (objetos utilizados
para desenvolvimento de páginas web).
Como RDF é um modelo que utiliza a linguagem XML para ser representado, na
seção 2.3 é feita uma breve explanação a respeito dos conceitos da linguagem de marcação
XML. A XML também dispõe de um recurso importantíssimo que possibilita o
compartilhamento de recursos: namespace. Na seção 2.4 são demonstrados os conceitos do
modelo RDF através de exemplos elucidativos, que buscam, assim, fazer com que o leitor
compreenda quais são os recursos oferecidos pelo modelo e a partir disso criar documentos
RDF.
E, por fim, na seção 2.5, dentre os diversos reursos oferecidos pela API Jena, foi
demonstrado, através de exemplos, como é o procedimento de criação (implementação) de
um documento RDF e os resultados finais obtidos.
63
3
MATERIAIS E MÉTODOS
Para o desenvolvimento do referido trabalho foram utilizados diversos recursos
bibliográficos, de hardware e software, que aliados às orientações permitiram a finalização
do mesmo.
3.1
Local e Período
Este trabalho foi desenvolvido durante o primeiro semestre de 2004, como parte da
disciplina “Prática em Sistemas de Informação I”. Os locais utilizados para sua elaboração
foram os laboratórios de informática do curso de Sistemas de Informação, sendo que os
mais utilizados foram o Laboratório de Inteligência Computacional (Linc) e Núcleo de
Desenvolvimento de Software (NDS) do Centro Universitário Luterano de Palmas. Bem
como, destacando também, a utilização de um computador pessoal.
3.2 Materiais
Os recursos utilizados para o desenvolvimento do trabalho foram disponibilizados
pelo próprio curso Sistemas de Informação do CEULP/ULBRA em seus laboratórios, tais
como hardware e software licenciados. As demais ferramentas free foram adquiridas via
Internet.
64
3.2.1 Hardware
Pentium III, 750 Mhz e 128 Mb de RAM (Disponível no laboratório);
Pentium IV, 2.4 Ghz e 256 Mb de RAM (Disponível no laboratório);
3.2.2 Software
Microsoft Windows 2000 Professional;
Microsoft Office 2000 Professional;
Internet Explorer 6.0;
Acrobat Reader 6.0;
Corel Draw 11
Macromedia Fireworks MX
Sun WebServer 6.1
Máquina Virtual Java (j2sdk 1.4.0 )
3.2.3 Fontes Bibliográficas
Livros
Dissertações de Mestrados;
Trabalhos de Conclusão de Curso;
Publicações Científicas;
Artigos;
Site da W3C (World Wide Web Consortium) (W3C, 2004);
Sites diversos.
3.3 Metodologia
Diversas pesquisas foram realizadas, de maneira que permitisse oferecer uma
sustentação teórica necessária para a conclusão do presente trabalho. Assim, foram
65
abordados conceitos e técnicas alusivas ao escopo do trabalho, para que fosse possível
desenvolver um sistema que possibilitasse a descrição de imagens, como forma de
concretização dos conceitos explanados na Revisão de Literatura.
Foi estabelecido também um cronograma de estudos para o desenvolvimento do
referido trabalho, sendo que o mesmo é apresentado na Tabela 6.
66
Tabela 6: Cronograma de atividades
Data
22/3/2004
29/3/2004
Atividade
Aprendizado sobre RDF: o que é, qual sua importância, elementos disponíveis para
criação de um documento RDF.
Baseado na fundamentação teórica: construir documentos RDF para esclarecer os
conceitos estudados anteriormente.
Depois de fazer um estudo dos conceitos básico do modelo RDF, fazer a documentação
5/4/2004
(revisão de literatura) sobre o RDF e RDF Básico, além da linguagem XML que serializa
o modelo.
Aprendizado de RDF Schema: realizar pesquisas e leitura do material fornecido pelo site
12/4/2004
da W3C e também de livros e dissertações. E, a partir disso, será utilizado esses
conceitos para criação de um esquema que represente o domínio do referido trabalho.
19/4/2004
Tendo como base os conceitos adquiridos até o momento, será feita a revisão de
literatura sobre RDF Schema.
Aprendizado sobre a tecnologia JSP: processamento de dados de formulários, interação
26/4/2004
com o usuário, manipulação de sessão, o que é, e para que serve uma diretiva, expressões
e utilização dos objetos implícitos. Fazer a devida documentação a respeito dos referidos
conceitos.
Aprendizado sobre API Jena (API Java desenvolvida pela HP para manipulação
dinâmica de documentos RDF): qual sua importância, para que serve, e como deve ser
3/5/2004
utilizada, sendo que para isso devem implementados exemplos de códigos Java que
criem documentos RDF. Realizar também a devida documentação a respeitos dos
recursos oferecidos pela mesma para manipulação de documentos RDF.
10/5/2004
17/5/2004
24/5/2004
31/5/2004
7/6/2004
Definir como será o esquema de funcionamento do sistema, ou seja, etapas para
descrição de uma determinada imagem.
Definir como será a forma de armazenamentos dos documentos RDF, para que, num
processo futuro, o processo de busca possa ser facilitado.
Definir a interface: a interface deverá ser preparada para suportar a descrição de
documentos de acordo com o esquema previamente definido.
Depois de todos os conceitos adquiridos anteriormente, o sistema deverá ser então
implementado.
Fazer a devida documentação a respeitos dos resultados obtidos, os testes na aplicação
desenvolvida e correções no relatório final.
67
4
RESULTADOS E DISCUSSÃO
A presente seção tem o objetivo de, a partir dos conceitos apresentados
anteriormente, mostrar um sistema que foi desenvolvido para construção de documentos
RDF que descrevam imagens referentes ao âmbito institucional, no caso em questão:
CEULP/ULBRA. O sistema foi implementado em JSP, sendo que, o que motivou a escolha
dessa tecnologia, foi o fato de a mesma ser uma tecnologia para web, além de trabalhar
com a linguagem Java, pois há uma API Java disponível para manipulação de documentos
RDF.
Para tanto, foi desenvolvido um esquema do sistema, além de um conjunto de
regras estabelecidas para descrição das imagens, que serão apresentadas nas seções
seguintes.
4.1
O Sistema
Para que haja um melhor entendimento, por parte do leitor, foi desenvolvida uma
representação gráfica dos passos necessários para a descrição das imagens, que vão desde a
digitalização até a descrição da mesma, através de um documento RDF, de forma
transparente ao usuário. Transparente, no sentido de que o mesmo não conhece a estrutura
interna de criação e armazenamento dos documentos RDF responsáveis pela descrição das
imagens.
68
Figura 56: Etapas possíveis para descrição das imagens.
De acordo com a Figura 56, inicialmente um usuário pode digitalizar a imagem
(passo 1), e com isso disponibilizá-la em algum meio físico de armazenamento (passo 2).
A partir da imagem armazenada, o usuário, através do browser¸ pode acessar o sistema que
foi desenvolvido e informar os dados referentes à imagem em questão, objetivando assim
descrevê-la (passo 3). A partir da confirmação do usuário para a respectiva descrição
(passo 4),
a imagem é então enviada e armazenada no servidor, juntamente com a
descrição equivalente, ou seja, o documento RDF.
69
4.2 RDF Schema na Criação de um Conjunto de Regras para Descrição das
Imagens
Baseado nos conceitos apresentados na seção 2.4.3, sobre RDF Schema, que
possibilita a representação de vocabulários diante da especificação de um domínio, foi
desenvolvido um esquema que representa as regras de criação de um documento RDF. A
Figura 57 demonstra esse esquema serializado em RDF/XML.
Figura 57: Esquema que representa as imagens referentes ao domínio “Instituição de
Ensino Superior”.
70
Seguindo a representação do esquema serializado em RDF/XML (Figura 57), das
linhas 04 a 07 está sendo definida a classe maior, que herda todas as características de
Resource, ou seja, todas as ramificações do esquema partirão dessa classe, que é a
genérica.
Para que possa haver um vínculo entre a figura (.jpeg) e o documento RDF que está
descrevendo-a, foi criada uma propriedade localFisico, que armazenará o caminho da
imagem equivalente, conforme pode ser observado das linhas 08 a 12 da Figura 57.
As imagens podem pertencer a dois âmbitos na instituição: o acadêmico e o
administrativo. Para tanto, foram criadas, respectivamente as classes Curso (linha 13 a
16) e setorAdministrativo (linha 27 a 30).
O que há nos cursos, tanto de graduação, quanto de pós-graduação, está sempre
ligado às atividades de ensino, pesquisa e extensão. Devido a isso, foi criada uma
propriedade atividadeNoCurso que é utilizada para representar tais atividades,
conforme pode ser visualizado na linha 22 a 26. Após a determinação da atividade, a
imagem pode estar ligada a uma pessoa ou a uma estrutura física. Para os casos em que
seja uma pessoa, foi criada uma classe Pessoa (linha 36 a 40), sendo que essa pessoa
pode ser de um dos três tipos: “docente”, “discente” e “funcionário administrativo”. Por
isso, da linha 41 a linha 45 foi criada uma propriedade tipoPessoa que se relaciona
com Pessoa. Se a pessoa for do tipo “docente”, estará implícito que é um professor, e
que também poderá possuir um cargo (linha 46 a 50), assim como, um “funcionário
administrativo”. Da mesma forma, os discentes são compreendidos, com a diferença que os
mesmos não terão um cargo, porém (em alguns casos) exercerão uma determinada função
(linha 51 a 55) na instituição, tais como: estagiário ou monitor. Se a imagem for uma
estrutura física, a mesma possuirá apenas um valor literal, que representará uma descrição
(linha 31 a 35).
Assim como a propriedade pessoa está relacionada com o setor acadêmico, ela
também se relaciona com “setor administrativo” (linha 39), com a diferença que a última
citada possui uma propriedade cargo, diferentemente do acadêmico, em que poderia
possuir um cargo ou uma função. Da mesma forma, a propriedade que determina a
descrição da estrutura física (estruturaFisica) também está agregada tanto ao setor
acadêmico quanto ao administrativo (linha 34). A Figura 58 representa o esquema
serializado em RDF/XML da Figura 58 no formato de grafo.
71
Figura 58: Grafo do esquema da Figura 57.
Segundo (NOLETO, 2003), um grafo RDF Schema (Figura 58) serve para
visualizar e auxiliar na definição de um modelo em que as classes (recursos) podem ser
representadas por nós, as propriedades pelas arestas e o tipo que essa propriedade pode
assumir é representada por um retângulo. Assim, através da aresta, pode-se fazer uma
ligação entre as classes representando uma relação de hierarquia, uma ligação entre classe
e tipo da propriedade, para determinar o tipo que uma propriedade pode assumir.
4.3 Representação do Vocabulário em uma Classe Java
De acordo com os exemplos demonstrados na seção 2.5, os recursos com suas
respectivas propriedades são criados e armazenados em um modelo na memória. Isso pode
ser observado como um problema, tendo em vista a portabilidade. Dessa forma, torna-se
inevitável a duplicação do modelo, haja vista a inexistência de um prefixo de namespace
dinâmico de forma a tornar ineficaz a reusabilidade do código em outros documentos
(NOLETO, 2003). Para isso, segundo representação da Figura 59, uma classe Java foi
72
criada com o intuito de representar o vocabulário criado e serializado em RDF/XML
(Figura 57), e a partir dessa representação o cliente (desenvolvedor) pode reutilizar o
esquema criado de acordo com as suas necessidades.
Figura 59: Criação de um vocabulário em uma classe Java: utilizando a API Jena.
Conforme pode ser observado (Figura 59), inicialmente (linha 01) é definido a que
pacote pertence a classe que está sendo implementada, logo em seguida (linha 12) é
instanciada uma variável do tipo String que contém a namespace à qual os recursos e as
73
propriedades serão posteriormente associados. Da linha 17 a 41 é feita a declaração das
propriedades e dos recursos, e um pouco mais adiante, linha 47 a 59, é feita a associação
dos recursos e das propriedades anteriormente declarados a namespace do referido
vocabulário.
4.4 Utilizando o Vocabulário representado em uma Classe Java para
Criação de um Documento RDF.
Com o intuito de demonstrar a utilização da classe Java, criada na seção 4.3, para
representação de um vocabulário, a Figura 60 apresenta um código que terá ao final de sua
execução a criação de um documento RDF.
74
Figura 60: Código Java de criação de um documento RDF a partir do esquema
representado na seção 4.3.
De acordo com o código representado na Figura 60, na linha 04 é importada a
classe que contém a definição do vocabulário e, a partir disso, o esquema pertinente a ela
poderá ser utilizado durante o processo de implementação. Conforme pode ser observado
da linha 32 a 37, um recurso e algumas das propriedades definidas anteriormente estão
sendo utilizados para a criação de um novo documento RDF. A Figura 61 apresenta o
documento RDF gerado a partir da execução do código demonstrado na Figura 60.
75
Figura 61: Documento RDF gerado a partir da execução do código Java demonstrado na
Figura 60.
4.5 Processo de Armazenamento das Descrições das Imagens
De acordo com a representação do esquema, na seção 4.2, uma propriedade
localFisico foi criada para estabelecer um vínculo entre a imagem (figura .jpeg) e sua
descrição equivalente (.rdf). Além disso, foi criada uma hierarquia de pastas, obedecendo a
estrutura estabelecida pelo esquema, com o objetivo de estabelecer uma organização para o
armazenamento dos documentos RDF. A estrutura hierárquica pode ser observada na
Figura 62.
76
Figura 62: Estrutura hierárquica de armazenamento dos documentos RDF.
Conforme foi dito anteriormente, a estrutura hierárquica das pastas foi criada de
acordo com a definição do esquema, por isso, pode ser observado que há duas pastas
genéricas: curso e setorAdm. Na pasta curso há mais um nível, em que o mesmo é
subdividido em graduaçao e posGraduacao, sendo que ambos contêm seus
respectivos cursos e cada um dos cursos contém mais um nível: estruturaFisica e
pessoa. O nível setorAdm é subdividido apenas em estruturaFisica e pessoa .
77
Para que a aplicação, num processo futuro, não tenha a necessidade de pesquisar
em todos os documentos e de conhecer a estrutura física que armazena os documentos
RDF, foi criado um documento RDF intermediário, que tem a responsabilidade de guardar
os nomes dos documentos criados, pertinentes a cada uma das ramificações da estrutura
hierárquica. Partindo-se do pré-suposto que o único documento criado foi o demonstrado
na Figura 60, o documento intermediário estaria organizado da seguinte forma (Figura 63).
Figura 63: Documento que armazena o nome dos arquivos RDF que descrevem as
imagens: de acordo com a posição ocupada pelos mesmos no esquema.
Como foi criado um único documento RDF, o arquivo intermediário contém apenas
um
recurso,
sendo
que
esse
recurso
possui
um
URI
com
valor
“curso/graduacao/SistemasDeInformacao/pessoa”, ou seja, todos os
documentos RDF associados a esse recurso, através da propriedade arquivo, são de uma
pessoa do curso de graduação de Sistemas de Informação
4.6 Classe Criada para Implementação do Sistema
Durante o processo de desenvolvimento do sistema, observou-se a necessidade de
criação de apenas uma classe Arquivo, que permite ao desenvolvedor trabalhar
fisicamente com os documentos RDF, já que para manipular os mesmos em memória
existem as classes disponibilizadas pela API Jena. Os métodos pertinentes a referida classe
estão sendo demonstrados na Tabela 7.
78
Tabela 7: Relação dos métodos da classe Arquivo.
Assinatura
Retorno
Métodos e Parâmetros
Boolean
verificarArquivoExiste(String nomeArquivo)
boolean
gravarArquivo(String, Model)
boolean
gravarArquivo(String, RDFWriter writer,
Model)
Model
carregarArquivo(String nomeArquivo)
int
pegarNovoArquivo(String)
File[]
pegarConjuntoArquivos(String)
Nas seções subseqüentes é feito um breve comentário a respeito de cada um desses
métodos, além do código Java que os implementam.
4.6.1 Método verificarArquivoExiste(String)
Esse método é utilizado para verificar se um determinado arquivo existe ou não em
um local especificado pelo usuário (desenvolvedor), sendo que tanto o nome do arquivo,
quanto o local são passados por parâmetro numa única string. O mesmo é utilizado para
verificar se o documento RDF intermediário existe. Se não existir, o mesmo deverá ser
então criado e, caso contrário, ele deverá ser apenas alterado. O código que implementa
esse método é apresentado na Figura 64.
79
Figura 64: Código Java que implementa o método verificarArquivoExiste
(String)
4.6.2 Método gravarArquivo(String, Model)
Esse método é utilizado para gravar um novo arquivo RDF, que recebe por
parâmetro o nome do arquivo e o objeto Model, que contém o modelo RDF. Esse método
é utilizado quando o documento RDF intermediário é gravado. Seu código pode ser
visualizado na Figura 65.
Model)
4.6.3 Método gravarArquivo (String, RDFWriter, Model)
Conforme pode ser observado, esse método possui a assinatura diferente do
apresentado na seção 4.6.2. Isso se deve ao fato de o mesmo possibilitar a alteração do(s)
prefixos(s) da(s) namespace(s) do documento RDF, antes que o arquivo possa ser então
armazenado em uma memória física. Esse método é utilizado durante o processo de
armazenamento dos documentos RDF que descrevem as imagens, tendo em vista que o
prefixo da namespace é alterado para “imagem”. O código que implementa esse método
pode ser visualizado na Figura 66.
80
RDFWriter, Model)
4.6.4 Método carregarArquivo(String)
A partir do nome do arquivo, juntamente com seu caminho físico, esse método,
quando invocado, retornará um objeto Model, ou seja, passará o conteúdo do arquivo
RDF para a memória, fazendo com que o mesmo possa ser então alterado e posteriormente
re-armazenado. O presente método é utilizado para realizar alteração no documento RDF
intermediário, tendo em vista que o mesmo já exista. Na Figura 67, pode ser visualizado o
código que implementa o presente método.
Figura 67: Código Java que implementa o método carregarArquivo(String)
4.6.5 Método pegarNovoArquivo (String)
Antes que um novo arquivo possa ser gerado, o mesmo precisa ser associado a um
identificador, pois não pode haver arquivos com o mesmo nome em um mesmo local
físico. Para isso, esse método é utilizado com a função de gerar um novo e único
identificador para o arquivo que posteriormente será armazenado. A implementação desse
método pode ser visualizada na Figura 68.
81
Figura 68: Código Java que implementa o método pegarNovoArquivo (String)
4.6.6 Método pegarConjuntoArquivos(String)
Esse método tem a responsabilidade de retornar um conjunto de arquivos
pertencentes a uma determinada pasta. Ele ainda não está sendo utilizado, foi projetado e
implementado para que possa ser utilizado durante o processo futuro de implementação de
um módulo que fará as buscas nos documentos RDF armazenados. Seu código pode ser
visualizado na Figura 69.
Figura 69: Código Java que implementa o método pegarConjuntoArquivos
(String)
4.7 Utilizando o Sistema para Descrição de uma Imagem
Como em RDF não há uma forma de verificar se os documentos criados estão de
acordo com o esquema que representa o domínio, foi desenvolvida uma interface que
segue a especificação do esquema, limitando assim as possibilidades do usuário, ou seja, só
poderão ser criados documentos de acordo com a especificação pré-definida pelo sistema.
Nesse sentido, pode ser observado como uma vantagem, analisando o ponto de vista de que
o usuário não poderá criar documentos aleatórios. Para a demonstração dos passos a serem
seguidos para descrição de uma dada imagem escolheu-se uma fotografia de um grupo de
82
estagiários, alunos do curso de graduação de Sistemas de Informação e que estão
vinculados à atividade ensino. A parte do sistema que possibilita a escolha de uma imagem
(.jpeg) pode ser visualizada na Figura 70.
Figura 70: Tela Principal do Sistema.
Após a escolha da imagem o sistema direciona o usuário para a tela em que estará
disponível o formulário com os campos necessários para descrição da referida imagem. A
Figura 71 apresenta tal formulário com as devidas informações a respeito da imagem
anteriormente escolhida.
83
Figura 71: Formulário que possibilita a submissão das informações sobre uma dada
imagem.
Conforme pode ser observado na Figura 71, para os campos, Titulo, Crédito,
Descrição
e Data (que fornecem informações gerais sobre a imagem) foram
atribuídas respectivamente as seguintes informações: “Estagiários em um laboratório”,
“Coordenadora do Curso”, “Estagiários do curso de Sist. Inf.” e “15/06/2004”. É
importante ressaltar que somente o campo Descrição é facultado ao usuário o seu
preenchimento. Informações mais específicas podem ser determinadas a partir das opções
demonstradas na parte 2 da Figura 71. Dessa forma foi possível detalhar a descrição da
imagem a tal ponto de dizer que a mesma se trata de alunos estagiários do curso de
graduação de Sistemas de Informação. A Figura 72 apresenta o documento RDF gerado a
partir da confirmação da descrição da referida imagem.
84
Figura 72: Documento RDF gerado.
85
4.8 Considerações
Como forma de colocar em prática parte dos conceitos que fundamentam
teoricamente o trabalho (seção 2), a seção 4 demonstrou as etapas a serem seguidas para a
construção de um sistema que vise a descrição de uma dada imagem referente a insituição
de ensino CEULP/ULBRA.
A seção 4.1 apresentou o sistema como um todo e, logo após, na seção 4.2, foi
apresentado o esquema criado e serializado em RDF/XML para representação do referido
domínio. A sua representação equivalente em uma classe Java (utilizando os recursos
oferecidos pela API Jena) foi apresentada na seção 4.3. A seção 4.4 demonstrou, através de
um exemplo prático, como a classe Java, que representa o vocabulário, pode ser utilizada
durante um processo de implementação que visa a criação de um documento RDF.
A seção 4.5 apresentou qual o processo de armazenamento seguido, sendo que esse
processo se deve ao fato de tornar os arquivos armazenados bem definidos e organizados,
objetivando assim facilitar o processo de implementação do módulo que realizará as
buscas, além de torná-las mais eficazes. A seção 4.6 apresenta uma classe que foi criada
para o gerenciamento dos arquivos RDF, como: verificar se um dado arquivo existe, pegar
o identificador para criação de um novo arquivo, gravar um arquivo ou então recuperá-lo.
E, por fim, na seção 4.7 é feita a descrição de uma determinada imagem de modo a
demonstrar quais seriam as etapas a serem seguidas para a descrição da mesma a partir da
utilização do sistema.
86
5
CONSIDERAÇÕES FINAIS
Um grande desafio enfrentado pelos pesquisadores é o desenvolvimento da web
semântica, pois envolve dispendiosas modificações da web atual, em que as informações
são apenas exibidas, para uma web onde as informações sejam apresentadas, interpretadas
e processadas por agentes de software. Segundo (LUSTOSA, 2003), a web semântica será
o futuro da web atual em as informações serão dads explicitamente com seus signficados e,
a partir disso as máquinas farão o processamento automático e a integração dessas
informações disponíveis na web.
Um dos passos para tornar essa web possível é a estruturação das informações de
forma homogênea, ou seja, obedecendo a um padrão específico. Para isso é explorada a
potencialidade da XML em definir esquema (vocabulários) e a flexibilidade do RDF em
representar dados (OWL, 2003).
O presente trabalho objetivou, a partir do entendimento sobre os conceitos RDF e
RDF Schema, a demonstração das etapas de desenvolvimento de uma ferramenta que
possibilitasse a um usuário a descrição e o armazenamento de uma determinada imagem
referente ao domínio “instituição de ensino superior CEULP/ULBRA”. A definição do
domínio era o ponto base para desenvolvimento da referida aplicação, sendo que, a partir
da definição do mesmo, foi definido formalmente um conjunto de termos que regeriam o
comportamento dos documentos RDF, ou seja, os documentos RDF que descreverão as
imagens estarão de acordo com o esquema criado.
Essas regras foram definidas a partir da utilização do RDF Schema que possibilita a
definição de classes que possuem superclasses e várias subclasses, propriedades que
podem ter subpropriedade e domínio. Nesse sentido, o RDF Schema pertence à definição
de ontologias, no entanto com algumas limitações, isso pelo fato de o mesmo não possuir,
87
em sua sintaxe, propriedades que viabilizem inferências. Essas inferências visam fazer com
que a máquina possa, através de acesso às regras e a uma coleção de dados e metadados,
abstrair um significado semântico das informações disponibilizadas na web (OWL, 2003).
Assim, como trabalho futuro, pode ser utilizada uma linguagem para ontologias na
representação do supracitado domínio. E, a partir da ontologia criada, possibilitar que as
máquinas possam fazer inferências. Assim, será possível obter uma performance útil de
raciocínio sobre os documentos.
Para a criação dessa ontologia pode ser utilizada a linguagem OWL, que pode ser
entendida como uma linguagem para construção de ontologias que permite a representação
explícita de um conjunto de termos de um vocabulário e os relacionamentos entre os
mesmos (OWL, 2003). A sua possível utilização deve-se ao fato de ser baseada na sintaxe
da XML e RDF, pois os documentos RDF responsáveis pela descrição das imagens
poderiam ser reaproveitados, ou seja, seriam apenas readaptados para a ontologia criada.
Tendo como base as imagens sistematizadas, a partir da utilização do sistema, uma
nova funcionalidade pode ser acrescida ao mesmo: a realização de consultas a esses
documentos RDF, sendo que para isso seria utilizada a linguagem de consulta RDQL.
RDQL é uma linguagem de consulta para extrair dados de um documento RDF, ou
seja, permite acessar informações específicas em um documento, a partir de uma dada
consulta (SEABORNE, 2004). A sintaxe dessa linguagem de consulta é similar à sintaxe
da SQL, uma linguagem para consulta a banco de dados relacionais. Embora esse não
tenha sido o objetivo do trabalho, foram realizados alguns estudos a respeito de tal
linguagem de consulta e, a partir desses estudos, foram realizados alguns testes para que
pudesse haver um entendimento de como a mesma poderia ser aplicada no ambiente.
88
6
REFERÊNCIA BIBLIOGRÁFICA
(AHMED, 2001) AHMED, Kal; et.al. Professional XML Metadata. Wrox Press. 2001.
(BRAGANHOLO, 2001) BRAGANHOLO, V. Paula XML Schema, RDF(s) e UML:
Uma comparação. Disponível em <www.inf.ufrgs.br/~vanessa/artigos/ideas2001.pdf.>,
2001.
(BRAY, 1999) BRAY, Tim, HOLLANDER, Dave, LAYMAN Andrew. Namespaces in
XML. Textuality, Hewlett-Packard, and Microsoft. World Wide Web Consortium,
1999. Disponível em <http://www.w3.org/TR/REC-xml-names/, 1999>. Acessado em:
20 de abril de 2004.
(BRAY, 2004) BRAY, Tim, PAOLI, Jean, SPERBERG-MCQUEEN, C. M., MALER,
Eve, YERGEAU, François. Extensible Markup Language (XML) 1.0 (Third
Edition), W3C Recommendation 04 February 2004. Disponível em:
<http://www.w3.org/TR/2004/REC-xml-20040204/> Acessado em: 09 de fevereiro de
2004
(BRICKLEY, 2000) BRICKEY, D.; GUHA R. V. (eds.) Resouce Description
Framework (RDF) Schema specification 1.0 mar 2003. Disponivel em:
<http://www.w3.org/TR/2000/CR-rdf-schema-20000327/>, 2000.
(BROGDEN, 2002) BROGDEN, Bill, Chris Minnick. Guia de Desenvolvimento Javatm
Desenvolvendo E-Comerce com JAVA, XML e JSP. Makron Books, São Paulo 2002.
(CIUFFO, 2002) CIUFFO, L. N. Linguagens e ferramentas para a WEB Semântica.
Trabalho de Conclusão de Curso (Curso de Ciências da Computação). UFJF, Minas
Gerais, 2002.
(HALL, ?) HALL, MARTY SERVLETS and JAVASERVER PAGESTM. Versão online. Disponível em: <http://www.moreservlets.com/>. Acessado em: 26 de abril de
2004.
(HUNTER, 2002) HUNTER, Jason & CRAWFORD, Willian. JAVA servlet:
programação. Ciência Moderna, Rio de Janeiro 2002.
(JCP – JAVASERVER PAGES SPECIFICATION, 2003) JAVA COMMUNITY
PROCESS, JSR-000152 JavaServer PagesTM 2.0 Specification. Disponível em:
<http://jcp.org/aboutJava/communityprocess/first/jsr152/index3.htm> Acessado em: 20
de abril de 2004.
(JCP – SERVLET SPECIFICATION, 2003) JAVA COMMUNITY PROCESS, JSR000154
JavaTM
Servlet
2.4
Specification.
89
<http://jcp.org/aboutJava/communityprocess/final/jsr154/index.html> Acessado em: 26
de abril de 2004
(KIRK & PITTS-MOULTIS, 2000) KIRK, Cheryl, PITTS-MOULTIS, Natanya. XML –
Black Book. São Paulo: Makron Books, 2000.
(KUMIAWAN, 2002) KUMIAWAN, Budi Java para Web com Servlets, JSP E EJB.
Rio de Janeiro, Editora Moderna, 2002.
(LASSILA, 1999) LASSILA, O., SWICK, RALPH R. Resource Description Framework
(RDF) Model and Syntax Specification W3C Recommendation 22 February 1999.
Disponível em:<http://www.w3.org/TR/REC-rdf-syntax/> Acessado em: 23 de janeiro
de 2004
(LUSTOSA, 2003) LUSTOSA, Pollyane de Almeida. OWL e Protégé: estudo e
aplicação de conceitos
para definição de ontologias Disponível em:
<http://www.ulbra-to.br/ensino/43020/artigos/TCC2003/> Acessado em: 2 de julho de
2004.
(MANOLA, 2004) MANOLA, Frank, MILLER, Eric. RDF Primer, W3C
Recommendation
10
February
2004.
Disponível
em:
<http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#conceptsummary> Acessado
em: 12 de fevereiro de 2004
(MARINO, 2001) MARINO, M. TERESA. Integração de informações em ambientes
científicos na WEB: Uma abordagem baseada na arquitetura RDF. Disponível em
<ttp://genesis.nce.ufrj.br/dataware/Metadados/Teses/Teresa/pagina_tese.htm >, 2001.
Acessado em: 15 de maio de 2004.
(MCBRIDE, 2004) MCBRIDE, Brian. An Introduction to RDF and the Jena RDF API
Disponível em
<http://jena.sourceforge.net/tutorial/RDF_API/index.html>, 2001.
Acessado em: 18 de junho de 2004.
(NOLETO, 2003) NOLETO, Danilo de Abreu. Utilização da API JENA e do Padrão
RDF para a estruturação de um portal para manipulação de Imagens. Disponível
em:
<http://www.ulbra-to.br/ensino/43020/artigos/
TCC2003/TCC/Relatorio_Estagio_Danilo.pdf > Acessado em: 16 de junho de 2004.
(OLIVEIRA, 2001) Alcione de Paiva Oliveira, Apostila Servlet/JSP, Universidade
Federal
de
Viçosa
Disponível
em:
<http://inf.unisul.br/~osmarjr/download/apostilajava.html> Acessado em: 18 de abril de
2004
OWL, 2003) Owl Web Ontology Language Guide. Agosto de 2003. Disponível em:
<http://www.w3.org/TR/2003/CR-owl-guide-20030818/>. Acessado em:2 de julho de
2004.
(SEABORNE,2004) SEABORNE, HP Labs Bristol RDQL - A Query Language for
RDF W3C Member Submission 9 January 2004 Disponível em:
<http://www.w3.org/Submission/2004/SUBM-RDQL-20040109/> Acessado em: 4 de
julho de 2004
(LIMA, 2003) LIMA, Carlos Eduardo, SILVA, Edeilson Milhomem, SCHMITZ, Lucas
Roberto Bechert, BRITO, Parcilene Fernandes, FAGUNDES, Fabiano XML e JAVA
no Desenvolvimento de um Editor de Fórmulas do Cálculo de Predicados. 3º
Encontro de Estudantes de Informática do Estado do Tocantins, 2002
90
ANEXO
Relação de alguns métodos das classes que implementam os objetos pré-definidos
pela tecnologia JSP e suas respectivas descrições.
91
Tabela 8: Métodos da classe HttpServletRequest (BROGDEN, 2002)
Retorno
Stri
ng
long
Stri
ng
Método
getContextPath()
getDateHeader(String nome)
getHeader(String nome)
Descrição
Retorna parte do URI
O
valor
do
Retorna
getIntHeader(String nome)
de
o
valor
de
cabeçalho
de requisição especificado
Converte
int
cabeçalho
requisição na forma de data.
o
cabeçalho
de
requisição especificado em um
valor inteiro.
Stri
ng
Retorna o nome do método que
getMethod()
foi utilizado para requisição,
por exemplo: GET, POST.
Stri
ng
Retorna
getPathInfo()
quaisquer
informações
associadas a URL que o cliente
fez a requisição.
Stri
ng
getQueryString()
Retorna
a
Retorna
Stri
ng
getRequestURI()
querystring,
ou
seja, o endereço completo.
parte
específica
do
URL, desde o nome do protocolo
utilizado (HTTP, HTTPS) até o
nome da página.
Stri
ng
Retorna
getServletPath()
parte
requisição
do
URL
que
dessa
chama
o
servlet.
Retorna o nome do esquema de
autenticação utilização para a
Stri
ng
getAuthType()
segurança
do
exemplo:
“BASIC
servlet,
ou
“SSL”
por
ou
null caso o servlet não esteja
protegido.
É utilizado somente em sessões
Stri
ng
de
getRemoteUser()
autenticação.
invocado,
retorna
Quando
o
login
do
usuário, ou null, caso o mesmo
não tenha sido autenticao.
Retorna
Prin
cipal
getUserPrincipal()
um
objeto
java.security.Principal
contendo
o
nome
do
usuário
autenticado atual.
Cook
ie[]
getCockies()
Retorna
um
objetos
Cookie
vetor
contendo
que
o
os
cliente
enviou junto a sua requisição.
92
Stri
ng
Http
Session
getRequestSessionId()
Retorna
o
Retorna
getSession()
não
a
Http
da
sessão
haja
sessão
uma
atual,
sessão
caso
ela
é
criada automaticamente.
Retorna
Session
id
especificada pelo cliente.
a
sessão
atual.
Caso
não haja nenhuma sessão e, a
getSession(boolean criar)
variável passada por parâmetro
for
verdadeira,
uma
nova
sessão é criada.
bool
ean
isRequestSessionIdValid()
Verifica
se
o
id
da
sessão
requisitada ainda é válido.
Tabela 9: Métodos da classe HttpServletResponse (BROGDEN, 2002)
Retorno
void
Método
addCookie(Cookie cookie)
Descrição
Adiciona um cookie no navegador
do cliente.
Adiciona
void
addDateHeader(String nome, long date)
um
cabeçalho
de
resposta com o nome e a data
que
foram
passados
por
parâmetro.
void
bool
ean
setDateHeader(String String nome, long data)
Modifica tanto o nome quanto a
data do cabeçalho de resposta.
Retorna verdadeiro (true) caso
containsHeader(String nome)
o
cabeçalho
de
resposta
já
tenha sido definido.
Redireciona o cliente para uma
void
sendRedirect(String endereco)
página qualquer, de acordo com
o valor passado por parâmetro.
Codifica
Stri
ng
para
encodeRedirectURL(String url)
o
URL
uso
send_Redirect
necessário
especificado
no
ou,
a
método
se
não
for
codificação,
retorna o URL sem alteração.
Codifica
Stri
ng
o
URL
especificado
incluindo nele o ID da sessão,
encodeURL (String url)
ou
se
a
necessária
codificação
retorna
o
não
for
URL
sem
alteração.
void
void
sendError (int sc)
sendError(int sc, String msg)
Envia um código de erro http
para o cliente
Envia um código de erro com uma
mensagem descritiva.
93
Tabela 10: Métodos da classe JspWriter (BROGDEN, 2002)
Retorno
Método
void
clearBuffer()
void
close()
void
flush()
int
getBufferSize()
int
getRemaining()
void
newLine()
void
print(boolean b)
void
print(char c)
void
print(char[] s)
void
print(double d)
void
print(float f)
void
print(int i)
void
Print(java.lang.Object obj)
void
println()
Descrição
Apaga o conteúdo do buffer.
Fecha
o
fluxo,
esvaziando-o
primeiro.
Esvazia o fluxo.
Retorna
o
tamanho
atual
do
buffer.
Retorna o espaço não utilizado
no buffer.
inicia uma nova linha.
Imprime um valor booleano.
Imprime um caracter.
Imprime um vetor de caracteres.
Imprime
um
valor
do
tipo
double.
Imprime
um
valor
de
ponto
flutuante.
Imprime um inteiro.
Imprime um objeto.
Imprime uma string.
Tabela 11: Métodos da classe HttpSession (BROGDEN, 2002)
Retorno
Método
Descrição
Retorna o objeto com um nome
Obje
ct
getAttribute(String nome)
específico,
exista
ou
nenhum
null
caso
objeto
não
com
o
nome indicado.
Insere
void
setAttribute(String nome, Object obj)
o
específica
indicado.
objeto
a
sessão
com
o
nome
94
Retorna
Enum
eration
getAttributeNames()
um
String
todos
lista
contendo
os
de
os
objetos
objetos
nomes
de
anexados
a
sessão em questão.
void
removeAttribute(String nome)
long
getCreationTime()
long
getLastAccessedTime()
Remove da sessão o objeto de
acordo com o nome informado.
Retorna a hora de quando uma
sessão foi criada.
Retorna a última vez em que o
cliente enviou uma requisição
com essa sessão.
Especifica
o
tempo,
em
segundos, que a sessão ficará
void
setMaxInactiveInterval(int intervalo)
aberta
para
o
cliente,
sendo
que esse tempo é contabilizado
entre
o
intervalo
de
requisição e outra.
void
invalidate()
Invalida
uma
desvincula
quaisquer
sessão
e
objetos
pertencentes a ela.
Stri
ng
getId()
Retorna
o
identificado
da
sessão em questão.
Tabela 12: Métodos da classe ServletContext (BROGDEN, 2002)
Retorno
Objec
t
Método
void
void
setAttribute(String nome, Object obj)
Descrição
Retorna
um
atributo
indexado
por nome.
Remove o atributo do contexto
do servlet.
Liga
um
objeto
determinado
nome
a
de
um
atributo
neste contexto de servlets.
Strin
g
Strin
g
getRealPath(String caminho)
Retorna o caminho real para um
determinado caminho virtual.
Retorna o nome e a versão do
getServletInfo()
contentor
servlets
no
qual
a
servlet está sendo executada.
Retorna a versão principal da
int
getMajorVersion()
API
de
servlets
Java
que
contentor servlet suporta.
o
95
Tabela 13: Métodos da classe PageContext
Retorno
Método
Descrição
Retorna
o
associado
object
objeto
ao
passado
por
retorno
será
que
nome
está
que
foi
parâmetro.
O
null
o
caso
objeto não exista.
void
void
setAttribute(String nome, Object atributo)
Remove o objedo de acordo com
o nome informado.
Anexa o objeto em questão ao
escopo da página.
O
void
include(String caminho)
recurso
processado
especificado
com
parte
é
das
ServletRequest
e
ServletResponse atuais.
Reinicializa
void
release()
objeto
o
estado
PageContext
de
para
ele possa ser reutilizado.
um
que
96
APÊNDICE
Código utilizado na aplicação para a criação dos documentos RDF que descreverão
as imagens.
97
<%@ page
import="java.util.*,com.hp.hpl.mesa.rdf.jena.mem.ModelMem,com.hp.hpl.mesa.rdf.jena.model.
*,com.hp.hpl.mesa.rdf.jena.vocabulary.*,java.io.PrintWriter,java.io.*,EDRDF.*,com.hp.hpl.mes
a.rdf.jena.vocabulary.*,EDRDF.Imagem.vocabulario.Imagem"%>
<%@include file="include/noCache.jsp"%>
<%
String script = "<script language='javascript'>";
int op = Integer.parseInt(request.getParameter("tipo"));
HttpSession s = request.getSession(true);
s.setMaxInactiveInterval(2400);
String strTitulo=request.getParameter("txtTitulo");
String strDescricao=request.getParameter("txtDescricao");
String strData=request.getParameter("txtData");
String strCriador=request.getParameter("txtCriador");
String strTipoCurso;
String strCaminhoFisico = "documentos/jpeg/"+s.getAttribute("figura");
switch (op){
case 1:{
strTipoCurso="Graduacao";
String strNomeCurso = request.getParameter("selGraduacao");
String strAtividade = request.getParameter("selAtividadeCurso");
String strTipoPessoa=request.getParameter("selTipoAtividade");
String strCargo=request.getParameter("selCargo");
try{
//Cria na memória o novo documento RDF
Model objModelo = new ModelMem();
Resource rImagem = objModelo.createResource(Imagem.rImagem);
rImagem.addProperty(DC.title,strTitulo);
rImagem.addProperty(DC.creator,strCriador);
rImagem.addProperty(DC.date,strData);
if (!strDescricao.equals(""))
rImagem.addProperty(DC.description,strDescricao);
rImagem.addProperty(Imagem.pLocalFisico,strCaminhoFisico);
rImagem.addProperty(Imagem.pCurso,
objModelo.createResource(strNomeCurso)
.addProperty(Imagem.pAtividadeNoCurso,strAtividade)
.addProperty(Imagem.pTipoCurso,strTipoCurso)
.addProperty(Imagem.pPessoa,
objModelo.createResource()
98
.addProperty(Imagem.pTipoPessoa,strTipoPessoa)));
RDFWriter objWriter = objModelo.getWriter();
to.br/imagem/esquema#");
objWriter.setNsPrefix("Imagem", "http://www.ulbra-
Arquivo objArquivo = new Arquivo();
String
strIntermediario="C:/Sun/WebServer6.1/docs/foto/documentos/intermediario.rdf";
String strCaminhoDestinoOriginal;
String strCaminhoDestino =strCaminhoDestinoOriginal
="C:/Sun/WebServer6.1/docs/foto/documentos/rdf/curso/graduacao/"+strNomeCurso+"/pessoa/
";
int novo = objArquivo.pegarNovoArquivo(strCaminhoDestino);
String tmpCaminhoArquivoRDF =
"/foto/documentos/rdf/curso/graduacao/"+strNomeCurso+"/pessoa/Imagem_"+novo+".rdf";
s.setAttribute("novo_arquivo_rdf",tmpCaminhoArquivoRDF);
strCaminhoDestino+="Imagem_"+novo+".rdf";
//Insere propriedade no documento intermediário
Model objModeloIntermediario = new ModelMem();
if (objArquivo.verificarArquivoExiste(strIntermediario))
objModeloIntermediario =
objArquivo.carregarArquivo(strIntermediario);
Property pArquivo = objModeloIntermediario.createProperty("http://www.ulbrato.br/Imagem/intermediario/","arquivo");
objModeloIntermediario.createResource("curso/graduacao/"+strNomeCurso+"/pessoa").
addProperty(pArquivo,"imagem_"+objArquivo.pegarNovoArquivo(strCaminhoDestinoOriginal
)+".rdf");
//Cria novo arquivo com o documento intermdiário
objArquivo.gravarArquivo(strIntermediario,objModeloIntermediario);
//Cria novo arquivo com a descrição da imagem
objArquivo.gravarArquivo(strCaminhoDestino,objWriter,objModelo);
}
catch(Exception e){
System.out.println("Error: "+e);
}
break;
}// fim case 1
99
case 2: {
try{
.addProperty(Imagem.pTipoPessoa,strTipoPessoa)
.addProperty(Imagem.pCargo,strCargo)));
objWriter.setNsPrefix("Imagem", "http://www.ulbraArquivo objArquivo = new Arquivo();
String
";
100
objModeloIntermediario.createResource("curso/graduacao/"+strNomeCurso+"/pessoa")
.addProperty(pArquivo,"imagem_"+objArquivo.pegarNovoArquivo(strCaminhoDestino
Original)+".rdf");
}
}
}catch(Exception e){
break;
case 4: {
try{
String strFuncao=request.getParameter("selFuncao");
101
.addProperty(Imagem.pFuncao,strFuncao)));
String
";
objModeloIntermediario.createResource("curso/graduacao/"+strNomeCurso+"/pessoa").
addProperty(pArquivo,"imagem_"+objArquivo.pegarNovoArquivo(strCaminhoDestinoOriginal
)+".rdf");
}
102
catch(Exception e){
}
break;
}// fim case 4
case 5:{
String strEstruturaFisica = request.getParameter("selEstruturaFisica");
try{
.addProperty(Imagem.pEstruturaFisica,strEstruturaFisica));
objWriter.setNsPrefix("Imagem", "http://www.ulbra//código de impressão, temporário
String
="C:/Sun/WebServer6.1/docs/foto/documentos/rdf/curso/graduacao/"+strNomeCurso+"/estrutur
aFisica/";
103
"/foto/documentos/rdf/curso/graduacao/"+strNomeCurso+"/estruturaFisica/Imagem_"+novo+".r
df";
objModeloIntermediario.createResource("curso/graduacao/"+strNomeCurso+"/estrutura
Fisica").addProperty(pArquivo,"imagem_"+objArquivo.pegarNovoArquivo(strCaminhoDestino
Original)+".rdf");
}
catch(Exception e){
}
break;
}
case 6:{
strTipoCurso="pos-graduacao";
String strNomeCurso = request.getParameter("selPosGraduacao");
String strAtividade =
request.getParameter("selAtividadePosGraduacao");
String
strTipoPessoa=request.getParameter("selTipoAtividadePosGraduacao");
String strCargo=request.getParameter("selCargoPosGraduacao");
try{
104
.addProperty(Imagem.pTipoPessoa,strTipoPessoa)));
String
="C:/Sun/WebServer6.1/docs/foto/documentos/rdf/curso/posGraduacao/"+strNomeCurso+"/pes
soa/";
RDF gerado>
// Ccodigo temporario. Apeans para pegar o nome e caminho do arquivo
"/foto/documentos/rdf/curso/posGraduacao/"+strNomeCurso+"/pessoa/Imagem_"+novo+".rdf";
// Ccodigo temporario. Apeans para pegar o nome e caminho do
arquivo RDF gerado>
System.out.println(strCaminhoDestino);
objModeloIntermediario.createResource("curso/posGraduacao/"+strNomeCurso+"/pesso
a").addProperty(pArquivo,"imagem_"+objArquivo.pegarNovoArquivo(strCaminhoDestinoOrigi
nal)+".rdf");
105
}
catch(Exception e){
}
break;
}
case 7:{
String
String strCargo=request.getParameter("selCargoPosGraduacao");
try{
String
106
soa/";
nal)+".rdf");
}
catch(Exception e){
}
break;
}
case 9:{
String
String strFuncao=request.getParameter("selFuncaoPosGraduacao");
try{
107
rImagem.addProperty(DC.description,strDescricao)
.addProperty(Imagem.pFuncao,strFuncao)));
String
soa/";
nal)+".rdf");
108
}
catch(Exception e){
}
break;
}
case 10 : {
String strEstruturaFisica =
request.getParameter("selEstruturaFisicaPosGraduacao");
try{
String
109
="C:/Sun/WebServer6.1/docs/foto/documentos/rdf/curso/posGraduacao/"+strNomeCurso+"/estr
uturaFisica/";
"/foto/documentos/rdf/curso/posGraduacao/"+strNomeCurso+"/estruturaFisica/Imagem_"+novo
+".rdf";
objModeloIntermediario.createResource("curso/posGraduacao/"+strNomeCurso+"/estrut
uraFisica").addProperty(pArquivo,"imagem_"+objArquivo.pegarNovoArquivo(strCaminhoDest
inoOriginal)+".rdf");
}
catch(Exception e){
}
break;
}
case 11:{
String
strTipoPessoa=request.getParameter("selTipoAtividadeSetorAdministrativo");
String strCargo=request.getParameter("selCargoSetorAdministrativo");
try{
110
rImagem.addProperty(Imagem.pSetorAdministrativo,
objWriter.setNsPrefix("Imagem", "http://www.ulbra//código de impressão, temporário
String
="C:/Sun/WebServer6.1/docs/foto/documentos/rdf/setorAdm/pessoa/";
"/foto/documentos/rdf/setorAdm/pessoa/Imagem_"+novo+".rdf";
objModeloIntermediario.createResource("setorAdm/pessoa/").addProperty(pArquivo,"i
magem_"+objArquivo.pegarNovoArquivo(strCaminhoDestinoOriginal)+".rdf");
111
}
catch(Exception e){
}
break;
}
case 12:{
String strEstruturaFisica =
request.getParameter("selEstruturaFisicaSetorAdministrativo");
try{
rImagem.addProperty(Imagem.pSetorAdministrativo,
objWriter.setNsPrefix("Imagem", "http://www.ulbrato.br/imagem/esquema#");
String
="C:/Sun/WebServer6.1/docs/foto/documentos/rdf/setorAdm/estruturaFisica/";
"/foto/documentos/rdf/setorAdm/estruturaFisica/Imagem_"+novo+".rdf";
112
objModeloIntermediario.createResource("setorAdm/estruturaFisica").addProperty(pArq
uivo,"imagem_"+objArquivo.pegarNovoArquivo(strCaminhoDestinoOriginal)+".rdf");
}
}
catch(Exception e){
}
break;
}
default:{
break;
}
script += "alert('Imagem descrita com sucesso!');";
script += "</script>";
out.print(script);
%>

Desenvolvimento de um Sistema Utilizando a Tecnologia JSP para

Transcrição

Documentos relacionados

Recordes Superados na Competição

Internet do Futuro: aspectos de uma visão centrada no usuário

waste-to-power plant power plant waste to power plant power plant

João Paulo Andrade Almeida – Professor associado da

catalogação descritiva no século xxi: modelo funcional para

Enriquecimento de um Data Mart através de dados

Manipulação de dados abertos para construção de novas

ver/abrir - Repositório do Departamento de Ciência da Computação

Nova aba

Enfrentando os Desafios da Interoperabilidade Semântica de Dados