Mapeamento de Bancos de Dados para Domínios Semânticos

Transcrição

1 UNIVERSIDADE FEDERAL DE GOIÁS INSTITUTO DE INFORMÁTICA JÁDERSON ARAÚJO GONÇALVES DA CRUZ Mapeamento de Bancos de Dados para Domínios Semânticos Goiânia 2015

2

3 JÁDERSON ARAÚJO GONÇALVES DA CRUZ 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. Área de concentração: Sistemas Ciências da de Informação. Computação Orientador: Prof. Cedric Luiz de Carvalho Goiânia 2015

4 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 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, 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.

5

6 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

7 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.

8 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.

9 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.

10 Resumo da Cruz, Jáderson A. G.. Mapeamento de Bancos de Dados para Domínios Semânticos. Goiânia, p. 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.

11 Abstract da Cruz, Jáderson A. G.. Database Mapping for Semantic Domains. Goiânia, p. 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.

12 Sumário Lista de Figuras 13 Lista de Tabelas 14 Lista de Códigos de Programas 15 1 Introdução Motivação Objetivo Metodologia Organização da Dissertação 20 2 Fundamentos Teóricos Modelos de Bancos de Dados Bancos de Dados Relacionais Bancos de Dados Orientados a Objetos Bancos de Dados Chave-Valor Bancos de Dados Orientados a Colunas Bancos de Dados de Documentos Bancos de Dados Orientados a Grafos Web Semântica Unicode e Uniform Resource Identifiers (URIs) Extensible Mark-up Language (XML) Resource Description Framework (RDF) Resource Description Framework Schema (RDFS) Web Ontology Language (OWL) Lógica, Prova e Validação Dados Abertos Dados Abertos Científicos Dados Abertos Governamentais 31 Princípios dos Dados Abertos Governamentais 31 Leis dos Dados Abertos Governamentais 32 Dados Abertos no Mundo 32 Dados Abertos no Brasil Dados Abertos Ligados Sobre o Capítulo 36

13 3 Bases de Conhecimento e suas Ontologias DBPedia Ontologia DBPedia Acessando a DBPedia GeoNames Ontologia GeoNames Acessando o GeoNames WordNet Ontologia WordNet Acessando o WordNet YAGO Ontologia YAGO Acessando o YAGO Freebase Ontologia Freebase Acessando o Freebase Interligando Dados Abertos Sobre o Capítulo 48 4 Trabalhos Relacionados Morph RDB RDOTE RDB2OWL MARSON RONTO AuReLi StdTrip MASTRO Resumo dos Sistemas Analisados Sobre o Capítulo 56 5 Solução Proposta Mapeamento Semântico de Banco de Dados Etapas da Solução Mapeando entre Bancos de Dados e Ontologia 59 Classificação Sintática 60 Definindo Candidatos 60 Filtrando Candidatos Mapeamento para Repositórios Semânticos 64 Categorizando o Acesso a Repositórios Semânticos 65 Analisando Agrupadores Primários 68 Lematização 68 Associando Categorias com Agrupadores Primários 68 Analisando Agrupadores Secundários Gerando Formatos Abertos de Mapeamento de Dados Sobre o Capítulo 71

14 6 Projeto do Sistema de Mapeamento de Banco de Dados Atores Requisitos da Aplicação Requisitos Funcionais Requisitos Não Funcionais Modelagem, Arquitetura e Arquivo de Resultado Arquitetura 77 Interface 77 Motor de Execução 77 Analisador Léxico/Sintático 78 Extrator 79 Cliente SPARQL Arquivo de Resultado Modelagem Desenvolvimento da Aplicação Tecnologias Empregadas Bases de Dados Linguísticas Categorias Utilizadas Exemplo de Utilização Sobre o Capítulo 96 7 Análise de Resultados Resultados da Aplicação - Agrupadores Primários Experimento Experimento Experimento Resultados da Aplicação - Agrupadores Secundários Experimento Experimento Experimento Resultados da Aplicação - Associação Semântica Sobre o Capítulo Conclusão e Trabalhos Futuros Contribuições Trabalhos Futuros 107 Referências Bibliográficas 109 A Bancos de Dados Relacionais e NoSQL 116 A.1 O Modelo Relacional - ACID 117 A.2 O Modelo NoSQL - BASE 117 B Ontologias 118 B.1 Elementos Básicos 118 B.1.1 Classe 118 B.1.2 Indivíduos ou Instâncias 118 B.1.3 Propriedades ou Relações 119

15 C Ferramentas Utilizadas 120 C.1 Apache Jena 120 C.2 JAWS 121 C.3 GTranslate 121 D Modelo de Dados 122 D.1 Tabelas Utilizadas pelo Cliente SPARQL 122 D.2 Tabelas Utilizadas pelo Extrator 123 D.3 Tabelas Utilizadas pelo Analisador Léxico/Sintático 123

16 Lista de Figuras 1.1 Diagrama de Fluxo do Projeto 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 Linguagens Utilizadas na Web Modelo Adaptado de Integração de Dados de Beners-Lee Esquema de Mapeamento do RD2OWL[22] Mapeamento Semântico de Banco de Dados 58 (a) Tabelas para Nodos 58 (b) Banco de Dados Mapeado Tabelas x Colunas Processo de Associação do Banco de Dados com Ontologia de Referência Tabela x Colunas Complementação de Colunas Complementação de Linhas Modelo de Acesso de Dados por Ontologia 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 92

17 Lista de Tabelas 2.1 As 5 estrelas do modelo Gov 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 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] Resumo Trabalhos Relacionados Modos de agrupamento de dados por paradigma de banco de dados Relação entre synsets da ontologia com synsets do banco de dados Categorias Extrator Categorias Cliente SPARQL Banco de Dados x Ontologias Entrada e Saída Agrupador Primário - Experimento 1 98 (a) Entradas 98 (b) Saídas Entrada e Saída Agrupador Primário - Experimento 2 99 (a) Entradas 99 (b) Saídas Entrada e Saída Agrupador Primário - Experimento (a) Entradas 100 (b) Saídas Entrada/Saída Agrupador Secundário - Experimento (a) Entradas 101 (b) Saídas Entrada/Saída Agrupador Secundário - Experimento (a) Entradas 102 (b) Saídas Entrada/Saída Agrupador Secundário - Experimento (a) Entradas 103 (b) Saídas Categorias X Experimentos 104

18 Lista de Códigos de Programas 5.1 Consulta SPARQL a DBPedia Consulta SPARQL a Dailymed Exemplo de Consulta SPARQL Tabela Verbetes Individual x Colunas SQL Individual x Colunas 95 D.1 Tabela de Categorias por SPARQL Endpoint 122 D.2 Tabela de Categorias por Extrator 123 D.3 Tabela de palavras traduzidas por idioma 124

19 Introdução CAPÍTULO 1 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

20 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

21 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 PDF 1. 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]

22 1.2 Objetivo 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 Figura 1.1. A realização dessa pesquisa foi dividida em etapas, como pode ser observado na

23 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

24 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.

25 Fundamentos Teóricos CAPÍTULO 2 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 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

26 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 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 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.

27 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 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 ).

28 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] 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

29 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 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 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 CouchDB. Exemplos de bases de dados de documentos seriam o MongoDB e o Apache

30 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] 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].

31 2.2 Web Semântica 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

32 2.2 Web Semântica 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 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] 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] 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].

33 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] 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 Lógica, Prova e Validação forma: Segundo Sridevi e Umarani[73], é possível definir essas três camadas da seguinte 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

34 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 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] 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-

35 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

36 2.3 Dados Abertos 33 um conjunto de várias informações públicas. O portal de dados abertos do Reino Unido 1 possui espaço para comunidades virtuais, wiki, RSS e envio de novas aplicações web pelo cidadão. O governo da Nova Zelândia 2 e da Austrália 3 criaram seus portais de dados abertos no ano de 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 abertos 4, 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 digital 5. 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 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 ( ). 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 acessado em junho de acessado em junho de acessado em junho de acessado em junho de acessado em junho de 2015

37 2.3 Dados Abertos 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.

38 2.3 Dados Abertos 35 Tabela 2.2: Custos e benefícios do modelo de dados web Como consumidor Pode vê-lo Pode imprimi-lo Pode armazená-lo localmente (no seu disco rígido) Pode inserir os dados manualmente em outro sistema Como publicador É fácil publicar Tabela 2.3: Custos e benefícios do modelo de dados web Como consumidor, pode fazer tudo que o anterior fazia, mais: Pode processar diretamente com software proprietário para agregá-lo, executar cálculos, visualizá-lo, etc Pode exportá-lo para outro formato (estruturado). Como publicador... É fácil publicar. Tabela 2.4: Custos e benefícios do modelo de dados web Como consumidor, pode fazer tudo que o anterior fazia, mais: Não tem que pagar por um formato em que uma única entidade tem controle exclusivo Como publicador É fácil publicar. 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.

39 2.4 Sobre o Capítulo 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.

40 Bases de Conhecimento e suas Ontologias CAPÍTULO 3 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.

41 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.

42 3.1 DBPedia 39 Figura 3.2: Modelo Adaptado de Integração de Dados de Beners- Lee 3.1 DBPedia DBPedia[51] é uma base de conhecimento multilinguístico construída em grande escala para agrupar informações enciclopédicas provenientes do projeto Wikipedia. A enciclopédia digital Wikipedia é o sexto website mais acessado do planeta 1. 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 acessado em agosto de 2014

43 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 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 DBPedia 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 Endpoint 3 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 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

44 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 GeoNames 4, 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 WGS Ontologia GeoNames O projeto GeoNames apresenta um esquema ontológico simples e aberto de representação de dados 6, 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 acessado em julho de World Geodetic System. Norma usada em cartografia de origem geocêntrica, utilizada principalmente pelo Sistema de Posicionamento Global - (GPS) 6

45 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 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 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.

46 3.4 YAGO2 43 Tabela 3.1: Exemplo de Relações Léxicas na WordNet Sinônimos significa o mesmo que Bonito significa o mesmo que belo Hiperônimos termo geral para Mobília é o termo geral para sofá Hipônimos tipo de Sofá é um tipo de mobília Merônimos parte de membro de Galho é parte de uma árvore Uma pessoa é membro de um grupo Holônimos tem parte membro Carro tem a roda como parte Um grupo tem uma pessoa como membro Antônimos contrário de 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ânticas 7. No total, a WordNet possui cerca de synsets, sendo substantivos, verbos, adjetivos e 3621 advérbios 8. 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 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 entidades 9, tais como pessoas, organizações, cidades, entre outros. Estima-se que existam cerca de acessado em julho de informação obtida em Julho de 2014

47 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 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 classes, dez milhões de entidades e cerca de 120 milhões de fatos Acessando o YAGO2 É possível baixar todo o banco de dados e ontologia do YAGO2 no site oficial do projeto 10 em formatos de texto ttl e tsv. Além disso YAGO2 oferece uma interface web de 10

48 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 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 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.

49 3.6 Interligando Dados Abertos 46 Ao todo, o Freebase possui cerca de de tópicos, fatos divididos em cerca de 77 categorias 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 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

50 3.6 Interligando Dados Abertos 47 Tabela 3.2: Ligações da DBPedia para outros repositórios[51] Repositório Predicados Quantidade Amsterdam Museum owl:sameas 627 BBC Wildlife Finder owl:sameas 444 Book Mashup rdf:type 9100 owl:sameas Bricklink dc:publisher CORDIS owl:sameas 314 Dailymed owl:sameas 894 DBLP Bibliography owl:sameas 196 DBTune owl:sameas 838 Diseasome owl:sameas Drugbank owl:sameas EUNIS owl:sameas Eurostat (Linked Stats) owl:sameas 253 Eurostat (WBSG) owl:sameas 137 CIA World Factbook owl:sameas 545 flickr wrappr dbp:hasphoto Collection Freebase owl:sameas GADM owl:sameas GeoNames owl:sameas GeoSpecies owl:sameas GHO owl:sameas 196 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 678 Revyu owl:sameas 6 Sider owl:sameas TCMGeneDIT owl:sameas 904 UMBEL rdf:type US Census owl:sameas WikiCompany owl:sameas WordNet dbp:wordnet type YAGO2 rdf:type Somatório

51 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 Quantidade de Predicados Quantidade de Ligações okaboo.com 4 2,407,121 tfri.gov.tw ,459 naplesplus.us 2 212,460 fu-berlin.de 7 145,322 freebase.com ,619 geonames.org 3 125,734 opencyc.org 3 19,648 geospecies.org 10 16,188 dbrec.net 3 12,856 faviki.com 5 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.

52 Trabalhos Relacionados CAPÍTULO 4 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 Group 1 como continuação do projeto ODEMapster 2. 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 acessado em junho de acessado em junho de 2015

53 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,

54 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 N 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

55 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.

56 4.6 AuReLi 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 Server 3 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 acessado em junho de 2015

57 4.8 MASTRO 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]. 3. 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. 4. 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. 5. Conclusão. Se nada funciona, os usuários são direcionados para o Best Practice Recipes for Publishing RDF Vocabularies[13]. 6. Saída. O processo gera dois artefatos: (1) um arquivo de configuração, para servir para a parametrização de uma ferramenta de triplificação padrão. (2) uma ontologia que contém os mapeamentos do esquema de banco de dados original para o vocabulários padrão RDF. 4.8 MASTRO MASTRO[23] é uma ferramenta desenvolvida na linguagem de programação JAVA, criado na Universidade de Roma La Sapienza e na Universidade Livre de Bozen- Bolzano. Essa ferramenta foi desenvolvida com o objetivo de gerenciar sistemas de 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.

58 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 Restrição Relacional NoSQL Integrado MorphRDB Manual não sintático - Sim Não Não sem ontologia RDRoute Manual não sintático - Sim Não Não sem ontologia RDB2OWL Manual não sintático - Sim Não Não com ontologia Marson Automático sintático - Sim Não Não com ontologia Ronto Semiautomático - Sim Não Não sintático com ontologia AuReLi Automático sintático - Sim Não Parcial com ontologia StdTrip Manual não sintático Banco de Sim Não Não sem ontologia dados na 3 a forma normal Mastro Manual não sintático Ontologia Sim Não Não com ontologia em DL- Lite 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

59 4.10 Sobre o Capítulo 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. 3. Restrição. apresenta alguma exigência do sistema. 4. Relacional. indica se o sistema tem suporte ao mapeamento de bancos de dados do tipo relacional. 5. NoSQL. indica se o sistema tem suporte ao mapeamento de bancos de dados do tipo NoSQL. 6. Integrado. o sistema gera um mapeamento integrado com a nuvem semântica de dados, observa-se que apenas o sistema AuReLi possui um mecanismo parcial de integração de dados, onde os resultados são validados com a DBPedia 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.

60 Solução Proposta CAPÍTULO 5 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.

61 5.1 Mapeamento Semântico de Banco de Dados 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.

62 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 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 Chave- Valor, 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.

63 5.2 Etapas da Solução 60 Tabela 5.1: Modos de agrupamento de dados por paradigma de banco de dados Paradigma Agrupador Primário Agrupador Secundário Relacional Tabelas Colunas Orientado a Objetos Classes de Objeto Propriedades de Objeto Chave-Valor Chaves Chaves Orientado a Colunas Família de Colunas Colunas Orientado a Documentos Coleções Atributo Orientado a Grafos Nós 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.

64 5.2 Etapas da Solução 61 Relação Sinônimos Tabela 5.2: Relação entre synsets da ontologia com synsets do banco de dados 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-

65 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

66 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 T 1,T 2,...,T n representam subconjuntos de candidatos a entidades da tabela provenientes do conjunto original e os conjuntos C 1,C 2,...,C n 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: T R = T 1 T 2... T n. 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.

67 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 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

68 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-

69 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 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. org / / 0 7 / owl#> PREFIX xsd : < h t t p : / / www. w3. org / / XMLSchema#> PREFIX r d f s : < h t t p : / / www. w3. org / / 0 1 / rdf schema#> PREFIX rdf : < h t t p : / / www. w3. org /1999/02/22 rdf syntax ns #> PREFIX : < h t t p : / / d b p e d i a. org / 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. org / 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. org / > SELECT? e n t i t y WHERE {? e n t i t y rdf : t y p e < h t t p : / / d b p e d i a. org / 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

70 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 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. uni 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. uni mannheim. de / dailymed / r e s o u r c e / > PREFIX r d f s : < h t t p : / / www. w3. org / / 0 1 / rdf schema#> PREFIX d2r : < h t t p : / / s i t e s. wiwiss. fu b e r l i n. de / s u h l / b i z e r / d2r s e r v e r / c o n f i g. rdf #> PREFIX map : < f i l e : / C : / apps / dailymed / dailymed. n3#> PREFIX owl : < h t t p : / / www. w3. org / / 0 7 / owl#> PREFIX xsd : < h t t p : / / www. w3. org / / XMLSchema#> PREFIX rdf : < h t t p : / / www. w3. org /1999/02/22 rdf syntax ns #> PREFIX dailymed : < h t t p : / / wifo5 04. i n f o r m a t i k. uni 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 rdf : t y p e < h t t p : / / wifo5 04. i n f o r m a t i k. uni 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.

71 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

72 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 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 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.

73 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 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 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.

74 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.

75 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.

76 6.1 Atores 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 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,

77 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.

78 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 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 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.

79 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.

80 6.3 Modelagem, Arquitetura e Arquivo de Resultado 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.

81 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

82 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.

83 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 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.

84 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 :// 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)

85 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 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

86 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 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.

87 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

88 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.

89 6.4 Desenvolvimento da Aplicação 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 ; 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 Desktop 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 Firefox 1. 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 último acesso em Dezembro de 2014

90 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 último acesso em Novembro de 2014

91 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 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]

92 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 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,

93 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], 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

94 6.4 Desenvolvimento da Aplicação 91 Categoria agrotóxico anatomia animal artista atleta ator ave bactéria bebida cantor cidade comida cor doença doença droga droga empresas empresas farmaceuticas escritor evento flores fungo gene instituições de ensino livro moeda musgo música país peixe periódico acadêmico personagem fictício pessoa pesticida província quadrinhos substância química Tabela 6.2: Categorias Cliente SPARQL Repositório

95 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 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 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