ALINE DE OLIVEIRA FREITAS
Uma Proposta para Mapeamento Relacional para RDF da Base de Dados da Biblioteca do IFF
Campos dos Goytacazes/RJ 2018
ALINE DE OLIVEIRA FREITAS
Uma Proposta para Mapeamento Relacional-RDF da Base de Dados da Biblioteca do IFF.
Trabalho de conclusão de curso apresentado ao Instituto Federal Fluminense como requisito parcial para a conclusão do curso Bacharelado em
Sistemas de Informação.
Orientador: Mark Douglas de Azevedo Jacyntho
Campos dos Goytacazes/RJ 2018
Elaborada pelo Sistema de Geração Automática de Ficha Catalográfica da Biblioteca Anton Dakitsch do IFF com os dados fornecidos pelo(a) autor(a).
F866p
Freitas, Aline de Oliveira
Uma Proposta para Mapeamento Relacional-RDF da Base de Dados da Biblioteca do IFF / Aline de Oliveira Freitas - 2018.
94 f.: il. color.
Orientador: Mark Douglas de Azevedo Jacyntho
Trabalho de conclusão de curso (graduação) -- Instituto Federal de Educação, Ciência e Tecnologia Fluminense, Campus Campos Centro, Curso de Bacharelado em Sistemas de Informação, Campos dos Goytacazes, RJ, 2018.
Referências: f. 72 a 74.
1. Web semântica. 2. acervo biblioteca. 3. IFF. 4. D2RQ. I. Jacyntho, Mark Douglas de Azevedo, orient. II. Título.
Dedico este trabalho ao meu falecido avô, Elson Freitas Batista. Que do plano dos desencarnados ele possa ver que sua neta conseguiu, finalmente, vencer essa etapa.
AGRADECIMENTOS
Em primeiro lugar gostaria de agradecer à minha família por todo o apoio, incentivo e paciência. Principalmente pela paciência (essa é pra você, mãe).
A todos meus professores, desde a infância e, especialmente ao meu orientador, Mark Douglas, pelo apoio e orientação firmes.
Finalmente, agradeço a todos aqueles que acreditaram em mim, principalmente quando eu não acreditava mais.
“Tudo que um homem pode imaginar outros homens poderão realizar” Júlio Verne.
RESUMO
Produções bibliográficas do meio acadêmico e científico servem de base para todos os futuros trabalhos a serem produzidos. Porém, há uma barreira entre esses textos e seus potenciais consumidores, já que em geral os registros dos trabalhos se encontram circunscritos em bases de dados e sistemas específicos de cada instituição. Como uma proposta de tornar público e plenamente explorável toda bibliografia documentada na biblioteca do Instituto Federal Fluminense, este trabalho aplica conceitos da Web Semântica para tornar público e explorável por máquinas os dados contidos no acervo da biblioteca. Utilizando a ferramenta D2RQ para mapear os dados contidos no escopo deste trabalho para o modelo de dados RDF, além de disponibilizar um endpoint SPARQL para consultar o grafo gerado. Com a descrição incluída juntamente com os dados, serviços de busca poderão utilizar web crawlers para descobrir e indexar as informações do acervo e dar maior visibilidade para a produção científica da instituição.
ABSTRACT
Academic and scientific bibliographical productions are the foundation for all future work to be produced. However, there is a barrier between these texts and their potential consumers, since generally, these records are restrained in databases and specific systems specific for each institution. This work applies Semantic Web concepts as a proposal to make public and machine-readable all bibliographic documented in the library of the Federal Fluminense Institute, to make the data contained in the library collection public and exploitable. D2RQ tool is used to map the data contained in the scope of this work to RDF data model, in addition to providing a SPARQL endpoint to query the generated graph. With the description included along with the data, search services can use web crawlers to discover and index information in the collection and provide greater visibility to the scientific production of the institution.
LISTA DE FIGURAS
Figura 1 Arquitetura em camadas da Web Semântica. Fonte: Thangaraj e Sujatha (2014). ... 21 Figura 2 LOD Cloud Diagram. Fonte: Cyganiak et al (2017). ... 24 Figura 3 Exemplo de representação em grafo de uma tripla RDF. Fonte: Autoria Própria (2018). ... 26 Figura 4 Grafo RDF com 2 assertivas de mesmo sujeito. Fonte: Autoria Própria (2018). ... 27 Figura 5 Sintaxes em relação à compatibilidade com as versões do modelo RDF. Fonte: WOOD (2014). ... 28 Figura 6 Conversão entre um registro de tabela relacional em um grafo RDF. Fonte: Autoria Própria (2018). ... 32 Figura 7 Visão geral da Arquitetura do OpenLink Virtuoso. Fonte: OpenLink Software (2015). ... 35 Figura 8 Arquitetura da Plataforma D2RQ e suas ferramentas. Fonte: Cyganiak (2012). ... 37 Figura 9 Visualização em diagrama das tabelas EDITORAS, MIDIAS, OBRA,
PERIODICO e REGISTRO_BIBLIOGRAFICO. Fonte: Autoria Própria (2018). ... 40 Figura 10 Visualização da Tabela EDITORAS à esquerda, e alguns de seus registros à direita. Fonte: Autoria Própria (2018). ... 41 Figura 11 Trecho da tabela MIDIAS ao lado de uma visualização dos primeiros
registros. Fonte: Autoria Própria (2018). ... 41 Figura 12 Tabelas de interesse associadas à REGISTRO_BIBLIOGRÁFICO. Fonte: Autoria Própria (2018). ... 42 Figura 13 Consulta SQL da view do sistema AUTORES. Fonte: Autoria Própria
(2018). ... 43 Figura 14 Subconsultas da view OBRAS responsável por retornar colunas TITULO e SUBTITULO. Fonte: Autoria Própria (2018). ... 43 Figura 15 Visualização das ligações entre as tabelas REGISTRO, REGISTRO_TAG, REGISTRO_TAG_DADO, REGISTRO_SUBCAMPO. Fonte: Autoria Própria (2018). ... 44
Figura 16 Exemplo de consulta agrupando todas tags e subcampos para cada
registro. Fonte: Autoria Própria (2018). ... 45
Figura 17 Resultado da consulta da Figura 16 contendo todas tags e subcampos referentes ao registro de ID 2. Fonte: Autoria Própria (2018)... 45
Figura 18 Diagrama de entidades relacionadas à entidade Registro. Fonte: Autoria Própria (2018). ... 47
Figura 19 Diagrama contendo tabelas associativas e associadas à tabela Registro. Fonte: Autoria Própria (2018). ... 48
Figura 20 Tabelas relacionadas à Autoridade. Fonte: Autoria Própria (2018). ... 50
Figura 21 Lista de atributos de Autoridade. Fonte: Autoria Própria (2018). ... 50
Figura 22 Atributos da entidade Evento. Fonte: Autoria Própria (2018). ... 51
Figura 23 Atributos de RegistroAutoridade e Papel. Fonte: Autoria Própria (2018). . 52
Figura 24 Entidade Registro e seus atributos. Fonte: Autoria Própria (2018). ... 53
Figura 25 Entidades, atributos e relacionamentos a serem mapeados. Fonte: Autoria Própria (2018). ... 54
Figura 26 Entidades e atributos mapeados em ontologias. Fonte: Autoria Própria (2018). ... 57
Figura 27 Exemplo da estrutura de um mapeamento do D2RQ. Fonte: Cyganiak (2012). ... 58
Figura 28 Trecho de mapeamento de Registro. Fonte: Autoria Própria (2018). ... 59
Figura 29 Mapeamento de RegistroAutoridade. Fonte: Autoria Própria (2018)... 60
Figura 30 Visão HTML de uma Autoridade. Fonte: Autoria Própria (2018). ... 61
Figura 31 Visão RDF (sintaxe Turtle) da mesma autoridade da Figura 30. Fonte: Autoria Própria (2018). ... 62
Figura 32 Propriedades de um RegistroAutoridade. Fonte: Autoria Própria (2018). . 63
Figura 33 Comparação das propriedades de uma Monografia (acima) e um CD-ROM (abaixo). Fonte: Autoria Própria (2018). ... 63
Figura 34 Versão simplificada de RDF/Turtle gerado para um registro de Monografia (à esquerda) e outro de CD-ROM (à direita). Fonte: Autoria Própria (2018). ... 64
Figura 35 Arquitetura geral do projeto "Ligados nos Políticos". Fonte: Araújo (2010). ... 66
LISTA DE QUADROS
Quadro 1 Exemplo de tripla em formato (SUJEITO, PREDICADO, OBJETO). ... 26 Quadro 2 Mapeamento de uma base de dados relacionais para a web. ... 34
LISTA DE TABELAS
LISTA DE SIGLAS
API Application Programming Interface BIBO Bibliographic Ontology
ENEM Exame Nacional do Ensino Médio FOAF Friend of a Friend
HTML Hypertext Markup Language HTTP Hypertext Transfer Protocol IFF Instituto Federal Fluminense
INEP Instituto Nacional de Estudos e Pesquisas Educacionais Anísio Teixeira IRI Internationalized Resource Identifier
JSON-LD JavaScript Object Notation for Linked Data LD4L Linked Data for Libraries
LOD Linked Open Data
MARC Machine-Readable Catalog OWL Web Ontology Language PDF Portable Document Format RAM Random-access memory
RDF Resource Description Framework RDF4J RDF for Java
RIF Rule Interchange Format
SGBD Sistema Gerenciador de Banco de Dados SKOS Simple Knowledge Organization System SPARQL SPARQL Protocol and RDF Query Language SQL Structured Query Language
TCC Trabalho de Conclusão de Curso URI Uniform Resource Identifier URL Uniform Resource Locator
WWW World Wide Web
SUMÁRIO
1 Introdução ... 16 1.1 OBJETIVOS ... 17 1.1.1 Objetivo Geral ... 17 1.1.2 Objetivos Específicos... 18 1.2 JUSTIFICATIVA ... 18 1.3 ORGANIZAÇÃO DO DOCUMENTO ... 18 2 Referencial Teórico ... 20 2.1 WEB SEMÂNTICA ... 20 2.1.1 Linked Data ... 222.2 PADRÕES DA WEB SEMÂNTICA ... 24
2.2.1 Resource Description Framework (RDF) ... 25
2.2.2 SPARQL ... 28
2.2.3 Ontologia ... 29
2.3 CONVERSÃO DO MODELO RELACIONAL PARA RDF ... 31
2.3.1 OpenLink Virtuoso ... 34
2.3.2 RDF4J ... 35
2.3.3 Plataforma D2RQ ... 36
3 Mapeamento Relacional-RDF ... 38
3.1 METODOLOGIA ... 38
3.2 ANÁLISE DA BASE DE DADOS RELACIONAL ... 39
3.2.1 Identificação de Entidades ... 39
3.2.2 Associações de Entidades ... 46
3.2.3 Elaboração de views e seleção de atributos ... 49
3.3 MAPEAMENTO PARA RDF E SELEÇÃO DE ONTOLOGIAS ... 56
3.4 RESULTADO DO MAPEAMENTO EM RDF ... 60
4 Trabalhos Relacionados ... 65
4.1 PUBLICAÇÃO DE DADOS LIGADOS DE POLÍTICOS BRASILEIROS NA WEB ... 65
4.3 CRIAÇÃO E PUBLICAÇÃO DE UM LINKED DATASET SOBRE O SIMPÓSIO
BRASILEIRO DE BANCO DE DADOS ... 67
4.4 PUBLISHING BIBLIOGRAPHIC RECORDS ON THE WEB OF DATA: OPPORTUNITIES FOR THE BNF (FRENCH NATIONAL LIBRARY) ... 67
4.5 CONCLUSÕES ... 68
5 Considerações Finais ... 70
5.1 TRABALHOS FUTUROS ... 70
6 Referências ... 72
APÊNDICE A – Função concat_assunto ... 75
APÊNDICE B – Função return_role ... 76
APÊNDICE C – Função slugify ... 77
APÊNDICE D – View Assuntos ... 78
APÊNDICE E – View Autoridades ... 79
APÊNDICE F – View Eventos ... 80
APÊNDICE G – View Papel ... 81
APÊNDICE H – View Registro_Autoridade ... 82
APÊNDICE I – View Registros ... 83
APÊNDICE J – View tags_subcampos ... 85
1 INTRODUÇÃO
Nos últimos anos, o interesse por aplicações web semânticas tem crescido e atraído empresas e organizações de grande porte. O Facebook, por exemplo, criou o OpenGraph protocol (FACEBOOK, 2017), um protocolo que permite que qualquer página web tenha as mesmas funcionalidades de um objeto dentro do Facebook, e que foi construído com tecnologias semânticas como base.
A Google desenvolveu o Google Knowledge Graph (GOOGLE, 2015), uma base de conhecimento implementada utilizando várias fontes (notadamente Freebase e Wikipédia) conectadas semanticamente com termos da Schema1, um vocabulário criado em esforço conjunto das principais empresas que fornecem serviço de busca na web: Google, Yahoo, Bing e Yandex. O objetivo da Schema é oferecer um vocabulário comum que todos os serviços ofereçam suporte.
Também nesta tendência, desde 2014, grandes bibliotecas, como a Biblioteca do Congresso Norte Americano, iniciaram esforços em conjunto com bibliotecas e pesquisadores das Universidades de Harvard, Cornell, Columbia, Princeton, Iowa e Stanford, através do projeto LD4L2 (Linked Data for Libraries, Dados Ligadas para Bibliotecas, em português) e suas ramificações, a fim de publicar seus conteúdos em formato inteligível por máquina nesta nova versão da Web, chamada de Web Semântica.
A Web Semântica é uma extensão da Web original, na qual a informação recebe significado bem definido, de tal forma que máquinas possam compreendê-lo e, então, executar tarefas "inteligentes" para nos auxiliar (BERNERS-LEE, HENDLER e LASSILA, 2001). Resumidamente, a ideia é enriquecer o conteúdo publicado com metadados formalmente estruturados, seguindo um conjunto de tecnologias e padrões que permitam agentes de software entender o significado (semântica) da informação disponibilizada na Web.
1 http://schema.org/
Posteriormente, em 2006, Tim Berners-Lee propõe o conceito de Linked Data (Dados Ligados, em português), como um “conjunto de diretrizes para publicar e interligar dados estruturados na Web” (HEATH e BIZER, 2011, p. 7), criando a Web de Dados Ligados: uma Web formada por fontes de dados distintas, criando um grande grafo global de dados.
Neste contexto, assim como muitas outras instituições, o Instituto Federal Fluminense (IFF) armazena diversas informações em bases de dados relacionais: quadro de alunos, horários de aula, servidores, e muitas outras informações relevantes. Algumas destas informações, notadamente as que não são de caráter privado, se beneficiariam enormemente quanto maior sua publicidade. Na segunda categoria, temos o acervo da biblioteca, que armazena valioso conhecimento em formato de livros, teses, monografias, dissertações, etc.
Estas produções científicas, atualmente, se encontram circunscritas à interface de busca do atual sistema gerenciador da biblioteca do IFF. No entanto, sua inserção na Web de Dados Ligados nos permitiria explorar livremente esses dados bibliográficos, e até mesmo expandi-los, interligando-os com dados publicados em outras fontes de dados consagradas, de modo a integrar o atual acervo a esta nova Web.
1.1 OBJETIVOS
1.1.1 Objetivo Geral
O objetivo geral deste trabalho é mapear os dados relacionais do acervo da biblioteca central do IFF para o modelo de dados da Web Semântica, o RDF (Resource Description Framework, Framework de Descrição de Recursos, em português) (RDF WORKING GROUP, 2014) que será apresentado na seção 2.2.1.
1.1.2 Objetivos Específicos
• Identificar e extrair as entidades (recursos) chave presentes nos dados relacionais existentes;
o Mapear estes recursos para o modelo RDF, utilizando ontologias (vocabulários) Linked Data de referência;
• Publicar os dados de acordo com os princípios Linked Data;
• Oferecer um SPARQL endpoint público sobre os dados publicados para que outras pessoas possam realizar consultas SPARQL ad-hoc sobre os dados.
1.2 JUSTIFICATIVA
A introdução da biblioteca do IFF no contexto da Web Semântica traz importantes benefícios, como: maior visibilidade em nível global, divulgação da produção bibliográfica, possibilidade de integração com fontes de dados importantes, enriquecendo, pois, o acervo. Por fim, a proposta do presente trabalho vem ao encontro do artigo 8º da Lei de Acesso à Informação (BRASIL, 2011), que reconhece a necessidade de publicar dados governamentais em formatos abertos.
1.3 ORGANIZAÇÃO DO DOCUMENTO
Após esta introdução, este documento está estruturado nos seguintes capítulos: o Capítulo 2 contém o embasamento teórico desta pesquisa, apresentando os conceitos de Web Semântica e Dados Ligados, bem como as tecnologias relacionadas; o Capítulo 3 relata a análise da base de dados da
biblioteca do IFF, a escolha de ontologias apropriadas, a preparação da base de dados e os resultados do mapeamento realizado; finalmente, o Capítulo 4 apresenta as conclusões, considerações finais e sugestões para trabalhos futuros.
2 REFERENCIAL TEÓRICO
Nesta seção, são apresentados os conceitos principais para a compreensão do trabalho realizado, bem como a base teórica sobre a qual o trabalho foi desenvolvido.
2.1 WEB SEMÂNTICA
A Web semântica é uma extensão da atual World Wide Web (WWW), na qual a informação recebe significados bem definidos, permitindo assim que máquinas e humanos trabalhem em cooperação (BERNERS-LEE et al, 2001). E, segundo Salles (2016, p.14):
(...) tem o propósito de desenvolver tecnologias, linguagens, padrões e recomendações para a estruturação de dados e metadados onde a informação publicada na Web é representada com um significado explicitamente definido e de forma legível por máquinas.
Sendo apenas uma extensão, a web semântica se aproveita da infraestrutura já madura e difundida sob a qual a web tradicional é construída (p. ex.: protocolo HTTP) para compartilhar o significado das informações em formato estruturado, e, portanto, legível por máquinas. Esse novo paradigma tem por objetivo permitir que o conteúdo das páginas web sejam processáveis por máquinas de forma que elas possam extrair meta informações de forma análoga à que humanos, que tem capacidade de compreensão de texto, fazem.
De modo simplificado, a Web tradicional funciona como uma série de documentos HTML interligados através de hiperlinks. O ambiente ubíquo e livre da internet permite a qualquer um postar qualquer coisa. Justamente por isso, o volume crescente de novos documentos publicados torna cada vez mais complicado de se extrair informações relevantes aos usuários da web.
Há, portanto, um grande volume de informações disponibilizadas sobre os mais diversos assuntos. Porém, tão importante quanto a informação estar disponível
é ela ser recuperada pelos usuários. Para suprir essa necessidade, surgiram serviços de buscadores como: Google, Yahoo, entre outros. Acerca disso, Ferreira e Santos (2013, p.14) afirmam que:
A falta de estruturação, isto é, a falta de descrição das informações presentes nas páginas Web, fez com que os mecanismos de busca clássicos se tornassem insuficientes para gerenciar a quantidade sempre crescente de conteúdo.
Parte do motivo da insuficiência supracitada é o fato da Web atual ter sido construída de tal forma que os computadores são meros apresentadores das informações contidas nos documentos, sem compreendê-las de fato (JACYNTHO, 2012). E é com esse objetivo que a Web semântica surgiu, propondo um modo padrão para descrever coisas na internet de modo que máquinas possam processá-las, enriquecendo assim a extração de conhecimento úteis e relevantes para uso humano.
Temos, na Figura 1, uma representação da arquitetura da web semântica incluindo as tecnologias consideradas padrão pela W3C (World Wide Web Consortium). Destacam-se, dentre estas, RDF (modelo de dados padrão), SPARQL (linguagem de consulta para dados RDF) e OWL (linguagem para criar ontologias), que serão melhor aprofundadas posteriormente.
2.1.1 Linked Data
Como subconjunto da Web semântica, surge o conceito de Linked Data (Dados Ligados, em português), como uma série de “melhores práticas” para publicar e interligar dados estruturados na Web (BERNERS-LEE, 2009). A ideia é muito simples: por que não publicar e interligar dados diretamente na Web? Em outros termos, em vez de apenas publicar metadados associados a documentos, publicar diretamente os dados, independentemente de páginas web, e interligá-los por meio de links semânticos, criando a chamada Web de Dados Ligados (em inglês, Web of Linked Data).
Em Berners-Lee (2006) foram definidos 4 princípios básicos para a publicação de Dados Ligados, a saber:
1. Use URIs (Uniform Resource Identifier) para nomear os recursos; 2. Use URIs HTTP (Hypertext Transfer Protocol) de forma que estes
recursos possam ser acessados na Web (por pessoas ou agentes de software);
3. Quando uma URI for acessada, retorne alguma informação útil, usando os padrões (RDF, SPARQL);
4. Inclua links para outros URIs, de modo que se possa navegar para outros recursos na Web e obter mais informações (Linked Data Mashup).
Esses 4 princípios buscam garantir a utilização de URIs para identificar recursos na Web, independente de fazer parte do mundo real, ou meramente conceitos abstratos. Além disso, restringe-se ao uso do protocolo HTTP, que, segundo Heath e Bizer (2011) é o mecanismo de acesso universal da Web, ou seja: um padrão bem estabelecido para acessar recursos. Os últimos 2 princípios tratam, respectivamente, de garantir a utilização das tecnologias padrões da Web Semântica e de se estabelecer ligações com outros recursos de outras fontes, de modo a se obter maiores informações acerca deste recurso.
Assim como a Web convencional, a Web de Dados Ligados Abertos (em inglês, Linked Open Data - LOD) vem crescendo rapidamente. Dados abertos são dados publicados sob uma licença aberta, que permita reuso gratuito. Governos, museus, bibliotecas, universidades, entre outros, têm publicado seus dados como Dados Ligados Abertos. Uma das fontes de dados mais reusadas é a DBpedia, que é uma versão em dados ligados do conteúdo da Wikipédia.
Para estimular a publicação de dados abertos ligados, Berners-Lee (2006) também definiu um modelo de classificação de maturidade de dados abertos, baseado em estrelas, descrito a seguir:
★ Disponível na Web (qualquer formato, p.ex. PDF), desde que com uma licença aberta, para que seja considerado Dado Aberto;
★★ A regra anterior, mais: dados estruturados processáveis por máquina (p.ex. Excel em vez de uma imagem digitalizada de uma tabela);
★★★ Todas as regras anteriores, mais: formato não proprietário (p.ex. CSV4 em vez de Excel);
★★★★ Todas as regras anteriores, mais: usar os padrões abertos do W3C (RDF e SPARQL) para identificar os recursos, de modo que as pessoas possam referenciá-los para reuso;
★★★★★ Todas as regras anteriores, mais: ligar seus dados a dados de outras pessoas para prover contexto (Linked Data Mashup)
A topologia da Web de Dados Ligados Abertos, pode ser vista na Figura 2, onde temos várias fontes de dados (círculos) interligadas por links semânticos. Cada círculo representa um dataset que publica seus dados no padrão Linked Data e com licença aberta, fazendo conexão um ou mais dos outros círculos existentes na Figura. A cor indica o tipo de dataset, e o tamanho a quantidade de interconexões. Evolução notável desde 2007, quando foi feita a primeira versão, com somente 12 círculos.
Figura 2 LOD Cloud Diagram. Fonte: Cyganiak et al (2017).
2.2 PADRÕES DA WEB SEMÂNTICA
Um dos principais motivos da Web tradicional ter crescido e se popularizado globalmente é a utilização de padrões previamente definidos para garantir a interoperabilidade como um ambiente universal. Da mesma maneira, para
se atingir o objetivo da Web Semântica, algumas tecnologias foram desenvolvidas ou adaptadas para utilização padrão, conforme visto na Figura 1.
2.2.1 Resource Description Framework (RDF)
Um dos mais importantes aspectos da publicação de dados na Web de Dados é a representação destes dados. Não basta diferentes fontes de dados publicarem e interligarem seus dados, estas devem também compartilhar um modelo de dados padrão, bem como reusar termos semânticos (classes e propriedades) comumente estabelecidos para determinada área de conhecimento para classificar e descrever recursos (entidades, objetos) presentes nos seus dados, garantindo assim, uma interpretação inequívoca entre quem publica e quem consome estes dados.
Segundo Teixeira Neto (2014), RDF é um framework para descrever recursos na web focando em flexibilidade, em detrimento de restrições. É um modelo de dados em grafo, usado para descrever recursos por meio de triplas {recurso propriedade valor} (também conhecidas por: {sujeito predicado objeto}) (JACYNTHO, 2012). Portanto, RDF nos permite definir asserções acerca de recursos, sendo então o modelo de dados padrão da Web Semântica.
De acordo com Ferreira e Santos (2013) documentos RDF são estruturados em forma de um grafo dirigido, ou seja, dois nós ligados por uma aresta direcionada, chamada de arco. A estrutura das triplas é semelhante à de uma frase simples em linguagem natural. Sujeito e objeto são nós e o predicado é um arco. Segundo Cyganiak, Wood e Lanthaler (2014), existem três tipos possíveis de nós em um grafo RDF: URIs, literais e nós em branco.
Dessa forma, passando para o modelo RDF a frase de exemplo “Leonardo Da Vinci é autor de Mona Lisa”, poderíamos representá-la de duas maneiras: como tripla ou grafo RDF, conforme os exemplos a seguir (Quadro 1 e Figura 3).
Quadro 1 Exemplo de tripla em formato (SUJEITO, PREDICADO, OBJETO).
Sujeito Predicado Objeto
http://dbpedia.org/resource/Leonar do_da_Vinci http://purl.org/dc/elements/1 .1/creator http://dbpedia.org/resource/ Mona_Lisa
Fonte: Autoria Própria (2018).
Figura 3 Exemplo de representação em grafo de uma tripla RDF. Fonte: Autoria Própria (2018).
Assim como no exemplo dado, cada item da tripla pode estar localizada em um domínio diferente. Segundo Jacyntho (2012), essa característica é essencial para a Web Semântica, permitindo que recursos de fontes de dados distintas possam ser interligados. Dessa forma, ao acessarem os grafos, as máquinas podem navegar pelos recursos, obtendo mais informações acerca do sujeito em questão. Além dessa, outras duas vantagens são: a facilidade para acrescentar informações acerca do Sujeito (conforme exemplo na Figura 4) e que cada nó de um grafo RDF pode ser simultaneamente sujeito de uma tripla, e objeto de outra.
Figura 4 Grafo RDF com 2 assertivas de mesmo sujeito. Fonte: Autoria Própria (2018).
Na web em geral, cada objeto deve possuir uma URL (Uniform Resource Locator) única, de modo a poder ser recuperado. Cada website, portanto, possui seu endereço único. No contexto da web semântica, cada recurso está associado a um identificador chamada URI ou IRI (Internationalized Resource Identifier), segundo a denominação mais recente. Espera-se que estes sejam únicos e imutáveis.
Convém reforçar, porém, que RDF é um modelo abstrato de dados, ou seja, para se armazenar dados nesse formato, estes devem ser serializado em uma dentre as diversas sintaxes existentes. Pode-se citar, por exemplo, RDF/XML (GANDON e SCHREIBER, 2014), JSON-LD (SPORNY, KELLOGG e LANTHALER, 2014) e Turtle (PRUD’HOMMENAUX e CAROTHERS, 2014). A Figura 5 divide as sintaxes existentes em relação a compatibilidade da versão do modelo RDF.
Figura 5 Sintaxes em relação à compatibilidade com as versões do modelo RDF. Fonte: WOOD (2014).
2.2.2 SPARQL
Tão importante quanto armazenar as informações é ter um método eficiente de recuperar posteriormente. Da mesma forma, dados serializados como RDF também tem uma linguagem de consulta própria denominada SPARQL. De acordo com Harris e Seaborne (2013) O SPARQL pode ser usado para expressar consultas de diversas fontes de dados, sejam os dados armazenados nativamente como RDF ou visualizados como RDF por meio de middleware.
De modo simplificado, SPARQL faz comparação entre grafos. Segundo (PÉREZ, ARENAS e GUTIERREZ, 2006) uma consulta SPARQL é composta de três partes: 1) O padrão a ser comparado, 2) os modificadores e 3) o resultado. A estrutura básica é simples, consistindo somente dos operadores SELECT e WHERE, similar à da linguagem SQL, do modelo relacional. Porém, a flexibilidade do modelo RDF associado às particularidades do SPARQL, que foi concebido já prevendo consulta em fontes de dados distintas, tornam este uma linguagem robusta capaz de realizar diversos tipos de processamento com os dados obtidos. Entretanto, SPARQL não é somente uma linguagem de consulta, e sim “um conjunto de
especificações que fornecem idiomas e protocolos para consultar e manipular o conteúdo do grafo RDF na Web ou em uma RDF store” (W3C, 2013).
2.2.3 Ontologia
Oriundo da filosofia, o termo ontologia, no contexto da web semântica, porém, se refere a descrição formal de um conjunto de conceitos e seus relacionamentos. Em Jacyntho (2012, p. 54) temos que uma ontologia é criada para um domínio específico e contém conceitos ou classes e relacionamentos entre essas classes, que podem ser expressos por meio de hierarquias: superclasses e subclasses. Em outras palavras: é o conjunto da definição de conceitos e a forma que estes se relacionam, dentro de um domínio específico.
É uma forma de representação do conhecimento em formato digital e peça chave da Web semântica, já que é através dos termos definidos por elas que se atribui a semântica correta dos recursos a serem descritos. Em uma tripla RDF este assume a posição do predicado ou propriedade, responsáveis diretos por dizerem como o sujeito e o objeto estão relacionados.
O fato de cada ontologia ter um domínio bem específico, torna possível a desambiguação de termos de grafia semelhante, ou seja, é possível distinguir termos homógrafos. Também é possível relacionar termos distintos, estabelecendo uma relação de equivalência entre eles. Essa é uma característica essencial quando se tem por objetivo interligar informações provenientes de fontes distintas e que talvez chamem a mesma coisa (conceito) por termos distintos.
Segundo Martins (2002) ao se elaborar uma ontologia deve-se considerar os seguintes elementos:
1. Entidades, que descrevem conceitos (elementos de um domínio estudado) e providenciam uma representação lógica;
3. Relações, que descrevem as ligações entre objetos no modelo (entidades e atributos);
4. Restrições, condições que o projetista impõe sobre as entidades, atributos ou relações.
Martins (2002) afirma ainda que uma ontologia consiste de uma taxonomia, responsável por definir classes, subclasses e os relacionamentos entre eles, e um conjunto de regras de inferência, que fornece um mecanismo de manipulação dos objetos da taxonomia através de raciocínio lógico. Essa informação inclusive condiz com o que se observa na Figura 1.
Existem diversas linguagens associadas com a construção de ontologias (também chamadas vocabulários): RDF Schema (RDFS) (BRICKLEY e GUHA, 2014), OWL (W3C, 2012), RIF (KIFER e BOLEY, 2013) e SKOS (MILES e BECHHOFER, 2009). Cada uma destas com um foco específico.
A linguagem OWL (Web Ontology Language) está disponível em 3 versões:
1. OWL full - É a linguagem completa, incluindo todas as primitivas de OWL. A grande vantagem é ser totalmente compatível com RDF, tanto em sintaxe quanto em semântica: qualquer documento RDF válido é também um documento OWL Full válido.
2. OWL DL – Focado em eficiência computacional, esta versão restringe a forma como construtores de OWL e RDF podem ser usados. A vantagem desta é permitir um suporte a raciocínio eficiente. A desvantagem, por sua vez, é a perda de compatibilidade com RDF.
3. OWL lite – É uma restrição sobre o OWL DL. A principal vantagem é uma maior facilidade tanto de compreensão quanto de implementação para desenvolvedores de ferramentas. A desvantagem sendo a expressividade restringida.
2.3 CONVERSÃO DO MODELO RELACIONAL PARA RDF
O modelo relacional é um modelo de dados largamente adotado no ambiente de desenvolvimento computacional, e especialmente na web. Independente do sistema gerenciador de banco de dados utilizado, e apesar da crescente adoção de base de dados com modelos não-relacionais tais como NoSQL, orientado a objeto ou orientado a documentos, a imensa maioria dos dados produzidos e armazenados na web ainda estão no formato relacional.
Ao se considerar então o volume significativo de dados atualmente armazenados nesse paradigma, o passo lógico a seguir é estabelecer uma forma de conversão entre o modelo relacional e o RDF, aproveitando-se assim toda informação pré-existente. Temos na Figura 6 uma representação gráfica da correspondência entre o modelo relacional (acima) e o modelo RDF (abaixo).
Na parte superior temos um registro da tabela de exemplo, Pessoa, e na parte inferior, a representação em grafo do registro. Dentro do namespace definido (http://www.exemplo.org/schema), o caminho utilizado para se identificar aquela pessoa específica foi: nome da tabela/id do registro. A classe (no caso, type, definido com termos da sintaxe RDF) Person, definido pela ontologia FOAF (friend of a friend) e as propriedades (atributos) deste registro de pessoa definidas usando termos da ontologia: name para o nome, mbox para e-mail.
Figura 6 Conversão entre um registro de tabela relacional em um grafo RDF. Fonte: Autoria Própria (2018).
Existem duas maneiras de se abordar esse problema: conversão para triple stores e RDB2RDF. O primeiro caso consiste de se reescrever e importar toda estrutura e dados do modelo relacional e passar a adotar o modelo RDF nativamente, algo que para sistemas maiores e complexos dificilmente seria prático. Já o segundo consiste em utilizar R2RML (DAS, SUNDARA e CYGANIAK, 2012) ou
Direct Mapping (ARENAS et al, 2012) para se criar uma visão RDF dos dados relacionais.
Por motivos de fácil dedução, o caso específico dos desenvolvedores de sistemas pré-existentes, a solução mais viável é RDB2RDF. Nesta situação utiliza-se o direct mapping para se extrair automaticamente a estrutura e o esquema da base de dados relacional informada como entrada. Esse mapeamento, portanto, será um mero reflexo da estrutura original.
R2RML é “uma linguagem para expressar mapeamentos customizados de bancos de dados relacionais para RDF” (DAS, SUNDARA e CYGANIAK, 2012). Ao contrário do método anterior, este não é automático e requer conhecimento acerca do esquema a ser mapeado, de ontologias e de mapeamento. Obviamente que, ao menos de início pode-se utilizar direct mapping para gerar um mapeamento genérico que então será customizado, e, de toda maneira, exige um nível de expertise para se obter um resultado satisfatório.
Em Berners-Lee (2009) o autor faz algumas comparações entre os dois modelos e afirma que um registro corresponde ao sujeito, o nome de um campo (coluna) é o predicado e o campo de registro (célula da tabela) corresponde ao objeto. Temos então que o conjunto (Sujeito, Predicado, Objeto) é equivalente ao conjunto (Registro, Coluna, Célula). Além desta conclusão, Berners-Lee propõe uma estratégia para se disponibilizar uma base de dados na Web. O exemplo consta no Quadro 2 abaixo e considera http://www.acme.com/catalog/schema/employees/ como URI radical para a base de dados employees do esquema.
Quadro 2 Mapeamento de uma base de dados relacionais para a web.
Adaptado de: Berners-Lee (2009).
Realizados os paralelos necessários, a seguir serão apresentadas algumas das principais ferramentas que disponibilizam algum tipo de conversão RDB2RDF.
2.3.1 OpenLink Virtuoso
O OpenLink Virtuoso3 é um híbrido de middleware e mecanismo de banco de dados que combina a funcionalidade de bancos de dados relacional, objeto-relacional e virtual, RDF, XML, texto livre, servidor de aplicativos da Web e funcionalidade de servidor de arquivos em um sistema único. Como pode ser visto na Figura 7 o sistema oferece diversas funcionalidades integradas em si. Existe também disponível uma versão paga.
3 https://github.com/openlink/virtuoso-opensource
Nível URI Relativa Exemplo
Tabela /employees/employee employee
Coluna /employees/employee/shoe employee/shoe
View /employees/employee2 employee2
Linha /employees/employee/rowid=123 employee/rowid=123 Célula /employees/employee/rowid=123;col=s
hoe
employee/rowid=123; col=shoe
Figura 7 Visão geral da Arquitetura do OpenLink Virtuoso. Fonte: OpenLink Software (2015).
2.3.2 RDF4J
Conhecido previamente como Sesame, é um framework open source Java para processar dados RDF. Inclui análise, armazenamento, inferência e consulta dos dados. Oferece também uma API que pode ser conectada a todas as principais soluções de armazenamento RDF e SPARQL endpoints.
O RDF4J4 oferece dois tipos de bancos de dados RDF próprios:
1. Armazenamento em Memória: Trata-se de um banco de dados RDF transacional que usa a memória principal da máquina, com
sincronização persistente opcional para o disco. O uso da memória é escalado de acordo com quantidade de RAM disponível e é ideal para conjuntos de dados pequenos.
2. Armazenamento Nativo: É um banco de dados RDF transacional e uma solução mais escalonável do que o anterior. Consume menos memória e oferece melhor consistência e durabilidade. Recomendado a conjuntos de dados de tamanho médio na ordem de 100 milhões de triplas.
Além dos nativos, conta com soluções de armazenamento de terceiros também disponíveis. Suporta totalmente SPARQL 1.1 para consultas expressivas e oferece acesso transparente a repositórios RDF remotos. Oferece suporte a todos os formatos de arquivos RDF, incluindo: RDF/XML, Turtle, N-Triples, N-Quads, JSON-LD, TriG e TriX.
2.3.3 Plataforma D2RQ
A Plataforma D2RQ5 é um sistema para acessar bancos de dados relacionais como grafos RDF virtuais de somente leitura. Oferece acesso baseado em RDF ao conteúdo de bancos de dados relacionais sem necessidade de importa-lo em uma RDF triple store. Consiste de:
1. Linguagem de Mapeamento: uma linguagem de mapeamento declarativo para descrever a relação entre uma ontologia e um esquema de dados do modelo relacional.
2. Motor D2RQ: um plug-in para o Jena Semantic Web, que usa os mapeamentos para reescrever as chamadas da API do Jena para consultas SQL no banco de dados e passa os resultados da consulta para as camadas superiores das estruturas.
5 http://d2rq.org/
3. Servidor D2RQ: um servidor HTTP que fornece uma visualização de dados vinculados, uma exibição de HTML para depuração e um endpoint do protocolo SPARQL sobre o banco de dados.
Fazendo utilização de um arquivo de mapeamento (que em si é um arquivo RDF serializado em Turtle) expresso usando termos do namespace D2RQ, a plataforma se conecta à base de dados relacional indicada. Este mapeamento define um grafo RDF virtual que contém informações do banco de dados. O grafo gerado pode ser acessado através de um SPARQL endpoint, como dump RDF ou através de uma interface HTML disponibilizada pelo Servidor D2R, além de um acesso à API da Jena para bancos de dados mapeados por D2RQ. A Figura 8 mostra um esquema geral da plataforma e suas ferramentas.
3 MAPEAMENTO RELACIONAL-RDF
3.1 METODOLOGIA
O passo inicial consistiu de uma análise da estrutura original da base que armazena os dados do acervo da biblioteca do IFF. Identificando tabelas, suas relações, e as entidades às quais estas equivaleriam. Em um processo iterativo e incremental, as tabelas de interesse e entidades foram sendo identificadas por meio de seu conteúdo e relacionamentos com outras tabelas de interesse. Para fins de organização, porém, este trabalho considera como marco final desta etapa o momento que se identificou a principal entidade dentro do escopo deste projeto: Registro, correspondente às obras deste acervo, já que toda as entidades identificadas posteriormente são devido à relação destas com as obras, que se encaixavam no contexto definido para o referido trabalho.
Na fase de análise foram identificados três tipos de Entidades: Simples (em que uma única tabela contém em suas estruturas todos os atributos daquela entidade), compostas (que são obtidas pela combinação de tabelas distintas) e derivadas (geradas a partir de tags e/ou conjuntos de tags específicas). Estas entidades ditas complexas, portanto, precisavam ser normalizadas à nível do banco de dados de modo a facilitar o mapeamento a ser realizado. Para tal, foram criadas views que então corresponderiam às entidades, reunindo todos atributos relevantes para estas.
Encerrada a etapa de normalização da base de dados, e tendo um modelo claro das entidades e seus atributos, bem como os relacionamentos entre elas, cuidadosamente foram estudadas as ontologias publicadas na web de modo a selecionar a mais adequada para descrever os dados existentes. Utilizando então a ferramenta escolhida para realizar o mapeamento relacional-RDF foi gerado, automaticamente, um arquivo em Turtle contendo um mapeamento genérico da base de dados inteira.
O arquivo gerado foi posteriormente editado de modo a desconsiderar as entidades não relevantes, incluir as ontologias selecionadas, associar os atributos adequados e estabelecer corretamente os relacionamentos entre as entidades. Esta é a última fase do mapeamento propriamente dito, na qual o arquivo de mapeamento chega à versão final e a plataforma D2RQ gera a visão RDF a partir dos dados mapeados, utilizando as ontologias indicadas no arquivo.
Ao longo deste trabalho duas visões principais auxiliaram no processo de análise e seleção das informações. A visão de tabelas e seus relacionamentos, utilizada para identificar como a estrutura relacional se organizava na base de dados, e a visão de Entidades, que refletia o conteúdo da visão relacional, mas considerando as classes dos dados do ponto de vista prático, e não do modo que os dados se encontravam armazenados. É através das muitas versões dessas visões que o aspecto iterativo e incremental do trabalho é melhor visualizado, evoluindo até chegar à uma versão satisfatória, encapsulando todas as entidades e tabelas chave identificadas.
3.2 ANÁLISE DA BASE DE DADOS RELACIONAL
O primeiro passo do processo de mapeamento é analisar a estrutura do banco de dados relacional corrente da biblioteca do IFF, a fim de identificar as entidades, seus atributos e relacionamentos a serem mapeados. Portanto, é preciso ter acesso à base de dados a ser investigada. Com este intuito, uma cópia da base de dados foi obtida e restaurada em uma máquina de trabalho já configurada com o Sistema Gerenciador de Banco de Dados (SGBD) adequado, o Microsoft SQL Server. Encerrada a restauração bem-sucedida, o ambiente de análise estava devidamente pronto.
Esta etapa iniciou com uma análise preliminar da estrutura de dados relacionais existente. Constatou-se que a base de dados continha ao todo 367 tabelas, 24 views e 33 funções. Toda esta estrutura existente serve como base para o funcionamento do sistema gerenciador da biblioteca do IFF, o SophiA6, que, entre outras informações, contém o acervo de obras. Todas as entidades serão grafadas em itálico, para assim diferenciá-las das tabelas, grafadas em caixa alta.
Em vista do elevado número de itens, para que uma visualização completa das tabelas e seus relacionamentos em um diagrama fosse eficiente, definiu-se um critério para selecionar tabelas para análise. O critério escolhido, inicialmente, foi o nome das tabelas, resultando na seleção das tabelas EDITORAS, MIDIAS, OBRA, PERIODICO e REGISTRO_BIBLIOGRAFICO, como pode ser visto na Figura 9.
Figura 9 Visualização em diagrama das tabelas EDITORAS, MIDIAS, OBRA, PERIODICO e REGISTRO_BIBLIOGRAFICO. Fonte: Autoria Própria (2018).
Com exceção de EDITORAS, todas as tabelas se relacionam, por meio da tabela central REGISTRO_BIBLIOGRAFICO. Considerando seus registros, a tabela EDITORAS contém informações sobre editoras, conforme mostra a Figura 10, logo, deve se relacionar às obras de outra forma que não fora utilizada neste trabalho.
6 https://www.sophia.com.br
Figura 10 Visualização da Tabela EDITORAS à esquerda, e alguns de seus registros à direita. Fonte: Autoria Própria (2018).
Além desta, apenas MIDIAS foi identificada como entidade, contendo (entre outras informações pouco relevantes) dados sobre os tipos das obras registradas, conforme a Figura 11. Desta forma, as tabelas EDITORAS e MIDIAS equivalem às duas primeiras entidades identificadas: Editora e Mídia. As tabelas OBRA, PERIODICO e REGISTRO_BIBLIOGRAFICO, à primeira vista, não continham informações consideradas relevantes.
Figura 11 Trecho da tabela MIDIAS ao lado de uma visualização dos primeiros registros. Fonte: Autoria Própria (2018).
Retomando o diagrama da Figura 9, nota-se que tanto PERIODICO quanto OBRA se relacionam com REGISTRO_BIBLIOGRAFICO. Esta última, porém, não possui chave primária própria, tendo somente uma chave estrangeira, referenciando outra tabela: REGISTRO. Conclui-se assim que a tabela REGISTRO_BIBLIOGRÁFICO é uma extensão da tabela REGISTRO. Esta, porém,
contém apenas dados como data de cadastro, de atualização, mas sem conter informações de obras em si.
Presume-se, em projetos de bases de dados, que os nomes das tabelas sejam relacionados a seu conteúdo. Considerando esta boa prática, decidiu-se por analisar melhor as relações, tendo como referência a tabela REGISTRO_BIBLIOGRAFICO, visto que se é a tabela central dos relacionamentos identificados na Figura 9.
Elaborando um novo diagrama, tendo como ponto de partida a tabela REGISTRO_BIBLIOGRAFICO e acrescentando todas as tabelas a ela associadas, temos uma visão mais ampla do armazenamento de seu conteúdo. A seguir, foram removidas da visualização as tabelas fora do escopo, produzindo um diagrama cujo resultado consta na Figura 12. Nota-se que, além da tabela MIDIAS, novas tabelas
foram selecionadas para análise, a saber: AREAS,
REGISTRO_BIBLIOGRAFICO__SUB, SUBAREAS e IDIOMAS.
Figura 12 Tabelas de interesse associadas à REGISTRO_BIBLIOGRÁFICO. Fonte: Autoria Própria (2018).
Com a intenção de se compreender melhor as descobertas feitas até então, passou-se à análise das views existentes na base de dados. Três delas foram destacadas para observação mais atenta, AUTORES, OBRAS e VW_ACERVO, que, após visualização de conteúdo, comprovaram conter as informações que seus nomes sugerem. Ao se realizar uma análise do script gerador de cada view foi possível identificar de quais tabelas as informações estavam sendo extraídas, lançando luz à forma que as tabelas identificadas anteriormente (e outras que não haviam sido consideradas) se relacionam para armazenar seus dados.
Figura 13 Consulta SQL da view do sistema AUTORES. Fonte: Autoria Própria (2018).
A consulta SQL exibida na Figura 13 retorna dados das tabelas
INSTITUICAO, AUTORIDADE_TAG, AUTORIDADE_TAG_DADO e
AUTORIDADE_SUBCAMPO. Conclui-se desta forma que estas contêm informações referentes a autores. As views OBRAS e VW_ACERVO aparentam ter visões distintas da mesma fonte de dados, mas como OBRAS retornar campos como título, subtítulo e editora fez com que esta fosse a escolhida para se efetuar a análise. Por ser extensa demais, apenas algumas subconsultas serão apresentadas, de modo a compreender como esta view foi construída.
Figura 14 Subconsultas da view OBRAS responsável por retornar colunas TITULO e SUBTITULO. Fonte: Autoria Própria (2018).
Ambas as subconsultas da Figura 14 combinam informações das tabelas,
REGISTRO_TAG, REGISTRO_TAG_DADO, REGISTRO_SUBCAMPO e
REGISTRO. Nota-se, inclusive, que a subconsulta da coluna SUBTITULO é quase idêntica à da coluna TITULO, a única diferença entre elas sendo o conteúdo do trecho “S.SUBCAMPO=”. Observando a consulta como um todo, nota-se que todas as subconsultas possuem a mesma estrutura, tendo diferenças apenas nos trechos “C.TAG =” e “S.SUBCAMPO=” (C sendo um alias da tabela REGISTRO_TAG e S de REGISTRO_SUCAMPO).
Figura 15 Visualização das ligações entre as tabelas REGISTRO, REGISTRO_TAG, REGISTRO_TAG_DADO, REGISTRO_SUBCAMPO. Fonte: Autoria Própria (2018).
O diagrama da Figura 15 mostra como estas quatro tabelas se associam. Comparando as subconsultas da Figura 14 com o diagrama da Figura 15, conclui-se que cada Registro possui diversas tags associadas a ele, que então são associadas a subcampos, que contém, por fim, o valor referido. Uma mesma tag pode ser associada mais de uma vez com subcampo distinto, modificando assim o significado do dado. Para melhor exemplificar, segue uma consulta SQL de exemplo nas Figuras 16 e 17 contendo, respectivamente, um join das tabelas da Figura 15 e o resultado da mesma.
Figura 16 Exemplo de consulta agrupando todas tags e subcampos para cada registro. Fonte: Autoria Própria (2018).
Figura 17 Resultado da consulta da Figura 16 contendo todas tags e subcampos referentes ao registro de ID 2. Fonte: Autoria Própria (2018).
Assim como REGISTRO_BIBLIOGRAFICO, as tabelas da Figura 15 funcionam como uma extensão dos dados salvos em REGISTRO. Foi identificado, desta forma, o conjunto de tabelas que contém os dados das obras do acervo. Como esta fase inicial busca somente identificar possíveis entidades, este conjunto de tabelas será revisitado posteriormente para serem melhor compreendidas.
Sabe-se que as tabelas IDIOMAS, MIDIAS, AREAS e REGISTRO_BIBLIOGRAFICO__SUB (responsável por estabelecer a ligação com SUBAREA), conforme a Figura 12, se relacionam diretamente com REGISTRO_BIBLIOGRAFICO, que por sua vez, é extensão de REGISTRO. Temos então listado a seguir as primeiras entidades identificadas até então: Autoridade, Área, Editora, Idioma, Mídia, Subárea e Registro.
3.2.2 Associações de Entidades
Na etapa anterior, algumas entidades foram identificadas. Estas entidades somente têm relevância para este trabalho devido à sua relação com as obras do acervo, representada pela entidade Registro. Em outras palavras é preciso não somente identificar a tabela (ou conjunto de tabelas) associada a uma entidade, mas também compreender de que forma estas se conectam aos registros.
Partindo da tabela EDITORA, que até então se encontrava isolada, sem conexões com Registro, e adicionando suas tabelas associadas, surgiu uma tabela chamada REGISTRO_SUBCAMPO__EDITORA que acabou por ser a responsável por interligar um Registro à sua Editora. De forma semelhante, apenas observando tabelas com o radical comum "REGISTRO_SUBCAMPO"_, foi possível identificar uma nova entidade, Coleção, através da sua tabela associativa, REGISTRO_SUBCAMPO__COLECAO, bem como a responsável por conectar Autoridade (REGISTRO_SUBCAMPO__AUTORIDADE).
Encerra-se então esta etapa tendo identificado as tabelas de ligação de todas as entidades identificadas até esta etapa. Com base nestas descobertas, foi elaborado um diagrama (Figura 18), contendo as entidades relevantes para o trabalho. Conforme dito anteriormente, todas as entidades são ligadas à entidade Registro (obra), cada uma complementando as informações desta.
Figura 18 Diagrama de entidades relacionadas à entidade Registro. Fonte: Autoria Própria (2018).
Em contraposição à visão abstrata da Figura 18, temos a Figura 19 que mostra a correspondente estrutura física da base de dados. Comparando as duas figuras, pode-se compreender melhor a modelagem desses dados, além de se identificar visualmente quais tabelas funcionam como tabela associativa para cada entidade. Ao todo, cinco tabelas associam as sete entidades: REGISTRO_SUBCAMPO__EDITORA, REGISTRO_SUBCAMPO__AUTORIDADE,
REGISTRO_SUBCAMPO__COLECAO, REGISTRO_BIBLIOGRAFICO__SUB e
Figura 19 Diagrama contendo tabelas associativas e associadas à tabela Registro. Fonte: Autoria Própria (2018).
Idealmente, não haveria diferenças grandes entre os diagramas das Figuras 18 e 19, sendo somente visualizações diferentes. Já se sabe, porém, que Registro e Autoridade possuem seus dados principais fragmentados em tabelas com
o padrão: ENTIDADE, ENTIDADE_TAG, ENTIDADE_TAG_DADO e
ENTIDADE_SUBCAMPO. Esse nível de granularidade torna extremamente difícil de se mapear os dados de forma direta. A solução encontrada para contornar este
problema foi utilizar o recurso de views para agregar os dados relevantes destas entidades, customizando para a necessidade deste trabalho, já que as views pré-existentes eram menos completas que o desejado.
3.2.3 Elaboração de views e seleção de atributos
O processo de elaboração de uma view envolve, a princípio, descobrir de onde serão extraídos os dados relacionados à entidade ao qual irá corresponder. Com o uso de uma consulta obtém-se todas as colunas, tags e subcampos em questão. A seguir, interpreta-se o resultado obtido, fazendo a devida filtragem de modo a selecionar somente os dados relevantes para descrever a entidade, vindo a se tornar seus atributos.
Para fins de clareza, adota-se a partir deste ponto o termo tag-subcampo para identificar cada conjunto específico de associação de tag a subcampo (p. ex.: 245a, para tag 245, subcampo ‘a’). Esta é a estrutura utilizada no formato MARC (Machine Readable Cataloging)7 , criado pela Biblioteca do Congresso Norte Americano ao final dos anos 60 com objetivo de padronizar a representação descritiva automatizada dos registros bibliográficos, permitir a troca das informações bibliográficas entre bibliotecas e possibilitar a catalogação cooperativa.
7 https://www.loc.gov/marc/
Figura 20 Tabelas relacionadas à Autoridade. Fonte: Autoria Própria (2018).
Na Figura 20 temos um diagrama com as tabelas principais de Autoridade, muito semelhante à estrutura da consulta da Figura 13. Elaborada a consulta inicial, e finalizado o processo de filtragem das informações, chegou-se a um resultado satisfatório para comporem os atributos da view correspondente à entidade Autoridade (autor), nomeada view_autoridades (disponível como Apêndice E). Os atributos selecionados para esta entidade podem ser vistos na Figura 21.
Figura 21 Lista de atributos de Autoridade. Fonte: Autoria Própria (2018).
dados de Autoridade foi compreendido como semanticamente distinto, originando uma nova entidade: Evento. Esta, conforme o nome sugere, contém dados acerca de eventos variados. Armazenados sob a tag 111 e seus subcampos, os atributos podem ser observados na Figura 22. A view correspondente foi nomeada view_eventos (disponível como Apêndice F), contendo três subcampos específicos associados à tag 111.
Figura 22 Atributos da entidade Evento. Fonte: Autoria Própria (2018).
Encerrada a análise mais aprofundada dos dados de Autoridade, passa-se à entidade Registro, entidade principal do trabalho. Já passa-se ressaltou o quanto a estrutura de armazenamento de Registro é complexa, considerando que existem 41 tabelas com o prefixo REGISTRO_. Para contornar essa fragmentação intensa e simplificar a consulta optou-se por criar uma view auxiliar, que não corresponde a nenhuma entidade, servindo somente para se obter todas as tags-subcampos dos registros. Esta view foi elaborada tomando por base a consulta da Figura 16 e foi nomeada view_tags_subcampos (disponível como Anexo J).
Em relação a Registro, 85 tags-subcampos distintas estavam sendo utilizadas para descrever seus dados. Assim como ocorreu com Autoridade, porém, algumas peculiaridades foram sendo encontradas. A principal delas a respeito da associação de Autoridades à Registros. Inicialmente, achava-se que a tag-subcampo 100a era a única responsável por identificar as autoridades dos registros, mas é um pouco mais complexo que isso.
Foi descoberto que, no caso de mais de um autor para determinado registro, um deles era considerado o principal e identificado com 100a (ou algum
outro da mesma família. p. ex.: 110a, 130a) e outros colaboradores eram identificados através da família de tags 700, 710, 711 e 730. Estas tags se associam ao subcampo ‘a’, indicando o nome da autoridade referenciada, e ao subcampo ‘e’, que identifica o papel que aquela autoridade realizou na produção daquele registro. O subcampo ‘e’ identifica papéis tais como: coautor, orientador, ilustrador, adaptador, tradutor, entre outros.
Essa descoberta revelou uma situação distinta do que se pensava inicialmente a respeito dessa associação. O fato da associação, quando identificada pelas tags-subcampos entre 700 e 730, ser tipificada fez com que fosse necessário se incluir duas entidades novas: Papel e RegistroAutoridade (Figura 23). A primeira identificando os diferentes papéis que uma autoridade pode exercer, e a segunda representando a transformação da associação em entidade necessária pela própria inclusão de papel. As views correspondentes: view_registro_autoridade e view_papel estão disponíveis na íntegra como Apêndice G e H, respectivamente.
Figura 23 Atributos de RegistroAutoridade e Papel. Fonte: Autoria Própria (2018).
As entidades RegistroAutoridade e Papel (Figura 23) são ligadas, com RegistroAutoridade servindo de intermediária entre Registro, Autoridade e Papel. Papel é uma entidade simples, com dois atributos apenas. Label contendo somente
o conteúdo original da tag-subcampo que descreve o papel e slug gerado a partir do outro, aplicando-se uma função slugify (disponível como Apêndice C) criada para se substituir espaços e caracteres especiais. Este último atributo é utilizado como identificador e é referenciado por RegistroAutoridade. Para RegistroAutoridade, foram combinados os dados da view_tags_subcampos e a tabela REGISTRO_SUBCAMPO__AUTORIDADE. Para referenciar o papel, uma segunda função teve que ser criada e nomeada return_role (disponível na íntegra como Apêndice B).
Figura 24 Entidade Registro e seus atributos. Fonte: Autoria Própria (2018).
Retomando a elaboração da view da entidade Registro (Figura 24), a maior e mais complexa de todas, uma última função chamada concat_assunto (disponível na íntegra como Apêndice A) foi criada para agrupar os dados do atributo de Registro, assunto. Foi criada uma view auxiliar view_assunto (disponível como Apêndice D), apenas com o ID do registro associado e a descrição do assunto em. Isso se fez necessário porque um Registro pode ter mais de um assunto associado
usando a tag-subcampo 650a. Esta view além das tags-subcampos escolhidas, também contém as referências para as entidades a ela associadas: Área, Coleção, Editora, Evento, Idioma, Mídia e Subárea. A view_registros está disponível como Apêndice I.
As entidades a serem mapeadas para RDF, seus atributos e relações encontram-se representadas na Figura 25, já considerando quais serão mapeados. Também abaixo, na Tabela 1, temos listadas todas as entidades identificadas, com uma breve descrição do que esta entidade representa no contexto deste trabalho. Todos os códigos disponibilizados como apêndices encontram-se também publicados no GitHub8.
Figura 25 Entidades, atributos e relacionamentos a serem mapeados. Fonte: Autoria Própria (2018).
Tabela 1 Descrição Resumida da representação de cada entidade mapeada.
Fonte: Autoria Própria (2018).
Entidade Descrição
Área Grande área do conhecimento relacionada ao Registro, p. ex.: Ciências Sociais Aplicadas.
Subárea Especificação dentro de uma área de conhecimento, p. ex.: Administração.
Autoridade Pessoas ou instituições que contribuíram para a produção de um registro.
Coleção Identificação de um conjunto relacionado de registros, sejam em série ou não.
Editora Editora responsável pela publicação do registro.
Evento Evento relacionado ao registro.
Idioma Idioma em que o registro está disponível.
Mídia Tipo de material em que o Registro está disponível, p. ex.: Tese de Mestrado, TCC, Livro, etc.
Registro Obra pertencente ao acervo da Biblioteca.
RegistroAutoridade Entidade associativa, identificando colaboradores (autoridades) e papéis associados ao registro.
Papel Diferentes papéis que uma ou mais autoridades desempenham com relação a um registro.
3.3 MAPEAMENTO PARA RDF E SELEÇÃO DE ONTOLOGIAS
Para mapear para RDF a estrutura construída na etapa anterior, a ferramenta escolhida foi o D2RQ. Citada no Capítulo 2 brevemente, com uma visão geral da plataforma D2RQ apresentada na Figura 8, o D2RQ utiliza um arquivo de mapeamento para gerar uma visão RDF da estrutura da base de dados relacional existente, descrevendo toda a fonte de dados mapeando cada entidade para uma classe de ontologia, e seus atributos para propriedades ontológicas. Tanto as propriedades, quanto as classes associadas no arquivo de mapeamento gerado automaticamente pelo D2RQ são genéricas, nomeadas a partir da própria estrutura relacional em questão. A partir deste arquivo gerado automaticamente pelo próprio D2RQ que a fase de mapeamento se inicia.
Sabe-se que, cada entidade no diagrama da Figura 25 corresponde a uma view ou tabela, portanto, todo o restante do mapeamento gerado automaticamente foi removido por não pertencer ao escopo definido. Como views não tem recursos de tabelas reais tais como chave primária, chave estrangeira ou índices, as referências tiveram que ser apontadas manualmente, utilizando a linguagem de mapeamento do D2RQ.
O catálogo Linked Open Vocabularies (ONTOLOGY ENGINEERING GROUP, 2018) foi consultado para identificar os termos mais apropriados para descrever cada propriedade das entidades identificadas a serem mapeadas, dentro do contexto do trabalho. Ao todo, três vocabulários foram utilizados: FOAF, SKOS e Schema.
A ontologia principal foi a Schema (SCHEMA.ORG COMMUNITY GROUP, 2018), utilizada para descrever a maior parte das classes e propriedades mapeadas. O motivo da escolha se deu principalmente por dois motivos: possibilidade de descrever de forma mais similar a relação entre Autoridades e Registros, e como bônus, ser oficialmente suportada e desenvolvida pelos principais serviços de busca. FOAF e SKOS (W3C, 2012) foram utilizadas para descrever os itens que não puderam ser descritos com Schema. A Figura 26 mostra uma visão
geral das entidades identificadas, os atributos e os respectivos mapeamentos em classes e propriedades das ontologias selecionadas.
Figura 26 Entidades e atributos mapeados em ontologias. Fonte: Autoria Própria (2018).
A linguagem de mapeamento utilizada segue um padrão de notação que se encontra exemplificada na Figura 27. Neste exemplo há duas entidades: Paper e Author, com seus atributos associados a termos de ontologias, e uma referência para o Author de um Paper. Esta estrutura, embora muito mais simples, serve para compreender a linguagem de mapeamento da ferramenta D2RQ.
Figura 27 Exemplo da estrutura de um mapeamento do D2RQ. Fonte: Cyganiak (2012).
Cada tabela dentro de uma base de dados se torna um ClassMap e cada ClassMap é relacionada a uma ou mais classes de ontologia(s). No exemplo acima, Paper é da classe Text, descrita no vocabulário dcmi, e Author é da classe Person, descrita na ontologia foaf. Os termos belongsToClassMap e refersToClassMap servem para, respectivamente, identificar um novo atributo (PropertyBridge) e referenciar um outro ClassMap (estabelecendo um relacionamento). Já o termo property identifica a propriedade ontológica utilizada. Todo o mapeamento se utiliza desses itens básicos para descrever o mapeamento entre a base relacional e o modelo RDF.
D2RQ oferece três diferentes visões somente leitura sobre os dados mapeados: RDF e SPARQL, para máquinas, e HTML, para humanos. No caso das entidades oriundas de tabelas, somente foram modificados os valores em d2rq:class e d2rq:property, além de adequar o padrão de URIs para seguir o adotado.
No caso das entidades Autoridade, Registro, RegistroAutoridade, Evento e Papel, oriundas de views, foi necessário identificar manualmente todas as referências. Na Figura 26, somente três entidades referenciam outras: Subárea, Registro e RegistroAutoridade. Como Subárea é uma tabela, sua chave estrangeira foi corretamente identificada e seu mapeamento serviu como base para criar os mapeamentos das outras duas entidades, cujos detalhes serão apresentados a seguir.
Figura 28 Trecho de mapeamento de Registro. Fonte: Autoria Própria (2018).
Na Figura 28, temos um trecho do mapeamento de Registro com duas de suas chaves estrangeiras, uma apontando para Subárea e outro para RegistroAutoridade. Ambos correspondendo aos vocabulários propostos na Figura 25. Repare que, assim como no exemplo dado, utiliza-se o termo d2rq:refersToClassMap para identificar o ClassMap da entidade referenciada, e d2rq:join para apontar essa mesma referência no banco de dados.
A seguir, na Figura 29, temos o mapeamento completo de RegistroAutoridade. Podemos, a partir deste trecho, reiterar a linguagem adotada para descrever todas as outras entidades mapeadas. No mapeamento atribui-se um nome para o ClassMap; define-se o uriPattern utilizado para gerar as URIs de cada linha da view em questão; atribui-se uma d2rq:Class, que no caso é Role, da ontologia Schema.org e se segue para identificar as duas d2rq:PropertyBridge associativas. A partir de então, a estrutura é igual à da Figura 28, apenas com valores distintos.
