mapeamento de bancos de dados para domínios semânticos (.pdf)

UNIVERSIDADE FEDERAL DE GOIÁSINSTITUTO DE INFORMÁTICA

JÁDERSON ARAÚJO GONÇALVES DA CRUZ

Mapeamento de Bancos de Dados paraDomínios Semânticos

Goiânia2015

JÁDERSON ARAÚJO GONÇALVES DA CRUZ

Mapeamento de Bancos de Dados paraDomínios Semânticos

Dissertação apresentada ao Programa de Pós–Graduação doInstituto de Informática da Universidade Federal de Goiás,como requisito parcial para obtenção do título de Mestre emCiências da Computação.

Área de concentração: Sistemas de Informação.

Orientador: Prof. Cedric Luiz de Carvalho

Goiânia2015

Ciências da ComputaçãoCiências da Computação

Ficha catalográfica elaborada automaticamente com os dados fornecidos pelo(a) autor(a), sob orientação do Sibi/UFG.

Araújo Gonçalves da Cruz, Jáderson Mapeamento de Bancos de Dados para Domínios Semânticos[manuscrito] / Jáderson Araújo Gonçalves da Cruz. - 2015. XVII, 126 f.

Orientador: Prof. Dr. Cedric Luiz de Carvalho.Dissertação (Mestrado) - Universidade Federal de Goiás, Instituto deInformática (INF) , Programa de Pós-Graduação em Ciência daComputação, Goiânia, 2015. Inclui algoritmos, lista de figuras, lista de tabelas.

1. Repositório Semântico. 2. Dado Aberto Ligado. 3. MapeamentoSemântico. I. Luiz de Carvalho, Cedric, orient. II. Título.

Todos os direitos reservados. É proibida a reprodução total ou parcial dotrabalho sem autorização da universidade, do autor e do orientador(a).

Jáderson Araújo Gonçalves da Cruz

Graduou–se em Engenharia de Computação na UFG - Universidade Federalde Goiás. Durante sua graduação, atuou com pesquisa em aplicações baseadasem localização no Instituto de Informática da UFG. Nos últimos dois anosatuou num projeto de melhoramento da qualidade do leite, em parceria coma FAPEG e com o LQL - Laboratório da Qualidade do Leite; desde o anode 2014 atua no projeto de visão computacional AFAD em parceria coma FINEP/FAPEG. Atualmente é coordenador de desenvolvimento em umaempresa especializada em integração de dados e aplicações de Big Data eBusiness Intelligence

Dedico este trabalho primeiramente a Deus.Aos meus pais, João e Maria, por terem sempre me apoiado na minha busca pelo

conhecimento, mesmo nos momentos mais difíceis.

Agradecimentos

A realização deste trabalho em muito se deve à colaboração e apoio de diversaspessoas, às quais transmito meus mais singelos agradecimentos:

Ao professor Cedric L. de Carvalho, pela orientação, conselhos, sugestões,atenção e críticas construtivas.

Ao meu ex-chefe Thiago Borges de Oliveira, hoje professor da UFG no CampusJataí, pelos valiosos conselhos e orientações.

Aos colegas do mestrado e professores, que considero, pessoas extraordinárias edo qual tenho orgulho de ter conhecido.

Aos aos meus familiares, pelo apoio em todos os sentidos. Sem eles, eu não teriaconseguido chegar até aqui.

À todos os amigos que colaboraram de alguma forma para a concretização destetrabalho, seja por sua amizade e paciência ou simplesmente por aguentarem o meu malhumor durante esse período tão complicado da minha vida.

Dê-me uma alavanca e um ponto de apoio e levantarei o mundo

Arquimedes de Siracusa,Exclamação realizada por Arquimedes segundo Pappus de Alexandria.

Resumo

da Cruz, Jáderson A. G.. Mapeamento de Bancos de Dados para DomíniosSemânticos. Goiânia, 2015. 124p. Dissertação de Mestrado. Instituto de Infor-mática, Universidade Federal de Goiás.

Este trabalho apresenta uma proposta de mapeamento de bancos de dados para um do-mínio semântico. Esse processo consiste em mapear um conjunto de banco de dados,relacional ou NoSQL, para uma ontologia preexistente e definida pelo usuário. Subse-quentemente os elementos desses bancos de dados são ligados a repositórios semânticos,a fim de produzir uma representação em formato de dado aberto ligado.

Palavras–chave

Repositório Semântico, Dado Aberto Ligado, Mapeamento Semântico.

Abstract

da Cruz, Jáderson A. G.. Database Mapping for Semantic Domains. Goiânia,2015. 124p. MSc. Dissertation. Instituto de Informática, Universidade Federalde Goiás.

This paper proposes a database mapping to a semantic domain. This process consists ofmapping a set of database, relational or NoSQL, for a pre-existing user-defined ontology.Subsequently the elements of these databases are linked to semantic repositories in orderto produce a representation as linked open data.

Keywords

Semantic Repository, Open Linked Data, Semantic Mapping.

Sumário

Lista de Figuras 13

Lista de Tabelas 14

Lista de Códigos de Programas 15

1 Introdução 161.1 Motivação 171.2 Objetivo 191.3 Metodologia 191.4 Organização da Dissertação 20

2 Fundamentos Teóricos 222.1 Modelos de Bancos de Dados 22

2.1.1 Bancos de Dados Relacionais 232.1.2 Bancos de Dados Orientados a Objetos 232.1.3 Bancos de Dados Chave-Valor 242.1.4 Bancos de Dados Orientados a Colunas 252.1.5 Bancos de Dados de Documentos 262.1.6 Bancos de Dados Orientados a Grafos 27

2.2 Web Semântica 282.2.1 Unicode e Uniform Resource Identifiers (URIs) 292.2.2 Extensible Mark-up Language (XML) 292.2.3 Resource Description Framework (RDF) 292.2.4 Resource Description Framework Schema (RDFS) 292.2.5 Web Ontology Language (OWL) 302.2.6 Lógica, Prova e Validação 30

2.3 Dados Abertos 302.3.1 Dados Abertos Científicos 312.3.2 Dados Abertos Governamentais 31

Princípios dos Dados Abertos Governamentais 31Leis dos Dados Abertos Governamentais 32Dados Abertos no Mundo 32Dados Abertos no Brasil 33

2.3.3 Dados Abertos Ligados 342.4 Sobre o Capítulo 36

3 Bases de Conhecimento e suas Ontologias 373.1 DBPedia 39

3.1.1 Ontologia DBPedia 403.1.2 Acessando a DBPedia 40

3.2 GeoNames 413.2.1 Ontologia GeoNames 413.2.2 Acessando o GeoNames 42

3.3 WordNet 423.3.1 Ontologia WordNet 433.3.2 Acessando o WordNet 43

3.4 YAGO2 433.4.1 Ontologia YAGO2 443.4.2 Acessando o YAGO2 44

3.5 Freebase 453.5.1 Ontologia Freebase 453.5.2 Acessando o Freebase 46

3.6 Interligando Dados Abertos 463.7 Sobre o Capítulo 48

4 Trabalhos Relacionados 494.1 Morph RDB 494.2 RDOTE 504.3 RDB2OWL 514.4 MARSON 524.5 RONTO 524.6 AuReLi 534.7 StdTrip 534.8 MASTRO 544.9 Resumo dos Sistemas Analisados 554.10 Sobre o Capítulo 56

5 Solução Proposta 575.1 Mapeamento Semântico de Banco de Dados 585.2 Etapas da Solução 59

5.2.1 Mapeando entre Bancos de Dados e Ontologia 59Classificação Sintática 60Definindo Candidatos 60Filtrando Candidatos 61

5.2.2 Mapeamento para Repositórios Semânticos 64Categorizando o Acesso a Repositórios Semânticos 65Analisando Agrupadores Primários 68Lematização 68Associando Categorias com Agrupadores Primários 68Analisando Agrupadores Secundários 69

5.2.3 Gerando Formatos Abertos de Mapeamento de Dados 705.3 Sobre o Capítulo 71

6 Projeto do Sistema de Mapeamento de Banco de Dados 726.1 Atores 736.2 Requisitos da Aplicação 73

6.2.1 Requisitos Funcionais 736.2.2 Requisitos Não Funcionais 75

6.3 Modelagem, Arquitetura e Arquivo de Resultado 766.3.1 Arquitetura 77

Interface 77Motor de Execução 77Analisador Léxico/Sintático 78Extrator 79Cliente SPARQL 80

6.3.2 Arquivo de Resultado 826.3.3 Modelagem 83

6.4 Desenvolvimento da Aplicação 856.4.1 Tecnologias Empregadas 866.4.2 Bases de Dados Linguísticas 866.4.3 Categorias Utilizadas 886.4.4 Exemplo de Utilização 90

6.5 Sobre o Capítulo 96

7 Análise de Resultados 977.1 Resultados da Aplicação - Agrupadores Primários 97

7.1.1 Experimento 1 987.1.2 Experimento 2 997.1.3 Experimento 3 100

7.2 Resultados da Aplicação - Agrupadores Secundários 1017.2.1 Experimento 1 1017.2.2 Experimento 2 1027.2.3 Experimento 3 103

7.3 Resultados da Aplicação - Associação Semântica 1047.4 Sobre o Capítulo 105

8 Conclusão e Trabalhos Futuros 1068.1 Contribuições 1078.2 Trabalhos Futuros 107

Referências Bibliográficas 109

A Bancos de Dados Relacionais e NoSQL 116A.1 O Modelo Relacional - ACID 117A.2 O Modelo NoSQL - BASE 117

B Ontologias 118B.1 Elementos Básicos 118

B.1.1 Classe 118B.1.2 Indivíduos ou Instâncias 118B.1.3 Propriedades ou Relações 119

C Ferramentas Utilizadas 120C.1 Apache Jena 120C.2 JAWS 121C.3 GTranslate 121

D Modelo de Dados 122D.1 Tabelas Utilizadas pelo Cliente SPARQL 122D.2 Tabelas Utilizadas pelo Extrator 123D.3 Tabelas Utilizadas pelo Analisador Léxico/Sintático 123

Lista de Figuras

1.1 Diagrama de Fluxo do Projeto 20

2.1 Um exemplo de bancos de dados relacional 232.2 Um exemplo de bancos de dados orientado a objetos 242.3 Um exemplo de bancos de dados do tipo chave valor 252.4 Um exemplo de bancos de dados orientado a colunas 252.5 Um exemplo de bancos de dados de documentos 262.6 Um exemplo de bancos de dados do tipo grafos 272.7 Arquitetura da Web Semântica 28

3.1 Linguagens Utilizadas na Web 373.2 Modelo Adaptado de Integração de Dados de Beners-Lee 39

4.1 Esquema de Mapeamento do RD2OWL[22] 51

5.1 Mapeamento Semântico de Banco de Dados 58(a) Tabelas para Nodos 58(b) Banco de Dados Mapeado 58

5.2 Tabelas x Colunas 625.3 Processo de Associação do Banco de Dados com Ontologia de Referência 625.4 Tabela x Colunas 635.5 Complementação de Colunas 645.6 Complementação de Linhas 655.7 Modelo de Acesso de Dados por Ontologia 70

6.1 Casos de Uso do Sistema 746.2 Arquitetura Proposta 776.3 Analisador Léxico/Sintático 786.4 Módulo Extrator 806.5 Módulo Cliente SPARQL 816.6 Exemplo de Resultado da Aplicação 826.7 Mapeando Bancos de Dados e Ontologia 846.8 Vinculando Categoria a um Domínio 846.9 Vinculando Categoria a um Domínio 856.10 Exemplo de dicionário do pacote de francês 876.11 Exemplo de regras do pacote de inglês 876.12 Nuvem de Dados Abertos Ligados, Abril de 2014[32] 886.13 Ontologia de Exemplo 906.14 Adicionando um Banco de Exemplo 92

Lista de Tabelas

2.1 As 5 estrelas do modelo Gov 2.0 342.2 Custos e benefícios do modelo de ? dados web 352.3 Custos e benefícios do modelo de ? ? dados web 352.4 Custos e benefícios do modelo de ? ? ? dados web 352.5 Custos e benefícios do modelo de ? ? ? ? dados web 352.6 Custos e benefícios do modelo de ? ? ? ? ? dados web 35

3.1 Exemplo de Relações Léxicas na WordNet 433.2 Ligações da DBPedia para outros repositórios[51] 473.3 Os 10 repositórios com mais ligações para a DBPedia[51] 48

4.1 Resumo Trabalhos Relacionados 55

5.1 Modos de agrupamento de dados por paradigma de banco de dados 605.2 Relação entre synsets da ontologia com synsets do banco de dados 61

6.1 Categorias Extrator 896.2 Categorias Cliente SPARQL 91

7.1 Banco de Dados x Ontologias 987.2 Entrada e Saída Agrupador Primário - Experimento 1 98

(a) Entradas 98(b) Saídas 98

7.3 Entrada e Saída Agrupador Primário - Experimento 2 99(a) Entradas 99(b) Saídas 99

7.4 Entrada e Saída Agrupador Primário - Experimento 3 100(a) Entradas 100(b) Saídas 100

7.5 Entrada/Saída Agrupador Secundário - Experimento 1 101(a) Entradas 101(b) Saídas 101



7.8 Categorias X Experimentos 104

Lista de Códigos de Programas

5.1 Consulta SPARQL a DBPedia 665.2 Consulta SPARQL a Dailymed 676.1 Exemplo de Consulta SPARQL 816.2 Tabela Verbetes 886.3 Individual x Colunas 946.4 SQL Individual x Colunas 95D.1 Tabela de Categorias por SPARQL Endpoint 122D.2 Tabela de Categorias por Extrator 123D.3 Tabela de palavras traduzidas por idioma 124

CAPÍTULO 1Introdução

O surgimento da World WideWeb mudou a forma como os negócios são condu-zidos, como as pessoas interagem entre si, e como o conhecimento é disseminado. Muitassão as ferramentas que utilizam a Web em seu formato atual, estando essas ferramentassujeitas às limitações dessa.

Dentre as limitações mais conhecidas da web atual cita-se sua baixa precisão nasbuscas, seus resultados são muito dependentes do vocabulário utilizado, as informaçõessão localizadas e não recuperadas, suas principais ferramentas para busca de informaçãosão inteiramente voltadas para a interação humana, não sendo legíveis para outras ferra-mentas de software.

É possível dividir a web em algumas fases, sendo a primeira fase representadapor uma web de conteúdo sintático (Web 1.0 ou Web Sintática). Nessa primeira versão daweb os documentos eram indexados, endereçados e acessados de qualquer computadora partir de um navegador. Existia nesse momento uma certa divisão entre aqueles queproduziam os documentos disponibilizados e aqueles que os liam. Esse modelo foi oproposto por Tim Berners-Lee[9].

Em um segundo momento, a web evoluiu para um modelo onde surgiramaplicações dentro dessa. Nesse novo modelo, os usuários da web passaram a interagire a atuarem tanto como produtores quanto consumidores de conteúdo. Esse modelo deweb, também conhecido como Web 2.0, ou mesmo Web Social, é o modelo predominantenos dias atuais.

Dentre as várias possibilidades que vêm surgindo com a evolução da web,uma delas possui um importante destaque. Promovida pelo idealizador da web, TimBerners-Lee e pelo W3C Consortium, a Web Semântica ou Web 3.0, propõem ummodelo onde a web não seja legível somente para os seres humanos, mas também paraos computadores. Nesse modelo, a informação é disponibilizada de forma estruturada,padronizada, interligada e em formato não proprietário (Dados Abertos Ligados ou DadosAbertos Conectados[58]).

Ao longo dos últimos anos, um número crescente de provedores de dadoscomeçaram a adotar os princípios dos Dados Abertos Conectados, levando à criação de

1.1 Motivação 17

um espaço global de dados contendo bilhões de afirmações sobre localizações geográficas,pessoas, empresas, livros, publicações científicas, filmes, músicas, programas de rádio etelevisão, genes, proteínas, medicamentos e ensaios clínicos, comunidades online, dadosestatísticos, os resultados do censo, entre outros[14].

Dentre as fontes para a geração de dados abertos, merece destaque a geraçãode dados abertos a partir de bancos de dados. A maior parte dos dados que sustentama Web e em domínios como as ciências naturais, gerenciamento de dados espaciais sãoarmazenados em bancos de dados relacionais, por seu histórico comprovado de escalabi-lidade, armazenamento eficiente, execução de consultas otimizadas e confiabilidade[68].Nos últimos anos, entretanto, vem aumentando a demanda pelo uso de bancos de dadosnão relacionais, ou NoSQL[55], em domínios específicos.

A capacidade de mapear bancos de dados, seja relacional ou NoSQL, para umformato de dados abertos que favoreça a integração e leitura por máquina, é um dospassos a serem dados para a evolução da web. Este trabalho, apresenta algumas técnicasde mapeamento de banco de dados, assim como propõe uma nova técnica de mapeamentoque permita uma análise semântica na formulação de consultas à base de dados sendomapeada.

1.1 Motivação

A web em seus dias atuais, vivencia um momento de transição. Neste momento, aweb possui a maior parte de seu conteúdo voltado à compreensão de informações por partedos seres humanos. Entretanto, a nova geração da web busca a criação de um ambiente deconteúdo compreensível não somente pelo ser humano, mas também por computadores.

O novo modelo da web, conhecido por Web Semântica, favorece principalmentea modificação da forma como os dados são estruturados. O principal objetivo desse novomodelo da web é permitir uma melhor interpretação dos recursos da web por parte doscomputadores, e consequentemente o aumento do poder de resposta computacional sobrea massa de dados crescente encontrada na web.

A Web Semântica pode ser vista como uma extensão da web atual, onde a conso-lidação desse novo paradigma depende não somente da disponibilização dos novos dadossegundo suas especificações, mas também de formas de inserir nesse os dados existentesmodelados sobre o paradigma atual. Dessa forma, torna-se importante o desenvolvimentode sistemas capazes de realizarem a análise dos dados modelados sobre esse paradigma econvertê-lo para o paradigma da Web Semântica.

Dentre as várias fontes de dados utilizadas na web, os bancos de dados são al-gumas das mais importantes existentes. Bancos de dados são utilizados por praticamentetodos os domínios e aplicações encontrados na web, sendo que seus dados de interesse

1.1 Motivação 18

são disponibilizados, principalmente, na forma de tabelas e gráficos voltados à visualiza-ção por parte dos usuários. Além disso, os formatos apresentados muitas vezes possuemcaracterísticas que inviabilizam sua leitura por máquinas, tomando como exemplo forma-tos como o PDF1. Logo, a integração dos bancos de dados no modelo da Web Semântica,mostra-se como uma tarefa de grande importância para o desenvolvimento contínuo dessenovo paradigma da web.

Bancos de dados relacionais possuem uma estrutura sintática mínima, onde oconteúdo é armazenado em uma divisão pré-definida de estrutura de entidades e relaci-onamento entre essas, assim como definição de tipos específicos para as propriedadesdessas entidades. Mesmo possuindo essa estrutura mínima, esses bancos de dados nãoapresentam a semântica de seus dados e relacionamentos entre esses de modo explícito,de tal forma que a semântica de tratamento desses dados é detida pelos especialistas res-ponsáveis pela manutenção dos bancos de dados em questão.

Outro aspecto sobre a Web Semântica é a relação explícita existente entre osdados, de forma que as informações de um domínio possam ser utilizadas por outrosdomínios a fim de produzir resultados mais significativos. Uma informação sobre aevolução do nível de renda da população brasileira por região do país, contida em umbanco de dados do ministério do desenvolvimento, poderia ser enriquecida através daintegração desses dados com estatísticas encontradas em bancos de dados de outrosministérios, de secretarias estaduais e municipais, entidades paraestatais ou instituiçõesprivadas sobre educação, saneamento, preferências políticas, entre outros.

Este trabalho busca o desenvolvimento de técnicas para a integração de sistemasde bancos de dados ao novo paradigma, trazido pela Web Semântica, assim como desen-volver uma ferramenta que compatibilize esses sistemas permitindo assim a coexistênciaentre esses modelos, até o dia que a web esteja pronta para desenvolver-se unicamentesobre o paradigma semântico.

Em resumo, as motivações para este trabalho consistem nos seguintes tópicos:

• Apresentar técnicas para viabilizar o processo de mapeamento de bancos de dados,de modo que os dados dessas fontes de dados até então isoladas possam ser vistosde forma integrada, segundo um modelo definido numa ontologia.• Permitir que a informação proveniente dessas fontes de dados mapeadas referen-

ciem outros domínios, permitindo o enriquecimento dos dados desses bancos dedados.

1Portable Document Format[45]

1.2 Objetivo 19

1.2 Objetivo

Segundo o Dicionário Oxford do Inglês, podemos definir mapeamento da se-guinte forma: uma operação que associa a cada elemento de um dado conjunto (domínio)um ou mais elementos de um segundo conjunto (o contradomínio)[75].

O principal objetivo deste trabalho é definir um método para o mapeamentoautomático, entre bancos de dados, relacionais e NoSQL, e uma ontologia que possuamdomínios correlacionados. Esta proposta tem como objetivo facilitar o desenvolvimentoda Web Semântica.

Um foco adicional deste trabalho é de disponibilizar o mapeamento entre osbancos de dados e a ontologia de referência em formato de Dado Aberto Conectado. Essarepresentação utiliza padrões preestabelecidos e formalizados pelas entidades competen-tes.

A ideia por trás desse projeto é construir um mecanismo para a disponibilizaçãodos dados provenientes de bancos de dados, utilizando como referência a ontologia. Dessaforma, um usuário pode acessar os dados dessas bases, mesmo sem conhecer os detalhesdessas bases de dados.

O usuário apenas conhece o domínio tratado pela base de dados, e define suasintenções sobre essa base de dados requisitando informações através da ontologia para oqual deseja-se mapear a informação.

Para atingir esses objetivos principais, pretende-se atingir os seguintes objetivosespecíficos, convergentes com esses objetivos principais :

1. Apresentar uma visão geral sobre Bancos de Dados e Web Semântica, descrevendoresumidamente as principais tecnologias e conceitos presentes nessas áreas, assimcomo suas atuais limitações.

2. Realizar um estudo do estado da arte das técnicas utilizadas até então para mapearbancos de dados para ontologias, assim como aplicações para essas técnicas emambientes reais.

3. Disponibilizar a informação proveniente dos Bancos de Dados analisados emformato aberto e conectado a outros elementos da Web Semântica.

4. Projetar uma ferramenta que permita demonstrar o mecanismo de mapeamento defi-nido nesse trabalho, sendo aplicado em situações reais, assim como seu mecanismode integração com repositórios semânticos diversos.

1.3 Metodologia

A realização dessa pesquisa foi dividida em etapas, como pode ser observado naFigura 1.1.

1.4 Organização da Dissertação 20

Figura 1.1: Diagrama de Fluxo do Projeto

1. Estudo Teórico. Nesta etapa, foram realizadas as pesquisas bibliográficas necessá-rias para a definição do método aqui proposto. Dentre os temas pesquisados, citam-se os paradigmas de bancos de dados e a teoria fundamental da Web Semântica.

2. Levantamento do Estado da Arte e Trabalhos Correlacionados. Nesta etapa,foram estudados os trabalhos publicados relacionados com o tema de mapeamentode banco de dados para modelos semânticos.

3. Projeto de Software. Foi efetuado um levantamento de requisitos e definição deuma arquitetura para uma ferramenta responsável por aplicar o modelo propostoneste trabalho.

4. Desenvolvimento do Projeto. Foi feita a implementação da aplicação de mapea-mento de banco de dados, tanto para bancos relacionais como não relacionais.

5. Documentação. Essa etapa consiste na descrição sistemática de todas as etapas,tem como produto esta dissertação.

1.4 Organização da Dissertação

O presente trabalho, além deste Capítulo 1, está dividido em 8 capítulos eorganizado como descrito a seguir.

No Capítulo 2, são introduzidos os fundamentos teóricos utilizados ao longodesse trabalho, sendo apresentado um estudo sobre os principais modelos de banco de

1.4 Organização da Dissertação 21

dados utilizados atualmente. Em seguida, é realizado um estudo sobre a Web Semântica,seus conceitos, assim como as principais ferramentas utilizadas por essa. Também sãoabordados os conceitos de Dados Abertos e sua importância dentro da Web Semântica.

No Capítulo 3, é realizado um estudo sobre as possíveis bases de conhecimentosemânticas, com foco na ontologia que as definem e que podem ser utilizadas nesseprojeto.

No Capítulo 4, são apresentados alguns trabalhos relacionados ao tema dessadissertação.

No Capítulo 5, é apresentada a solução proposta nesse trabalho num contexto dealto nível, onde define-se a proposta para realizar o mapeamento de bancos de dados emcontexto semântico.

No Capítulo 6, é realizada uma explicação sobre o projeto implementado. Nessecapítulo, são descritos os principais atores, requisitos funcionais, requisitos não funcionaisque serviram de base para o projeto do sistema. Uma arquitetura do projeto é descrita, bemcomo uma explicação sobre cada um dos componentes do projeto.

O Capítulo 7 apresenta os resultados obtidos em algumas simulações do sistema,sendo executado sobre bases de dados reais. Nesse capítulo, são apresentadas as principaisvantagens com relação ao sistema, assim como é realizada uma análise de suas principaisdeficiências.

Finalmente, o Capítulo 8 apresenta considerações finais do trabalho, onde sãoenumeradas as contribuições esperadas desse sistema e possíveis trabalhos futuros.

CAPÍTULO 2Fundamentos Teóricos

O ponto de partida para desenvolver uma pesquisa visando o mapeamento entrebancos de dados e ontologias por anotações semânticas é a compreensão de determinadostemas considerados fundamentais para essa pesquisa. Dessa forma, torna-se possívelpropor novas técnicas, de propósito geral, para realizar o processo de mapeamentoproposto neste trabalho.

Nesse capítulo, são apresentados alguns dos conceitos fundamentais necessáriospara o desenvolvimento dessa pesquisa. Inicialmente, na Seção 2.1, são apresentados osprincipais paradigmas de bancos de dados utilizados nos Capítulos 4, 5 e 6.

Em seguida, na Seção 2.2, são apresentadas explicações mais detalhadas da WebSemântica, assim como das principais tecnologias relacionadas a ela. A compreensãodesse tópico é necessária tanto para o entendimento do Capítulo 3, quanto para desen-volver as integrações entre os bancos de dados e os repositórios semânticos, processodescrito na Seção 6.3.1.

Ao final do capítulo, são apresentados os conceitos relacionados a Dados AbertosLigados. Esse paradigma corresponde a um dos objetivos desse trabalho, onde os dadosdas bases mapeadas são disponibilizados segundo o modelo utilizado na ontologia dereferência seguindo as recomendações desse paradigma.

2.1 Modelos de Bancos de Dados

Existem diferentes paradigmas que definem a forma como os dados são arma-zenados ou recuperados. Pensando em um sistema capaz de realizar a engenharia reversade uma base de dados genérica, os diferentes modelos de bancos de dados devem serconsiderados. Um dos objetivos desse projeto, é criar um mecanismo de tratamento gené-rico para as diferentes formas de representar os dados. Isso pode ser alcançado através dautilização das bases de dados num formato intermediário.

A maior parte dos trabalhos de mapeamento de bancos de dados para ontologias,apresentados em detalhes no Capítulo 4, preocupam-se apenas no tratamento de bancos

2.1 Modelos de Bancos de Dados 23

de dados relacionais. Os bancos de dados NoSQL, apesar de sua crescente utilização, sãoignorados.

Nas seções seguintes, serão apresentadas definições para os principais modelosde banco de dados. Considera-se tanto os bancos de dados relacionais quanto os bancosNoSQL. O Apêndice A contém uma explicação mais detalhada sobre as diferenças dosbancos de dados relacionais e NoSQL.

2.1.1 Bancos de Dados Relacionais

O modelo relacional para gerenciamento de banco de dados é um modelomatemático para descrever a estrutura de dados. É um modelo de bancos de dados combase na lógica de predicados de primeira ordem, formulada pela primeira vez e propostoem 1969 por Edgar F. Codd.[30]. Em um Banco de Dados Relacional, todos os dados sãorepresentados em termos de tuplas, agrupados em relações. Uma base de dados organizadaem termos de modelo relacional é um banco de dados relacional.

Figura 2.1: Um exemplo de bancos de dados relacional

Como pode ser observado na Figura 2.1, tomando uma descrição informal usa-se termos como tabelas, linhas e colunas para representar os conceitos de relações, tuplase atributos, respectivamente.

As tuplas ou linhas de uma tabela ou relação são identificadas através de atributoschamados de chave primária. Da mesma forma, essas tabelas de bancos de dados podemrelacionar-se entre si, por meio de elementos de ligação chamadas chaves estrangeiras.

2.1.2 Bancos de Dados Orientados a Objetos

Um banco de dados orientado a objeto é um banco em que cada informação éarmazenada na forma de objetos, e só pode ser manipulado através de métodos definidospela classe em que esteja o objeto[48]. Pode ser visto como a junção entre o paradigmade orientação a objetos, presente nas linguagens de programação moderna, e a teoria debanco de dados relacionais.


Figura 2.2: Um exemplo de bancos de dados orientado a objetos

Através do paradigma orientado a objetos estende-se a lógica de relacionamentoentre as tabelas, permitindo a utilização de conceitos como a herança entre entidades,recurso muito presente nas linguagens orientadas a objetos, como pode ser observadona Figura 2.2. Observa-se que tanto a tabela Física quanto a tabela Jurídica possuemrelacionamento de herança com a tabela Pessoa, indicando que essas tabelas representamtipos de Pessoas.

2.1.3 Bancos de Dados Chave-Valor

Esse modelo de banco de dados possui uma estrutura simples de utilização dechaves devidamente indexadas[59]. Estes sistemas podem armazenar dados estruturadose não estruturados. Segundo Moniruzzaman e Hossain[55] esse tipo de banco de dadospode ser definido do seguinte modo:

“Normalmente, esses Sistemas de Gerenciamento de Dados armazenamitens como identificadores alfanuméricos (chave) e associam com valo-res em tabelas simples, autônomas (conhecidas como hash tables). Osvalores podem ser sequências de texto simples ou listas e conjuntos maiscomplexas. As buscas de dados normalmente só podem ser realizadassobre as chaves, não sobre seus valores, sendo limitados a correspon-dência exata.”

As hash tables utilizadas por esse tipo de banco de dados são semelhantes àque-las estruturas de dados encontradas em linguagens de programação. Sua estrutura simplespermite um acesso rápido aos dados, sendo utilizada principalmente para trabalhar com ainformação na memória principal. Na Figura 2.3, é possível visualizar uma representaçãodesse tipo de banco de dados. Nesse exemplo, existem chaves ( Massa, Comprimento,Largura ) que possuem itens respectivamente relacionados a valores ( 5kg, 15cm, 12cm ).


Figura 2.3: Um exemplo de bancos de dados do tipo chave valor

O mais conhecido caso de utilização de banco de dados do tipo chave-valor é oSimpleDB da Amazon[27]. O SimpleDB da Amazon é um serviço web que fornece osrecursos essenciais de banco de dados, utilizando a infraestrutura de nuvem da Amazonpara oferecer alta disponibilidade, escalabilidade e resistência a falhas de armazenamentode dados [67].

2.1.4 Bancos de Dados Orientados a Colunas

Estes tipos de bancos de dados contêm uma coluna extensível de dados estrei-tamente relacionadas, em vez de conjuntos de informações em uma tabela estritamenteestruturada de colunas e linhas, como é encontrado em bancos de dados relacionais[59].

A Figura 2.4 apresenta uma representação de um banco de dados orientado acolunas, onde uma chave está relacionada a um conjunto de elementos abstratos comvalores correspondentes, elementos esses chamados de colunas.

Figura 2.4: Um exemplo de bancos de dados orientado a colunas


Dentre os bancos de dados que seguem esse paradigma, cita-se o BigTable daGoogle e Cassandra.

Bigtable é uma implementação de um mapa multidimensional ordenado, ondea indexação é feita por linhas, colunas e campo do tipo timestamp[28]. Esse banco dedados foi construído pela Google para atender demandas de projetos internos, tornando-se operacional em abril de 2005. Bigtable foi desenvolvido para trabalhar com petabytesde informação, sendo executado sobre centenas ou mesmo milhares de computadores.

O Apache Cassandra é um sistema de armazenamento distribuído para o geren-ciamento de grandes quantidades de dados distribuídos, podendo funcionar em hardwarede baixo custo [50]. Esse banco de dados ganhou grande popularidade por ser usado emredes sociais como o Twitter e o Facebook.

2.1.5 Bancos de Dados de Documentos

Os dados são armazenados e organizados como uma coleção de documentos.Os usuários têm permissão para adicionar qualquer número de campos de qualquercomprimento em um documento [59]. Geralmente esses bancos de dados armazenamdocumentos baseados no formato de dados JSON[31].

A Figura 2.5 apresenta uma representação de um banco de dados orientado adocumentos. Observa-se que a ideia por trás desse paradigma consiste numa extensãodo paradigma de banco de dados orientado a colunas. Nesse modelo, os conceitosabstratos de colunas observados anteriormente são agrupados em um conjunto chamadodocumento.

Figura 2.5: Um exemplo de bancos de dados de documentos

Exemplos de bases de dados de documentos seriam o MongoDB e o ApacheCouchDB.


O MongoDB é um Sistema de Gerenciamento de Dados em Nuvem de códigoaberto, escalável e de propósito geral, que utiliza sistemas de índices secundários, consul-tas sobre intervalos, técnicas de ordenação, agregação e índices geoespaciais[29].

O Apache CouchDB é um banco de dados escrito em Erlang, desenvolvido paraviabilizar sua utilização em servidores com hardware de baixo desempenho. CouchDBrealiza consultas sobre estruturas chamadas “views”, possui um sistema de indexaçãobaseado em B-trees e utiliza técnicas de armazenamento e controle de concorrênciabaseadas na estrutura do documento[25].

2.1.6 Bancos de Dados Orientados a Grafos

Bancos de dados orientados a grafos podem ser definidos como aqueles em queas estruturas de dados para o esquema e as instâncias são modelados na forma de grafosou generalizações desses. A Figura 2.6 apresenta um modelo de um banco de dadosorientado a grafos. Nesse modelo, a manipulação de dados é expressa por operaçõesem grafos orientados, usando conceitos como caminhos, vizinhos, subgrafos, padrõesgráficos, conectividade e gráfico de estatísticas[2].

Figura 2.6: Um exemplo de bancos de dados do tipo grafos

Como exemplo de banco de dados que segue esse paradigma cita-se o Neo4j,um banco de dados orientado a grafos de código aberto baseado em Java que oferecepersistência de alta performance, escalabilidade e possui uma comunidade ativa e comuma boa documentação[43].

2.2 Web Semântica 28

2.2 Web Semântica

Segundo Bonifácio & Heuser[16], a Web possui problemas de localização,acesso, apresentação e manutenção da informação por parte dos usuários. Esses proble-mas são ocasionados por fatores como a estrutura para compartilhamento de recursosdistribuídos, autônomos, heterogêneos, a falta de um padrão mínimo para exibição dainformação, entre outros.

A informação na Web é tipicamente representada em linguagem natural, per-mitindo que ela seja compreendida por pessoas. Entretanto, para prover informação deforma que computadores também possam compreendê-la é necessário representá-la deforma sistemática e semântica.

Nas palavras de Berners-Lee[10]: “Web semântica é a extensão da web obtidavia adição de semântica ao formato atual de representação de dados”. Em um ponto devista mais prático, a Web Semântica é a representação abstrata de dados sobre a World

Wide Web, com base nos padrões RDF e outras normas a serem definidas[78]. Ela estásendo normatizada pelo W3C, em colaboração com um grande número de pesquisadorese parceiros industriais.

A Web Semântica pode ser dividida em partes, segundo um modelo de cama-das proposto por Berners-Lee[12]. Segundo esse, a arquitetura da Web Semântica estádividida em sete camadas: 1) Unicode e URI; 2) XML, NS, e esquema XML; 3) RDF eesquema RDF e 4) Vocabulário ontologia; 5) Lógica; 6) Prova e 7) Validação.

O modelo proposto por Berners-Lee pode ser observado na Figura 2.7.

Figura 2.7: Arquitetura da Web Semântica

2.2 Web Semântica 29

2.2.1 Unicode e Uniform Resource Identifiers (URIs)

Unicode é um padrão que fornece um número único para cada caractere, não im-porta qual a plataforma, não importa qual o programa, não importa qual a linguagem[76].

URI corresponde ao conjunto genérico de todos os nomes e endereços, geral-mente na forma de cadeias de caracteres compactos, utilizados para referir-se a recursosabstratos ou físicos, geralmente usados na internet[8]. Esses nomes são utilizados paraidentificação única de recursos na Web.

Essa camada fornece interoperabilidade em relação à codificação de caracteres eao endereçamento e nomeação de recursos da Web Semântica.

2.2.2 Extensible Mark-up Language (XML)

XML é um formato de texto simples, muito flexível derivado do SGML[70].Originalmente concebido para enfrentar os desafios da publicação eletrônica em grandeescala, o XML também está desempenhando um papel cada vez mais importante na trocade uma ampla variedade de dados na Web e em outros contextos[18].

2.2.3 Resource Description Framework (RDF)

RDF é um modelo padrão para o intercâmbio de dados na web com característi-cas que facilitam a fusão de dados, mesmo se os esquemas subjacentes diferirem[24].

RDF tem uma sintaxe abstrata, para refletir um modelo simples baseado em gra-fos e modelos de semântica formal com uma noção rigorosamente definida de vinculaçãoentre os dados. RDF é um modelo de representação de dados baseado em triplas, ou seja,os dados são apresentados utilizando estruturas de três partes, na forma de sujeito predi-cado e objeto.

Esse formato de dados é projetado para representar informações de forma flexí-vel e minimamente restritivo. Ele pode ser usado em aplicações isoladas, onde formatosconcebidos individualmente possam ser de compreensão mais fácil e direta, mas a genera-lidade do RDF oferece maior valor no processo de compartilhamento de informações[24].

2.2.4 Resource Description Framework Schema (RDFS)

RDFS é construído sobre o modelo RDF básico, visando estendê-lo para incluirum vocabulário maior com restrições semânticas mais complexas[41]

O modelo de dados RDF não prevê mecanismos para declarar classes nem pro-priedades, nem fornece qualquer mecanismo para definir as relações entre propriedades eoutros recursos. A declaração destas propriedades (atributos) e sua semântica correspon-dente são definidas no contexto do RDF como um RDFS[20, 74].

2.3 Dados Abertos 30

Um esquema define não apenas as propriedades do recurso (por exemplo, título,autor, assunto, tamanho, cor, etc. . . ) , mas também pode definir os tipos de recursos queestão sendo descritos (livros, páginas da web, pessoas, empresas , etc.)[20].

2.2.5 Web Ontology Language (OWL)

De modo geral, OWL é projetada para uso em aplicações que precisam processaro conteúdo da informação ao invés de apenas apresentar informações para os sereshumanos [52].

OWL é considerada uma linguagem mais complexa, com maior capacidade deinterpretação do que o RDF. OWL busca identificar com precisão a natureza dos recursose suas relações[47]. De modo geral, OWL é uma linguagem para descrever ontologias.

Segundo Gruber[38]: “Uma ontologia é uma especificação formal e explícita deuma conceitualização compartilhada”. Entende-se por “formal” o fato de uma ontologiaser interpretável por seres humanos ou por máquinas; ser “explícita” significa que essapossui conceitos, propriedades, relações, funções, restrições, axiomas, explicitamente de-finidos; “compartilhado” significa que sua representação de conhecimento é consensual;e “conceitualização” diz respeito a um modelo abstrato de algum fenômeno do mundoreal. O apêndice B apresenta uma visão mais detalhada sobre ontologias.

A principal função dessa camada é a inferência de semântica, para produzirconjuntos de possíveis significados[73], auxiliando o processamento por máquinas efacilitando o compartilhamento de informações.

2.2.6 Lógica, Prova e Validação

Segundo Sridevi e Umarani[73], é possível definir essas três camadas da seguinteforma:

• Lógica: É responsável pelo raciocínio e execução de inferências lógicas a partir dasemântica previamente descrita;• Prova: Camada para verificar a autenticidade do comportamento do agente e corro-

boração dos resultados;• Validação: Camada que provê um mecanismo para avaliar o nível de confiabilidade

das fontes de recursos e informações;

2.3 Dados Abertos

Segundo a definição da Open Knowledge Foundation[58]: “dados são abertosquando qualquer pessoa pode livremente usá-los, reutilizá-los e redistribuí-los, estando


sujeito a, no máximo, a exigência de creditar a sua autoria e compartilhar pela mesmalicença.”

Dados Abertos ou Dados Públicos são dados de livre acesso a todas as pessoasque assim desejarem, para que essas os utilizem ou publiquem independente de qualquerrestrição ou mecanismo de controle. A filosofia dos Dados Abertos foi estabelecida hámuito tempo, no entanto o termo Dados Abertos ganhou popularidade recentemente como advento da Internet.

Várias podem ser as fontes dos Dados Abertos, em particular nos últimos anosesses ganharam muito espaço na ciência e nos governos.

2.3.1 Dados Abertos Científicos

O conceito de acesso aberto a dados científicos foi institucionalmente estabe-lecido com a formação do sistema Centro Mundial de Dados. O Conselho Internacionaldas Uniões Científicas (agora o Conselho Internacional para a Ciência) estabeleceu várioscentros de dados mundiais para minimizar o risco de perda de dados e para maximizar aacessibilidade dos dados, ainda em 1955, recomendando que os dados sejam disponibili-zados em formato legível por máquina[54].

2.3.2 Dados Abertos Governamentais

Dados Abertos Governamentais (DAG) podem ser definidos da seguinte forma:“disponibilização, através da Internet, de informações e dados governamentais de domíniopúblico para a livre utilização pela sociedade[1]”.

Em outras palavras os DAG são uma metodologia para a publicação de dados dosgovernos em formatos reutilizáveis, a fim de aumentar a transparência na gestão pública,bem como majorar a participação popular.

É importante destacar que a filosofia referente aos dados abertos governamentaisconverge com a evolução das democracias modernas, onde esses representam um novoestágio de transparência e accountability da gestão pública. Em outras palavras, osdados abertos e sua filosofia são um meio para a implementação dos paradigmas degestão governamental do chamado Novo Serviço Público (NSP) para o qual caminhamas democracias ao redor do mundo.

Em um nível mais elevado, o conceito de DAG favorece o desenvolvimento deaplicações colaborativas entre o governo e a sociedade.

Princípios dos Dados Abertos Governamentais

No ano de 2007 um grupo de trinta especialistas denominados OpenGovData,se reuniu na Califórnia - EUA a fim de definir os princípios dos dados abertos governa-


mentais. Dessa reunião, surgiram os 8 princípios dos dados governamentais abertos[57].Segundo esses, os dados abertos governamentais devem ser:

1. Completos. Todos os dados públicos estão disponíveis. Dado público é o dadoque não está sujeito a limitações válidas de privacidade, segurança ou controle deacesso.

2. Primários. Os dados são apresentados tais como os coletados na fonte, com o maiornível possível de granularidade e sem agregação ou modificação.

3. Atuais. Os dados são disponibilizados tão rapidamente quanto necessário à preser-vação do seu valor.

4. Acessíveis. Os dados são disponibilizados para o maior alcance possível de usuáriose para o maior conjunto possível de finalidades.

5. Compreensíveis por máquinas. Os dados são razoavelmente estruturados de modoa possibilitar processamento automatizado.

6. Não discriminatórios. Os dados são disponíveis para todos, sem exigência derequerimento ou cadastro.

7. Não proprietários. Os dados são disponíveis em formato sobre o qual nenhumaentidade detenha controle exclusivo.

8. Livres de licenças. Os dados não estão sujeitos a nenhuma restrição de direitoautoral, patente, propriedade intelectual ou segredo industrial. Restrições sensatasrelacionadas à privacidade, segurança e privilégios de acesso são permitidas.

Leis dos Dados Abertos Governamentais

Com a consolidação dos acordos internacionais para transparência governamen-tal entre as nações, o consultor e pesquisador canadense David Eaves definiu três “leis”para os dados abertos governamentais[34]:

1. Se o dado não for encontrado e indexado na web, ele não existe;2. Se não estiver aberto e disponível em formato compreensível por máquina, ele não

pode ser aproveitado;3. Se algum dispositivo legal não permitir sua replicação, ele é inútil.

Dados Abertos no Mundo

Como um movimento de proporções globais, vários governos nacionais e sub-nacionais estão disponibilizando seus dados a partir das orientações do governo aberto.Pode-se citar como referencias para esse: Estados Unidos, Reino Unido, Austrália e NovaZelândia[1].

A Grã-Bretanha no ano de 2008 em um concurso denominado Show us a better

way, o qual visava o desenvolvimento de aplicações com dados públicos, liberou acesso a


um conjunto de várias informações públicas. O portal de dados abertos do Reino Unido1

possui espaço para comunidades virtuais, wiki, RSS e envio de novas aplicações web pelocidadão.

O governo da Nova Zelândia2 e da Austrália3 criaram seus portais de dadosabertos no ano de 2010. Aquele é um espaço para discussão através de fóruns propostospelos cidadãos, enquanto esse encoraja a criação de gadgets e programas de computadorque fazem controle social de todas as informações dentro do portal.

Os Estados Unidos apresentam o plano mais ambicioso com relação aos dadosabertos4, onde o presidente Barack Obama, no início de seu primeiro mandato, crioupolíticas públicas para a promoção da transparência, que incentiva a disponibilizaçãodos dados públicos em formato aberto. Promovendo o uso de dados abertos em umnível global, de tal forma que esse governo enviou um memorando a todos os chefesde governos se comprometendo a criar “níveis sem precedentes de abertura” no governo.

Dados Abertos no Brasil

Os esforços no sentido de publicação dos DAG podem ser vistos a partir de2009, quando o Comitê de Informação da Presidência da República do Brasil começoua reunir grandes quantidades de dados agregados do governo para a publicação digital5.O objetivo do comitê foi criar um catálogo central de informações da atividade pública,com a intenção de melhorar a governança e monitoramento de atividades de governo.Este catálogo foi criado originalmente para servir ao então Presidente da República esua equipe de assessores, como uma fonte confiável de dados oficiais, o catálogo foidisponibilizado ao público em 2010.

Esse catálogo de informações é composto de pouco mais de 1300 séries de dadoshistóricos, representando 8 anos de registros públicos, que refletem as ações do governodurante a presidência de Luiz Inácio "Lula"da Silva (2003-2010). Como padrão, a equipede gestão propôs classificar os dados em duas dimensões: territoriais (países, estados,cidades) e temporal (ano ou mês). Séries de dados foram classificadas em várias árvorestemáticas hierárquicas, que se ramificam a partir de assuntos gerais para assuntos maisespecíficos.

1http://data.gov.uk/, acessado em junho de 20152https://data.govt.nz/, acessado em junho de 20153http://data.gov.au/, acessado em junho de 20154http://www.data.gov/, acessado em junho de 20155http://dados.gov.br/, acessado em junho de 2015


2.3.3 Dados Abertos Ligados

Uma vez que os dados tenham sido disponibilizados em formato aberto eutilizem-se dos recursos da Web Semântica para relacionar a informação contida neles,de forma a definir claramente um significado e as relações inerentes daquele dado, surgeum novo conceito de Linked Open Data (LOD) ou Dados Abertos Ligados (DAL).

Segundo Florian Bauer[36]: “Para se beneficiar inteiramente dos Dados Aber-tos, é crucial disponibilizar informações e dados em um contexto que crie novos conheci-mentos e permita o desenvolvimento de serviços e aplicativos poderosos. Como os DALfacilitam a inovação e a criação de conhecimento a partir de dados interligados, é umimportante mecanismo de gestão e integração de informações”.

Os dados abertos ligados são capazes de gerar esse conhecimento, uma vez queesses favorecem a interação entre duas ou mais fontes de informações, permitindo querelações sejam derivadas entre esses conhecimentos.

A transformação de dados abertos para dados abertos ligados foi melhor descritapor Berners-Lee ao apresentar um modelo de 5 estrelas para o Governo Eletrônico. Desdeentão, o modelo de Berners-Lee foi adaptado e explicado de várias maneiras diferentes.Um resumo do modelo de 5 estrelas de Berners-Lee pode ser observado na Tabela 2.1.

Tabela 2.1: As 5 estrelas do modelo Gov 2.0

? Informação está disponível na web (qualquer formato) sobre uma licençaaberta

? ? Informação está disponível como um dado estruturado (e.g. Excel ao invés deuma imagem escaneada de uma tabela)

? ? ? Utilização de formatos não proprietários (e.g. CSV ao invés de Excel)? ? ? ? Identificação por URI para que as pessoas possam apontar para os dados

individualmente.? ? ? ? ? Os dados estão ligados a outros dados para fornecer contexto

Hausenblas[40] apresenta um modelo de custos e benefícios para aqueles quepublicam e para aqueles que consomem DAL, a partir do modelo de 5 estrelas propostopor Berners-Lee. Esse modelo pode ser observado através de 5 tabelas, correspondendocada uma dessas a uma das cinco estrelas do modelo proposto por Berners-Lee. Essaspodem ser observadas a seguir nas Tabelas 2.2 a 2.6

Esse modelo não representa uma definição absoluta, mas apenas uma forma devisualizar o que os agentes que publicam e que consomem informações podem esperar desistemas que se proponham a atender essa filosofia.

Observa-se que o publicador obtém o ônus de formatar e vincular a informação,algo que ainda é feito de forma manual. O consumidor da informação ganha uma série debenefícios para trabalhar com os dados, pois esse pode utilizar e mesmo agregar valor aesses dados.


Tabela 2.2: Custos e benefícios do modelo de ? dados web

Como consumidor Como publicadorPode vê-lo É fácil publicarPode imprimi-loPode armazená-lo localmente (no seu discorígido)Pode inserir os dados manualmente em outrosistema

Tabela 2.3: Custos e benefícios do modelo de ? ? dados web

Como consumidor, pode fazer tudo que oanterior fazia, mais:

Como publicador...

Pode processar diretamente com softwareproprietário para agregá-lo, executar cálcu-los, visualizá-lo, etc

É fácil publicar.

Pode exportá-lo para outro formato (estrutu-rado).

Tabela 2.4: Custos e benefícios do modelo de ? ? ? dados web


Como publicador

Não tem que pagar por um formato em queuma única entidade tem controle exclusivo

É fácil publicar.

Tabela 2.5: Custos e benefícios do modelo de ? ? ? ? dados web


Como publicador

Pode ligar o dado de qualquer outro lugar,seja na web ou localmente.

Precisará investir algum tempo dividindo eseparando os dados.

Pode marcá-lo. Precisará atribuir URIs para as propriedadesdos dados e pensar em como representar osdados.

Pode reutilizar partes dos dados. Tem um bom controle granular sobre aspropriedades de dados e pode otimizar oseu acesso (por exemplo, balanceamento decarga, cache, etc)

Tabela 2.6: Custos e benefícios do modelo de ? ? ? ? ? dados web


Como publicador

Pode descobrir novos dados de interesse aoconsumir outras informações.

Precisará investir recursos para vincular osdados com outros dados na Web.

Tem acesso ao esquema de dados. Tornar os dados descobríveis.Aumenta o valor dos dados.


2.4 Sobre o Capítulo

Ao longo deste capítulo, foram apresentados alguns conceitos consideradosrelevantes para o desenvolvimento da proposta desse trabalho. O conteúdo apresentadosobre Modelos de Bancos de Dados, Web Semântica e Dados Abertos apresentou umcaráter introdutório e restrito às necessidades desse projeto.

Dentre os temas tratados neste capítulo, a Web Semântica é aquele com maispossibilidades, pois implica numa mudança geral de paradigmas da web. Mudanças essasque permitirão um significativo avanço na capacidade dos computadores atuais trataremas informações.

Todo o esforço empregado neste trabalho dedica-se a desenvolver meios que au-xiliem na adoção da Web Semântica, através da utilização de bases de dados tradicionaispara formatos abertos com nível de estruturação e semântica.

CAPÍTULO 3Bases de Conhecimento e suas Ontologias

A forma de representar dados na web, apesar de parecer um conceito muitosimples, carrega uma série de requisitos, pois até o momento a web foi desenvolvidaprincipalmente em formato não estruturado, onde a semântica dos conceitos dos objetosdo mundo real é colocada de forma implícita, voltada para o entendimento do ser humano.As representações de dados utilizadas dentro da Web Semântica definem as possibilidadescomputacionais, existindo uma relação entre a expressividade da linguagem utilizada e acapacidade de processamento do computador. A Figura 3.1 apresenta uma visão do ganhode expressividade observado de acordo com a linguagem adotada.

Figura 3.1: Linguagens Utilizadas na Web

É possível observar que a web atual, utilizando representações de dados na formade linguagem natural com uma representação de dados pouco expressiva como a HTML,apresenta grandes limitações em termos de aproveitamento de recursos computacionais.Os esforços da Web Semântica têm sido principalmente para transformar o modeloatual pouco expressivo, num modelo mais facilmente compreensível pelos computadores.Ferramentas de anotação semântica, ou vinculação de dados de fontes pouco estruturadastêm sido desenvolvidas com o intuito de trazer a web tradicional para o modelo semântico.

38

Dentre as linguagens apresentadas, o RDF tem sido uma importante aposta,devido a seu formato simples e com razoável expressividade. O próprio conceito de DadosAbertos Ligados intersecta-se com o do RDF, onde um recurso proveniente de uma páginaweb, um documento de texto plano ou um banco de dados, uma vez anotado pode serreferenciado para recursos de um outro domínio. Esses domínios muitas vezes possuemcomplexas ontologias, representadas em linguagens como a OWL, as quais possuemdefinições complexas a respeito de seus recursos e os relacionam com recursos de outrosdomínios.

Esses domínios com complexas ontologias, que possuem recursos bem defini-dos por meio de esquemas de representação em RDF, são chamados de repositórios se-mânticos. Segundo Kiryakov e Damova[49], repositórios semânticos são sistemas quecombinam características dos sistemas de gerenciamento de banco de dados (SGBD) emotores de inferência, capazes de lidar com dados estruturados, levando em consideraçãosua semântica.

Ao mapear uma fonte de dados qualquer para um formato RDF e vinculá-laa outros repositórios semânticos, inclui-se essa nova fonte de dados em uma rede derepositórios, formando uma verdadeira nuvem de dados semânticos. Tim Berners-Lee,um dos principais idealizadores do conceito de Web Semântica, propôs um modelo deevolução para a web, onde as fontes de dados atuais podem ser integradas por meio deprocedimentos de conversão e anotação semântica[11].

A Figura 3.2 apresenta um modelo adaptado da proposta de Berners-Lee paraa integração de bases heterogêneas. Nesse modelo, fontes de dados diversas, sejam elasfontes não estruturadas, semi-estruturadas ou estruturadas, são trazidas para um formatode representação em RDF. Esse conjunto de dados em RDF, tomados com ontologias eacesso de dados por meio de ferramentas como o SPARQL, formam uma camada quepode alimentar uma série de serviços computacionais de natureza semântica.

Nas seções seguintes desse capítulo, são apresentados alguns repositórios se-mânticos conhecidos, selecionados por critérios, como sua diversidade de conteúdo, inte-gração com outros repositórios e utilização em pesquisas relacionadas à Web Semântica.Também apresenta-se uma rápida visão das ontologias que os definem e suas formas deacesso.

3.1 DBPedia 39

Figura 3.2: Modelo Adaptado de Integração de Dados de Beners-Lee

3.1 DBPedia

DBPedia[51] é uma base de conhecimento multilinguístico construída em grandeescala para agrupar informações enciclopédicas provenientes do projeto Wikipedia. Aenciclopédia digital Wikipedia é o sexto website mais acessado do planeta1. Ela possuiversões em mais de 287 idiomas, tendo centenas ou até milhões de artigos em cada umade suas edições e está disponível de forma gratuita e aberta.

A maior parte do conhecimento proveniente da Wikipedia encontra-se em for-mato de texto plano, para servir ao entendimento dos seres humanos. Entretanto a estru-tura dessa enciclopédia digital abrange também uma série de informações apresentadasem formatos estruturados, como tabelas, listas e conteúdo agrupado em estruturas conhe-cidas como infoboxes.

O projeto DBPedia visa reunir essa informação estruturada da Wikipedia em umúnico repositório, sendo organizado segundo as classes de uma ontologia pré-definidae disponibilizado como um Dado Ligado. A partir disso, a informação semanticamentecategorizada da DBPedia permite que aplicações efetuem consultas com um nível decomplexidade muito maior do que as simples consultas por palavra-chave da Wikipedia.

Assim como a Wikipedia, o projeto DBPedia é mantido a partir de um esforçocolaborativo mundial, onde os membros do projeto não somente mantém o esquemaontológico, mas criam novas ferramentas de mapeamento entre as enciclopédias. Deforma geral, pode-se dizer que o projeto DBPedia trata-se de um projeto de mapeamento

1http://www.alexa.com/topsites, acessado em agosto de 2014

3.1 DBPedia 40

de informação multilinguístico proveniente das várias edições da Wikipedia. Ao todo oprojeto DBPedia trabalha com 111 edições da Wikipedia, disponibilizando as informaçõesde pelo menos 14 dessas na forma de SPARQL Endpoint.

O projeto DBPedia é possivelmente um dos mais importantes repositórios se-mânticos existentes, pois tornou-se uma referência para a maioria dos outros, já que umagrande parte dos repositórios existentes hoje em dia possuem esquemas de mapeamentode seus modelos para o encontrado na DBPedia. Esse tópico é discutido em mais detalhesna Seção 3.6.

3.1.1 Ontologia DBPedia

Apesar de ser um projeto para representar semanticamente informação proveni-ente de qualquer fonte, assim como ser uma referência para a maior parte dos repositóriossemânticos encontrados atualmente, a DBPedia possui uma ontologia relativamente sim-ples. Ao todo sua ontologia possui cerca de 320 classes e 1650 propriedades.

Além disso, possui uma estrutura hierárquica de no máximo cinco níveis, sendomantida dessa forma para facilitar o entendimento e para que possa ser visualizadaintegralmente, assim como para manter uma estrutura de navegação simples.

Essa ontologia pode ser visualizada de forma integral e on-line através do portalda DBPedia2.

3.1.2 Acessando a DBPedia

Como um dos principais projetos de Dados Abertos Ligados do mundo, o projetoDBPedia oferece acesso a seus dados na forma de triplas RDF, de três formas diferentes.Sendo todas elas livres e sem qualquer restrição quanto ao uso.

É possível acessar as triplas RDF da DBPedia utilizando um SPARQL Endpoint3

público, mantido sobre um cluster de quatro nós de um Virtuoso Universal Server[35].Esse SPARQL Endpoint apresenta um mecanismo de paralelização de execução deconsultas de usuários, podendo dividir o processamento sobre vários nós do cluster. Nota-se que, devido ao grande número de dados provenientes desse repositório, existe umalimitação de trafego que permite a realização de consultas cujo o resultado não excedao tamanho máximo de 50000 linhas. Dessa forma, os usuários desse SPARQL Endpointgeralmente devem utilizar limitadores como OFFSET e LIMIT.

Além de fornecer acesso por meio de consultas SPARQL, a DBPedia possui ummecanismo de acesso do tipo a Linked Data Hub onde, por meio de requisições HTTP, o

2http://mappings.dbpedia.org/server/ontology/classes/3http://dbpedia.org/sparql

3.2 GeoNames 41

endpoint redireciona o usuário para páginas HTML ou dados em RDF em formatos comoo RDF/XML.

Por fim, é possível a utilização do repositório DBPedia por meio de um sincro-nizador de dados, que baixa a informação proveniente do endpoint e o armazena no com-putador local do usuário, mantendo assim um espelho atual do repositório da DBPedia.Dessa forma, o sincronizador mantém o repositório local do usuário apenas atualizandoaquilo que foi alterado entre uma sincronização e outra.

3.2 GeoNames

GeoNames[37] é um banco de dados com informações geográficas globais,abrangendo funções de busca, mapas e arquivos de dados para download disponívelgratuitamente e em formato aberto.

Segundo informações do próprio GeoNames4, essa base de dados contém maisde 10 milhões de nomes geográficos e é composto por mais de 8 milhões de recursosexclusivos, nos quais 2,8 milhões corresponde a lugares povoados e 5,5 milhões de nomesalternativos.

O objetivo do projeto GeoNames é integrar dados geográficos, tais como nomesde lugares em línguas diferentes, altitude, população e outras informações provenientesde fontes de dados diversas. Trata-se de um projeto desenvolvido por uma comunidade deusuários, dessa forma o projeto fornece possibilidades de edição manual e correções denomes por parte dos usuários do serviço.

As informações de coordenadas do projeto GeoNames são disponibilizadas deforma aberta em formato WGS845.

3.2.1 Ontologia GeoNames

O projeto GeoNames apresenta um esquema ontológico simples e aberto derepresentação de dados6, definido sobre uma estrutura de apenas sete classes. Essaontologia contém ainda vinte e nove propriedades, sendo treze propriedades de tipos dedados e dezesseis de objetos.

Essa ontologia descreve locais por meio de diferentes classificações de nomes(nome, nome oficial, nome alternativo, nome coloquial, nome abreviado) e por meio deuma divisão espacial de nove tipos, como listados abaixo:

4http://www.geonames.org/about.html, acessado em julho de 20145World Geodetic System. Norma usada em cartografia de origem geocêntrica, utilizada principalmente

pelo Sistema de Posicionamento Global - (GPS)6http://www.geonames.org/ontology/ontology_v3.1.rdf

3.3 WordNet 42

• Limites Administrativos: país, estado, região, . . .• Hidrográfica: rios, lagos, . . .• Áreas: parques, bairros, . . .• Locais Populados: cidades, vilas, . . .• Transporte: rodovias, ferrovias . . .• Recursos à Vista: construções, fazendas, . . .• Hipsográfico: montanhas, colunas, . . .• Marítimos: recifes, corais, depressões, . . .• Vegetação: florestas, bosques, plantações, . . .

Todos os recursos do GeoNames apresentam definições utilizando SKOS [5],assim como especificam a nomenclatura do recurso em cinco línguas diferentes.

3.2.2 Acessando o GeoNames

A informação do GeoNames pode ser obtida de duas formas. A primeira dasformas de acesso é o download integral da base de dados do GeoNames por meio de umasérie de arquivos em formato zip disponibilizadas no site do GeoNames.

A segunda é através da consulta a um Web Service com uma interface de buscapré-definida, onde o usuário pode realizar requisições com campos para buscas do nomedo local, locais que começam com o texto, locais que contém o texto, entre outraspossibilidades. Esse Web Service oferece a opção de configuração do formato da respostaem XML ou JSON.

3.3 WordNet

WordNet[53] é um banco de dados léxico da língua inglesa, em desenvolvimentopelo Cognitive Science Laboratory da Universidade de Princenton desde 1985. Nessedicionário léxico os dados sobre substantivos, verbos, adjetivos e advérbios são agrupadosem conjuntos de sinônimos cognitivos chamados synsets, cada um expressando umconceito distinto.

A classificação das palavras em synsets ocorre de acordo com o significado dessapalavra num dado contexto. Assim, cada synset identifica um sentido (conceito ou seja,semântica). Palavras com múltiplos significados, palavras ambíguas, pertencem a váriossynsets.

Além da classificação das palavras em synsets, o WordNet especifica uma sériede relações lógicas entre palavras e synsets. A Tabela 3.1 resume as principais relaçõeslógicas encontradas na WordNet.

3.4 YAGO2 43

Tabela 3.1: Exemplo de Relações Léxicas na WordNet

Sinônimos significa o mesmo que Bonito significa o mesmo que beloHiperônimos termo geral para Mobília é o termo geral para sofáHipônimos tipo de Sofá é um tipo de mobíliaMerônimos parte de

membro deGalho é parte de uma árvoreUma pessoa é membro de um grupo

Holônimos tem partemembro

Carro tem a roda como parteUm grupo tem uma pessoa como membro

Antônimos contrário de Alto é o contrário de baixo

3.3.1 Ontologia WordNet

Apesar de ser um dos repositórios mais utilizados dentro das pesquisas sobreWeb Semântica, a WordNet não foi concebida inicialmente como um RDF/OWL. Muitossão os trabalhos que consideram técnicas para converter ou tratar os dados provenientesda WordNet para o formato RDF/OWL, entretanto somente em junho de 2006 o consórciow3c estabeleceu um padrão para trabalhar com a WordNet em aplicações semânticas7.

No total, a WordNet possui cerca de 117659 synsets, sendo 82115 substantivos,13767 verbos, 18156 adjetivos e 3621 advérbios8. Entretanto, muitas das cadeias decaracteres existem em mais de uma categoria. De forma que, o total, considerando arelação palavra por significados é de 206941.

3.3.2 Acessando o WordNet

É possível baixar a base de dados da WordNet em formatos como o zip e o tar.gzno site oficial da Universidade de Princenton. Além disso, existem SPARQL Endpointsnão oficiais do qual é possível realizar consultas SPARQL a base de dados da WordNet.

3.4 YAGO2

YAGO2[42] é uma base de conhecimento construída sobre o paradigma dedivisão de fatos, entidade e eventos definidos em termos de tempo e espaço. Essa base dedados é construída automaticamente a partir das informações estruturadas da Wikipedia,do GeoNames e da WordNet.

YAGO2, atualmente, possui dados de cerca de 10 milhões de entidades9, taiscomo pessoas, organizações, cidades, entre outros. Estima-se que existam cerca de 120

7http://www.w3.org/TR/wordnet-rdf/, acessado em julho de 20148http://wordnet.princeton.edu/wordnet/man/wnstats.7WN.html9https://www.mpi-inf.mpg.de/departments/databases-and-information-systems/research/yago-

naga/yago/, informação obtida em Julho de 2014

3.4 YAGO2 44

milhões de fatos sobre estas entidades.Apesar de ser uma base de conhecimento semântico construída a partir de outras

bases de informação, esse projeto tem suas triplas RDF validadas manualmente, sendo queoficialmente possui uma precisão com relação a suas tuplas de cerca de 95% de acuráciaconfirmados.

3.4.1 Ontologia YAGO2

YAGO apresenta um modelo próprio de representação de dados, baseado noRDFS, o qual denomina-se YAGO model. Nesse modelo de dados, todos os objetos (ex.:cidades, pessoas, etc. . . ) são representados como entidades. A ligação entre as entidadesé chamada de relação. O conjunto de entidades unidas por uma relação é chamada de fato.

Numa definição recursiva, as classes e relações e até mesmo os fatos tambémsão vistos como entidades dentro desse modelo. Outro aspecto importante a ser destacadoé que dentro do YAGO model, números, cadeias de caracteres, palavras e outros literaistambém são interpretados como entidades.

Como pode ser observado, a entidade dentro desse modelo corresponde a umconceito muito amplo. De forma geral, o conceito de entidade dentro do YAGO model éde um objeto abstrato de uma ontologia, que seja independente de linguagem[42].

Dentro de sua definição geral de entidades, esse modelo apresenta uma subdivi-são de entidades comuns e entidades individuais. A primeira corresponde a entidades quenão são nem fatos e nem relações. A segunda corresponde a uma entidade comum quetambém não é uma classe.

Dessa forma, é possível definir a ontologia YAGO através de uma função injetiva,tomando C como um conjunto finito de entidades comuns, R como um conjunto finito derelações e I como um conjunto finito de fatos, tem-se:

y : I =⇒ (I∪C∪R)×R× (I∪C∪R)

Ao todo, a ontologia YAGO2 possui cerca de 72 tipos de relações, cerca de 350.000classes, dez milhões de entidades e cerca de 120 milhões de fatos.

3.4.2 Acessando o YAGO2

É possível baixar todo o banco de dados e ontologia do YAGO2 no site oficial doprojeto10 em formatos de texto ttl e tsv. Além disso YAGO2 oferece uma interface web de

10https://www.mpi-inf.mpg.de/departments/databases-and-information-systems/research/yago-naga/yago/downloads/

3.5 Freebase 45

acesso utilizando requisições HTTP do tipo POST. Existe ainda a possibilidade de navegarpela ontologia do YAGO2 utilizando um browser de ontologias disponível no site oficialdo projeto. A partir de novembro de 2014, foi disponibilizado um SPARQL Endpoint paraacessar a base de dados do YAGO2, apesar de ainda apresentar certa instabilidade.

3.5 Freebase

Freebase[15] é um banco de dados de tuplas, usado para estruturar fatos doconhecimento humano em geral. Seus dados são criados, estruturados e mantidos deforma colaborativa. Freebase foi desenvolvido pela Metaweb Tecnologies e foi adquiridopela Google em 2010.

A ideia por trás do Freebase é tenta mesclar a escalabilidade de bases de dadosestruturadas, com a diversidade de wikis colaborativos em uma base de conhecimentohumano de propósito geral. Esse projeto visa à praticidade, fornecendo interfaces eferramentas que permitam a usuários leigos o uso imediato, tanto para consultar quantopara contribuir com adição de novos dados.

Cita-se ainda que o Freebase possui uma filosofia da normalização completa dosdados. Ao contrário de alguns bancos de dados, as entidades Freebase são construídaspara ser explicitamente únicas. Ou seja, deve haver apenas um GUID em Freebaserepresentante de cada entidade, tópico ou conceito do mundo real.

Essa base de dados é constituída a partir de uma série de fontes, alguns dadossão carregados por ferramentas de extração automáticas, alguns enviados a granel, querpela equipe de Dados da Metaweb Tecnologies ou pela comunidade de colaboradores,utilizando API ou outras ferramentas de carregamento de dados. Existe ainda uma parcelade dados que são adicionados manualmente pedaço por pedaço por indivíduos quesimplesmente usam o site oficial.

3.5.1 Ontologia Freebase

Freebase não possui uma ontologia que o defina, ao invés disso esse projetoutiliza um metaesquema de descrição das suas propriedades. Esse metaesquema defineum método simples para explorar o conteúdo do banco de dados na forma de caminhosentre categorias.

Como um exemplo de caminho válido dentro do metaesquema do Freebase cita-se /film/director/film. Através desse caminho, o metaesquema interpreta a solicitação feitacomo a consulta “que filmes um diretor de filmes dirigiu”.

3.6 Interligando Dados Abertos 46

Ao todo, o Freebase possui cerca de 45076141 de tópicos, 2631063003 fatosdivididos em cerca de 77 categorias11.

3.5.2 Acessando o Freebase

Apesar de não possuir uma ontologia que o defina, Freebase oferece a possibili-dade de baixar toda a informação de sua base de conhecimento no formato RDF N-Triples,empacotado e compactado em um arquivo do tipo tar.gz.

Outra forma de acesso aos dados usando o Freebase seria através de requisiçõesHTTP a uma API de consultas programáticas numa linguagem especial chamada MQL.MQL significa Metaweb Query Language, trata-se de um formato de consulta semelhanteao SPARQL desenvolvido especificamente para consultas ao Freebase. Essa API utiliza oformato JSON tanto na requisição quanto na resposta.

3.6 Interligando Dados Abertos

Dados Abertos Ligados trazem no seu conceito e descrição a ideia de queesses dados, geralmente localizados em repositórios semânticos, devem possuir ligaçõesentre si. Essas ligações, principalmente aquelas que expressam relações de igualdadeentre classes e entidades das ontologias que definem esses repositórios, são de grandeimportância. A partir do momento que uma entidade ou classe é definida como possuindouma relação de igualdade com uma entidade ou classe de um outro repositório, a mesmapassa a partilhar das evoluções que a entidade ou classe venha a sofrer.

No contexto da nuvem semântica, onde a informação é partilhada entre osrepositórios, quanto maior o número de ligações entre os repositórios, maior será aexpressividade do dado web. Desse modo, mais importante que a representação do dadoé como esse dado se encontra com relação a outros repositórios.

Não é possível enumerar nesse trabalho todas as ligações existentes entre osrepositórios semânticos, pois essas são demasiadamente numerosas. Tomando comoexemplo a DBPedia, um repositório de referência dentro da nuvem semântica, é possívelobservar como é numerosa a quantidade de ligações entre os repositórios.

Na Tabela 3.2 é possível observar os repositórios que a DBPedia referencia,sendo esses dados de abril de 2013. Na primeira coluna aparece o nome dos repositóriosreferenciados, na segunda coluna apresenta-se o predicado utilizado para ligar a entidadeDBPedia ao repositório externo. Por fim, na terceira coluna, apresenta-se o número deligações existentes.

11Números de Agosto de 2014

3.6 Interligando Dados Abertos 47

Tabela 3.2: Ligações da DBPedia para outros repositórios[51]

Repositório Predicados QuantidadeAmsterdam Museum owl:sameAs 627BBC Wildlife Finder owl:sameAs 444Book Mashup rdf:type 9100

owl:sameAsBricklink dc:publisher 10100CORDIS owl:sameAs 314Dailymed owl:sameAs 894DBLP Bibliography owl:sameAs 196DBTune owl:sameAs 838Diseasome owl:sameAs 2 300Drugbank owl:sameAs 4 800EUNIS owl:sameAs 3 100Eurostat (Linked Stats) owl:sameAs 253Eurostat (WBSG) owl:sameAs 137CIA World Factbook owl:sameAs 545flickr wrappr dbp:hasPhoto- 3 800 000

CollectionFreebase owl:sameAs 3 600 000GADM owl:sameAs 1 900GeoNames owl:sameAs 86 500GeoSpecies owl:sameAs 16 000GHO owl:sameAs 196Project Gutenberg owl:sameAs 2 500Italian Public Schools owl:sameAs 5 800LinkedGeoData owl:sameAs 103 600LinkedMDB owl:sameAs 13 800MusicBrainz owl:sameAs 23 000New York Times owl:sameAs 9 700OpenCyc owl:sameAs 27 100OpenEI (Open Energy) owl:sameAs 678Revyu owl:sameAs 6Sider owl:sameAs 2 000TCMGeneDIT owl:sameAs 904UMBEL rdf:type 896 400US Census owl:sameAs 12 600WikiCompany owl:sameAs 8 300WordNet dbp:wordnet type 467 100YAGO2 rdf:type 18 100 000Somatório 27 211 732


Tabela 3.3: Os 10 repositórios com mais ligações para aDBPedia[51]

URL do Repositório Quantidade de Predicados Quantidade de Ligaçõesokaboo.com 4 2,407,121tfri.gov.tw 57 837,459naplesplus.us 2 212,460fu-berlin.de 7 145,322freebase.com 108 138,619geonames.org 3 125,734opencyc.org 3 19,648geospecies.org 10 16,188dbrec.net 3 12,856faviki.com 5 12,768

É possível realizar a análise inversa também, onde analisa-se os repositórios quepossuem uma ligação com a DBPedia. Na Tabela 3.3, apresenta-se os 10 repositórioscom maior número de ligações com a DBPedia. Na primeira coluna, tem-se o URL dorepositório, na segunda coluna o número de predicados distintos usados para referenciarelementos da DBPedia. Por fim, na terceira coluna, a quantidade de ligações.


Ao longo deste capítulo, foram apresentados alguns dos repositórios semânticosmais conhecidos atualmente. Existem centenas de outros não tratados nesse trabalho,entretanto, optou-se por descrever aqueles considerados mais representativos.

Observou-se que, mais importante do que disponibilizar seus dados em formatoaberto e fornecer acesso por requisições HTTP, Web Services ou SPARQL Endpoint, omais importante dessas informações é que elas relacionam-se entre si. Os conceitos deum repositório são ligados com os de outro repositório.

Em alguns casos, o mapeamento entre um repositório e outro é parcial, ou seja,nem todas as entidades existentes entre os repositórios é mapeada. Em outros casos omapeamento é total, ou seja, todas as entidades do repositório são mapeadas, como nocaso do YAGO com a WordNet. Essa interligação entre os repositórios demonstra oquanto o paradigma de vinculação dos dados está presente dentro da Web Semântica.

CAPÍTULO 4Trabalhos Relacionados

Os trabalhos apresentados nessa seção objetivam solucionar o mesmo problemaproposto nessa pesquisa. As abordagens utilizadas pelo autores de cada um dessestrabalhos divergem bastante entre si, indo desde técnicas muito simples até frameworks

muito complexos de análise de banco de dados.Os dois primeiros trabalhos apresentados, usam técnicas de mapeamento manual

de bancos de dados para ontologias, onde existem padrões estabelecidos para nomeaçãoe definição dos elementos mapeados.

Em seguida, é apresentada uma ferramenta que usa um complexo esquema demapeamento, utilizando um banco de dados externo e a inserção de scripts de mapea-mento por parte do usuário. Os demais trabalhos desse capítulo buscam similaridadesentre cadeias de caracteres, presentes entre as ontologias e os banco de dados, cada umapresentando uma abordagem diferente e chegando a diferentes tipos de resultados.

4.1 Morph RDB

Morph-RDB[66] é um processador de mapeamento R2RML, desenvolvido emScala, pelo Ontology Engineering Group1 como continuação do projeto ODEMapster2.

Seu principal objetivo é realizar o mapeamento de bancos de dados relacionaispara representações em RDF usando o mapeamento R2RML. R2RML é uma linguagempara expressar mapeamentos personalizadas a partir de bancos de dados relacionais paraum conjuntos de dados RDF. Esses mapeamentos fornecem a capacidade de visualizardados relacionais existentes no modelo de dados RDF, expressa em uma estrutura evocabulário alvo da escolha do autor do mapeamento.

Morph-RDB trabalha com dois modos básicos de operações, a atualização dedados e a tradução de consultas. No primeiro, acontece a geração de dados RDF a partir

1http://www.oeg-upm.net/, acessado em junho de 20152http://mayor2.dia.fi.upm.es/oeg-upm/index.php/en/downloads/9-r2o-odempaster, acessado em junho

de 2015

4.2 RDOTE 50

de um banco de dados relacional, de acordo com as descrições de mapeamento R2RML.No segundo modo de operação, consultas são realizadas em SPARQL e avaliadas sobreum conjunto de dados RDF virtual criados a partir do banco relacional de origem, asconsultas são reescritas em SQL, de acordo com as descrições de mapeamento R2RML.

Esse framework trabalha com sistemas de gerenciamento de banco de dadosrelacionais como MySQL, PostgreSQL e MonetDB. Recentemente, foi realizada umaextensão desse framework para permitir a integração com o Google Fusion Tables,chamado Morph-GFT[65].

4.2 RDOTE

Um outro exemplo de definição manual de mapeamento entre bancos de dadosrelacionais e ontologias pode ser observado no RDOTE[77]. Essa é uma ferramentagráfica para definição manual de esquemas de mapeamento de banco de dados, onde oSQL é usado como meio para especificação do subconjunto de dados que serão mapeadospara instâncias de classes em ontologias.

RDOTE se conecta a um sistema gerenciador de banco de dados relacional, domesmo modo que carrega uma ontologia de destino desejado. O usuário então escreveconsultas SQL que selecionam as tuplas que deseja-se representar como um grafo RDF.Nesse caso, cada consulta representa um conjunto de resultados usado para preencher umaclasse de ontologia. As consultas realizadas devem possuir a chave primária das tabelas,pois do contrário podem ocorrer duplicações e outras possíveis falhas no processo demapeamento.

Existe uma etapa opcional no processo de execução do RDOTE onde o usuáriopode definir opções de renomeação e junção de cadeias de caracteres para os casos deconsultas que selecionam dados de múltiplas colunas.

O usuário então realiza uma etapa de conexão de consultas com classes daontologia, desta forma, para cada tupla de uma consulta SQL, uma instância da respectivaclasse é criada. Caso se deseje utilizar os dados reais, em vez de apenas criar URIs, oRDOTE oferece a possibilidade de copiar as informações reais das tuplas numa série depossíveis formatos.

Uma vez realizadas as conexões entre as consultas SQL do usuário com asclasses da ontologia é possível estabelecer ligações condicionais do mapeamento comoutros mapeamentos, por meio de propriedades do objeto ou, no caso de propriedades detipo de dados com consultas SQL. Todo esse processo é realizado utilizando um esquemasimples ao usuário do tipo clicar e arrastar, numa interface gráfica simples.

O resultado do RDOTE é um esquema de associação de consultas com classesda ontologia, onde essas são armazenados em um arquivo de configuração. Dessa forma,

4.3 RDB2OWL 51

o usuário pode realizar consultas referenciando a ontologia, onde o formato de saída podeser especificado pelo usuário em formatos abertos, tais como o RDF/XML ou N3.

4.3 RDB2OWL

RDB2OWL[26] é um acrônimo para Relational Database to OWL. Consideradouma das mais famosas ferramentas para mapear esquemas de banco de dados relacionaispara ontologias, esse framework apresenta um mecanismo complexo para realizar omapeamento utilizando um banco de dados externo com um esquema pré-definido paraarmazenar os dados da ontologia e do banco de dados que se deseja mapear.

Esse esquema de banco de dados é, de fato, um meta esquema desenvolvidoespecificamente para realizar esse processo de mapeamento. Na Figura 4.1 é possívelobservar o esquema de banco de dados utilizado pelo RDB2OWL.

Figura 4.1: Esquema de Mapeamento do RD2OWL[22]

No processo de mapeamento, considera-se uma ontologia e um ou mais bancosde dados de domínios correlatos. As informações dos bancos de dados são armazenadasem três tabelas, sendo essas db_database, db_table e db_column. As informações sobre

4.4 MARSON 52

a ontologia são armazenadas nas tabelas, ontology, owl_class, owl_object_property eowl_datatype_property. Os mapeamentos são especificados nos registros das tabelasclass_map, object_property_map, datatype_property_map.

O usuário então introduz as informações de mapeamento a partir do qual osscripts SQL são gerados para realizar a transformação de consultas no nível de instância.

4.4 MARSON

MARSON[44] é um acrônimo para Mapping between relational schemas and

ontologies.Este framework possui uma abordagem simples porém diferenciada com relação

aos demais. Primeiramente, as relações são classificados em grupos, de acordo com o queelas representam, se representam entidades ou relacionamentos entre entidades.

Vetores de coeficientes, chamados documentos virtuais, são construídos paracada relação e atributo do esquema de banco de dados. A descrição de uma relação levaem conta a descrição de relações ligadas a ela através de chaves estrangeiras, enquanto adescrição dos atributos incorpora a descrição da sua relação pai e outras relações ligadas aeste último. Da mesma forma, os documentos virtuais para todas as classes e propriedadesda ontologia são construídos e similaridades existentes entre os elementos do esquema debanco de dados e da ontologia são calculados como pares de distância cosseno de seusvetores de identificação. Em outras palavras, MARSON interpreta o esquema relacionalcomo um gráfico e utiliza a teoria matemática fundamental para interpretá-lo.

MARSON é um projeto que visa automatizar completamente o processo dedescoberta de mapeamentos entre um banco de dados relacional e uma determinadaontologia. Como tal, esse projeto se assenta no pressuposto de proximidade lexical entrenomes de elementos do banco de dados e da ontologia durante o cálculo dos coeficientesde similaridade e no pressuposto da existência de um número suficiente de indivíduos naontologia, necessário para o cálculo do ganho de informação

4.5 RONTO

RONTO[60] é mais uma ferramenta de comparação linguística entre ontologiase bancos de dados relacionais, onde são estabelecidas medidas de similaridade entreelementos estruturais correspondentes de um banco de dados e uma ontologia. Dessaforma os conceitos de relação, chave estrangeira e não estrangeira de atributos do bancode dados são comparados com classes, tipos de dados e propriedade da ontologia,respectivamente, para encontrar as correspondências lexicais mais próximas, que sãodepois validadas pelo usuário.

4.6 AuReLi 53

4.6 AuReLi

AuReLi[62] é um acrônimo para Automatic Relational Database to Linked Data

Converter.Essa ferramenta trabalha com similaridade de cadeias de caracteres entre as onto-

logias e tabelas de um banco de dados relacional. Difere de outras abordagens por utilizardiversas medidas de similaridade para comparar atributos e relações provenientes de ban-cos de dados relacionais com as propriedades e classes de uma ontologia especificadas apriori.

Um outro fato importante sobre o AuReLi é que essa ferramenta busca avinculação dos dados provenientes do banco de dados com as instâncias da ontologiaatravés de um sistema de consultas pré-definidas de associação entre essas e entidades daDBPedia. Os resultados do algoritmo, em seguida, são apresentados ao utilizador humanopara validação. AuReLi é implementado como uma extensão D2R Linked Server3 comacesso a dados utilizando SPARQL.

4.7 StdTrip

StdTrip[69] é uma ferramenta de triplificação, ou seja, uma ferramenta quetrabalha com a conversão de bancos de dados relacionais para triplas RDF. A propostaprincipal do StdTrip é promover um mecanismo de reutilização de vocabulários padrõesexistentes.

Nessa proposta, é realizada a suposição implícita de que o banco de dados deentrada está totalmente normalizado, ou seja, supõem-se que as entradas para a ferramentaatendam os critérios da terceira forma normal. Essa ferramenta apresenta a característicade considerar que o usuário do sistema tem algum conhecimento sobre o domínio daaplicação das bases de dados tratadas.

O processo de reutilização de vocabulários proposto pelo StdTrip, é dividido emseis etapas, resumidas a seguir:

1. Conversão. Esta etapa consiste em transformar a estrutura do banco de dadosrelacional para uma ontologia RDF. Nesse ponto, o designer pode confiar emabordagens como a proposta pelo W-Ray[61].

2. Alinhamento. Este passo utiliza uma ferramenta de alinhamento para fazer aontologia, obtida no Passo 1, corresponder a um conjunto de vocabulários padrõesconfigurados na ferramenta. Esta operação fornece, para cada elemento do esquema

3http://d2rq.org/d2r-server, acessado em junho de 2015

4.8 MASTRO 54

(tabela ou atributo) uma lista de possíveis correspondências. Por exemplo, umatabela chamada Pessoa seria combinadas para foaf: maker ou dc: creator[21].

3. Seleção. Esta etapa apresenta ao usuário uma lista de possibilidades de que ele ouela selecione o elemento do vocabulário que melhor representa cada conceito nabase de dados.

4. Inclusão. Se para um determinado elemento, o processo não produz qualquerresultado (não há nenhum elemento nos vocabulários conhecidos que coincide como conceito de banco de dados), ou nenhuma das sugestões na lista é consideradaadequada pelo usuário, StdTrip fornece uma lista de triplas de outros vocabuláriosque poderia ser uma possível combinação. O raciocínio é o seguinte “se o seuconceito não está abrangido por qualquer dos padrões conhecidos, olhe em voltae veja como os outros o tratam. Ao escolher um vocabulário já em uso, você irátorná-lo mais fácil de interligar ao seu vocabulário, do que através da criação de umnovo vocabulário. ”

5. Conclusão. Se nada funciona, os usuários são direcionados para o Best Practice

Recipes for Publishing RDF Vocabularies[13].6. Saída. O processo gera dois artefatos: (1) um arquivo de configuração, para servir

para a parametrização de uma ferramenta de triplificação padrão. (2) uma ontologiaque contém os mapeamentos do esquema de banco de dados original para ovocabulários padrão RDF.

4.8 MASTRO

MASTRO[23] é uma ferramenta desenvolvida na linguagem de programaçãoJAVA, criado na Universidade de Roma “La Sapienza” e na Universidade Livre de Bozen-Bolzano. Essa ferramenta foi desenvolvida com o objetivo de gerenciar sistemas de acessoa dados baseados em ontologias ( Ontology-Based Data Access - ODBA ).

A ideia dessa ferramenta consiste em descrever uma ontologia num formatoderivado do DL-Lite e expressar sentenças genéricas da lógica de primeira ordem. Dessaforma MASTRO é uma estrutura que permite a definição de mapeamentos entre umbanco de dados relacional e uma ontologia e a emissão de consultas conjuntivas expressasem EQL, uma linguagem semelhante ao SQL. Dessa forma, MASTRO é uma suíte deferramentas de acesso a dados de base ontológica que reformula uma consulta conjuntivaexpressa através de uma ontologia para uma consulta SQL que é avaliada sobre umbanco de dados relacional. Existem também nessa aplicação algoritmos otimizados pararesponder a consultas expressivas, bem como possui um sistema para recursos verificaçãoda consistência das requisições.

4.9 Resumo dos Sistemas Analisados 55

MASTRO fornece uma API proprietária, mas também possui uma interfacecompatível com a OWLAPI, e um plugin para o editor de ontologias Protégé.

4.9 Resumo dos Sistemas Analisados

Nesse momento, é possível realizar uma abordagem comparativa sobre os siste-mas de mapeamento tratados nesse capítulo. Na Tabela 4.1, alguns critérios são utilizadospara analisar as características desses sistema.

Tabela 4.1: Resumo Trabalhos Relacionados

Sistema Funcionamento Restrição Relacional NoSQL IntegradoMorphRDB Manual não sintá-

tico sem ontologia- Sim Não Não

RDRoute Manual não sintá-tico sem ontologia

- Sim Não Não

RDB2OWL Manual não sintá-tico com ontologia

- Sim Não Não

Marson Automático sintá-tico com ontologia

- Sim Não Não

Ronto Semiautomáticosintático comontologia

- Sim Não Não

AuReLi Automático sintá-tico com ontologia

- Sim Não Parcial

StdTrip Manual não sintá-tico sem ontologia

Banco dedados na3a formanormal

Sim Não Não

Mastro Manual não sintá-tico com ontologia

Ontologiaem DL-Lite

Sim Não Não

Segue uma explicação detalhada de cada coluna dessa tabela na lista a seguir.

1. Sistema. apresenta-se o nome da ferramenta analisada.2. Funcionamento. resumo das principais características, sendo o primeiro elemento

o modo de execução da ferramenta, esse modo é dividido em manual( usuário re-aliza as vinculações entre elementos da ontologia com os do banco de dados ),semiautomático ( usuário atual apenas validando os resultados ) e automático ( fer-ramenta gera o mapeamento sem a intervenção do usuário ). O método de análiseda ontologia e do banco de dados, é divido em não sintático, não analisa lexico-graficamente por meio de alguma medida matemática a relação entre elementos daontologia e do banco de dados, e sintático, o qual possui essa análise lexicográfica


com algum tipo de coeficiente de similaridade. O terceiro item dessa coluna refere-se à existência de uma ontologia de destino para mapear o banco de dados, ou seja,nos casos que o sistema não tem uma ontologia, o sistema geralmente gera umaontologia a partir do banco de dados. Nos casos que a coluna aparece com o valor“com ontologia”, significa que o usuário informa uma ontologia de destino, no qualo banco de dados é mapeado.

3. Restrição. apresenta alguma exigência do sistema.4. Relacional. indica se o sistema tem suporte ao mapeamento de bancos de dados do

tipo relacional.5. NoSQL. indica se o sistema tem suporte ao mapeamento de bancos de dados do

tipo NoSQL.6. Integrado. o sistema gera um mapeamento integrado com a nuvem semântica de

dados, observa-se que apenas o sistema AuReLi possui um mecanismo parcial deintegração de dados, onde os resultados são validados com a DBPedia.


Ao longo deste capítulo, foram descritos trabalhos relacionados com a ferra-menta proposta nessa dissertação, algumas dessas ferramentas trabalhando em processosde mapeamento de bancos de dados para ontologia de forma manual e outras de formaautomática ou semiautomática.

Entretanto, esses trabalhos dedicam-se exclusivamente ao mapeamento de bancode dados relacionais para ontologias específicas. Não existe uma preocupação em desen-volver um método que sirva tanto para mapear os bancos de dados relacionais quanto osbancos de dados NoSQL. Além disso, esses trabalhos tem como foco o simples mapea-mento do banco de dados para uma ontologia. Não existe uma preocupação em relacionaresse dado à nuvem semântica, tornando assim a informação um verdadeiro Dado AbertoLigado.

CAPÍTULO 5Solução Proposta

Como observado até o presente momento, o ato de mapear um banco de dadospara uma ontologia é uma tarefa complexa, onde vários caminhos podem ser adotados.Das técnicas observadas no capítulo anterior é possível distinguir duas principais aborda-gens. A primeira consiste em gerar ontologias a partir de bancos de dados relacionais, asegunda de mapear bancos de dados relacionais para uma ontologia preexistente.

Dentre essas duas abordagens, a segunda permite tratar um conjunto de bancosde dados distintos de maneira uniforme. Mapear bancos de dados para uma ontologia éuma atividade que permite tratar bases de dados segundo uma semântica conhecida. Aocriar um mecanismo para mapeamento de um banco de dados para uma ontologia pré-definida, cria-se vantagens para a interpretação de dados. Ontologias buscam forneceruma descrição mais exata do conhecimento, eliminando ambiguidades e assim facilitandoo compartilhamento do conhecimento.

As soluções propostas até o momento apresentam limitações, tanto no que dizrespeito ao seu objetivo ao limitar-se aos bancos de dados relacionais, quanto ao fato deque se restringem a realizar o mapeamento isolado entre os bancos de dados e a ontologiasem se preocupar em relacionar esses bancos no contexto da Web Semântica como umdado aberto ligado.

Pouca atenção foi dispensada até o momento para estabelecer esquemas demapeamento para bancos de dados NoSQL. Essa postura se justifica na medida que osbancos de dados relacionais representam a maior fonte de dados na web atual. Entretanto,faz-se necessária a avaliação dos bancos de dados não relacionais, pois esses vêmganhando espaço nos últimos anos, em detrimento dos relacionais em alguns cenáriosparticulares.

Da mesma forma, mapear um banco de dados para uma ontologia tem sido oúnico foco dos trabalhos observados no capítulo anterior. O relacionamento desses dadoscom o de outros repositórios semânticos representa a complementação do conteúdo dessasbases de forma semântica. Essa complementação do conteúdo semântico representa umaforma dinâmica de expandir o conhecimento do banco de dados.

5.1 Mapeamento Semântico de Banco de Dados 58

5.1 Mapeamento Semântico de Banco de Dados

Ao definir o objetivo desse trabalho, na Seção 1.2, apresentou-se uma definiçãoda palavra mapeamento. Em seguida, apresentou-se como principal objetivo desse traba-lho o processo de mapeamento entre um conjunto de bancos de dados e uma ontologia dereferência.

Um banco de dados é uma forma de representação de dados, assim como tantosoutros formatos existentes que apresentam uma semântica implícita. Mapear um bancode dados para uma ontologia, consiste na tentativa de apresentar os dados segundo umformato que favoreça a apresentação desse dados de forma que a semântica, ou seja, o seusignificado, se torne explícito.

Ontologia é uma forma de representação de informação que favorece a descriçãodo significado das coisas, não somente para o ser humano, mas também para o computa-dor.

O título desse trabalho, Mapeamento Semântico de Banco de Dados, refere-se aoato de tornar os bancos de dados analisados melhores descritos semanticamente. A Figura5.1, representa o ato do mapeamento semântico de um banco de dados.

(a) Tabelas para Nodos

(b) Banco de Dados Mapeado

Figura 5.1: Mapeamento Semântico de Banco de Dados

No exemplo da Figura 5.1(a), observa-se um banco de dados relacional, ou seja,suas informações são apresentadas em tabelas, sendo mapeado para os nodos de umaontologia. Nesse processo, são estabelecidos relacionamentos entre cada tabela do bancode dados relacional e um ou mais nodos da ontologia. Ao final do processo, Figura 5.1(b),o banco de dados mapeado para a ontologia de referência, pode ser acessado usando asdefinições presentes na ontologia.

5.2 Etapas da Solução 59

Ao conseguir estabelecer uma relação entre um modelo de dados simples, comoo banco de dados relacional, para uma modelo de dados mais detalhado, a ontologia,pode-se dizer que ocorreu um detalhamento semântico do modelo de dados.

O processo de mapeamento semântico requer que os elementos mapeados apre-sentem uma coincidência de domínios, total ou parcial. Em outras palavras, o banco dedados mapeado para a ontologia de referência deve representar um domínio, ao menospróximo, do domínio tratado na ontologia. Não faz sentido, por exemplo, tentar mapearum banco de dados que trate de um domínio como ecologia, para uma ontologia que tratede um domínio como mecânica de automóveis.

A solução apresentada nesse capítulo, consiste na proposta para realizar o ditoMapeamento Semântico de Banco de Dados.

5.2 Etapas da Solução

A solução proposta nesse trabalho para o mapeamento semântico de bancosde dados divide-se em duas etapas. Na primeira parte, define-se um mecanismo paraestabelecer um mapeamento entre um banco de dados e uma ontologia. Na segunda parte,relaciona-se o conteúdo dos bancos de dados, agora definidos segundo uma ontologia dereferência, com entidades de outros repositórios semânticos.

5.2.1 Mapeando entre Bancos de Dados e Ontologia

A proposta de mapeamento semântico desse trabalho, consiste em inferir ummapeamento entre os elementos que definem um banco de dados segundo uma ontolo-gia pré-definida. Considerando os diferentes paradigmas de bancos de dados existentes,como observado no Capítulo 2, é possível dividir os elementos do banco de dados emdois tipos. O primeiro tipo, chamado agrupador primário, representa a forma de agrupa-mento de informação mais geral, o que corresponde às classes da ontologia. O segundotipo, chamado agrupador secundário, corresponde à uma estrutura de agrupamento maisdetalhada, tomada como as propriedades de uma classe da ontologia.

A Tabela 5.1 apresenta essa forma de dividir os dados, tomados pelo paradigmade banco de dados que os definem.

Como pode ser observado na Tabela 5.1, a divisão em dois níveis da informaçãoestá presente em todos os paradigmas de bancos de dados. No caso do paradigma Chave-Valor, a chave representa tanto o agrupador primário quanto o secundário, pois a maioriadesses bancos possui uma estrutura de chaves do tipo tipo-de-objeto:id-do-objeto:campo-

do-objeto, por exemplo user:21:username.


Tabela 5.1: Modos de agrupamento de dados por paradigma debanco de dados

Paradigma Agrupador Primário Agrupador SecundárioRelacional Tabelas ColunasOrientado a Objetos Classes de Objeto Propriedades de ObjetoChave-Valor Chaves ChavesOrientado a Colunas Família de Colunas ColunasOrientado a Documentos Coleções AtributoOrientado a Grafos Nós Arestas

No caso dos bancos orientados a objetos, o que representa a classe e a proprie-dade do objeto depende do tipo de implementação do banco. Nos casos de bancos do tipoobjeto-relacional, esses correspondem às próprias tabelas e colunas.

Neste trabalho, o termo elementos do banco de dados, refere-se aos agrupadoresprimários e secundários de cada paradigma de banco de dados, descritos na Tabela 5.1.

Classificação Sintática

A fim de aumentar a probabilidade de acerto na inferência do mapeamentoentre classes e propriedades da ontologia com os elementos provenientes do banco dedados analisado, realiza-se uma classificação sintática dos nomes desses elementos edas classes e propriedades provenientes da ontologia. Nesse processo, é possível utilizarbases de conhecimento específicas para realizar essas classificações, tais como a base deconhecimento da WordNet.

Uma vez realizada a classificação sintática das classes e propriedades da ontolo-gia e dos elementos do banco de dados, é possível definir candidatos dentro dos bancosde dados a serem mapeados a uma correspondente classe ou propriedade na ontologia.

Definindo Candidatos

Tomando como exemplo um banco de dados relacional, uma classe poderia sermapeada para uma tabela desse banco. Da mesma forma, em um banco de dados orientadoa documentos, a própria estrutura conhecida como coleção de documentos poderia serobservada como candidata a uma classe da ontologia. A estrutura conhecida como coluna,no caso do banco de dados relacional, seria o candidato à propriedade dessa ontologia,enquanto no banco de dados orientado a documentos seria o atributo de um documento.

Utilizando um dicionário como a WordNet, os relacionamentos entre synsets

tornam-se as primeiras evidências de uma possível correspondência entre o elemento dobanco de dados e a classe ou propriedade da ontologia. A Tabela 5.2 apresenta algumaspossibilidades com relação à definição de candidatos entre banco de dados e ontologia.


Tabela 5.2: Relação entre synsets da ontologia com synsets dobanco de dados

Relação É um candidato?Sinônimos Possível candidato. Nesse caso, observa-se tam-

bém na ontologia propriedades owl:sameAs,owl:equivalentClass, owl:equivalentProperty

Hiperônimos ou Hipônimos Possível candidato. Elemento do banco pode ser de-finido com um termo mais ou menos geral que o daontologia. Vale também observar propriedades comordfs:subClassOf e rdfs:subPropertyOf

Merônimos ou Holônimos Possível candidato. Elemento pode representar partede uma correspondente classe ou propriedade da on-tologia.

Antônimos Não forma um candidato, mas observa-se proprieda-des como owl:inverseOf

Ontologias são formas de representar conhecimento, assim como esquemasde bancos de dados. No ato de mapear elementos do banco de dados para classes epropriedades da ontologia deve-se considerar a possibilidade de uma agrupador primáriodo banco de dados representar mais de uma classe da ontologia e vice-versa, por issorelações como merônimos e holônimos devem ser consideradas.

Ao final do processo de classificação sintática, uma série de candidatos a classese propriedades da ontologia são definidas dentro do banco de dados, formando conjuntosde candidatos. Busca-se então refinar esses resultados realizando operações de álgebra deconjuntos.

Tomando como exemplo o caso de um banco de dados relacional, as colunas deuma tabela podem ser vistas como as partes ou características da entidade representadapela tabela. Cada coluna pode ser vista como uma entidade que se relaciona com a tabela,por meio de uma relação considerada intuitiva sobre o ponto de vista de um ser humano. Ocomputador não dotado dessa capacidade cognitiva, carece de um mecanismo para tornarexplícitas essas relações.

Filtrando Candidatos

Inicialmente, define-se os candidatos na ontologia para representar os agrupa-dores primários e secundários do banco de dados. A seguir, sabendo-se das relações quepodem existir entre os candidatos a classes, com os correspondentes candidatos a propri-edades, realiza-se um processo de filtragem dos candidatos, considerando-se as relaçõesentre esses candidatos.

O próximo passo é eliminar os elementos que não possuam uma relação corres-pondente a nenhum dos elementos do outro conjunto de candidatos. Dessa forma, elimina-


se tabelas candidatas a uma classe da ontologia que não possua nenhuma coluna candidataa propriedade da ontologia sobre a referida classe. Da mesma forma, elimina-se colunascandidatas a uma propriedade da ontologia, onde a tabela correspondente não seja candi-data a nenhuma classe da ontologia que possua essa propriedade. A Figura 5.2 representaessa relação. Serão eliminadas da lista de candidatos a entidade da tabela o elemento B eda lista de candidatos a entidade da coluna o elemento Z.

Figura 5.2: Tabelas x Colunas

Pode-se considerar uma situação mais concreta, a fim de tornar mais claro oentendimento do processo. A Figura 5.3 apresenta uma situação hipotética. Em um bancode dados existe uma tabela cadposto a qual deseja-se mapear para uma ontologia. Atravésdo processo descrito nas seções anteriores, infere-se as palavras que deram origem aonome da tabela cadposto. Na análise, ignorou-se o prefixo cad considerando-se somentea palavra posto, sendo essa uma palavra válida da língua inglesa.

Figura 5.3: Processo de Associação do Banco de Dados com On-tologia de Referência

Em seguida, associa-se essa palavra, posto, com os nodos da ontologia chama-dos cargo e estabelecimento. A associação ocorre, pois esses nodos possuem nomes que


são sinônimos da palavra posto. Entretanto, a tabela cadposto possui colunas chamadaslati e long, as quais foram mapeadas como possíveis candidatas às propriedades lati-tude_estabelecimento e longitude_estabelecimento da ontologia. Não foi estabelecida ne-nhuma relação de candidato entre uma propriedade da classe cargo com colunas da tabelacadposto, pois as colunas da tabela cadposto não apresentaram similaridades léxicas comas propriedades da classe cargo, logo o candidato cargo é eliminado da lista de possíveiscorrespondências na ontologia com a tabela cadposto.

Esse procedimento é realizado entre a tabela e cada coluna, formando váriosconjuntos de relacionamentos entre a tabela e suas colunas. Seleciona-se a relação entreclasse da ontologia com a tabela do banco de dados, que possuir maior número de relaçõesentre propriedades da ontologia com colunas do banco de dados correspondente. A Figura5.4 representa essa situação, onde os conjuntos T1,T2, ...,Tn representam subconjuntosde candidatos a entidades da tabela provenientes do conjunto original e os conjuntosC1,C2, ...,Cn representam os candidatos a entidades das colunas.

Figura 5.4: Tabela x Colunas

Por fim, realiza-se a operação de intersecção entre os conjuntos de candidatos aentidades da tabela: TR = T1 ∩T2 ∩ ...∩Tn. Dessa forma, tem-se um conjunto resultantesomente com aqueles possíveis candidatos que possuírem pelo menos uma relação comcada conjunto de candidatos a entidade da coluna.

Após executadas as etapas descritas anteriormente, espera-se que a maioria dastabelas do banco de dados possua uma lista de poucos candidatos a entidades da tabela.Nesse ponto, analisa-se o relacionamento existente entre as tabelas do banco. Conformedescrito no apêndice B, os relacionamentos entre indivíduos de classes de ontologiasocorrem por meio de propriedades de objetos. Nos bancos de dados, os relacionamentosentre tabelas ocorrem por chaves estrangeiras, relações de herança entre outros critérios,dependendo do paradigma de banco de dados analisado.


Pode-se realizar uma série de consultas à base de conhecimento, utilizando comosujeito e objeto da relação combinações de pares de entidades provenientes dos conjuntosde candidatos existentes entre ambas as tabelas.

Após todas as etapas descritas anteriormente, se ainda restarem múltiplos candi-datos a entidades de tabelas e colunas, é realizada uma etapa adicional de ranqueamento,onde serão atribuídas pontuações aos candidatos de tabelas e colunas.

5.2.2 Mapeamento para Repositórios Semânticos

Uma vez estabelecido o mapeamento entre os bancos de dados analisados e aontologia, torna-se possível relacionar os elementos do banco de dados com classes eentidades de outros repositórios semânticos. Dessa forma, o dado proveniente do bancode dados pode ser utilizado com dados provenientes de outras fontes com informaçõescomplementares.

A fim de entender como seria esse processo de complementação dos resultadosprovenientes de outras fontes de dados, toma-se o exemplo apresentado na Figura 5.5.Considerando uma tabela “PessoaFamosa”, proveniente de um banco de dados relacional,contendo apenas duas colunas. A primeira coluna chamada “Nome” e a segunda chamada“Nascimento”.

Figura 5.5: Complementação de Colunas

Através do relacionamento entre os elementos dessa tabela com as entidadesde outros repositórios semânticos, tais como a DBPedia, descobre-se que esses nomescorrespondem aos verdadeiros nomes de alguns cantores famosos. Dessa forma é possívelderivar uma nova coluna “Apelido”, obtida a partir das propriedades givenName daontologia da DBpedia.

Tomando um segundo exemplo, apresentado na Figura 5.6. Considerando umatabela “Atores”, contendo três colunas. A primeira coluna chamada “Doutor”, a segunda


chamada “Interpretado Por” e a terceira “Duração”. Através do relacionamento entre oselementos dessa tabela com as entidades de outros repositórios, descobre-se tratar-sede atores que interpretaram o personagem Doctor Who, na série de ficção científica demesmo nome. Entretanto, observa-se que existem apenas dez linhas nessa tabela. Pode-seassim derivar uma nova linha correspondente ao décimo primeiro ator que interpretou opersonagem na série.

Figura 5.6: Complementação de Linhas

Todo esse processo de mapeamento, entre o banco de dados representado sobrea ontologia e os repositórios semânticos, acontece por buscas de similaridade de conteúdoentre os elementos do banco de dados referenciado sobre a ontologia e categorias definidaspreviamente sobre o conteúdo esperado sobre aquele repositório semântico.

Categorizando o Acesso a Repositórios Semânticos

Repositórios Semânticos podem apresentar definições complexas, utilizandoontologias com centenas ou até milhares de classes e propriedades. Esses modelos porsua vez podem ser utilizados para definir milhões de entidades, geralmente relacionadasutilizando triplas RDF que interconectam essas entidades fornecendo um dado descritocom uma riqueza de detalhes que muitas vezes não é encontrada nos bancos de dadosconvencionais.

Uma vez que tentar analisar esses complexos repositórios para realizar a vincula-ção a um banco de dados é um processo complexo que exigiria um esforço muito grande,tenta-se simplificar o processo de associação restringindo-o a definições particulares rea-


lizadas por um usuário com algum conhecimento, mesmo superficial, sobre o repositórioanalisado.

Essas definições simplificadas de elementos presentes nos repositórios são de-finidas nesse trabalho como categorias. Categorias são palavras chaves utilizadas paraacessar uma lista de consultas descritas em SPARQL a repositórios semânticos diversoscujo resultado dessas consultas podem ser relacionadas ao banco de dados analisado.

A fim de compreender melhor essa definição, pode-se considerar um exemplo:tomando a palavra “droga”, um ser humano possui uma série de formas de definir osignificado dessa palavra. Droga é uma palavra polissêmica, possui vários possíveissignificados, sendo o mais utilizado aquele relativo a substâncias entorpecentes, apesarde também ser utilizado para produtos da indústria farmacêutica.

No repositório semântico da DBPedia, uma droga, adotando o significadode produto farmacêutico, pode ser definida como uma entidade que forme umatripla RDF com a propriedade de objeto rdf:type relacionando-se com a classehttp://dbpedia.org/ontology/Drug do repositório DBPedia. Dessa forma, o mapeamentodo conceito para esse repositório poderia ser estabelecido utilizando uma consultaSPARQL como a apresentada no Código 5.1.

Código 5.1 Consulta SPARQL a DBPedia

PREFIX owl : < h t t p : / / www. w3 . org / 2 0 0 2 / 0 7 / owl#>

PREFIX xsd : < h t t p : / / www. w3 . org / 2 0 0 1 / XMLSchema#>

PREFIX r d f s : < h t t p : / / www. w3 . org / 2 0 0 0 / 0 1 / rdf−schema#>

PREFIX rdf : < h t t p : / / www. w3 . org /1999/02 /22− rdf−syn t ax−ns #>

PREFIX : < h t t p : / / d b p e d i a . o rg / r e s o u r c e / >

PREFIX d b p e d i a 2 : < h t t p : / / d b p e d i a . o rg / p r o p e r t y / >

PREFIX d b p e d i a : < h t t p : / / d b p e d i a . o rg / >

SELECT ? e n t i t y

WHERE {

? e n t i t y rdf : t y p e < h t t p : / / d b p e d i a . o rg / o n t o l o g y / Drug > .

}

O conceito de droga, no contexto de produto farmacêutico, pode ser mapeadotambém para outro repositório semântico como o Dailymed. Esse repositório apresentauma lista dos medicamentos comercializados nos Estados Unidos da América. Nesse


repositório, uma droga pode ser definida como uma entidade que forme uma triplaRDF com a propriedade de objeto rdf:type relacionando-se com a classe http://wifo5-04.informatik.uni-mannheim.de/dailymed/resource/dailymed/drugs.

Dessa forma, o mapeamento do conceito para esse repositório poderia ser feitoatravés da consulta SPARQL apresentada no Código 5.2.

Código 5.2 Consulta SPARQL a Dailymed

PREFIX v o c a b C l a s s : < h t t p : / / wifo5 −04. i n f o r m a t i k . uni−mannheim . de

/ da i lymed / vocab / r e s o u r c e / c l a s s / >

PREFIX db : < h t t p : / / wifo5 −04. i n f o r m a t i k . uni−mannheim . de /

da i lymed / r e s o u r c e / >

PREFIX r d f s : < h t t p : / / www. w3 . org / 2 0 0 0 / 0 1 / rdf−schema#>

PREFIX d2r : < h t t p : / / s i t e s . wiwiss . fu−b e r l i n . de / s u h l / b i z e r / d2r−s e r v e r / c o n f i g . rdf #>

PREFIX map : < f i l e : / C : / apps / da i lymed / da i lymed . n3#>

PREFIX owl : < h t t p : / / www. w3 . org / 2 0 0 2 / 0 7 / owl#>

PREFIX xsd : < h t t p : / / www. w3 . org / 2 0 0 1 / XMLSchema#>

PREFIX rdf : < h t t p : / / www. w3 . org /1999/02 /22− rdf−syn t ax−ns #>

PREFIX da i lymed : < h t t p : / / wifo5 −04. i n f o r m a t i k . uni−mannheim . de /

da i lymed / r e s o u r c e / da i lymed / >

SELECT ? e n t i t y

WHERE {

? e n t i t y rdf : t y p e < h t t p : / / wifo5 −04. i n f o r m a t i k . uni−mannheim . de /

da i lymed / r e s o u r c e / da i lymed / drugs > .

}

O mesmo conceito pode ser definido em diferentes repositórios, cada um dessesrepositórios podendo trabalhar aspectos particulares daquele conceito em maior ou menorescala.

Resumidamente, nesse trabalho o termo categorias correspondem a palavraschaves utilizadas para acessar uma lista de consultas SPARQL com as definições daquelapalavra chave em repositórios semânticos específicos.

As categorias utilizadas na solução desse trabalho são armazenadas nas tuplas deum banco de dados SQLite. Além do nome da categoria são definidos também para cadacategoria uma consulta SPARQL e o endereço do SPARQL Endpoint utilizado.


Definidas as categorias utilizadas para associar elementos do banco de dadoscom repositórios semânticos, resta agora realizar a associação entre bancos de dados erepositórios semânticos.

Analisando Agrupadores Primários

O primeiro passo consiste em realizar uma leitura dos agrupadores primários dobanco de dados sendo analisado. Nesse processo, busca-se encontrar sinônimos para aspalavras utilizadas pelo projetista de banco de dados para definir os agrupadores primáriosdo banco de dados. Como exemplo, no caso de um banco de dados relacional, a tabelaé o agrupador primário. Uma tabela com o nome município, poderia ter sido definidasimilarmente utilizando a palavra cidade ao invés de município.

Sabendo que muitas vezes projetistas de banco de dados não utilizam palavrasplanas para definir seus agrupadores primários uma análise de padrões é realizada sobreesses agrupadores. Busca-se padrões como o Camel Case, palavras planas separadas porcaracteres especiais e palavras planas simplesmente concatenadas. Caso não consiga acharum padrão de nomeação dos agrupadores primários, utiliza-se um padrão heurístico paraanálise das palavras.

Lematização

Uma vez que as palavras utilizadas para realizar a nomeação dos agrupadoresprimários foram encontradas, utiliza-se a Wordnet como dicionário para obter os sinôni-mos correspondentes dessas palavras.

As palavras utilizadas para definir os agrupadores primários, assim como seussinônimos e as categorias definidas no banco de dados são lematizadas, removendoflexões de gênero, número e grau, assim como flexões verbais quando for o caso.

Associando Categorias com Agrupadores Primários

Tomando cada um dos agrupadores primários do banco de dados e os sinôni-mos encontrados para esse agrupador, lematizados na etapa anterior, compara-se essesagrupadores e seus sinônimos com as categorias definidas no banco de dados.

Caso seja encontrada alguma coincidência entre o agrupador e seus sinônimoscom uma ou mais categorias definidas no banco de dados, busca-se as consultas SPARQLcorrespondentes àquelas categorias que coincidiram com o agrupador ou com um de seussinônimos.

Realiza-se as consultas SPARQL sobre os repositórios semânticos obtidos atra-vés das categorias. O resultados de uma consulta SPARQL são armazenados em uma lista


em memória, e serão lematizadas assim como foram os nomes e sinônimos dos agrupa-dores primários.

A lista de resultados lematizados é então comparada com cada um dos agrupa-dores secundários daquele agrupador primário. Tomando novamente o exemplo do bancode dados relacional com a tabela município, caso essa tabela possua duas colunas chama-das código e nome. A lista de resultados lematizados obtidos do repositório semântico écomparada com cada uma dessas colunas tendo seus resultados também lematizados.

Caso sejam encontrados intersecções entre um agrupador secundário lematizado,como a coluna nome do exemplo, e a lista de resultados lematizados da consulta SPARQL,então é provável que o agrupador primário se relacione com a classe da ontologiarepresentada por aquela consulta SPARQL e as células daquela coluna de fato sejamrelacionadas com as entidades daquela classe do repositório semântico. No exemplocitado da tabela de banco de dados relacional, município poderia estar se relacionandocom a classe http://dbpedia.org/ontology/City do repositório DBPedia.

Não afirma-se de fato que a tabela município do banco de dados de fato cor-responde à classe do repositório da DBPedia, mas apenas define-se a probabilidade derepresentar essa, devido à coincidência entre o identificador das entidades dessa classe daontologia e o conteúdo da célula da coluna nome. Se houve uma coincidência entre oselementos de apenas 2% dos resultados por exemplo, muito provavelmente essa coinci-dência não é exata. Entretanto, se a coincidência é da ordem de 90%, é bem provável queessa correspondência seja exata.

Os resultados não são descartados por possuírem índices de correspondênciapercentual baixos, mas são ordenados de forma a apresentar para o usuário as associaçõescom maior percentual.

Analisando Agrupadores Secundários

Uma vez encontrada uma associação provável entre um agrupador primáriodo banco de dados com uma classe do repositório semântico, seria possível analisaressa classe para buscar suas propriedades e tentar relacioná-las com outros agrupadoressecundários daquela classe do repositório semântico.

No exemplo da tabela município do banco de dados relacional, caso ela tenhasido também associada com a classe http://schema.org/City da comunidade schema.org,uma análise de suas demais colunas, no exemplo citado restaria a coluna código, poderiaser associada como a propriedade de objeto globalLocationNumber desse repositório.

Da mesma forma, como na análise dos agrupadores primários, classifica-se osresultados de acordo com o índices de correspondência percentual entre os resultadosprovenientes do banco de dados com o repositório semântico sendo analisado.


Encontrar possíveis correspondências entre os agrupadores secundários de bancode dados com as propriedades da classe do repositório semântico analisado reforça aprobabilidade da associação correta do agrupador primário.

5.2.3 Gerando Formatos Abertos de Mapeamento de Dados

Feito o processo de mapeamento descrito nas seções anteriores, torna-se possívelapresentar o resultado na forma de um Dado Aberto Ligado. Recapitulando o exposto naTabela 2.1, um Dado Aberto Ligado pode possuir várias classificações.

Nesse trabalho, optou-se pelo modelo de 5 estrelas proposto por Berners-Lee,descrito na Tabela 2.1. Dessa forma, o mapeamento realizado deve ser publicável na webcomo um dado estruturado, em formato não proprietário, identificado por URI e ligado aoutros dados para fornecer contexto.

Na seção 2.2.3 apresentou-se o RDF, um formato de dados que facilita ointercâmbio de dados na web. Esse formato pode ser utilizado para disponibilizar os dadosdo mapeamento realizado.

Ao disponibilizar o mapeamento entre os bancos de dados e a ontologia de refe-rência, torna-se possível construir aplicações que acessam os bancos de dados utilizandoa ontologia de referência como camada de abstração, como pode ser observado na Figura5.7.

Figura 5.7: Modelo de Acesso de Dados por Ontologia

Observa-se que, independente do banco de dados, do paradigma que o define,a aplicação pode acessá-lo utilizando somente as definições de dados especificadas naontologia.


No próximo capítulo, apresenta-se em detalhes o arquivo de mapeamento geradoa partir da solução descrita nesse trabalho.


Nesse capítulo, foi apresentada uma proposta de solução para o mapeamentoentre ontologias e bancos de dados, com base na classificação gramatical das palavrasque definem os elementos do banco de dados e da ontologia, assim como na utilização deoperações da álgebra de conjuntos.

A solução apresentada difere dos trabalhos realizados até o momento, pois sepropõem a mapear bancos de dados relacionais e NoSQL. Da mesma forma, essa soluçãobusca a integração do resultado como um dado aberto ligado.

No capítulo seguinte, será apresentada a proposta de um sistema que implementaos conceitos descritos nesse capítulo. Num primeiro momento, é apresentado um projetoem função de seus requisitos. Em seguida, apresenta-se os detalhes de implementaçãorelacionados ao desenvolvimento dessa aplicação.

CAPÍTULO 6Projeto do Sistema de Mapeamento de Banco deDados

Nesse capítulo, será descrito o projeto para o desenvolvimento do sistema demapeamento de banco de dados proposto nesse trabalho. Seguindo as conceitos de projetopropostos pela Engenharia de Software, esse projeto foi dividido em quatro partes.

Segundo Pressman [63]: “Projeto de Software é a parte da Engenharia deSoftware que se encarrega de transformar os resultados da Análise de Requisitos em umdocumento ou conjunto de documentos capazes de serem interpretados diretamente peloprogramador.”

Na primeira parte, foi realizada uma etapa de análise, onde foram definidos osrequisitos funcionais e requisitos não funcionais da ferramenta proposta. Em seguida, naetapa de projeto foi realizada a modelagem, por meio de diagramas, e a arquitetura dosistema proposto. Após a elaboração do projeto, procedeu-se ao seu desenvolvimento eposteriormente ao processo de teste da aplicação, sendo essa última etapa descrita nopróximo capítulo.

Os critérios adotados para desenvolver o sistema de mapeamento aqui proposto,foram o baixo acoplamento e a alta coesão do conteúdo gerado, conceitos esses conheci-dos e bastante difundidos dentro da Engenharia de Software.

O baixo acoplamento do código gerado visa facilitar o entendimento e eventualnecessidade de manutenção ou extensão de suas funcionalidades. Além disso, outrosbenefícios decorrentes do baixo acoplamento são facilidade ao realizar o processo deteste de classes, métodos, funções e módulos em contexto individual.

Sobre o critério adotado de coesão do código, busca-se o ganho de flexibilidadedecorrente desse conceito, assim como evitar efeitos conhecidos, decorrentes de suaomissão, tais como dificuldades de extensões, modificações e reutilizações futuras.

6.1 Atores 73

6.1 Atores

Antes de realizar o levantamento de requisitos da ferramenta proposta, é neces-sário definir quais são os atores do sistema. Dá-se nome de ator a um papel desempe-nhado por entidades físicas (pessoas ou outros sistemas) que interagem com o sistemada mesma maneira, procurando atingir os mesmos objetivos. Uma mesma entidade físicapode desempenhar diferentes papéis no mesmo sistema, bem como um dado papel podeser desempenhado por diferentes entidades [56].

O ator não representa a pessoa ou sistema e sim o papel que essa pessoa ousistema representa para a aplicação. A seguir são descritos os atores do sistema.

1. Desenvolvedor: indivíduo que relaciona domínios específicos ao extrator de dados,por meio de uma série de possíveis categorias representativas. Da mesma forma,esse indivíduo relaciona o repositório semântico a uma consulta SPARQL. Domí-nios e repositórios semânticos são explicados nos subitens a seguir.

Repositórios Semânticos: domínios geralmente acessíveis, por meio de lin-guagens de consulta como SPARQL, Web Services ou API de comunicação espe-cífica. A aplicação busca esses repositórios para reforçar a categorização de umaentidade de banco de dados, como fonte de complementação de conteúdo, em casosolicitado pelo usuário.

Página para Extração: página web onde o extrator de dados busca informaçãocomplementar, de acordo com uma categoria definida previamente pelo desenvol-vedor. O acesso do sistema a esse geralmente é realizado por meio de requisiçõesHTTP e processamento de linguagem natural.

2. Usuário: indivíduo que se comunica com a aplicação requisitando informações arespeito do conteúdo dos bancos de dados marcados semanticamente.

6.2 Requisitos da Aplicação

Requisitos de software são um conjunto de atividades que o software devedesempenhar, com suas limitações e restrições, além das características não ligadasdiretamente às funções desempenhadas pelo software [72]. Nesta seção, serão descritosos requisitos funcionais e não funcionais da aplicação proposta.

6.2.1 Requisitos Funcionais

Requisitos Funcionais são declarações de serviços que o sistema deve prover,descrevendo o que o sistema deve fazer, como o sistema deve reagir a entradas específicas,

6.2 Requisitos da Aplicação 74

como o sistema deve se comportar em situações específicas e o que o sistema não devefazer [71].

A partir dos Requisitos Funcionais descreve-se as funcionalidades necessáriaspara que casos de usos sejam colocados em prática. Segundo Jacobson[46], um Caso deUso é um “documento narrativo que descreve a sequência de eventos de um ator que usaum sistema para completar um processo”. A partir deles, é possível identificar as açõesque devem ser executadas para que o sistema atinja seu objetivo

A construção do Modelo de Casos de Uso corresponde a uma das primeirasetapas no projeto de software, pois essa etapa determina os usos que o sistema terá.

A Figura 6.1 apresenta o diagrama de casos de uso adotado por esse projeto.

Figura 6.1: Casos de Uso do Sistema

• Selecionar Ontologia: O sistema deve permitir ao usuário definir qual ontologiaserá utilizada para o processo de anotação semântica.• Adicionar Banco de Dados: O sistema deve permitir ao usuário adicionar um ou

mais bancos de dados a serem anotados semanticamente.• Anotar Banco de Dados: O sistema deve ser capaz de realizar marcação de

anotações em bancos de dados, relacionais ou NoSQL, que associem suas entidadescom as classes e entidades de uma ontologia.• Complementar Anotações: O sistema deve ser capaz de complementar as anota-

ções realizadas, associando as respectivas com entidades de outros repositórios oudomínios específicos para o qual exista um extrator ou consulta SPARQL associada.• Alterar Anotação: O sistema deve permitir ao usuário alterar as associações

realizadas entre a Ontologia e o Banco de Dados feitas por anotações.

6.2 Requisitos da Aplicação 75

• Apresentar Anotações: O sistema deve permitir ao usuário gerar um formato derepresentação aberta para o processo de anotação. Essa representação deve atenderaos paradigmas de Dados Abertos Ligados.• Ocultar Anotações: O sistema deve permitir ao usuário ocultar associações reali-

zadas entre a ontologia e o banco de dados.• Associar Extratores: O sistema deve permitir ao Desenvolvedor indicar um novo

domínio para complementar as buscas, associando esse domínio a um conjunto decategorias.• Associar Repositórios: O sistema permite ao Desenvolvedor indicar um novo repo-

sitório semântico para complementar as buscas, associando uma consulta SPARQLa um conjunto de categorias.

6.2.2 Requisitos Não Funcionais

Requisitos Não-Funcionais dizem respeito às restrições sobre os serviços ou fun-ções do sistema. Por exemplo, restrições de tempo, restrições do processo de desenvolvi-mento, usabilidade, confiabilidade, desempenho, suporte, padrões, etc [64].

A elaboração dos requisitos não funcionais foi baseada na Norma ISO 9126.Essa norma propõe um Modelo de Qualidade de Software baseado em 6 atributos dequalidade: Funcionalidade, Confiabilidade, Usabilidade, Eficiência, Manutenibilidade ePortabilidade.

Adaptações foram necessárias para a aplicação proposta e o domínio de pro-blemas que deseja-se tratar. Para o atributo Funcionalidade, foram definidos os requisitosInteroperabilidade e o requisito Segurança; para o atributo Confiabilidade foram definidosos requisitos Recuperabilidade e Tratamento de Exceções; para o atributo Usabilidade foidefinido o requisito Inteligibilidade; como Eficiência foram definidos os requisitos Parale-lismo e Balanceamento de Carga; para o atributo Manutenibilidade foi definido o requisitoEstabilidade; para o atributo Portabilidade foi definido o requisito Flexibilidade.

Alguns outros requisitos que não possuem um termo correlato na norma foramadotados. Esses requisitos são Simplicidade, Modularidade e Semântica.

• Interoperabilidade: O sistema desenvolvido nessa proposta deve possuir funcio-nalidades que permitam a interação com outros sistema, podendo ser, por exemplo,frameworks e interfaces com o usuário.• Segurança: a arquitetura disponibiliza as informações dos bancos de dados anota-

dos semanticamente, mas permite indicar quais informações devem ser ocultadas• Recuperabilidade: o sistema deve possuir a capacidade de recuperar anotações

referentes aos bancos de dados analisados.

6.3 Modelagem, Arquitetura e Arquivo de Resultado 76

• Tratamento de Exceções: o sistema deve possuir um mecanismo de identificaçãoe tratamento de exceções adequado.• Inteligibilidade: o sistema deve possuir um mecanismo simples de utilização,

permitindo ao usuário interagir com esse de modo a aperfeiçoá-lo.• Paralelismo: o sistema deve possuir um mecanismo de paralelização de tarefas

tanto no que se refere à notação semântica dos bancos de dados quanto à utilizaçãoe a manipulação do arquivo de representação intermediária utilizado para realizarconsultas aos bancos de dados.• Balanceamento de Carga: o sistema deve possuir a capacidade de distribuir as

tarefas de forma ponderada entre os recursos de processamento.• Estabilidade: o sistema deve possuir a capacidade de receber alterações sem

grandes efeitos colaterais. A estrutura básica de funcionamento desse deve ser capazde receber novos módulos que permitam a extensão das funcionalidades.• Flexibilidade: o sistema pode manipular a informação de modo uniforme, se

adaptando conforme o volume dessa, estando preparado para crescer. O sistemadeve ser flexível e permitir a substituição de elementos externos utilizados. Emum contexto mais amplo, o sistema deve possuir um alto nível de coesão e baixoacoplamento.• Simplicidade: a capacidade de agregar novos agentes, sejam eles extratores ou

repositórios semânticos, deve ser o mais simples possível;• Modularidade: as ferramentas serão disponibilizas como módulos, trabalhando

como agentes de software;• Semântica: a arquitetura deve permitir o acesso, armazenamento, processamento

e comunicação dos dados de forma semântica, utilizando ontologias, metadados efeedback dos usuários.

6.3 Modelagem, Arquitetura e Arquivo de Resultado

Nesta seção, detalha-se o design do projeto, a arquitetura do sistema proposto eo arquivo de resultado. Em um primeiro momento apresenta-se a arquitetura do sistemaem seus mínimos detalhes. Esta arquitetura foi baseada nos requisitos levantados e nasfuncionalidades esperadas desse framework. Em um segundo momento, apresenta-se oformato do arquivo de resultado produzido pela aplicação. Finalmente, é apresentada amodelagem proposta para o sistema, através da apresentação de diagramas de sequência.

A partir da definição explícita da arquitetura e modelagem do sistema, será possí-vel definir, de forma clara, os recursos a serem empregados numa eventual implementaçãodessa proposta. No apêndice D, apresenta-se uma descrição da base de dados utilizada poressa aplicação.


6.3.1 Arquitetura

Nesta seção, apresenta-se a arquitetura do sistema proposto para o mapeamentode banco de dados, assim como os componentes dessa arquitetura. Esse modelo é baseadonos requisitos definidos no início desse capítulo. Os componentes dessa arquitetura sãoo Motor de Execução, o Analisador Léxico/Sintático, o Extrator, o Cliente SPARQL e aInterface com Usuário.

A Figura 6.2 apresenta esses componentes e como eles se relacionam.

Figura 6.2: Arquitetura Proposta

Interface

Componente responsável por realizar todas as interações com o Usuário ou como Desenvolvedor, assim como processar o resultado dos demais componentes e apresentaro resultado do processo de anotação.

Através desse módulo, o usuário seleciona a ontologia que deseja utilizar comoreferência no processo de anotação. O Usuário fornece dados para a conexão da aplicaçãocom um ou mais Banco de Dados, tais como nome do banco de dados, usuário e senha.

O Desenvolvedor pode criar uma categoria e associar a ela uma consultaSPARQL a ser executada em um Repositório Semântico específico. Da mesma forma,o Desenvolvedor pode associar a uma categoria uma consulta XQuery a ser executadasobre um domínio especificado por um URL.

Motor de Execução

Componente responsável por unir o resultado dos outros componentes do sis-tema, produzir as anotações semânticas, gerar categorias de complementação e produziruma saída em formato aberto do relacionamento entre ontologia e bases de dados.


Um dos objetivos desse projeto é realizar a marcação semântica de bancos dedados, tomando por base uma ontologia de referência. Em segundo plano, os bancosde dados marcados semanticamente são complementados adicionando relações entre oselementos dessas bases de dados com entidades de domínios ou repositórios semânticosespecíficos por meio de categorias pré-definidas.

Essa etapa de complementação do conteúdo do banco de dados permite um enri-quecimento dos resultados de aplicações que utilizem as notações semânticas produzidasna primeira etapa.

Uma vez que tenham sido realizadas as classificações léxicas e sintáticas daspalavras pelo Analisador Léxico e Sintático, o Motor de Execução produz as primeirasanotações semânticas sobre os bancos de dados. Em seguida, utiliza-se o Extrator e oCliente SPARQL para encontrar possíveis categorias ao qual essa entidade de banco dedados possa estar vinculada.

Por fim, gera-se um arquivo em formato RDF, que contém as relações entre osbancos de dados e as ontologias, assim como os URLs e repositórios semânticos quepodem ser usados para complementar cada um dos elementos do banco de dados.

Analisador Léxico/Sintático

O Analisador Léxico/Sintático é uma ferramenta responsável por realizar aanálise das classes e entidades das ontologias, assim como dos elementos do bancos dedados; sejam tabelas e colunas, chaves e valores, documentos e colunas ou nós e arestas.A Figura 6.3 apresenta um modelo desse Analisador Léxico.

Figura 6.3: Analisador Léxico/Sintático


Esse componente analisa individualmente a ontologia de referência, assim comocada um dos bancos de dados a serem anotados. A análise de uma ontologia ou banco dedados inicia-se pelo processo de leitura dos nomes utilizados pelos elementos do bancosde dados ou ontologias, onde a ferramenta Localizador de Padrões busca detectar padrõesutilizados no processo de nomeação desses elementos.

Alguns padrões utilizados recorrentemente por projetistas de bancos de dadose ontologias são a utilização do Camel Case para nomeação de palavras, por exemploPrimeiroElemento. Da mesma forma, é muito comum a utilização de caracteres especiaispara realizar a separação de palavras, tais como em primeiro_elemento.

Caso o Localizador de Padrões não consiga achar um padrão de nomeação,utilizado pela ontologia ou banco de dados analisado, esse responde ao controladorindicando a necessidade de utilização de um padrão heurístico para análise das palavras.

Após a definição do padrão utilizado para as palavras, o controlador invocao Analisador Linguístico para realizar um processo de definição da linguagem naturalutilizada no processo de nomeação dos elementos da ontologia ou do banco de dados.O Analisador Linguístico verifica a existência em dicionários linguísticos das palavrasutilizadas para nomear os elementos, nas linguagens naturais inglês, francês, espanhol,italiano e português. O processo de análise é abortado caso não seja detectada umalinguagem para o banco ou ontologia.

Sabendo-se quais são as palavras utilizadas para nomear os elementos do bancoou ontologia, assim como as línguas em que foram escritas, o controlador chama oTradutor. Esse componente converte os nomes dos elementos para uma linguagem natural,nesse caso adotou-se o inglês.

Uma vez traduzidas para o inglês, as palavras são analisadas e classificadassintaticamente, utilizando a ontologia da WordNet. São obtidos dessa os sinônimos,antônimos, merônimos, holônimos, hipônimos e hiperônimos de cada palavra utilizadapara representar o elemento do banco de dados ou ontologia analisada.

O resultado desse procedimento é então retornado para o Motor de Execução.

Extrator

O Extrator é uma aplicação responsável por buscar informações complementaresem páginas web específicas, que estejam vinculadas a uma categoria. Pode-se observar ofuncionamento desse componente pela Figura 6.4.


Figura 6.4: Módulo Extrator

O Extrator recebe como entrada um elemento do banco de dados, sejam colunas,valores ou nós de um grafo. A seguir o extrator realiza um processo de requisições adomínios específicos, que tenham sido alimentados anteriormente pelo Desenvolvedor,tentando vincular esse elemento a esses domínios.

Uma vez que tenha sido encontrada uma possível categorização do elementodo banco de dados, novas requisições são feitas sobre aquele domínio, utilizando outrasinstâncias do mesmo elemento da base de dados. Não é necessário que todas as instânciasencontrem um correspondente elemento naquele domínio, mas apenas que uma parcelasignificativa da amostra possua essa correspondência. Nesse trabalho, adotou-se comocritério que pelo menos oitenta por cento das amostras possuam essa correspondência.

A fim de compreender melhor o que acontece, pode-se considerar um exemplo:o extrator recebe uma coluna de um banco de dados relacional com a descrição name_act,dessa coluna são extraídas uma amostra de dez células. Nesse momento, os pares de URLe Seletores JQuery, definidos pelo Desenvolvedor, são utilizados para buscar relaciona-mentos entre a coluna com domínios pré-definidos. Nesse processo, um dos domíniosdefinidos pelo desenvolvedor poderia ser o do URL http://sg.media-imdb.com/suggests/,usando o seletor JQuery #prometer_container h1.header[itemprop=name]. Dentre as dezcélulas analisadas, nove foram encontradas nesse domínio, ao qual o Desenvolvedor as-sociou as categorias ator, atriz, filme. É razoável atribuir a essa coluna as respectivascategorias associando com esse URL.

Cliente SPARQL

O Cliente SPARQL é uma aplicação responsável por buscar informações com-plementares em repositórios semânticos específicos, que estejam vinculadas a uma cate-goria. Pode-se observar o funcionamento desse componente pela Figura 6.5.


Figura 6.5: Módulo Cliente SPARQL

O Cliente SPARQL recebe como entrada um elemento do banco de dados, sejamcolunas, valores ou nós de um grafo. A seguir, o Cliente SPARQL realiza um processode requisição a repositórios semânticos, alimentados anteriormente pelo Desenvolvedor,tentando vincular esse elemento a entidades desses repositórios.

Uma vez que tenha sido encontrada uma possível categorização do elemento dobanco de dados, novas requisições são feitas sobre aquele SPARQL Endpoint, utilizandooutras instâncias do mesmo elemento da base de dados. Não é necessário que todasas instâncias encontrem um correspondente elemento naquele domínio, mas apenasque uma parcela significativa da amostra possua essa correspondência. Nesse trabalho,adotou-se como critério que pelo menos oitenta por cento das amostras possuam essacorrespondência.

A fim de compreender melhor o que acontece, pode-se considerar um exemplo:o Cliente SPARQL recebe um atributo de um banco de dados orientado a documentoscom a descrição FamousMountain, desse atributo é extraída uma amostra de dez células.Nesse momento, as consultas SPARQL definidas previamente pelo Desenvolvedor sãoutilizadas para buscar nomes de montanhas nesses repositórios. Nesse processo, um dosdomínios definidos pelo desenvolvedor poderia ser o do GeoNames, usando consultaSPARQL definida no Código 6.1.

Código 6.1 Exemplo de Consulta SPARQL

PREFIX gn:<http://www.geonames.org/ontology#>

SELECT ?x MIN(?code) MIN(?name) MIN(?iso) WHERE {

?x gn:featureCode ?code ;

gn:name ?name ;

gn:countryCode ?iso .

FILTER (?code IN (gn:T.MT, gn:T.MTS))

}

GROUP BY ?x

ORDER BY MIN(?name)


Dentre as dez células analisadas, oito foram encontradas nesse repositório, aoqual o Desenvolvedor associou as categorias local, montanha. É razoável atribuir a essacoluna às respectivas categorias, associando-a com esse repositório.

6.3.2 Arquivo de Resultado

Após fazer o mapeamento de um banco de dados para uma ontologia de refe-rência, cria-se um arquivo de resultados. O arquivo de resultados possui os mapeamentosrealizados entre a ontologia e o banco de dados. Da mesma forma, esse arquivo possui osmapeamentos feitos entre o banco de dados e os repositórios semânticos.

O formato escolhido para registrar os resultados da aplicação, a fim de atenderos requisitos de um Dado Aberto Ligado, é o RDF. A Figura 6.6 apresenta um exemplodo arquivo de resultado produzido pela aplicação.

Figura 6.6: Exemplo de Resultado da Aplicação

Na primeira linha do arquivo, observa-se que o base do arquivo é a ontologia dereferência. Além disso, os arquivos possuem referências às especificações dos formatosOWL, RDF, RDFS e FOAF, descritas da segunda até a quinta linha.

Os prefixos endpoint1 e endpoint2, descritos na sexta e na sétima linha, corres-pondem a Repositórios Semânticos onde foram encontradas associações com uma tabela,através do Cliente SPARQL.

O agrupador primário do banco de dados, é definido no arquivo de resultadosutilizando o prefixo table seguido do nome do agrupador. No exemplo da figura, na nonalinha, é descrita como <#table-nome_no_banco_de_dados>. Esse agrupador primáriodo banco de dados, é definido como o correspondente a uma classe da ontologia dereferência, descrito na decima linha do arquivo.

Na décima primeira e décima segunda linhas do arquivo de resultados, apresenta-se referências para SPARQL Endpoints descobertos pelo Cliente SPARQL. Finalmente, na


décima terceira e décima quarta linha do arquivo de resultados, apresenta-se referências adomínios descobertos pelo Extrator.

Essa descrição continua para cada agrupador primário do banco de dados anali-sado.

6.3.3 Modelagem

A modelagem dessa proposta foi definida através do uso de diagramas desequência. Um diagrama de sequência representa, de forma clara, por meio de um fluxode execução, representado por linhas verticais, e comunicação inter-processos por linhashorizontais, a colaboração dinâmica existente entre os processos que compõem o sistema.Através desse tipo de diagrama, é possível observar o que acontecerá em um pontoespecífico do programa, assim como os passos necessários para a conclusão de umadeterminada ação.

Foram identificados três fluxos de atividades básicas para o sistema proposto,logo foram definidos três diagramas de sequência. No primeiro diagrama, que pode serobservado na Figura 6.7, apresenta-se o processo de mapeamento de um banco de dadospara uma ontologia de referência. No segundo diagrama, apresentado na Figura 6.8, oDesenvolvedor define uma nova categoria associada a um domínio. Finalmente, na Figura6.9, o Desenvolvedor define uma categoria associada a um SPARQL Endpoint.

O primeiro diagrama, Figura 6.7, começa com a definição do Usuário da ontolo-gia utilizada como referência e do banco de dados a ser anotado. O Motor de Execuçãoredireciona os endereços de bancos de dados e ontologia para o Analisador Léxico/Sin-tático, onde esse identifica padrões utilizados para nomear os elementos, a linguagemnatural utilizada e a classificação sintática das palavras. O Motor de Execução então asso-cia os elementos de bancos de dados com elementos da ontologia. Em seguida, o Motorde Execução consulta o Extrator para buscar categorização dos elementos da tabela e,após isso, consulta o Cliente SPARQL para buscar categorização desses mesmos elemen-tos com SPARQL Endpoint. Por fim, o Motor de Execução devolve para o usuário umarquivo, em formato RDF, com o mapeamento e com a categorização realizada.


Figura 6.7: Mapeando Bancos de Dados e Ontologia

O segundo diagrama de sequências, Figura 6.8, inicia-se com uma requisiçãodo Desenvolvedor pela inclusão de uma nova categoria vinculada a um domínio. Osistema pede ao Desenvolvedor que informe o URL da página a ser procurado, assimcomo o seletor em JQuery para encontrar o campo a ser relacionado. O sistema executauma requisição contra essa página web utilizando o URL e o seletor especificado.Se for encontrado um elemento válido no caminho do seletor, o sistema apresenta aoDesenvolvedor possíveis resultados e pergunta se esse deseja adicionar a nova categoria.O Desenvolvedor confirma a nova categoria e o sistema persiste o URL e o seletorvinculados a essa categoria.

Figura 6.8: Vinculando Categoria a um Domínio

6.4 Desenvolvimento da Aplicação 85

O terceiro diagrama de sequências, Figura 6.9, inicia-se com uma requisição doDesenvolvedor pela inclusão de uma nova categoria vinculada a um SPARQL Endpoint.O sistema pede ao Desenvolvedor que informe o URL a ser procurado, assim como aconsulta em SPARQL a ser executada. O sistema executa uma requisição contra esseSPARQL Endpoint utilizando o URL e a consulta especificada. Se a consulta produzir umresultado válido, o sistema apresenta ao Desenvolvedor possíveis resultados e perguntase esse deseja adicionar a nova categoria. O Desenvolvedor confirma a nova categoria e osistema persiste o URL e a consulta vinculados a essa categoria.

Figura 6.9: Vinculando Categoria a um Domínio

6.4 Desenvolvimento da Aplicação

Neste seção, são descritos os principais passos executados na implementação doAnotador Semântico de Banco de Dados. A implementação a ser apresentada, é baseadana análise e projeto realizados nas seções anteriores deste capítulo. Da mesma forma,foram utilizados grande parte dos conceitos descritos nos Capítulos 2 e 3.

Inicialmente, são descritas as principais tecnologias utilizadas para construira aplicação, assim como as configurações utilizadas nos sistemas do qual a aplicaçãofoi testada. Em seguida, apresenta-se as fontes de informação utilizadas para realizar oprocesso de mapeamento e integração do resultado. Por fim, apresenta-se um exemplo defuncionamento da aplicação num contexto simplificado.

O funcionamento da aplicação em contexto real é apresentado no Capítulo 7,onde uma análise estatística detalhada sobre o funcionamento da aplicação sobre bases dedados de sistemas reais é desenvolvida.


6.4.1 Tecnologias Empregadas

Para o desenvolvimento do Anotador Semântico de Banco de Dados, foi utilizadoo ambiente de desenvolvimento Eclipse Kepler, além das ferramentas JDK 1.8.0_05;Apache Jena 2.11.0; JAWS 1.3; gtranslateapi 1.0 e drivers de conexão jdbc específicospara os bancos de dados PostgreSQL, Firebird, Oracle, SQLite, Cassandra e MongoDB.

No Apêndice C, são apresentadas explicações mais detalhadas sobre algumasdas ferramentas citadas.

A aplicação desenvolvida foi testada nos Sistemas Operacionais Windows 7Professional SP1, no Apple OS X Yosemite IOS 8.1 e no Ubuntu 14.04.1 Desktop.

6.4.2 Bases de Dados Linguísticas

Na Subseção 6.3.1, o Analisador Léxico/Sintático apresenta uma estrutura de vá-rios subcomponentes necessários para o seu funcionamento. Dentre esses subcomponen-tes dois deles, Analisador Linguístico e Localizador de Padrões, necessitam de uma basede informações com palavras consideradas válidas nos idiomas suportados pelo AnotadorSemântico de Banco de Dados.

Apesar de existirem Web Services de dicionários disponíveis na web, permitindoconsultas a palavras específicas de um idioma, o custo em termos de desempenho dedesenvolver esses subcomponentes utilizando esses Web Services é elevado.

A fim de viabilizar o desenvolvimento desses subcomponentes com o grau dedesempenho desejado, optou-se por embutir os dicionários na aplicação na forma de umbanco de dados linguístico, utilizando SQLite.

Foram utilizados os pacotes linguísticos disponibilizados como add-ons doNavegador Firefox1. Esses pacotes linguísticos são utilizados para sistema de correçãoortográfica, tanto de navegadores de internet quanto de editores de texto.

Cada pacote linguístico possui dois arquivos, um arquivo com a lista de palavrasdo idioma tendo uma extensão .dic e um arquivo com as regras de flexão de sufixos eprefixos, tendo a extensão .aff.

Cada linha do arquivo de extensão .dic possui uma única palavra, podendo serseguido ou não de uma sequência de letras e números. Tomando um exemplo de algumaslinhas do dicionário de francês, como pode ser observado na Figura 6.10.

1https://addons.mozilla.org/en-US/firefox/language-tools/, último acesso em Dezembro de 2014


Figura 6.10: Exemplo de dicionário do pacote de francês

As letras indicam flexões que podem ser utilizadas, havendo diferenciação en-tre letras maiúsculas e minúsculas. As regras de flexões correspondentes encontram-seno arquivo de extensão .aff, sendo essas regras dividas em SFX para sufixos e PFX paraprefixos. Tomando como exemplo um prefixo, sendo a mesma regra aplicável para sufi-xos, esse possui a seguinte regra: PFX <letra-identificadora> <número-de-letras-para-

deletar> <o-que-adicionar> <quando-adicionar-(expressão-regular)>. A Figura 6.11apresenta algumas regras do pacote de inglês.

Figura 6.11: Exemplo de regras do pacote de inglês

Se “B” é uma das letras indicadas no arquivo de dicionário, então existem trêsflexões que podem ocorrer, pois existem três linhas no arquivo. No exemplo da Figura6.11, tomando a primeira linha, able é adicionado ao final da palavra quando essa nãotermina com uma vogal (question pode ser flexionada para questionable). Explicaçõesmais detalhadas sobre a sintaxe de arquivos de dicionários podem ser encontradas napágina de desenvolvedores do projeto Chromium 2.

Visando a construção da base de dados linguística, construiu-se uma aplicaçãopara ler os arquivos .dic e .aff de cada pacote. Essa aplicação lê cada linha do arquivo.dic e gera as derivações possíveis de cada palavra de acordo com as regras definidasno arquivo .aff. As palavras formadas são inseridas numa tabela de uma única colunachamada verbetes. O Código 6.2 corresponde ao código SQL necessário para a criaçãodessa tabela de banco de dados.

2http://www.chromium.org/developers/how-tos/editing-the-spell-checking-dictionaries, último acessoem Novembro de 2014


Código 6.2 Tabela Verbetes

CREATE TABLE ‘verbetes ‘ (

‘nome ‘ TEXT NOT NULL,

PRIMARY KEY(nome)

);

Essa tabela possui todas as palavras presentes no idioma analisado, tanto suasformas primitivas quanto suas derivações. Conforme foi relatado na subseção 6.3.1,o Anotador Semântico de Banco de Dados foi projetado para compreender o Inglês,Português, Francês, Italiano e Espanhol. Dessa forma, foi criado um banco de dados paracada um dos idiomas citados.

6.4.3 Categorias Utilizadas

Ao longo desse trabalho, reiteradamente afirmou-se o objetivo de não somenterealizar o mapeamento de banco de dados para um domínio semântico, mas tambémintegrar o dados mapeando a nuvem semântica de dados abertos.

O número de repositórios semânticos, cuja informação encontra-se disponívelde forma aberta e integrada com outros repositórios semânticos aumenta a cada dia. NaFigura 6.12 é possível ver em alta perspectiva como os repositórios semânticos estãointerligados.

Figura 6.12: Nuvem de Dados Abertos Ligados, Abril de 2014[32]


É possível garantir essa integração com outros repositórios, bastando que aontologia tomada como referência no processo de mapeamento dos bancos de dados,já esteja ligada à nuvem de dados abertos. Entretanto, uma vez que esse trabalho sepropôs a desenvolver um mecanismo automático de disponibilização das informaçõesprovenientes dos bancos de dados na forma de dados abertos ligados, torna-se necessárioo desenvolvimento de uma ferramenta como o Cliente SPARQL descrito na Subseção6.3.1.

Tanto com relação ao Cliente SPARQL, quanto com relação ao Extrator trabalha-se com categorias vinculadas a um determinado recurso. No caso do Extrator, essacategoria corresponde a um recurso da Web 2.0, ou seja, da Web Social onde os recursosnão são adequados para a leitura de máquinas. No caso do Cliente SPARQL, a categoriaé vinculada a um recurso da Web 3.0, ou seja, da Web Semântica onde os recursos sãoexplicitamente descritos e os dados são interligados.

De modo geral, as categorias selecionadas definem as ligações que a aplicaçãotenta realizar entre o dado proveniente do banco de dados e elementos externos da Web2.0 e da Web 3.0. Dessa forma, as categorias selecionadas são muito importantes paradefinir a qualidade do Dado Aberto Ligado.

A despeito do procedimento para incluir uma categoria no banco de dados,conforme relatado na Seção 6.3.3, nesse momento são descritas as categorias utilizadasnas simulações realizadas nesse trabalho. É importante citar que essa não é uma listaexaustiva, centenas de outras categorias podem ser registradas, abrangendo, se preciso,todos os recursos de todos os repositórios semânticos ou de milhões de domínios da web.

Tomando-se primeiramente o módulo Extrator, foram registradas algumas cate-gorias vinculados principalmente a buscadores de variados tipos, desde músicas até pes-quisadores e trabalhos acadêmicos. A Tabela 6.1 apresenta as categorias utilizadas:

Tabela 6.1: Categorias Extrator

Categoria Domíniofilme imdb.comfilme themoviedb.org

música vagalume.com.brmúsica musicbrainz.org

jogo thegamesdb.netjogo gamesdbase.comjogo ultimategamedb.com

pesquisador lattes.cnpq.br

Em seguida, foram analisadas as categorias vinculadas ao Cliente SPARQL.Uma vez que foram registradas mais de uma centena de categorias com relação aoCliente SPARQL, optou-se apenas por indicar algumas categorias vinculadas a DBPedia,


ao Dailymed e ao Diseasome, mostradas na Tabela 6.2. Observa-se que as categoriasescolhidas são tanto de propósito geral quanto específico. As classes Ator, Cantor,Escritor na ontologia da DBPedia são todas subclasses da classe Artista, dessa formauma vinculação bem sucedida a uma dessas três categorias também pode ser a categoriaArtista. O objetivo é realizar a vinculação mais específica possível, logo a categoria Artistaassume um caráter residual no processo de vinculação.

Outros repositórios, além dos relatados na Tabela 6.2, foram utilizados, totali-zando vinte três repositórios, tais como o Yago2[42], GeoSPARQL[4], GeoSpecies[33],LinkedMovieDatabase[39], Freebase[15], . . .

6.4.4 Exemplo de Utilização

A fim de tornar mais claro o processo de funcionamento do Anotador Semânticode Banco de Dados, apresenta-se um exemplo simples de funcionamento do sistema.

Supondo que um usuário tivesse uma ontologia simples, de apenas duas classes,pessoa e cidade, tendo algumas poucas propriedades. A ontologia em questão pode serobservada na Figura 6.13, sendo apresentada no formato Turtle[7] e descrita em portuguêsbrasileiro.

Figura 6.13: Ontologia de Exemplo


Tabela 6.2: Categorias Cliente SPARQL

Categoria Repositórioagrotóxico http://dbpedia.org/sparqlanatomia http://dbpedia.org/sparqlanimal http://dbpedia.org/sparqlartista http://dbpedia.org/sparqlatleta http://dbpedia.org/sparqlator http://dbpedia.org/sparqlave http://dbpedia.org/sparql

bactéria http://dbpedia.org/sparqlbebida http://dbpedia.org/sparqlcantor http://dbpedia.org/sparqlcidade http://dbpedia.org/sparqlcomida http://dbpedia.org/sparql

cor http://dbpedia.org/sparqldoença http://dbpedia.org/sparqldoença http://wifo5-03.informatik.uni-mannheim.de/diseasome/sparqldroga http://dbpedia.org/sparqldroga http://wifo5-04.informatik.uni-mannheim.de/dailymed/sparql

empresas http://dbpedia.org/sparqlempresas farmaceuticas http://wifo5-04.informatik.uni-mannheim.de/dailymed/sparql

escritor http://dbpedia.org/sparqlevento http://dbpedia.org/sparqlflores http://dbpedia.org/sparqlfungo http://dbpedia.org/sparqlgene http://wifo5-03.informatik.uni-mannheim.de/diseasome/sparql

instituições de ensino http://dbpedia.org/sparqllivro http://dbpedia.org/sparql

moeda http://dbpedia.org/sparqlmusgo http://dbpedia.org/sparqlmúsica http://dbpedia.org/sparql

país http://dbpedia.org/sparqlpeixe http://dbpedia.org/sparql

periódico acadêmico http://dbpedia.org/sparqlpersonagem fictício http://dbpedia.org/sparql

pessoa http://dbpedia.org/sparqlpesticida http://dbpedia.org/sparqlprovíncia http://dbpedia.org/sparql

quadrinhos http://dbpedia.org/sparqlsubstância química http://dbpedia.org/sparql


Esse usuário deseja realizar o mapeamento semântico de um banco de dados deuma loja varejista para essa ontologia simples. Supondo que esse banco de dados seja umbanco de dados PostgreSQL, onde as tabelas do banco de dados e suas colunas foramdescritas em inglês conforme o manual de usuário do sistema. O usuário então define aontologia de referência utilizada, as informações de conexão com o banco de dados e oidioma do banco de dados. Como o usuário não tem conhecimento do padrão utilizadopara fazer a nomeação das colunas e das tabelas, o campo “Padrão” fica com o valor“Desconhecido”. Os campos preenchidos pelo usuário podem ser observados na Figura6.14.

Figura 6.14: Adicionando um Banco de Exemplo

O usuário então, sabendo que a ontologia possui apenas uma classe cidade e umaclasse pessoa, escolhe essas opções na aba “Categorias”. Após essa definição, o usuárioseleciona a aba “Principal” e clica no botão Aplicar.

A primeira tarefa do Anotador Semântico de Banco de Dados é realizar a classifi-cação sintática tanto da ontologia quanto do banco de dados. Sabendo que a ontologia foidefinida em português o Motor de Execução chama o Analisador Léxico/Sintático paraanalisar a ontologia, conforme o descrito na Subseção 6.3.1.

Sabendo da linguagem utilizada, o Analisador Léxico/Sintático dispensa o usodo Analisador Linguístico, chamando em seguida o Localizador de Padrões. O Locali-zador de Padrões testa o caso mais simples em que classes, entidades e propriedades daontologia utilizem texto plano do português. Sendo o teste bem sucedido, o AnalisadorLéxico/Sintático chama o Tradutor para converter o texto em inglês ( mantêm-se o textooriginal apenas guardando esse valor em um texto a parte para ter uma linguagem de re-ferência internacional ). Finalmente, o Analisador Léxico/Sintático consulta a WordNetpara fazer a classificação das palavras.

O Analisador Léxico/Sintático começa a analisar o banco de dados, sabendoda linguagem utilizada, o Analisador Léxico/Sintático dispensa o uso do Analisador


Linguístico, chamando em seguida o Localizador de Padrões. O Localizador de Padrõestesta o uso de texto plano, em seguida testa o uso de camel case, finalmente encontrao padrão utilizado pelo banco de dados ao considerar o padrão de palavras em textoplano separadas por caractere especial underline. Uma vez que os nomes de tabelas ecampos já estão em inglês o Analisador Léxico/Sintático dispensa o Tradutor, realizandodiretamente a consulta à WordNet e classificando as palavras.

O Motor de Execução começa a realizar cruzamento das informações sobre obanco de dados e a ontologia, obtidas a partir do Analisador Léxico/Sintático. Apósrealizar várias comparações, o Motor de Execução indica que a tabela clientes do banco dedados possui uma relação de hiperônimo com a classe pessoa da ontologia. Além disso, atabela município do banco de dados possui uma relação de sinônimo com a classe cidade.

Uma vez estabelecidos os candidatos, começa o processo de comparação dascolunas e do banco de dados. O Motor de Execução detecta uma coluna description

na tabela de banco de dados, e interpreta isso como sendo um possível sinônimo paraa propriedade nome da classe pessoa, da mesma forma encontra uma correspondênciade uma coluna idade_cliente dessa mesma tabela com a propriedade idade da classe daontologia.

Ao comparar as colunas da tabela município com as propriedades da classecidade da ontologia, o Motor de Execução observa que a tabela possui uma colunahas_ibge_code, da qual ele descarta o verbo has e observa que essa coluna da tabelacontém um substantivo igual à propriedade ibge da classe município.

Estabelecidos os candidatos a relacionamento entre colunas da tabela e proprie-dades da ontologia, o Motor de Execução agora analisa os Inviduals da ontologia. Comoo banco de dados é relacional, o Motor de Execução cria uma consulta buscando em cadauma das colunas valores que coincidam com os Inviduals ou com as propriedades da on-tologia. Caso o o banco de dados fosse NoSQL, o Motor de Execução buscaria cada umindividualmente.

O Código 6.3 apresenta o trecho do programa em java responsável por criar essecódigo SQL.


Código 6.3 Individual x Colunas

List <String > columns = table.Columns.stream()

.filter(x->x.ColumnType.equals("string"))

.map( x -> x.Cells.get(0).Content )

.collect(Collectors.toList());

String ontIndividuals = StringUtils.join(

ontClass.individualFacts.stream()

.map(x -> "’"+x.object.toLowerCase()

.replace("_", " ").replace(" ", "")+"’" )

.toArray(), ", ");

try {

if(ontClass.individualFacts.size() > 0) {

String sql = StringUtils.join( columns.stream()

.map(x -> String.format(

"select ’%1$s’, count(%1$s) from %2$s where %3

$s",

x,

table.Name ,

String.format(dbInf[0], x,

ontIndividuals)) )

.toArray(), " \n union \n ");

List <String[]> results = Arrays.asList(

db.GetStringArrayEntities(sql, new Object[] {}) ).

stream()

.filter(x-> Integer.parseInt(x[1]) != 0)

.collect(Collectors.toList());

Uma vez que não existem Individuals na ontologia para classe pessoa, o códigoSQL é construído somente em função da propriedade description, o qual não encontranenhum resultado. Entretanto, existe na ontologia Inviduals para a classe cidade. Dessaforma, o Motor de Execução constrói uma consulta em função desses e da propriedadeibge. A consulta construída pode ser observada no trecho de Código 6.4


Código 6.4 SQL Individual x Colunas

select ’description’, count(description) from municipio

where replace(replace(lower(description), ’_’, ’ ’), ’ ’, ’’)

in

(’goiânia’, ’caldasnovas’, ’trindade’,

’aparecidadegoiânia’, ’senadorcanedo’)

union

select ’has_ibge_code’, count(has_ibge_code) from municipio

where replace(replace(lower(ibge), ’_’, ’ ’), ’ ’, ’’) in

(’goiânia’, ’caldasnovas’, ’trindade’,

’aparecidadegoiânia’, ’senadorcanedo’)

union

...

// outras colunas da tabela cruzadas com Inviduals

Após realizar essa consulta, o Motor de Execução verifica que todos os Inviduals

foram encontrados na tabela município, na coluna description.Finalmente, o Motor de Execução considera o relacionamento entre as tabelas,

comparando-as com as Object Properties da ontologia. As duas tabelas do banco de dadoscliente e município estão ligadas por uma chave estrangeira, o qual o Motor de Execuçãoanalisa como uma possível correspondência com a Object Property “mora” da ontologia.

Considerando-se todos os candidatos e os cálculos realizados até o momento, oMotor de Execução anota a tabela município com uma anotação para a classe cidade daontologia. Como a relação entre a tabela cliente e a classe pessoa ocorreu por meio deuma relação de hiperônimo, o Motor de Execução adiciona uma anotação à tabela clientecomo subclasse de pessoa.

A partir desse momento, o Anotador Semântico de Banco de Dados buscarealizar a categorização das tabelas anotadas de acordo com as categorias selecionadaspelo usuário. Primeiramente, o Anotador Semântico verifica se existem registros na tabelado Extrator para as categorias selecionadas pelo usuário. Em seguida, realiza consultas àSPARQL Endpoint utilizando o Cliente SPARQL.

Ao realizar essas consultas, detecta-se uma correspondência entre a tabela mu-nicípio, anotada como correspondente da classe cidade, com a classe Town da DBPedia ecom a classe wikicategory_Locations_in_Brazil_(city) do Yago2. O Anotador Semânticode Banco de Dados adiciona anotações de correspondência entre essa tabela anotada e ascorrespondentes classes dos repositórios.



Nesse capítulo, foi apresentado o projeto de uma aplicação desenvolvida emjava, que implementa os conceitos discutidos no Capítulo 5. A aplicação foi apresentadana forma de seus requisitos funcionais, requisitos não funcionais, atores e casos de uso,descritos nas seções 6.1 e 6.2.

A seguir, uma descrição da aplicação em termos arquiteturais foi desenvolvida naseção 6.3, onde explicou-se em detalhes o funcionamento de cada componente do sistemae seu fluxo foi detalhado através de diagramas de sequência.

Finalmente, foi apresentado, na seção 6.4, os detalhes finos da aplicação, taiscomo ferramentas utilizadas, modelagem do banco de dados, dicionários linguísticos ecategorias utilizadas.

Percebe-se que esse capítulo representa a síntese de todos os capítulos anteriores.O conhecimento adquirido com pesquisas realizadas e descritas nos Capítulos 2, 3, 4somados à proposta de mapeamento, desenvolvida no Capítulo 5, definiram os parâmetrosgerais dessa aplicação. De forma geral, o objetivo dessa aplicação é apenas servir comouma ferramenta para provar o conceito de eficiência do método estabelecido nessaproposta.

No capítulo seguinte, são apresentados resultados práticos dessa aplicação, via-bilizando analisar as vantagens e desvantagens desse método com relação a outros desen-volvidos até esse momento.

CAPÍTULO 7Análise de Resultados

Neste capítulo, é feita uma avaliação prática da ferramenta desenvolvida anali-sando seus resultados de forma estatística. Inicialmente, na Seção 7.1, são apresentados osresultados dos testes sobre o agrupador primário dos bancos de dados analisados. A Seção7.2 apresenta a análise dos resultados obtidos sobre o agrupador secundário, lembrandoque os agrupadores primários e secundários foram enumerados na Tabela 5.1 da Seção5.2.1. A Seção 7.3 apresenta estatisticamente as associações semânticas realizadas comoutros repositórios. Por fim, discute-se na Seção 7.4 o desempenho global da aplicação,considerando os resultados parciais obtidos anteriormente.

Por questão de simplificação, os bancos de dados utilizados nos testes são bancosde dados de demonstração públicos, abrangendo os sistemas SQL Server, PostgreSQL,MySQL e Apache Cassandra. Dessa forma, o teste realizado contempla tanto os tradicio-nais bancos de dados relacionais quanto um banco de dados NoSQL de exemplo.

Os bancos de dados utilizados para realizar os testes são: World1, IMDB2

e Twissandra3. Todos esses são bancos de dados simples, com poucos agrupadoresprimários e esquemas desenvolvido principalmente para finalidades didáticas, de acordocom o respectivo banco de dados para o qual foram desenvolvidos.

As ontologias utilizadas em cada um dos testes estão relacionadas na Tabela7.1, sendo todas elas públicas. Algumas dessas ontologias são de repositórios semânticosconhecidos, o que não inviabiliza o processo de associação semântica, no pior caso esseprocedimento apenas não encontra novos relacionamentos.

7.1 Resultados da Aplicação - Agrupadores Primários

Os bancos de dados escolhidos para realizar a análise de agrupadores primáriossão bancos relacionais e orientados a colunas. Logo os agrupadores primários utilizados

1https://dev.mysql.com/doc/world-setup/en/, acessado em Janeiro de 20152http://blog.secaserver.com/2013/08/importing-imdb-sample-data-set-mysql/, acessado em Janeiro de

20153https://github.com/twissandra/twissandra, acessado em Janeiro de 2015

7.1 Resultados da Aplicação - Agrupadores Primários 98

Tabela 7.1: Banco de Dados x Ontologias

Banco deDados

Ontologia

World http://www.dbis.informatik.uni-goettingen.de/Mondial/IMDB http://www.movieontology.org/downloads/Twissandra http://rdfs.org/sioc/ns#

são tabelas para os bancos relacionais e famílias de colunas para os orientados a colunas.

7.1.1 Experimento 1

Na Tabela 7.2, é possível visualizar as entradas e saídas do primeiro experimento,realizado entre o banco de dados World e a ontologia do Mondial.

Tabela 7.2: Entrada e Saída Agrupador Primário - Experimento 1

Parâmetro ValorBanco de Dados PostgreSQLIdioma(Banco) InglêsPadrão(Banco) Camel CaseIdioma(Ontologia) InglêsPadrão(Ontologia) Camel Case

(a) Entradas

Métrica TotalTotal de Classes Associáveis 3Associações Corretas 3Associações Incorretas 0Não Associados 0

(b) Saídas

No experimento realizado entre a ontologia e o banco de dados, a quantidadede classes na ontologia é superior ao total de tabelas do banco de dados, sendo que aontologia abrange um domínio maior e mais representativo que o utilizado no banco dedados. Dessa forma, não existem restrições com relação ao mapeamento entre a ontologiae o banco de dados, ou seja, todas as tabelas do banco de dados podem ser mapeadas parauma ou mais classes da ontologia.

As relações Country, City e CountryLanguage foram mapeadas respectivamentepara as classes Country, City e Language da ontologia. O fato das tabelas do banco dedados possuírem nomes iguais ou próximos ao das classes da ontologia contribuiu para aassociação correta dos elementos da ontologia.

Contribuiu também o fato de que todos esses pares de ligações banco de dadosvs. ontologia tiveram intersecções em seus dados. Sobre as entidades Country, tanto daontologia quanto do banco de dados, a correspondência dos elementos foi integral, ouseja, todos os elementos presentes no banco de dados possuíam uma entidade da classeCountry da ontologia com valor igual ou próximo (a ontologia Mondial não considerasinais de acentuação latinos). Procedimento similar ocorreu com a entidade City, tantoda ontologia quanto do banco de dados, ocorreu correspondência entre vários, mas nãotodas, as instâncias da ontologia e do banco de dados.


Sobre o relacionamento CountryLanguage do banco de dados com Language

da ontologia, a princípio a tabela CountryLanguage apresentou dois possíveis candidatosna ontologia, sendo eles Country e CountryLanguage. Como existia a chave estrangeirada tabela CountryLanguage para a tabela Country concluiu-se que essa estava apenasrepresentando uma ligação por meio de uma propriedade de objeto entre duas entidadesda ontologia.

7.1.2 Experimento 2

Na Tabela 7.3, é possível visualizar as entradas e saídas do segundo experimento,realizado entre o banco de dados IMDB e a ontologia MovieOntology.


Parâmetro ValorBanco de Dados MySQLIdioma(Banco) InglêsPadrão(Banco) Palavras Planas

Separadas porUnderline

Idioma(Ontologia) InglêsPadrão(Ontologia) Nenhum

(a) Entradas


(b) Saídas

No experimento realizado, utilizou-se o banco de dados IMDB, o qual agregainformações de filmes, séries de televisão, informações sobre celebridades. A ontologiautilizada, por outro lado, é utilizada para representar apenas informações sobre filmes.Desse modo, o banco de dados utilizado representa um domínio maior que o apresentadopela ontologia, o que implica em certas limitações na análise.

O banco de dados utilizado possui cerca de 9 relações que poderiam ser ma-peadas para a ontologia. Desse total, 8 foram associadas corretamente e uma não foiassociada.

As tabelas name, aka_name e person_info foram compreendidas pelo sistemacomo sendo tabelas ligadas a uma série de classes da ontologia: Costume_Design, Editor,Film_Director, Musical_Artist, Produce, Writer e Artist. Enquanto no banco de dadosexiste apenas uma entidade representando pessoas que trabalham no filme, na ontologiaesses são detalhados por classes específicas.

As tabelas title e aka_title foram mapeadas para a classe Movie da ontologia.Esse mapeamento aconteceu mais pelo conteúdo das tabelas do que pelos termos utiliza-dos para definir tabelas e colunas.

As tabelas company_name e movie_companies foram mapeadas para a classeProduct_Company da ontologia.


Por fim, a tabela que não foi associada no processo de mapeamento semânticofoi a tabela cast_info. Essa tabela poderia ter sido mapeada para a classe pessoa, a qualapresenta informações que representam genericamente as pessoas que trabalham em umfilme.

7.1.3 Experimento 3

Na Tabela 7.4, é possível visualizar as entradas e saídas do terceiro experimento,realizado entre o banco de dados Twissandra e a ontologia SIOC.


Parâmetro ValorBanco de Dados CassandraIdioma(Banco) InglêsPadrão(Banco) Palavras Planas

ou ConcatenadasIdioma(Ontologia) InglêsPadrão(Ontologia) Palavras Planas

(a) Entradas


(b) Saídas

Nesse experimento, foram utilizados um banco de dados orientado a colunasque procura simular um modelo de dados para a rede social Twitter4 e uma ontologiautilizada principalmente para representações de comunidades virtuais. O domínio tratadopela ontologia e o banco de dados são muito próximos, não havendo famílias de colunasno banco de dados utilizadas como metainformação. Dessa forma, não existem restriçõescom relação ao mapeamento entre a ontologia e o banco de dados, ou seja, todas asfamílias de colunas do banco de dados podem ser mapeadas para uma ou mais classesda ontologia.

O seguinte mapeamento foi realizado pela ferramenta de anotação: a família decolunas user foi mapeada para a classe User Account, as famílias followers e following

foram mapeadas para a classe Agent, a família de colunas Tweet foi mapeada para a classePost, a família de colunas userline foi mapeada para as classes Forum e User Account e afamília de colunas timeline foi mapeada para a classe Forum.

No mapeamento realizado pela aplicação considera-se como incorreto o mapea-mento realizado entre as famílias followers e following com a classe Agent, pois a associ-ação mais provável numa rede social seria associá-la com a classe User Account. Apesarde existir um relacionamento de subclasse entre User Account e Agent, a aplicação nãoconseguiu definir uma relação de candidato entre as famílias de colunas do banco de da-dos e a classe User Account. O dicionário linguístico utilizado para realizar a análise

4https://twitter.com/?lang=pt

7.2 Resultados da Aplicação - Agrupadores Secundários 101

léxica e sintática, a WordNet, não observou que modernamente os termos followers e fol-

lowing podem referir-se a tipos de usuários em redes sociais. Como uma melhoria futurada aplicação pode-se pensar em incluir a utilização de múltiplos dicionários na considera-ção dos sinônimos ou simplesmente esperar uma atualização da WordNet sobre os termosutilizados em redes sociais.

7.2 Resultados da Aplicação - Agrupadores Secundários

Os bancos de dados utilizados nos experimentos são relacionais e orientadosa colunas, nesse caso o agrupador secundário de ambos os tipos de banco de dadosutilizados denomina-se “colunas”.

Sabendo-se que existe uma relação de dependência do agrupador primário como agrupador secundário, foi realizada a inclusão de eventuais associações não realizadasnos experimentos relativos ao agrupador primário, afim de isolar os resultados. A inclusãodesses valores apenas adiciona mais dados à análise, não prejudicando os resultadosdaqueles elementos que foram associados corretamente.

7.2.1 Experimento 1

Na Tabela 7.5, é possível visualizar as entradas e saídas do primeiro experimento,realizado entre o banco de dados World e a ontologia Mondial, sobre o agrupadorsecundário.

Tabela 7.5: Entrada/Saída Agrupador Secundário - Experimento 1

Parâmetro ValorBanco de Dados PostgreSQLIdioma(Banco) InglêsPadrão(Banco) Palavras Planas

ou ConcatenadasIdioma(Ontologia) InglêsPadrão(Ontologia) Camel Case

(a) Entradas

Métrica TotalTotal de Propriedades Asso-ciáveis

14

Associações Corretas 10Associações Incorretas 0Não Associados 4

(b) Saídas

Tendo-se relacionado todas as tabelas do banco de dados com uma classecorrespondente na ontologia, na primeira etapa, é possível associar 14 das 24 colunasexistentes no banco de dados. As 10 colunas não associáveis correspondem a colunas doqual não existe uma propriedade correspondente na ontologia.

Observa-se que apenas 4 colunas não foram associadas no processo, sendo ascolunas countrycode e district da tabela City, a coluna indepyear da tabela Country e acoluna countrycode da tabela CountryLanguage.


No caso da tabela City, não ocorreu a associação, pois as informa-ções das colunas countrycode e district foram embutidas através de um pa-drão de URL no nome da entidade da ontologia. Exemplificando-se o caso,a entidade correspondente à cidade de Salvador possuía a seguinte descrição{url padrão}/country/BR/province/Bahia/city/Salvador/. O Anotador Se-mântico aqui desenvolvido não foi construído para analisar possíveis composições dedados nos nomes das entidades, dessa forma essa informação presente no banco de dadosnão foi mapeada para o nome da entidade da ontologia.

Não ocorreu o mapeamento da coluna indepyear da tabela Country, pois ostipos de dados utilizados diferiram. Apesar de existirem proximidades léxicas entre acoluna indepyear (tipo inteiro) e a propriedade indendenceDate (tipo data) da ontologia,o fato desses dados serem de tipos diferentes, inviabilizou a sua associação. Associar tiposdiferentes onde um tipo seja capaz de abranger outro tipo pode ser uma melhoria futuradesse projeto.

Na coluna countrycode da tabela CountryLanguage, a associação falhou, pormotivos semelhantes ao ocorrido na tabela City, o código do país foi embutido no nomeda entidade ao invés de possuir uma propriedade para guardar a referência da informação.

7.2.2 Experimento 2

Na Tabela 7.6, é possível visualizar as entradas e saídas do segundo experimento,realizado entre o banco de dados IMDB e a ontologia MovieOntology.


Parâmetro ValorBanco de Dados MySQLIdioma(Banco) InglêsPadrão(Banco) Palavras Planas

Separadas porUnderline

Idioma(Ontologia) InglêsPadrão(Ontologia) Palavras Planas

(a) Entradas


7


(b) Saídas

O banco de dados do IMDB é um banco normalizado, onde a maioria das colunasutilizadas nas tabelas do banco de dados representam ligações com outras tabelas. A maiorparte das colunas passíveis de associação com propriedades da ontologia tem descriçõescontendo palavras como name, info e note.

Todas as colunas passíveis de associação com a ontologia que possuíam o termoname se ligaram com a Datatype Property name da ontologia. Aquelas colunas comos termos info e note foram associadas com a Datatype Property description. As duas


propriedades são propriedades do tipo string presentes em todas as classes da ontologiaque foram associadas na primeira parte do experimento.

7.2.3 Experimento 3

Na Tabela 7.7, é possível visualizar as entradas e saídas do terceiro experimento,realizado entre o banco de dados Twissandra e a ontologia SIOC, sobre o agrupadorsecundário.


Parâmetro ValorBanco de Dados CassandraIdioma(Banco) InglêsPadrão(Banco) NenhumIdioma(Ontologia) InglêsPadrão(Ontologia) Palavras Planas

(a) Entradas


12


(b) Saídas

No experimento realizado sobre o agrupador primário do banco de dados,observou-se a associação incorreta das famílias de colunas followers e following coma classe Agent da ontologia. A associação foi manualmente realizada com a classe User

Account, a fim de isolar a análise de agrupadores secundários da correspondente análisede agrupador primário.

No banco de dados analisado, 12 colunas poderiam ser associadas com elementoscorrespondentes da ontologia, sendo que 10 foram corretamente associados e 2 elementosdeixaram de ser associados.

As colunas não associadas do banco de dados com uma propriedade correspon-dente da ontologia foram as colunas de nome body das famílias de colunas userline etimeline. Essas colunas deviam ter sido associadas com a Datatype property content daclasse de domínio item da ontologia.

Nenhuma das famílias de colunas utilizadas, userline e timeline, realizou essaassociação, pois elas não tiveram uma ligação correspondente com a classe item ouuma de suas subclasses. No caso de bancos de dados NoSQL, onde não existem chavesestrangeiras que tornam explícita a semântica de relacionamento entre as entidades, aanálise dessas dependências é significativamente mais complicada.

Uma outra possibilidade seria considerar nomes de agrupadores secundáriosiguais para indicar possível relacionamento. No caso do experimento, as famílias decolunas userline e timeline possuíam uma coluna tweetid, o que poderia representar umapossível ligação com a tabela tweet, que também possui uma coluna de chave primáriacom esse nome. Dessa forma, seria possível incluir as classes mapeadas de tweet, assimcomo suas superclasses, na análise das famílias de colunas userline e timeline.

7.3 Resultados da Aplicação - Associação Semântica 104

7.3 Resultados da Aplicação - Associação Semântica

O processo de associação semântica, realizado após o mapeamento entre o bancode dados e a ontologia, tem por objetivo realizar a ligação entre as bases de dadosrecém anotadas e um ou mais repositórios semânticos ou domínios web associadas a umacategoria definida pelo desenvolvedor.

As categorias existentes no sistema são tantas quantas forem definidas pelodesenvolvedor antes do usuário iniciar o processo de associação entre os bancos de dadose a ontologia de referência. Nos experimentos realizados, existia mais de uma centenade categorias disponíveis, entretanto não faz sentido tentar associar todas as categorias aum único experimento se não existe uma relação de pertinência daquela categoria com orespectivo domínio tratado.

Ao realizar o mapeamento de uma série de bancos de dados para uma ontologiaque trate de automóveis, é razoável associar categorias como veículos, combustíveis epaís. No entanto, não faz muito sentido esperar bons resultados ao escolher categoriascomo fungos, doenças ou livros.

O usuário pode selecionar todas as categorias numa análise, em casos queo domínio tratado não é perfeitamente conhecido por exemplo, mas por questões desimplicidade definiu-se apenas algumas categorias ao realizar cada experimento. Essascategorias foram selecionadas por apresentarem alguma pertinência temática com odomínio tratado pela ontologia de referência.

A Tabela 7.8 apresenta as categorias selecionadas em cada experimento. Aprimeira coluna indica o experimento realizado, a segunda coluna as categorias utilizadasem cada experimento e a terceira coluna as categorias encontradas em cada um dosexperimentos realizados.

Tabela 7.8: Categorias X Experimentos

Experimento Selecionadas EncontradasExperimento 1 Idioma, Cidade,

Estado, País,Moeda

Idioma, Cidade,Estado, País

Experimento 2 Ator, Filme,Diretor, Escritor,Evento, Pessoa

Ator, Filme,Diretor, Escritor,Evento, Pessoa

Experimento 3 Pessoa -

Observa-se que, no Experimento 1 foram selecionadas 5 categorias para odomínio do problema tratado. Dessas categorias tratadas, apenas uma não apresentouresultado, sendo esta a categoria Moeda. Apesar do banco de dados selecionado tratarinformações sobre países e seus idiomas, ele não possui a informação da moeda emcirculação desses países. Entretanto, como foi realizada a ligação entre a entidade país


do banco de dados com o repositório semântico da DBPedia, essa informação pode serobtida subsequentemente através dessa ligação, o que seria a consequência direta dacomplementação semântica explicada no Capítulo 5.

No Experimento 2, foram selecionadas 6 categorias, sendo que todas elas foramrelacionadas com pelo menos um repositório semântico. Apesar da relação Pessoa ter sidoencontrada, essa foi encontrada sempre como possuindo uma subclasse mais específicapara representação da entidade tratada na coluna.

Por fim, no Experimento 3, foi associada uma única categoria Pessoa, sendo queessa categoria não foi vinculada a nenhum repositório semântico das categorias registra-das. Esse resultado se deve ao fato de que as colunas analisadas não apresentaram pessoasconhecidas pelos repositórios tratados. Se as pessoas registradas no banco de dados doTwissandra fossem pessoas famosas, como políticos, atores ou cantores possivelmenteteriam sido encontrados em algum repositório.

De forma geral, o processo de associação realizado possui forte dependência doconteúdo com relação ao dado armazenado no banco de dados. Nota-se que os melhoresresultados foram os do Experimento 2, cujo banco de dados é o mais populado de todos.


Neste Capítulo, foram apresentados resultados de alguns experimentos realiza-dos utilizando a aplicação desenvolvida nesse trabalho, o Anotador Semântico de Bancode Dados. Optou-se pela utilização de ontologias e bancos de dados simples, de acessopúblico por questões de simplicidade de análise e para facilitar o entendimento.

Ao longo dos experimentos realizados, novas ideias surgiram para melhorar osresultados da aplicação. Dessa forma, a execução da aplicação em contextos reais, mesmoque simplistas, fornecem conteúdo para eventuais trabalhos futuros sobre a ferramentadesenvolvida nesse trabalho.

Analisando os resultados obtidos de forma percentual, observa-se que a aplicaçãopossui bom desempenho no processo de associação, tanto com relação a uma ontologiade referência quanto no processo de ligação com repositórios externos.

No próximo capítulo, apresenta-se uma análise dos resultados da aplicaçãocom relação a seus objetivos iniciais, um levantamento de suas principais vantagens edesvantagens, assim como discute-se as possíveis melhorias desse projeto.

CAPÍTULO 8Conclusão e Trabalhos Futuros

Ao longo desse trabalho, apresentou-se uma ferramenta para o processo demapeamento semântico de banco de dados. Essa pesquisa foi estruturada abordando ostópicos básicos relativos às áreas de Bancos de Dados, Web Semântica e Dados Abertos,conforme explicitado no Capítulo 2.

Tendo em vista o objetivo de integrar o resultado produzido do mapeamento dobanco de dados para uma ontologia de referência com a nuvem de dados abertos, noCapítulo 3 foi realizado um estudo sobre alguns repositórios semânticos utilizados nessetrabalho. Esses repositórios foram apresentados de forma individual, mas demonstrou-se a integração desses através de predicados indicativos de igualdade entre classesestabelecendo mapeamentos parciais e até mesmo integrais entre esses repositórios.

Em seguida, no Capítulo 4 foi apresentado um estudo sobre o método de opera-ção de algumas soluções semelhantes à proposta apresentada nesse trabalho. Observou-seas peculiaridades de cada solução, tanto suas vantagens quanto suas desvantagens, vi-sando definir ideias inovadoras no processo de mapeamento de banco de dados.

Finalmente, nos Capítulos 5, 6 e 7, a solução proposta nesse trabalho foi apresen-tada, projetada, detalhada e desenvolvida, criando uma ferramenta de anotação semânticade bancos de dados com interessantes resultados e que satisfaz os objetivos definidos noinício dessa pesquisa.

Observa-se que o trabalho desenvolvido até aqui não foi a criação de umprograma, mas sim o melhoramento das técnicas de mapeamento de bancos de dadosquaisquer para domínios semânticos representados por ontologias de referência sobre umdomínio específico desejado pelo usuário.

Apesar de obter um resultado satisfatório no processo de mapeamento de bancode dados, limitações foram observadas ao longo da pesquisa, nessa ferramenta.

A seguir, serão abordadas algumas contribuições realizadas por esta pesquisa.Em seguida, serão apresentadas algumas limitações observadas na ferramenta desenvol-vida durante este trabalho. Por fim, são levantados possíveis melhoramentos e desafiosainda em aberto que poderão ser realizados em trabalhos futuros.

8.1 Contribuições 107

8.1 Contribuições

Uma das contribuições deste trabalho foi a proposta, definição, desenvolvimentoe implementação de uma arquitetura extensível, flexível, genérica, escalável no processode mapeamento de bancos de dados para ontologias, utilizando tecnologias abertas desoftware livre.

Essa proposta de mapeamento de banco de dados foi desenvolvida de formaque fosse possível tratar tanto os tradicionais bancos de dados relacionais, largamenteexplorados nos trabalhos anteriores, quanto os bancos de dados NoSQL. A inclusãodessas bases não relacionais representa uma das evoluções desenvolvidas nesse trabalhocom relação às técnicas existentes. Apesar desses bancos de dados ganharem espaço emvários contextos nos anos recentes, esses ainda não foram tratados com profundidade naspesquisas realizadas até o momento.

Além disso, esse trabalho procurou inovar no processo de mapeamento de bancosde dados, no que diz respeito ao resultado do mapeamento contemplar não somente oconteúdo da ontologia de referência, mas o de outros repositórios na nuvem semânticade banco de dados. O objetivo dessa funcionalidade é enriquecer semanticamente osdados sendo mapeados, permitindo que esse dado compartilhe das eventuais melhoriasque possam ocorrer nesses repositórios para o qual tenha sido mapeado.

A seguir são apresentadas algumas sugestões de trabalhos futuros que podemcontribuir com a evolução do processo de mapeamento semântico de bancos de dados.

8.2 Trabalhos Futuros

A ferramenta apresentada nesse trabalho possui limitações com relação aosmétodos de mapeamento de bancos de dados relacionais e NoSQL, tanto para a ontologiade referência quanto para repositórios semânticos externos.

Nessa seção, são apresentadas algumas sugestões de melhorias da solução pro-posta, visando melhorar os resultados, torná-los mais abrangentes ou mesmo utilizar osresultados desenvolvidos até o momento para outros propósitos. A seguir apresenta-seuma lista de possíveis trabalhos futuros a serem estudados e implementados na ferramentadesenvolvida.

• Dicionários de Sinônimos: A aplicação apresenta certa dependência de sinônimosentre palavras, limitando os seus resultados àquilo especificado na WordNet. Épossível melhorar os resultados ao considerar outros dicionários de sinônimos, osquais podem ser integrados à solução com relativa facilidade dada a sua arquiteturaextensível.

8.2 Trabalhos Futuros 108

• Análise Semântica: A aplicação busca realizar uma análise léxica e sintática tantodos componentes do banco de dados, quanto da ontologia. É possível melhorar essesresultados ao analisar a semântica dos comentários presentes nessas estruturas,quando esses estiverem presentes.• Inferir Relacionamentos: A solução desenvolvida apresentou certas limitações na

análise de bancos de dados NoSQL, por esses não apresentarem o relacionamentoentre suas entidades de forma explícita, como ocorre nos bancos relacionais. Épossível estabelecer mecanismos de análise dos elementos de bancos de dados paracontemplar esses relacionamentos não explícitos.• Suporte a Outros Bancos NoSQL: A aplicação desenvolvida nessa pesquisa

utilizou apenas os bancos Cassandra e MongoDB como bancos de dados NoSQL.Esses bancos são os mais conhecidos bancos dos paradigmas de bancos orientadosa colunas e bancos orientados a documentos. Entretanto, outros paradigmas comobancos do tipo chave-valor e bancos orientados a documentos podem ser exploradosem pesquisas futuras.• Mecanismos de Full Text Search: O processo de associação com repositórios se-

mânticos externos é realizado utilizando igualdade nas consultas SPARQL realiza-dos sobre esses repositórios. Existem alguns repositórios semânticos que começama oferecer o mecanismo de full text search, presente em bancos de dados relacio-nais como o PostgreSQL, no contexto de seus dados. A utilização desse método debuscas, possivelmente é capaz de sofisticar os resultados no processo de associaçãocom repositórios externos.• Novos Predicados de Relacionamento: No processo de associação com os re-

positórios semânticos externos busca-se principalmente a igualdade com entidadesdesses repositórios. Em outras palavras, procura-se estabelecer relacionamentos uti-lizando predicados comuns como owl:sameAs. Entretanto, existem outros tipos derelacionamentos além da igualdade, apresentado por esse predicado, que podemser explorados, tais como skos:broadMatch, skos:narrowMatch, skos:closeMatch eoutros.

Referências Bibliográficas

[1] AGUNE, R. M.; FILHO, A. S. G.; BOLLIGER, S. P. Governo aberto sp: disponibili-

zação de bases de dados e informações em formato aberto. In: III CONGRESSO

CONSAD DE GESTÃO PÚBLICA, 2010.

[2] ANGLES, R.; GUTIERREZ, C. Survey of graph database models. ACM Comput.

Surv., 40(1):1:1–1:39, Feb. 2008.

[3] APACHE JENA. A semantic web framework for java. http://jena.apache.org/

index.html, acessado em janeiro de 2015, 2015.

[4] BATTLE, R.; KOLAS, D. Enabling the geospatial semantic web with parliament

and geosparql. Semantic Web, 3(4):355–370, 2012.

[5] BECHHOFER, S.; MILES, A. SKOS simple knowledge organization system refe-

rence. W3C recommendation, W3C, Aug. 2009. http://www.w3.org/TR/2009/REC-

skos-reference-20090818/.

[6] BECHHOFER, S.; VAN HARMELEN, F.; HENDLER, J.; HORROCKS, I.; MCGUINNESS,

D. L.; PATEL-SCHNEIDER, P. F.; STEIN, L. A. OWL Web Ontology Language

Reference. Technical report, W3C, http://www.w3.org/TR/owl-ref/, February 2004.

[7] BECKETT, D.; BERNERS-LEE, T. Turtle - terse RDF triple language, W3C team

submission, 2008. See: http://www.w3.org/TeamSubmission/turtle/.

[8] BERNERS-LEE, T. Universal Resource Identifiers in WWW: A Unifying Syntax for

the Expression of Names and Addresses of Objects on the Network as used in

the World-Wide Web. RFC 1630 (Informational), June 1994.

[9] BERNERS-LEE, T. Information management: A proposal. Technical report, CERN,

Genf, March 1989.

[10] BERNERS-LEE, T. The World Wide Web - Past Present and Future. In: Japan Prize

Commemorative Lecture, 2002.


[11] BERNERS-LEE, T. Semantic Web concepts. Presented at Edinburgh University,

September 2005.

[12] BERNERS-LEE, T.; HENDLER, J.; LASSILA, O. The semantic web. Scientific

American, 284(5):34–43, May 2001.

[13] BERRUETA, D.; PHIPPS, J. Best practice recipes for publishing rdf vocabularies.

World Wide Web Consortium, Note NOTE-swbp-vocab-pub-20080828, August 2008.

[14] BIZER, C. The emerging web of linked data. Intelligent Systems, IEEE, 24(5):87–

92, 2009.

[15] BOLLACKER, K.; EVANS, C.; PARITOSH, P.; STURGE, T.; TAYLOR, J. Freebase: a

collaboratively created graph database for structuring human knowledge. In:

Proceedings of the 2008 ACM SIGMOD international conference on Management of

data, SIGMOD ’08, p. 1247–1250, New York, NY, USA, 2008. ACM.

[16] BONIFACIO, A. S. Ontologias e consulta semântica: uma aplicação ao caso

lattes. Master’s thesis, UFRGS, Porto Alegre, Outubro 2002.

[17] BORST, W. N. Construction of Engineering Ontologies for Knowledge Sharing

and Reuse. PhD thesis, Enschede, September 1997.

[18] BRAY, T.; PAOLI, J.; SPERBERG-MCQUEEN, C. M.; MALER, E.; YERGEAU, F. Ex-

tensible markup language (xml) 1.0 (fifth edition). World Wide Web Consortium,

Recommendation REC-xml-20081126, November 2008.

[19] BREWER, E. A. Towards robust distributed systems. In: Symposium on Principles

of Distributed Computing (PODC), 2000.

[20] BRICKLEY, D.; GUHA, R. V. Rdf vocabulary description language 1.0: Rdf

schema. Technical report, 2 2004.

[21] BRICKLEY, D.; MILLER, L. FOAF Vocabulary Specification 0.97. Namespace

document, January 2010.

[22] BUMANS, G.; CERANS, K. Rdb2owl: a practical approach for transforming rdb

data into rdf/owl. In: Paschke, A.; Henze, N.; Pellegrini, T., editors, I-SEMANTICS,

ACM International Conference Proceeding Series. ACM, 2010.

[23] CALVANESE, D.; GIACOMO, G. D.; LEMBO, D.; LENZERINI, M.; POGGI, A.;

RODRIGUEZ-MURO, M.; ROSATI, R.; RUZZI, M.; SAVO, D. F. The mastro system

for ontology-based data access. Semantic Web, 2(1):43–53, 2011.


[24] CARROLL, J. J.; KLYNE, G. Resource description framework (RDF):

Concepts and abstract syntax. W3C recommendation, W3C, Feb. 2004.

http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/.

[25] CATTELL, R. Scalable sql and nosql data stores. SIGMOD Rec., 39(4):12–27, May

2011.

[26] CERANS, K.; BUMANS, G. Rdb2owl: a rdb-to-rdf/owl mapping specification

language. In: Barzdins, J.; Kirikova, M., editors, DB & IS, volume 224 de Frontiers

in Artificial Intelligence and Applications, p. 139–152. IOS Press, 2010.

[27] CHAGANTI, P.; HELMS, R. Amazon SimpleDB Developer Guide. Packt Publishing,

Limited, 2010.

[28] CHANG, F.; DEAN, J.; GHEMAWAT, S.; HSIEH, W.; WALLACH, D.; BURROWS, M.;

CHANDRA, T.; FIKES, A.; GRUBER, R. Bigtable: A distributed storage system for

structured data. Proceedings of the 7th USENIX Symposium on Operating Systems

Design and Implementation (OSDI’06), 2006.

[29] CHODOROW, K.; DIROLF, M. MongoDB - The Definitive Guide: Powerful and

Scalable Data Storage. O’Reilly, 2010.

[30] CODD, E. F. A relational model of data for large shared data banks. Commun.

ACM, 13(6):377–387, June 1970.

[31] CROCKFORD, D. RFC 4627 - The application/json Media Type for JavaScript

Object Notation (JSON). Technical report.

[32] CYGANIAK, R.; JENTZSCH, A. The linking open data cloud diagram. http:

//lod-cloud.net/, acessado em março de 2015, 2014.

[33] DEVRIES, P. J. GeoSpecies Ontology. http://bioportal.bioontology.org/

ontologies/GEOSPECIES, acessado em Fevereiro de 2015, 2011.

[34] EAVES, D. About David. http://www.eaves.ca/about, acessado em maio de

2013, 2009.

[35] ERLING, O. Virtuoso, a hybrid rdbms/graph column store. IEEE Data Eng. Bull.,

35(1):3–8, 2012.

[36] FLORIAN, B.; MARTIN, K. Linked Open Data: The Essentials - A Quick Start Guide

for Decision Makers. edition mono/monochrom, Vienna, Austria, 2012.

[37] GEONAMES. GeoNames geographical database, 2010. Last access on Jul 2014

at: http://www.geonames.org.


[38] GRUBER, T. R. A translation approach to portable ontology specifications.

Knowledge Acquisition, 5(2):199–220, June 1993.

[39] HASSANZADEH, O.; CONSENS, M. P. Linked movie data base. In: Proceedings of

the WWW2009 workshop on Linked Data on the Web (LDOW2009), 2009.

[40] HAUSENBLAS, M. 5 stars model on open government data. http://lab.

linkeddata.deri.ie/2010/star-scheme-by-example, acessado em Junho de

2014, Abril 2012.

[41] HAYES, P.; MCBRIDE, B. Rdf semantics. Technical report, Fevereiro 2004.

[42] HOFFART, J.; SUCHANEK, F. M.; BERBERICH, K.; WEIKUM, G. YAGO2: A spatially

and temporally enhanced knowledge base from wikipedia. Artificial Intelligence,

194:28–61, 2013.

[43] HOLZSCHUHER, F.; PEINL, R. Performance of graph query languages compari-

son of cypher, gremlin and native access in neo4j. 2013.

[44] HU, W.; QU, Y. Discovering simple mappings between relational database

schemas and ontologies. p. 225–238. 2008.

[45] ISO. ISO 32000-1:200. Document management – Portable document format –

Part 1: PDF 1.7. Technical report, July 2008.

[46] JACOBSON, I.; M.CHRISTERSON.; JONSSON, P.; OVERGAARD, G. Object-Oriented

Software Engineering — A Use Case Driven Approach. Addison-Wesley, 1992.

[47] JAIN, A.; KHAN, P. I.; VERMA, D. B. Article: Secure and intelligent decision

making in semantic web mining. International Journal of Computer Applications,

15(7):14–18, February 2011. Published by Foundation of Computer Science.

[48] KIM, W. Introduction to object-oriented databases. MIT Press, Cambridge, MA,

USA, 1990.

[49] KIRYAKOV, A.; DAMOVA, M. Storing the semantic web: Repositories. In: Domin-

gue, J.; Fensel, D.; Hendler, J., editors, Handbook of Semantic Web Technologies, p.

231–297. Springer Berlin Heidelberg, 2011.

[50] LAKSHMAN, A.; MALIK, P. Cassandra: a decentralized structured storage system.

SIGOPS Oper. Syst. Rev., 44(2):35–40, Apr. 2010.

[51] LEHMANN, J.; ISELE, R.; JAKOB, M.; JENTZSCH, A.; KONTOKOSTAS, D.; MENDES,

P. N.; HELLMANN, S.; MORSEY, M.; VAN KLEEF, P.; AUER, S.; BIZER, C. DBpedia -


a large-scale, multilingual knowledge base extracted from wikipedia. Semantic

Web Journal, 2014.

[52] MCGUINNESS, D. L.; VAN HARMELEN, F. OWL web ontology language over-

view. W3C recommendation, W3C, Feb. 2004. http://www.w3.org/TR/2004/REC-

owl-features-20040210/.

[53] MILLER, G. A. Wordnet: A lexical database for english. COMMUNICATIONS OF

THE ACM, 38:39–41, 1995.

[54] MINSTER, B.; CAMPBELL, J.; DOZIER, J.; FLEMING, J.; GILLE, J.; HARTMANN,

D.; JEZEK, K.; KIDDER, S.; RAMANKUTTY, N.; THOMPSON, A.; OTHERS. Earth

observations from space: The first 50 years of scientific achievements. In: AGU

Fall Meeting Abstracts, volume 1, p. 08, 2007.

[55] MONIRUZZAMAN, A. B. M.; HOSSAIN, S. A. Nosql database: New era of databases

for big data analytics - classification, characteristics and comparison. CoRR,

abs/1307.0191, 2013.

[56] OLIVÉ, A. Conceptual Modeling of Information Systems. Springer, 2007.

[57] OPEN GOV DATA. Eight principles of open government data. http://resource.

org/8_principles.html, acessado em maio de 2013, 2007.

[58] OPEN KNOWLEDGE FOUNDATION. The Open Knowledge Foundation EMPOWE-

RING THROUGH OPEN KNOWLEDGE. http://www.okfn.org, acessado em

maio de 2013, 2013.

[59] PADHY, R. P.; PATRA, M. R.; SATAPATHY, S. C. RDBMS to NoSQL: Reviewing

Some Next-Generation Non-Relational Database’s? International Journal of Ad-

vanced Engineering Science and Technologies, 11(1), 2011.

[60] PAPAPANAGIOTOU, P.; KATSIOULI, P.; TSETSOS, V.; ANAGNOSTOPOULOS, C.; HAD-

JIEFTHYMIADES, S. RONTO: Relational to ontology schema matching. AIS SIG-

SEMIS BULLETIN, 3(3-4):32–36, 2006.

[61] PICCININI, H.; LEMOS, M.; CASANOVA, M. A.; FURTADO, A. L. W-ray: A strategy

to publish deep web geographic data. In: Trujillo, J.; Dobbie, G.; Kangassalo, H.;

Hartmann, S.; Kirchberg, M.; Rossi, M.; Reinhartz-Berger, I.; Zimányi, E.; Frasincar,

F., editors, ER Workshops, volume 6413 de Lecture Notes in Computer Science,

p. 2–11. Springer, 2010.


[62] POLFLIET, S.; ICHISE, R. Automated mapping generation for converting databa-

ses into linked data. In: Polleres, A.; Chen, H., editors, ISWC Posters & Demos,

volume 658 de CEUR Workshop Proceedings. CEUR-WS.org, 2010.

[63] PRESSMAN, R. S. Software Engineering: A Practitioner’s Approach. McGraw-Hill,

european edition, 1994. Adapted by Darrel Ince.

[64] PRESSMAN, R. S. Software Engineering: A Practicioner’s Approach. McGraw

Hill, 5th edition, 2001.

[65] PRIYATNA, F.; ARANDA, C. B.; CORCHO, S. Applying sparql-dqp for federated

sparql querying over google fusion tables. In: Cimiano, P.; Fernández, M.; Lopez,

V.; Schlobach, S.; Völker, J., editors, ESWC (Satellite Events), volume 7955 de

Lecture Notes in Computer Science, p. 189–193. Springer, 2013.

[66] PRIYATNA, F.; CORCHO, O.; SEQUEDA, J. Formalisation and experiences of r2rml-

based sparql to sql query translation using morph. In: Proceedings of the 23rd

International Conference on World Wide Web, WWW ’14, p. 479–490, Republic and

Canton of Geneva, Switzerland, 2014. International World Wide Web Conferences

Steering Committee.

[67] RAMANATHAN, S.; GOEL, S.; ALAGUMALAI, S. Comparison of cloud database:

Amazon’s simpledb and google’s bigtable. In: Recent Trends in Information

Systems (ReTIS), 2011 International Conference on, p. 165–168, Dec 2011.

[68] SAHOO, S. S.; HALB, W.; HELLMANN, S.; IDEHEN, K.; JR, T. T.; AUER, S.; SE-

QUEDA, J.; EZZAT, A. A survey of current approaches for mapping of relational

databases to rdf, 01 2009.

[69] SALAS, P.; VITERBO, J.; BREITMAN, K.; CASANOVA, M. Stdtrip: Promoting the

reuse of standard vocabularies in open government data. In: Wood, D., editor,

Linking Government Data, p. 113–133. Springer New York, 2011.

[70] SMITH, J.; STUTELY, R. SGML: the user’s guide to ISO 8879. Ellis Horwood Series

in Computers and their Applications. E. Horwood, 1988.

[71] SOMMERVILLE, I.; MELNIKOFF, S.; ARAKAKI, R.; DE ANDRADE BARBOSA, E. Enge-

nharia de software. Pearson Prentice Hall, 2008.

[72] SOMMERVILLE, I. Engenharia de Software. Addison Wesley, São Paulo, SP, 6

edition, 2003. Tradução André Maurício de Andrade Ribeiro; Revisão técnica Kechi

Hirama.


[73] SRIDEVI, K.; UMARANI, D. R. A survey of semantic based solutions to web

mining. International Journal of Emerging Trends and Technology in Computer

Science (IJETTS), 1, 2012.

[74] STAAB, S.; ERDMANN, M.; MAEDCHE, A.; DECKER, S. An extensible approach

for modeling ontologies in rdf(s). In: Proceedings of the ECDL-2000 Workshop

“Semantic Web: Models, Architectures and Management”, Lisbon, September 21,

2000, 2000.

[75] STEVENSON, A. Oxford Dictionary of English. Oxford reference online premium.

OUP Oxford, 2010.

[76] THE UNICODE CONSORTIUM. The Unicode Standard. Technical Report Version

6.0.0, Unicode Consortium, Mountain View, CA, 2011.

[77] VAVLIAKIS, K. N.; GROLLIOS, T. K.; MITKAS, P. A. Rdote - publishing relational

databases into the semantic web. Journal of Systems and Software, 86(1):89–99,

2013.

[78] W3C. W3c semantic web activity, 2009. Última visita 22/11/2013.

APÊNDICE ABancos de Dados Relacionais e NoSQL

Entender a diferença entre um banco de dados relacional e um banco de dadosNoSQL, consiste primeiro em compreender que eles representam dois paradigmas distin-tos com relação ao processo de armazenamento de dados em nuvem e transações.

Brewer [19] propôs um modelo para os sistemas distribuídos, onde provou-se queum sistema distribuído não pode prover simultaneamente as propriedades de consistência,disponibilidade e tolerância ao particionamento. Esse modelo chamado de Teorema CAP( acrônimo inglês para Consistency, Availability, Partition Tolerance ), diz que um sistemapode prover no máximo duas dessas três características simultaneamente.

Se o sistema possui consistência forte e alta disponibilidade (Sistema CA), essesistema não possui tolerância ao particionamento, dessa forma, esse sistema torna-seproblemático caso um nó do cluster fique indisponível.

Existem sistemas que precisam de consistência forte e tolerância ao particiona-mento (Sistema CP), abrindo mão da disponibilidade. Em outras palavras, nesse sistema,caso exista particionamento e não exista um consenso sobre o dado, a escrita pode serrejeitada.

Por fim, existem sistemas que necessitam de alta disponibilidade, não podendonunca ficar offline, e também precisam de tolerância ao particionamento (Sistema AP).Logo, esses sistemas sacrificam a consistência permitindo a escrita a todo o momento,sincronizando os dados num momento posterior. Esses sistemas admitem uma janela deinconsistência, ou seja, em algum momento o sistema se tornar consistente, mas em algunsmomentos ele está inconsistente.

Os paradigmas que definem bancos de dados relacionais e NoSQL, são con-sequências dessa indisponibilidade simultânea das três propriedades do Teorema CAP.Não cabendo a esse trabalho demonstrar vantagens e desvantagens com relação a adoçãode um modelo ou de outro, ele limita-se a enumerar as características que definem essesbancos de dados através de dois paradigmas que os definem chamados ACID e BASE.

Apêndice A 117

A.1 O Modelo Relacional - ACID

O termo ACID ( acrônimo inglês para Atomicity, Consistency, Isolation,

Durability ), refere-se às quatro propriedades das transações.

• Atomicidade: significa “tudo ou nada”. Se qualquer parte da transação ficou incom-pleta, então toda a transação é considerada falha.• Coerência: garante que um banco de dados, antes e depois de uma transação, é

considerado estável em um estado válido.• Isolamento: garante que várias transações sendo executadas ao mesmo tempo não

afetam a execução uma da outra.• Durabilidade: garante que, uma vez que uma transação foi confirmada, permanecerá

no mesmo estado, mesmo que hajam alguns erros, ou mesmo que ocorra uma quedano sistema ou falha de energia.

Esse modelo de transações adotados pelos bancos de dados relacionais, corres-ponde aos Sistemas CA do Teorema CAP. Dessa forma, bancos de dados relacionais (PostgreSQL, Firebird, SQL Server ), apresentam um modelo de transações que garante aconsistência e disponibilidade, mas não apresentam a propriedade de tolerância ao parti-cionamento.

A.2 O Modelo NoSQL - BASE

O termo BASE ( acrônimo inglês para Basically Available, Soft state, Eventual

consistency ),

• Basicamente Disponível: essa restrição afirma que o sistema não garante a dispo-nibilidade dos dados no que diz respeito ao Teorema CAP; haverá uma resposta aqualquer pedido. Entretanto, essa resposta pode ser simplesmente “falha” na obten-ção dos dados solicitados ou os dados podem estar em um estado inconsistente.• Estado Leve: o estado do sistema pode mudar ao longo do tempo, de modo que,

mesmo em momentos sem entrada, pode haver mudanças em curso devido a seumodelo de consistência eventual.• Eventual Consistência: o sistema se torna consistente, uma vez que deixa de receber

entradas. Os dados serão propagados para todos os lugares devidos, mais cedo oumais tarde, mas o sistema não verifica a consistência de cada transação antes de seiniciar a próxima.

Esse modelo corresponde aos Sistemas CP (BigTable, HBase, MongoDB), eSistemas AP (Cassandra, Riak, Amazon Dynamo) do Teorema CAP.

APÊNDICE BOntologias

O objetivo desse trabalho não é explicar em detalhes cada uma das linguagensutilizadas na Web Semântica. Entretanto, como esse trabalho recorrentemente refere-se a ontologias e a linguagem OWL, nesse apêndice são apresentados alguns termosrelacionados à ontologias que são utilizados com frequência ao longo desse trabalho.Todas as definições apresentadas nesse apêndice foram retiradas do relatório técnico daw3c OWL Web Ontology Language Reference [6].

B.1 Elementos Básicos

Os elementos básicos que definem uma ontologia são as classes, os indivíduosou instâncias das classes e as propriedades, também chamadas de relacionamentos, entreestas instâncias. A seguir uma breve descrição de cada um dos elementos citados.

B.1.1 Classe

As classes proveem um método de abstração para agrupar recursos com caracte-rísticas próximas, dessa forma, uma classe define um conjunto de indivíduos que compar-tilham algumas propriedades.

Uma classe pode possuir um relacionamento hierárquico com outras classes, ouseja, uma classe pode apresentar um mecanismo de herança do tipo classe e subclasse.

B.1.2 Indivíduos ou Instâncias

Numa definição similar, se uma classe representa um conjunto de indivíduos quecompartilham algumas propriedades, o indivíduo representa a entidade que implementaas propriedades definidas por uma classe. A entidade que implementa essas propriedadesé chamada de instância da classe.

Apêndice B 119

Os indivíduos em uma ontologia podem incluir objetos concretos como pessoas,animais, móveis, veículos, planetas, assim como indivíduos abstratos como números,direitos ou palavras.

B.1.3 Propriedades ou Relações

Propriedades são relacionamentos binários utilizados no processo de descriçãode um indivíduo. Assim como as classes uma propriedade pode apresentar um relaciona-mento hierárquico com outras propriedades, ou seja, duas propriedades podem se relaci-onar num esquema do tipo propriedade e sub-propriedade.

Em termos de OWL, existem dois tipos de propriedades.

• Propriedades de dados: relação entre indivíduos e valores de dados.• Propriedades de objetos: relação entre indivíduos.

APÊNDICE CFerramentas Utilizadas

C.1 Apache Jena

Jena é uma ferramenta open source, desenvolvida pelo HP Labs até outubro de2009 e atualmente sobre responsabilidade da Apache Software Foundation, destinada paraa construção de aplicações no contexto da Web Semântica e Dados Abertos Ligados[3].

Esse framework agrupa uma série de API’s destinadas a manipulação de for-matos de dados conhecidos como o OWL e o RDF. O framework pode ser dividido nasseguinte partes:

1. RDF

(a) API RDF: essa API é responsável pela manipulação dos dados RDF, permi-tindo sua serialização em formatos como o RDF/XML, N3 e Turtle.

(b) ARQ: ferramenta para realizar consultas SPARQL 1.1, permitindo acessoremoto de múltiplos repositórios semânticos

2. Triple store

(a) TDB: uma triple store nativa para a persistência dos dados.(b) Fuseki: uma ferramenta para disponibilizar as triplas do usuário na forma de

um SPARQL Endpoint acessível por meio de consultas sobre o protolo HTTP.

3. OWL

(a) API de Ontologias: permite a manipulação de RDFS e OWL para enriqueci-mento da semântica dos dados RDF.

(b) API de Inferência: conjunto de regras de inferência preestabelecidos sobreos dados RDF, possui suporte a regras de inferência definidas pelo usuário.

No desenvolvimento do Anotador Semântico de Banco de Dados, foram utiliza-dos a API de Ontologias, API de Inferência, API RDF e o módulo ARQ.

Apêndice C 121

C.2 JAWS

Como citado na seção 3.3, a WordNet é um dicionário léxico com dados sobresubstantivos, verbos, adjetivos e advérbios agrupados em conjuntos de sinônimos cogni-tivos chamados synsets.

Apesar de existirem formas de acesso a WordNet por meio de SPARQL End-

points ou mesmo trazer o seu conteúdo para um banco de dados relacional, neste trabalhooptou-se por utilizar uma API em Java, para manipulação do conteúdo da WordNet naforma de objetos.

O JAWS ( acrônimo para Java API for WordNet Searching ) é uma API desen-volvida para consultas a base de dados da WordNet nas suas versões 2.1 e 3.0, onde oresultado das consultas é classificado de acordo com os sinônimos, antônimos, hiperôni-mos, hipônimos, merônimos e parônimos de um synset 1.

C.3 GTranslate

Gtranslate é uma API open-source desenvolvida em Java, que oferece suportea maioria dos recursos utilizados pelo Google Translator2. Essa API foi utilizada naaplicação pelo Analisador Léxico Sintático, componente descrito na subseção 6.3.1.Utiliza-se essa API para fazer traduções de palavras de uma língua qualquer, do quala ontologia ou os bancos de dados estejam definidos, assim como no processo dereconhecimento da linguagem natural sendo utilizado por essas ontologias ou bancos dedados.

1http://lyle.smu.edu/ tspell/jaws/, último acesso em Janeiro de 20152https://code.google.com/p/java-google-translate-text-to-speech/source/checkout, último acesso em Ja-

neiro de 2015

APÊNDICE DModelo de Dados

Nesta apêndice, são apresentados os detalhes do banco de dados utilizado inter-namente pelo Anotador Semântico de Banco de Dados. O banco de dados utilizado foium banco de dados SQLite, sendo todos os dados inseridos diretamente pela aplicação.

Nas seções seguintes, são descritas as tabelas desse banco de dados utilizadaspor módulo da solução desenvolvida.

D.1 Tabelas Utilizadas pelo Cliente SPARQL

O Cliente SPARQL possui uma única tabela, utilizada para armazenar a relaçãoentre a categoria e o SPARQL Endpoint correspondente. O Código D.1 corresponde aoSQL necessário para a criação dessa tabela de banco de dados.

Código D.1 Tabela de Categorias por SPARQL Endpoint

CREATE TABLE ‘categoria_endpoint ‘ (

‘id‘ INTEGER PRIMARY KEY AUTOINCREMENT ,


‘sql‘ TEXT NOT NULL,

‘sqlparameter ‘ TEXT ,

‘endpoint ‘ TEXT NOT NULL

);

A seguir apresenta-se uma breve descrição sobre cada coluna:

1. id: chave primária auto incrementável da tabela.2. nome: nome utilizado para definir a categoria.3. sql: consulta, geralmente em SPARQL, utilizada contra o repositório semântico.4. sqlparameter: parâmetro a ser adicionado na consulta quando esse for um

SPARQL, para filtrar resultados.

Apêndice D 123

5. endpoint: endereço do repositório semântico, geralmente sendo um SPARQL End-

point ou Web Service.

D.2 Tabelas Utilizadas pelo Extrator

O Extrator possui uma única tabela, utilizada para armazenar a relação entre acategoria e o domínio web correspondente. O Código D.2 corresponde ao SQL necessáriopara a criação dessa tabela de banco de dados.

Código D.2 Tabela de Categorias por Extrator

CREATE TABLE ‘categoria_extrator ‘ (

‘id‘ INTEGER PRIMARY KEY AUTOINCREMENT ,


‘url‘ TEXT NOT NULL,

‘caminho ‘ TEXT NOT NULL,

‘template ‘ TEXT

);


1. id: chave primária auto incrementável da tabela.2. nome: nome utilizado para definir a categoria.3. url: endereço do domínio do qual se realiza a busca.4. caminho: seletor JQuery utilizado para localizar o componente utilizado para

identificação do recurso.5. template: nome de uma classe necessária para realizar a leitura de uma página,

necessário em situações que não seja possível utilizar o seletor JQUery da colunacaminho.

D.3 Tabelas Utilizadas pelo Analisador Léxico/Sintático

O Analisador Léxico/Sintático possui uma única tabela, utilizada para armazenaras traduções realizadas pelo gtranslate. O Código D.3 corresponde ao SQL necessário paraa criação dessa tabela de banco de dados.

Apêndice D 124

Código D.3 Tabela de palavras traduzidas por idioma

CREATE TABLE ‘translatedSentence ‘ (

‘lg_text ‘ TEXT ,

‘lg_from ‘ TEXT ,

‘lg_to ‘ TEXT ,

‘lg_value ‘ TEXT NOT NULL,

PRIMARY KEY(lg_text ,lg_from ,lg_to)

);


1. lg_text: texto plano utilizado no processo de tradução.2. lg_from: indicador de duas letras que define o idioma de origem.3. lg_to: indicador de duas letras que define o idioma de destino.4. lg_value: texto plano traduzido.

mapeamento de bancos de dados para domínios semânticos (.pdf)

Documents