universidade luterana do brasil um pacote .net para manipulação de

UNIVERSIDADE LUTERANA DO BRASIL
CURSO DE CIÊNCIA DA COMPUTAÇÃO
CÂMPUS GRAVATAÍ
UM PACOTE .NET PARA
MANIPULAÇÃO DE RDF E RDF
SCHEMA SOBRE SGBD
Murilo Ramos Pereira
Monografia desenvolvida durante a disciplina de Trabalho
de Conclusão de Curso em Informática I e apresentada ao
Curso de Ciência da Computação da Universidade
Luterana do Brasil, câmpus Gravataí, como pré-requisito
para a obtenção do título de Bacharel em Ciência da
Computação.
Orientador: Prof. Msc. Carlos Morelli D. da Silveira
Gravataí, novembro de 2004.
2
Universidade Luterana do Brasil – ULBRA
Curso de Ciência da Computação – Câmpus Gravataí
Reitor:
Pastor Ruben Eugen Becker
Vice-Reitor:
Eng. Leandro Eugênio Becker
Diretor do Câmpus Gravataí:
Prof. Felício Korb
Coordenador do Curso de Ciência da Computação (Câmpus Gravataí):
Prof.ª Patrícia Nogueira Hübler.
Coordenador das Disciplinas de Trabalho de Conclusão de Curso (Câmpus Gravataí):
Prof. Roland Teodorowitsch
Banca Avaliadora composta por:
Data da defesa: 10/12/2004.
Prof. Carlos Morelli Dutra da Silveira (Orientador)
Prof.ª Patrícia Nogueira Hübler
Prof.ª Tanisi Pereira de Carvalho
Revisão Ortográfica: Prof.ª Patrícia Reis.
CIP – Catalogação na Publicação
Ramos Pereira, Murilo
Um pacote .Net para manipulação de RDF e RDF Schema sobre
SGBD / Murilo Ramos Pereira; [orientado por] Carlos Morelli Dutra
da Silveira. – Gravataí: 2004.
80 p.: il.
Trabalho de Conclusão de Curso (Graduação em Ciência da
Computação). Universidade Luterana do Brasil, 2004.
1. Banco de Dados. 2. Metadados. 3. RDF. I. Morelli Dutra da
Silveira, Carlos. II. Título.
Endereço:
Universidade Luterana do Brasil – Câmpus Gravataí
Estrada Itacolomi, 3.600 – Bairro São Vicente
CEP 94170-240 Gravataí-RS – Brasil
SUMÁRIO
LISTA DE FIGURAS .......................................................................................................... 6
LISTA DE QUADROS ........................................................................................................ 7
LISTA DE ABREVIATURAS E SIGLAS .......................................................................... 8
RESUMO ............................................................................................................................. 9
ABSTRACT ....................................................................................................................... 10
1 INTRODUÇÃO ............................................................................................................. 11
2 CONCEITOS ENVOLVIDOS...................................................................................... 13
2.1 RESOURCE DESCRIPTION FRAMEWORK (RDF) ......................................................... 13
2.1.1 Modelo Básico ................................................................................................ 13
2.1.2 Tripla e Grafo.................................................................................................. 14
2.1.3 Serialização em XML...................................................................................... 15
2.1.4 Tipos do Recurso............................................................................................. 16
2.1.5 Coleções.......................................................................................................... 17
2.1.6 Reificação ....................................................................................................... 18
2.2 RDF SCHEMA ......................................................................................................... 19
2.2.1 Classes ............................................................................................................ 19
2.2.2 Propriedades.................................................................................................... 20
2.2.3 Restrições........................................................................................................ 20
2.2.4 Documentação................................................................................................. 20
2.3 DUBLIN CORE ......................................................................................................... 22
2.4 ANALOGIA COM UML ............................................................................................. 23
3 RDF SOBRE SGBD RELACIONAL ........................................................................... 24
3.1 ANÁLISE ESTRUTURAL DE JENA E SESAME ............................................................... 24
3.1.1 Jena... .............................................................................................................. 25
3.1.2 Sesame ............................................................................................................ 26
3.1.3 Comparação entre Jena e Sesame..................................................................... 27
3.2 ENTIDATE RELACIONAMENTO (ER) VERSUS RDF .................................................... 28
3.2.1 Modelagem ER................................................................................................ 28
3.2.2 Modelagem RDF/XML ................................................................................... 28
3.2.3 Modelagem RDF persistida em SGBD ............................................................ 30
3.2.4 Mudança estrutural em ER e RDF ................................................................... 31
4 PACOTE DE PERSISTÊNCIA PARA RDF ............................................................... 33
4.1 TECNOLOGIAS ENVOLVIDAS .................................................................................... 33
4
4.1.1 DriveRDF........................................................................................................ 33
4.1.2 .Net Framework............................................................................................... 33
4.1.3 MSDE ............................................................................................................. 34
4.1.4 Rational Rose Data Modeler Edition................................................................ 34
4.2 MODELO DE DADOS ER PARA PERSISTÊNCIA ........................................................... 34
4.3 ARQUITETURA ........................................................................................................ 36
4.3.1 DriveRDF........................................................................................................ 37
4.3.1.1 IRdfParserFactory .................................................................................. 38
4.3.1.2 IRdfParser .............................................................................................. 38
4.3.1.3 IRdfGraph .............................................................................................. 38
4.3.2 RDFPackage.................................................................................................... 38
4.3.2.1 RDFs...................................................................................................... 38
4.3.3 RDFPersistence ............................................................................................... 40
4.3.3.1 Class ...................................................................................................... 40
4.3.3.2 Domain .................................................................................................. 40
4.3.3.3 Literals ................................................................................................... 40
4.3.3.4 Namespaces............................................................................................ 41
4.3.3.5 Property.................................................................................................. 41
4.3.3.6 Range ..................................................................................................... 41
4.3.3.7 Resources ............................................................................................... 41
4.3.3.8 SubClassOf ............................................................................................ 42
4.3.3.9 SubPropertyOf........................................................................................ 42
4.3.3.10 Triples .................................................................................................... 42
4.3.4 RDFDatabases................................................................................................. 43
4.3.4.1 DBAccess............................................................................................... 43
4.3.4.2 DBConfig............................................................................................... 43
4.3.4.3 DBException.......................................................................................... 44
4.3.4.4 DBSequences ......................................................................................... 45
4.3.4.5 DBSqls................................................................................................... 46
4.3.5 RDFModels ..................................................................................................... 46
4.3.6 RDFQuery....................................................................................................... 46
4.3.6.1 Query ..................................................................................................... 47
4.4 ESCOPO................................................................................................................... 47
5 Caso de Uso e Outras Aplicações .................................................................................. 48
5.1 CASO DE USO .......................................................................................................... 48
5.1.1 RDFModels ..................................................................................................... 49
5.1.1.1 Models ................................................................................................... 50
5.1.2 Aplicação de Administração de Modelos ......................................................... 50
5.2 OUTRAS APLICAÇÕES .............................................................................................. 53
6 CONCLUSÃO ............................................................................................................... 55
ANEXO A – FORMATOS DE URI SCHEMAS .............................................................. 57
ANEXO B – EXEMPLO DE DECLARAÇÃO RDF ........................................................ 58
ANEXO C – RDF SCHEMA QUE DEFINE O MODELO RDF ..................................... 59
ANEXO D – VOCABULÁRIO DO RDF SCHEMA ........................................................ 61
ANEXO E – RDF SCHEMA SIMPLIFICADO DO PADRÃO DUBLIN CORE ........... 63
ANEXO E – GRAFO RDF COM CINCO RECURSOS .................................................. 67
5
ANEXO F – DOCUMENTAÇÃO DE CLASSES DO DRIVERDF................................. 68
ANEXO G – PROJETOS DE PERSISTÊNCIA DE RDF ............................................... 69
ANEXO H – DIAGRAMAS DE SEQÜÊNCIA DO COMPONENTE RDFPACKAGE 72
ANEXO I – DIAGRAMAS DE SEQÜÊNCIA DO COMPONENTE
RDFPERSISTENCE ..................................................................................................... 74
ANEXO J – DIAGRAMAS DE SEQÜÊNCIA DO COMPONENTE RDFDATABASES
RELACIONADOS A MULTI-BANCO ....................................................................... 77
REFERÊNCIAS................................................................................................................. 79
LISTA DE FIGURAS
Figura 1 – Representação de recurso por grafo, notação conceitual da tripla e QNames........ 14
Figura 2 – Serialização em XML de uma declaração RDF.................................................... 15
Figura 3 – Serialização em XML abreviada de uma declaração RDF.................................... 16
Figura 4 – Declaração RDF/XML utilizando XMLBase ....................................................... 16
Figura 4 – Definição de tipos de um recurso em RDF........................................................... 16
Figura 5 – Grafo que representa um container alternative ..................................................... 17
Figura 6 – Grafo que representa uma collection.................................................................... 18
Figura 6 – Reificação de um statement RDF......................................................................... 19
Figura 7 – Restrição de propriedade através de RDF Schema ............................................... 21
Figura 8 – Exemplo de RDFS representado com Qnames..................................................... 21
Figura 9 – Declaração Dublin Core da documentação do pacote .Net ................................... 22
Figura 10 – Modelo físico de dados do Jena ......................................................................... 26
Figura 11 – Modelo físico de dados do Sesame .................................................................... 27
Figura 12 – Exemplo de Modelagem ER tradicional............................................................. 28
Figura 13 – Modelagem utilizando RDFSchema .................................................................. 29
Figura 14 – Exemplo de declaração baseada num schema .................................................... 30
Figura 15 – Exemplo de Persistência de RDF no modelo relacional ..................................... 30
Figura 16 – Modelo de dados ER alterado ............................................................................ 31
Figura 17 – Alteração de RDF Schema................................................................................. 32
Figura 18 – Modelagem RDF utilizando flexibilidade dos metadados .................................. 32
Figura 19 – Modelo de dados do pacote .Net de persistência ................................................ 35
Figura 20 – Arquitetura do Pacote de Persistência para RDF ................................................ 36
Figura 21 – Exemplo de configuração do banco de dados do pacote..................................... 44
Figura 22 – RDF Schema que define os modelos de dados ................................................... 49
Figura 23 – Inclusão dos namespaces do pacote de persistência no projeto........................... 51
Figura 24 – Exemplo de importação de schema utilizando o pacote de persistência.............. 51
Figura 24 – Interface inicial do aplicativo de administração dos modelos ............................. 52
Figura 25 – Exemplo de utilização da classe Query .............................................................. 52
Figura 26 – Tela de edição do aplicativo de administração dos modelos............................... 52
Figura 27 – Exemplo de utilização da classe Models ............................................................ 53
Figura 28 – Tela de listagem dos recursos do modelo de dados ............................................ 53
7
LISTA DE QUADROS
Quadro 1 – Analogia entre RDF Schema e UML ................................................................. 23
Quadro 2 – Métodos de armazenamento da classe RDFs ...................................................... 39
Quadro 3 – Métodos de exclusão da classe RDFs................................................................. 39
Quadro 4 – Métodos de persistência da classe Class............................................................. 40
Quadro 5 – Métodos de persistência da classe Domain......................................................... 40
Quadro 6 – Métodos de persistência da classe Literals ......................................................... 41
Quadro 7 – Métodos de persistência da classe Namespaces.................................................. 41
Quadro 8 – Métodos de persistência da classe Property........................................................ 41
Quadro 9 – Métodos de persistência da classe Range ........................................................... 41
Quadro 10 – Métodos de persistência da classe Resources ................................................... 42
Quadro 11 – Métodos de persistência da classe SubClassOf................................................. 42
Quadro 12 – Métodos de persistência da classe SubPropertyOf ............................................ 42
Quadro 13 – Métodos de persistência da classe Triples ........................................................ 43
Quadro 14 – Métodos de abstração da classe DBAccess....................................................... 43
Quadro 15 – Métodos da classe DBConfig........................................................................... 44
Quadro 16 – Métodos da classe DBException ...................................................................... 45
Quadro 17 – Métodos da classe DBSequences ..................................................................... 46
Quadro 18 – Métodos da classe DBSqls ............................................................................... 46
Quadro 19 – Métodos da classe Query ................................................................................. 47
Quadro 20 – Métodos da classe Models ............................................................................... 50
LISTA DE ABREVIATURAS E SIGLAS
HTML
MSDE
RDF
RDFS
RDMS
SGBD
SGML
UML
URI
W3C
XML
XSLT
Hyper Text Markup Language
Microsoft Database Engine
Resource Description Framework
Resource Description Framework Schema Specification
Relational Database Management Systems
Sistema Gerenciador de Banco de Dados
Standard Generalized Markup Language
Unified Modeling Language
Uniform Resoucer Identifier
World Wide Web Consorium
eXtensible Markup Language
eXtensible Stylesheet Language Transformations
RESUMO
Esta monografia apresenta uma proposta de arquitetura para um pacote .Net de
persistência de RDF e RDF Schema, que definem um padrão para representação e
manipulação de dados e metadados estruturados e semi-estruturados, sobre um Sistema
Gerenciador de Banco de Dados (SGBD). Sua arquitetura foi projetada baseada na análise
realizada nos principais frameworks de persistência de RDF sobre banco de dados (Jena e
Sesame), com objetivo de utilizar as melhores práticas de persistência e garantir a
confiabilidade do pacote. Seu desenvolvimento foi realizado em C#, possuindo total
compatibilidade com qualquer aplicação .Net e projetado para suportar futuramente diversos
bancos de dados. São apresentados os conceitos envolvidos, alguns exemplos que justificam a
utilização desta tecnologia, vantagens e desvantagens, bem como algumas sugestões de
trabalhos futuros que poderão permitir a expansão deste pacote.
Palavras-chaves: Banco de dados; Metadados; RDF.
ABSTRACT
Title: “Manipulation Package .Net for RDF and RDF Schema on RDMS”
The main goal of this monograph is present the architecture proposal for RDF and
RDF Schema persistence, which define a standard, to represent and manipulate structured
and semi-structured data and metadata to allow the RDF persistence on Relational Database
Management Systems (RDMS). Its projected architecture was based on the analysis through
in main RDF database persistence frameworks (Jena and Sesame), the objective use best of
persistence practical and to the package guarantee. Development in C#, possessing
compatibility with any .Net application and to future support future for databases diverse. It
also demonstrates the reasons justify implementation, advantages and disadvantages, as well
future works suggestions for package expansion.
Key-words: Database; Metadata; RDF.
11
1 INTRODUÇÃO
A grande utilização de sistemas por toda a sociedade e a dependência cada vez maior
da informática em todas as áreas geram uma constante preocupação com o armazenamento
estruturado de dados, devido a importância da informação nos dias de hoje. Existem várias
pesquisas neste sentido, que exploram estruturas em que os dados geram informações sobre si
próprios em que sua semântica e identificação também são dados, tornando mais flexível e
produtivo o gerenciamento da informação.
Com base no cenário descrito anteriormente, surge a necessidade da utilização de
novos modelos estruturais de armazenamento. Este trabalho descreve o Resource Description
Framework (RDF), um padrão criado pela World Wide Web Consorium (W3C), que
possibilita a criação de modelos semânticos para dados e metadados estruturados e semiestruturados. O modelo básico de RDF é baseado e representado na eXtensible Markup
Language (XML).
O processo de manipulação de um grande volume declarações RDF em XML pode se
tornar lento e fragmentado, desta forma são necessárias outras técnicas para criação de
repositórios de dados representados no formato RDF. A utilização da tecnologia de Banco de
Dados Relacional para armazenar declarações RDF é uma alternativa que aumenta a
performance em seu acesso e manutenção (Zanete, 2001), sendo a persistência de RDF em
Sistema Gerenciador de Banco de Dados (SGBD) relacional o foco principal deste trabalho.
•
•
•
•
•
•
•
Como principais objetivos destacam-se os seguintes itens:
Estudar os conceitos de RDF e RDF Schema;
Realizar uma análise das abordagens de mapeamento de dados RDF em banco de dados
relacional existentes e escolher uma delas, com algumas adaptações (se necessário), para
modelagem e desenvolvimento deste pacote;
Criar uma camada de classes para manipulação de RDFs, de forma genérica, podendo ser
reutilizado por aplicações desenvolvidas na plataforma .Net e que necessitem deste
suporte, funcionando como uma camada de persistência dos dados no banco relacional;
Desenvolver e disponibilizar classes de acesso a um banco específico para manipulação
deste formato, inicialmente utilizando Microsoft Database Engine (MSDE);
Disponibilizar alguns métodos estáticos ao usuário, de forma que seja possível realizar
consultas previamente definidas sobre os dados armazenados. Tendo em vista que este
trabalho não visa o desenvolvimento de uma linguagem de consulta sobre os dados;
Desenvolver uma espécie de gerenciador dos modelos RDF armazenados, de forma que o
usuário tenha facilidade em sua manipulação;
Criar uma pequena aplicação em .Net para demonstrar a funcionalidade das classes
desenvolvidas, possibilitando a manutenção dos dados RDF.
12
Como motivação para estes desenvolvimentos é possível eleger alguns pontos de
destaque que justificam esta implementação:
• Já existem implementações neste sentido na linguagem Java, mas nenhuma foi
desenvolvida em .Net e com código fonte aberto;
• A disponibilidade deste pacote de classes facilitará e dará suporte a construção de
aplicações e gerência de repositórios de dados de maneira flexível;
• O armazenamento de RDF em SGBD será provavelmente utilizado no futuro, visto que
muita informação neste formato já se encontra na internet, mas de forma pulverizada,
podendo se tornar uma solução simples para troca de dados entre fontes heterogêneas;
• RDF possui componentes capazes de modelar praticamente qualquer tipo de informação
(W3C, 2003).
Esta documento está organizado como descrito a seguir.
O segundo capítulo tem o objetivo de realizar uma revisão teórica sobre os principais
conceitos de RDF e RDF Schema.
O terceiro capítulo tem o objetivo de justificar a necessidade de realizar a persistência
de RDF e RDF Schema em SGBD e demonstrar alguns importantes benefícios da utilização
destas tecnologias. Também descreve a análise que foi realizada sobre os modelos de dados
das duas principais tecnologias que realizam a persistência de RDF e RDF Schema em banco
de dados relacional.
O quarto capítulo descreve as tecnologias que serão utilizadas para o desenvolvimento
do pacote de persistência de RDF, bem como realiza as definições técnicas envolvidas na
implementação deste trabalho.
O quinto capítulo é dedicado a uma aplicação exemplo, que utiliza os métodos de
persistência do pacote, demonstrando seu funcionamento e a indicação de alguns casos de uso
possíveis.
O sexto capítulo apresenta as conclusões do desenvolvimento deste trabalho e algumas
possibilidades que permitam a expansão do pacote.
Buscando uma padronização dos exemplos práticos descritos neste trabalho procurouse manter um único contexto, com o objetivo de facilitar o entendimento dos conceitos
técnicos envolvidos. Todos os exemplos estão voltados a uma realidade hospitalar, contendo
dados do próprio hospital, paciente, internações, recepções, altas e etc.
2 CONCEITOS ENVOLVIDOS
Este capítulo realiza uma revisão teórica dos conceitos e tecnologias envolvidas para
viabilizar a persistência de RDF em banco de dados relacional. O propósito é expor as
informações técnicas sobre o assunto para que haja nivelamento de conhecimento e
posteriormente um melhor entendimento dos objetivos e motivações que justificam o
desenvolvimento deste trabalho.
2.1
RESOURCE DESCRIPTION FRAMEWORK (RDF)
O Resource Description Framework (RDF) foi criado sob a influência de várias
comunidades que estão diretamente ligadas a catalogação e organização das informações de
sítios disponíveis na rede mundial de computadores, com o objetivo de padronizar e facilitar a
interoperabilidade das informações entre aplicações, otimizando os mecanismos de busca.
Atualmente é uma tecnologia normalizada pelo W3C, sendo um modelo destaque entre as
ontologias utilizadas na comunidade computacional. Ontologias são basicamente formas de
representação do conhecimento que utilizam vocabulários próprios e permitem definir a
semântica dos dados.
O RDF é uma infra-estrutura que possibilita a codificação, troca e reuso de metadado
estruturado. Metadados são dados sobre dados com o objetivo de auxiliar na identificação,
descrição e localização de recursos (Zanete, 2001). Pode ser utilizado por aplicações onde a
própria estrutura, não só os próprios dados, é manipulada pela aplicação, ou quando a
estrutura de dados é alterada com freqüência.
2.1.1
•
•
Modelo Básico
O modelo básico é composto pelos seguintes componentes:
Recursos: tudo que possa ser identificado como um Uniform Resoucer Identifier (URI)
como, por exemplo, uma página da internet ou qualquer informação de um documento que
não esteja necessariamente disponibilizado na internet. Podendo estar ligado à sua forma
de aplicação ou formato de representação, conforme definido pelo padrão de URI
Schemas listados no Anexo A (W3C). Dessa forma cria-se uma certa ligação entre o
conceito lógico e o físico, levando em consideração a tecnologia de representação do
recurso. Toda declaração RDF é por si só um recurso, considerando que ela pode ser
identificada como um URI e fazer parte de uma outra declaração. Existe somente um URI
para indicação do recurso, o que define uma chave única de localização da informação;
Propriedades: representam os atributos do recurso a serem descritos ou até mesmo
definem relacionamento entre os recursos. Neste sentido, existe uma certa semelhança
14
•
•
com o modelo de Entidade-Relacionamento, uma propriedade em relação a ER seria um
relacionamento entre entidades.
Objetos: são os valores definidos para determinada propriedade em relação a um recurso.
Podem ser definidos por recursos ou literais, tipados ou não.
Literais: representam valores constantes que podem obedecer a um conjunto definido por
tipos de dados. Os tipos de dados estão diretamente ligados aos tipos primários de XML e
eXtensible Stylesheet Language Transformations (XSLT), inclusive a marcação de
linguagem para indicar o idioma do valor em questão (W3C, 2001).
2.1.2
Tripla e Grafo
A construção mais básica que compõe um modelo de dados estrutural em RDF é
definida na forma de uma tripla composta de propriedade, recurso e valor de uma
propriedade. A notação (propriedade,[recurso],[valor]) pode ser utilizada para representação
de uma tripla. Também é possível representar de forma simplificada através de Qnames
(W3C, 1999), facilitando sua interpretação.
A tripla é um mecanismo muito eficiente, uma vez que permite que recursos e valores
sejam relacionados, ou seja, qualquer recurso pode atuar no papel de valor, o que garante uma
grande flexibilidade ao modelo para representação de estruturas com uma complexidade
elevada.
Apesar de dar suporte a formação de estruturas complexas, a tripla, possui uma fácil
compreensão por parte de seres humanos ou até mesmo pela simplicidade de sua estrutura e
relacionamento das informações.
Além do formato de tripla, o modelo RDF pode ser visto num formato de grafo,
formado por nós conectados por arcos rotulados. Por definição, os elipses representam os
recursos, os arcos representam as propriedades dos recursos e como convencionado pelo W3C
os literais são representados como retângulo para que seja diferenciado facilmente. A Figura 1
refere-se a um exemplo de recurso, definido no modelo RDF, na forma de grafo e uma
definição através da notação conceitual da tripla.
Figura 1 – Representação de recurso por grafo, notação conceitual da tripla e QNames
É importante enfatizar que o recurso “Henrique Oliveira”, demonstrado na figura
anterior possui uma URI associada que serve com identificação exclusiva, já o literal
“30/04/2004” é definido por um valor constante, ou seja, não possui nenhuma identificação
exclusiva ou URI associada. Na notação simplificada ou Qnames são utilizados prefixos que
indicam quais namespaces pertencem a cada recurso, neste caso o prefixo ex refere-se a um
namespace exemplo.
15
2.1.3
Serialização em XML
A declaração de RDF é representada através de XML, referenciada através de
RDF/XML, auxiliando na portabilidade dos dados RDF entre diferentes plataformas,
aplicativos ou sistemas (W3C, 2003), como importante colaboradora para expansão do
framework conceitual e abstrato de RDF. A escolha da linguagem de marcação XML possui
características que agregam na representação de conhecimento, nas mais diversas formas.
Como principais benefícios da utilização de XML destacam-se:
• Aplicabilidade consagrada na internet pela simplicidade e interoperabilidade de dados;
• Possui namespaces que o RDF utiliza para definição de escopos de dados distintos,
auxiliando na organização e clareza das declarações, possibilitando a criação de junção de
metadados com padrões diferentes num mesmo documento;
• Compatibilidade com Hyper Text Markup Language (HTML) e Standard Generalized
Markup Language (SGML) o que aumenta a portabilidade do modelo;
• Documentação ampla sobre o assunto e diversas ferramentas comerciais e até mesmo
acadêmicas, para manipulação de dados codificados em XML.
Um documento definido no modelo RDF possui namespaces que são padronizados
através do termo xmlns, seguido de seu nome e URI. Nas declarações RDF são utilizados dois
namespaces básicos: o rdf que contém as definições do modelo RDF básico e rdfs que contém
as definições do RDF Schema. A próxima seção deste documento descreve as características
de RDF Schema.
Existem duas sintaxes para codificação em XML das declarações do modelo RDF,
serialização em XML e serialização em XML abreviada; Porém, não existe nenhuma restrição
quanto a representação de nenhuma estrutura de dados entre as codificações. Ou seja, o que
pode ser representado através de uma codificação também pode ser representado pela outra
sem qualquer perda. O que diferencia uma da outra é a forma de codificação das declarações.
A primeira, serialização em XML, representa o modelo completo com todos os
componentes pertencentes ao modelo. A Figura 2 representa a serialização em XML de uma
declaração RDF.
Figura 2 – Serialização em XML de uma declaração RDF
A segunda sintaxe para codificação, serialização em XML abreviada, representa de
forma compacta o modelo, utilizando atributos adicionais e agrupando os dados para
descrever subconjuntos do modelo de dados, reduzindo o número de marcadores utilizados
para representação. A Figura 3 representa uma serialização abreviada em XML de uma
declaração RDF.
16
Figura 3 – Serialização em XML abreviada de uma declaração RDF
O modelo RDF utiliza um recurso do XML chamado XMLBase que permite definir
um namespace base ou padrão para todos os recursos que possuem a indicação rdf:ID. Desta
forma é possível definir uma declaração de forma reduzida e legível, sem a necessidade de
colocar o URI completo a cada definição de recursos que utilizam o namespace principal do
contexto. A Figura 4 demonstra a declaração RDF/XML da Figura 3 alterada para utilização
de XMLBase.
Figura 4 – Declaração RDF/XML utilizando XMLBase
2.1.4
Tipos do Recurso
Além dos componentes básicos, descritos anteriormente, o modelo de dados RDF
provê outras primitivas importantes que auxiliam na qualificação do recurso a ser descrito. A
primitiva rdf:type é destacada pela função de identificar a que grupo de informações o recurso
pertence. Além disso, este mecanismo possibilita descrever num mesmo documento
informações sobre os dados e metadados através de uma instanciação dos elementos em
questão, tornando cada vez mais flexível o modelo. A Figura 4 demonstra a definição de tipos
de um recurso em RDF.
Figura 4 – Definição de tipos de um recurso em RDF
A definição de tipos de recurso é muito utilizada pelo conceito de RDF Schema,
indicando que o recurso em questão foi definido através de um esquema qualquer. Conforme
a Figura 4, o recurso “Henrique Oliveira” está definido através do esquema “paciente”,
17
definido pelo URI “www.clientes/esquema#paciente”, que possui um vocabulário que rege a
criação do recurso.
2.1.5
Coleções
Eventualmente uma mesma tripla pode ser montada com diversos objetos, ou até
mesmo o objeto em questão se trata de um grupo, lista ou conjunto de objetos. Para definir
este conceito o modelo de dados RDF suporta a declaração de três tipos básicos de coleções
ou containers de dados, de acordo com a necessidade e algumas características específicas do
conjunto quando a ordenação e repetição. Os tipos são definidos da seguinte forma:
• Bag: representa uma lista não ordenada de recursos ou literais e aceita repetição de
valores;
• Sequence: representa um lista ordenada de valores e aceita repetição de valores;
• Alternative: representa uma lista ordenada de valores e não aceita repetição de valores.
Qualquer um dos tipos de agrupamento pode ser representado no formato de grafo
como toda declaração RDF. Como exemplo de alternative, a Figura 5 representa um
container RDF neste formato.
Figura 5 – Grafo que representa um container alternative
Além dos containers existe um outro conceito de agrupamento semelhante em RDF,
que se chama collection, porém com algumas diferenças na forma de representação.
Com a utilização do collection é possível representar um tipo de lista definida sobre
listas, contendo definições de cabeça e calda (first e rest), realizando um encadeamento entre
recursos. O encadeamento e os elementos da lista possuem uma semântica definida no próprio
formato de tripla RDF e marcadores específicos que identificam os componentes básicos da
lista. A Figura 6 demonstra um grafo com um exemplo de collection.
18
Figura 6 – Grafo que representa uma collection
Note que, quando a lista não possui mais nenhum componente como calda, o modelo
permite a definição de fim de lista através da indicação do valor rdfs:nil para o componente
que indica o resto.
2.1.6
Reificação
Uma das mais importantes características do modelo é a possibilidade de uma
manipulação eficiente de metadados através do conceito de reificação, que consiste na
aproximação de níveis diferentes de abstração de dados em um nível comum, proporcionando
o aninhamento de descrições. Com a reificação é possível considerar qualquer statement RDF
como um recurso. Na prática, é uma representação de um recurso, anônimo ou não, com no
mínimo quatro propriedades. O recurso anônimo é aquele definido apenas dentro do
documento ou declaração de origem e não possui uma URI própria que o referencie, ou seja, é
uma definição lógica da declaração e não um recurso físico.
•
•
•
•
As quatro propriedades básicas são definidas pelo modelo como listadas a seguir:
Subject: indica o recurso descrito pela declaração modelada, ou seja, a origem da
declaração;
Predicate: indica a propriedade original na declaração modelada;
Object: é o valor da propriedade na declaração modelada;
Type: descreve o tipo do novo recurso.
Qualquer tripla pode ser representada utilizando tais propriedades. Se um recurso é
relativo a uma tripla, o respectivo recurso poderá ser referenciado como de tipo statement
como qualquer outro recurso, ou seja, possuem uma propriedade de tipagem cujo o objeto é
rdf:statement. A Figura 6 demonstra um exemplo de reificação de um statement RDF.
19
Figura 6 – Reificação de um statement RDF
Um exemplo mais completo de uma declaração RDF pode ser consultado no Anexo B.
2.2
RDF SCHEMA
O Resource Description Framework Schema Specification (RDFS) é uma linguagem
de especificação de esquemas que serve como complemento ao modelo RDF básico. Seu
objetivo é alcançar a interoperabilidade semântica de dados num universo heterogêneo. Sua
estrutura é composta por vocabulários que definem os esquemas à serem seguidos para a
declaração dos dados. Podem ser comparados aos esquemas utilizados nos bancos de dados
que servem para garantir, entre outros pontos, a compatibilidade e confiabilidade dos dados
através de regras pré-definidas.
A utilização de namespaces para este tipo de declaração serve para que não haja
conflito entre camadas de classes distintas e também para organização das regras estipuladas.
Um exemplo disso pode ser a especificação de uma propriedade “Nome” que deve aparecer
em dois contextos distintos.
Os vocabulários definem recursos e propriedades em um sistema com uma
interessante tipagem de dados, semelhante a linguagens de programação orientada a objetos,
de acordo com as especificações do modelo RDF. As linguagens e metodologias de
modelagem de dados são voltadas para representação das estruturas através da identificação
das entidades que serão apresentadas como classes e subclasses. Já o mecanismo de RDF
Schema define as propriedades em termos das classes de recursos aos quais elas se aplicam,
alterando um pouco esta visão (Zanete, 2001).
A descrição dos vocabulários em RDF Schema conta com quatro componentes
principais que são classificados como classes, propriedades, restrições e documentação.
2.2.1
Classes
As classes permitem a definição de herança entre classes e subclasses, tornando-se um
mecanismo de herança múltipla do modelo. Essa componente proporciona uma grande
extensibilidade do modelo através do uso, reuso e compartilhamento destes esquemas. É
fundamental para prática de aproveitamento de metadados complexos. Para tornar possível o
descrito anteriormente este mecanismo conta com algumas primitivas de definição de classes
para estruturar o esquema. São elas:
20
•
•
•
rdfs:Resource – classe genérica do modelo ou classe mãe. Toda e qualquer entidade
descrita por expressões RDF é considerada um recurso;
rdfs:Class – é subclasse de rdfs:Resource e representa a generalização de tipo ou
categoria, equivalente ao conceito de classes da orientação a objetos;
rdf:Property - é subclasse de rdfs:Resource e representa uma característica do recurso,
equivalente ao conceito de atributo da orientação a objetos.
2.2.2
Propriedades
As propriedades representam o relacionamento entre as classes, superclasses,
instâncias das classes ou até mesmo com propriedades, criando uma estrutura de hierarquia de
propriedades. As primitivas das propriedades são:
• rdf:type – é subclasse de rdf:Property e representa que um recurso é instância de uma ou
mais classes, possuindo todos os seus atributos;
• rdfs:subClassOf – é subclasse de rdf:Property e representa uma relação de subconjunto
e/ou super conjunto entre classes. É a principal responsável pela herança múltipla, devido
a sua característica transitiva;
• rdfs:subPropertyOf – é subclasse de rdf:Property e representa o relacionamento entre
duas propriedades, sendo fundamental para a definição da hierarquia de propriedades;
• rdfs:isDefinedBy – indica qual recurso contém todas as informações de definição do
recurso em questão.
2.2.3
Restrições
As restrições permitem acrescentar associações de restrição junto as propriedades de
um recurso específico. Utiliza as seguintes primitivas:
• rdfs:domain – indica as classes que uma determinada propriedade é válida ou aplicada.
Deve ser utilizado se a propriedade for restrita a classe apontada. Se vários domains são
definidos para uma mesma propriedade, o recurso que possui a propriedade deve pertencer
a todos os domains apontados. Se nenhum domain for definido, qualquer classe pode
conter esta propriedade;
• rdfs:range - define quais classes podem dar valores a uma determinada propriedade, ou
seja, restringe a valoração da propriedade. Quando não é definido para uma propriedade,
assume-se que o valor válido é literal.
2.2.4
Documentação
A documentação é o recurso que dá suporte à documentação ou anotações do modelo
RDF, porém é bem simples e limitada. Suas primitivas são:
• rdfs:comment - marcador que possibilita a inserção de um comentário no modelo.
• rdfs:label – possibilita a inclusão de um nome auxiliar para um recurso. Normalmente
utilizado para facilitar na legibilidade de recursos muito complexos.
• rdfs:seeAlso – é subclasse de rdf:Property. Faz a indicação a um recurso que pode ter
mais informações sobre o recurso em questão, sendo muito útil quando se trata de
definições de subclasses ou subpropriedades. Também é caracterizado como
documentação, apesar de ser valorado por um recurso.
21
É possível definir juntamente com as primitivas de documentação a marcação de
linguagem que indica o idioma da informação.
É importante salientar que RDF Schema contempla apenas relações binárias entre
recursos e propriedades. Restrições de cardinalidade associadas aos relacionamentos não são
contempladas pelo mecanismo.
Para exemplificar, a Figura 7 demonstra uma definição simples de uma restrição de
propriedades através de RDF Schema, onde está definido que para a classe
“PrescricaoMedica”, a propriedade “prescritaPor” somente pode receber valores de “Medico”.
Utilizando a linguagem natural a definição poderia ser definida pela seguinte sentença:
“somente os médicos podem prescrever uma prescrição médica”.
Figura 7 – Restrição de propriedade através de RDF Schema
A Figura 8 exemplifica a notação simplificada ou QNames utilizando um exemplo
baseado num RDFS.
Figura 8 – Exemplo de RDFS representado com Qnames
Neste exemplo de schema representado com a notação simplificada utiliza-se prefixos
que identificam os namespaces de cada componente do modelo. Os prefixos “rdf” e “rdfs”,
representam os namespaces do modelo RDF e RDFS respectivamente. Já o prefixo “ex” esta
relacionado ao namespace do exemplo em questão. Neste caso são definidos os seguintes
componentes:
• Classes
- “ex:Medicamento rdf:type rdfs:Class.”: define que “ex:Medicamento” é do
tipo “rdfs:Class”;
- “ex:Paciente rdf:type rdfs:Class.” : define que “ex:Paciente” é do tipo
“rdfs:Class”;
• Propriedades
- “ex:Recebe rdf:type rdf:Property.”: define que “ex:Recebe” é do tipo
“rdf:Property”;
- “ex:Idade rdf:type rdf:Property.”: define que “ex:Idade” é do tipo
“rdf:Property”;
• Domain
22
•
“ex:Recebe rdfs:domain ex:Paciente.”: define que a propriedade “ex:Recebe”
é válida para a classe “ex:Paciente”;
“ex:Idade rdfs:domain ex:Paciente.”: indica que a propriedade “ex:Idade” é
válida para a classe “ex:Paciente”;
Range
-
“ex:Recebe rdfs:range ex:Medicamento.”: define que os valores válidos para
a propriedade “ex:Recebe” são somente os da classe “ex:Medicamento”;
Como não foi definido nenhum range para a propriedade “ex:Idade” deve-se
assumir “rdf:XMLLiteral”.
O Anexo C possui a definição completa do RDF Schema que define o modelo RDF e,
por sua vez, o Anexo D define o vocabulário utilizado pelo RDF Schema.
2.3
DUBLIN CORE
Um dos primeiros exemplos de RDF Schema foi o Dublin Core, um padrão de
metadados com a finalidade de catalogação de documentos na internet. Foi idealizado pela
comunidade biblioteconômica e permite uma classificação otimizada de qualquer tipo de
documento.
Foi elaborado utilizando como definição um modelo RDFS e acabou tornando-se um
dos mais conhecidos padrões de catalogação da atualidade, por sua qualidade e abrangência,
auxiliando na expansão do modelo RDF. O próprio RDFS utiliza alguns elementos deste
padrão para sua identificação, o que indica a importância do padrão para este modelo.
•
•
•
Os principais elementos do padrão estão organizados da seguinte forma:
Caracterização do conteúdo: Title, Subject, Description, Type, Source, Relation,
Coverage;
Caracterização da instância: Date, Format, Identifier, Language;
Caracterização da propriedade intelectual: Creator, Contributor, Publisher, Rigths.
A Figura 9 demonstra uma declaração dublin core da documentação do pacote
desenvolvido neste trabalho.
Figura 9 – Declaração Dublin Core da documentação do pacote .Net
O Anexo E possui a definição do RDFS simplificado do padrão Dublin Core para
ilustrar os elementos em sua forma original.
23
2.4
ANALOGIA COM UML
É possível realizar uma analogia dos componentes do modelo RDF Schema com
alguns conceitos envolvidos na Unified Modeling Language (UML). É importante ressaltar
que esta analogia serve somente como auxílio ao aprendizado, não possuindo nenhuma
ligação direta com os conceitos desta tecnologia e possibilitando traçar um paralelo entre os
conceitos apresentados anteriormente. O Quadro 1 demonstra a analogia que pode ser feita
entre os componentes RDF Schema e os conceitos UML (Santos, 2002).
Quadro 1 – Analogia entre RDF Schema e UML
RDF
UML
Class
Classe
Property
Atributo
(não definido)
Tipos de Atributo
Range
Domínio
Todos os atributos são públicos
Visibilidade de atributos
Property + Range
Associação
Property (bag ou sequence)
Composição
Property + Range
Agregação
SubClassOf
Generalização
SubPropertyOf
(não definido)
SubClassOf
Herança Múltipla
(não definido)
Cardinalidade Mínima
(não definido)
Cardinalidade Máxima
(não definido)
Classe Abstrata
Descrições sobre recursos
Instância
Namespace
Pacote
O Anexo F demonstra um grafo RDF contendo cinco recursos. Neste exemplo, é
definida a raiz de uma árvore genealógica utilizando alguns dos conceitos vistos
anteriormente.
24
3 RDF SOBRE SGBD RELACIONAL
O armazenamento confiável e organizado de dados é fundamental para qualquer
sistema de informação da atualidade. Uma estrutura de dados bem definida auxilia na redução
de tempo no desenvolvimento de sistemas, bem como em futuras manutenções ou expansões.
Considerando que RDF modela praticamente qualquer tipo de informação (W3C, 2003) e
proporciona uma flexibilidade muito grande na manutenção de estruturas de dados, conclui-se
que este modelo possui características que podem auxiliar na otimização do processo de
construção, manutenção e evolução de sistemas.
Atualmente os aplicativos estão praticamente “presos” ao modelo de dados, ou seja, a
cada novo requisito que necessite de alguma alteração, em uma estrutura já existente ou até
mesmo a criação de uma nova, é necessária a intervenção humana para tal. Com a criação de
um repositório de RDFS sobre SGBD é possível realizar toda a manipulação de modelo de
dados diretamente pela aplicação, considerando que ele também é dado armazenado no
modelo, tornando muito mais eficiente esta atualização. Isso é possível porque no banco de
dados existe somente a estrutura contendo as entidades (tabelas) do modelo RDFS e não
entidades como “paciente”, por exemplo. Ou seja, todas as entidades do modelo entidaderelacionamento são consideradas como metadados definidos por um RDF Schema, e são
facilmente manipulados pela aplicação como se fossem dados comuns.
A persistência de dados e metadados no formato RDF em um modelo relacional
proporciona vantagens importantes em sua manipulação, pois o acesso e modificação de um
grande volume de declarações RDF em XML podem se tornar lentas e fragmentadas, havendo
necessidade de otimizações para obter um melhor desempenho. A utilização da tecnologia de
Banco de Dados Relacional para armazenar declarações RDF é uma alternativa que aumenta a
performance em seu acesso e manutenção (Zanete, 2001), utilizando recursos otimizados do
próprio SGBD. Esta proposta combina tecnologias de banco de dados, consagradas
mundialmente, com a inovação e a flexibilidade proposta pelo modelo RDF.
Existem diversos projetos que definem inúmeras formas de persistência de RDF sobre
Banco de Dados Relacional, conforme descrito no Anexo G. Porém para o desenvolvimentos
deste trabalho foram analisados os dois principais frameworks de persistência existentes, os
quais serão descritos na próxima seção deste trabalho.
3.1
ANÁLISE ESTRUTURAL DE JENA E SESAME
Este seção é dedicada à documentação da análise realizada sobre o framework Jena e
Sesame, com o objetivo de mapear as diferenças entre os modelos de dados, tendo condições
de definir qual o modelo mais consistente, ou seja, o modelo que melhor se enquadra à
25
realidade proposta por este trabalho. Além disso, é também objetivo verificar também qual
proposta de cada modelo para a persistência e quais técnicas são mais eficientes para uma
persistência segura de documentos RDF em banco de dados relacional.
3.1.1
Jena
O framework Jena foi projetado para possibilitar a manipulação de diversas ontologias
da internet, e tem o objetivo de representar o conhecimento de forma semântica, dentre elas o
modelo RDF. Este projeto foi desenvolvido por Brian McBride, juntamente com a HP,
usufruindo de pacotes implementados anteriormente em outros projetos que possuíam
contextos semelhantes a este, adicionando novas implementações. Deste cenário, surgiu a API
Jena desenvolvida em Java. O Jena possui um pacote de classes que dá suporte total a criação
e manipulação de documentos RDF, os quais são representadas de maneira genérica por
recursos, propriedades e literais.
Algumas características importantes do pacote de manipulação de RDF do Jena são
listadas a seguir:
• Módulo de armazenamento persistente sobre o banco de dados. Atualmente dá suporte a
Oracle, MySql e PostgreSQL;
• Métodos de declarações e recursos centrais que permitem a manipulação de um modelo
RDF como um conjunto de triplas RDF. Possui um conjunto de recursos com
propriedades respectivamente;
• Possibilidade de expansão devido a implementação de uma arquitetura aberta;
• Possui uma linguagem de consulta;
• Utiliza parsers integrados;
• Suporte a containers e a extensão de recursos.
O modelo físico de dados utilizado pelo Jena trabalha basicamente com o conceito de
triplas para armazenamento dos dados. Deste modo, o sistema utiliza prefixos internos para
identificação de cada um dos componentes dos modelos suportados pelo framework, tendo em
vista que não possui um estrutura física que permita o armazenamento normalizado de cada
informação. Através destes prefixos, são criados identificadores para cada dado,
possibilitando a criação do encadeamento lógico dos dados a partir dos próprios dados. É
importante salientar que a estrutura foi modelada desta forma, para obter uma maior
abrangência aos diferentes formatos de ontologias suportadas pelo Jena, além do suporte ao
modelo RDF. Esta estrutura proporciona flexibilidade para inclusão de novas tecnologias ao
projeto e por outro lado, dificulta a persistência devido a necessidade da localização de cada
prefixo para cada inclusão ou alteração de dados no modelo físico. A Figura 10 demonstra o
modelo físico dos dados utilizados pelo Jena.
26
Figura 10 – Modelo físico de dados do Jena
O modelo físico de dados é gerado automaticamente a partir da execução do
framework Jena. O processo de geração automática do modelo não cria nenhuma chave
estrangeira entre as tabelas. Por este motivo, não existe nenhum relacionamento representado
na Figura 10.
3.1.2
Sesame
O Sesame foi desenvolvido inicialmente pelo projeto do OntoKnowledge, mas em
conjunto com as empresas Aidministrator e OntoText, com o objetivo de criar uma arquitetura
genérica para armazenamento e consulta de RDF e RDF Schema em banco de dados
relacional. Foi um projeto desenvolvido em Java com suporte a MySql e PostgreSQL. Além
da estrutura de dados modelada para proporcionar compatibilidade total com RDFS, o Sesame
está se voltando para uma arquitetura que permita o armazenamento de outras ontologias e
algumas técnicas de armazenamento de dados de serviços remotos através da internet.
Atualmente utiliza técnicas que aumentam a performance de acesso às informações e tem uma
grande preocupação quanto à incorporação de primitivas transacionais em sua implementação.
Algumas características importantes do pacote de manipulação de RDF do Sesame são
listadas a seguir:
• Módulo de armazenamento persistente sobre o banco de dados;
• Utiliza uma API de manipulação de RDF;
• Expansão contínua através de diversas pesquisas;
• Possui uma linguagem de consulta sobre os dados;
• Suporte a containers e a extensão de recursos;
• Arquitetura modular e voltada à performance de consulta.
O modelo físico dos dados utilizado pelo SESAME é bem detalhado, voltado
especificamente para armazenamento de RDF e RDF Schema. Todos os componentes do
modelo RDF estão contemplados nesta estrutura de forma normalizada, tornando mais
eficiente o gerenciamento dos dados. A Figura 11 demonstra o modelo físico dos dados
utilizados pelo Sesame.
27
Figura 11 – Modelo físico de dados do Sesame
O modelo físico de dados do Sesame possui as constraints físicas do banco que
garantem a confiabilidade das informações que estão sendo armazenados.
3.1.3
Comparação entre Jena e Sesame
Para definição do modelo de dados implementado neste trabalho, foi realizado um
trabalho de análise que buscou fazer o mapeamento das diferenças entre os modelos existentes
no framework Jena e Sesame. O objetivo é identificar qual a melhor estrutura ou até mesmo
criar um modelo que agrupe as melhores características entre ambos, caso haja necessidade.
Avaliando as características de Jena e Sesame é possível identificar grandes diferenças
entre os modelos de dados. Este fato está diretamente relacionado a abrangência de cada
tecnologia.
O Jena não é uma implementação específica para manipulação de RDF, necessitando
de uma grande flexibilidade de dados para persistir diversas ontologias. Por este motivo,
possui uma estrutura de dados simplista, baseada no conceito de tripla. Utiliza prefixos que
identificam os componentes de cada ontologia, totalmente baseado no conceito de metadados.
O Sesame é uma implementação específica para manipulação de RDF que possui uma
estrutura de dados mais elaborada, totalmente de acordo com as características do modelo
RDF. Utiliza constraints do próprio banco que garantem um armazenamento consistente dos
dados. Para isso, não são utilizados metadados ou qualquer tipo de prefixo agregado às
28
informações do RDF para possibilitar a persistência, pois todos os componentes do modelo
são entidades presentes no modelo de dados.
Avaliando todas as vantagens e desvantagens de cada tecnologia, chega-se à conclusão
que o modelo mais consistente e que apresenta as características estruturais mas alinhadas ao
objetivo deste trabalho é o do Sesame. Portanto este modelo de dados foi utilizado para
armazenar os dados persistidos por este pacote.
3.2
ENTIDATE RELACIONAMENTO (ER) VERSUS RDF
Para ilustrar melhor a diferença entre uma modelagem de dados realizada através do
modelo ER e a proposta pelo RDF, esta seção demonstra um exemplo prático que permita
realizar a comparação entre as duas abordagens.
3.2.1
Modelagem ER
A modelagem ER é amplamente utilizada no mercado para armazenamento de dados.
Nessa abordagem define-se cada entidade de forma independente e cria-se diversas relações
entre entidades. Dependendo da situação é permitida a geração de entidades auxiliares para
que o relacionamento torne-se normalizado, ou seja, entidades que representam
relacionamento.
Figura 12 – Exemplo de Modelagem ER tradicional
Com a finalidade de exemplificar uma modelagem ER, a Figura 12 demonstra como
ficaria armazenada, no modelo relacional tradicional, a informação da declaração RDF da
Figura 2. Nesta representação são geradas quatro entidades: “Hospital”, “Paciente”,
“Hospital_Paciente” e “Internação”. Cada entidade possui seus atributos e um identificador
principal que é utilizado como chave para criação de um relações com outras entidades. A
entidade “Hospital_Paciente” é utilizada para representar a relação entre “Hospital” e
“Paciente”, tendo em vista que um paciente pode ser atendido em diversos hospitais. Este por
sua vez está relacionado com a entidade “Internação”, o que representa que a internação foi
realizada para um paciente e hospital específico.
3.2.2
Modelagem RDF/XML
A modelagem RDF/XML é representada através da linguagem XML. Nessa
abordagem é necessário mapear todos os requisitos do problema e representá-los utilizando os
componentes do modelo RDF. Deve-se também definir um contexto para os dados através de
29
namespaces e URI’s de identificação de cada recurso envolvido. Logo após, deve ser definido
o schema que definem a estrutura dos dados e, por fim, fazer a representação dos dados
propriamente ditos (baseado no schema). Como exemplo, a Figura 13 demonstra como seria a
definição de um RDFS equivalente a estrutura do modelo ER descrito na Figura 12.
Figura 13 – Modelagem utilizando RDFSchema
Este schema define as classes “Hospital”, “Paciente” e “Internação”. A propriedade da
classe “Hospital” é definida como “Nome_Hospital”. A classe “Paciente” possui a
propriedade “Nome_Paciente”. A classe “Internacao” possui as propriedades
“Data_Internacao”, “Paciente_Internacao” e “Hospital_Internacao”. É importante salientar
que a propriedade “Paciente_Internacao” somente aceita os valores oriundos da classe
“Paciente” e a propriedade “Hospital_Internacao” somente aceita os valores oriundos da
classe “Hospital”, e isso viabiliza a relacionamento correto das informações.
Depois dessa definição, é possível criar uma declaração RDF baseada no schema,
totalmente voltado à realidade proposta. A Figura 14 demonstra um exemplo de uma
declaração RDF baseado no schema, carregando somente parte dos componentes definidos.
30
Figura 14 – Exemplo de declaração baseada num schema
No exemplo anterior são declaradas as informações baseado no exemplo da Figura 2.
3.2.3
Modelagem RDF persistida em SGBD
Na modelagem de dados RDF em Banco de Dados Relacional é possível definir
diversas estruturas como metadados e armazenar diversos tipos de dados sem a necessidade
de alterar o modelo físico de armazenamento. Para que isso seja possível, utiliza-se um
modelo de dados relacional que contemple os componentes do modelo RDF. Para este
exemplo, está sendo utilizado o modelo de dados do Sesame.
Com a finalidade de exemplificar a persistência de RDF no modelo de dados, a Figura
15 demonstra como ficaria a persistência da declaração RDF da Figura 2 num modelo de
dados relacional. Neste exemplo, está sendo utilizado um modelo de dados resumido e não
estão sendo declaradas as entidades de schema. Somente são representadas as entidades
equivalentes aos da modelagem ER anterior, porém, deve-se considerar que o schema da
seção 3.2.2.1 está persistido neste modelo.
Figura 15 – Exemplo de Persistência de RDF no modelo relacional
Nesta persistência estão envolvidos três recursos, dois namespaces, uma tripla, um
literal e uma propriedade. Cada recurso possui obrigatoriamente um namespace. Todos os
componentes da declaração são persistidos como recurso. A classificação de cada recurso é
especializada quando o identificador do recurso é inserido numa tabela de especialização,
neste caso “Property” e “Literal”. A tripla da declaração também é armazenada fisicamente no
modelo, onde as chaves de sujeito, predicado e objeto são identificadores de recurso. A tripla
possui um identificador único para auxiliar em sua manipulação.
31
É importante salientar que dados, metadados e tipagens são tratados como recurso, ou
seja, estão armazenados na mesma estrutura. Este técnica permite a expansão estrutural dos
dados e schemas de forma otimizada, sem que haja qualquer alteração no modelo relacional.
3.2.4
Mudança estrutural em ER e RDF
Esta seção pretende demonstrar algumas diferenças na expansão do modelo de dados
do negócio através destas duas técnicas de modelagem de dados.
Considerando o contexto dos exemplos anteriores, pode-se supor que haja a
necessidade de aumentar o número de informações sobre a internação do paciente. Seria
interessante ter a armazenada a data da “Alta do paciente”. Neste caso existe a necessidade de
fazer uma adaptação no modelo de dados para armazenar esta informação.
O modelo de dados exemplo da Figura 12 não suporta o armazenamento da
informação de “Alta”. É necessário criar uma nova entidade chamada “Alta” para permitir o
armazenamento destes dados. A Figura 16 exibe como ficaria o modelo de dados anterior com
a adaptação para a informação de “Alta”.
Figura 16 – Modelo de dados ER alterado
Nota-se que a nova entidade “Alta” possui o atributo “Data” e está relacionado à
internação do paciente. Qualquer nova informação que venha ser necessária gera um trabalho
de reestruturação física no modelo de dados, refletindo diretamente na estrutura da aplicação e
no tempo de desenvolvimento do recurso.
Para realizar a mesma alteração na modelagem RDF/XML deve-se acrescentar a
definição demonstrada na Figura 17 no schema da Figura 13. Essa definição cria a classe
“Alta” e as propriedades “Data_Alta” e “Alta_Internacao”. É importante salientar que a
propriedade “Alta_Internacao” somente aceita os valores oriundos da classe “Internacao”.
Isso viabiliza a informação que indica que uma “Alta” possui uma “Internacao” associada.
32
Figura 17 – Alteração de RDF Schema
A mesma alteração pode ser realizada na modelagem RDF sobre SGBD, dando
suporte a esta nova informação. A Figura 18 exibe como estaria persistida a informação na
modelagem RDF apenas utilizando metadados.
Figura 18 – Modelagem RDF utilizando flexibilidade dos metadados
Nesta modelagem não foi necessária nenhuma alteração no modelo físico dos dados.
Apenas foram criados novos recursos que indicam a “Alta” como metadado e “Property”,
indicando o novo atributo. Além disso foram incluídas a data de alta do paciente como
“Literal” e a “Triple 101” que gera o relacionamento entre o recurso, propriedade e valor.
Tudo isso agregado aos dados do modelo anterior.
Portanto, a modelagem utilizando os componentes RDF no modelo relacional torna
mais flexível qualquer adaptação no modelo de dados da aplicação, gerando o menor impacto
possível e eliminando adaptações no modelo de dados e alterações na camada de persistência.
4 PACOTE DE PERSISTÊNCIA PARA RDF
Este capítulo é dedicado a descrição das principais tecnologias envolvidas no processo
de criação do Pacote .Net para manipulação de RDF e RDF Schema sobre SGBD, bem como
a definição técnica dos conceitos e funcionalidades disponibilizadas por este pacote.
4.1
TECNOLOGIAS ENVOLVIDAS
Com o objetivo de realizar a persistência e manipulação de declarações RDF
SGBD Relacional, foram realizadas diversas pesquisas de tecnologia para auxiliar
processo de definição, análise, estruturação e elaboração dos conceitos envolvidos.
tecnologias com maior aderência ao assunto foram escolhidas para auxiliar
desenvolvimento deste trabalho, são elas:
• DriveRDF: Parser RDF para a plataforma .Net;
• .Net Framework: Plataforma de desenvolvimento;
• MSDE: Banco de dados;
• Rational Rose Data Modeler Edition
4.1.1
em
no
As
no
DriveRDF
É um parser RDF para a plataforma .Net que possui os componentes necessários para
validação e manipulação de RDF e RDF Schema. Além disso, o DriveRDF é uma ferramenta
homologada pelo W3C e desenvolvida em C#, uma linguagem de programação orientada a
objetos, criada para desenvolvimento .Net.
Como este trabalho não visa a criação de um parser RDF o DriveRDF tem um papel
importante na validação sintática do modelo RDF e no reconhecimento dos componentes da
declaração RDF. Portanto o pacote utiliza a estrutura de dados armazenada pelo DriveRDF,
em memória, após leitura e validação do documento RDF e realizará a persistência dos
documentos no banco de dados escolhido.
O conjunto de classes disponíveis pelo DriveRDF estão dispostas no Anexo F.
4.1.2
.Net Framework
Não existe até o momento nenhuma implementação conhecida desenvolvida em .Net e
que possua código fonte aberto, que realize a persistência de declarações RDF em banco de
dados. Portanto, a escolha da linguagem de desenvolvimento para este trabalho, levou em
34
consideração este fato e também a característica de trabalhar com uma tecnologia inovadora
de desenvolvimento.
O .Net Framework é uma tecnologia que possui um ambiente de desenvolvimento
multi-plataforma, multi-linguagens, multi-dispositivos e que dá suporte total à orientação a
objetos, além de conter uma biblioteca de classes muito rica (CORPORATION, 2004). É uma
plataforma de desenvolvimento similar à plataforma de desenvolvimento Java, ao comparar
seus conceitos e propostas.
O desenvolvimento deste pacote será realizado na linguagem C#, totalmente integrado
com o DriveRDF. Também será utilizada a linguagem ASP.NET para a criação da aplicação
de administração dos modelos de dados que serão disponibilizadas ao usuário.
4.1.3
MSDE
O MSDE foi escolhido como banco de dados para utilização deste desenvolvimento
por possuir um driver nativo para .Net, tornando confiável a comunicação entre o banco de
dados e o pacote. Outro benefício é contar com uma tecnologia robusta, utilizadas por grandes
corporações, com ferramentas que auxiliam no gerenciamento de dados e estruturas.
Possui praticamente todas as características do SGBD Relacional Microsoft
SQLServer, porém é freeware e, como restrição, admite apenas cinco conexões simultâneas
ao banco de dados. A limitação de conexões simultâneas não chega a afetar o
desenvolvimento deste pacote, tendo em vista que não será necessário utilizar múltiplas
conexões ativas para homologar a funcionalidade proposta por este trabalho.
4.1.4
Rational Rose Data Modeler Edition
Para realizar a modelagem dos componentes desenvolvidos neste trabalho foi utilizado
o software Rational Rose Data Modeler Edition que proporciona um bom suporte a
documentação no padrão UML. Nesta ferramenta foram desenvolvidos os principais
diagramas de seqüência, entidade relacionamento, componente e modelagem das principais
classes e interface. O objetivo é detalhar os principais processos envolvidos e promover uma
boa documentação técnica sobre o assunto.
4.2
MODELO DE DADOS ER PARA PERSISTÊNCIA
Após análise realizada nos principais frameworks de persistência de RDF sobre Banco
de Dados Relacional (Jena e Sesame), foi selecionado o modelo utilizado pelo Sesame.
Conforme descrido na seção 3.1.3.
Durante o desenvolvimento do pacote de persistência, foi disponibilizada uma nova
versão do Sesame com modificações importantes no modelo de dados utilizado. Este novo
modelo modifica a estrutura de armazenamento, tornando a entidade “Recurso” ainda mais
importante, onde praticamente todas as chaves das tabelas envolvidas são chaves estrangeiras
para a tabela de recurso.
A utilização do modelo de dados, proposto pela nova versão do Sesame, tornou mais
simples a persistência das declarações, pois a centralização no recurso de todos os
componentes, diminui o processamento e otimiza a execução do pacote. Para definir os
35
demais componentes do modelo são utilizadas tabelas adicionais, contendo somente as
chaves, diminuindo inclusive o volume de dados a ser persistido.
Foram realizadas algumas alterações no modelo de dados original para implementação
deste pacote. Basicamente foram incluídas todas as constraints, de forma física, no banco de
dados; pois, após a utilização do framework Sesame em alguns testes, existiam constraints
que não haviam sido geradas e, como não foram encontradas nenhuma justificativa para tal,
optou-se pela criação das mesmas para garantir confiabilidade da persistência. Também foi
adicionada a tabela “Sequences”, que serve para armazenar os identificadores, que são
utilizados pelo pacote, para geração dos identificadores requeridos na persistências de alguns
componentes do modelo.
A Figura 19 demonstra o modelo de dados completo do pacote .Net de persistência de
RDF e RDF Schema proposto por este pacote.
Figura 19 – Modelo de dados do pacote .Net de persistência
A entidade “Recurso” é o mais importante componente do modelo. Todos os dados
são considerados recursos. Cada recurso possui um “Namespace” que funciona como um
agrupador de dados homogêneos. Os recursos podem ser especializados como “Property”,
“Class”, “Triples” ou “Literals”. A especialização das propriedades é realizada através da
entidade “SubPropertyOf”, onde são definidas sub-propriedades e super-propriedades. A
36
especialização das classes é realizada através da entidade “SubClassOf”, onde são definidas
sub-classes e super-classes. As entidades “Domain” e “Range” definem relações entre as
classes e propriedades. A entidade “Sequences” armazena os próximos identificadores dos
componentes “Resources” e “Namespaces”. Uma característica interessante do modelo
proposto é a distribuição de chaves pelo modelo de dados para realizar o armazenamento da
informação, mantendo centralizado os dados e metadados, apenas utilizando os conceitos de
RDFS para caracterizar cada componente.
De acordo com a teoria do modelo RDF triplas não representadas físicamente e literais
não seriam recursos; porém, este modelo utiliza este artifício para centralizar todos os
componentes e evitar a geração de múltiplas seqüências que poderiam tornar mais complexa a
estrutura do modelo.
Algumas particulartidades importantes sobre a implementação da persistência de cada
componente do modelo estão descritas nas próximas seções deste documento juntamente com
as especificações técnicas deste pacote.
4.3
ARQUITETURA
O Pacote de persistência para RDF é uma proposta de arquitetura para persistência de
declarações RDF em SGBD. Este Pacote poderá ser utilizado por qualquer aplicação
desenvolvida em .Net, pois sua estrutura é totalmente independente da aplicação. Outra
característica importante se dá ao fato que a implementação foi baseada em diversas camadas,
proporcionando uma grande flexibilidade na manutenção e suporte à expansão para outros
bancos de dados, pois a classe de acesso e execução é desenvolvida de forma independente de
banco, sem que haja qualquer impacto na aplicação ou demais camadas do pacote.
A implementação deste pacote de classes foi realizada em C# e, inicialmente,
disponibiliza o suporte ao Microsoft Database Engine (MSDE). Sua arquitetura está dividida
em seis componente principais, são eles: DriveRDF, RDFPackage, RDFPersistence,
RDFModels, RDFQuery e RDFDatabases. A Figura 20 demonstra o diagrama de
componentes UML para um melhor entendimento da arquitetura do pacote de forma geral.
Figura 20 – Arquitetura do Pacote de Persistência para RDF
37
Uma descrição funcional informal da arquitetura descrita anteriormente seria
basicamente a seguinte:
• No processo de persistência de declarações RDF, a aplicação .Net utiliza a interface
RDFInterface para acessar os métodos de persistências e consultas aos dados e schemas
armazenados. Essa interface faz parte do componente RDFPackage, responsável pelo
gerenciamento e execução de todos os componentes do pacote. O componente
RDFPackage, por sua vez, utiliza as interfaces do parser Drive para fazer a validação da
declaração. Somente podem ser persistidas declarações válidas; caso contrário, o processo
é abortado.
• Primeiramente, é criado um objeto que implementa a interface IRdfParserFactory. Este
objeto possui um método que retorna um objeto que implementa a interface IRdfParser.
Esta por sua vez possui um método que valida a declaração, retornando outro objeto que
implementa a interface IRdfGraph, possuindo o resultado da validação e todos os nodos
do RDF estruturados em memória. Este objeto é utilizado pelo componente RDFPackage,
executando um método do objeto IRdfGraph que retorna todas as triplas da declaração;
• Depois disso ocorre uma navegação em todas as triplas da declaração, que estão em
memória pelo componente RDFPackage. À medida que os componentes do modelo vão
sendo reconhecidos, são realizadas as chamadas de métodos disponibilizados pelo
componente RDFPersistence, armazenando as declarações. Este possui uma abstração de
todos os componentes do RDF e gera SQLs padrão para realizar a persistência.
• Através da interface IRdfDatabases, o RDFPersistence chama métodos que devem
persistir todos os componentes do modelo. O RDFDatabases possui métodos para criação
de conexões, execuções, exceções e até mesmo as modificações sobre os SQLs padrão são
realizadas neste componente. Este componente também é responsável pelo isolamento da
aplicação e banco de dados.
• Os modelos de dados, implementados por este pacote, são semelhantes ao conceito
utilizado no modelo ER. Ou seja, são conjuntos de dados que possuem a mesma
semântica, podendo estar ligados a tempo, à visão ou à regra de negócio. Esta
funcionalidade é disponibilizada pelo pacote atráves do componente RDFModels, que é
definido na seção 5.1. (Por ser uma funcionalidade agregada ao pacote de persistência está
definido num capítulo à parte).
• O componente RDFQuery disponibiliza alguns métodos estáticos que possibilitam a
leitura dos dados persistidos, utilizando diversos recursos estruturais desenvolvidos neste
pacote.
Os Anexos G, H, I e J descrevem alguns diagramas relacionados aos processos de
persistência descritos anteriormente. As principais regras e particularidades de implementação
de cada componente estão descritas nas próximas seções.
4.3.1
DriveRDF
Como descrito na seção 4.1.1, o parser DriveRDF será responsável pela validação
sintática do modelo RDF e reconhecimento de cada componente do documento RDF. Foi
implementada uma forte integração com o componente RDFPackage, dando a visibilidade
necessária para obter as informações que devem ser persistidas no banco de dados ou até
mesmo informando algum erro que tenha sido encontrado na declaração. O único componente
que integra com o DriveRDF é o RDFPackage. Para isso são utilizadas três interfaces para
comunicação do pacote de persitência com o parser.
38
4.3.1.1
IRdfParserFactory
Uma instância da classe RdfParserFactory implementa a interface IRdfParserFactory.
Em seu método construtor, todos os controles do parser RDF são ativados, bem como os
atributos de validação setados. Após essa inicialização, é possível obter uma instância do
objeto RDFParser, através do método “GetRdfXmlParser()”.
4.3.1.2
IRdfParser
Uma instância da classe RdfParser implementa a interface IRdfParser, possibilitando
validar uma declaração RDF através do método “ParseRdf()”, passando como parâmetro uma
URI de declaração válida. O retorno deste método é um objeto chamado RdfGraph, que
contém todos os componentes do RDF definidos na declaração dispostos em memória. Porém,
esse objeto é retornado somente quando a declaração é válida, caso contrário, o retorno é nulo
e a própria instância de RdfParser possui uma estrutura que armazena os erros e/ou alertas
encontrados pelo parser em caso de declaração incompleta ou inválida. Neste caso, a
persistência é abortada evitando que algum dado incorreto comprometa a confiabilidade da
informação.
4.3.1.3
IRdfGraph
A instância da classe RdfGraph implementa a interface IRdfGraph. Este objeto possui
estrururas em memória com todos os componentes do RDF e RDFS, inclusive uma estrutura
contendo todas as triplas declaradas. Um ponto positivo da utilização do DriveRdf foi quanto
a padronização estrutural dos dados disponibilizados pelo parser, apesar das diferentes
sintaxes para realizar uma declaração RDF (referenciadas no capítulo 2), permitindo que a
implementação da persistência trabalhasse apenas com a persistência de cada componente e
eliminando certas diferenças que poderiam gerar incoerências nos dados persistidos.
4.3.2
RDFPackage
O componente de negócio RDFPackage é um dos mais importantes deste pacote de
persistência, pois realiza a integração com o DriveRDF, controla a execução de todos os
outros componentes e ainda disponibiliza diversos métodos de acesso e manipulação às
declarações persistidas pelo pacote por qualquer aplicação externa através de interfaces. São
utilizadas interfaces com o objetivo de tornar transparente para as aplicações toda e qualquer
alteração que venha a ser necessária a algum componente do pacote.
4.3.2.1
RDFs
Esta classe define todos os métodos disponíveis pelo pacote de persistência. Em sua
construção são instanciados todos os objetos de persistência e os necessários para integração
com o DriveRdf. As demais funcionalidades vão sendo solicitadas por demanda dependendo
da funcionalidade. Todos os métodos desta classe relacionados a seguir são disponibilizados
pela interface chamada RDFInterface.
O Quadro 2 demonstra todos os métodos disponíveis pela classe RDFs e sua descrição
de funcionalidade.
39
Quadro 2 – Métodos de armazenamento da classe RDFs
Nome do Método
Descrição da funcionalidade
Executa o método de persistência da Class e seu respectivo
PostClass
recurso.
Executa o método de persistência do Domain.
PostDomain
Executa o método de persistência do Literal e seu respectivo
PostLiteral
recurso.
Executa o método de persistência do Namespace.
PostNamespace
Executa o método de persistência da Property e seu respectivo
PostProperty
recurso.
Executa o método de persistência do Range.
PostRange
Executa o método de persistência do Resource e seu respectivo
PostResource
Namespace.
Executa o método de persistência da SubClassOf.
PostSubClassOf
Executa o método de persistência da SubPropertyOf.
PostSubPropertyOf
Executa o método de persistência da Triple e seu respectivo
PostTriple
recurso.
Executa o parser da declaração através do DriveRDF e o método
PostRdfXml
de persitência quando a declaração é válida ou gera uma exceção
no caso contrário, abortanto o processo de persistência.
Realiza a navegação no objeto RdfGraph do DriveRDF e executa
PersistRDFS
a persistência de todos os componentes da declaração utilizando
os métodos anteriores.
Cada componente do modelo de dados é incluído no banco somente se não for
persistido anteriormente. Nos casos de reincidência o método apenas retorna o identificador
do dado. Na primeira inclusão, o registro é incluído e o novo identificador do dado é
retornado para manipulação.
Além dos métodos de persistência, a classe RDFs possui métodos que permitem a
exclusão dos dados persistidos conforme descritos no Quadro 3.
Quadro 3 – Métodos de exclusão da classe RDFs
Nome do Método
Descrição da funcionalidade
Executa o método de exclusão da Class.
DeleteClass
Executa o método de exclusão do Domain.
DeleteDomain
Executa o método de exclusão do Literal.
DeleteLiteral
Executa o método de exclusão do Namespace.
DeleteNamespace
Executa o método de exclusão da Property.
DeleteProperty
Executa o método de exclusão do Range.
DeleteRange
Executa o método de exclusão do Resource.
DeleteResource
Executa o método de exclusão da SubClassOf.
DeleteSubClassOf
Executa o método de exclusão da SubPropertyOf.
DeleteSubPropertyOf
Executa o método de exclusão da Triple.
DeleteTriple
É importante ressaltar que todos os métodos de exclusão possuem a opção de exclusão
em cascata ou restrita, deixando a cargo da aplicação decidir qual a melhor abordagem para
exclusão. Para exclusão em cascata, foram utilizadas as constraints do banco de dados,
enquanto que, para exclusão restrita, o controle de exclusão é realizado pelo pacote de
persistência.
40
4.3.3
RDFPersistence
O componente RDFPersistence é a camada de persistência deste pacote. Este
componente não executa nenhuma instrução SQL diretamente no banco de dados, pois este
pacote está prevendo uma expansão a qualquer outro banco. Para viabilizar este recurso é
utilizada a interface multi-banco para isolar a camada de persistência da camada do banco de
dados. Além disso, são utilizadas instruções SQL padrão, para que seja possível realizar a
persistência de forma transparente, visando que particularidades de cada banco sejam tratadas
de forma independente pelo componente específico para este fim. Para garantir o controle de
persistência cada componente do modelo de dados, descrito na seção 4.2, possui uma classe
de persistência associada, que utiliza o interface IRDFDatabases de abstração do banco.
4.3.3.1
Class
Classe responsável pela persistência da entidade “Class”. Seus métodos são dispostos
no Quadro 4.
Métodos
Insert
Get
Delete
4.3.3.2
Quadro 4 – Métodos de persistência da classe Class
Parâmetro
Descrição
Class_Id
Inclui nova classe
Class_Id
Busca classe pelo identificador
Class_Id
Deleta classe pelo identificador
Domain
Classe responsável pela persistência da entidade “Domain”. Seus métodos são
dispostos no Quadro 5.
Métodos
Insert
Get
Delete
4.3.3.3
Quadro 5 – Métodos de persistência da classe Domain
Parâmetro
Descrição
Property_Id, Class_Id
Inclui novo domain
Property_Id, Class_Id
Busca domain pela propriedade e classe
Property_Id, Class_Id
Deleta domain pela propriedade e classe
Literals
Classe responsável pela persistência da entidade “Literals”. Seus métodos são
dispostos no Quadro 6.
41
Quadro 6 – Métodos de persistência da classe Literals
Parâmetro
Descrição
Literal_Id, Data_Type_Id,
Inclui novo literal
Language, LabelKey, Label
Language, LabelKey,
Busca literal pela linguagem, chave do
Data_Type_Id
literal e o tipo de dado
Literal_Id
Deleta o literal pelo identificador
Métodos
Insert
Get
Delete
4.3.3.4
Namespaces
Classe responsável pela persistência da entidade “Namespaces”. Seus métodos são
dispostos no Quadro 7.
Métodos
Insert
Get
Delete
4.3.3.5
Quadro 7 – Métodos de persistência da classe Namespaces
Parâmetro
Descrição
Prefix, Name
Inclui um novo namespace
Name
Busca pelo nome ou descrição
Namespace_id
Deleta o namespace pelo identificador
Property
Classe responsável pela persistência da entidade “Property”. Seus métodos são
dispostos no Quadro 8.
Métodos
Insert
Get
Delete
4.3.3.6
Quadro 8 – Métodos de persistência da classe Property
Parâmetro
Descrição
Property_Id
Inclui um novo propriedade
Property_Id
Busca a propriedade pelo identificador
Property_Id
Deleta a propriedade pelo identificador
Range
Classe responsável pela persistência da entidade “Range”. Seus métodos são dispostos
no Quadro 9.
Métodos
Insert
Get
Delete
4.3.3.7
Quadro 9 – Métodos de persistência da classe Range
Parâmetro
Descrição
Property_Id, Class_Id
Inclui um novo Range
Property_Id, Class_Id
Busca o range pelo identificador da
propriedade e classe
Property_Id, Class_Id
Deleta o range pelo identificador da
propriedade e classe
Resources
Classe responsável pela persistência da entidade “Resources”. Seus métodos são
dispostos no Quadro 10.
42
Métodos
Insert
Get
Delete
4.3.3.8
Quadro 10 – Métodos de persistência da classe Resources
Parâmetro
Descrição
Namespace_Id, Local_Name
Inclui um novo recurso
Local_Name, Namespace_Id
Busca o Resource pelo identificador do
namespace e o nome do recurso
Resource_Id
Deleta o recurso pelo identificador
SubClassOf
Classe responsável pela persistência da entidade “SubClassOf”. Seus métodos são
dispostos no Quadro 11.
Métodos
Insert
Get
Delete
4.3.3.9
Quadro 11 – Métodos de persistência da classe SubClassOf
Parâmetro
Descrição
SubClass_Id, SuperClass_Id
Inclui uma nova subclasse
SubClass_Id, SuperClass_Id
Busca a subclasse pelo identificador da
subclasse e superclasse
SubClass_Id, SuperClass_Id
Deleta a subclasse pelo identificador da
subclasse e superclasse
SubPropertyOf
Classe responsável pela persistência da entidade “SubPropertyOf”. Seus métodos são
dispostos no Quadro 12.
Métodos
Insert
Get
Delete
Quadro 12 – Métodos de persistência da classe SubPropertyOf
Parâmetro
Descrição
SubProperty_Id,
Inclui uma nova subpropriedade
SuperProperty_Id
SubProperty_Id,
Busca a subpropriedade pelo
SuperProperty_Id
identificador da subpropriedade e
superpropriedade
SubProperty_Id,
Deleta a subpropriedade pelo
SuperProperty_Id
identificador da subpropriedade e
superpropriedade
4.3.3.10 Triples
Classe responsável pela persistência da entidade “Triples”. Seus métodos são
dispostos no Quadro 13.
43
Métodos
Insert
Get
Delete
4.3.4
Quadro 13 – Métodos de persistência da classe Triples
Parâmetro
Descrição
Triple_Id, Subject_Id,
Inclui uma nova tripla
Predicate_Id, Object_Id
Subject_Id, Predicate_Id,
Busca a tripla pelo identificador do
Object_Id
sujeito, predicado e objeto
Triple_Id
Deleta a tripla pelo identificador
RDFDatabases
O componente RDFDatabases é responsável pelo sistema multi-banco do pacote de
persistência. Possui uma interface chamada IRDFDatabases que realiza a abstração das
conexões, exceções e métodos de execução de instruções, de forma que a adaptação para o
suporte a um novo banco de dados gere pouco impacto na implementação da alteração deste
componente e nenhum impacto nas camadas superiores. Todas as informações diretamente
relacionadas a banco de dados, estão organizadas em cinco componentes.
4.3.4.1
DBAccess
A classe DBAcess é responsável pela abertura das conexões, criação de parâmetros,
providers, tipos de comandos e substituição de parâmetros e todas estas atividades de maneira
específica para o banco de dados. Para isso conta com os métodos listados no Quadro 14.
Quadro 14 – Métodos de abstração da classe DBAccess
Parâmetro
Descrição
Connection, CommandType, Executa um comando Sql que retorna
CommandText,
vários registros encapsulados num
CommandParameters
Dataset. (select)
Connection, CommandType, Executa comando SQL como um
ExecuteNonQuery
CommandText,
delete, insert ou update.
CommandParameters
Connection, Factory
Abre a conexão com o banco de
OpenConnection
dados
Cmd,
CommandParameters
Adiciona
os parametros no comando
AddParameters
Cria um DataAdapter para suportar a
CreateDataAdapter
execução do comando de acordo com
o banco.
Cria conexão de acordo com o banco
CreateConnection
Cria commando de acordo com o
CreateCommand
banco
CreateDataParameter paramName, DBType, Value Cria um parametro de acordo com o
banco
Métodos
ExecuteDataSet
4.3.4.2
DBConfig
A classe DBConfig é responsável pela busca da configuração do banco de dados ativo
do pacote de persistência. Esta configuração deve estar definida no arquivo de configuração
44
da aplicação .Net, que pode ser o Web.config no caso de uma aplicação para internet ou
App.config para uma aplicação tradicional.
Figura 21 – Exemplo de configuração do banco de dados do pacote
A Figura 21 demonstra um exemplo de configuração do banco de dados do pacote. A
definição da configuração é realizada de uma forma simples utilizando a linguagem XML,
com a marcação <Database>, indicando o grupo, e a <DBActive>, indicando a seção. Existem
também chaves que definem o provider (no caso do MSDE é “SQLClient”) chamada
“Provider” e a string de conexão com o banco de dados chamada “ConnString”.
Caso a configuração não tenha sido definida nos arquivos de configuração, será gerada
uma exceção e o processo de persistência abortado.
O Quadro 15 exibe a definição do método que realiza a busca da configuração do
banco de dados ativo do pacote.
Método
GetConfig
4.3.4.3
Quadro 15 – Métodos da classe DBConfig
Parâmetro
Descrição
groupName, sectionName, key Busca a configuração que indica o banco
de dados ativo para persistência.
DBException
A classe DBException é responsável pelo controle de todas as exceções provenientes
da execução do pacote de persistência. Para realizar este controle são utilizados os métodos
listados no Quadro 16.
45
Métodos
DBException
DBException
DBException
DBException
DBConfigException
DBConfigException
DBConfigException
DBConfigException
RDFPackage
DatabaseException
RDFPackage
DatabaseException
RDFPackage
DatabaseException
RDFPackage
DatabaseException
RDFPackage
ParserException
RDFPackage
ParserException
RDFPackage
ParserException
RDFPackage
ParserException
4.3.4.4
Quadro 16 – Métodos da classe DBException
Parâmetro
Descrição
Exceção genérica
Message
Exceção genérica com mensagem
message, inner
Exceção genérica com mensagem e
exceção original
info, context
Exceção genérica que permite
serialização do resultado
Exceção de configuração
Message
Exceção de configuração com mensagem
message, inner
Exceção de configuração com mensagem
e exceção original
info, context
Exceção de configuração que permite
serialização do resultado
Exceção do banco de dados do pacote
Message
message, inner
info, context
Message
message, inner
info, context
Exceção do banco de dados do pacote
com mensagem
Exceção do banco de dados do pacote
com mensagem e exceção original
Exceção do banco de dados do pacote
que permite serialização do resultado
Exceção do banco de dados do pacote
Exceção do parser do pacote com
mensagem
Exceção do parser do pacote com
mensagem e exceção original
Exceção do parser do pacote que permite
serialização do resultado
DBSequences
O modelo de dados do pacote utiliza diversos identificadores para representar o
relacionamento entre os componentes do modelo RDF. A classe DBSequences é responsável
pela geração dos identificadores do pacote. Somente as entidades “Namespaces” e
“Resources” necessitam de geração, considerando a estrutura do modelo, pois cada novo
“Namespace” requer uma identificação, que posteriormente será utilizada pelo recurso. O
“Resource”, por sua vez, requer uma identificação. Os demais componentes são
especializações de “Resources” ou, então, classificações de especializações de “Resources”;
portanto, não necessitam de identificadores exclusivos.
A geração de identificadores é uma funcionalidade que está disponível em alguns
bancos de dados de forma nativa. Porém como este pacote prevê o suporte a diversos bancos
dados, não pode utilizar nenhuma funcionalidade específica de nenhum banco. Essa afirmação
justifica a implementação de um controle programático de identificadores, de forma que não
haja nenhum tipo de restrição neste sentido.
O Quadro 17 exibe os métodos da classe DBSequences para geração de seqüência.
46
Método
GetNextKey
Execute
4.3.4.5
Quadro 17 – Métodos da classe DBSequences
Parâmetro
Descrição
TableName
Busca o próximo identificador da tabela
informada como parâmetro.
TableName
Incrementa o identificador da tabela
informada como parâmetro.
DBSqls
A classe DBSqls armazena de forma estática os comandos SQLs padrão utilizados por
toda a camada de persistência e consulta do pacote. Seu acesso é realizado através de tipos
enumerados que definem todas as funcionalidades do pacote, ou seja, cada funcionalidade
possui um SQL associado e por consequência um enumerado que facilita o acesso à instrução
SQL.
O Quadro 18 exibe o método da classe DBSqls que realiza a busca do SQL
dependendo do enumerado por parâmetro.
Método
GetCommand
4.3.5
Quadro 18 – Métodos da classe DBSqls
Parâmetro
Descrição
Sql.Enum (tipo enumerado de
Busca a instrução SQL padrão conforme
identificação do SQL)
o enumerado passado por parâmetro.
RDFModels
O componente de Administração dos Modelos tem o objetivo de fazer o
gerenciamento dos modelos de dados, disponibilizando métodos para criação, alteração e
remoção de cada modelo armazenado. É importante salientar que esta implementação poderia
ser desenvolvida externamente ao pacote de persistência, porém optou-se pela criação da
funcionalidade agregada à persistência, proporcionando uma melhor organização das
declarações persistidas. Outra questão importante é que todas as definições do sistema de
gerência de modelos foram implementadas baseada nos componentes RDF e utilizam o
próprio modelo de dados do pacote de persistência, servindo como um exemplo prático de
utilização deste conjunto de classes. Todo o detalhamento deste componente encontra-se na
seção 5.1, referente aos casos de uso.
4.3.6
RDFQuery
O componente RDFQuery é responsável pelas consultas padrão sobre os dados
persistidos. As consultas estáticas serão utilizadas para realizar a homologação deste pacote,
que será disponibilizado para futuras aplicações .Net que necessitarem deste recurso. No
processo de elaboração dos métodos estáticos procurou-se definir quais as informações seriam
mais relavantes e deveriam ser disponibilizadas para auxiliar na recuperação dos dados de
uma forma geral.
47
4.3.6.1
Query
A classe Query é responsável pelo gerenciamento das consultas deste pacote de
persistência, disponibilizando as principais formas de recuperação de dados no modelo de
dados proposto. O Quadro 19 demonstra os métodos da classe Query.
Método
GetResourceBy
Id
GetResourceBy
Name
GetResourceBy
Type
GetNamespace
ById
GetNamespace
ByName
GetLiteralById
GetLiteralByN
ame
GetTriples
4.4
Quadro 19 – Métodos da classe Query
Parâmetro
Descrição
Resource_Id
Retorna os dados do recurso realizando a
busca pelo identificador
Resource_Name
Retorna os dados do recurso realizando a
busca pelo nome
Type
Retorna os dados do recurso realizando a
busca pelo tipo (ex: Class, Property, etc.)
Namespace_Id
Retorna os dados do namespace
realizando a busca pelo identificador
Namespace_Name
Retorna os dados do namespace
realizando a busca pelo nome
Literal_Id
Retorna os dados do literal realizando a
busca pelo identificador
Literal_Name
Retorna os dados do literal realizando a
busca pelo nome
Subject[], predicate[], object[] Retorna os dados das triplas de acordo
com os parametros de sujeito, predicado e
objeto. Os parâmetros são arrays
permitindo uma consulta bastante flexivel
e obtendo dados de retorno de diversos
sujeitos, predicados e objetos. É admitido
parametro nulo, neste caso somente serão
considerados critérios de busca os
parâmetros informados.
ESCOPO
Não faz parte deste trabalho desenvolver uma linguagem de consulta aos dados
armazenados no modelo RDF. Por este motivo não foi dedicada nenhuma seção sobre esse
assunto neste documento. Porém é uma área atraente, com diversas particularidades, que
requer estudos específicos para este fim.
A maioria das ferramentas desenvolvidas com o propósito de possibilitar a persistência
de RDF em banco de dados disponibilizam uma linguagem de consulta aos dados
armazenados, de forma que o usuário possa criar uma consulta qualquer sobre os dados. Não
desenvolvendo uma linguagem de consulta, este trabalho disponibiliza alguns métodos
estáticos, que disponibilizam buscas padronizadas aos dados persistidos, como forma de
acesso aos dados, servindo para validar a funcionalidade da persistência das declarações pelo
pacote.
Este trabalho implementa somente a persistência para o MSDE, porém sua estrutura
não restringe a utilização de diferentes bancos de dados, podendo ser incluídos futuramente,
num segundo momento sem nenhum impacto na camada de persistência.
48
5 Caso de Uso e Outras Aplicações
Este capítulo é dedicado à demonstração do caso de uso desenvolvido para este
trabalho, detalhando os principais pontos do componente de administração de modelos, as
principais funcionalidades da aplicação desenvolvida para demonstrar as funcionalidades do
Pacote .Net e para manipulação de RDF e RDF Schema sobre SGBD, também indicar
algumas possíveis utilizações destes conceitos.
5.1
CASO DE USO
Para auxiliar na homologação deste trabalho foi implementada uma pequena aplicação
em .Net que permite manipular os modelos de dados, agregando funcionalidades importantes
ao usuário final deste pacote. Além de auxiliar na manipulação dos modelos de dados, esta
aplicação serve para demonstrar a funcionalidade do pacote de classes desenvolvido.
Os modelos de dados são conjuntos de dados que possuem a mesma semântica,
podendo estar ligado a tempo, visão ou regra de negócio. Este conceito não existe
formalmente no RDF. A noção de modelo se dá eventualmente pelo agrupamento de
informações declaradas em um mesmo documento RDF/XML, ou ainda, vários documentos
RDF residindo em um mesmo local (namespace). Este conceito foi definido no decorrer do
desenvolvimento deste trabalho, com o objetivo de facilitar a contextualização de um
conjunto de dados de certa forma distintos, mas que por algum motivo possam ser úteis de
uma forma agrupada. Por exemplo no caso de um hospital, têm-se informações de consumos,
controle de estoques e dados clínicos que podem ser agrupados para determinação de um
controle de custos por unidades de atendimento. Mesmo informações com contextos bem
definidos podem ser utilizadas de maneira agrupada em algumas situações.
Para realizar o controle dos modelos foi necessária a criação de um schema que
definesse as principais propriedades dos modelos de dados. A Figura 22 demonstra a
definição do schema utilizado pela aplicação e o componente de gerência dos modelos.
49
Figura 22 – RDF Schema que define os modelos de dados
Neste schema são definidas características do modelo de dados, propriedades do
relacionamento com os recursos e a classe dos modelos de dados chamada “PackageModel”.
Essa definição é persistida no banco de dados, definindo a estrutura da informação
(metadados), deixando preparada para futuras persistências de dados referente aos modelos e
associações.
Os atributos do modelo são: “modelType”, “modelOwner” e “modelCreationDate”. A
persistência destes atributos ocorre normalmente, indicando cada propriedade e seus
respectivos valores.
As propriedades utilizadas para relacionamento de recursos são: “associatedToModel”
e “primaryModel”. A persistência destes relacionamentos são realizadas através da inclusão
de uma tripla no modelo proposto, indicando qual o recurso pertence a qual modelo, criando,
então, um relacionamento lógico com o modelo.
Supondo este conceito complementar e o fato de que tais agrupamentos poderiam ser
gerenciados por uma aplicação, surgiu a idéia deste desenvolvimento.
5.1.1
RDFModels
Como descrito anteriormente, o componente RDFModels poderia ser implementado
totalmente separadado do pacote, porém para agregar funcionalidades a este trabalho, optouse pela implementação conjunta. Todos os métodos de gerência dos modelos são definidos
neste componente e implementados na classe “Models”.
50
5.1.1.1
Models
A classe Models possui os métodos de gerenciamento dos modelos de dados e do
relacionamento de recursos com os modelos. Somente são realizados relacionamentos com a
entidade “Recursos”, tendo em vista que esta funcionalidade requer uma divisão de todos os
componentes do modelo e como o recurso é o componente principal do modelo de dados, não
é necessário criar relacionamento com os demais componentes. Esta classe utiliza métodos
disponibilizados pelo componentes RDFPackage e RDFQuery, utilizando toda a estrutura
montada, como qualquer outra aplicação.
Baseado neste contexto, a classe Models define um conjunto de métodos para
gerenciamento deste dados baseado na definição do schema, como dispostos no Quadro 20.
Quadro 20 – Métodos da classe Models
Parâmetro
Descrição
modelName, modelType,
Insere um novo modelo de dados
modelOwner
Model_Id
Excluí um modelo de dados e todos os
Delete
relacionamentos com recursos (caso
existam)
Associa um recurso ao modelo de dados
AssociateModel Resource_id, Model_Id
Desvincula o recurso do modelo de dados
DeleteAssociate Resource_id, Model_Id
Model
Verifica se o recurso persistido foi
IsPrimaryMod Resource_id
incluso em algum modelo de dados ou é a
el
primeira inserção
Indica o primeiro modelo ou modelo
DefinePrimary Model_Id, Resource_id
principal do recurso.
Model
Retorna todos os modelos de dados
GetAllModels
cadastrados
Model_Id
Retorna o modelo de dados conforme o
GetModel
parâmetro
Retorna os recursos associados ao
GetAssocieated Model_Id
modelo de dados.
Resources
Retorna as propriedades associadas ao
GetAssocieated Model_Id
modelo de dados.
Propertys
Retorna as classes associadas ao modelo
GetAssocieated Model_Id
de dados.
Classes
Retorna os literais associados ao modelo
GetAssocieated Model_Id
de dados.
Literals
Retorna os namespaces associados ao
GetAssocieated Model_Id
modelo de dados.
Namespaces
Método
Post
5.1.2
Aplicação de Administração de Modelos
Utilizando o mesmo critério da definição do componente RDFPackage e agregando
funcionalidades ao pacote, foi elaborada a definição de uma pequena aplicação, com o
objetivo de realizar a gerência dos modelos de dados de forma simples, utilizando todas as
51
camadas desenvolvidas neste pacote de persistência e auxiliando o usuário que necessita da
manipulação dos modelos de dados. O objetivo não foi implementar interfaces sofisticadas,
mas efetivar o uso das principais funcionalidades do pacote. O desenvolvimento foi realizado
utilizando a linguagem C# e ASP.Net
Com o objetivo de demonstrar como foi construída e também como o pacote .Net pode
ser utilizado por qualquer aplicação, são descritos os principais passos para o
desenvolvimento desta aplicação.
Primeiramente devem ser adicionadas as referências dos namespaces na classe que
necessida utilizar os métodos do pacote. Neste caso todos os namespaces diponíveis, pois
deve-se utilizar os recursos de consulta, gerência de modelo e persistência. Após a definição
dos namespaces é só criar uma instância dos objetos e executar os métodos necessários. A
Figura 23 demonstra um exemplo de inclusão de namespaces em uma classe.
Figura 23 – Inclusão dos namespaces do pacote de persistência no projeto
O primeiro passo é definir qual estrutura de dados deve ser utilizada pela aplicação
através de um schema. Essa definição pode ser realizada, persistindo componente a
componente, através dos métodos disponibilizados por este pacote; ou, então, através da
definição de um schema, utilizando a sintaxe RDF/XML e, posteriormente esta definição deve
ser importada através do método do pacote de persistência PostRdfXml(uri) informando o
URI do documento. É importante salientar que o método PostRdfXml(uri) importa qualquer
tipo de declaração RDF (schemas ou dados), auxiliando na carga e/ou portabilidade de
declarações deste modelo. O exemplo de importação do schema da Figura 22, definido para
administração dos modelo de dados do pacote, está demonstrado na Figura 24.
Figura 24 – Exemplo de importação de schema utilizando o pacote de persistência
Somente é necessária a importação uma única vez, porém não existe qualquer restrição
de invocação deste método mais de uma vez. Desta forma pode-se utilizar esse método para
garantir que a estrutura esteja de acordo com o esperado, tendo em vista que somente serão
inclusos os componentes que por qualquer motivo não estão mais persistidos, funcionando
como uma checagem de schema. Feito isso, já é possível criar uma aplicação baseada nesta
estrutura.
52
O desenvolvimento da interface inicial dos modelos de dados possui um componente
DataGrid com as colunas “Nome do Modelo”, “Responsável”, “Classificação” e “Data de
Criação” onde são listados todos os modelos cadastrados. Existem os botões “Sair” (fecha o
administrador de Modelos) e Incluir (inclui um novo modelo de dados).
A Figura 24 demonstra a tela inicial do aplicativo de administração dos modelo
Figura 24 – Interface inicial do aplicativo de administração dos modelos
Para realizar a carga dos modelos de dados no DataGrid, foi necessária a utilização do
componente RDFModels, através do método GetAllModels(). A Figura 25 demonstra como é
utilizado o método da classe Models.
Figura 25 – Exemplo de utilização da classe Query
Desta forma quando a página for carregada os dados serão listados no componente
DataGrid. Por definição, a aplicação realiza a edição do modelo ao clicar na linha do
DataGrid referente ao modelo. A Figura 26 demonstra a tela de edição do modelo de dados.
Figura 26 – Tela de edição do aplicativo de administração dos modelos
53
Semelhante à interface anterior, os dados devem ser carregados, porém em diversos
componentes. Desta vez, são dados referentes a um modelo específico, portanto o método de
consulta deve ser mais específico. Foi utilizado o método GetModel(1), de maneira muito
semelhante ao anterior, porém informando o identificador do modelo a ser carregado. Em
caso de “Inclusão” os campos não são preenchidos e nenhum método de carga é invocado.
Quando o botão confirmar é pressionado deve-se armazenar um novo modelo de dados
ou atualizá-lo. Essa operação é definida pela classe Models, através do método Post(). Deve
ser utilizado como demonstrado na Figura 27.
Figura 27 – Exemplo de utilização da classe Models
A interface de edição dos modelos possui um recurso que possibilita a visualização
dos componentes do modelo RDF relacionados ao modelo em edição. Desta forma são
utilizados métodos que buscam informações sobre os recursos persistidos para o modelo
através do método GetAssocieatedResources(1) passando o identificador do modelo por
parâmetro. O processo é semelhante para todos os componentes do modelo, porém são
utilizados métodos específicos que retornam a informação de cada um dos componentes. A
Figura 28 demonstra a interface dos recursos relacionados ao modelo de dados.
Figura 28 – Tela de listagem dos recursos do modelo de dados
Foram demonstrados alguns exemplos práticos de utilização de diversos métodos
desenvolvidos por este pacote, proporcionando uma vizualização um pouco mais clara do
funcionamento de uma aplicação que faça uso desse recurso.
5.2
OUTRAS APLICAÇÕES
Utilizando este pacote de persistência, uma aplicação poderá ter diversos benefícios na
manipulação de declarações RDF e RDFS e nos recursos que o modelo proporciona. Dentre
eles estão:
• Flexibilidade no controle dos dados que o sistema é proposto;
54
•
•
•
•
•
•
•
•
•
Facilidade na manipulação das informações;
Gerência de estrutura de dados pela aplicação, muito utilizado quando a regra do negócio
necessita de alterações na estrutura dos dados;
Tempo de desenvolvimento reduzido em caso de manutenção;
RDF modela praticamente qualquer tipo de informação (W3C, 2003), tornando ainda mais
atraente a disponibilização deste pacote de classes;
A persistência de RDF em SGBD proporciona a qualquer aplicação uma flexibilidade
muito grande, porque além do controle de dados e estruturas totalmente flexíveis, ainda
estão agregados todos os benefícios que os SGBDs disponibilizam ao usuário;
Menor impacto para manutenção de aplicações;
Semântica de dados para otimização de consultas;
Padrão alternativo de serialização de classes e metaclasses;
Interoperabilidade entre aplicações.
Também podem ser utilizados os conceitos baseados em RDF e RDFS em
implementações com estrutura flexíveis ou que exigem um controle semântico sobre os dados,
como por exemplo:
• Aplicativos para publicação e geração de pesquisas, questionários, enquetes, etc;
• Gerenciamento de recursos de aplicações e controle de acesso por usuário e/ou tipo de
usuário;
• Sistema de menus dinâmicos;
• Aplicativo para geração de código através de templates, com possibilidade de adaptação;
• Persistência transparente de objetos em banco de dados relacional;
• Qualquer outro aplicativo que necessite de grande flexibilidade estrutural e consultas
otimizadas.
Outra aplicação que proporciona uma boa visão dos recursos que o modelo RDF
disponibiliza é o trabalho realizado no Portal do Centro Universitário Luterano de Palmas
(CEULP/ULBRA), com uma comlexidade elevada, que requer uma vasta quantidade de
recursos e propriedades envolvidas no processo de informatização (Noleto, 2003).
55
6 CONCLUSÃO
Após o estudo realizado sobre os conceitos de RDF e RDF Schema e várias análises
sobre as declarações que podem ser geradas, baseadas neste modelo, é possivel obter uma
visão clara da grande flexibilidade adquirida com a definição da modelagem e manipulação
dos dados através de RDFS. O RDF Schema complementa o modelo RDF básico,
possibilitando a definição de esquemas para criação das declarações, com o objetivo de
alcançar a interoperabilidade semântica dos dados. Pela estruturação proposta pelo modelo é
possível obter resultados importantes na organização dos dados e metadados, otimizando
mecanismos de buscas e facilitando o gerenciamento da informação.
Quando o volume de declarações RDF torna-se muito extenso é necessário criar outro
mecanismo para manipulação destes dados, tendo em vista que a manipulação de declarações
codificadas em XML pode se tornar fragmentada. Para resolver este problema é necessário a
utilização de uma tecnologia agregada ao modelo RDF, que proporcione o aumento de
performance no acesso as informações. Este trabalho foi focado exatamente nesta premissa,
com o objetivo de disponibilizar um acesso rápido e seguro aos dados e proporcionar total
confiabilidade em sua persistência, utilizando a tecnologia de banco de dados relacional
associada aos conceitos de RDF.
Já existem implementações que realizam a persistência de declarações RDF em banco
de dados relacional, porém implementadas na linguagem Java. Os frameworks Jena e Sesame
são as mais importantes implementações dentro deste contexto. Visando qualidade, este
trabalho realizou uma análise para obter as melhores práticas utilizadas nestas tecnologias, a
fim de definir qual o modelo de dados que deveria ser utilizado para implementação deste
trabalho. Porém foi identificado que cada um deles possui uma divisão lógica de classes e
dados totalmente diferente um do outro. Isso ocorre devido a uma abrangência diferenciada
entre as tecnologias, tornando completamente diferente a maneira de armazenamento e
manipulação das informações. Após a realização de alguns testes e as análises dos modelos,
foi definido que o modelo que mais se enquadra para o desenvolvimento deste trabalho é o
definido pelo Sesame, por ser muito mais detalhado e voltado diretamente para a persistência
de RDF e RDF Schema. Durante a implementação foi disponibilizada uma nova versão do
framework Sesame com algumas inovações. O novo modelo de dados proposto, tornou mais
simples a persistência das declarações, pois a centralização do recurso como componente
principal diminuiu o processamento e otimizou a execução do pacote.
O pacote .Net para manipulação de RDF e RDF Schema sobre SGBD foi desenvolvido
utilizando a plataforma .Net, linguagem C#, com uma arquitetura totalmente isolada da
aplicação, de forma que possa ser reutilizado facilmente por qualquer aplicação que necessite
desta persistência. Primeiramente, o pacote foi desenvolvido com o suporte à persistência para
o MSDE, mas com a previsão de incorporação de novos bancos de dados, futuramente, com
56
uma implementação flexível que realiza a abstração dos métodos relacionados ao banco. Foi
desenvolvido um componente de gerência de modelos de dados persistidos, agregado ao
pacote de persistência, para auxiliar o usuário no agrupamento dos modelos, definida a partir
dos componentes do modelo RDF. Com o objetivo de agregar funcionalidades ao pacote e
auxiliar na homologação final deste trabalho, foi desenvolvida em ASP.Net uma aplicação de
manipulação dos modelos que utiliza praticamente todas as funcionalidades desenvolvidas
neste trabalho.
Durante o desenvolvimento deste trabalho, foi possível detectar algumas restrições na
modelagem de dados realizada utilizando os componentes do RDF e RDFS. As restrições
encontradas são:
• Não é possivel definir um relacionamento de equivalência entre literais de diversas
linguagens, o que acaba gerando um problema semântico nas declarações;
• Os “datatypes” estão definidos semanticamente pelo schema/DTD do XML e não existe
nenhum controle destes tipos de dados no modelo RDF, podendo apenas ser utilizado pelo
modelo;
• Não é possível definir nenhum tipo de limitador de quantidade sobre os dados dispostos,
gerando um problema de cardinalidade. Por exemplo, uma limitação de quantidade em um
“rdf:bag”.
• Não existe nenhuma garantia semântica de que uma declaração RDF obedecerá
completamente às definições estruturais ou restritivas definidas pelo seu schema.
As principais dificuldades encontradas no desenvolvimento deste trabalho foram
relacionadas à análise dos framewors Jena e Sesame e à utilização da estrutura em memória
proposta pelo DriveRDF. Para utilização dos frameworks, as dificuldades foram as
configurações dos aplicativos, tendo em vista que ambos possuem estruturas bastante
complexas, e a documentação técnica disponível limitada. Quanto a utilização do DriveRDF,
as dificuldades estão ligadas à busca da informação das declarações RDF/XML armazenadas
em memória pelo componente, pois não existe uma documentação completa da estrutura de
acesso às informações.
As principais vantangens da utilização deste pacote são as inúmeras formas de
trabalhar com diversos recursos disponibilizados para manipulação dos componentes do
modelo RDF e RDFs, flexibilidade no gerenciamento de dados e metadados, e também pela
simplicidade de utilização por qualquer aplicativo .Net.
As principais desvantagens da utilização deste pacote estão relacionadas a não
disponibilização de um recurso que utilize a estrutura relacional do banco de dados para
garantir a semântica do modelo e a não disponibilização de um conjuntos de métodos de
serialização das declarações persistidas, devido à restrição de tempo de desenvolvimento
deste trabalho.
Como proposta de expansão para o mesmo, pode ser implementado um controle
semântico sobre as declarações RDF, que analisa se o conteúdo das declarações estão de
acordo com o schema pré-definido no namespace. Outra implementação possível é o
desenvolvimento de uma linguagem de consulta sobre os dados, permitindo que o próprio
usuário possa definir suas buscas, diretamente no banco de dados, e com uma línguagem
específica para a estrutura proposta.
57
ANEXO A – FORMATOS DE URI SCHEMAS
58
ANEXO B – EXEMPLO DE DECLARAÇÃO RDF
<?xml version="1.0" encoding="iso-8859-1"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rel="http://www.perceive.net/schemas/20021119/relationship/relationship.rdf#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:foaf="http://xmlns.com/foaf/0.1/"
xmlns:wn="http://xmlns.com/wordnet/1.6/"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:contact="http://www.w3.org/2000/10/swap/pim/contact#"
xmlns:air="http://www.megginson.com/exp/ns/airports#"
>
<foaf:Person>
<foaf:mbox rdf:resource="mailto:[email protected]" />
<foaf:name>Ben Hammersley</foaf:name>
<foaf:title>Mr</foaf:title>
<foaf:firstName>Ben</foaf:firstName>
<foaf:surname>Hammersley</foaf:surname>
<foaf:homepage rdf:resource="http://www.benhammersley.com"/>
<foaf:mbox_sha1sum>a6707acc31550cdf9ed9fbaead1af914d0df805d</foaf:mbox_sha1sum>
<foaf:projectHomepage rdf:resource="http://www.benhammersley.com" />
<foaf:weblog>
<rdf:Description rdf:about="http://www.benhammersley.com/blogindex.html">
<dc:title>Ben Hammersley's Dangerous Precedent</dc:title>
</rdf:Description>
</foaf:weblog>
<foaf:depiction rdf:resource="http://www.oreillynet.com/images/people/ben_hammersley.jpg"/>
<foaf:image>
<rdf:Description
rdf:about="http://www.oreillynet.com/images/people/ben_hammersley.jpg">
<dc:description>Head shot of Ben Hammersley</dc:description>
<dc:title>Ben Hammersley</dc:title>
</rdf:Description>
</foaf:image>
</foaf:Person>
</rdf:RDF>
ANEXO C – RDF SCHEMA QUE DEFINE O MODELO RDF
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<owl:Ontology rdf:about="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<dc:title>The RDF Vocabulary (RDF)</dc:title>
<dc:description>This is the RDF Schema for the RDF vocabulary defined in the RDF
namespace.</dc:description>
</owl:Ontology>
<rdf:Property rdf:about="http://www.w3.org/1999/02/22-rdf-syntax-ns#type">
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#" />
<rdfs:label>type</rdfs:label>
<rdfs:comment>The subject is an instance of a class.</rdfs:comment>
<rdfs:range rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class" />
<rdfs:domain rdf:resource="http://www.w3.org/2000/01/rdf-schema#Resource" />
</rdf:Property>
<rdfs:Class rdf:about="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property">
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#" />
<rdfs:label>Property</rdfs:label>
<rdfs:comment>The class of RDF properties.</rdfs:comment>
<rdfs:subClassOf rdf:resource="http://www.w3.org/2000/01/rdf-schema#Resource" />
</rdfs:Class>
<rdfs:Class rdf:about="http://www.w3.org/1999/02/22-rdf-syntax-ns#Statement">
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#" />
<rdfs:label>Statement</rdfs:label>
<rdfs:subClassOf rdf:resource="http://www.w3.org/2000/01/rdf-schema#Resource" />
<rdfs:comment>The class of RDF statements.</rdfs:comment>
</rdfs:Class>
<rdf:Property rdf:about="http://www.w3.org/1999/02/22-rdf-syntax-ns#subject">
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#" />
<rdfs:label>subject</rdfs:label>
<rdfs:comment>The subject of the subject RDF statement.</rdfs:comment>
<rdfs:domain rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Statement" />
<rdfs:range rdf:resource="http://www.w3.org/2000/01/rdf-schema#Resource" />
</rdf:Property>
<rdf:Property rdf:about="http://www.w3.org/1999/02/22-rdf-syntax-ns#predicate">
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#" />
<rdfs:label>predicate</rdfs:label>
<rdfs:comment>The predicate of the subject RDF statement.</rdfs:comment>
<rdfs:domain rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Statement" />
<rdfs:range rdf:resource="http://www.w3.org/2000/01/rdf-schema#Resource" />
</rdf:Property>
<rdf:Property rdf:about="http://www.w3.org/1999/02/22-rdf-syntax-ns#object">
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#" />
<rdfs:label>object</rdfs:label>
<rdfs:comment>The object of the subject RDF statement.</rdfs:comment>
<rdfs:domain rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Statement" />
<rdfs:range rdf:resource="http://www.w3.org/2000/01/rdf-schema#Resource" />
</rdf:Property>
<rdfs:Class rdf:about="http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag">
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#" />
<rdfs:label>Bag</rdfs:label>
<rdfs:comment>The class of unordered containers.</rdfs:comment>
<rdfs:subClassOf rdf:resource="http://www.w3.org/2000/01/rdf-schema#Container" />
</rdfs:Class>
60
<rdfs:Class rdf:about="http://www.w3.org/1999/02/22-rdf-syntax-ns#Seq">
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#" />
<rdfs:label>Seq</rdfs:label>
<rdfs:comment>The class of ordered containers.</rdfs:comment>
<rdfs:subClassOf rdf:resource="http://www.w3.org/2000/01/rdf-schema#Container" />
</rdfs:Class>
<rdfs:Class rdf:about="http://www.w3.org/1999/02/22-rdf-syntax-ns#Alt">
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#" />
<rdfs:label>Alt</rdfs:label>
<rdfs:comment>The class of containers of alternatives.</rdfs:comment>
<rdfs:subClassOf rdf:resource="http://www.w3.org/2000/01/rdf-schema#Container" />
</rdfs:Class>
<rdf:Property rdf:about="http://www.w3.org/1999/02/22-rdf-syntax-ns#value">
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#" />
<rdfs:label>value</rdfs:label>
<rdfs:comment>Idiomatic property used for structured values.</rdfs:comment>
<rdfs:domain rdf:resource="http://www.w3.org/2000/01/rdf-schema#Resource" />
<rdfs:range rdf:resource="http://www.w3.org/2000/01/rdf-schema#Resource" />
</rdf:Property>
<rdfs:Class rdf:about="http://www.w3.org/1999/02/22-rdf-syntax-ns#List">
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#" />
<rdfs:label>List</rdfs:label>
<rdfs:comment>The class of RDF Lists.</rdfs:comment>
<rdfs:subClassOf rdf:resource="http://www.w3.org/2000/01/rdf-schema#Resource" />
</rdfs:Class>
<rdf:List rdf:about="http://www.w3.org/1999/02/22-rdf-syntax-ns#nil">
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#" />
<rdfs:label>nil</rdfs:label>
<rdfs:comment>The empty list, with no items in it. If the rest of a list is nil then the
list has no more items in it.</rdfs:comment>
</rdf:List>
<rdf:Property rdf:about="http://www.w3.org/1999/02/22-rdf-syntax-ns#first">
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#" />
<rdfs:label>first</rdfs:label>
<rdfs:comment>The first item in the subject RDF list.</rdfs:comment>
<rdfs:domain rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#List" />
<rdfs:range rdf:resource="http://www.w3.org/2000/01/rdf-schema#Resource" />
</rdf:Property>
<rdf:Property rdf:about="http://www.w3.org/1999/02/22-rdf-syntax-ns#rest">
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#" />
<rdfs:label>rest</rdfs:label>
<rdfs:comment>The rest of the subject RDF list after the first item.</rdfs:comment>
<rdfs:domain rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#List" />
<rdfs:range rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#List" />
</rdf:Property>
<rdfs:Datatype rdf:about="http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral">
<rdfs:subClassOf rdf:resource="http://www.w3.org/2000/01/rdf-schema#Literal" />
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#" />
<rdfs:label>XMLLiteral</rdfs:label>
<rdfs:comment>The class of XML literal values.</rdfs:comment>
</rdfs:Datatype>
<rdf:Description rdf:about="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdfs:seeAlso rdf:resource="http://www.w3.org/2000/01/rdf-schema-more" />
</rdf:Description>
</rdf:RDF>
ANEXO D – VOCABULÁRIO DO RDF SCHEMA
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<owl:Ontology rdf:about="http://www.w3.org/2000/01/rdf-schema#" dc:title="The RDF Schema
vocabulary (RDFS)" />
<rdfs:Class rdf:about="http://www.w3.org/2000/01/rdf-schema#Resource">
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2000/01/rdf-schema#" />
<rdfs:label>Resource</rdfs:label>
<rdfs:comment>The class resource, everything.</rdfs:comment>
</rdfs:Class>
<rdfs:Class rdf:about="http://www.w3.org/2000/01/rdf-schema#Class">
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2000/01/rdf-schema#" />
<rdfs:label>Class</rdfs:label>
<rdfs:comment>The class of classes.</rdfs:comment>
<rdfs:subClassOf rdf:resource="http://www.w3.org/2000/01/rdf-schema#Resource" />
</rdfs:Class>
<rdf:Property rdf:about="http://www.w3.org/2000/01/rdf-schema#subClassOf">
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2000/01/rdf-schema#" />
<rdfs:label>subClassOf</rdfs:label>
<rdfs:comment>The subject is a subclass of a class.</rdfs:comment>
<rdfs:range rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class" />
<rdfs:domain rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class" />
</rdf:Property>
<rdf:Property rdf:about="http://www.w3.org/2000/01/rdf-schema#subPropertyOf">
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2000/01/rdf-schema#" />
<rdfs:label>subPropertyOf</rdfs:label>
<rdfs:comment>The subject is a subproperty of a property.</rdfs:comment>
<rdfs:range rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property" />
<rdfs:domain rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property" />
</rdf:Property>
<rdf:Property rdf:about="http://www.w3.org/2000/01/rdf-schema#comment">
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2000/01/rdf-schema#" />
<rdfs:label>comment</rdfs:label>
<rdfs:comment>A description of the subject resource.</rdfs:comment>
<rdfs:domain rdf:resource="http://www.w3.org/2000/01/rdf-schema#Resource" />
<rdfs:range rdf:resource="http://www.w3.org/2000/01/rdf-schema#Literal" />
</rdf:Property>
<rdf:Property rdf:about="http://www.w3.org/2000/01/rdf-schema#label">
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2000/01/rdf-schema#" />
<rdfs:label>label</rdfs:label>
<rdfs:comment>A human-readable name for the subject.</rdfs:comment>
<rdfs:domain rdf:resource="http://www.w3.org/2000/01/rdf-schema#Resource" />
<rdfs:range rdf:resource="http://www.w3.org/2000/01/rdf-schema#Literal" />
</rdf:Property>
<rdf:Property rdf:about="http://www.w3.org/2000/01/rdf-schema#domain">
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2000/01/rdf-schema#" />
<rdfs:label>domain</rdfs:label>
<rdfs:comment>A domain of the subject property.</rdfs:comment>
<rdfs:range rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class" />
<rdfs:domain rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property" />
</rdf:Property>
<rdf:Property rdf:about="http://www.w3.org/2000/01/rdf-schema#range">
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2000/01/rdf-schema#" />
<rdfs:label>range</rdfs:label>
62
<rdfs:comment>A range of the subject property.</rdfs:comment>
<rdfs:range rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class" />
<rdfs:domain rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property" />
</rdf:Property>
<rdf:Property rdf:about="http://www.w3.org/2000/01/rdf-schema#seeAlso">
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2000/01/rdf-schema#" />
<rdfs:label>seeAlso</rdfs:label>
<rdfs:comment>Further information about the subject resource.</rdfs:comment>
<rdfs:range rdf:resource="http://www.w3.org/2000/01/rdf-schema#Resource" />
<rdfs:domain rdf:resource="http://www.w3.org/2000/01/rdf-schema#Resource" />
</rdf:Property>
<rdf:Property rdf:about="http://www.w3.org/2000/01/rdf-schema#isDefinedBy">
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2000/01/rdf-schema#" />
<rdfs:subPropertyOf rdf:resource="http://www.w3.org/2000/01/rdf-schema#seeAlso" />
<rdfs:label>isDefinedBy</rdfs:label>
<rdfs:comment>The defininition of the subject resource.</rdfs:comment>
<rdfs:range rdf:resource="http://www.w3.org/2000/01/rdf-schema#Resource" />
<rdfs:domain rdf:resource="http://www.w3.org/2000/01/rdf-schema#Resource" />
</rdf:Property>
<rdfs:Class rdf:about="http://www.w3.org/2000/01/rdf-schema#Literal">
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2000/01/rdf-schema#" />
<rdfs:label>Literal</rdfs:label>
<rdfs:comment>The class of literal values, eg. textual strings and integers.</rdfs:comment>
<rdfs:subClassOf rdf:resource="http://www.w3.org/2000/01/rdf-schema#Resource" />
</rdfs:Class>
<rdfs:Class rdf:about="http://www.w3.org/2000/01/rdf-schema#Container">
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2000/01/rdf-schema#" />
<rdfs:label>Container</rdfs:label>
<rdfs:subClassOf rdf:resource="http://www.w3.org/2000/01/rdf-schema#Resource" />
<rdfs:comment>The class of RDF containers.</rdfs:comment>
</rdfs:Class>
<rdfs:Class rdf:about="http://www.w3.org/2000/01/rdf-schema#ContainerMembershipProperty">
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2000/01/rdf-schema#" />
<rdfs:label>ContainerMembershipProperty</rdfs:label>
<rdfs:comment>The class of container membership properties, rdf:_1, rdf:_2, ..., all of
which are sub-properties of 'member'.</rdfs:comment>
<rdfs:subClassOf rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property" />
</rdfs:Class>
<rdf:Property rdf:about="http://www.w3.org/2000/01/rdf-schema#member">
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2000/01/rdf-schema#" />
<rdfs:label>member</rdfs:label>
<rdfs:comment>A member of the subject resource.</rdfs:comment>
<rdfs:domain rdf:resource="http://www.w3.org/2000/01/rdf-schema#Resource" />
<rdfs:range rdf:resource="http://www.w3.org/2000/01/rdf-schema#Resource" />
</rdf:Property>
<rdfs:Class rdf:about="http://www.w3.org/2000/01/rdf-schema#Datatype">
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2000/01/rdf-schema#" />
<rdfs:label>Datatype</rdfs:label>
<rdfs:comment>The class of RDF datatypes.</rdfs:comment>
<rdfs:subClassOf rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class" />
</rdfs:Class>
<rdf:Description rdf:about="http://www.w3.org/2000/01/rdf-schema#">
<rdfs:seeAlso rdf:resource="http://www.w3.org/2000/01/rdf-schema-more" />
</rdf:Description>
</rdf:RDF>
ANEXO E – RDF SCHEMA SIMPLIFICADO DO PADRÃO
DUBLIN CORE
<?xml version="1.0" encoding="UTF-8" ?>
<rdf:RDF xmlns:dcterms="http://purl.org/dc/terms/" xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:rdf="http://www.w3.org/1999/02/22rdf-syntax-ns#">
<rdf:Description rdf:about="http://purl.org/dc/elements/1.1/">
<dc:title xml:lang="en-US">The Dublin Core Element Set v1.1 namespace providing access to
its content by means of an RDF Schema</dc:title>
<dc:publisher xml:lang="en-US">The Dublin Core Metadata Initiative</dc:publisher>
<dc:description xml:lang="en-US">The Dublin Core Element Set v1.1 namespace provides URIs
for the Dublin Core Elements v1.1. Entries are declared using RDF Schema language to support
RDF applications.</dc:description>
<dc:language xml:lang="en-US">English</dc:language>
<dcterms:issued>1999-07-02</dcterms:issued>
<dcterms:modified>2003-03-24</dcterms:modified>
<dc:source rdf:resource="http://dublincore.org/documents/dces/" />
<dc:source rdf:resource="http://dublincore.org/usage/decisions/" />
<dcterms:isReferencedBy rdf:resource="http://www.dublincore.org/documents/2001/10/26/dcminamespace/" />
<dcterms:isRequiredBy rdf:resource="http://purl.org/dc/terms/" />
<dcterms:isReferencedBy rdf:resource="http://purl.org/dc/dcmitype/" />
</rdf:Description>
<rdf:Property rdf:about="http://purl.org/dc/elements/1.1/title">
<rdfs:label xml:lang="en-US">Title</rdfs:label>
<rdfs:comment xml:lang="en-US">A name given to the resource.</rdfs:comment>
<dc:description xml:lang="en-US">Typically, a Title will be a name by which the resource is
formally known.</dc:description>
<rdfs:isDefinedBy rdf:resource="http://purl.org/dc/elements/1.1/" />
<dcterms:issued>1999-07-02</dcterms:issued>
<dcterms:modified>2002-10-04</dcterms:modified>
<dc:type rdf:resource="http://dublincore.org/usage/documents/principles/#element" />
<dcterms:hasVersion rdf:resource="http://dublincore.org/usage/terms/history/#title-004" />
</rdf:Property>
<rdf:Property rdf:about="http://purl.org/dc/elements/1.1/creator">
<rdfs:label xml:lang="en-US">Creator</rdfs:label>
<rdfs:comment xml:lang="en-US">An entity primarily responsible for making the content of the
resource.</rdfs:comment>
<dc:description xml:lang="en-US">Examples of a Creator include a person, an organisation, or
a service. Typically, the name of a Creator should be used to indicate the
entity.</dc:description>
<rdfs:isDefinedBy rdf:resource="http://purl.org/dc/elements/1.1/" />
<dcterms:issued>1999-07-02</dcterms:issued>
<dcterms:modified>2002-10-04</dcterms:modified>
<dc:type rdf:resource="http://dublincore.org/usage/documents/principles/#element" />
<dcterms:hasVersion rdf:resource="http://dublincore.org/usage/terms/history/#creator-004" />
</rdf:Property>
<rdf:Property rdf:about="http://purl.org/dc/elements/1.1/subject">
<rdfs:label xml:lang="en-US">Subject and Keywords</rdfs:label>
<rdfs:comment xml:lang="en-US">The topic of the content of the resource.</rdfs:comment>
<dc:description xml:lang="en-US">Typically, a Subject will be expressed as keywords, key
phrases or classification codes that describe a topic of the resource. Recommended best
practice is to select a value from a controlled vocabulary or formal classification
scheme.</dc:description>
<rdfs:isDefinedBy rdf:resource="http://purl.org/dc/elements/1.1/" />
<dcterms:issued>1999-07-02</dcterms:issued>
64
<dcterms:modified>2002-10-04</dcterms:modified>
<dc:type rdf:resource="http://dublincore.org/usage/documents/principles/#element" />
<dcterms:hasVersion rdf:resource="http://dublincore.org/usage/terms/history/#subject-004" />
</rdf:Property>
<rdf:Property rdf:about="http://purl.org/dc/elements/1.1/description">
<rdfs:label xml:lang="en-US">Description</rdfs:label>
<rdfs:comment xml:lang="en-US">An account of the content of the resource.</rdfs:comment>
<dc:description xml:lang="en-US">Description may include but is not limited to: an abstract,
table of contents, reference to a graphical representation of content or a free-text account
of the content.</dc:description>
<rdfs:isDefinedBy rdf:resource="http://purl.org/dc/elements/1.1/" />
<dcterms:issued>1999-07-02</dcterms:issued>
<dcterms:modified>2002-10-04</dcterms:modified>
<dc:type rdf:resource="http://dublincore.org/usage/documents/principles/#element" />
<dcterms:hasVersion rdf:resource="http://dublincore.org/usage/terms/history/#description004" />
</rdf:Property>
<rdf:Property rdf:about="http://purl.org/dc/elements/1.1/publisher">
<rdfs:label xml:lang="en-US">Publisher</rdfs:label>
<rdfs:comment xml:lang="en-US">An entity responsible for making the resource
available</rdfs:comment>
<dc:description xml:lang="en-US">Examples of a Publisher include a person, an organisation,
or a service. Typically, the name of a Publisher should be used to indicate the
entity.</dc:description>
<rdfs:isDefinedBy rdf:resource="http://purl.org/dc/elements/1.1/" />
<dcterms:issued>1999-07-02</dcterms:issued>
<dcterms:modified>2002-10-04</dcterms:modified>
<dc:type rdf:resource="http://dublincore.org/usage/documents/principles/#element" />
<dcterms:hasVersion rdf:resource="http://dublincore.org/usage/terms/history/#publisher-004"
/>
</rdf:Property>
<rdf:Property rdf:about="http://purl.org/dc/elements/1.1/contributor">
<rdfs:label xml:lang="en-US">Contributor</rdfs:label>
<rdfs:comment xml:lang="en-US">An entity responsible for making contributions to the content
of the resource.</rdfs:comment>
<dc:description xml:lang="en-US">Examples of a Contributor include a person, an
organisation, or a service. Typically, the name of a Contributor should be used to indicate
the entity.</dc:description>
<rdfs:isDefinedBy rdf:resource="http://purl.org/dc/elements/1.1/" />
<dcterms:issued>1999-07-02</dcterms:issued>
<dcterms:modified>2002-10-04</dcterms:modified>
<dc:type rdf:resource="http://dublincore.org/usage/documents/principles/#element" />
<dcterms:hasVersion rdf:resource="http://dublincore.org/usage/terms/history/#contributor004" />
</rdf:Property>
<rdf:Property rdf:about="http://purl.org/dc/elements/1.1/date">
<rdfs:label xml:lang="en-US">Date</rdfs:label>
<rdfs:comment xml:lang="en-US">A date associated with an event in the life cycle of the
resource.</rdfs:comment>
<dc:description xml:lang="en-US">Typically, Date will be associated with the creation or
availability of the resource. Recommended best practice for encoding the date value is defined
in a profile of ISO 8601 [W3CDTF] and follows the YYYY-MM-DD format.</dc:description>
<rdfs:isDefinedBy rdf:resource="http://purl.org/dc/elements/1.1/" />
<dcterms:issued>1999-07-02</dcterms:issued>
<dcterms:modified>2002-10-04</dcterms:modified>
<dc:type rdf:resource="http://dublincore.org/usage/documents/principles/#element" />
<dcterms:hasVersion rdf:resource="http://dublincore.org/usage/terms/history/#date-004" />
</rdf:Property>
<rdf:Property rdf:about="http://purl.org/dc/elements/1.1/type">
<rdfs:label xml:lang="en-US">Resource Type</rdfs:label>
<rdfs:comment xml:lang="en-US">The nature or genre of the content of the
resource.</rdfs:comment>
<dc:description xml:lang="en-US">Type includes terms describing general categories,
functions, genres, or aggregation levels for content. Recommended best practice is to select a
value from a controlled vocabulary (for example, the DCMI Type Vocabulary [DCMITYPE]). To
describe the physical or digital manifestation of the resource, use the Format
element.</dc:description>
<rdfs:isDefinedBy rdf:resource="http://purl.org/dc/elements/1.1/" />
<dcterms:issued>1999-07-02</dcterms:issued>
<dcterms:modified>2002-10-04</dcterms:modified>
<dc:type rdf:resource="http://dublincore.org/usage/documents/principles/#element" />
<dcterms:hasVersion rdf:resource="http://dublincore.org/usage/terms/history/#type-004" />
</rdf:Property>
<rdf:Property rdf:about="http://purl.org/dc/elements/1.1/format">
<rdfs:label xml:lang="en-US">Format</rdfs:label>
65
<rdfs:comment xml:lang="en-US">The physical or digital manifestation of the
resource.</rdfs:comment>
<dc:description xml:lang="en-US">Typically, Format may include the media-type or dimensions
of the resource. Format may be used to determine the software, hardware or other equipment
needed to display or operate the resource. Examples of dimensions include size and duration.
Recommended best practice is to select a value from a controlled vocabulary (for example, the
list of Internet Media Types [MIME] defining computer media formats).</dc:description>
<rdfs:isDefinedBy rdf:resource="http://purl.org/dc/elements/1.1/" />
<dcterms:issued>1999-07-02</dcterms:issued>
<dcterms:modified>2002-10-04</dcterms:modified>
<dc:type rdf:resource="http://dublincore.org/usage/documents/principles/#element" />
<dcterms:hasVersion rdf:resource="http://dublincore.org/usage/terms/history/#format-004" />
</rdf:Property>
<rdf:Property rdf:about="http://purl.org/dc/elements/1.1/identifier">
<rdfs:label xml:lang="en-US">Resource Identifier</rdfs:label>
<rdfs:comment xml:lang="en-US">An unambiguous reference to the resource within a given
context.</rdfs:comment>
<dc:description xml:lang="en-US">Recommended best practice is to identify the resource by
means of a string or number conforming to a formal identification system. Example formal
identification systems include the Uniform Resource Identifier (URI) (including the Uniform
Resource Locator (URL)), the Digital Object Identifier (DOI) and the International Standard
Book Number (ISBN).</dc:description>
<rdfs:isDefinedBy rdf:resource="http://purl.org/dc/elements/1.1/" />
<dcterms:issued>1999-07-02</dcterms:issued>
<dcterms:modified>2002-10-04</dcterms:modified>
<dc:type rdf:resource="http://dublincore.org/usage/documents/principles/#element" />
<dcterms:hasVersion rdf:resource="http://dublincore.org/usage/terms/history/#identifier-004"
/>
</rdf:Property>
<rdf:Property rdf:about="http://purl.org/dc/elements/1.1/source">
<rdfs:label xml:lang="en-US">Source</rdfs:label>
<rdfs:comment xml:lang="en-US">A reference to a resource from which the present resource is
derived.</rdfs:comment>
<dc:description xml:lang="en-US">The present resource may be derived from the Source
resource in whole or in part. Recommended best practice is to reference the resource by means
of a string or number conforming to a formal identification system.</dc:description>
<rdfs:isDefinedBy rdf:resource="http://purl.org/dc/elements/1.1/" />
<dcterms:issued>1999-07-02</dcterms:issued>
<dcterms:modified>2002-10-04</dcterms:modified>
<dc:type rdf:resource="http://dublincore.org/usage/documents/principles/#element" />
<dcterms:hasVersion rdf:resource="http://dublincore.org/usage/terms/history/#source-004" />
</rdf:Property>
<rdf:Property rdf:about="http://purl.org/dc/elements/1.1/language">
<rdfs:label xml:lang="en-US">Language</rdfs:label>
<rdfs:comment xml:lang="en-US">A language of the intellectual content of the
resource.</rdfs:comment>
<dc:description xml:lang="en-US">Recommended best practice is to use RFC 3066 [RFC3066],
which, in conjunction with ISO 639 [ISO639], defines two- and three-letter primary language
tags with optional subtags. Examples include "en" or "eng" for English, "akk" for Akkadian,
and "en-GB" for English used in the United Kingdom.</dc:description>
<rdfs:isDefinedBy rdf:resource="http://purl.org/dc/elements/1.1/" />
<dcterms:issued>1999-07-02</dcterms:issued>
<dcterms:modified>2002-10-04</dcterms:modified>
<dc:type rdf:resource="http://dublincore.org/usage/documents/principles/#element" />
<dcterms:hasVersion rdf:resource="http://dublincore.org/usage/terms/history/#language-005"
/>
</rdf:Property>
<rdf:Property rdf:about="http://purl.org/dc/elements/1.1/relation">
<rdfs:label xml:lang="en-US">Relation</rdfs:label>
<rdfs:comment xml:lang="en-US">A reference to a related resource.</rdfs:comment>
<dc:description xml:lang="en-US">Recommended best practice is to reference the resource by
means of a string or number conforming to a formal identification system.</dc:description>
<rdfs:isDefinedBy rdf:resource="http://purl.org/dc/elements/1.1/" />
<dcterms:issued>1999-07-02</dcterms:issued>
<dcterms:modified>2002-10-04</dcterms:modified>
<dc:type rdf:resource="http://dublincore.org/usage/documents/principles/#element" />
<dcterms:hasVersion rdf:resource="http://dublincore.org/usage/terms/history/#relation-004"
/>
</rdf:Property>
<rdf:Property rdf:about="http://purl.org/dc/elements/1.1/coverage">
<rdfs:label xml:lang="en-US">Coverage</rdfs:label>
<rdfs:comment xml:lang="en-US">The extent or scope of the content of the
resource.</rdfs:comment>
<dc:description xml:lang="en-US">Coverage will typically include spatial location (a place
name or geographic coordinates), temporal period (a period label, date, or date range) or
66
jurisdiction (such as a named administrative entity). Recommended best practice is to select a
value from a controlled vocabulary (for example, the Thesaurus of Geographic Names [TGN]) and
that, where appropriate, named places or time periods be used in preference to numeric
identifiers such as sets of coordinates or date ranges.</dc:description>
<rdfs:isDefinedBy rdf:resource="http://purl.org/dc/elements/1.1/" />
<dcterms:issued>1999-07-02</dcterms:issued>
<dcterms:modified>2002-10-04</dcterms:modified>
<dc:type rdf:resource="http://dublincore.org/usage/documents/principles/#element" />
<dcterms:hasVersion rdf:resource="http://dublincore.org/usage/terms/history/#coverage-004"
/>
</rdf:Property>
<rdf:Property rdf:about="http://purl.org/dc/elements/1.1/rights">
<rdfs:label xml:lang="en-US">Rights Management</rdfs:label>
<rdfs:comment xml:lang="en-US">Information about rights held in and over the
resource.</rdfs:comment>
<dc:description xml:lang="en-US">Typically, a Rights element will contain a rights
management statement for the resource, or reference a service providing such information.
Rights information often encompasses Intellectual Property Rights (IPR), Copyright, and
various Property Rights. If the Rights element is absent, no assumptions can be made about the
status of these and other rights with respect to the resource.</dc:description>
<rdfs:isDefinedBy rdf:resource="http://purl.org/dc/elements/1.1/" />
<dcterms:issued>1999-07-02</dcterms:issued>
<dcterms:modified>2002-10-04</dcterms:modified>
<dc:type rdf:resource="http://dublincore.org/usage/documents/principles/#element" />
<dcterms:hasVersion rdf:resource="http://dublincore.org/usage/terms/history/#rights-004" />
</rdf:Property>
</rdf:RDF>
ANEXO E – GRAFO RDF COM CINCO RECURSOS
68
ANEXO F – DOCUMENTAÇÃO DE CLASSES DO DRIVERDF
Class
Description
InvalidRdfException
Represents an exception that is thrown when invalid RDF Syntax is encountered by the parser
RdfAlt
Represents an RDF Container of type rdf:Alt
RdfBag
Represents an RDF container of type rdf:Bag
RdfContainer
Represents an RDF Container
RdfEdge
Represents an Edge in the RDF Graph
RdfEdgeCollection
Represents a collection of edges. This class maps edge IDs to lists of RdfEdge objects
RdfEdgeList
Represents a collection of RdfEdge objects
RdfGraph
Represents an RDF Graph.
RdfLiteral
Represents a Literal in the RDF Graph.
RdfN3Parser
Summary description for RdfN3Parser.
RdfNamespaceCollection
Represents a collection of Namespaces
RdfNode
Represents a node in the RDF Graph
RdfNodeCollection
Represents a collection of RDF Nodes
RdfNTriple
Summary description for RdfNTriple.
RdfNTripleCollection
Summary description for RdfN3Collection.
RdfParser
Summary description for RdfParser.
RdfParserFactory
Represents a ParserFactory that creates and returns Drive.Rdf objects
RdfSeq
Represents an RDF container of type rdf:Seq.
RdfStatement
Represents a reified statement
RdfXmlParser
The primary RDF Parser.
Util
Represents a class of utility methods
69
ANEXO G – PROJETOS DE PERSISTÊNCIA DE RDF
70
71
72
ANEXO H – DIAGRAMAS DE SEQÜÊNCIA DO
COMPONENTE RDFPACKAGE
Figura H – 1 Definição do método PostNamespace da Classe RDFs
Figura H – 2 Definição do método PostResource da Classe RDFs
73
Figura H – 3 Definição do método PostTriples da class RDFs
74
ANEXO I – DIAGRAMAS DE SEQÜÊNCIA DO
COMPONENTE RDFPERSISTENCE
Figura I – 1 Busca de dados da classe “Resources” de persitência
75
Figura I – 2 Inclusão de dados na classe Resources
76
Figura I – 3 Exclusão de dados na classe Resources
77
ANEXO J – DIAGRAMAS DE SEQÜÊNCIA DO
COMPONENTE RDFDATABASES RELACIONADOS A
MULTI-BANCO
Figura J – 1 Abstração do banco no processo ExecuteDataset
78
Figura J – 2 Abstração do banco no processo ExecuteNonQuery
REFERÊNCIAS
W3C. RDF Primer. <http://www.w3.org/TR/rdf-primer/>. Acesso em: 13 maio 2004.
W3C. Resource Description Framework (RDF) Model and Syntax Specification.
<http://www.w3.org/TR/REC-rdf-syntax/>. Acesso em: 20 junho 2004.
W3C. Resource Description Framework (RDF) Schema Specification 1.0
<http://www.w3.org/TR/2000/CR-rdf-schema-20000327/>. Acesso em: 22 junho 2004.
W3C. eXtensible Markup Language (XML). <http://www.w3.org/XML/>. Acesso em: 22
junho 2004.
W3C. XML Schema Part 2 < http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/>.
Acesso em: 22 junho 2004.
W3C. Uri Schemes < http://esw.w3.org/topic/UriSchemes />. Acesso em: 20 novembro 2004.
W3C. XML Namespace - Quality Names < http://www.w3.org/TR/1999/REC-xml-names19990114/#ns-qualnames />. Acesso em: 20 novembro 2004.
Drive - An RDF Parser for the .NET Platform. <http://www.driverdf.org/>. Acesso em: 22
junho 2004.
Packard, Hewlett Development Company. Jena – A Semantic Web Framework for Java
<http://www.hpl.hp.com/semweb/>. Acesso em: 19 junho 2004.
Broekstra, Jean; Kampman, Arjohn; Harmelen, Frank van. Sesame: A Generic Architecture
for Storing and Quering RDF and RDF Schema. Amersfoort: Aidministrator Nederland.
Artigo.
CORPORATION, Microsoft. ASP.NET Web The Official Microsoft ASP.NET Site Home
Page <http://www.asp.net/>. Acesso em: 20 junho 2004.
ZANETE, Nelson Henrique. Uma Avaliação de Abordagens Alternativas para Armazenar
RDF em Banco de Dados Relacional. Porto Alegre: PPGC da UFRGS, 2001. 92 f.:il.
Dissertação (mestrado) – UFRGS, Porto Alegre, BR-RS, 2001. Orientador: Lima, José
SANTOS, Domingos Sávio Apolônio. RDF na Interoperabilidade entre Domínios na
Web. Campina Grange: UFCG, 2002. 108 f.:il. Dissertação (mestrado) – UFCG, Campina
Grande, BR-PB, 2002. Orientador: Schiel, Ulrich.
SILVA, Geiza Cristina da; LIMA, Tarcísio de Souza. RDF e RDFS na Infra-estrutura de
Suporte à Web Semântica. Revista Eletrônica de Iniciação Científica da Sociedade
Brasileira e Computação. Porto Alegre, Ano II, Volume II, Número I, ISSN 1519-8219,
80
Março/2002.<www.sbc.org.br/reic/edicoes/edicao3/cientificos/RDFeRDFSnaInfraEstruturade
SuporteaWebSemantica.pdf>. Acesso em 05/04/2004.
Noleto, Danilo de Abreu; Brito, Parcilene Fernandes de. RDF e RDF Schema na
representação de páginas do portal CEULP/ULBRA. ULBRA, Palmas, BR-TO, 2003.