Mapeamento de Bancos de Dados para Domínios - INF

U NIVERSIDADE F EDERAL DE G OIÁS
I NSTITUTO DE I NFORMÁTICA
JÁDERSON A RAÚJO G ONÇALVES DA C RUZ
Mapeamento de Bancos de Dados para
Domínios Semânticos
Goiânia
2015
JÁDERSON A RAÚJO G ONÇALVES DA C RUZ
Mapeamento de Bancos de Dados para
Domínios Semânticos
Dissertação apresentada ao Programa de Pós–Graduação do
Instituto de Informática da Universidade Federal de Goiás,
como requisito parcial para obtenção do título de Mestre em
Ciências da Computação.
Ciências da
Área de concentração: Sistemas
de Computação
Informação.
Orientador: Prof. Cedric Luiz de Carvalho
Goiânia
2015
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 de
Informática (INF) , Programa de Pós-Graduação em Ciência da
Computação, Goiânia, 2015.
Inclui algoritmos, lista de figuras, lista de tabelas.
1. Repositório Semântico. 2. Dado Aberto Ligado. 3. Mapeamento
Semântico. I. Luiz de Carvalho, Cedric, orient. II. Título.
Todos os direitos reservados. É proibida a reprodução total ou parcial do
trabalho 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 Federal
de Goiás. Durante sua graduação, atuou com pesquisa em aplicações baseadas
em localização no Instituto de Informática da UFG. Nos últimos dois anos
atuou num projeto de melhoramento da qualidade do leite, em parceria com
a FAPEG e com o LQL - Laboratório da Qualidade do Leite; desde o ano
de 2014 atua no projeto de visão computacional AFAD em parceria com
a FINEP/FAPEG. Atualmente é coordenador de desenvolvimento em uma
empresa especializada em integração de dados e aplicações de Big Data e
Business 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 diversas
pessoas, à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 Campus
Jataí, pelos valiosos conselhos e orientações.
Aos colegas do mestrado e professores, que considero, pessoas extraordinárias e
do qual tenho orgulho de ter conhecido.
Aos aos meus familiares, pelo apoio em todos os sentidos. Sem eles, eu não teria
conseguido chegar até aqui.
À todos os amigos que colaboraram de alguma forma para a concretização deste
trabalho, seja por sua amizade e paciência ou simplesmente por aguentarem o meu mal
humor 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ínios
Semânticos. Goiânia, 2015. 124p. Dissertação de Mestrado. Instituto de Informática, Universidade Federal de Goiás.
Este trabalho apresenta uma proposta de mapeamento de bancos de dados para um domí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. Subsequentemente 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 Federal
de Goiás.
This paper proposes a database mapping to a semantic domain. This process consists of
mapping 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 order
to 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
16
17
19
19
20
Introdução
1.1
1.2
1.3
1.4
2
Motivação
Objetivo
Metodologia
Organização da Dissertação
Fundamentos Teóricos
2.1
2.2
2.3
Modelos de Bancos de Dados
2.1.1
Bancos de Dados Relacionais
2.1.2
Bancos de Dados Orientados a Objetos
2.1.3
Bancos de Dados Chave-Valor
2.1.4
Bancos de Dados Orientados a Colunas
2.1.5
Bancos de Dados de Documentos
2.1.6
Bancos de Dados Orientados a Grafos
Web Semântica
2.2.1
Unicode e Uniform Resource Identifiers (URIs)
2.2.2
Extensible Mark-up Language (XML)
2.2.3
Resource Description Framework (RDF)
2.2.4
Resource Description Framework Schema (RDFS)
2.2.5
Web Ontology Language (OWL)
2.2.6
Lógica, Prova e Validação
Dados Abertos
2.3.1
2.3.2
Dados Abertos Científicos
Dados Abertos Governamentais
Princípios dos Dados Abertos Governamentais
Leis dos Dados Abertos Governamentais
Dados Abertos no Mundo
Dados Abertos no Brasil
2.3.3
2.4
Dados Abertos Ligados
Sobre o Capítulo
22
22
23
23
24
25
26
27
28
29
29
29
29
30
30
30
31
31
31
32
32
33
34
36
3
Bases de Conhecimento e suas Ontologias
3.1
3.2
3.3
3.4
3.5
3.6
3.7
4
3.1.1
Ontologia DBPedia
3.1.2
Acessando a DBPedia
GeoNames
3.2.1
Ontologia GeoNames
3.2.2
Acessando o GeoNames
WordNet
3.3.1
Ontologia WordNet
3.3.2
Acessando o WordNet
YAGO2
3.4.1
Ontologia YAGO2
3.4.2
Acessando o YAGO2
Freebase
3.5.1
Ontologia Freebase
3.5.2
Acessando o Freebase
Interligando Dados Abertos
Sobre o Capítulo
Trabalhos Relacionados
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
5
DBPedia
Morph RDB
RDOTE
RDB2OWL
MARSON
RONTO
AuReLi
StdTrip
MASTRO
Resumo dos Sistemas Analisados
Sobre o Capítulo
Solução Proposta
5.1
5.2
Mapeamento Semântico de Banco de Dados
Etapas da Solução
5.2.1
Mapeando entre Bancos de Dados e Ontologia
Classificação Sintática
Definindo Candidatos
Filtrando Candidatos
5.2.2
Mapeamento para Repositórios Semânticos
Categorizando o Acesso a Repositórios Semânticos
Analisando Agrupadores Primários
Lematização
Associando Categorias com Agrupadores Primários
Analisando Agrupadores Secundários
5.2.3
5.3
Gerando Formatos Abertos de Mapeamento de Dados
Sobre o Capítulo
37
39
40
40
41
41
42
42
43
43
43
44
44
45
45
46
46
48
49
49
50
51
52
52
53
53
54
55
56
57
58
59
59
60
60
61
64
65
68
68
68
69
70
71
6
Projeto do Sistema de Mapeamento de Banco de Dados
6.1
6.2
6.3
Atores
Requisitos da Aplicação
6.2.1
Requisitos Funcionais
6.2.2
Requisitos Não Funcionais
Modelagem, Arquitetura e Arquivo de Resultado
6.3.1
Arquitetura
Interface
Motor de Execução
Analisador Léxico/Sintático
Extrator
Cliente SPARQL
6.4
6.5
7
6.3.2
Arquivo de Resultado
6.3.3
Modelagem
Desenvolvimento da Aplicação
6.4.1
Tecnologias Empregadas
6.4.2
Bases de Dados Linguísticas
6.4.3
Categorias Utilizadas
6.4.4
Exemplo de Utilização
Sobre o Capítulo
Análise de Resultados
7.1
7.2
7.3
7.4
Resultados da Aplicação - Agrupadores Primários
7.1.1
Experimento 1
7.1.2
Experimento 2
7.1.3
Experimento 3
Resultados da Aplicação - Agrupadores Secundários
7.2.1
Experimento 1
7.2.2
Experimento 2
7.2.3
Experimento 3
Resultados da Aplicação - Associação Semântica
Sobre o Capítulo
72
73
73
73
75
76
77
77
77
78
79
80
82
83
85
86
86
88
90
96
97
97
98
99
100
101
101
102
103
104
105
Contribuições
Trabalhos Futuros
106
107
107
Referências Bibliográficas
109
A
116
117
117
8
Conclusão e Trabalhos Futuros
8.1
8.2
Bancos de Dados Relacionais e NoSQL
A.1
A.2
B
O Modelo Relacional - ACID
O Modelo NoSQL - BASE
Ontologias
B.1
Elementos Básicos
B.1.1
Classe
B.1.2
Indivíduos ou Instâncias
B.1.3
Propriedades ou Relações
118
118
118
118
119
C Ferramentas Utilizadas
C.1
C.2
C.3
Apache Jena
JAWS
GTranslate
D Modelo de Dados
D.1
D.2
D.3
Tabelas Utilizadas pelo Cliente SPARQL
Tabelas Utilizadas pelo Extrator
Tabelas Utilizadas pelo Analisador Léxico/Sintático
120
120
121
121
122
122
123
123
Lista de Figuras
1.1
Diagrama de Fluxo do Projeto
20
2.1
2.2
2.3
2.4
2.5
2.6
2.7
Um exemplo de bancos de dados relacional
Um exemplo de bancos de dados orientado a objetos
Um exemplo de bancos de dados do tipo chave valor
Um exemplo de bancos de dados orientado a colunas
Um exemplo de bancos de dados de documentos
Um exemplo de bancos de dados do tipo grafos
Arquitetura da Web Semântica
23
24
25
25
26
27
28
3.1
3.2
Linguagens Utilizadas na Web
Modelo Adaptado de Integração de Dados de Beners-Lee
37
39
4.1
Esquema de Mapeamento do RD2OWL[22]
51
5.2
5.3
5.4
5.5
5.6
5.7
58
58
58
Tabelas x Colunas
62
Processo de Associação do Banco de Dados com Ontologia de Referência 62
Tabela x Colunas
63
Complementação de Colunas
64
Complementação de Linhas
65
Modelo de Acesso de Dados por Ontologia
70
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
6.9
6.10
6.11
6.12
6.13
6.14
Casos de Uso do Sistema
Arquitetura Proposta
Analisador Léxico/Sintático
Módulo Extrator
Módulo Cliente SPARQL
Exemplo de Resultado da Aplicação
Mapeando Bancos de Dados e Ontologia
Vinculando Categoria a um Domínio
Vinculando Categoria a um Domínio
Exemplo de dicionário do pacote de francês
Exemplo de regras do pacote de inglês
Nuvem de Dados Abertos Ligados, Abril de 2014[32]
Ontologia de Exemplo
Adicionando um Banco de Exemplo
5.1
Mapeamento Semântico de Banco de Dados
(a)
(b)
Tabelas para Nodos
Banco de Dados Mapeado
74
77
78
80
81
82
84
84
85
87
87
88
90
92
Lista de Tabelas
2.1
2.2
2.3
2.4
2.5
2.6
As 5 estrelas do modelo Gov 2.0
Custos e benefícios do modelo de ? dados web
Custos e benefícios do modelo de ? ? dados web
Custos e benefícios do modelo de ? ? ? dados web
Custos e benefícios do modelo de ? ? ? ? dados web
Custos e benefícios do modelo de ? ? ? ? ? dados web
34
35
35
35
35
35
3.1
3.2
3.3
Exemplo de Relações Léxicas na WordNet
Ligações da DBPedia para outros repositórios[51]
Os 10 repositórios com mais ligações para a DBPedia[51]
43
47
48
4.1
Resumo Trabalhos Relacionados
55
5.1
5.2
Modos de agrupamento de dados por paradigma de banco de dados
Relação entre synsets da ontologia com synsets do banco de dados
60
61
6.1
6.2
Categorias Extrator
Categorias Cliente SPARQL
89
91
7.1
7.2
Banco de Dados x Ontologias
Entrada e Saída Agrupador Primário - Experimento 1
(a)
(b)
7.3
Entrada e Saída Agrupador Primário - Experimento 2
(a)
(b)
7.4
Entradas
Saídas
Entrada/Saída Agrupador Secundário - Experimento 3
(a)
(b)
7.8
Entradas
Saídas
Entrada/Saída Agrupador Secundário - Experimento 2
(a)
(b)
7.7
Entradas
Saídas
Entrada/Saída Agrupador Secundário - Experimento 1
(a)
(b)
7.6
Entradas
Saídas
Entrada e Saída Agrupador Primário - Experimento 3
(a)
(b)
7.5
Entradas
Saídas
Entradas
Saídas
Categorias X Experimentos
98
98
98
98
99
99
99
100
100
100
101
101
101
102
102
102
103
103
103
104
Lista de Códigos de Programas
5.1
5.2
6.1
6.2
6.3
6.4
D.1
D.2
D.3
Consulta SPARQL a DBPedia
Consulta SPARQL a Dailymed
Exemplo de Consulta SPARQL
Tabela Verbetes
Individual x Colunas
SQL Individual x Colunas
Tabela de Categorias por SPARQL Endpoint
Tabela de Categorias por Extrator
Tabela de palavras traduzidas por idioma
66
67
81
88
94
95
122
123
124
CAPÍTULO 1
Introdução
O surgimento da World WideWeb mudou a forma como os negócios são conduzidos, como as pessoas interagem entre si, e como o conhecimento é disseminado. Muitas
são as ferramentas que utilizam a Web em seu formato atual, estando essas ferramentas
sujeitas às limitações dessa.
Dentre as limitações mais conhecidas da web atual cita-se sua baixa precisão nas
buscas, seus resultados são muito dependentes do vocabulário utilizado, as informações
são localizadas e não recuperadas, suas principais ferramentas para busca de informação
são inteiramente voltadas para a interação humana, não sendo legíveis para outras ferramentas de software.
É possível dividir a web em algumas fases, sendo a primeira fase representada
por uma web de conteúdo sintático (Web 1.0 ou Web Sintática). Nessa primeira versão da
web os documentos eram indexados, endereçados e acessados de qualquer computador
a partir de um navegador. Existia nesse momento uma certa divisão entre aqueles que
produziam os documentos disponibilizados e aqueles que os liam. Esse modelo foi o
proposto por Tim Berners-Lee[9].
Em um segundo momento, a web evoluiu para um modelo onde surgiram
aplicações dentro dessa. Nesse novo modelo, os usuários da web passaram a interagir
e a atuarem tanto como produtores quanto consumidores de conteúdo. Esse modelo de
web, também conhecido como Web 2.0, ou mesmo Web Social, é o modelo predominante
nos 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, Tim
Berners-Lee e pelo W3C Consortium, a Web Semântica ou Web 3.0, propõem um
modelo onde a web não seja legível somente para os seres humanos, mas também para
os computadores. Nesse modelo, a informação é disponibilizada de forma estruturada,
padronizada, interligada e em formato não proprietário (Dados Abertos Ligados ou Dados
Abertos Conectados[58]).
Ao longo dos últimos anos, um número crescente de provedores de dados
começ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 e
televisão, genes, proteínas, medicamentos e ensaios clínicos, comunidades online, dados
estatísticos, os resultados do censo, entre outros[14].
Dentre as fontes para a geração de dados abertos, merece destaque a geração
de dados abertos a partir de bancos de dados. A maior parte dos dados que sustentam
a Web e em domínios como as ciências naturais, gerenciamento de dados espaciais são
armazenados em bancos de dados relacionais, por seu histórico comprovado de escalabilidade, armazenamento eficiente, execução de consultas otimizadas e confiabilidade[68].
Nos últimos anos, entretanto, vem aumentando a demanda pelo uso de bancos de dados
não relacionais, ou NoSQL[55], em domínios específicos.
A capacidade de mapear bancos de dados, seja relacional ou NoSQL, para um
formato de dados abertos que favoreça a integração e leitura por máquina, é um dos
passos a serem dados para a evolução da web. Este trabalho, apresenta algumas técnicas
de mapeamento de banco de dados, assim como propõe uma nova técnica de mapeamento
que permita uma análise semântica na formulação de consultas à base de dados sendo
mapeada.
1.1
Motivação
A web em seus dias atuais, vivencia um momento de transição. Neste momento, a
web possui a maior parte de seu conteúdo voltado à compreensão de informações por parte
dos seres humanos. Entretanto, a nova geração da web busca a criação de um ambiente de
conteú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 principalmente
a modificação da forma como os dados são estruturados. O principal objetivo desse novo
modelo da web é permitir uma melhor interpretação dos recursos da web por parte dos
computadores, e consequentemente o aumento do poder de resposta computacional sobre
a massa de dados crescente encontrada na web.
A Web Semântica pode ser vista como uma extensão da web atual, onde a consolidação desse novo paradigma depende não somente da disponibilização dos novos dados
segundo suas especificações, mas também de formas de inserir nesse os dados existentes
modelados sobre o paradigma atual. Dessa forma, torna-se importante o desenvolvimento
de sistemas capazes de realizarem a análise dos dados modelados sobre esse paradigma e
convertê-lo para o paradigma da Web Semântica.
Dentre as várias fontes de dados utilizadas na web, os bancos de dados são algumas das mais importantes existentes. Bancos de dados são utilizados por praticamente
todos 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 possuem
características que inviabilizam sua leitura por máquinas, tomando como exemplo formatos 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 desse
novo paradigma da web.
Bancos de dados relacionais possuem uma estrutura sintática mínima, onde o
conteúdo é armazenado em uma divisão pré-definida de estrutura de entidades e relacionamento entre essas, assim como definição de tipos específicos para as propriedades
dessas entidades. Mesmo possuindo essa estrutura mínima, esses bancos de dados não
apresentam 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 responsá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 os
dados, de forma que as informações de um domínio possam ser utilizadas por outros
domínios a fim de produzir resultados mais significativos. Uma informação sobre a
evolução do nível de renda da população brasileira por região do país, contida em um
banco de dados do ministério do desenvolvimento, poderia ser enriquecida através da
integração desses dados com estatísticas encontradas em bancos de dados de outros
ministérios, de secretarias estaduais e municipais, entidades paraestatais ou instituições
privadas sobre educação, saneamento, preferências políticas, entre outros.
Este trabalho busca o desenvolvimento de técnicas para a integração de sistemas
de bancos de dados ao novo paradigma, trazido pela Web Semântica, assim como desenvolver uma ferramenta que compatibilize esses sistemas permitindo assim a coexistência
entre esses modelos, até o dia que a web esteja pronta para desenvolver-se unicamente
sobre 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 vistos
de forma integrada, segundo um modelo definido numa ontologia.
• Permitir que a informação proveniente dessas fontes de dados mapeadas referenciem outros domínios, permitindo o enriquecimento dos dados desses bancos de
dados.
1 Portable
Document Format[45]
1.2 Objetivo
1.2
19
Objetivo
Segundo o Dicionário Oxford do Inglês, podemos definir mapeamento da seguinte 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 mapeamento
automático, entre bancos de dados, relacionais e NoSQL, e uma ontologia que possuam
domínios correlacionados. Esta proposta tem como objetivo facilitar o desenvolvimento
da Web Semântica.
Um foco adicional deste trabalho é de disponibilizar o mapeamento entre os
bancos de dados e a ontologia de referência em formato de Dado Aberto Conectado. Essa
representação utiliza padrões preestabelecidos e formalizados pelas entidades competentes.
A ideia por trás desse projeto é construir um mecanismo para a disponibilização
dos dados provenientes de bancos de dados, utilizando como referência a ontologia. Dessa
forma, um usuário pode acessar os dados dessas bases, mesmo sem conhecer os detalhes
dessas bases de dados.
O usuário apenas conhece o domínio tratado pela base de dados, e define suas
intenções sobre essa base de dados requisitando informações através da ontologia para o
qual deseja-se mapear a informação.
Para atingir esses objetivos principais, pretende-se atingir os seguintes objetivos
específicos, convergentes com esses objetivos principais :
1. Apresentar uma visão geral sobre Bancos de Dados e Web Semântica, descrevendo
resumidamente as principais tecnologias e conceitos presentes nessas áreas, assim
como suas atuais limitações.
2. Realizar um estudo do estado da arte das técnicas utilizadas até então para mapear
bancos de dados para ontologias, assim como aplicações para essas técnicas em
ambientes reais.
3. Disponibilizar a informação proveniente dos Bancos de Dados analisados em
formato aberto e conectado a outros elementos da Web Semântica.
4. Projetar uma ferramenta que permita demonstrar o mecanismo de mapeamento definido nesse trabalho, sendo aplicado em situações reais, assim como seu mecanismo
de integração com repositórios semânticos diversos.
1.3
Metodologia
A realização dessa pesquisa foi dividida em etapas, como pode ser observado na
Figura 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, citamse 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 mapeamento
de banco de dados para modelos semânticos.
3. Projeto de Software. Foi efetuado um levantamento de requisitos e definição de
uma arquitetura para uma ferramenta responsável por aplicar o modelo proposto
neste trabalho.
4. Desenvolvimento do Projeto. Foi feita a implementação da aplicação de mapeamento 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 e
organizado como descrito a seguir.
No Capítulo 2, são introduzidos os fundamentos teóricos utilizados ao longo
desse 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ão
abordados 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 conhecimento
semânticas, com foco na ontologia que as definem e que podem ser utilizadas nesse
projeto.
No Capítulo 4, são apresentados alguns trabalhos relacionados ao tema dessa
dissertação.
No Capítulo 5, é apresentada a solução proposta nesse trabalho num contexto de
alto nível, onde define-se a proposta para realizar o mapeamento de bancos de dados em
contexto semântico.
No Capítulo 6, é realizada uma explicação sobre o projeto implementado. Nesse
capítulo, são descritos os principais atores, requisitos funcionais, requisitos não funcionais
que serviram de base para o projeto do sistema. Uma arquitetura do projeto é descrita, bem
como 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 principais
vantagens com relação ao sistema, assim como é realizada uma análise de suas principais
deficiências.
Finalmente, o Capítulo 8 apresenta considerações finais do trabalho, onde são
enumeradas as contribuições esperadas desse sistema e possíveis trabalhos futuros.
CAPÍTULO 2
Fundamentos Teóricos
O ponto de partida para desenvolver uma pesquisa visando o mapeamento entre
bancos de dados e ontologias por anotações semânticas é a compreensão de determinados
temas considerados fundamentais para essa pesquisa. Dessa forma, torna-se possível
propor novas técnicas, de propósito geral, para realizar o processo de mapeamento
proposto neste trabalho.
Nesse capítulo, são apresentados alguns dos conceitos fundamentais necessários
para o desenvolvimento dessa pesquisa. Inicialmente, na Seção 2.1, são apresentados os
principais 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 Web
Semântica, assim como das principais tecnologias relacionadas a ela. A compreensão
desse tópico é necessária tanto para o entendimento do Capítulo 3, quanto para desenvolver as integrações entre os bancos de dados e os repositórios semânticos, processo
descrito na Seção 6.3.1.
Ao final do capítulo, são apresentados os conceitos relacionados a Dados Abertos
Ligados. Esse paradigma corresponde a um dos objetivos desse trabalho, onde os dados
das bases mapeadas são disponibilizados segundo o modelo utilizado na ontologia de
referê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 armazenados ou recuperados. Pensando em um sistema capaz de realizar a engenharia reversa
de uma base de dados genérica, os diferentes modelos de bancos de dados devem ser
considerados. 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 da
utilizaçã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ão
ignorados.
Nas seções seguintes, serão apresentadas definições para os principais modelos
de banco de dados. Considera-se tanto os bancos de dados relacionais quanto os bancos
NoSQL. O Apêndice A contém uma explicação mais detalhada sobre as diferenças dos
bancos de dados relacionais e NoSQL.
2.1.1
Bancos de Dados Relacionais
O modelo relacional para gerenciamento de banco de dados é um modelo
matemático para descrever a estrutura de dados. É um modelo de bancos de dados com
base na lógica de predicados de primeira ordem, formulada pela primeira vez e proposto
em 1969 por Edgar F. Codd.[30]. Em um Banco de Dados Relacional, todos os dados são
representados em termos de tuplas, agrupados em relações. Uma base de dados organizada
em 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 usase termos como tabelas, linhas e colunas para representar os conceitos de relações, tuplas
e atributos, respectivamente.
As tuplas ou linhas de uma tabela ou relação são identificadas através de atributos
chamados de chave primária. Da mesma forma, essas tabelas de bancos de dados podem
relacionar-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 definidos
pela classe em que esteja o objeto[48]. Pode ser visto como a junção entre o paradigma
de orientação a objetos, presente nas linguagens de programação moderna, e a teoria de
banco de dados relacionais.
2.1 Modelos de Bancos de Dados
24
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 relacionamento
entre 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 observado
na Figura 2.2. Observa-se que tanto a tabela Física quanto a tabela Jurídica possuem
relacionamento de herança com a tabela Pessoa, indicando que essas tabelas representam
tipos de Pessoas.
2.1.3
Bancos de Dados Chave-Valor
Esse modelo de banco de dados possui uma estrutura simples de utilização de
chaves devidamente indexadas[59]. Estes sistemas podem armazenar dados estruturados
e não estruturados. Segundo Moniruzzaman e Hossain[55] esse tipo de banco de dados
pode ser definido do seguinte modo:
“Normalmente, esses Sistemas de Gerenciamento de Dados armazenam
itens como identificadores alfanuméricos (chave) e associam com valores em tabelas simples, autônomas (conhecidas como hash tables). Os
valores podem ser sequências de texto simples ou listas e conjuntos mais
complexas. As buscas de dados normalmente só podem ser realizadas
sobre as chaves, não sobre seus valores, sendo limitados a correspondência exata.”
As hash tables utilizadas por esse tipo de banco de dados são semelhantes àquelas estruturas de dados encontradas em linguagens de programação. Sua estrutura simples
permite um acesso rápido aos dados, sendo utilizada principalmente para trabalhar com a
informação na memória principal. Na Figura 2.3, é possível visualizar uma representação
desse tipo de banco de dados. Nesse exemplo, existem chaves ( Massa, Comprimento,
Largura ) que possuem itens respectivamente relacionados a valores ( 5kg, 15cm, 12cm ).
2.1 Modelos de Bancos de Dados
25
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 é o
SimpleDB da Amazon[27]. O SimpleDB da Amazon é um serviço web que fornece os
recursos essenciais de banco de dados, utilizando a infraestrutura de nuvem da Amazon
para oferecer alta disponibilidade, escalabilidade e resistência a falhas de armazenamento
de 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 estreitamente relacionadas, em vez de conjuntos de informações em uma tabela estritamente
estruturada 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 a
colunas, onde uma chave está relacionada a um conjunto de elementos abstratos com
valores correspondentes, elementos esses chamados de colunas.
Figura 2.4: Um exemplo de bancos de dados orientado a colunas
2.1 Modelos de Bancos de Dados
26
Dentre os bancos de dados que seguem esse paradigma, cita-se o BigTable da
Google e Cassandra.
Bigtable é uma implementação de um mapa multidimensional ordenado, onde
a indexação é feita por linhas, colunas e campo do tipo timestamp[28]. Esse banco de
dados foi construído pela Google para atender demandas de projetos internos, tornandose operacional em abril de 2005. Bigtable foi desenvolvido para trabalhar com petabytes
de informação, sendo executado sobre centenas ou mesmo milhares de computadores.
O Apache Cassandra é um sistema de armazenamento distribuído para o gerenciamento de grandes quantidades de dados distribuídos, podendo funcionar em hardware
de baixo custo [50]. Esse banco de dados ganhou grande popularidade por ser usado em
redes 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 qualquer
comprimento em um documento [59]. Geralmente esses bancos de dados armazenam
documentos baseados no formato de dados JSON[31].
A Figura 2.5 apresenta uma representação de um banco de dados orientado a
documentos. Observa-se que a ideia por trás desse paradigma consiste numa extensão
do paradigma de banco de dados orientado a colunas. Nesse modelo, os conceitos
abstratos de colunas observados anteriormente são agrupados em um conjunto chamado
documento.
Figura 2.5: Um exemplo de bancos de dados de documentos
Exemplos de bases de dados de documentos seriam o MongoDB e o Apache
CouchDB.
2.1 Modelos de Bancos de Dados
27
O MongoDB é um Sistema de Gerenciamento de Dados em Nuvem de código
aberto, escalável e de propósito geral, que utiliza sistemas de índices secundários, consultas sobre intervalos, técnicas de ordenação, agregação e índices geoespaciais[29].
O Apache CouchDB é um banco de dados escrito em Erlang, desenvolvido para
viabilizar sua utilização em servidores com hardware de baixo desempenho. CouchDB
realiza consultas sobre estruturas chamadas “views”, possui um sistema de indexação
baseado em B-trees e utiliza técnicas de armazenamento e controle de concorrência
baseadas 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 que
as estruturas de dados para o esquema e as instâncias são modelados na forma de grafos
ou generalizações desses. A Figura 2.6 apresenta um modelo de um banco de dados
orientado a grafos. Nesse modelo, a manipulação de dados é expressa por operações
em grafos orientados, usando conceitos como caminhos, vizinhos, subgrafos, padrões
grá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 oferece
persistência de alta performance, escalabilidade e possui uma comunidade ativa e com
uma boa documentação[43].
2.2 Web Semântica
2.2
28
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 problemas são ocasionados por fatores como a estrutura para compartilhamento de recursos
distribuídos, autônomos, heterogêneos, a falta de um padrão mínimo para exibição da
informação, entre outros.
A informação na Web é tipicamente representada em linguagem natural, permitindo que ela seja compreendida por pessoas. Entretanto, para prover informação de
forma que computadores também possam compreendê-la é necessário representá-la de
forma sistemática e semântica.
Nas palavras de Berners-Lee[10]: “Web semântica é a extensão da web obtida
via adição de semântica ao formato atual de representação de dados”. Em um ponto de
vista 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 pesquisadores
e parceiros industriais.
A Web Semântica pode ser dividida em partes, segundo um modelo de camadas 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 e
esquema 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
2.2.1
29
Unicode e Uniform Resource Identifiers (URIs)
Unicode é um padrão que fornece um número único para cada caractere, não importa 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, geralmente na forma de cadeias de caracteres compactos, utilizados para referir-se a recursos
abstratos ou físicos, geralmente usados na internet[8]. Esses nomes são utilizados para
identificação única de recursos na Web.
Essa camada fornece interoperabilidade em relação à codificação de caracteres e
ao 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 grande
escala, o XML também está desempenhando um papel cada vez mais importante na troca
de 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ísticas 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 grafos e modelos de semântica formal com uma noção rigorosamente definida de vinculação
entre 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 predicado 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 formatos
concebidos individualmente possam ser de compreensão mais fácil e direta, mas a generalidade 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 incluir
um vocabulário maior com restrições semânticas mais complexas[41]
O modelo de dados RDF não prevê mecanismos para declarar classes nem propriedades, nem fornece qualquer mecanismo para definir as relações entre propriedades e
outros recursos. A declaração destas propriedades (atributos) e sua semântica correspondente 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 que
estã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 processar
o conteúdo da informação ao invés de apenas apresentar informações para os seres
humanos [52].
OWL é considerada uma linguagem mais complexa, com maior capacidade de
interpretação do que o RDF. OWL busca identificar com precisão a natureza dos recursos
e 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 de
uma conceitualização compartilhada”. Entende-se por “formal” o fato de uma ontologia
ser interpretável por seres humanos ou por máquinas; ser “explícita” significa que essa
possui conceitos, propriedades, relações, funções, restrições, axiomas, explicitamente definidos; “compartilhado” significa que sua representação de conhecimento é consensual;
e “conceitualização” diz respeito a um modelo abstrato de algum fenômeno do mundo
real. 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 produzir
conjuntos de possíveis significados[73], auxiliando o processamento por máquinas e
facilitando 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 seguinte
forma:
• Lógica: É responsável pelo raciocínio e execução de inferências lógicas a partir da
semântica previamente descrita;
• Prova: Camada para verificar a autenticidade do comportamento do agente e corroboraçã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 abertos
quando qualquer pessoa pode livremente usá-los, reutilizá-los e redistribuí-los, estando
2.3 Dados Abertos
31
sujeito a, no máximo, a exigência de creditar a sua autoria e compartilhar pela mesma
licença.”
Dados Abertos ou Dados Públicos são dados de livre acesso a todas as pessoas
que assim desejarem, para que essas os utilizem ou publiquem independente de qualquer
restrição ou mecanismo de controle. A filosofia dos Dados Abertos foi estabelecida há
muito tempo, no entanto o termo Dados Abertos ganhou popularidade recentemente com
o advento da Internet.
Várias podem ser as fontes dos Dados Abertos, em particular nos últimos anos
esses 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 estabelecido com a formação do sistema Centro Mundial de Dados. O Conselho Internacional
das Uniões Científicas (agora o Conselho Internacional para a Ciência) estabeleceu vários
centros de dados mundiais para minimizar o risco de perda de dados e para maximizar a
acessibilidade dos dados, ainda em 1955, recomendando que os dados sejam disponibilizados 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ínio
público para a livre utilização pela sociedade[1]”.
Em outras palavras os DAG são uma metodologia para a publicação de dados dos
governos 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 governamentais
converge com a evolução das democracias modernas, onde esses representam um novo
estágio de transparência e accountability da gestão pública. Em outras palavras, os
dados abertos e sua filosofia são um meio para a implementação dos paradigmas de
gestão governamental do chamado Novo Serviço Público (NSP) para o qual caminham
as democracias ao redor do mundo.
Em um nível mais elevado, o conceito de DAG favorece o desenvolvimento de
aplicaçõ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-
2.3 Dados Abertos
32
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 dado
que não está sujeito a limitações válidas de privacidade, segurança ou controle de
acesso.
2. Primários. Os dados são apresentados tais como os coletados na fonte, com o maior
ní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 à preservação do seu valor.
4. Acessíveis. Os dados são disponibilizados para o maior alcance possível de usuários
e para o maior conjunto possível de finalidades.
5. Compreensíveis por máquinas. Os dados são razoavelmente estruturados de modo
a possibilitar processamento automatizado.
6. Não discriminatórios. Os dados são disponíveis para todos, sem exigência de
requerimento ou cadastro.
7. Não proprietários. Os dados são disponíveis em formato sobre o qual nenhuma
entidade detenha controle exclusivo.
8. Livres de licenças. Os dados não estão sujeitos a nenhuma restrição de direito
autoral, patente, propriedade intelectual ou segredo industrial. Restrições sensatas
relacionadas à 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 governamental 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 subnacionais 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 Nova
Zelâ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
2.3 Dados Abertos
33
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 pelo
cidadão.
O governo da Nova Zelândia2 e da Austrália3 criaram seus portais de dados
abertos no ano de 2010. Aquele é um espaço para discussão através de fóruns propostos
pelos cidadãos, enquanto esse encoraja a criação de gadgets e programas de computador
que fazem controle social de todas as informações dentro do portal.
Os Estados Unidos apresentam o plano mais ambicioso com relação aos dados
abertos4 , onde o presidente Barack Obama, no início de seu primeiro mandato, criou
políticas públicas para a promoção da transparência, que incentiva a disponibilização
dos dados públicos em formato aberto. Promovendo o uso de dados abertos em um
nível global, de tal forma que esse governo enviou um memorando a todos os chefes
de 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 de
2009, quando o Comitê de Informação da Presidência da República do Brasil começou
a 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 e
sua equipe de assessores, como uma fonte confiável de dados oficiais, o catálogo foi
disponibilizado ao público em 2010.
Esse catálogo de informações é composto de pouco mais de 1300 séries de dados
históricos, representando 8 anos de registros públicos, que refletem as ações do governo
durante a presidência de Luiz Inácio "Lula"da Silva (2003-2010). Como padrão, a equipe
de 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 árvores
temáticas hierárquicas, que se ramificam a partir de assuntos gerais para assuntos mais
específicos.
1 http://data.gov.uk/,
acessado em junho de 2015
acessado em junho de 2015
3 http://data.gov.au/, acessado em junho de 2015
4 http://www.data.gov/, acessado em junho de 2015
5 http://dados.gov.br/, acessado em junho de 2015
2 https://data.govt.nz/,
2.3 Dados Abertos
2.3.3
34
Dados Abertos Ligados
Uma vez que os dados tenham sido disponibilizados em formato aberto e
utilizem-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, surge
um novo conceito de Linked Open Data (LOD) ou Dados Abertos Ligados (DAL).
Segundo Florian Bauer[36]: “Para se beneficiar inteiramente dos Dados Abertos, é crucial disponibilizar informações e dados em um contexto que crie novos conhecimentos e permita o desenvolvimento de serviços e aplicativos poderosos. Como os DAL
facilitam a inovação e a criação de conhecimento a partir de dados interligados, é um
importante mecanismo de gestão e integração de informações”.
Os dados abertos ligados são capazes de gerar esse conhecimento, uma vez que
esses favorecem a interação entre duas ou mais fontes de informações, permitindo que
relações sejam derivadas entre esses conhecimentos.
A transformação de dados abertos para dados abertos ligados foi melhor descrita
por Berners-Lee ao apresentar um modelo de 5 estrelas para o Governo Eletrônico. Desde
entã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ça
aberta
Informação está disponível como um dado estruturado (e.g. Excel ao invés de
uma 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 que
publicam e para aqueles que consomem DAL, a partir do modelo de 5 estrelas proposto
por Berners-Lee. Esse modelo pode ser observado através de 5 tabelas, correspondendo
cada uma dessas a uma das cinco estrelas do modelo proposto por Berners-Lee. Essas
podem ser observadas a seguir nas Tabelas 2.2 a 2.6
Esse modelo não representa uma definição absoluta, mas apenas uma forma de
visualizar o que os agentes que publicam e que consomem informações podem esperar de
sistemas 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 de
benefícios para trabalhar com os dados, pois esse pode utilizar e mesmo agregar valor a
esses dados.
2.3 Dados Abertos
35
Tabela 2.2: Custos e benefícios do modelo de ? dados web
Como consumidor
Como publicador
Pode vê-lo
É fácil publicar
Pode imprimi-lo
Pode armazená-lo localmente (no seu disco
rígido)
Pode inserir os dados manualmente em outro
sistema
Tabela 2.3: Custos e benefícios do modelo de ? ? dados web
Como consumidor, pode fazer tudo que o Como publicador...
anterior fazia, mais:
Pode processar diretamente com software É fácil publicar.
proprietário para agregá-lo, executar cálculos, visualizá-lo, etc
Pode exportá-lo para outro formato (estruturado).
Tabela 2.4: Custos e benefícios do modelo de ? ? ? dados web
Como consumidor, pode fazer tudo que o Como publicador
anterior fazia, mais:
Não tem que pagar por um formato em que É fácil publicar.
uma única entidade tem controle exclusivo
Tabela 2.5: Custos e benefícios do modelo de ? ? ? ? dados web
Como consumidor, pode fazer tudo que o
anterior fazia, mais:
Pode ligar o dado de qualquer outro lugar,
seja na web ou localmente.
Pode marcá-lo.
Pode reutilizar partes dos dados.
Como publicador
Precisará investir algum tempo dividindo e
separando os dados.
Precisará atribuir URIs para as propriedades
dos dados e pensar em como representar os
dados.
Tem um bom controle granular sobre as
propriedades de dados e pode otimizar o
seu acesso (por exemplo, balanceamento de
carga, cache, etc)
Tabela 2.6: Custos e benefícios do modelo de ? ? ? ? ? dados web
Como consumidor, pode fazer tudo que o
anterior fazia, mais:
Pode descobrir novos dados de interesse ao
consumir outras informações.
Tem acesso ao esquema de dados.
Como publicador
Precisará investir recursos para vincular os
dados com outros dados na Web.
Tornar os dados descobríveis.
Aumenta o valor dos dados.
2.4 Sobre o Capítulo
2.4
36
Sobre o Capítulo
Ao longo deste capítulo, foram apresentados alguns conceitos considerados
relevantes para o desenvolvimento da proposta desse trabalho. O conteúdo apresentado
sobre Modelos de Bancos de Dados, Web Semântica e Dados Abertos apresentou um
caráter introdutório e restrito às necessidades desse projeto.
Dentre os temas tratados neste capítulo, a Web Semântica é aquele com mais
possibilidades, pois implica numa mudança geral de paradigmas da web. Mudanças essas
que permitirão um significativo avanço na capacidade dos computadores atuais tratarem
as informações.
Todo o esforço empregado neste trabalho dedica-se a desenvolver meios que auxiliem na adoção da Web Semântica, através da utilização de bases de dados tradicionais
para formatos abertos com nível de estruturação e semântica.
CAPÍTULO 3
Bases de Conhecimento e suas Ontologias
A forma de representar dados na web, apesar de parecer um conceito muito
simples, carrega uma série de requisitos, pois até o momento a web foi desenvolvida
principalmente em formato não estruturado, onde a semântica dos conceitos dos objetos
do 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 possibilidades
computacionais, existindo uma relação entre a expressividade da linguagem utilizada e a
capacidade de processamento do computador. A Figura 3.1 apresenta uma visão do ganho
de 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 forma
de 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 modelo
atual pouco expressivo, num modelo mais facilmente compreensível pelos computadores.
Ferramentas de anotação semântica, ou vinculação de dados de fontes pouco estruturadas
tê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 Dados
Abertos Ligados intersecta-se com o do RDF, onde um recurso proveniente de uma página
web, um documento de texto plano ou um banco de dados, uma vez anotado pode ser
referenciado para recursos de um outro domínio. Esses domínios muitas vezes possuem
complexas ontologias, representadas em linguagens como a OWL, as quais possuem
definições complexas a respeito de seus recursos e os relacionam com recursos de outros
domínios.
Esses domínios com complexas ontologias, que possuem recursos bem definidos por meio de esquemas de representação em RDF, são chamados de repositórios semânticos. Segundo Kiryakov e Damova[49], repositórios semânticos são sistemas que
combinam características dos sistemas de gerenciamento de banco de dados (SGBD) e
motores de inferência, capazes de lidar com dados estruturados, levando em consideração
sua semântica.
Ao mapear uma fonte de dados qualquer para um formato RDF e vinculá-la
a outros repositórios semânticos, inclui-se essa nova fonte de dados em uma rede de
repositó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 de
evolução para a web, onde as fontes de dados atuais podem ser integradas por meio de
procedimentos de conversão e anotação semântica[11].
A Figura 3.2 apresenta um modelo adaptado da proposta de Berners-Lee para
a integração de bases heterogêneas. Nesse modelo, fontes de dados diversas, sejam elas
fontes não estruturadas, semi-estruturadas ou estruturadas, são trazidas para um formato
de representação em RDF. Esse conjunto de dados em RDF, tomados com ontologias e
acesso de dados por meio de ferramentas como o SPARQL, formam uma camada que
pode 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 semânticos conhecidos, selecionados por critérios, como sua diversidade de conteúdo, integraçã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 de
acesso.
3.1 DBPedia
39
Figura 3.2: Modelo Adaptado de Integração de Dados de BenersLee
3.1
DBPedia
DBPedia[51] é uma base de conhecimento multilinguístico construída em grande
escala para agrupar informações enciclopédicas provenientes do projeto Wikipedia. A
enciclopédia digital Wikipedia é o sexto website mais acessado do planeta1 . Ela possui
versões em mais de 287 idiomas, tendo centenas ou até milhões de artigos em cada uma
de suas edições e está disponível de forma gratuita e aberta.
A maior parte do conhecimento proveniente da Wikipedia encontra-se em formato de texto plano, para servir ao entendimento dos seres humanos. Entretanto a estrutura dessa enciclopédia digital abrange também uma série de informações apresentadas
em formatos estruturados, como tabelas, listas e conteúdo agrupado em estruturas conhecidas 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é-definida
e disponibilizado como um Dado Ligado. A partir disso, a informação semanticamente
categorizada da DBPedia permite que aplicações efetuem consultas com um nível de
complexidade 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ço
colaborativo mundial, onde os membros do projeto não somente mantém o esquema
ontológico, mas criam novas ferramentas de mapeamento entre as enciclopédias. De
forma geral, pode-se dizer que o projeto DBPedia trata-se de um projeto de mapeamento
1 http://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 o
projeto DBPedia trabalha com 111 edições da Wikipedia, disponibilizando as informações
de pelo menos 14 dessas na forma de SPARQL Endpoint.
O projeto DBPedia é possivelmente um dos mais importantes repositórios semânticos existentes, pois tornou-se uma referência para a maioria dos outros, já que uma
grande parte dos repositórios existentes hoje em dia possuem esquemas de mapeamento
de seus modelos para o encontrado na DBPedia. Esse tópico é discutido em mais detalhes
na Seção 3.6.
3.1.1
Ontologia DBPedia
Apesar de ser um projeto para representar semanticamente informação proveniente de qualquer fonte, assim como ser uma referência para a maior parte dos repositórios
semânticos encontrados atualmente, a DBPedia possui uma ontologia relativamente simples. 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, sendo
mantida dessa forma para facilitar o entendimento e para que possa ser visualizada
integralmente, assim como para manter uma estrutura de navegação simples.
Essa ontologia pode ser visualizada de forma integral e on-line através do portal
da DBPedia2 .
3.1.2
Acessando a DBPedia
Como um dos principais projetos de Dados Abertos Ligados do mundo, o projeto
DBPedia 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 de
consultas de usuários, podendo dividir o processamento sobre vários nós do cluster. Notase que, devido ao grande número de dados provenientes desse repositório, existe uma
limitação de trafego que permite a realização de consultas cujo o resultado não exceda
o tamanho máximo de 50000 linhas. Dessa forma, os usuários desse SPARQL Endpoint
geralmente devem utilizar limitadores como OFFSET e LIMIT.
Além de fornecer acesso por meio de consultas SPARQL, a DBPedia possui um
mecanismo de acesso do tipo a Linked Data Hub onde, por meio de requisições HTTP, o
2 http://mappings.dbpedia.org/server/ontology/classes/
3 http://dbpedia.org/sparql
3.2 GeoNames
41
endpoint redireciona o usuário para páginas HTML ou dados em RDF em formatos como
o RDF/XML.
Por fim, é possível a utilização do repositório DBPedia por meio de um sincronizador de dados, que baixa a informação proveniente do endpoint e o armazena no computador 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 atualizando
aquilo 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ível
gratuitamente e em formato aberto.
Segundo informações do próprio GeoNames4 , essa base de dados contém mais
de 10 milhões de nomes geográficos e é composto por mais de 8 milhões de recursos
exclusivos, nos quais 2,8 milhões corresponde a lugares povoados e 5,5 milhões de nomes
alternativos.
O objetivo do projeto GeoNames é integrar dados geográficos, tais como nomes
de lugares em línguas diferentes, altitude, população e outras informações provenientes
de fontes de dados diversas. Trata-se de um projeto desenvolvido por uma comunidade de
usuários, dessa forma o projeto fornece possibilidades de edição manual e correções de
nomes por parte dos usuários do serviço.
As informações de coordenadas do projeto GeoNames são disponibilizadas de
forma aberta em formato WGS845 .
3.2.1
Ontologia GeoNames
O projeto GeoNames apresenta um esquema ontológico simples e aberto de
representação de dados6 , definido sobre uma estrutura de apenas sete classes. Essa
ontologia contém ainda vinte e nove propriedades, sendo treze propriedades de tipos de
dados 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 de
uma divisão espacial de nove tipos, como listados abaixo:
4 http://www.geonames.org/about.html,
acessado em julho de 2014
Geodetic System. Norma usada em cartografia de origem geocêntrica, utilizada principalmente
pelo Sistema de Posicionamento Global - (GPS)
6 http://www.geonames.org/ontology/ontology_v3.1.rdf
5 World
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 das
formas de acesso é o download integral da base de dados do GeoNames por meio de uma
sé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 busca
pré-definida, onde o usuário pode realizar requisições com campos para buscas do nome
do local, locais que começam com o texto, locais que contém o texto, entre outras
possibilidades. Esse Web Service oferece a opção de configuração do formato da resposta
em XML ou JSON.
3.3
WordNet
WordNet[53] é um banco de dados léxico da língua inglesa, em desenvolvimento
pelo Cognitive Science Laboratory da Universidade de Princenton desde 1985. Nesse
dicionário léxico os dados sobre substantivos, verbos, adjetivos e advérbios são agrupados
em conjuntos de sinônimos cognitivos chamados synsets, cada um expressando um
conceito distinto.
A classificação das palavras em synsets ocorre de acordo com o significado dessa
palavra 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ários
synsets.
Além da classificação das palavras em synsets, o WordNet especifica uma série
de relações lógicas entre palavras e synsets. A Tabela 3.1 resume as principais relações
lógicas encontradas na WordNet.
3.4 YAGO2
43
Tabela 3.1: Exemplo de Relações Léxicas na WordNet
Sinônimos
Hiperônimos
Hipônimos
Merônimos
Holônimos
Antônimos
3.3.1
significa o mesmo que
termo geral para
tipo de
parte de
membro de
tem parte
membro
contrário de
Bonito significa o mesmo que belo
Mobília é o termo geral para sofá
Sofá é um tipo de mobília
Galho é parte de uma árvore
Uma pessoa é membro de um grupo
Carro tem a roda como parte
Um grupo tem uma pessoa como membro
Alto é o contrário de baixo
Ontologia WordNet
Apesar de ser um dos repositórios mais utilizados dentro das pesquisas sobre
Web Semântica, a WordNet não foi concebida inicialmente como um RDF/OWL. Muitos
são os trabalhos que consideram técnicas para converter ou tratar os dados provenientes
da WordNet para o formato RDF/OWL, entretanto somente em junho de 2006 o consórcio
w3c 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 de
caracteres existem em mais de uma categoria. De forma que, o total, considerando a
relaçã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.gz
no site oficial da Universidade de Princenton. Além disso, existem SPARQL Endpoints
nã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 de
divisão de fatos, entidade e eventos definidos em termos de tempo e espaço. Essa base de
dados é 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 , tais
como pessoas, organizações, cidades, entre outros. Estima-se que existam cerca de 120
7 http://www.w3.org/TR/wordnet-rdf/,
acessado em julho de 2014
8 http://wordnet.princeton.edu/wordnet/man/wnstats.7WN.html
9 https://www.mpi-inf.mpg.de/departments/databases-and-information-systems/research/yagonaga/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 que
oficialmente possui uma precisão com relação a suas tuplas de cerca de 95% de acurácia
confirmados.
3.4.1
Ontologia YAGO2
YAGO apresenta um modelo próprio de representação de dados, baseado no
RDFS, 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ém
sã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 literais
também são interpretados como entidades.
Como pode ser observado, a entidade dentro desse modelo corresponde a um
conceito 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 subdivisão de entidades comuns e entidades individuais. A primeira corresponde a entidades que
não são nem fatos e nem relações. A segunda corresponde a uma entidade comum que
també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 de
relaçõ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.000
classes, 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 do
em formatos de texto ttl e tsv. Além disso YAGO2 oferece uma interface web de
projeto10
10 https://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 navegar
pela ontologia do YAGO2 utilizando um browser de ontologias disponível no site oficial
do projeto. A partir de novembro de 2014, foi disponibilizado um SPARQL Endpoint para
acessar 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 do
conhecimento humano em geral. Seus dados são criados, estruturados e mantidos de
forma colaborativa. Freebase foi desenvolvido pela Metaweb Tecnologies e foi adquirido
pela Google em 2010.
A ideia por trás do Freebase é tenta mesclar a escalabilidade de bases de dados
estruturadas, com a diversidade de wikis colaborativos em uma base de conhecimento
humano de propósito geral. Esse projeto visa à praticidade, fornecendo interfaces e
ferramentas que permitam a usuários leigos o uso imediato, tanto para consultar quanto
para contribuir com adição de novos dados.
Cita-se ainda que o Freebase possui uma filosofia da normalização completa dos
dados. Ao contrário de alguns bancos de dados, as entidades Freebase são construídas
para ser explicitamente únicas. Ou seja, deve haver apenas um GUID em Freebase
representante 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 dados
são carregados por ferramentas de extração automáticas, alguns enviados a granel, quer
pela equipe de Dados da Metaweb Tecnologies ou pela comunidade de colaboradores,
utilizando API ou outras ferramentas de carregamento de dados. Existe ainda uma parcela
de dados que são adicionados manualmente pedaço por pedaço por indivíduos que
simplesmente usam o site oficial.
3.5.1
Ontologia Freebase
Freebase não possui uma ontologia que o defina, ao invés disso esse projeto
utiliza um metaesquema de descrição das suas propriedades. Esse metaesquema define
um método simples para explorar o conteúdo do banco de dados na forma de caminhos
entre categorias.
Como um exemplo de caminho válido dentro do metaesquema do Freebase citase /film/director/film. Através desse caminho, o metaesquema interpreta a solicitação feita
como 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 fatos
divididos em cerca de 77 categorias11 .
3.5.2
Acessando o Freebase
Apesar de não possuir uma ontologia que o defina, Freebase oferece a possibilidade 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ções
HTTP a uma API de consultas programáticas numa linguagem especial chamada MQL.
MQL significa Metaweb Query Language, trata-se de um formato de consulta semelhante
ao SPARQL desenvolvido especificamente para consultas ao Freebase. Essa API utiliza o
formato 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 que
esses dados, geralmente localizados em repositórios semânticos, devem possuir ligações
entre si. Essas ligações, principalmente aquelas que expressam relações de igualdade
entre classes e entidades das ontologias que definem esses repositórios, são de grande
importância. A partir do momento que uma entidade ou classe é definida como possuindo
uma relação de igualdade com uma entidade ou classe de um outro repositório, a mesma
passa 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 os
repositórios, quanto maior o número de ligações entre os repositórios, maior será a
expressividade 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 os
repositórios semânticos, pois essas são demasiadamente numerosas. Tomando como
exemplo a DBPedia, um repositório de referência dentro da nuvem semântica, é possível
observar 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órios
referenciados, na segunda coluna apresenta-se o predicado utilizado para ligar a entidade
DBPedia ao repositório externo. Por fim, na terceira coluna, apresenta-se o número de
ligações existentes.
11 Nú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
Amsterdam Museum
BBC Wildlife Finder
Book Mashup
Predicados
owl:sameAs
owl:sameAs
rdf:type
owl:sameAs
Bricklink
dc:publisher
CORDIS
owl:sameAs
Dailymed
owl:sameAs
DBLP Bibliography
owl:sameAs
DBTune
owl:sameAs
Diseasome
owl:sameAs
Drugbank
owl:sameAs
EUNIS
owl:sameAs
Eurostat (Linked Stats) owl:sameAs
Eurostat (WBSG)
owl:sameAs
CIA World Factbook
owl:sameAs
flickr wrappr
dbp:hasPhotoCollection
Freebase
owl:sameAs
GADM
owl:sameAs
GeoNames
owl:sameAs
GeoSpecies
owl:sameAs
GHO
owl:sameAs
Project Gutenberg
owl:sameAs
Italian Public Schools
owl:sameAs
LinkedGeoData
owl:sameAs
LinkedMDB
owl:sameAs
MusicBrainz
owl:sameAs
New York Times
owl:sameAs
OpenCyc
owl:sameAs
OpenEI (Open Energy) owl:sameAs
Revyu
owl:sameAs
Sider
owl:sameAs
TCMGeneDIT
owl:sameAs
UMBEL
rdf:type
US Census
owl:sameAs
WikiCompany
owl:sameAs
WordNet
dbp:wordnet type
YAGO2
rdf:type
Somatório
Quantidade
627
444
9100
10100
314
894
196
838
2 300
4 800
3 100
253
137
545
3 800 000
3 600 000
1 900
86 500
16 000
196
2 500
5 800
103 600
13 800
23 000
9 700
27 100
678
6
2 000
904
896 400
12 600
8 300
467 100
18 100 000
27 211 732
3.7 Sobre o Capítulo
48
Tabela 3.3: Os 10 repositórios com mais ligações para a
DBPedia[51]
URL do Repositório
okaboo.com
tfri.gov.tw
naplesplus.us
fu-berlin.de
freebase.com
geonames.org
opencyc.org
geospecies.org
dbrec.net
faviki.com
Quantidade de Predicados
4
57
2
7
108
3
3
10
3
5
Quantidade de Ligações
2,407,121
837,459
212,460
145,322
138,619
125,734
19,648
16,188
12,856
12,768
É possível realizar a análise inversa também, onde analisa-se os repositórios que
possuem uma ligação com a DBPedia. Na Tabela 3.3, apresenta-se os 10 repositórios
com maior número de ligações com a DBPedia. Na primeira coluna, tem-se o URL do
repositório, na segunda coluna o número de predicados distintos usados para referenciar
elementos da DBPedia. Por fim, na terceira coluna, a quantidade de ligações.
3.7
Sobre o Capítulo
Ao longo deste capítulo, foram apresentados alguns dos repositórios semânticos
mais 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 formato
aberto e fornecer acesso por requisições HTTP, Web Services ou SPARQL Endpoint, o
mais importante dessas informações é que elas relacionam-se entre si. Os conceitos de
um 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 o
mapeamento é total, ou seja, todas as entidades do repositório são mapeadas, como no
caso do YAGO com a WordNet. Essa interligação entre os repositórios demonstra o
quanto o paradigma de vinculação dos dados está presente dentro da Web Semântica.
CAPÍTULO 4
Trabalhos Relacionados
Os trabalhos apresentados nessa seção objetivam solucionar o mesmo problema
proposto nessa pesquisa. As abordagens utilizadas pelo autores de cada um desses
trabalhos 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ção
e definição dos elementos mapeados.
Em seguida, é apresentada uma ferramenta que usa um complexo esquema de
mapeamento, utilizando um banco de dados externo e a inserção de scripts de mapeamento por parte do usuário. Os demais trabalhos desse capítulo buscam similaridades
entre cadeias de caracteres, presentes entre as ontologias e os banco de dados, cada um
apresentando uma abordagem diferente e chegando a diferentes tipos de resultados.
4.1
Morph RDB
Morph-RDB[66] é um processador de mapeamento R2RML, desenvolvido em
Scala, pelo Ontology Engineering Group1 como continuação do projeto ODEMapster2 .
Seu principal objetivo é realizar o mapeamento de bancos de dados relacionais
para representações em RDF usando o mapeamento R2RML. R2RML é uma linguagem
para expressar mapeamentos personalizadas a partir de bancos de dados relacionais para
um conjuntos de dados RDF. Esses mapeamentos fornecem a capacidade de visualizar
dados relacionais existentes no modelo de dados RDF, expressa em uma estrutura e
vocabulário alvo da escolha do autor do mapeamento.
Morph-RDB trabalha com dois modos básicos de operações, a atualização de
dados e a tradução de consultas. No primeiro, acontece a geração de dados RDF a partir
1 http://www.oeg-upm.net/,
acessado em junho de 2015
2 http://mayor2.dia.fi.upm.es/oeg-upm/index.php/en/downloads/9-r2o-odempaster,
de 2015
acessado em junho
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 sobre
um conjunto de dados RDF virtual criados a partir do banco relacional de origem, as
consultas são reescritas em SQL, de acordo com as descrições de mapeamento R2RML.
Esse framework trabalha com sistemas de gerenciamento de banco de dados
relacionais como MySQL, PostgreSQL e MonetDB. Recentemente, foi realizada uma
extensã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 dados
relacionais e ontologias pode ser observado no RDOTE[77]. Essa é uma ferramenta
gráfica para definição manual de esquemas de mapeamento de banco de dados, onde o
SQL é usado como meio para especificação do subconjunto de dados que serão mapeados
para instâncias de classes em ontologias.
RDOTE se conecta a um sistema gerenciador de banco de dados relacional, do
mesmo modo que carrega uma ontologia de destino desejado. O usuário então escreve
consultas 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 uma
classe 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 de
mapeamento.
Existe uma etapa opcional no processo de execução do RDOTE onde o usuário
pode definir opções de renomeação e junção de cadeias de caracteres para os casos de
consultas que selecionam dados de múltiplas colunas.
O usuário então realiza uma etapa de conexão de consultas com classes da
ontologia, desta forma, para cada tupla de uma consulta SQL, uma instância da respectiva
classe é criada. Caso se deseje utilizar os dados reais, em vez de apenas criar URIs, o
RDOTE oferece a possibilidade de copiar as informações reais das tuplas numa série de
possíveis formatos.
Uma vez realizadas as conexões entre as consultas SQL do usuário com as
classes da ontologia é possível estabelecer ligações condicionais do mapeamento com
outros mapeamentos, por meio de propriedades do objeto ou, no caso de propriedades de
tipo de dados com consultas SQL. Todo esse processo é realizado utilizando um esquema
simples 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 classes
da 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 pode
ser 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. Considerado
uma das mais famosas ferramentas para mapear esquemas de banco de dados relacionais
para ontologias, esse framework apresenta um mecanismo complexo para realizar o
mapeamento utilizando um banco de dados externo com um esquema pré-definido para
armazenar os dados da ontologia e do banco de dados que se deseja mapear.
Esse esquema de banco de dados é, de fato, um meta esquema desenvolvido
especificamente para realizar esse processo de mapeamento. Na Figura 4.1 é possível
observar 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 bancos
de dados de domínios correlatos. As informações dos bancos de dados são armazenadas
em 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 e
owl_datatype_property. Os mapeamentos são especificados nos registros das tabelas
class_map, object_property_map, datatype_property_map.
O usuário então introduz as informações de mapeamento a partir do qual os
scripts 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 que
elas representam, se representam entidades ou relacionamentos entre entidades.
Vetores de coeficientes, chamados documentos virtuais, são construídos para
cada relação e atributo do esquema de banco de dados. A descrição de uma relação leva
em conta a descrição de relações ligadas a ela através de chaves estrangeiras, enquanto a
descrição dos atributos incorpora a descrição da sua relação pai e outras relações ligadas a
este último. Da mesma forma, os documentos virtuais para todas as classes e propriedades
da ontologia são construídos e similaridades existentes entre os elementos do esquema de
banco de dados e da ontologia são calculados como pares de distância cosseno de seus
vetores de identificação. Em outras palavras, MARSON interpreta o esquema relacional
como um gráfico e utiliza a teoria matemática fundamental para interpretá-lo.
MARSON é um projeto que visa automatizar completamente o processo de
descoberta de mapeamentos entre um banco de dados relacional e uma determinada
ontologia. Como tal, esse projeto se assenta no pressuposto de proximidade lexical entre
nomes de elementos do banco de dados e da ontologia durante o cálculo dos coeficientes
de similaridade e no pressuposto da existência de um número suficiente de indivíduos na
ontologia, 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 ontologias
e bancos de dados relacionais, onde são estabelecidas medidas de similaridade entre
elementos estruturais correspondentes de um banco de dados e uma ontologia. Dessa
forma os conceitos de relação, chave estrangeira e não estrangeira de atributos do banco
de 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ão
depois validadas pelo usuário.
4.6 AuReLi
4.6
53
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 ontologias e tabelas de um banco de dados relacional. Difere de outras abordagens por utilizar
diversas medidas de similaridade para comparar atributos e relações provenientes de bancos de dados relacionais com as propriedades e classes de uma ontologia especificadas a
priori.
Um outro fato importante sobre o AuReLi é que essa ferramenta busca a
vinculação dos dados provenientes do banco de dados com as instâncias da ontologia
através de um sistema de consultas pré-definidas de associação entre essas e entidades da
DBPedia. Os resultados do algoritmo, em seguida, são apresentados ao utilizador humano
para validação. AuReLi é implementado como uma extensão D2R Linked Server3 com
acesso a dados utilizando SPARQL.
4.7
StdTrip
StdTrip[69] é uma ferramenta de triplificação, ou seja, uma ferramenta que
trabalha com a conversão de bancos de dados relacionais para triplas RDF. A proposta
principal do StdTrip é promover um mecanismo de reutilização de vocabulários padrões
existentes.
Nessa proposta, é realizada a suposição implícita de que o banco de dados de
entrada está totalmente normalizado, ou seja, supõem-se que as entradas para a ferramenta
atendam os critérios da terceira forma normal. Essa ferramenta apresenta a característica
de considerar que o usuário do sistema tem algum conhecimento sobre o domínio da
aplicação das bases de dados tratadas.
O processo de reutilização de vocabulários proposto pelo StdTrip, é dividido em
seis etapas, resumidas a seguir:
1. Conversão. Esta etapa consiste em transformar a estrutura do banco de dados
relacional para uma ontologia RDF. Nesse ponto, o designer pode confiar em
abordagens como a proposta pelo W-Ray[61].
2. Alinhamento. Este passo utiliza uma ferramenta de alinhamento para fazer a
ontologia, obtida no Passo 1, corresponder a um conjunto de vocabulários padrões
configurados na ferramenta. Esta operação fornece, para cada elemento do esquema
3 http://d2rq.org/d2r-server,
acessado em junho de 2015
4.8 MASTRO
3.
4.
5.
6.
4.8
54
(tabela ou atributo) uma lista de possíveis correspondências. Por exemplo, uma
tabela chamada Pessoa seria combinadas para foaf: maker ou dc: creator[21].
Seleção. Esta etapa apresenta ao usuário uma lista de possibilidades de que ele ou
ela selecione o elemento do vocabulário que melhor representa cada conceito na
base de dados.
Inclusão. Se para um determinado elemento, o processo não produz qualquer
resultado (não há nenhum elemento nos vocabulários conhecidos que coincide com
o conceito de banco de dados), ou nenhuma das sugestões na lista é considerada
adequada pelo usuário, StdTrip fornece uma lista de triplas de outros vocabulários
que poderia ser uma possível combinação. O raciocínio é o seguinte “se o seu
conceito não está abrangido por qualquer dos padrões conhecidos, olhe em volta
e 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 um
novo vocabulário. ”
Conclusão. Se nada funciona, os usuários são direcionados para o Best Practice
Recipes for Publishing RDF Vocabularies[13].
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 ontologia
que contém os mapeamentos do esquema de banco de dados original para o
vocabulários padrão RDF.
MASTRO
MASTRO[23] é uma ferramenta desenvolvida na linguagem de programação
JAVA, criado na Universidade de Roma “La Sapienza” e na Universidade Livre de BozenBolzano. Essa ferramenta foi desenvolvida com o objetivo de gerenciar sistemas de acesso
a dados baseados em ontologias ( Ontology-Based Data Access - ODBA ).
A ideia dessa ferramenta consiste em descrever uma ontologia num formato
derivado do DL-Lite e expressar sentenças genéricas da lógica de primeira ordem. Dessa
forma MASTRO é uma estrutura que permite a definição de mapeamentos entre um
banco de dados relacional e uma ontologia e a emissão de consultas conjuntivas expressas
em EQL, uma linguagem semelhante ao SQL. Dessa forma, MASTRO é uma suíte de
ferramentas de acesso a dados de base ontológica que reformula uma consulta conjuntiva
expressa através de uma ontologia para uma consulta SQL que é avaliada sobre um
banco de dados relacional. Existem também nessa aplicação algoritmos otimizados para
responder a consultas expressivas, bem como possui um sistema para recursos verificação
da consistência das requisições.
4.9 Resumo dos Sistemas Analisados
55
MASTRO fornece uma API proprietária, mas também possui uma interface
compatí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 sistemas de mapeamento tratados nesse capítulo. Na Tabela 4.1, alguns critérios são utilizados
para analisar as características desses sistema.
Tabela 4.1: Resumo Trabalhos Relacionados
Sistema
Funcionamento
MorphRDB Manual não sintático sem ontologia
RDRoute
Manual não sintático sem ontologia
RDB2OWL Manual não sintático com ontologia
Marson
Automático sintático com ontologia
Ronto
Semiautomático
sintático
com
ontologia
AuReLi
Automático sintático com ontologia
StdTrip
Manual não sintático sem ontologia
Mastro
Restrição
-
Relacional NoSQL
Sim
Não
Integrado
Não
-
Sim
Não
Não
-
Sim
Não
Não
-
Sim
Não
Não
-
Sim
Não
Não
-
Sim
Não
Parcial
Banco de Sim
dados na
3a forma
normal
Manual não sintá- Ontologia Sim
tico com ontologia em DLLite
Não
Não
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 realiza 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 ( ferramenta gera o mapeamento sem a intervenção do usuário ). O método de análise
da ontologia e do banco de dados, é divido em não sintático, não analisa lexicograficamente por meio de alguma medida matemática a relação entre elementos da
ontologia e do banco de dados, e sintático, o qual possui essa análise lexicográfica
4.10 Sobre o Capítulo
3.
4.
5.
6.
56
com algum tipo de coeficiente de similaridade. O terceiro item dessa coluna referese à 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 uma
ontologia 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 qual
o banco de dados é mapeado.
Restrição. apresenta alguma exigência do sistema.
Relacional. indica se o sistema tem suporte ao mapeamento de bancos de dados do
tipo relacional.
NoSQL. indica se o sistema tem suporte ao mapeamento de bancos de dados do
tipo NoSQL.
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 de
integração de dados, onde os resultados são validados com a DBPedia.
4.10
Sobre o Capítulo
Ao longo deste capítulo, foram descritos trabalhos relacionados com a ferramenta proposta nessa dissertação, algumas dessas ferramentas trabalhando em processos
de mapeamento de bancos de dados para ontologia de forma manual e outras de forma
automática ou semiautomática.
Entretanto, esses trabalhos dedicam-se exclusivamente ao mapeamento de banco
de dados relacionais para ontologias específicas. Não existe uma preocupação em desenvolver um método que sirva tanto para mapear os bancos de dados relacionais quanto os
bancos de dados NoSQL. Além disso, esses trabalhos tem como foco o simples mapeamento do banco de dados para uma ontologia. Não existe uma preocupação em relacionar
esse dado à nuvem semântica, tornando assim a informação um verdadeiro Dado Aberto
Ligado.
CAPÍTULO 5
Solução Proposta
Como observado até o presente momento, o ato de mapear um banco de dados
para 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 abordagens. A primeira consiste em gerar ontologias a partir de bancos de dados relacionais, a
segunda de mapear bancos de dados relacionais para uma ontologia preexistente.
Dentre essas duas abordagens, a segunda permite tratar um conjunto de bancos
de 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. Ao
criar 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 fornecer
uma descrição mais exata do conhecimento, eliminando ambiguidades e assim facilitando
o compartilhamento do conhecimento.
As soluções propostas até o momento apresentam limitações, tanto no que diz
respeito ao seu objetivo ao limitar-se aos bancos de dados relacionais, quanto ao fato de
que se restringem a realizar o mapeamento isolado entre os bancos de dados e a ontologia
sem se preocupar em relacionar esses bancos no contexto da Web Semântica como um
dado aberto ligado.
Pouca atenção foi dispensada até o momento para estabelecer esquemas de
mapeamento para bancos de dados NoSQL. Essa postura se justifica na medida que os
bancos 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êm
ganhando espaço nos últimos anos, em detrimento dos relacionais em alguns cenários
particulares.
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 dados
com o de outros repositórios semânticos representa a complementação do conteúdo dessas
bases de forma semântica. Essa complementação do conteúdo semântico representa uma
forma dinâmica de expandir o conhecimento do banco de dados.
5.1 Mapeamento Semântico de Banco de Dados
5.1
58
Mapeamento Semântico de Banco de Dados
Ao definir o objetivo desse trabalho, na Seção 1.2, apresentou-se uma definição
da palavra mapeamento. Em seguida, apresentou-se como principal objetivo desse trabalho o processo de mapeamento entre um conjunto de bancos de dados e uma ontologia de
referência.
Um banco de dados é uma forma de representação de dados, assim como tantos
outros formatos existentes que apresentam uma semântica implícita. Mapear um banco
de dados para uma ontologia, consiste na tentativa de apresentar os dados segundo um
formato que favoreça a apresentação desse dados de forma que a semântica, ou seja, o seu
significado, se torne explícito.
Ontologia é uma forma de representação de informação que favorece a descrição
do significado das coisas, não somente para o ser humano, mas também para o computador.
O título desse trabalho, Mapeamento Semântico de Banco de Dados, refere-se ao
ato de tornar os bancos de dados analisados melhores descritos semanticamente. A Figura
5.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 uma
ontologia. Nesse processo, são estabelecidos relacionamentos entre cada tabela do banco
de 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 as
definições presentes na ontologia.
5.2 Etapas da Solução
59
Ao conseguir estabelecer uma relação entre um modelo de dados simples, como
o 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 apresentem uma coincidência de domínios, total ou parcial. Em outras palavras, o banco de
dados mapeado para a ontologia de referência deve representar um domínio, ao menos
próximo, do domínio tratado na ontologia. Não faz sentido, por exemplo, tentar mapear
um banco de dados que trate de um domínio como ecologia, para uma ontologia que trate
de um domínio como mecânica de automóveis.
A solução apresentada nesse capítulo, consiste na proposta para realizar o dito
Mapeamento Semântico de Banco de Dados.
5.2
Etapas da Solução
A solução proposta nesse trabalho para o mapeamento semântico de bancos
de dados divide-se em duas etapas. Na primeira parte, define-se um mecanismo para
estabelecer 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 de
referê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 um
mapeamento entre os elementos que definem um banco de dados segundo uma ontologia 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 em
dois tipos. O primeiro tipo, chamado agrupador primário, representa a forma de agrupamento de informação mais geral, o que corresponde às classes da ontologia. O segundo
tipo, chamado agrupador secundário, corresponde à uma estrutura de agrupamento mais
detalhada, tomada como as propriedades de uma classe da ontologia.
A Tabela 5.1 apresenta essa forma de dividir os dados, tomados pelo paradigma
de banco de dados que os definem.
Como pode ser observado na Tabela 5.1, a divisão em dois níveis da informação
está presente em todos os paradigmas de bancos de dados. No caso do paradigma ChaveValor, a chave representa tanto o agrupador primário quanto o secundário, pois a maioria
desses bancos possui uma estrutura de chaves do tipo tipo-de-objeto:id-do-objeto:campodo-objeto, por exemplo user:21:username.
5.2 Etapas da Solução
60
Tabela 5.1: Modos de agrupamento de dados por paradigma de
banco de dados
Paradigma
Relacional
Orientado a Objetos
Chave-Valor
Orientado a Colunas
Orientado a Documentos
Orientado a Grafos
Agrupador Primário
Tabelas
Classes de Objeto
Chaves
Família de Colunas
Coleções
Nós
Agrupador Secundário
Colunas
Propriedades de Objeto
Chaves
Colunas
Atributo
Arestas
No caso dos bancos orientados a objetos, o que representa a classe e a propriedade do objeto depende do tipo de implementação do banco. Nos casos de bancos do tipo
objeto-relacional, esses correspondem às próprias tabelas e colunas.
Neste trabalho, o termo elementos do banco de dados, refere-se aos agrupadores
primá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 mapeamento
entre classes e propriedades da ontologia com os elementos provenientes do banco de
dados analisado, realiza-se uma classificação sintática dos nomes desses elementos e
das classes e propriedades provenientes da ontologia. Nesse processo, é possível utilizar
bases de conhecimento específicas para realizar essas classificações, tais como a base de
conhecimento da WordNet.
Uma vez realizada a classificação sintática das classes e propriedades da ontologia e dos elementos do banco de dados, é possível definir candidatos dentro dos bancos
de 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 ser
mapeada para uma tabela desse banco. Da mesma forma, em um banco de dados orientado
a documentos, a própria estrutura conhecida como coleção de documentos poderia ser
observada 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 do
banco de dados e a classe ou propriedade da ontologia. A Tabela 5.2 apresenta algumas
possibilidades com relação à definição de candidatos entre banco de dados e ontologia.
5.2 Etapas da Solução
61
Tabela 5.2: Relação entre synsets da ontologia com synsets do
banco de dados
Relação
Sinônimos
Hiperônimos ou Hipônimos
Merônimos ou Holônimos
Antônimos
É um candidato?
Possível candidato. Nesse caso, observa-se também na ontologia propriedades owl:sameAs,
owl:equivalentClass, owl:equivalentProperty
Possível candidato. Elemento do banco pode ser definido com um termo mais ou menos geral que o da
ontologia. Vale também observar propriedades como
rdfs:subClassOf e rdfs:subPropertyOf
Possível candidato. Elemento pode representar parte
de uma correspondente classe ou propriedade da ontologia.
Não forma um candidato, mas observa-se propriedades como owl:inverseOf
Ontologias são formas de representar conhecimento, assim como esquemas
de bancos de dados. No ato de mapear elementos do banco de dados para classes e
propriedades da ontologia deve-se considerar a possibilidade de uma agrupador primário
do banco de dados representar mais de uma classe da ontologia e vice-versa, por isso
relaçõ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 classes
e propriedades da ontologia são definidas dentro do banco de dados, formando conjuntos
de candidatos. Busca-se então refinar esses resultados realizando operações de álgebra de
conjuntos.
Tomando como exemplo o caso de um banco de dados relacional, as colunas de
uma tabela podem ser vistas como as partes ou características da entidade representada
pela 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. O
computador não dotado dessa capacidade cognitiva, carece de um mecanismo para tornar
explícitas essas relações.
Filtrando Candidatos
Inicialmente, define-se os candidatos na ontologia para representar os agrupadores primários e secundários do banco de dados. A seguir, sabendo-se das relações que
podem existir entre os candidatos a classes, com os correspondentes candidatos a propriedades, realiza-se um processo de filtragem dos candidatos, considerando-se as relações
entre esses candidatos.
O próximo passo é eliminar os elementos que não possuam uma relação correspondente a nenhum dos elementos do outro conjunto de candidatos. Dessa forma, elimina-
5.2 Etapas da Solução
62
se tabelas candidatas a uma classe da ontologia que não possua nenhuma coluna candidata
a propriedade da ontologia sobre a referida classe. Da mesma forma, elimina-se colunas
candidatas a uma propriedade da ontologia, onde a tabela correspondente não seja candidata a nenhuma classe da ontologia que possua essa propriedade. A Figura 5.2 representa
essa relação. Serão eliminadas da lista de candidatos a entidade da tabela o elemento B e
da 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 o
entendimento do processo. A Figura 5.3 apresenta uma situação hipotética. Em um banco
de dados existe uma tabela cadposto a qual deseja-se mapear para uma ontologia. Através
do processo descrito nas seções anteriores, infere-se as palavras que deram origem ao
nome da tabela cadposto. Na análise, ignorou-se o prefixo cad considerando-se somente
a palavra posto, sendo essa uma palavra válida da língua inglesa.
Figura 5.3: Processo de Associação do Banco de Dados com Ontologia de Referência
Em seguida, associa-se essa palavra, posto, com os nodos da ontologia chamados cargo e estabelecimento. A associação ocorre, pois esses nodos possuem nomes que
5.2 Etapas da Solução
63
são sinônimos da palavra posto. Entretanto, a tabela cadposto possui colunas chamadas
lati e long, as quais foram mapeadas como possíveis candidatas às propriedades latitude_estabelecimento e longitude_estabelecimento da ontologia. Não foi estabelecida nenhuma relação de candidato entre uma propriedade da classe cargo com colunas da tabela
cadposto, pois as colunas da tabela cadposto não apresentaram similaridades léxicas com
as propriedades da classe cargo, logo o candidato cargo é eliminado da lista de possíveis
correspondências na ontologia com a tabela cadposto.
Esse procedimento é realizado entre a tabela e cada coluna, formando vários
conjuntos de relacionamentos entre a tabela e suas colunas. Seleciona-se a relação entre
classe da ontologia com a tabela do banco de dados, que possuir maior número de relações
entre propriedades da ontologia com colunas do banco de dados correspondente. A Figura
5.4 representa essa situação, onde os conjuntos T1 , T2 , ..., Tn representam subconjuntos
de candidatos a entidades da tabela provenientes do conjunto original e os conjuntos
C1 ,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 a
entidades da tabela: TR = T1 ∩ T2 ∩ ... ∩ Tn . Dessa forma, tem-se um conjunto resultante
somente com aqueles possíveis candidatos que possuírem pelo menos uma relação com
cada conjunto de candidatos a entidade da coluna.
Após executadas as etapas descritas anteriormente, espera-se que a maioria das
tabelas 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. Conforme
descrito no apêndice B, os relacionamentos entre indivíduos de classes de ontologias
ocorrem por meio de propriedades de objetos. Nos bancos de dados, os relacionamentos
entre tabelas ocorrem por chaves estrangeiras, relações de herança entre outros critérios,
dependendo do paradigma de banco de dados analisado.
5.2 Etapas da Solução
64
Pode-se realizar uma série de consultas à base de conhecimento, utilizando como
sujeito e objeto da relação combinações de pares de entidades provenientes dos conjuntos
de candidatos existentes entre ambas as tabelas.
Após todas as etapas descritas anteriormente, se ainda restarem múltiplos candidatos 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 a
ontologia, torna-se possível relacionar os elementos do banco de dados com classes e
entidades de outros repositórios semânticos. Dessa forma, o dado proveniente do banco
de dados pode ser utilizado com dados provenientes de outras fontes com informações
complementares.
A fim de entender como seria esse processo de complementação dos resultados
provenientes 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 entidades
de outros repositórios semânticos, tais como a DBPedia, descobre-se que esses nomes
correspondem aos verdadeiros nomes de alguns cantores famosos. Dessa forma é possível
derivar uma nova coluna “Apelido”, obtida a partir das propriedades givenName da
ontologia da DBpedia.
Tomando um segundo exemplo, apresentado na Figura 5.6. Considerando uma
tabela “Atores”, contendo três colunas. A primeira coluna chamada “Doutor”, a segunda
5.2 Etapas da Solução
65
chamada “Interpretado Por” e a terceira “Duração”. Através do relacionamento entre os
elementos dessa tabela com as entidades de outros repositórios, descobre-se tratar-se
de atores que interpretaram o personagem Doctor Who, na série de ficção científica de
mesmo nome. Entretanto, observa-se que existem apenas dez linhas nessa tabela. Pode-se
assim derivar uma nova linha correspondente ao décimo primeiro ator que interpretou o
personagem na série.
Figura 5.6: Complementação de Linhas
Todo esse processo de mapeamento, entre o banco de dados representado sobre
a ontologia e os repositórios semânticos, acontece por buscas de similaridade de conteúdo
entre os elementos do banco de dados referenciado sobre a ontologia e categorias definidas
previamente 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, utilizando
ontologias com centenas ou até milhares de classes e propriedades. Esses modelos por
sua vez podem ser utilizados para definir milhões de entidades, geralmente relacionadas
utilizando triplas RDF que interconectam essas entidades fornecendo um dado descrito
com uma riqueza de detalhes que muitas vezes não é encontrada nos bancos de dados
convencionais.
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-
5.2 Etapas da Solução
66
lizadas por um usuário com algum conhecimento, mesmo superficial, sobre o repositório
analisado.
Essas definições simplificadas de elementos presentes nos repositórios são definidas nesse trabalho como categorias. Categorias são palavras chaves utilizadas para
acessar uma lista de consultas descritas em SPARQL a repositórios semânticos diversos
cujo 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 o
significado dessa palavra. Droga é uma palavra polissêmica, possui vários possíveis
significados, sendo o mais utilizado aquele relativo a substâncias entorpecentes, apesar
de também ser utilizado para produtos da indústria farmacêutica.
No repositório semântico da DBPedia, uma droga, adotando o significado
de produto farmacêutico, pode ser definida como uma entidade que forme uma
tripla RDF com a propriedade de objeto rdf:type relacionando-se com a classe
http://dbpedia.org/ontology/Drug do repositório DBPedia. Dessa forma, o mapeamento
do conceito para esse repositório poderia ser estabelecido utilizando uma consulta
SPARQL como a apresentada no Código 5.1.
Código 5.1 Consulta SPARQL a DBPedia
PREFIX owl : < h t t p : / / www. w3 . o r g / 2 0 0 2 / 0 7 / owl #>
PREFIX x s d : < h t t p : / / www. w3 . o r g / 2 0 0 1 / XMLSchema#>
PREFIX r d f s : < h t t p : / / www. w3 . o r g / 2 0 0 0 / 0 1 / rdf−schema #>
PREFIX r d f : < h t t p : / / www. w3 . o r g / 1 9 9 9 / 0 2 / 2 2 − rdf−s y n t a x −n s #>
PREFIX : < h t t p : / / d b p e d i a . o r g / 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 r g / 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 r g / >
SELECT ? e n t i t y
WHERE {
? e n t i t y r d f : t y p e < h t t p : / / d b p e d i a . o r g / o n t o l o g y / Drug > .
}
O conceito de droga, no contexto de produto farmacêutico, pode ser mapeado
também para outro repositório semântico como o Dailymed. Esse repositório apresenta
uma lista dos medicamentos comercializados nos Estados Unidos da América. Nesse
5.2 Etapas da Solução
67
repositório, uma droga pode ser definida como uma entidade que forme uma tripla
RDF com a propriedade de objeto rdf:type relacionando-se com a classe http://wifo504.informatik.uni-mannheim.de/dailymed/resource/dailymed/drugs.
Dessa forma, o mapeamento do conceito para esse repositório poderia ser feito
atravé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 . u n i −mannheim . de
/ dailymed / 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 . u n i −mannheim . de /
dailymed / r e s o u r c e / >
PREFIX r d f s : < h t t p : / / www. w3 . o r g / 2 0 0 0 / 0 1 / rdf−schema #>
PREFIX d 2 r : < h t t p : / / s i t e s . w i w i s s . 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 . r d f #>
PREFIX map : < f i l e : / C : / a p p s / d a i l y m e d / d a i l y m e d . n3 #>
PREFIX owl : < h t t p : / / www. w3 . o r g / 2 0 0 2 / 0 7 / owl #>
PREFIX x s d : < h t t p : / / www. w3 . o r g / 2 0 0 1 / XMLSchema#>
PREFIX r d f : < h t t p : / / www. w3 . o r g / 1 9 9 9 / 0 2 / 2 2 − rdf−s y n t a x −n s #>
PREFIX d a i l y m e d : < h t t p : / / wifo5 −04. i n f o r m a t i k . u n i −mannheim . de /
dailymed / r e s o u r c e / dailymed / >
SELECT ? e n t i t y
WHERE {
? e n t i t y r d f : t y p e < h t t p : / / wifo5 −04. i n f o r m a t i k . u n i −mannheim . de /
dailymed / r e s o u r c e / dailymed / drugs > .
}
O mesmo conceito pode ser definido em diferentes repositórios, cada um desses
repositórios podendo trabalhar aspectos particulares daquele conceito em maior ou menor
escala.
Resumidamente, nesse trabalho o termo categorias correspondem a palavras
chaves utilizadas para acessar uma lista de consultas SPARQL com as definições daquela
palavra chave em repositórios semânticos específicos.
As categorias utilizadas na solução desse trabalho são armazenadas nas tuplas de
um banco de dados SQLite. Além do nome da categoria são definidos também para cada
categoria uma consulta SPARQL e o endereço do SPARQL Endpoint utilizado.
5.2 Etapas da Solução
68
Definidas as categorias utilizadas para associar elementos do banco de dados
com repositórios semânticos, resta agora realizar a associação entre bancos de dados e
repositórios semânticos.
Analisando Agrupadores Primários
O primeiro passo consiste em realizar uma leitura dos agrupadores primários do
banco de dados sendo analisado. Nesse processo, busca-se encontrar sinônimos para as
palavras utilizadas pelo projetista de banco de dados para definir os agrupadores primários
do 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 definida
similarmente utilizando a palavra cidade ao invés de município.
Sabendo que muitas vezes projetistas de banco de dados não utilizam palavras
planas para definir seus agrupadores primários uma análise de padrões é realizada sobre
esses agrupadores. Busca-se padrões como o Camel Case, palavras planas separadas por
caracteres especiais e palavras planas simplesmente concatenadas. Caso não consiga achar
um padrão de nomeação dos agrupadores primários, utiliza-se um padrão heurístico para
análise das palavras.
Lematização
Uma vez que as palavras utilizadas para realizar a nomeação dos agrupadores
primários foram encontradas, utiliza-se a Wordnet como dicionário para obter os sinônimos correspondentes dessas palavras.
As palavras utilizadas para definir os agrupadores primários, assim como seus
sinônimos e as categorias definidas no banco de dados são lematizadas, removendo
flexõ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ônimos encontrados para esse agrupador, lematizados na etapa anterior, compara-se esses
agrupadores e seus sinônimos com as categorias definidas no banco de dados.
Caso seja encontrada alguma coincidência entre o agrupador e seus sinônimos
com uma ou mais categorias definidas no banco de dados, busca-se as consultas SPARQL
correspondentes àquelas categorias que coincidiram com o agrupador ou com um de seus
sinônimos.
Realiza-se as consultas SPARQL sobre os repositórios semânticos obtidos através das categorias. O resultados de uma consulta SPARQL são armazenados em uma lista
5.2 Etapas da Solução
69
em memória, e serão lematizadas assim como foram os nomes e sinônimos dos agrupadores primários.
A lista de resultados lematizados é então comparada com cada um dos agrupadores secundários daquele agrupador primário. Tomando novamente o exemplo do banco
de dados relacional com a tabela município, caso essa tabela possua duas colunas chamadas 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 ontologia
representada por aquela consulta SPARQL e as células daquela coluna de fato sejam
relacionadas com as entidades daquela classe do repositório semântico. No exemplo
citado da tabela de banco de dados relacional, município poderia estar se relacionando
com 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 corresponde à classe do repositório da DBPedia, mas apenas define-se a probabilidade de
representar essa, devido à coincidência entre o identificador das entidades dessa classe da
ontologia e o conteúdo da célula da coluna nome. Se houve uma coincidência entre os
elementos de apenas 2% dos resultados por exemplo, muito provavelmente essa coincidência não é exata. Entretanto, se a coincidência é da ordem de 90%, é bem provável que
essa correspondência seja exata.
Os resultados não são descartados por possuírem índices de correspondência
percentual baixos, mas são ordenados de forma a apresentar para o usuário as associações
com maior percentual.
Analisando Agrupadores Secundários
Uma vez encontrada uma associação provável entre um agrupador primário
do banco de dados com uma classe do repositório semântico, seria possível analisar
essa classe para buscar suas propriedades e tentar relacioná-las com outros agrupadores
secundários daquela classe do repositório semântico.
No exemplo da tabela município do banco de dados relacional, caso ela tenha
sido 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, poderia
ser associada como a propriedade de objeto globalLocationNumber desse repositório.
Da mesma forma, como na análise dos agrupadores primários, classifica-se os
resultados de acordo com o índices de correspondência percentual entre os resultados
provenientes do banco de dados com o repositório semântico sendo analisado.
5.2 Etapas da Solução
70
Encontrar possíveis correspondências entre os agrupadores secundários de banco
de dados com as propriedades da classe do repositório semântico analisado reforça a
probabilidade 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ível
apresentar o resultado na forma de um Dado Aberto Ligado. Recapitulando o exposto na
Tabela 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 web
como um dado estruturado, em formato não proprietário, identificado por URI e ligado a
outros dados para fornecer contexto.
Na seção 2.2.3 apresentou-se o RDF, um formato de dados que facilita o
intercâmbio de dados na web. Esse formato pode ser utilizado para disponibilizar os dados
do mapeamento realizado.
Ao disponibilizar o mapeamento entre os bancos de dados e a ontologia de referência, torna-se possível construir aplicações que acessam os bancos de dados utilizando
a ontologia de referência como camada de abstração, como pode ser observado na Figura
5.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 na
ontologia.
5.3 Sobre o Capítulo
71
No próximo capítulo, apresenta-se em detalhes o arquivo de mapeamento gerado
a partir da solução descrita nesse trabalho.
5.3
Sobre o Capítulo
Nesse capítulo, foi apresentada uma proposta de solução para o mapeamento
entre ontologias e bancos de dados, com base na classificação gramatical das palavras
que definem os elementos do banco de dados e da ontologia, assim como na utilização de
operações da álgebra de conjuntos.
A solução apresentada difere dos trabalhos realizados até o momento, pois se
propõem a mapear bancos de dados relacionais e NoSQL. Da mesma forma, essa solução
busca a integração do resultado como um dado aberto ligado.
No capítulo seguinte, será apresentada a proposta de um sistema que implementa
os conceitos descritos nesse capítulo. Num primeiro momento, é apresentado um projeto
em função de seus requisitos. Em seguida, apresenta-se os detalhes de implementação
relacionados ao desenvolvimento dessa aplicação.
CAPÍTULO 6
Projeto do Sistema de Mapeamento de Banco de
Dados
Nesse capítulo, será descrito o projeto para o desenvolvimento do sistema de
mapeamento de banco de dados proposto nesse trabalho. Seguindo as conceitos de projeto
propostos pela Engenharia de Software, esse projeto foi dividido em quatro partes.
Segundo Pressman [63]: “Projeto de Software é a parte da Engenharia de
Software que se encarrega de transformar os resultados da Análise de Requisitos em um
documento ou conjunto de documentos capazes de serem interpretados diretamente pelo
programador.”
Na primeira parte, foi realizada uma etapa de análise, onde foram definidos os
requisitos funcionais e requisitos não funcionais da ferramenta proposta. Em seguida, na
etapa de projeto foi realizada a modelagem, por meio de diagramas, e a arquitetura do
sistema proposto. Após a elaboração do projeto, procedeu-se ao seu desenvolvimento e
posteriormente ao processo de teste da aplicação, sendo essa última etapa descrita no
pró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 conhecidos e bastante difundidos dentro da Engenharia de Software.
O baixo acoplamento do código gerado visa facilitar o entendimento e eventual
necessidade de manutenção ou extensão de suas funcionalidades. Além disso, outros
benefícios decorrentes do baixo acoplamento são facilidade ao realizar o processo de
teste 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 flexibilidade
decorrente desse conceito, assim como evitar efeitos conhecidos, decorrentes de sua
omissão, tais como dificuldades de extensões, modificações e reutilizações futuras.
6.1 Atores
6.1
73
Atores
Antes de realizar o levantamento de requisitos da ferramenta proposta, é necessário definir quais são os atores do sistema. Dá-se nome de ator a um papel desempenhado por entidades físicas (pessoas ou outros sistemas) que interagem com o sistema
da mesma maneira, procurando atingir os mesmos objetivos. Uma mesma entidade física
pode desempenhar diferentes papéis no mesmo sistema, bem como um dado papel pode
ser desempenhado por diferentes entidades [56].
O ator não representa a pessoa ou sistema e sim o papel que essa pessoa ou
sistema 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 linguagens de consulta como SPARQL, Web Services ou API de comunicação específica. A aplicação busca esses repositórios para reforçar a categorização de uma
entidade de banco de dados, como fonte de complementação de conteúdo, em caso
solicitado pelo usuário.
Página para Extração: página web onde o extrator de dados busca informação
complementar, de acordo com uma categoria definida previamente pelo desenvolvedor. O acesso do sistema a esse geralmente é realizado por meio de requisições
HTTP e processamento de linguagem natural.
2. Usuário: indivíduo que se comunica com a aplicação requisitando informações a
respeito 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 deve
desempenhar, com suas limitações e restrições, além das características não ligadas
diretamente às funções desempenhadas pelo software [72]. Nesta seção, serão descritos
os 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 deve
fazer [71].
A partir dos Requisitos Funcionais descreve-se as funcionalidades necessárias
para que casos de usos sejam colocados em prática. Segundo Jacobson[46], um Caso de
Uso é um “documento narrativo que descreve a sequência de eventos de um ator que usa
um sistema para completar um processo”. A partir deles, é possível identificar as ações
que devem ser executadas para que o sistema atinja seu objetivo
A construção do Modelo de Casos de Uso corresponde a uma das primeiras
etapas 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 ontologia
será 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 entidades
com 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 ou
domí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 de
representação aberta para o processo de anotação. Essa representação deve atender
aos paradigmas de Dados Abertos Ligados.
• Ocultar Anotações: O sistema deve permitir ao usuário ocultar associações realizadas 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 de
categorias.
• Associar Repositórios: O sistema permite ao Desenvolvedor indicar um novo repositório semântico para complementar as buscas, associando uma consulta SPARQL
a 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 desenvolvimento, 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 de
qualidade: Funcionalidade, Confiabilidade, Usabilidade, Eficiência, Manutenibilidade e
Portabilidade.
Adaptações foram necessárias para a aplicação proposta e o domínio de problemas que deseja-se tratar. Para o atributo Funcionalidade, foram definidos os requisitos
Interoperabilidade e o requisito Segurança; para o atributo Confiabilidade foram definidos
os requisitos Recuperabilidade e Tratamento de Exceções; para o atributo Usabilidade foi
definido o requisito Inteligibilidade; como Eficiência foram definidos os requisitos Paralelismo e Balanceamento de Carga; para o atributo Manutenibilidade foi definido o requisito
Estabilidade; para o atributo Portabilidade foi definido o requisito Flexibilidade.
Alguns outros requisitos que não possuem um termo correlato na norma foram
adotados. Esses requisitos são Simplicidade, Modularidade e Semântica.
• Interoperabilidade: O sistema desenvolvido nessa proposta deve possuir funcionalidades 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 anotados 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ção
e 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ção
e a manipulação do arquivo de representação intermediária utilizado para realizar
consultas 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 capaz
de 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 sistema
deve ser flexível e permitir a substituição de elementos externos utilizados. Em
um contexto mais amplo, o sistema deve possuir um alto nível de coesão e baixo
acoplamento.
• 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 e
feedback 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 e
o arquivo de resultado. Em um primeiro momento apresenta-se a arquitetura do sistema
em seus mínimos detalhes. Esta arquitetura foi baseada nos requisitos levantados e nas
funcionalidades esperadas desse framework. Em um segundo momento, apresenta-se o
formato do arquivo de resultado produzido pela aplicação. Finalmente, é apresentada a
modelagem 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ção
dessa proposta. No apêndice D, apresenta-se uma descrição da base de dados utilizada por
essa aplicação.
6.3 Modelagem, Arquitetura e Arquivo de Resultado
6.3.1
77
Arquitetura
Nesta seção, apresenta-se a arquitetura do sistema proposto para o mapeamento
de banco de dados, assim como os componentes dessa arquitetura. Esse modelo é baseado
nos requisitos definidos no início desse capítulo. Os componentes dessa arquitetura são
o Motor de Execução, o Analisador Léxico/Sintático, o Extrator, o Cliente SPARQL e a
Interface 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 com
o Desenvolvedor, assim como processar o resultado dos demais componentes e apresentar
o resultado do processo de anotação.
Através desse módulo, o usuário seleciona a ontologia que deseja utilizar como
referência no processo de anotação. O Usuário fornece dados para a conexão da aplicação
com 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 consulta
SPARQL 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 executada
sobre um domínio especificado por um URL.
Motor de Execução
Componente responsável por unir o resultado dos outros componentes do sistema, produzir as anotações semânticas, gerar categorias de complementação e produzir
uma saída em formato aberto do relacionamento entre ontologia e bases de dados.
6.3 Modelagem, Arquitetura e Arquivo de Resultado
78
Um dos objetivos desse projeto é realizar a marcação semântica de bancos de
dados, tomando por base uma ontologia de referência. Em segundo plano, os bancos
de dados marcados semanticamente são complementados adicionando relações entre os
elementos dessas bases de dados com entidades de domínios ou repositórios semânticos
específicos por meio de categorias pré-definidas.
Essa etapa de complementação do conteúdo do banco de dados permite um enriquecimento dos resultados de aplicações que utilizem as notações semânticas produzidas
na primeira etapa.
Uma vez que tenham sido realizadas as classificações léxicas e sintáticas das
palavras pelo Analisador Léxico e Sintático, o Motor de Execução produz as primeiras
anotações semânticas sobre os bancos de dados. Em seguida, utiliza-se o Extrator e o
Cliente SPARQL para encontrar possíveis categorias ao qual essa entidade de banco de
dados possa estar vinculada.
Por fim, gera-se um arquivo em formato RDF, que contém as relações entre os
bancos de dados e as ontologias, assim como os URLs e repositórios semânticos que
podem 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 a
análise das classes e entidades das ontologias, assim como dos elementos do bancos de
dados; 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
6.3 Modelagem, Arquitetura e Arquivo de Resultado
79
Esse componente analisa individualmente a ontologia de referência, assim como
cada um dos bancos de dados a serem anotados. A análise de uma ontologia ou banco de
dados inicia-se pelo processo de leitura dos nomes utilizados pelos elementos do bancos
de dados ou ontologias, onde a ferramenta Localizador de Padrões busca detectar padrões
utilizados no processo de nomeação desses elementos.
Alguns padrões utilizados recorrentemente por projetistas de bancos de dados
e ontologias são a utilização do Camel Case para nomeação de palavras, por exemplo
PrimeiroElemento. Da mesma forma, é muito comum a utilização de caracteres especiais
para 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 controlador
indicando 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 invoca
o Analisador Linguístico para realizar um processo de definição da linguagem natural
utilizada 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 palavras
utilizadas 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 uma
linguagem para o banco ou ontologia.
Sabendo-se quais são as palavras utilizadas para nomear os elementos do banco
ou ontologia, assim como as línguas em que foram escritas, o controlador chama o
Tradutor. 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 classificadas
sintaticamente, 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 utilizada
para 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 complementares
em páginas web específicas, que estejam vinculadas a uma categoria. Pode-se observar o
funcionamento desse componente pela Figura 6.4.
6.3 Modelagem, Arquitetura e Arquivo de Resultado
80
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 a
domí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 elemento
do banco de dados, novas requisições são feitas sobre aquele domínio, utilizando outras
instâncias do mesmo elemento da base de dados. Não é necessário que todas as instâncias
encontrem um correspondente elemento naquele domínio, mas apenas que 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 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 URL
e Seletores JQuery, definidos pelo Desenvolvedor, são utilizados para buscar relacionamentos entre a coluna com domínios pré-definidos. Nesse processo, um dos domínios
definidos 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 dez
células analisadas, nove foram encontradas nesse domínio, ao qual o Desenvolvedor associou as categorias ator, atriz, filme. É razoável atribuir a essa coluna as respectivas
categorias associando com esse URL.
Cliente SPARQL
O Cliente SPARQL é uma aplicação responsável por buscar informações complementares em repositórios semânticos específicos, que estejam vinculadas a uma categoria. Pode-se observar o funcionamento desse componente pela Figura 6.5.
6.3 Modelagem, Arquitetura e Arquivo de Resultado
81
Figura 6.5: Módulo Cliente SPARQL
O Cliente SPARQL recebe como entrada um elemento do banco de dados, sejam
colunas, valores ou nós de um grafo. A seguir, o Cliente SPARQL realiza um processo
de 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 do
banco de dados, novas requisições são feitas sobre aquele SPARQL Endpoint, utilizando
outras instâncias do mesmo elemento da base de dados. Não é necessário que todas
as instâncias encontrem um correspondente elemento naquele domínio, mas apenas
que 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 essa
correspondê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 documentos
com a descrição FamousMountain, desse atributo é extraída uma amostra de dez células.
Nesse momento, as consultas SPARQL definidas previamente pelo Desenvolvedor são
utilizadas para buscar nomes de montanhas nesses repositórios. Nesse processo, um dos
domínios definidos pelo desenvolvedor poderia ser o do GeoNames, usando consulta
SPARQL 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 )
6.3 Modelagem, Arquitetura e Arquivo de Resultado
82
Dentre as dez células analisadas, oito foram encontradas nesse repositório, ao
qual o Desenvolvedor associou as categorias local, montanha. É razoável atribuir a essa
coluna à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 referência, cria-se um arquivo de resultados. O arquivo de resultados possui os mapeamentos
realizados entre a ontologia e o banco de dados. Da mesma forma, esse arquivo possui os
mapeamentos 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 atender
os requisitos de um Dado Aberto Ligado, é o RDF. A Figura 6.6 apresenta um exemplo
do 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 de
referência. Além disso, os arquivos possuem referências às especificações dos formatos
OWL, RDF, RDFS e FOAF, descritas da segunda até a quinta linha.
Os prefixos endpoint1 e endpoint2, descritos na sexta e na sétima linha, correspondem 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 resultados
utilizando o prefixo table seguido do nome do agrupador. No exemplo da figura, na nona
linha, é descrita como <#table-nome_no_banco_de_dados>. Esse agrupador primário
do banco de dados, é definido como o correspondente a uma classe da ontologia de
referência, descrito na decima linha do arquivo.
Na décima primeira e décima segunda linhas do arquivo de resultados, apresentase referências para SPARQL Endpoints descobertos pelo Cliente SPARQL. Finalmente, na
6.3 Modelagem, Arquitetura e Arquivo de Resultado
83
décima terceira e décima quarta linha do arquivo de resultados, apresenta-se referências a
domínios descobertos pelo Extrator.
Essa descrição continua para cada agrupador primário do banco de dados analisado.
6.3.3
Modelagem
A modelagem dessa proposta foi definida através do uso de diagramas de
sequência. Um diagrama de sequência representa, de forma clara, por meio de um fluxo
de execução, representado por linhas verticais, e comunicação inter-processos por linhas
horizontais, 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 ponto
específico do programa, assim como os passos necessários para a conclusão de uma
determinada 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 ser
observado na Figura 6.7, apresenta-se o processo de mapeamento de um banco de dados
para uma ontologia de referência. No segundo diagrama, apresentado na Figura 6.8, o
Desenvolvedor define uma nova categoria associada a um domínio. Finalmente, na Figura
6.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 ontologia utilizada como referência e do banco de dados a ser anotado. O Motor de Execução
redireciona os endereços de bancos de dados e ontologia para o Analisador Léxico/Sintático, onde esse identifica padrões utilizados para nomear os elementos, a linguagem
natural utilizada e a classificação sintática das palavras. O Motor de Execução então associa os elementos de bancos de dados com elementos da ontologia. Em seguida, o Motor
de 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 elementos com SPARQL Endpoint. Por fim, o Motor de Execução devolve para o usuário um
arquivo, em formato RDF, com o mapeamento e com a categorização realizada.
6.3 Modelagem, Arquitetura e Arquivo de Resultado
84
Figura 6.7: Mapeando Bancos de Dados e Ontologia
O segundo diagrama de sequências, Figura 6.8, inicia-se com uma requisição
do Desenvolvedor pela inclusão de uma nova categoria vinculada a um domínio. O
sistema pede ao Desenvolvedor que informe o URL da página a ser procurado, assim
como o seletor em JQuery para encontrar o campo a ser relacionado. O sistema executa
uma 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 ao
Desenvolvedor 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 seletor
vinculados 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 do
Desenvolvedor 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 a
consulta em SPARQL a ser executada. O sistema executa uma requisição contra esse
SPARQL Endpoint utilizando o URL e a consulta especificada. Se a consulta produzir um
resultado válido, o sistema apresenta ao Desenvolvedor 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 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 do
Anotador Semântico de Banco de Dados. A implementação a ser apresentada, é baseada
na 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 construir
a aplicação, assim como as configurações utilizadas nos sistemas do qual a aplicação
foi testada. Em seguida, apresenta-se as fontes de informação utilizadas para realizar o
processo de mapeamento e integração do resultado. Por fim, apresenta-se um exemplo de
funcionamento 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 de
dados de sistemas reais é desenvolvida.
6.4 Desenvolvimento da Aplicação
6.4.1
86
Tecnologias Empregadas
Para o desenvolvimento do Anotador Semântico de Banco de Dados, foi utilizado
o 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íficos
para os bancos de dados PostgreSQL, Firebird, Oracle, SQLite, Cassandra e MongoDB.
No Apêndice C, são apresentadas explicações mais detalhadas sobre algumas
das ferramentas citadas.
A aplicação desenvolvida foi testada nos Sistemas Operacionais Windows 7
Professional 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 subcomponentes dois deles, Analisador Linguístico e Localizador de Padrões, necessitam de uma base
de informações com palavras consideradas válidas nos idiomas suportados pelo Anotador
Semântico de Banco de Dados.
Apesar de existirem Web Services de dicionários disponíveis na web, permitindo
consultas a palavras específicas de um idioma, o custo em termos de desempenho de
desenvolver esses subcomponentes utilizando esses Web Services é elevado.
A fim de viabilizar o desenvolvimento desses subcomponentes com o grau de
desempenho desejado, optou-se por embutir os dicionários na aplicação na forma de um
banco de dados linguístico, utilizando SQLite.
Foram utilizados os pacotes linguísticos disponibilizados como add-ons do
Navegador Firefox1 . Esses pacotes linguísticos são utilizados para sistema de correção
ortográfica, tanto de navegadores de internet quanto de editores de texto.
Cada pacote linguístico possui dois arquivos, um arquivo com a lista de palavras
do idioma tendo uma extensão .dic e um arquivo com as regras de flexão de sufixos e
prefixos, tendo a extensão .aff.
Cada linha do arquivo de extensão .dic possui uma única palavra, podendo ser
seguido ou não de uma sequência de letras e números. Tomando um exemplo de algumas
linhas do dicionário de francês, como pode ser observado na Figura 6.10.
1 https://addons.mozilla.org/en-US/firefox/language-tools/,
último acesso em Dezembro de 2014
6.4 Desenvolvimento da Aplicação
87
Figura 6.10: Exemplo de dicionário do pacote de francês
As letras indicam flexões que podem ser utilizadas, havendo diferenciação entre letras maiúsculas e minúsculas. As regras de flexões correspondentes encontram-se
no arquivo de extensão .aff, sendo essas regras dividas em SFX para sufixos e PFX para
prefixos. Tomando como exemplo um prefixo, sendo a mesma regra aplicável para sufixos, esse possui a seguinte regra: PFX <letra-identificadora> <número-de-letras-paradeletar> <o-que-adicionar> <quando-adicionar-(expressão-regular)>. A Figura 6.11
apresenta 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ês
flexões que podem ocorrer, pois existem três linhas no arquivo. No exemplo da Figura
6.11, tomando a primeira linha, able é adicionado ao final da palavra quando essa não
termina com uma vogal (question pode ser flexionada para questionable). Explicações
mais detalhadas sobre a sintaxe de arquivos de dicionários podem ser encontradas na
página de desenvolvedores do projeto Chromium 2 .
Visando a construção da base de dados linguística, construiu-se uma aplicação
para 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 definidas
no arquivo .aff. As palavras formadas são inseridas numa tabela de uma única coluna
chamada verbetes. O Código 6.2 corresponde ao código SQL necessário para a criação
dessa tabela de banco de dados.
2 http://www.chromium.org/developers/how-tos/editing-the-spell-checking-dictionaries,
em Novembro de 2014
último acesso
6.4 Desenvolvimento da Aplicação
88
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 suas
formas 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 para
cada um dos idiomas citados.
6.4.3
Categorias Utilizadas
Ao longo desse trabalho, reiteradamente afirmou-se o objetivo de não somente
realizar o mapeamento de banco de dados para um domínio semântico, mas também
integrar o dados mapeando a nuvem semântica de dados abertos.
O número de repositórios semânticos, cuja informação encontra-se disponível
de forma aberta e integrada com outros repositórios semânticos aumenta a cada dia. Na
Figura 6.12 é possível ver em alta perspectiva como os repositórios semânticos estão
interligados.
Figura 6.12: Nuvem de Dados Abertos Ligados, Abril de 2014[32]
6.4 Desenvolvimento da Aplicação
89
É possível garantir essa integração com outros repositórios, bastando que a
ontologia 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 se
propôs a desenvolver um mecanismo automático de disponibilização das informações
provenientes dos bancos de dados na forma de dados abertos ligados, torna-se necessário
o desenvolvimento de uma ferramenta como o Cliente SPARQL descrito na Subseção
6.3.1.
Tanto com relação ao Cliente SPARQL, quanto com relação ao Extrator trabalhase com categorias vinculadas a um determinado recurso. No caso do Extrator, essa
categoria corresponde a um recurso da Web 2.0, ou seja, da Web Social onde os recursos
nã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ão
explicitamente descritos e os dados são interligados.
De modo geral, as categorias selecionadas definem as ligações que a aplicação
tenta realizar entre o dado proveniente do banco de dados e elementos externos da Web
2.0 e da Web 3.0. Dessa forma, as categorias selecionadas são muito importantes para
definir 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 utilizadas
nas simulações realizadas nesse trabalho. É importante citar que essa não é uma lista
exaustiva, 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 categorias vinculados principalmente a buscadores de variados tipos, desde músicas até pesquisadores e trabalhos acadêmicos. A Tabela 6.1 apresenta as categorias utilizadas:
Tabela 6.1: Categorias Extrator
Categoria
Domínio
filme
imdb.com
filme
themoviedb.org
música
vagalume.com.br
música
musicbrainz.org
jogo
thegamesdb.net
jogo
gamesdbase.com
jogo
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 ao
Cliente SPARQL, optou-se apenas por indicar algumas categorias vinculadas a DBPedia,
6.4 Desenvolvimento da Aplicação
90
ao Dailymed e ao Diseasome, mostradas na Tabela 6.2. Observa-se que as categorias
escolhidas 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 forma
uma vinculação bem sucedida a uma dessas três categorias também pode ser a categoria
Artista. O objetivo é realizar a vinculação mais específica possível, logo a categoria Artista
assume um caráter residual no processo de vinculação.
Outros repositórios, além dos relatados na Tabela 6.2, foram utilizados, totalizando 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ântico
de 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 ser
observada na Figura 6.13, sendo apresentada no formato Turtle[7] e descrita em português
brasileiro.
Figura 6.13: Ontologia de Exemplo
6.4 Desenvolvimento da Aplicação
91
Tabela 6.2: Categorias Cliente SPARQL
Categoria
Repositório
agrotóxico
http://dbpedia.org/sparql
anatomia
http://dbpedia.org/sparql
animal
http://dbpedia.org/sparql
artista
http://dbpedia.org/sparql
atleta
http://dbpedia.org/sparql
ator
http://dbpedia.org/sparql
ave
http://dbpedia.org/sparql
bactéria
http://dbpedia.org/sparql
bebida
http://dbpedia.org/sparql
cantor
http://dbpedia.org/sparql
cidade
http://dbpedia.org/sparql
comida
http://dbpedia.org/sparql
cor
http://dbpedia.org/sparql
doença
http://dbpedia.org/sparql
doença
http://wifo5-03.informatik.uni-mannheim.de/diseasome/sparql
droga
http://dbpedia.org/sparql
droga
http://wifo5-04.informatik.uni-mannheim.de/dailymed/sparql
empresas
http://dbpedia.org/sparql
empresas farmaceuticas http://wifo5-04.informatik.uni-mannheim.de/dailymed/sparql
escritor
http://dbpedia.org/sparql
evento
http://dbpedia.org/sparql
flores
http://dbpedia.org/sparql
fungo
http://dbpedia.org/sparql
gene
http://wifo5-03.informatik.uni-mannheim.de/diseasome/sparql
instituições de ensino
http://dbpedia.org/sparql
livro
http://dbpedia.org/sparql
moeda
http://dbpedia.org/sparql
musgo
http://dbpedia.org/sparql
música
http://dbpedia.org/sparql
país
http://dbpedia.org/sparql
peixe
http://dbpedia.org/sparql
periódico acadêmico
http://dbpedia.org/sparql
personagem fictício
http://dbpedia.org/sparql
pessoa
http://dbpedia.org/sparql
pesticida
http://dbpedia.org/sparql
província
http://dbpedia.org/sparql
quadrinhos
http://dbpedia.org/sparql
substância química
http://dbpedia.org/sparql
6.4 Desenvolvimento da Aplicação
92
Esse usuário deseja realizar o mapeamento semântico de um banco de dados de
uma loja varejista para essa ontologia simples. Supondo que esse banco de dados seja um
banco de dados PostgreSQL, onde as tabelas do banco de dados e suas colunas foram
descritas em inglês conforme o manual de usuário do sistema. O usuário então define a
ontologia de referência utilizada, as informações de conexão com o banco de dados e o
idioma do banco de dados. Como o usuário não tem conhecimento do padrão utilizado
para 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 Figura
6.14.
Figura 6.14: Adicionando um Banco de Exemplo
O usuário então, sabendo que a ontologia possui apenas uma classe cidade e uma
classe pessoa, escolhe essas opções na aba “Categorias”. Após essa definição, o usuário
seleciona a aba “Principal” e clica no botão Aplicar.
A primeira tarefa do Anotador Semântico de Banco de Dados é realizar a classificação sintática tanto da ontologia quanto do banco de dados. Sabendo que a ontologia foi
definida em português o Motor de Execução chama o Analisador Léxico/Sintático para
analisar a ontologia, conforme o descrito na Subseção 6.3.1.
Sabendo da 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ões testa o caso mais simples em que classes, entidades e propriedades da
ontologia utilizem texto plano do português. Sendo o teste bem sucedido, o Analisador
Léxico/Sintático chama o Tradutor para converter o texto em inglês ( mantêm-se o texto
original apenas guardando esse valor em um texto a parte para ter uma linguagem de referência internacional ). Finalmente, o Analisador Léxico/Sintático consulta a WordNet
para fazer a classificação das palavras.
O Analisador Léxico/Sintático começa a analisar o banco de dados, sabendo
da linguagem utilizada, o Analisador Léxico/Sintático dispensa o uso do Analisador
6.4 Desenvolvimento da Aplicação
93
Linguístico, chamando em seguida o Localizador de Padrões. O Localizador de Padrões
testa o uso de texto plano, em seguida testa o uso de camel case, finalmente encontra
o padrão utilizado pelo banco de dados ao considerar o padrão de palavras em texto
plano separadas por caractere especial underline. Uma vez que os nomes de tabelas e
campos já estão em inglês o Analisador Léxico/Sintático dispensa o Tradutor, realizando
diretamente a consulta à WordNet e classificando as palavras.
O Motor de Execução começa a realizar cruzamento das informações sobre o
banco de dados e a ontologia, obtidas a partir do Analisador Léxico/Sintático. Após
realizar várias comparações, o Motor de Execução indica que a tabela clientes do banco de
dados possui uma relação de hiperônimo com a classe pessoa da ontologia. Além disso, a
tabela 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 das
colunas 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 para
a propriedade nome da classe pessoa, da mesma forma encontra uma correspondência
de uma coluna idade_cliente dessa mesma tabela com a propriedade idade da classe da
ontologia.
Ao comparar as colunas da tabela município com as propriedades da classe
cidade da ontologia, o Motor de Execução observa que a tabela possui uma coluna
has_ibge_code, da qual ele descarta o verbo has e observa que essa coluna da tabela
contém um substantivo igual à propriedade ibge da classe município.
Estabelecidos os candidatos a relacionamento entre colunas da tabela e propriedades da ontologia, o Motor de Execução agora analisa os Inviduals da ontologia. Como
o banco de dados é relacional, o Motor de Execução cria uma consulta buscando em cada
uma das colunas valores que coincidam com os Inviduals ou com as propriedades da ontologia. Caso o o banco de dados fosse NoSQL, o Motor de Execução buscaria cada um
individualmente.
O Código 6.3 apresenta o trecho do programa em java responsável por criar esse
código SQL.
6.4 Desenvolvimento da Aplicação
94
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ódigo
SQL é construído somente em função da propriedade description, o qual não encontra
nenhum resultado. Entretanto, existe na ontologia Inviduals para a classe cidade. Dessa
forma, o Motor de Execução constrói uma consulta em função desses e da propriedade
ibge. A consulta construída pode ser observada no trecho de Código 6.4
6.4 Desenvolvimento da Aplicação
95
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 dados
cliente e município estão ligadas por uma chave estrangeira, o qual o Motor de Execução
analisa 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, o
Motor de Execução anota a tabela município com uma anotação para a classe cidade da
ontologia. Como a relação entre a tabela cliente e a classe pessoa ocorreu por meio de
uma relação de hiperônimo, o Motor de Execução adiciona uma anotação à tabela cliente
como subclasse de pessoa.
A partir desse momento, o Anotador Semântico de Banco de Dados busca
realizar a categorização das tabelas anotadas de acordo com as categorias selecionadas
pelo usuário. Primeiramente, o Anotador Semântico verifica se existem registros na tabela
do 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 município, anotada como correspondente da classe cidade, com a classe Town da DBPedia e
com a classe wikicategory_Locations_in_Brazil_(city) do Yago2. O Anotador Semântico
de Banco de Dados adiciona anotações de correspondência entre essa tabela anotada e as
correspondentes classes dos repositórios.
6.5 Sobre o Capítulo
6.5
96
Sobre o Capítulo
Nesse capítulo, foi apresentado o projeto de uma aplicação desenvolvida em
java, que implementa os conceitos discutidos no Capítulo 5. A aplicação foi apresentada
na 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 na
seção 6.3, onde explicou-se em detalhes o funcionamento de cada componente do sistema
e 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, tais
como ferramentas utilizadas, modelagem do banco de dados, dicionários linguísticos e
categorias 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, 4
somados à proposta de mapeamento, desenvolvida no Capítulo 5, definiram os parâmetros
gerais dessa aplicação. De forma geral, o objetivo dessa aplicação é apenas servir como
uma ferramenta para provar o conceito de eficiência do método estabelecido nessa
proposta.
No capítulo seguinte, são apresentados resultados práticos dessa aplicação, viabilizando analisar as vantagens e desvantagens desse método com relação a outros desenvolvidos até esse momento.
CAPÍTULO 7
Análise de Resultados
Neste capítulo, é feita uma avaliação prática da ferramenta desenvolvida analisando seus resultados de forma estatística. Inicialmente, na Seção 7.1, são apresentados os
resultados dos testes sobre o agrupador primário dos bancos de dados analisados. A Seção
7.2 apresenta a análise dos resultados obtidos sobre o agrupador secundário, lembrando
que os agrupadores primários e secundários foram enumerados na Tabela 5.1 da Seção
5.2.1. A Seção 7.3 apresenta estatisticamente as associações semânticas realizadas com
outros 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 bancos
de dados de demonstração públicos, abrangendo os sistemas SQL Server, PostgreSQL,
MySQL e Apache Cassandra. Dessa forma, o teste realizado contempla tanto os tradicionais 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 agrupadores
primários e esquemas desenvolvido principalmente para finalidades didáticas, de acordo
com o respectivo banco de dados para o qual foram desenvolvidos.
As ontologias utilizadas em cada um dos testes estão relacionadas na Tabela
7.1, sendo todas elas públicas. Algumas dessas ontologias são de repositórios semânticos
conhecidos, o que não inviabiliza o processo de associação semântica, no pior caso esse
procedimento 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ários
são bancos relacionais e orientados a colunas. Logo os agrupadores primários utilizados
1 https://dev.mysql.com/doc/world-setup/en/,
acessado em Janeiro de 2015
2 http://blog.secaserver.com/2013/08/importing-imdb-sample-data-set-mysql/,
2015
3 https://github.com/twissandra/twissandra, acessado em Janeiro de 2015
acessado em Janeiro de
7.1 Resultados da Aplicação - Agrupadores Primários
98
Tabela 7.1: Banco de Dados x Ontologias
Banco
de
Dados
World
IMDB
Twissandra
Ontologia
http://www.dbis.informatik.uni-goettingen.de/Mondial/
http://www.movieontology.org/downloads/
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
Banco de Dados
Idioma(Banco)
Padrão(Banco)
Idioma(Ontologia)
Padrão(Ontologia)
Valor
PostgreSQL
Inglês
Camel Case
Inglês
Camel Case
(a) Entradas
Métrica
Total de Classes Associáveis
Associações Corretas
Associações Incorretas
Não Associados
Total
3
3
0
0
(b) Saídas
No experimento realizado entre a ontologia e o banco de dados, a quantidade
de classes na ontologia é superior ao total de tabelas do banco de dados, sendo que a
ontologia abrange um domínio maior e mais representativo que o utilizado no banco de
dados. Dessa forma, não existem restrições com relação ao mapeamento entre a ontologia
e o banco de dados, ou seja, todas as tabelas do banco de dados podem ser mapeadas para
uma ou mais classes da ontologia.
As relações Country, City e CountryLanguage foram mapeadas respectivamente
para as classes Country, City e Language da ontologia. O fato das tabelas do banco de
dados possuírem nomes iguais ou próximos ao das classes da ontologia contribuiu para a
associação correta dos elementos da ontologia.
Contribuiu também o fato de que todos esses pares de ligações banco de dados
vs. ontologia tiveram intersecções em seus dados. Sobre as entidades Country, tanto da
ontologia quanto do banco de dados, a correspondência dos elementos foi integral, ou
seja, todos os elementos presentes no banco de dados possuíam uma entidade da classe
Country da ontologia com valor igual ou próximo (a ontologia Mondial não considera
sinais de acentuação latinos). Procedimento similar ocorreu com a entidade City, tanto
da ontologia quanto do banco de dados, ocorreu correspondência entre vários, mas não
todas, as instâncias da ontologia e do banco de dados.
7.1 Resultados da Aplicação - Agrupadores Primários
99
Sobre o relacionamento CountryLanguage do banco de dados com Language
da ontologia, a princípio a tabela CountryLanguage apresentou dois possíveis candidatos
na ontologia, sendo eles Country e CountryLanguage. Como existia a chave estrangeira
da tabela CountryLanguage para a tabela Country concluiu-se que essa estava apenas
representando uma ligação por meio de uma propriedade de objeto entre duas entidades
da 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.
Tabela 7.3: Entrada e Saída Agrupador Primário - Experimento 2
Parâmetro
Banco de Dados
Idioma(Banco)
Padrão(Banco)
Valor
MySQL
Inglês
Palavras Planas
Separadas
por
Underline
Idioma(Ontologia) Inglês
Padrão(Ontologia) Nenhum
Métrica
Total de Classes Associáveis
Associações Corretas
Associações Incorretas
Não Associados
Total
9
8
0
1
(b) Saídas
(a) Entradas
No experimento realizado, utilizou-se o banco de dados IMDB, o qual agrega
informações de filmes, séries de televisão, informações sobre celebridades. A ontologia
utilizada, 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 apresentado
pela 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 mapeadas para a ontologia. Desse total, 8 foram associadas corretamente e uma não foi
associada.
As tabelas name, aka_name e person_info foram compreendidas pelo sistema
como 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 dados
existe apenas uma entidade representando pessoas que trabalham no filme, na ontologia
esses 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 utilizados para definir tabelas e colunas.
As tabelas company_name e movie_companies foram mapeadas para a classe
Product_Company da ontologia.
7.1 Resultados da Aplicação - Agrupadores Primários
100
Por fim, a tabela que não foi associada no processo de mapeamento semântico
foi a tabela cast_info. Essa tabela poderia ter sido mapeada para a classe pessoa, a qual
apresenta informações que representam genericamente as pessoas que trabalham em um
filme.
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.
Tabela 7.4: Entrada e Saída Agrupador Primário - Experimento 3
Parâmetro
Banco de Dados
Idioma(Banco)
Padrão(Banco)
Valor
Cassandra
Inglês
Palavras Planas
ou Concatenadas
Idioma(Ontologia) Inglês
Padrão(Ontologia) Palavras Planas
Métrica
Total de Classes Associáveis
Associações Corretas
Associações Incorretas
Não Associados
Total
6
4
2
0
(b) Saídas
(a) Entradas
Nesse experimento, foram utilizados um banco de dados orientado a colunas
que procura simular um modelo de dados para a rede social Twitter4 e uma ontologia
utilizada principalmente para representações de comunidades virtuais. O domínio tratado
pela ontologia e o banco de dados são muito próximos, não havendo famílias de colunas
no banco de dados utilizadas como metainformação. Dessa forma, não existem restrições
com relação ao mapeamento entre a ontologia e o banco de dados, ou seja, todas as
famílias de colunas do banco de dados podem ser mapeadas para uma ou mais classes
da ontologia.
O seguinte mapeamento foi realizado pela ferramenta de anotação: a família de
colunas 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 classe
Post, a família de colunas userline foi mapeada para as classes Forum e User Account e a
família de colunas timeline foi mapeada para a classe Forum.
No mapeamento realizado pela aplicação considera-se como incorreto o mapeamento realizado entre as famílias followers e following com a classe Agent, pois a associação mais provável numa rede social seria associá-la com a classe User Account. Apesar
de existir um relacionamento de subclasse entre User Account e Agent, a aplicação não
conseguiu definir uma relação de candidato entre as famílias de colunas do banco de dados e a classe User Account. O dicionário linguístico utilizado para realizar a análise
4 https://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 following podem referir-se a tipos de usuários em redes sociais. Como uma melhoria futura
da 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 termos
utilizados em redes sociais.
7.2
Resultados da Aplicação - Agrupadores Secundários
Os bancos de dados utilizados nos experimentos são relacionais e orientados
a colunas, nesse caso o agrupador secundário de ambos os tipos de banco de dados
utilizados denomina-se “colunas”.
Sabendo-se que existe uma relação de dependência do agrupador primário com
o agrupador secundário, foi realizada a inclusão de eventuais associações não realizadas
nos experimentos relativos ao agrupador primário, afim de isolar os resultados. A inclusão
desses valores apenas adiciona mais dados à análise, não prejudicando os resultados
daqueles 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 agrupador
secundário.
Tabela 7.5: Entrada/Saída Agrupador Secundário - Experimento 1
Parâmetro
Banco de Dados
Idioma(Banco)
Padrão(Banco)
Valor
PostgreSQL
Inglês
Palavras Planas
ou Concatenadas
Idioma(Ontologia) Inglês
Padrão(Ontologia) Camel Case
(a) Entradas
Métrica
Total de Propriedades Associáveis
Associações Corretas
Associações Incorretas
Não Associados
Total
14
10
0
4
(b) Saídas
Tendo-se relacionado todas as tabelas do banco de dados com uma classe
correspondente na ontologia, na primeira etapa, é possível associar 14 das 24 colunas
existentes no banco de dados. As 10 colunas não associáveis correspondem a colunas do
qual não existe uma propriedade correspondente na ontologia.
Observa-se que apenas 4 colunas não foram associadas no processo, sendo as
colunas countrycode e district da tabela City, a coluna indepyear da tabela Country e a
coluna countrycode da tabela CountryLanguage.
7.2 Resultados da Aplicação - Agrupadores Secundários
102
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 padrã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 Semântico aqui desenvolvido não foi construído para analisar possíveis composições de
dados nos nomes das entidades, dessa forma essa informação presente no banco de dados
não foi mapeada para o nome da entidade da ontologia.
Não ocorreu o mapeamento da coluna indepyear da tabela Country, pois os
tipos de dados utilizados diferiram. Apesar de existirem proximidades léxicas entre a
coluna 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 tipos
diferentes onde um tipo seja capaz de abranger outro tipo pode ser uma melhoria futura
desse projeto.
Na coluna countrycode da tabela CountryLanguage, a associação falhou, por
motivos semelhantes ao ocorrido na tabela City, o código do país foi embutido no nome
da 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.
Tabela 7.6: Entrada/Saída Agrupador Secundário - Experimento 2
Parâmetro
Banco de Dados
Idioma(Banco)
Padrão(Banco)
Valor
MySQL
Inglês
Palavras Planas
Separadas
por
Underline
Idioma(Ontologia) Inglês
Padrão(Ontologia) Palavras Planas
Métrica
Total de Propriedades Associáveis
Associações Corretas
Associações Incorretas
Não Associados
Total
7
7
0
0
(b) Saídas
(a) Entradas
O banco de dados do IMDB é um banco normalizado, onde a maioria das colunas
utilizadas nas tabelas do banco de dados representam ligações com outras tabelas. A maior
parte das colunas passíveis de associação com propriedades da ontologia tem descrições
contendo palavras como name, info e note.
Todas as colunas passíveis de associação com a ontologia que possuíam o termo
name se ligaram com a Datatype Property name da ontologia. Aquelas colunas com
os termos info e note foram associadas com a Datatype Property description. As duas
7.2 Resultados da Aplicação - Agrupadores Secundários
103
propriedades são propriedades do tipo string presentes em todas as classes da ontologia
que 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 agrupador
secundário.
Tabela 7.7: Entrada/Saída Agrupador Secundário - Experimento 3
Parâmetro
Banco de Dados
Idioma(Banco)
Padrão(Banco)
Idioma(Ontologia)
Padrão(Ontologia)
Valor
Cassandra
Inglês
Nenhum
Inglês
Palavras Planas
(a) Entradas
Métrica
Total de Propriedades Associáveis
Associações Corretas
Associações Incorretas
Não Associados
Total
12
10
0
2
(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 com
a 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álise
de agrupador primário.
No banco de dados analisado, 12 colunas poderiam ser associadas com elementos
correspondentes da ontologia, sendo que 10 foram corretamente associados e 2 elementos
deixaram de ser associados.
As colunas não associadas do banco de dados com uma propriedade correspondente da ontologia foram as colunas de nome body das famílias de colunas userline e
timeline. Essas colunas deviam ter sido associadas com a Datatype property content da
classe de domínio item da ontologia.
Nenhuma das famílias de colunas utilizadas, userline e timeline, realizou essa
associação, pois elas não tiveram uma ligação correspondente com a classe item ou
uma de suas subclasses. No caso de bancos de dados NoSQL, onde não existem chaves
estrangeiras que tornam explícita a semântica de relacionamento entre as entidades, a
análise dessas dependências é significativamente mais complicada.
Uma outra possibilidade seria considerar nomes de agrupadores secundários
iguais para indicar possível relacionamento. No caso do experimento, as famílias de
colunas userline e timeline possuíam uma coluna tweetid, o que poderia representar uma
possível ligação com a tabela tweet, que também possui uma coluna de chave primária
com esse nome. Dessa forma, seria possível incluir as classes mapeadas de tweet, assim
como suas superclasses, na análise das famílias de colunas userline e timeline.
7.3 Resultados da Aplicação - Associação Semântica
7.3
104
Resultados da Aplicação - Associação Semântica
O processo de associação semântica, realizado após o mapeamento entre o banco
de dados e a ontologia, tem por objetivo realizar a ligação entre as bases de dados
recém anotadas e um ou mais repositórios semânticos ou domínios web associadas a uma
categoria definida pelo desenvolvedor.
As categorias existentes no sistema são tantas quantas forem definidas pelo
desenvolvedor antes do usuário iniciar o processo de associação entre os bancos de dados
e a ontologia de referência. Nos experimentos realizados, existia mais de uma centena
de categorias disponíveis, entretanto não faz sentido tentar associar todas as categorias a
um único experimento se não existe uma relação de pertinência daquela categoria com o
respectivo domínio tratado.
Ao realizar o mapeamento de uma série de bancos de dados para uma ontologia
que trate de automóveis, é razoável associar categorias como veículos, combustíveis e
país. No entanto, não faz muito sentido esperar bons resultados ao escolher categorias
como fungos, doenças ou livros.
O usuário pode selecionar todas as categorias numa análise, em casos que
o domínio tratado não é perfeitamente conhecido por exemplo, mas por questões de
simplicidade definiu-se apenas algumas categorias ao realizar cada experimento. Essas
categorias foram selecionadas por apresentarem alguma pertinência temática com o
domínio tratado pela ontologia de referência.
A Tabela 7.8 apresenta as categorias selecionadas em cada experimento. A
primeira coluna indica o experimento realizado, a segunda coluna as categorias utilizadas
em cada experimento e a terceira coluna as categorias encontradas em cada um dos
experimentos realizados.
Tabela 7.8: Categorias X Experimentos
Experimento
Experimento 1
Experimento 2
Experimento 3
Selecionadas
Idioma, Cidade,
Estado,
País,
Moeda
Ator,
Filme,
Diretor, Escritor,
Evento, Pessoa
Pessoa
Encontradas
Idioma, Cidade,
Estado, País
Ator,
Filme,
Diretor, Escritor,
Evento, Pessoa
-
Observa-se que, no Experimento 1 foram selecionadas 5 categorias para o
domínio do problema tratado. Dessas categorias tratadas, apenas uma não apresentou
resultado, sendo esta a categoria Moeda. Apesar do banco de dados selecionado tratar
informações sobre países e seus idiomas, ele não possui a informação da moeda em
circulação desses países. Entretanto, como foi realizada a ligação entre a entidade país
7.4 Sobre o Capítulo
105
do banco de dados com o repositório semântico da DBPedia, essa informação pode ser
obtida subsequentemente através dessa ligação, o que seria a consequência direta da
complementação semântica explicada no Capítulo 5.
No Experimento 2, foram selecionadas 6 categorias, sendo que todas elas foram
relacionadas com pelo menos um repositório semântico. Apesar da relação Pessoa ter sido
encontrada, essa foi encontrada sempre como possuindo uma subclasse mais específica
para representação da entidade tratada na coluna.
Por fim, no Experimento 3, foi associada uma única categoria Pessoa, sendo que
essa categoria não foi vinculada a nenhum repositório semântico das categorias registradas. Esse resultado se deve ao fato de que as colunas analisadas não apresentaram pessoas
conhecidas pelos repositórios tratados. Se as pessoas registradas no banco de dados do
Twissandra fossem pessoas famosas, como políticos, atores ou cantores possivelmente
teriam sido encontrados em algum repositório.
De forma geral, o processo de associação realizado possui forte dependência do
conteúdo com relação ao dado armazenado no banco de dados. Nota-se que os melhores
resultados foram os do Experimento 2, cujo banco de dados é o mais populado de todos.
7.4
Sobre o Capítulo
Neste Capítulo, foram apresentados resultados de alguns experimentos realizados utilizando a aplicação desenvolvida nesse trabalho, o Anotador Semântico de Banco
de Dados. Optou-se pela utilização de ontologias e bancos de dados simples, de acesso
público por questões de simplicidade de análise e para facilitar o entendimento.
Ao longo dos experimentos realizados, novas ideias surgiram para melhorar os
resultados da aplicação. Dessa forma, a execução da aplicação em contextos reais, mesmo
que simplistas, fornecem conteúdo para eventuais trabalhos futuros sobre a ferramenta
desenvolvida nesse trabalho.
Analisando os resultados obtidos de forma percentual, observa-se que a aplicação
possui bom desempenho no processo de associação, tanto com relação a uma ontologia
de 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ção
com relação a seus objetivos iniciais, um levantamento de suas principais vantagens e
desvantagens, assim como discute-se as possíveis melhorias desse projeto.
CAPÍTULO 8
Conclusão e Trabalhos Futuros
Ao longo desse trabalho, apresentou-se uma ferramenta para o processo de
mapeamento semântico de banco de dados. Essa pesquisa foi estruturada abordando os
tó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 do
banco de dados para uma ontologia de referência com a nuvem de dados abertos, no
Capítulo 3 foi realizado um estudo sobre alguns repositórios semânticos utilizados nesse
trabalho. Esses repositórios foram apresentados de forma individual, mas demonstrouse a integração desses através de predicados indicativos de igualdade entre classes
estabelecendo 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-se
as peculiaridades de cada solução, tanto suas vantagens quanto suas desvantagens, visando 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 apresentada, projetada, detalhada e desenvolvida, criando uma ferramenta de anotação semântica
de bancos de dados com interessantes resultados e que satisfaz os objetivos definidos no
início dessa pesquisa.
Observa-se que o trabalho desenvolvido até aqui não foi a criação de um
programa, mas sim o melhoramento das técnicas de mapeamento de bancos de dados
quaisquer para domínios semânticos representados por ontologias de referência sobre um
domínio específico desejado pelo usuário.
Apesar de obter um resultado satisfatório no processo de mapeamento de banco
de 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 desenvolvida durante este trabalho. Por fim, são levantados possíveis melhoramentos e desafios
ainda em aberto que poderão ser realizados em trabalhos futuros.
8.1 Contribuições
8.1
107
Contribuições
Uma das contribuições deste trabalho foi a proposta, definição, desenvolvimento
e implementação de uma arquitetura extensível, flexível, genérica, escalável no processo
de mapeamento de bancos de dados para ontologias, utilizando tecnologias abertas de
software livre.
Essa proposta de mapeamento de banco de dados foi desenvolvida de forma
que fosse possível tratar tanto os tradicionais bancos de dados relacionais, largamente
explorados nos trabalhos anteriores, quanto os bancos de dados NoSQL. A inclusão
dessas bases não relacionais representa uma das evoluções desenvolvidas nesse trabalho
com relação às técnicas existentes. Apesar desses bancos de dados ganharem espaço em
vários contextos nos anos recentes, esses ainda não foram tratados com profundidade nas
pesquisas realizadas até o momento.
Além disso, esse trabalho procurou inovar no processo de mapeamento de bancos
de dados, no que diz respeito ao resultado do mapeamento contemplar não somente o
conteúdo da ontologia de referência, mas o de outros repositórios na nuvem semântica
de banco de dados. O objetivo dessa funcionalidade é enriquecer semanticamente os
dados sendo mapeados, permitindo que esse dado compartilhe das eventuais melhorias
que possam ocorrer nesses repositórios para o qual tenha sido mapeado.
A seguir são apresentadas algumas sugestões de trabalhos futuros que podem
contribuir 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 aos
métodos de mapeamento de bancos de dados relacionais e NoSQL, tanto para a ontologia
de referência quanto para repositórios semânticos externos.
Nessa seção, são apresentadas algumas sugestões de melhorias da solução proposta, visando melhorar os resultados, torná-los mais abrangentes ou mesmo utilizar os
resultados desenvolvidos até o momento para outros propósitos. A seguir apresenta-se
uma lista de possíveis trabalhos futuros a serem estudados e implementados na ferramenta
desenvolvida.
• Dicionários de Sinônimos: A aplicação apresenta certa dependência de sinônimos
entre palavras, limitando os seus resultados àquilo especificado na WordNet. É
possível melhorar os resultados ao considerar outros dicionários de sinônimos, os
quais podem ser integrados à solução com relativa facilidade dada a sua arquitetura
extensível.
8.2 Trabalhos Futuros
108
• Análise Semântica: A aplicação busca realizar uma análise léxica e sintática tanto
dos componentes do banco de dados, quanto da ontologia. É possível melhorar esses
resultados 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 relacionamento
entre suas entidades de forma explícita, como ocorre nos bancos relacionais. É
possível estabelecer mecanismos de análise dos elementos de bancos de dados para
contemplar 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 orientados
a colunas e bancos orientados a documentos. Entretanto, outros paradigmas como
bancos do tipo chave-valor e bancos orientados a documentos podem ser explorados
em pesquisas futuras.
• Mecanismos de Full Text Search: O processo de associação com repositórios semânticos externos é realizado utilizando igualdade nas consultas SPARQL realizados sobre esses repositórios. Existem alguns repositórios semânticos que começam
a oferecer o mecanismo de full text search, presente em bancos de dados relacionais como o PostgreSQL, no contexto de seus dados. A utilização desse método de
buscas, possivelmente é capaz de sofisticar os resultados no processo de associação
com repositórios externos.
• Novos Predicados de Relacionamento: No processo de associação com os repositórios semânticos externos busca-se principalmente a igualdade com entidades
desses repositórios. Em outras palavras, procura-se estabelecer relacionamentos utilizando predicados comuns como owl:sameAs. Entretanto, existem outros tipos de
relacionamentos além da igualdade, apresentado por esse predicado, que podem
ser explorados, tais como skos:broadMatch, skos:narrowMatch, skos:closeMatch e
outros.
Referências Bibliográficas
[1] AGUNE , R. M.; F ILHO, A. S. G.; B OLLIGER , S. P. Governo aberto sp: disponibilização de bases de dados e informações em formato aberto. In: III CONGRESSO
CONSAD DE GESTÃO PÚBLICA, 2010.
[2] A NGLES , R.; G UTIERREZ , C. Survey of graph database models. ACM Comput.
Surv., 40(1):1:1–1:39, Feb. 2008.
[3] A PACHE J ENA . A semantic web framework for java. http://jena.apache.org/
index.html, acessado em janeiro de 2015, 2015.
[4] B ATTLE , R.; KOLAS , D. Enabling the geospatial semantic web with parliament
and geosparql. Semantic Web, 3(4):355–370, 2012.
[5] B ECHHOFER , S.; M ILES , A. SKOS simple knowledge organization system reference. W3C recommendation, W3C, Aug. 2009. http://www.w3.org/TR/2009/RECskos-reference-20090818/.
[6] B ECHHOFER , S.; VAN H ARMELEN , F.; H ENDLER , J.; H ORROCKS , I.; M C G UINNESS ,
D. L.; PATEL -S CHNEIDER , P. F.; S TEIN , L. A.
OWL Web Ontology Language
Reference. Technical report, W3C, http://www.w3.org/TR/owl-ref/, February 2004.
[7] B ECKETT, D.; B ERNERS -L EE , T. Turtle - terse RDF triple language, W3C team
submission, 2008. See: http://www.w3.org/TeamSubmission/turtle/.
[8] B ERNERS -L EE , 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] B ERNERS -L EE , T. Information management: A proposal. Technical report, CERN,
Genf, March 1989.
[10] B ERNERS -L EE , T. The World Wide Web - Past Present and Future. In: Japan Prize
Commemorative Lecture, 2002.
Referências Bibliográficas
110
[11] B ERNERS -L EE , T. Semantic Web concepts. Presented at Edinburgh University,
September 2005.
[12] B ERNERS -L EE , T.; H ENDLER , J.; L ASSILA , O.
The semantic web.
Scientific
American, 284(5):34–43, May 2001.
[13] B ERRUETA , D.; P HIPPS , J. Best practice recipes for publishing rdf vocabularies.
World Wide Web Consortium, Note NOTE-swbp-vocab-pub-20080828, August 2008.
[14] B IZER , C. The emerging web of linked data. Intelligent Systems, IEEE, 24(5):87–
92, 2009.
[15] B OLLACKER , K.; E VANS , C.; PARITOSH , P.; S TURGE , 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] B ONIFACIO, A. S. Ontologias e consulta semântica: uma aplicação ao caso
lattes. Master’s thesis, UFRGS, Porto Alegre, Outubro 2002.
[17] B ORST , W. N. Construction of Engineering Ontologies for Knowledge Sharing
and Reuse. PhD thesis, Enschede, September 1997.
[18] B RAY, T.; PAOLI , J.; S PERBERG -M C Q UEEN , C. M.; M ALER , E.; Y ERGEAU, F. Extensible markup language (xml) 1.0 (fifth edition). World Wide Web Consortium,
Recommendation REC-xml-20081126, November 2008.
[19] B REWER , E. A. Towards robust distributed systems. In: Symposium on Principles
of Distributed Computing (PODC), 2000.
[20] B RICKLEY, D.; G UHA , R. V.
Rdf vocabulary description language 1.0: Rdf
schema. Technical report, 2 2004.
[21] B RICKLEY, D.; M ILLER , L.
FOAF Vocabulary Specification 0.97.
Namespace
document, January 2010.
[22] B UMANS , G.; C ERANS , 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] C ALVANESE , D.; G IACOMO, G. D.; L EMBO, D.; L ENZERINI , M.; P OGGI , A.;
R ODRIGUEZ -M URO, M.; R OSATI , R.; RUZZI , M.; S AVO, D. F. The mastro system
for ontology-based data access. Semantic Web, 2(1):43–53, 2011.
Referências Bibliográficas
111
Resource description framework (RDF):
[24] C ARROLL , J. J.; K LYNE , G.
Concepts and abstract syntax.
W3C recommendation, W3C, Feb. 2004.
http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/.
[25] C ATTELL , R. Scalable sql and nosql data stores. SIGMOD Rec., 39(4):12–27, May
2011.
[26] C ERANS , K.; B UMANS , 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] C HAGANTI , P.; H ELMS , R. Amazon SimpleDB Developer Guide. Packt Publishing,
Limited, 2010.
[28] C HANG , F.; D EAN , J.; G HEMAWAT, S.; H SIEH , W.; WALLACH , D.; B URROWS , M.;
C HANDRA , T.; F IKES , A.; G RUBER , 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] C HODOROW, K.; D IROLF, M. MongoDB - The Definitive Guide: Powerful and
Scalable Data Storage. O’Reilly, 2010.
[30] C ODD, E. F. A relational model of data for large shared data banks. Commun.
ACM, 13(6):377–387, June 1970.
[31] C ROCKFORD, D. RFC 4627 - The application/json Media Type for JavaScript
Object Notation (JSON). Technical report.
[32] C YGANIAK , R.; J ENTZSCH , A.
The linking open data cloud diagram. http:
//lod-cloud.net/, acessado em março de 2015, 2014.
[33] D E V RIES , P. J. GeoSpecies Ontology. http://bioportal.bioontology.org/
ontologies/GEOSPECIES, acessado em Fevereiro de 2015, 2011.
[34] E AVES , D. About David. http://www.eaves.ca/about, acessado em maio de
2013, 2009.
[35] E RLING , O. Virtuoso, a hybrid rdbms/graph column store. IEEE Data Eng. Bull.,
35(1):3–8, 2012.
[36] F LORIAN , B.; M ARTIN , K. Linked Open Data: The Essentials - A Quick Start Guide
for Decision Makers. edition mono/monochrom, Vienna, Austria, 2012.
[37] G EO N AMES . GeoNames geographical database, 2010. Last access on Jul 2014
at: http://www.geonames.org.
Referências Bibliográficas
[38] G RUBER , T. R.
112
A translation approach to portable ontology specifications.
Knowledge Acquisition, 5(2):199–220, June 1993.
[39] H ASSANZADEH , O.; C ONSENS , M. P. Linked movie data base. In: Proceedings of
the WWW2009 workshop on Linked Data on the Web (LDOW2009), 2009.
[40] H AUSENBLAS , 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] H AYES , P.; M C B RIDE , B. Rdf semantics. Technical report, Fevereiro 2004.
[42] H OFFART, J.; S UCHANEK , F. M.; B ERBERICH , K.; W EIKUM , G. YAGO2: A spatially
and temporally enhanced knowledge base from wikipedia. Artificial Intelligence,
194:28–61, 2013.
[43] H OLZSCHUHER , F.; P EINL , R. Performance of graph query languages comparison of cypher, gremlin and native access in neo4j. 2013.
[44] H U, W.; Q U, 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] J ACOBSON , I.; M.C HRISTERSON .; J ONSSON , P.; OVERGAARD, G. Object-Oriented
Software Engineering — A Use Case Driven Approach. Addison-Wesley, 1992.
[47] J AIN , A.; K HAN , P. I.; V ERMA , 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] K IM , W. Introduction to object-oriented databases. MIT Press, Cambridge, MA,
USA, 1990.
[49] K IRYAKOV, A.; DAMOVA , M. Storing the semantic web: Repositories. In: Domingue, J.; Fensel, D.; Hendler, J., editors, Handbook of Semantic Web Technologies, p.
231–297. Springer Berlin Heidelberg, 2011.
[50] L AKSHMAN , A.; M ALIK , P. Cassandra: a decentralized structured storage system.
SIGOPS Oper. Syst. Rev., 44(2):35–40, Apr. 2010.
[51] L EHMANN , J.; I SELE , R.; J AKOB , M.; J ENTZSCH , A.; KONTOKOSTAS , D.; M ENDES ,
P. N.; H ELLMANN , S.; M ORSEY, M.; VAN K LEEF, P.; AUER , S.; B IZER , C. DBpedia -
Referências Bibliográficas
113
a large-scale, multilingual knowledge base extracted from wikipedia. Semantic
Web Journal, 2014.
[52] M C G UINNESS , D. L.; VAN H ARMELEN , F.
OWL web ontology language over-
view. W3C recommendation, W3C, Feb. 2004. http://www.w3.org/TR/2004/RECowl-features-20040210/.
[53] M ILLER , G. A. Wordnet: A lexical database for english. COMMUNICATIONS OF
THE ACM, 38:39–41, 1995.
[54] M INSTER , B.; C AMPBELL , J.; D OZIER , J.; F LEMING , J.; G ILLE , J.; H ARTMANN ,
D.; J EZEK , K.; K IDDER , S.; R AMANKUTTY, N.; T HOMPSON , A.; OTHERS . Earth
observations from space: The first 50 years of scientific achievements. In: AGU
Fall Meeting Abstracts, volume 1, p. 08, 2007.
[55] M ONIRUZZAMAN , A. B. M.; H OSSAIN , S. A. Nosql database: New era of databases
for big data analytics - classification, characteristics and comparison. CoRR,
abs/1307.0191, 2013.
[56] O LIVÉ , A. Conceptual Modeling of Information Systems. Springer, 2007.
[57] O PEN G OV DATA . Eight principles of open government data. http://resource.
org/8_principles.html, acessado em maio de 2013, 2007.
[58] O PEN K NOWLEDGE F OUNDATION . The Open Knowledge Foundation EMPOWERING THROUGH OPEN KNOWLEDGE. http://www.okfn.org, acessado em
maio de 2013, 2013.
[59] PADHY, R. P.; PATRA , M. R.; S ATAPATHY, S. C. RDBMS to NoSQL: Reviewing
Some Next-Generation Non-Relational Database’s? International Journal of Advanced Engineering Science and Technologies, 11(1), 2011.
[60] PAPAPANAGIOTOU, P.; K ATSIOULI , P.; T SETSOS , V.; A NAGNOSTOPOULOS , C.; H AD JIEFTHYMIADES ,
S. RONTO: Relational to ontology schema matching. AIS SIG-
SEMIS BULLETIN, 3(3-4):32–36, 2006.
[61] P ICCININI , H.; L EMOS , M.; C ASANOVA , M. A.; F URTADO, 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.
Referências Bibliográficas
114
[62] P OLFLIET, S.; I CHISE , R. Automated mapping generation for converting databases into linked data. In: Polleres, A.; Chen, H., editors, ISWC Posters & Demos,
volume 658 de CEUR Workshop Proceedings. CEUR-WS.org, 2010.
[63] P RESSMAN , R. S. Software Engineering: A Practitioner’s Approach. McGraw-Hill,
european edition, 1994. Adapted by Darrel Ince.
[64] P RESSMAN , R. S. Software Engineering: A Practicioner’s Approach. McGraw
Hill, 5th edition, 2001.
[65] P RIYATNA , F.; A RANDA , C. B.; C ORCHO, 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] P RIYATNA , F.; C ORCHO, O.; S EQUEDA , J. Formalisation and experiences of r2rmlbased 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] R AMANATHAN , S.; G OEL , S.; A LAGUMALAI , 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] S AHOO, S. S.; H ALB , W.; H ELLMANN , S.; I DEHEN , K.; J R , T. T.; AUER , S.; S E QUEDA ,
J.; E ZZAT, A. A survey of current approaches for mapping of relational
databases to rdf, 01 2009.
[69] S ALAS , P.; V ITERBO, J.; B REITMAN , K.; C ASANOVA , 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] S MITH , J.; S TUTELY, R. SGML: the user’s guide to ISO 8879. Ellis Horwood Series
in Computers and their Applications. E. Horwood, 1988.
[71] S OMMERVILLE , I.; M ELNIKOFF , S.; A RAKAKI , R.; DE A NDRADE B ARBOSA , E. Engenharia de software. Pearson Prentice Hall, 2008.
[72] S OMMERVILLE , 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.
Referências Bibliográficas
115
[73] S RIDEVI , K.; U MA R ANI , 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] S TAAB , S.; E RDMANN , M.; M AEDCHE , A.; D ECKER , 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] S TEVENSON , A. Oxford Dictionary of English. Oxford reference online premium.
OUP Oxford, 2010.
[76] T HE U NICODE C ONSORTIUM . The Unicode Standard. Technical Report Version
6.0.0, Unicode Consortium, Mountain View, CA, 2011.
[77] VAVLIAKIS , K. N.; G ROLLIOS , T. K.; M ITKAS , 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 A
Bancos de Dados Relacionais e NoSQL
Entender a diferença entre um banco de dados relacional e um banco de dados
NoSQL, consiste primeiro em compreender que eles representam dois paradigmas distintos 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 que
um 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 sistema
pode prover no máximo duas dessas três características simultaneamente.
Se o sistema possui consistência forte e alta disponibilidade (Sistema CA), esse
sistema não possui tolerância ao particionamento, dessa forma, esse sistema torna-se
problemático caso um nó do cluster fique indisponível.
Existem sistemas que precisam de consistência forte e tolerância ao particionamento (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 ser
rejeitada.
Por fim, existem sistemas que necessitam de alta disponibilidade, não podendo
nunca 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 de
inconsistência, ou seja, em algum momento o sistema se tornar consistente, mas em alguns
momentos ele está inconsistente.
Os paradigmas que definem bancos de dados relacionais e NoSQL, são consequê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ção
de um modelo ou de outro, ele limita-se a enumerar as características que definem esses
bancos de dados através de dois paradigmas que os definem chamados ACID e BASE.
Apêndice A
A.1
117
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 incompleta, 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 queda
no sistema ou falha de energia.
Esse modelo de transações adotados pelos bancos de dados relacionais, corresponde aos Sistemas CA do Teorema CAP. Dessa forma, bancos de dados relacionais (
PostgreSQL, Firebird, SQL Server ), apresentam um modelo de transações que garante a
consistência e disponibilidade, mas não apresentam a propriedade de tolerância ao particionamento.
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 disponibilidade dos dados no que diz respeito ao Teorema CAP; haverá uma resposta a
qualquer 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 seu
modelo 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 ou
mais tarde, mas o sistema não verifica a consistência de cada transação antes de se
iniciar a próxima.
Esse modelo corresponde aos Sistemas CP (BigTable, HBase, MongoDB), e
Sistemas AP (Cassandra, Riak, Amazon Dynamo) do Teorema CAP.
APÊNDICE B
Ontologias
O objetivo desse trabalho não é explicar em detalhes cada uma das linguagens
utilizadas na Web Semântica. Entretanto, como esse trabalho recorrentemente referese a ontologias e a linguagem OWL, nesse apêndice são apresentados alguns termos
relacionados à 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 da
w3c 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íduos
ou instâncias das classes e as propriedades, também chamadas de relacionamentos, entre
estas 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 características próximas, dessa forma, uma classe define um conjunto de indivíduos que compartilham algumas propriedades.
Uma classe pode possuir um relacionamento hierárquico com outras classes, ou
seja, 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 que
compartilham algumas propriedades, o indivíduo representa a entidade que implementa
as 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ção
de um indivíduo. Assim como as classes uma propriedade pode apresentar um relacionamento hierárquico com outras propriedades, ou seja, duas propriedades podem se relacionar 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 C
Ferramentas Utilizadas
C.1
Apache Jena
Jena é uma ferramenta open source, desenvolvida pelo HP Labs até outubro de
2009 e atualmente sobre responsabilidade da Apache Software Foundation, destinada para
a 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 formatos de dados conhecidos como o OWL e o RDF. O framework pode ser dividido nas
seguinte partes:
1. RDF
(a) API RDF: essa API é responsável pela manipulação dos dados RDF, permitindo sua serialização em formatos como o RDF/XML, N3 e Turtle.
(b) ARQ: ferramenta para realizar consultas SPARQL 1.1, permitindo acesso
remoto 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 enriquecimento da semântica dos dados RDF.
(b) API de Inferência: conjunto de regras de inferência preestabelecidos sobre
os dados RDF, possui suporte a regras de inferência definidas pelo usuário.
No desenvolvimento do Anotador Semântico de Banco de Dados, foram utilizados a API de Ontologias, API de Inferência, API RDF e o módulo ARQ.
Apêndice C
C.2
121
JAWS
Como citado na seção 3.3, a WordNet é um dicionário léxico com dados sobre
substantivos, verbos, adjetivos e advérbios agrupados em conjuntos de sinônimos cognitivos chamados synsets.
Apesar de existirem formas de acesso a WordNet por meio de SPARQL Endpoints ou mesmo trazer o seu conteúdo para um banco de dados relacional, neste trabalho
optou-se por utilizar uma API em Java, para manipulação do conteúdo da WordNet na
forma de objetos.
O JAWS ( acrônimo para Java API for WordNet Searching ) é uma API desenvolvida para consultas a base de dados da WordNet nas suas versões 2.1 e 3.0, onde o
resultado das consultas é classificado de acordo com os sinônimos, antônimos, hiperônimos, hipônimos, merônimos e parônimos de um synset 1 .
C.3
GTranslate
Gtranslate é uma API open-source desenvolvida em Java, que oferece suporte
a maioria dos recursos utilizados pelo Google Translator2 . Essa API foi utilizada na
aplicaçã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 qual
a ontologia ou os bancos de dados estejam definidos, assim como no processo de
reconhecimento da linguagem natural sendo utilizado por essas ontologias ou bancos de
dados.
1 http://lyle.smu.edu/
tspell/jaws/, último acesso em Janeiro de 2015
2 https://code.google.com/p/java-google-translate-text-to-speech/source/checkout,
neiro de 2015
último acesso em Ja-
APÊNDICE D
Modelo de Dados
Nesta apêndice, são apresentados os detalhes do banco de dados utilizado internamente pelo Anotador Semântico de Banco de Dados. O banco de dados utilizado foi
um 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 utilizadas
por 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ção
entre a categoria e o SPARQL Endpoint correspondente. O Código D.1 corresponde ao
SQL 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 ,
‘nome ‘ TEXT NOT NULL,
‘sql ‘ TEXT NOT NULL,
‘ sqlparameter ‘ TEXT ,
‘ endpoint ‘ TEXT NOT NULL
);
A seguir apresenta-se uma breve descrição sobre cada coluna:
1.
2.
3.
4.
id: chave primária auto incrementável da tabela.
nome: nome utilizado para definir a categoria.
sql: consulta, geralmente em SPARQL, utilizada contra o repositório semântico.
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 Endpoint ou Web Service.
D.2
Tabelas Utilizadas pelo Extrator
O Extrator possui uma única tabela, utilizada para armazenar a relação entre a
categoria e o domínio web correspondente. O Código D.2 corresponde ao SQL necessário
para 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 ,
‘nome ‘ TEXT NOT NULL,
‘url ‘ TEXT NOT NULL,
‘caminho ‘ TEXT NOT NULL,
‘ template ‘ TEXT
);
A seguir apresenta-se uma breve descrição sobre cada coluna:
id: chave primária auto incrementável da tabela.
nome: nome utilizado para definir a categoria.
url: endereço do domínio do qual se realiza a busca.
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 coluna
caminho.
1.
2.
3.
4.
D.3
Tabelas Utilizadas pelo Analisador Léxico/Sintático
O Analisador Léxico/Sintático possui uma única tabela, utilizada para armazenar
as traduções realizadas pelo gtranslate. O Código D.3 corresponde ao SQL necessário para
a criação dessa tabela de banco de dados.
Apêndice D
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 )
);
A seguir apresenta-se uma breve descrição sobre cada coluna:
1.
2.
3.
4.
lg_text: texto plano utilizado no processo de tradução.
lg_from: indicador de duas letras que define o idioma de origem.
lg_to: indicador de duas letras que define o idioma de destino.
lg_value: texto plano traduzido.
124