UNIVERSIDADE FEDERAL DE SANTA CATARINA – UFSC
CENTRO TECNOLÓGICO – CTC
CURSO DE CIÊNCIAS DA COMPUTAÇÃO
D
ESENVOLVIMENTO DE UMAB
ASE DEC
ONHECIMENTO PARAF
INSD
ES
UPORTES
EMÂNTICO AA
PLICAÇÕESRENATO DA MOTTA BUSTAMANTE
F
LORIANÓPOLIS–
SC
RENATO DA MOTTA BUSTAMANTE
D
ESENVOLVIMENTO DE UMAB
ASE DEC
ONHECIMENTO PARAF
INSD
ES
UPORTES
EMÂNTICO AA
PLICAÇÕESUNIVERSIDADEFEDERALDESANTACATARINA
FLORIANÓPOLIS–SC 2013/6
TRABALHO DE CONCLUSÃO DE CURSO
APRESENTADO COMO PARTE DOS REQUISITOS PARA OBTENÇÃO DO GRAU DE BACHAREL EM
RENATO DA MOTTA BUSTAMANTE
D
ESENVOLVIMENTO DE UMAB
ASE DEC
ONHECIMENTO PARAF
INSD
ES
UPORTES
EMÂNTICO AA
PLICAÇÕESTrabalho de conclusão de curso apresentado pelo acadêmico Renato da Motta Bustamante do Curso de Ciências da Computação da Universidade Federal de Santa Catarina, como requisito para obtenção do grau de Bacharel em Ciências da Computação.
Florianópolis, Novembro de 2012.
Orientador:
_____________________________________________ Prof. Dr. Ronaldo dos Santos Mello
Banca Examinadora:
_____________________________________________ Prof.Me. José Eduardo De Lucca
_____________________________________________ Prof. Dr.Renato Fileto
Agradecimentos
Agradeço a minha família por toda ajuda, motivação e apoio e por estarem presentes em todos os momentos em que precisei ao longo de toda minha graduação e minha vida.
Aos meus grandes amigos e colegas que estiveram presentes em momentos de estudos e descontração tornando estes longos anos de curso, divertidos e descontraídos.
Ao meu orientador, professor Ronaldo Mello por me ajudar com dicas e conselhos na realização deste trabalho.
Aos professores José Eduardo e Renato Fileto por participarem da banca avaliadora e por contribuírem com suas sugestões e criticas.
Resumo
Este trabalho tem como objetivo a criação de uma base de conhecimento ampla e bem estruturada com dados extraídos de diversas fontes publicas de dados nos mais diversos domínios, como a Wikipédia e Freebase, visando o suporte para aplicações que necessitam realizar inferências semânticas sobre dados extraídos da Web e/ou dados fracamente estruturados. Neste trabalho é apresentado como foi modelada a base proposta e quais métodos foram utilizados para extrair dados relevantes. Também é disponibilizada uma API para acesso a base, visando atender à demanda de acesso a grandes quantidades de dados de forma eficiente.
Sumário
1 Introdução. . . 8 1.1 Visão geral . . . 8 1.2 Objetivos . . . 8 1.3 Metodologia . . . 9 1.4 Organização da Monografia . . . 9 2 Bases de Conhecimento. . . 11 2.1 Freebase . . . 11 2.2 Wikipédia. . . 14 2.2.1 MediaWiki API. . . 15 2.2.2 DBpedia. . . 15 3 DeepEC. . . 184 Desenvolvimento da Base de Conhecimento. . . 20
4.1 Modelagem. . . 21
4.1.1 Criação das tabelas relacionais de dados e metadados da base. . . 21
4.2 Extração de Dados. . . 28
4.2.1 FreeBase. . . 28
4.2.2 DBpedia. . . 31
4.3 API da Base de Conhecimento . . . 35
4.3.1 Estrutura de Classes da API. . . 36
4.3.2 Métodos de Acesso para o Usuário. . . 38
5 Trabalhos Relacionados. . . 43
6 Conclusão. . . 44
Página | 7
Lista de Figuras
Figura 1: Grafo representando parte da estrutura de dados da Freebase. . . 12
Figura 2: Screenshot da sessão Query Editor da pagina web da Freebase . . . 14
Figura 3: Código de consulta http aos servidores da MediaWiki API. . . 15
Figura 4: Ligações semânticas entre servidores Linked Open Data . . . 17
Figura 5: Esquema do funcionamento do DeepEC . . . 18
Figura 6: Sequencia das etapas do desenvolvimento da base de conhecimento . . . 20
Figura 7: Busca MQL na base Freebase, pelas entidades de um determinado domínio . . . 22
Figura 8: Tabela de associação (ast_) pertencente ao domínio de “zoo” . . . 22
Figura 9: Exemplo de tabela com propriedades de multiplicidade e sem multiplicidade . . . 23
Figura 10: Tabelas que guardam informações sobre as estruturas das entidades e do banco . . 24
Figura 11: Trecho de código para a criação das tabelas associativas . . . 25
Figura 12: Tabela de metadados (zoos_all_combined_tables) do domínio “zoos” . . . 26
Figura 13: Relação das tabelas do domínio “zoos” da base de conhecimento. . . 27
Figura 14: Estrutura das classes Java para extração da Freebase. . . 28
Figura 15: Código MQL para query gerada pelo método de população. . . 30
Figura 16: Sequencia de tarefas realizadas pela classe “Populador.class” . . . 30
Figura 17: Tabela de dados da base de conhecimento remetente a entidade zoo. . . 31
Figura 18: Screenshot do OpenLinkiSPARQL . . . 32
Figura 19: Screenshot das telas do freebase e DBpedia aonde aparecem o wikiPageID . . . 33
Figura 20: Consulta MQL realizada na Freebase para buscar wikiPageID da entidade . . . 33
Figura 21: Parte do algoritmo utilizado para extrair dados da DBpedia . . . 34
Figura 22: Exemplo de Web Server usando notações Jax-RS . . . 36
Página | 8
1 Introdução
1.1 Visão geral
Com a crescente informatização dos mais variados tipos de atividades e serviços, cresce também uma área muito interessante da computação: os sistemas inteligentes. Tais sistemas dependem muitas vezes de grandes quantidades de dados e consultas rápidas para poderem tomar decisões, simular ações, prever acontecimentos e outras situações em que é necessário se ter um conhecimento sobre os dados em diferentes contextos. A partir desta necessidade de conhecimento surgiram as bases de conhecimento, que são repositórios de informações organizadas de forma a representar o conhecimento humano.
Atualmente, duas das grandes bases de conhecimento que disponibilizam seu conteúdo na internet são a Freebase¹ e a Wikipédia², as quais tiveram maior importância no decorrer deste projeto de conclusão de curso. No entanto, algumas bases de conhecimento não têm como prioridade o acesso por máquinas e sim por pessoas, que é o caso da Wikipédia, que não disponibiliza todo seu conteúdo para consultas a serem feitas por sistemas informatizados. Por outro lado, a base de dados da Freebase está toda disponível na Web para consultas feitas usando a API HTTP disponível pela própria empresa. Mesmo assim, ambas as bases ainda poderiam prover melhorias, tanto em suas APIs, tornando-as mais confiáveis e fáceis de utilizar, quanto no processamento das consultas, tornando-as mais rápidas. Por dependerem de APIs que utilizam Web Services, ambas acabam tendo atrasos demasiadamente grandes que envolvem atrasos de cada requisição feita pela rede e na codificação e decodificação dos dados para o envio pela rede, fazendo com que o processamento por máquinas e sistemas que dependam delas se torne lento ou inviável. Além disso, outro problema vem à tona quando se deseja extrair dados com mais rapidez e em maior volume, pois ambas as bases possuem limitações quanto à quantidade de requisições feitas.
1.2 Objetivos
Devido principalmente a esses problemas das bases de conhecimento atuais, este trabalho tem como objetivo criar uma nova base de conhecimento que esteja acessível a todos e que possa ser exportada caso seja necessário. A nova base de dados deve proporcionar buscas rápidas, com funções e consultas pré-projetadas, visando facilitar o acesso por parte dos usuários. Ela pode
Página | 9
também ser exportada para o servidor do laboratório do grupo de banco de dados da UFSC (LISA/GBD) para que os alunos também possam contribuir e consultar a base.
O trabalho visa também à colaboração com uma dissertação de mestrado do PPGCC, em que é proposto um processo de extração e catalogação de dados da “Deep Web”. A intenção é comparar os dados extraídos com as informações da base de conhecimento, para então inferir o domínio e as entidades conceituais aos quais estes dados pertencem.
1.3 Metodologia
Com relação ao desenvolvimento da base de conhecimento proposta, primeiramente, foi modelada uma base de dados relacional que facilite a realização de consultas pelo fato de não replicar dados dentro da mesma tabela para propriedades com multiplicidade. Para essas propriedades, acrescentamos uma tabela de associação que fica com uma referência a ela que, por sua vez, é mantida em outra tabela de metadados, onde é anotada a propriedade a qual a tabela associativa pertence e a qual tipo de entidade. Essa modelagem permite que a base de dados seja expansível em termos de domínios, dados e metadados. Utilizou-se como base para esta modelagem a estrutura usada pela base de conhecimento Freebase. Sendo assim, durante a primeira etapa do projeto, foi realizada a extração dos dados da Freebase bem como o mapeamento para a estrutura da base de conhecimento proposta. Logo em seguida, na segunda etapa do projeto foi implementada a extração de dados da DBpedia e a criação da API para prover acesso aos usuários.
1.4 Organização da Monografia
Bases de Conhecimento: Definem o conceito de base de conhecimento, exemplificando
bases atualmente conhecidas. Explica-se também as estruturas e as APIs de acesso das bases de conhecimento Freebase e Wikipédia.
DeepEC: Apresenta a proposta do trabalho de mestrado Augusto que faz uso da base de conhecimento proposta. Descrevendo o funcionamento do algoritmo desenvolvido pelo mestrando.
Desenvolvimento da Base de Conhecimento : É descrito como foi projetada a base de
Página | 10
foi realizada. Apresenta-se ainda a API criada para o acesso à base e as consultas disponíveis exemplificadas.
Trabalhos Relacionados Conclusão: Último capítulo é dedicado às aos trabalhos
relacionados, conclusões e trabalhos futuros.
________________________________________ ¹ https://www.freebase.com/
Página | 11
2
Bases de Conhecimento
Bases de conhecimento são coleções de dados organizados de forma a representar o conhecimento humano sobre determinados objetos, guardando informações, características, propriedades e associações que normalmente são separadas por domínios e entidades deste domínio (Knowledge_base- Wikipédia, 2013).
A construção de uma base de conhecimento tem como objetivo disponibilizar informações. Desta forma, é sempre necessário definir a quem a base de dados será disponibilizada, ou seja, se suas informações são voltadas a pessoas, máquinas ou ambos. Podem-se definir aprimoramentos que facilitem a consulta visando a comparação de propriedades, na utilização das bases de conhecimento por máquinas a fim de inferir informações, ou de consultas que facilitem a obtenção de informações sobre um determinado domínio ou entidade.
Atualmente, existem diversas bases de conhecimento, sendo duas delas as mais conhecidas e disponíveis gratuitamente na web: a Freebase e a Wikipédia.
2.1 Freebase
Segue a tradução da definição da base de dados encontrada no site da Freebase: “Freebase é um banco de dados de grafo. Isto significa que, em vez de utilizar as tabelas e
chaves encontradas na base de dados convencionais, a Freebase define a sua estrutura de dados como uma série de nós e um conjunto de ligações que estabelecem relações entre os nós. Devido a sua estrutura de dados não-hierárquica, a Freebase pode modelar relações muito mais complexas entre os elementos individuais do que um banco de dados convencional e está aberta para que os usuários insiram novos objetos e relacionamentos no grafo subjacente.” (Graph - Freebase, 2009).
Sobre a Freebase, pode-se citar como uma das melhores bases públicas projetadas e utilizadas para diversas pesquisas acadêmicas. Atualmente ela possui mais de 40 milhões de tópicos, 1.998 tipos e mais de 30.000 propriedades, crescendo a cada dia. Estes fatores motivaram a Freebase a ser a referência no projeto da base de conhecimento proposta neste trabalho. A Freebase, além de ter sua estrutura muito bem elaborada, tem como principal
Página | 12
objetivo a integração de outras bases e do acesso por pessoas que desejem acessar e alterar dados. A base de dados dispõe ainda de uma interface amigável para realizar consultas e APIs nas linguagens Java e PHP, sendo possível também o acesso via Web através de requisições HTTP.
Figura 1: Grafo representando parte da estrutura de dados da Freebase
Para entender o modelo de dados da Freebase (um exemplo é mostrado na Figura 1) é necessária uma compreensão dos seus conceitos, detalhados a seguir:
Grafos: Os dados armazenados na Freebase estão em uma estrutura de grafo. Um grafo é composto por nodos e arestas que conectam estes nodos. Na Freebase cada nodo é representado por um tipo;
Página | 13
Tópicos: A Freebase tem mais de 40 milhões de tópicos sobre entidades do mundo real, como pessoas e lugares. Como os dados da Freebase são representados em um grafo, alguns nodos possuem mais ligações que outros e outros possuem mais propriedades, dependendo de seus tipos;
Tipos e propriedades: Um determinado tópico pode ser visto sob muitas
perspectivas diferentes. Por exemplo, Michael Jackson pode ser visto como cantor, compositor, ator, etc. E para cara atribuição dada a Michael Jackson, podemos definir propriedades, como por exemplo, cantor: ele é um bom cantor? Já cantou em quais locais? etc. Neste caso, Michael Jackson é um nodo que pertence a diversos tipos, com ligações diferentes e propriedades diferentes para cada tipo associado a ele;
Domínios: Da mesma forma que as propriedades são agrupadas por tipos, os tipos são
agrupados em relações de mais alto nível, separando os tipos por assuntos de mesmo interesse e categoria.
Como comentado anteriormente, a Freebase possui uma API disponível em Java. Esta API durante o período da pesquisa deixou de ser utilizada e não é mais recomentada pela Freebase. Mesmo assim, por questões de conhecimento, segue o funcionamento desta API. Para seu funcionamento é necessário baixar os arquivos jar do site da Freebase-Java-API. Em seguida, é possível executar funções como freebase.mqlread(str_param), que realiza consultas à base e traz informações de propriedades, domínios e associações entre entidades. Estas funções são providas pela classe Freebase.class, encontrada no pacote baixado da API.
Com o descarte da API Java pela própria Freebase, ela recomenda que se use a API Web que, através de requisições HTTP com consultas MQL (Metaweb Query Language). MQL é a linguagem utilizada para estruturar consultas realizadas a base de conhecimento, que retornam strings em JSON contendo o resultado da consulta. A Figura 2 a seguir representa um screenshot do novo site disponibilizado pela Freebase, onde além de poder navegar entre os domínios e tópicos, é possível também realizar consultas MQL (lado esquerdo da figura) e visualizar o resultado delas (lado direito da figura).
Página | 14 Figura 2: Screenshot de uma sessão do Query Editor da pagina Web da Freebase
2.2 Wikipédia
A Wikipédia é um projeto que visa a criação de uma enciclopédia multilíngue que pode ser editada por qualquer pessoa, ou seja, qualquer um pode criar novos tópicos e acrescentar informações. O nome Wikipédia vem da junção de duas palavras: wiki, que significa rápido, e
pedia, que significa enciclopédia. A Wikipédia disponibiliza suas informações através da web
com um acesso muito rápido e é comparada a muitas enciclopédias tais como a Encyclopædia Britannica. A Wikipédia é atualmente uma ferramenta de pesquisa amplamente utilizada por estudantes, pesquisadores e professores que queiram contribuir ou consultar informações. Ela já atinge 26 milhões de artigos com mais de 784 839 em Português. Esta base de conhecimento tem como objetivo facilitar consultas humanas e tem sua estrutura voltada a atender esta demanda. Apesar de a Wikipédia prover API e atender requisições HTTP, nem todo o conteúdo da enciclopédia está disponível através deste tipo de consulta.
Página | 15
2.2.1 MediaWiki API
MediaWiki é uma API de código aberto desenvolvida em PHP. Inicialmente criada para prover acesso apenas para Wikipédia, atualmente ela fornece diversos serviços a outros projetos da Fundação Wikimedia. Trabalhando juntamente com a Wikipédia, ela oferece funções de alto nível de leitura e escrita em artigos publicados na base de conhecimento da enciclopédia. Os clientes podem, através de outros sistemas, obter dados e realizar mudanças automaticamente, fazendo uso de solicitações HTTP para o serviço web. A Figura 3 demonstra uma consulta de HTTP usando esta API. Em seguida são detalhados alguns parâmetros importantes usados nessa consulta:
http://en.wikipedia.org/w/api.php?format=json&action=query &titles=Main%20Page&prop=revisions&rvprop=content
Figura 3: Código de consulta http aos servidores da MediaWiki API
Format: Este parâmetro informa a WikiMedia Web Service API de qual tipo deve ser o retorno desta requisição. O parâmetro anotado como “format=json” significa que o
retorno devera ser do tipo JSON. Para obter outros formatos de retorno é possível trocar o tipo de retorno passando como parâmetro por outras opções como WDDX, XML, YAML e PHP.
Action: Action é o parâmetro responsável por informar qual ação deve ser tomada pela requisição enviada. O parâmetro mais utilizado é query. No trecho de código da Figura 3 ela está presente como “action=query”, significando que esta requisição deve efetuar
uma busca na base de conhecimento da Wikipédia.
2.2.2 DBpedia
DBpedia é um projeto iniciado pela Universidade Livre de Berlim e pela Universidade de Leipzig. Ele tem como objetivo extrair conteúdo estruturado a partir das informações criadas na Wikipédia. Estas informações estruturadas são então disponibilizadas na Web. A DBpedia
Página | 16
permite aos usuários consultar relacionamentos e propriedades associadas com recursos Wikipédia, incluindo links para outros conjuntos de dados relacionados.
Os artigos da Wikipédia consistem principalmente de texto livre, porém também incluem informações estruturadas incorporadas nos artigos, conhecidas como Infoboxes. Uma Infobox é uma tabela com informações que aparece ao lado direito das paginas da Wikipédia. O projeto DBpedia tem como missão extrair estas informações e colocar em um banco de dados consultável.
Devido a esta diferença em relação aos dados estruturados e não estruturados extraídos da DBPedia e da WikiMedia Web Service API, este trabalho de conclusão de curso dá preferência à utilização dos dados disponíveis pelo projeto DBPedia, que, por retornar dados estruturados, tornam mais fáceis de serem associados e inseridos na base de conhecimento construída nesse trabalho.
A DBpedia disponibiliza seus dados seguindo o novo padrão de compartilhamento de dados nas Web, o Linked Open Data, que interliga dados relacionados na Internet. Tal padrão que segue um formato muito semelhante à estrutura descrita pela Freebase. No entanto, o Linked Open Data relaciona dados de diversos sites do mundo inteiro, compartilhando dados em formato RDF e consultas SPARQL, as quais são mais bem explicadas na seção 4.2.2. A Figura 4 ilustra em um grafo os servidores (vértices) que mais disponibilizam dados na rede da DBPedia e as relações (arestas) associadas a dados de diversos outros servidores.
Página | 17
Figura 4: Ligações semânticas entre servidores Linked Open Data¹
________________________________________
Página | 18
3 DeepEC
Este trabalho foi motivado por uma dissertação de mestrado desenvolvida no GBD/UFSC que propõe uma abordagem para extração e catalogação de dados presentes em bancos de dados escondidos na Web, também denominado Web oculta ou Deep Web (Souza, 2013). Este capítulo descreve brevemente a abordagem proposta, intitulada DeepEC, que utiliza o suporte de uma base de conhecimento, base esta que foi desenvolvida neste trabalho de conclusão de curso.
A extração e catalogação de dados da Deep Web visa recuperar dados relevantes presentes em bancos de dados acessíveis através da Web, porém, sem que o usuário tenha conhecimento completo do seu esquema e principalmente do seu conteúdo. O objetivo é obter conhecimento presente nestas fontes de dados, que mantêm conteúdo sobre diversos domínios, e proporcionar consultas estruturadas de forma simplificada sobre estes dados.
A abordagem DeepEC tem essa finalidade, ou seja, ela realiza a extração e a catalogação de informações relevantes presentes em páginas HTML obtidas através do preenchimento e submissão de formulários Web que são portas de entrada para os bancos de dados escondidos. O processo executado pela DeepEC primeiramente extrai registros estruturados presentes nas paginas HTML e, em seguida, cataloga de forma estruturada, com o suporte de uma base de conhecimento, os dados extraídos em um banco de dados relacional. A Figura 5 mostra a arquitetura da DeepEC.
Página | 19
A primeira etapa (1) traz o conjunto de paginas (2) extraído da Web e enviado para o modulo de extração (3) que é responsável por identificar padrões e separar informações relevantes, retirando propagandas, menus e outras informações irrelevantes. Em seguida, é realizado um pós-processamento (4) junto com a base de conhecimento para remover mais informações irrelevantes e, então, os registros extraídos são enviados para o módulo de catalogação (5), que é responsável por catalogar as informações diferenciando valores de rótulos de atributos, com apoio da base de conhecimento (6), para identificar entidades que possam ser armazenadas em um banco de dados (7).
Durante a etapa de catalogação (5) o sistema DeepEC utiliza a base de conhecimento para descobrir a qual domínio determinado registro extraído pertence, comparando seus atributos mandatórios específicos de cada domínio. Após a descoberta do domínio é então iniciado o processo de identificação do significado do registro. Para isso, é utilizada a função de similaridade Jaro-Winkler. Ao fim da identificação do novo valor, este é então acrescentado a base de conhecimento, enriquecendo ainda mais o seu conteúdo.
Página | 20
4 Desenvolvimento da Base de Conhecimento
Este capítulo descreve a base de conhecimento desenvolvida neste trabalho, cuja principal finalidade é oferecer um suporte facilitado para a consulta de significados de objetos do mundo real em diferentes contextos. Esta consulta deve ser processada da forma mais eficiente possível, considerando o grande volume de dados que uma base de conhecimento possui. O diferencial desta base proposta é que ela agrega conhecimento de diversas bases públicas e foi estruturada em um banco de dados relacional, que oferece acesso simples e eficiente.
Para tanto, primeiramente foram estudadas bases de conhecimento que pudessem servir de referência para a construção da base proposta. Deste levantamento, definiu-se que a estrutura de dados mais adequada foi a da base de conhecimento Freebase, por manter seus dados armazenados de forma organizada, ou seja, separada por diferentes domínios, tipos de entidades e suas propriedades, conforme descrito na seção 2.1. Tal organização facilita pesquisas com relação à identificação do contexto de determinados dados. Na primeira versão do projeto, ela serviu de referencia para a criação, modelagem e população da base de dados relacional proposta para abrigar a base de conhecimento.
Atualmente há diversas formas de armazenamento, tal como o conjunto de triplas utilizado nos padrões da web semântica, no entanto para o desenvolvimento da base de conhecimento foi definido a utilização de uma forma mais convencional, os bancos de dados relacionais. Este tipo de modelo de armazenamento foi atribuído ao projeto com intuito de minimizar o tempo de implementação por ser um modelo bem conhecido, aproveitando também do amadurecimento dessa tecnologia que garante otimizações no acesso, também como vários SGBDs disponíveis no mercado.
O processo de desenvolvimento foi dividido em 3 etapas, como demonstrado na figura 6. Primeiramente a etapa de Modelagem define a estrutura da base de dados relacional que mantém a base de conhecimento. Em seguida a etapa de extração de dados que popula a base de dados modelada, com conhecimento de diversas fontes de dados públicas. Por fim, a criação de uma API de acesso possibilita que os usuários tenham acesso a toda informação armazenada na base de conhecimento.
Figura6: Sequencia das etapas do desenvolvimento da base de conhecimento
Página | 21
4.1 Modelagem
Para a modelagem da base, inicialmente pensou-se em definir exatamente a estrutura da base de conhecimento a partir dos dados obtidos da Freebase. Entretanto, os dados desta base, além de existirem em grande quantidade, possuem valores e propriedades muito distintas, dificultando qualquer tentativa de se definir uma modelagem geral para cada um deles. Na sequência, procurou-se por APIs que dessem apoio ao encontro de informações sobre as estruturas de cada entidade, como propriedades, domínios e tipos associados. Assim sendo, inicialmente foi usada a API Java para consultas à Freebase. Porém, ao longo do tempo, atualizações e mudanças constantes na API dificultaram sua utilização. Logo, foi preciso encontrar um novo método de busca, que foram as requisições em HTTP enviadas diretamente aos Web Services da Freebase. Este foi o mecanismo adotado para a extração de dados estruturais e informativos que ajudou na construção e modelagem da base de conhecimento relacional proposta neste trabalho.
4.1.1 Criação das Tabelas Relacionais e Metadados da Base
As primeiras informações extraídas da Freebase foram informações sobre as entidades, suas propriedades e relações de herança. Com estas informações, foi possível a criação de mais de 1000 tabelas de tipos de entidades, separadas em diferentes domínios. A Figura 7 a seguir mostra um exemplo de busca enviada para os servidores da Freebase que retorna informações sobre as entidades. Neste caso, a consulta se refere aos IDs dos tipos de entidades encontradas em um especifico domínio, o qual para o exemplo é mostrado como tableDomain. A linguagem utilizada no exemplo é a MQL (Metaweb Query Language).
A MQL tem uma forma de representar os dados estruturados muito similar ao JSON. Entretanto, para os valores aos quais se deseja consultar é atribuído o valor null ou [{*}] em casos de valores como arrays com mais de um valor de resposta. A busca deve trazer apenas as propriedades das entidades que contiverem valores exatamente iguais aos das propriedades com valores fixados, ou seja, diferentes de null e [{*}].
Página | 22 Figura7: Busca MQL na base Freebase pelas entidades de um determinado domínio
Seguinte à criação das tabelas, usando a consulta de IDs por domínio, surgiu a necessidade de se definir uma forma de estrutura para as propriedades e relacionamentos de cada tipo de entidade. Para as propriedades das entidades, definiu-se que as propriedades de tipos comuns como strings, integer, array de bits e outros que pudessem ser armazenados no banco de dados seriam mapeados diretamente com seus devidos valores primitivos. Porém, para as propriedades associativas múltiplas, que não podem ser representadas por apenas um valor primitivo por terem diversos valores associados a uma propriedade, foi então necessário que, para cada tabela correspondente a uma entidade conceitual no banco de dados, fosse anotado em forma de metadado, qual o nome da propriedade que a entidade associada pertence e qual tabela de associação detém os valores das associações entre as entidades. A Figura 8 traz um exemplo de uma tabela de associação do domínio de zoológicos. Nela são associados locais com zoológicos.
Página | 23
Esta estrutura de propriedades evitou que fossem necessários espaços em branco (exemplificado na Figura 8 com um quadrado vermelho) nas tabelas relacionais e ao mesmo tempo tornou nossa implementação dinâmica por possibilitar a inserção de novas propriedades sem requerer nenhuma alteração nos dados já contidos no banco de dados. Ao mesmo tempo em que evitamos espaços em branco e mantivemos a dinamicidade, para que não fosse necessário criar uma tabela a mais para cada entidade, diminuindo o desempenho, decidiu-se por criar apenas uma tabela de metadados por domínio que guardasse as informações de todas as propriedades associativas das entidades deste domínio, evitando, assim, o aumento demasiado do número de tabelas. Na Figura 9 a seguir é ilustrado como ficaria um exemplo de uma tabela sem usar tabelas associativas para guardar as propriedades com múltiplos valores e, em seguida, um exemplo desta mesma tabela considerando que a propriedade “location” está armazenada em outra tabela associativa.
Figura 9: Exemplo de tabela com propriedades de multiplicidade e sem multiplicidade
A Figura 10 a seguir demonstra de uma forma ilustrativa, as tabelas de metadados criadas para manter a estrutura da base de conhecimento. A primeira tabela mais a esquerda da figura
Página | 24
(all_tables) contém o nome de todas as tabelas que representam tipos de entidades no banco de dados. Em seguida, para fins de exemplo, é mostrada a tabela zoos, que guarda nomes das propriedades de cada tipo de entidade no domínio, neste caso, uma tabela no domínio de zoológicos. A terceira tabela, zoos_included_types, é explicada e exemplificada adiante. Por fim, a tabela zoos_all_combined_tables, conforme explicado anteriormente, a tabela responsável por guardar todas as propriedades associativas de todas as tabelas de entidades de um determinado domínio. Cada coluna dessa tabela guarda uma informação sobre a propriedade associativa, sendo que a primeira coluna, table, informa de qual tabela do domínio a propriedade pertence; a segunda coluna, property, armazena o nome desta propriedade, e por ultimo, a terceira coluna, indica qual tabela associativa guarda as associações entre as entidades.
Figura 10: Tabelas que guardam informações sobre as estruturas das entidades e do banco de dados
A seguir um trecho de código que demonstra parte da implementação desenvolvida para a criação das tabelas de associação das propriedades de cada entidade é mostrado na Figura 11. Maiores detalhes de implementação são apresentados nas próximas seções.
Página | 25 Figura11: Trecho de código para a criação das tabelas associativas
Neste trecho são executados métodos que alteram a estrutura do banco, criando propriedades reversíveis, isto é, propriedades que definem referências cruzadas entre as entidades relacionadas. Caso a propriedade descrita na tabela de metadados de seu domínio já esteja relacionada em algum dos sentidos, então ela apenas é associada à tabela já existente. Caso contrário, é criada uma tabela de associação iniciada com “ast_” concatenada com o nome do domínio e um número aleatório para evitar que, de forma probabilística, já tenha sido criada uma tabela com o mesmo nome. Por fim, é adicionada a associação a esta tabela gerada. Para as propriedades não reversíveis, é apenas criada uma tabela de associação com características iguais à tabela de associação citada anteriormente e então é adicionada a associação a ela.
É importante ressaltar também que, para ambos os casos referentes às propriedades associativas, é necessário que seja anotado na tabela de metadados o ID da tabela referente ao tipo da entidade, o nome da propriedade e qual tabela de associação representa essa propriedade. O exemplo retratado na Figura 12 demonstra uma tabela de metadados do domínio zoológicos onde, para cada propriedade, é especificada a tabela e a tabela que contem as associações.
Página | 26 Figura 12: Tabela de metadados (zoos_all_combined_tables) do domínio “zoos”
O terceiro tipo de tabela exemplificado na Figura 10 armazena informações sobre quais tipos de entidades incluem outros tipos. Por isso, o nome da tabela deixa esta informação explícita, como no caso de zoos_included_types. Um exemplo de um tipo de entidade que poderia incluir outro seria uma entidade empresa que inclui uma entidade zoológico. Desta forma, quando se desejar buscar informações de uma entidade é necessário realizar uma busca por todos os tipos incluídos nesse tipo de entidade.
Para facilitar a compreensão, um outro exemplo da estrutura modelada é apresentado na Figura 13. Ele detalha as tabelas referentes ao domínio zoo. À esquerda estão as tabelas de tipos de entidades: zoo_category, animal_captivity, zoo e zoo_animalezoo_exhibit. Já à direita estão as tabelas que mantêm informações de propriedades associativas entre as entidades deste domínio.
Página | 27 Figura 13: Relação das tabelas do domínio “Zoológico” da base de conhecimento
Página | 28
4.2 Extração de Dados
Uma vez modelada a base de conhecimento, foi iniciada a etapa de extração de dados da Web para populá-la. Conforme explicado anteriormente, esta extração foi realizada das fontes de dados Freebase e Wikipédia, sendo detalhada a seguir.
4.2.1 Freebase
Devido à forte influência da Freebase na modelagem da base de conhecimento proposta, optou-se por iniciar a extração de dados desta fonte de dados. A seguir é detalhado o projeto de implementação da extração de dados desta base.
Figura 14: Estrutura das classes Java para extração da Freebase
Na estrutura das classes Java do projeto (mostrado na figura 14), a classe principal que constrói a base de conhecimento é a classe Main.java e a classe responsável por popular a base de conhecimento é a Populador.java. As classes com notação “Helper” no final do nome são
Página | 29
classes que auxiliam a interação do Java com o banco de dados que, no caso deste trabalho, é o MySQL. Por fim, as classes de entidades do banco de dados relacional são encontradas no pacote tabelas e a classe ConnectorDB.java do pacote tcc que realiza a conexão com o MySQL.
A principal classe responsável pela extração de dados da Freebase é a Populador.java. Ela constrói consultas a serem executadas na Freebase e o retorno dessas consultas é direcionado para a inserção na base de conhecimento proposta.
Esta classe é dividida em dois métodos principais: “populaTabelas” e “completaEntidade”. O primeiro método executa uma consulta ao banco de dados relacional para saber quais tabelas de tipos de entidades foram construídas durante a parte de modelagem da base. Esta informação é disponibilizada através da classe AllTablesHelper.java. A partir daí, o procedimento é realizado para todos os tipos de entidade, ou seja, para todas as tabelas de dados do banco relacional. Para cada uma é realizada uma consulta aos servidores da Freebase, responsável por buscar um número de entidades, recuperando apenas os IDs das entidades. Em seguida, para cada ID é executado o segundo método “completaEntidade”, responsável por completar os dados da entidade com o respectivo ID.
O método “completaEntidade” constrói dinamicamente um scriptMQL a partir das informações da base de conhecimento obtidas com o auxilio das classesIncludedTypeHelper.java, CombinedTableHelper.java e TableInformationHelper.java. A montagem do script é realizada buscando informações do banco sobre as propriedades que a entidade possui, quais delas são associativas e quais delas são únicas. Para as propriedades únicas é necessário apenas que se procure pelo valor da propriedade. Já para as propriedades associativas é necessário procurar por informações sobre o tipo ao qual esta propriedade se associa. Com estas informações, é possível obter toda a informação necessária para popular a entidade.
Um exemplo de busca na linguagem MQL usando o ID igual a “/en/san_diego_wild_animal_park” é mostrado na Figura 15.
Página | 30 Figura 15: Código MQL para a consulta gerada pelo método de população “completaEntidade”
Após a execução do script que traz os valores das propriedades da entidade, outras rotinas percorrem o resultado de cada consulta colocando os valores de suas propriedades em suas devidas posições na base de conhecimento. O mesmo método que completa a entidade também é responsável por trazer as entidades a que a entidade principal se associa, visando evitar inconsistências de integridade referencial no banco de dados relacional.
Para tanto, viu-se como necessário, para cada associação a ser definida, primeiramente criar a entidade a qual esta vai ser associada. Para não entrar em uma recursão infinita, sempre tentando completar a entidade associada, decidiu-se acrescentar uma coluna “fetched” para todas as tabelas de entidades. Este valor booleano guarda a informação de que a entidade foi completada ou apenas criada para evitar a inconsistência de uma associação. A seguir a figura 16 demonstra as etapas realizadas pela classe “Populador”.
Figura 16: Sequencia de tarefas realizadas pela classe “Populador.class”
Busca no banco de dados por todos os tipos de entidades e associações entre tipos criadas na etapa
de modelagem.
É consultando na Freebase os IDs da entidades para cada tipo encontrado no
banco.
Em seguida para cada ID e a cada tipo associado a entidade, é consultado os valores das propriedades e inseridas na base de dados. No caso das propriedades
multivaloradas são criadas tabelas associativas e anotadas nas tabelas de
Página | 31
A Figura 17 mostra a tabela de dados correspondente aos exemplos anteriores sobre as ocorrências da entidade Zoológico que foram extraídas da Freebase.
Figura 17: Tabela de dados da base de conhecimento referente à entidade Zoológico.
4.2.2DBpedia
Conforme comentado anteriormente, a DBpedia, durante os últimos anos, vem extraindo dados da Wikipedia, catalogando-os e armazenando-os de forma estruturada em um banco de dados interno. Esta iniciativa permitiu a realização de consultas igualmente estruturadas, facilitando o trabalho de extração dos seus dados para a base de conhecimento proposta neste trabalho. Esse processo de extração enriqueceu ainda mais o conteúdo da base de dados proposta, diversificando mais ainda domínios e entidades, bem como completando-a com mais dados.
Para a extração de dados da DBpedia foi necessário conhecer os métodos de acesso disponíveis. Verificou-se que ela disponibilizava apenas consultas em HTTP usando uma linguagem de consulta denominada SPARQL. Mesmo não existindo nenhuma API em Java para o acesso a DBpedia, foi possível, através das requisições HTTP combinadas com SPARQL, manter a implementação da extração de dados na linguagem Java e utilizar métodos semelhantes aos já utilizados anteriormente para a extração de dados da Freebase. Métodos como os que
Página | 32
realizam consultas HTTP, métodos da classe ConnectorDB.java para executar alterações no banco de dados e até mesmo entidades mapeadas em JPA.
A DBpedia utiliza o padrão Linked Open Data¹ e, portanto, cabe detalhá-lo neste momento. Linked Open Data é um padrão de estrutura que interliga dados relacionados na Web, reduzindo barreiras com relação ao compartilhamento de conhecimento. Esta estrutura é mantida por um conjunto de datasets que interligam e compartilham suas informações através da linguagem RDF². Este padrão de ligação tem 4 princípios básicos:
1- Usar URIs como nomes para as coisas;
2- Usar HTTP URIs de modo que as pessoas possam olhar esses nomes;
3- Quando alguém procurar uma URI, fornecer informação útil em formato RDF; e 4- Incluir declarações RDF ligadas a outras URIs para que se possam descobrir relações.
SPARQL³ é a linguagem utilizada para realizar consultas a estas estruturas de dados. Esta linguagem é dividida em 3 partes: (i) o prefixo, onde são descritas as URLs que são utilizadas na consulta; (ii) a cláusula SELECT, que descreve quais parâmetros devem ser retornados; e (iii) a cláusula WHERE, onde são definidos os filtros que o retorno da consulta deve satisfazer. A Figura 18 mostra uma consulta SPARQL, utilizada durante a pesquisa para buscar objetos que satisfizessem a condição de ter o wikiPageID igual a “1278191”. Esta consulta foi executada no editor de consulta OpenLinkiSPARQL.
Página | 33
Uma vez descoberto o método de acesso à DBpedia, foi necessário solucionar a questão de como unir os dados trazidos dela com os já catalogados na base de conhecimento proposta. Após um período de pesquisa, descobriu-se que as entidades armazenadas no DBpedia possuíam um identificador referente à pagina da Wikipédia e que as entidades armazenadas na Freebase possuíam o mesmo identificador de página da Wikipédia. Tal constatação tornou possível a unificação dos dados das duas fontes. Um exemplo de tal fato é mostrado na Figura 19.
Figura 19: Screenshot de telas do Freebase e DBpedia indicando uma mesma entidade
Assim sendo, a extração de dados da DBpedia foi realizada de modo que, para cada entidade existente na base de conhecimento foi executada uma consulta primeiramente para a Freebase, pois era necessário obter o wikiPageID (identificador de pagina da Wikipedia). Tal identificador não havia sido extraído durante a etapa de extração da Freebase. Na Figura 20 é ilustrada a consulta realizada na Freebase para buscar este ID para a entidade
"/en/aaron_brooks", cujo resultado é o wikiPageID “1278191”.
Página | 34
Na sequência, buscou-se as entidades respectivas na base da DBpedia utilizando como parâmetro os wikiPageIDs recuperados. Para tanto, foram submetidas requisições HTTP com parâmetros “query” contendo consultas SPARQL que informavam o wikiPageID e retornavam a entidade completa.
Após tais consultas, foi executado um algoritmo que busca as propriedades já modeladas na base de conhecimento proposta. Parte do algoritmo é mostrada na Figura 21.
Figura 21: Parte do algoritmo utilizado para popular dados da DBpedia
Neste algoritmo, para cada propriedade, é verificada se ela já esta preenchida ou está sem valor (igual a null). Para o caso dela já estar preenchida, não é alterado nada na propriedade da entidade. Porém, se a propriedade estiver sem valor nenhum, então é feita uma busca no retorno da consulta realizada na DBpedia para encontrar este valor. Caso o valor esteja presente no retorno da consulta, então é executado um script em Java que altera a entidade encontrada na base de conhecimento, tornando-a, assim, mais completa.
________________________________________ ¹ http://linkeddata.org/
² http://en.wikipedia.org/wiki/SPARQL ³http://www.w3.org/RDF/
Página | 35
4.3 API da Base de Conhecimento
A API desenvolvida para a base de conhecimento tem como principal função prover acesso aos dados para os usuários através de métodos que executam consultas e retornam as informações desejadas.
Para o desenvolvimento da API, o foco do projeto foi em disponibilizar o maior número de consultas que tornassem possível extrair todos os dados de forma eficiente. Nesta primeira versão do projeto não foi desenvolvida a parte gráfica da API. Assim sendo, para acessar o conteúdo da API os usuários devem submeter consultas utilizando o protocolo HTTP e passando parâmetros em sua URL retornando os resultados em texto e tabelas. A escolha de se utilizar o protocolo HTTP foi devido a sua facilidade de uso, por ser um protocolo de uso comum e bem conhecido. Podendo assim organizar métodos de acessos que considerassem a forma hierárquica natural das informações de domínios.
A API foi desenvolvida em Java com o auxilio de outras linguagens como SQL, XML e JSON. Utilizou-se a IDE Eclipse para o desenvolvimento combinada com ferramentas como Maven, CDI, JAX-RS e JBoss. A seguir é detalhado como cada uma dessas ferramentas e linguagens foi utilizada para construir a API.
JAX-RS é a biblioteca responsável por fornecer auxilio na criação de Web Servers. Com ela pode-se utilizar notações como “@Path e @Get” para configurar quais métodos a API vai fornecer, qual será o retorno da consulta e em qual caminho será concedido o acesso. A Figura 22 mostra um exemplo de uma notação utilizada nesta pesquisa para a criação da API. Nesta figura, o Web Server está configurado para atender requisições contendo, no final da URL, a string “/Domain” seguido do ID do domínio, seguido do caractere “/” e, por fim, a propriedade a ser buscada.
Maven foi desenvolvido pela empresa Apache e é um software de gerenciamento de projetos. Sua principal funcionalidade é o gerenciamento de bibliotecas Java. O software serve também para outras funcionalidades, como a criação de archetypes, muito utilizados em empresas de software. Para este trabalho utilizaram-se apenas as funções de gerenciamento das bibliotecas, como jax-rs, google-apis, freebase, cdi etc.
Página | 36
Figura 22: Exemplo de Web Server usando notações JAX-RS
O CDI (Contexts and Dependency Injection) foi necessário por se utilizar Web Servers nesta API. Ela funciona gerenciando EJBs para cada requisição enviada ao servidor. Já o Jboss é o servidor de aplicação responsável por unir todas as ferramentas utilizadas para a criação desta API e disponibilizá-la na rede. Nele foi colocada a nossa aplicação com todas suas dependências gerenciadas pelo Maven, notações JAX-RS e classes Java.
4.3.1 Estrutura de Classes da API
Esta seção detalha as classes desenvolvidas no contexto da API. Elas são apresentadas na Figura 23.
As classes responsáveis pelas requisições HTTP são: EntityWS, PropertyWS e ServiceWS. Elas são responsáveis por dar acesso a API utilizando URLs iniciadas com /Entity, /Property e
/Domain respectivamente. Cada uma dessas classes contém notações JAX-RS que recebem as
requisições e repassam as consultas a outras classes como a classe Buscador ou classes Helper do pacote Connector. O Buscador é uma classe auxiliar que divide as consultas de acordo com cada Helper responsável. No entanto, para algumas consultas não foi necessário utilizar o Buscador, pois era possível retornar o valor direto do Helper para o WebService.
Página | 37 Figura 23: Estrutura das classes Java para criação da API
A classe ConnectorDB, assim como no processo de extração de dados, é responsável por criar uma conexão com o banco de dados MySQL. Por fim, dois arquivos XML que compõem ainda a arquitetura da API são o persistence.xml e o pom.xml. O primeiro mantém as configurações de acesso ao banco de dado e o segundo é um arquivo de configuração para uso da ferramenta Maven. Neste segundo arquivo declaram-se quais pacotes Java são usados como biblioteca, para que o Maven possa buscá-los na Web e anexá-los ao projeto.
Página | 38
4.3.2 Métodos de Acesso para o Usuário
Um conjunto de métodos de acesso foi desenvolvido para permitir ao usuário a busca por conhecimento na base de dados proposta. Para um melhor entendimento da exemplificação dos métodos de acesso a seguir, é assumido que, para acessar a servidor responsável por manter a API, utiliza-se, no prefixo da URL, o texto “http://localhost:8080/API_TCC4/”. As partições seguintes da URL são denominações escolhidas para cada tipo de consulta. Estas denominações são conhecidas como o path do Web Server. Elas foram previamente anotadas em cada classe de Web Server. A passagem de parâmetro foi implementada através da URL, descrevendo os parâmetros desejados no endereço de acesso. Para parâmetros em que é necessário enviar o símbolo „/‟, foi escolhido usar, ao invés dele, o símbolo „!‟ para evitar problemas com o path e o parâmetro enviado ao Web Server.
Os métodos de acesso da API da base de conhecimento proposta foram projetados para ser eficientes, uma vez que a estrutura do banco de dados relacional foi igualmente projetada para evitar muitos acessos e processamentos custosos. Durante esta etapa do desenvolvimento da API foram criados também índices para as tabelas muito acessadas por consultas. Estas tabelas são as tabelas responsáveis por guardar as propriedades de cada domínio, as tabelas que guardavam informações de propriedades associativas “_all_combined_table” e as tabelas de inclusões de tipos “_included_types” responsáveis por armazenar informações sobre quais tipos de entidades incluem outros tipos.
Os métodos de acesso da API são os seguintes: a) .../ Domain
Consulta responsável por buscar os domínios existentes. A tabela AllTables em nossa base de conhecimento contém todas as tabelas e a quais domínios elas pertencem. Levando em conta essa estrutura para realizar esta consulta, busca-se apenas nesta tabela pelos domínios diferentes.
Exemplo
Consulta:\Domain Resultado:
Página | 39
b) .../ Domain/“id_do_dominio”
Parâmetros: id_do_dominio: ID do domino
Está consulta é responsável por trazer as propriedades de um determinado domínio. Esta consulta percorre todas as tabelas relacionadas ao domínio, extraindo informações de estrutura sobre as propriedades (colunas) presentes na própria tabela e as propriedades anotadas na tabela
all_combined_tables de cada domínio.
Exemplo
Consulta: /Domain/!astronomy/ Resultado:
Página | 40
c) .../ Domain/“id_do_dominio”/“busca_propriedade” Parâmetros: id _do_dominio: ID do domino
busca_propriedade: termo de busca para propriedades que contenham o este padrão de string.
Esta consulta busca por propriedades dentro do domínio que contenham nomes semelhantes ao enviado por parâmetro. Semelhante à consulta b, esta consulta busca todas as propriedades que contenham em seu nome o termo informado no parâmetro busca_propriedade. Exemplo
Consulta: /Domain/!automotive/model Resultado:
Página | 41
d) .../ Property/“id_do_dominio”/“id _da_propriedade” Parâmetros: id_do_dominio: ID do domino
id _da_propriedade: ID da propriedade
Esta consulta retorna os valores de uma propriedade Y de um domínio X. Ela encontra todas as tabelas de propriedades do domínio e verifica se há valores para aquela propriedade. Exemplo
Consulta: /Property/!astronomy/constellation Resultado:
e) .../ Entity/find/“ id_dominio”/“id_tabela”/“id_entidade” Parâmetros: id _do_dominio: ID do domino
id _tabela: ID da tabela onde se encontra a entidade id_entidade: ID da entidade buscada
Esta consulta retorna uma ocorrência dentro de uma tabela e domínio específicos dados como parâmetros, incluindo o ID da entidade buscada. Esta consulta não percorre várias tabelas, pois o ID da tabela deve ser enviado como parâmetro. Nesse caso, é necessário apenas encontrar os valores das propriedades da própria tabela e as propriedades anotadas na tabela
all_combined_tables do domínio.
Exemplo
Consulta: /Entity/find/!astronomy /!meteorite/!en!hoba_meteorite Resultado:
Página | 42
f) .../ Entity/“ id_dominio”/“id_propriedade”/“valor”
Parâmetros: id _do_dominio: ID do domino
id _da_propriedade: ID da propriedade
valor: valor a procurar dentro da propriedade Y no domínio X.
Esta consulta retorna, para um determinado domínio e propriedade, as entidades que tenham, na propriedade selecionada, valores que contenham a string enviada como parâmetro “valor”. Exemplo
Consulta: Entity/!astronomy/meteorite_composition/iron Resultado:
Página | 43
5 Trabalhos Relacionados
Dentro do tema de bases de conhecimento há uma grande variedade de trabalhos, no entanto a grande maioria desses trabalhos está relacionada a criações de bases de conhecimento limitadas a certos domínios. Estes trabalhos criam bases de conhecimento como repositório de informações sobre os assuntos de interesse de cada instituição, de forma que a instituição criadora da base de conhecimento possa armazenar informações como: manuais de utilizações, técnicas de funcionamento, histórico das empresas e dos funcionários entre outras informações de interesse próprio. Foram poucas as bases de conhecimento encontradas que tem interesse em obter dados de diversos domínios, dentre elas as bases já comentadas neste trabalho, que são a Freebase e a DBpedia.
A criação da Freebase é citada novamente nesta pesquisa agora como um trabalho relacionado por ter objetivos similares aos propostos nesta pesquisa. A Freebase se iniciou como um projeto da empresa AppliedMinds conhecido como meta web. Atualmente renomeada para Freebase ela já possui mais de 40 milhões de tópicos em diferentes domínios. No entanto, as consultas que podem ser realizadas na Freebase devem estar na linguagem MQL dificultando a utilização de sua API. Outro problema também relacionado às consultas é a não especialização delas quanto à realização de comparações entre entidades, que facilitaria e melhoraria sua eficiência em sistemas especialistas.
Também como um trabalho similar está o projeto de criação da DBpedia, que apesar de incluir a tarefa de mapeamento dos dados da Wikipédia, tem também como propósito a criação de uma base de conhecimento. As dificuldades relacionadas a esta base de conhecimento estão devido a forma de armazenamento, que segue o padrão LinkedOpen Data, e a dificuldade em mapear os relacionamentos extraídos da Wikipédia. Apesar de possibilitar uma grande quantidade de diferentes entidades, tem também uma dificuldade quanto à eficiência em consultas que visam comparações entre entidades.
Este trabalho teve como principal objetivo resolver as dificuldades relacionadas a utilização dessas bases de conhecimento universais, criando uma API simples com as principais consultas relacionadas à aquisição de conhecimento, ao mesmo tempo em que se definiu uma estrutura que facilitasse a inserção de novos dados e propriedades, e o acesso a eles.
Página | 44
6 Conclusão
A aquisição de conhecimento é um problema atual e relevante, e que até os dias de hoje ainda dificulta a construção de sistemas que necessitam de diversos tipos de informação, como sistemas especialistas e sistemas de integração de dados (Costa e Silva et. al., 2005). A construção da base de conhecimento proposta neste trabalho visa solucionar esta problemática, procurando disponibilizar de maneira facilitada o acesso ao conhecimento de domínios diferentes e fornecendo algumas associações existentes.
Vale ressaltar que uma recente publicação relacionada ao tema propõe um modelo baseado em 7 etapas para a construção de bases de conhecimento, sendo considerada a quinta etapa (Armazenar e Distribuir o Conhecimento) a mais importante delas (Douglas P.et. al., 2012). Dentro das normas desta quinta etapa, afirma-se que se deve disponibilizar o fácil acesso a todos que desejem obter conhecimento através de métodos simples e que a base de dados possa ser dinamicamente atualizada com novos conhecimentos também de forma simples. Tais normas foram aplicadas na modelagem da base proposta neste trabalho.
Especificamente, este trabalho propõe a modelagem, criação e a população de dados de diversos domínios a partir da extração dos mesmos de duas importantes fontes de dados: a Freebase e a DBpedia. A escolha por elas se deve ao fato de que ambas possuem seus dados disponíveis na web e estão armazenados de forma estruturada, facilitando a catalogação desses dados para a base de conhecimento proposta nesta pesquisa. Adicionalmente, foi criada uma API para prover acesso à base, desenvolvida na linguagem Java e utilizando ferramentas de programação atuais e disponíveis. A API disponibiliza Web Servers que recebem requisições com consultas à base de dados e facilitam a visualização dos dados.
A principal motivação desse trabalho foi prover uma base de conhecimento rica e confiável que pudesse disponibilizar, a sistemas que necessitam realizar inferências semânticas, dados relacionados e organizados em forma de conhecimento. Busca-se, assim, contribuir com a evolução desses sistemas, evitando que cada um deles tenha que criar a sua própria base de conhecimento. Um exemplo de sistema desse tipo é o DeepEC, que além de usar as propriedades de cada domínio, usa também seus valores para refinar ainda mais a catalogação dos dados obtidos da Deep Web.
Página | 45
Como trabalhos futuros, sugere-se extrações de dados de outras fontes de conhecimento disponíveis. Para casos em que a fonte não tenha uma referência direta para a base de dados já existente, como foi o caso da DBpedia em relação à Freebase que havia como referencia direta o “wikiPageId”, interligando os dados de ambas bases. Para casos como este poderiam ser desenvolvidos algoritmos que infiram associações entre os dados extraídos com os existentes na base de conhecimento.
Para contribuir com o crescente padrão de compartilhamento na web, o Open Linked Data é possível ainda de se pensar na criação de um servidor RDF da base desenvolvida nesse projeto para relacionar com dados de outras bases que seguem este mesmo padrão. Podendo até realizar testes comparativos entre as duas versões: relacional e triplas.
Página | 46
Referências Bibliográficas
DBpedia - Wikipedia, thefreeencyclopedia.
Disponível em: http://en.wikipedia.org/wiki/DBpedia. Acesso em: 15 maio 2013 DBpedia- wiki.dbpedia.org : Online Access.
Disponível em: http://wiki.dbpedia.org/OnlineAccess#h28-11. Acesso em: 21 outubro 2013
SPARQL - SPARQL Query Language for RDF.
Disponível em: http://www.w3.org/TR/rdf-sparql-query/. Acesso em: 22setembro 2013 SPARQL - Virtuoso SPARQL Query Editor.
Disponível em: http://dbpedia.org/sparql. Acesso em: 23setembro 2013 Linked Data - Linked Data - Connect Distributed Data acrossthe Web
Disponívelem: http://linkeddata.org/. Acesso em: 17 outubro 2013 API:Mainpage - MediaWiki.
Disponível em: http://www.mediawiki.org/wiki/API:Main_page#A_simple_example. Acesso em: 15 maio 2013
Wikipédia – Wikipédia, a enciclopédia livre.
Disponível em: http://pt.wikipedia.org/wiki/Wikip%C3%A9dia. Acesso em: 11 junho 2013
History of Wikipedia - Wikipedia, the free encyclopedia.
Disponível em: http://en.wikipedia.org/wiki/History_of_Wikipedia. Acesso em: 8 outubro 2013
Query – Freebase.
Disponível em: https://www.freebase.com/query. Acesso em: 20 abril 2013
Graph - Freebase
Disponível em: http://wiki.freebase.com/wiki/Graph. Acesso em: 5 maio 2013 Main Page – Freebase.
Disponível em: http://wiki.freebase.com/wiki/Main_Page. Acesso em: 20 abril 2013 MQL Manual/Metaweb Query LanguagePartEight - Freebase.
Disponível em:
http://wiki.freebase.com/wiki/MQL_Manual/Metaweb_Query_Language_Part_Eight. Acesso em: 27 abril 2013
Página | 47
AUGUSTO F. SOUZA. Extração e Catalogação de Informações sobre Bancos de Dados Escondidos na Web. 2013. Dissertação de Mestrado, PPGCC/UFSC.
Welbson Siqueira Costa e ShirllyChristiany Macedo Silva. Aquisição de conhecimento: O Grande Desafio na Concepção de sistemas especialistas. 2005. 10 pag. Curso de Mestrado em Sistemas e Computação da UFRN.
Douglas Paulesky Juliani, Jordan PauleskyJuliani , Janine da Silva Alves Bello, João Artur de Souza. Modelo para Construção de Base de Conhecimentos sobre Projetos Suportado por Ferramentas Colaborativas. 2012. 14 pag. Revista de Gestão e Projetos - GeP, São Paulo. Vagner Nogueira Silva. Modelagem de Base de Conhecimentos Baseada em Ontologia. 2010.
