de forma automática. O produtor de dados tem que carregar os arquivos em diferentes formatos como "recursos". No entanto, identificamos que o conceito de recursos dessas soluções diverge do que consideramos como distribuição, uma vez que por meio dos recursos é possível até mesmo que o produtor de dados disponibilize outros conjuntos de dados. Também identificamos que o Junar apresenta o conceito de recursos para um conjunto de dados, que neste caso podem ser gráficos ou visualizações de dados (data view), mas não apresentam o conceito de distribuições e não disponibiliza os dados em múltiplos formatos. As demais soluções possibilitam a criação de múltiplas distribuições para um mesmo conjunto de dados utilizando a negociação de conteúdo (content negotiation). Dentre elas, podemos destacar o Socrata por possibilitar a recuperação dos dados no maior número de formatos.
O CKAN e o DKAN permitem realizar o download dos dados em massa, mas não permitem acessar os dados por padrão por meio de uma API conforme descrito no R3. É necessário utilizar uma extensão para prover o acesso aos dados. Apesar do DKAN não permitir a criação de subconjuntos de forma automática, quando mais de um subconjunto é disponibilizado como recurso, o DKAN possibilita o pré-processamento dos dados no servidor gerando um único arquivo para download. As demais soluções permitem realizar o download dos dados e acessá- los por meio de uma API. É também pelo uso da API que elas permitem que os consumidores realizem filtros e acessem subconjuntos de dados. No entanto, apenas o Socrata e o Junar permite o download de subconjuntos de dados criados dinamicamente pelo consumidor. Portanto, o Socrata e o Junar se aproximam mais do que se espera de uma solução de compartilhamento de dados na Web quanto ao acesso aos dados.
De modo geral, as soluções adotam poucos mecanismos para comunicação entre os produtores e consumidores. O DKAN não apresenta mecanismos para comunicação. O CKAN e o ArcGIS Open Data permitem que os consumidores cadastrem comentários em cada conjunto de dados. O OpenDataSoft permite que seja cadastrado o reúso do conjunto de dados, seja uma aplicação ou os dados usados, permite que seja cadastrado um título, descrição, URL e uma imagem. O Junar permite que os consumidores criem visualizações dos dados, realizando filtros nos dados, e descrevendo o uso delas e é disponibilizado para os demais consumidores, após aprovação do produtor. Neste requisito, mais uma vez, podemos destacar o Socrata, pois além de permitir que comentários sejam cadastrados nos conjuntos de dados, permite que eles enviem mensagens para o produtor e também salvem as visualizações dos dados para disponibilizar para todos. Além disso, ele também permite que os consumidores efetuem o cadastro, o que possibilita cadastrar e gerenciar as aplicações desenvolvidas por ele.
Analisando as soluções à luz do R5, constatamos que o CKAN, o DKAN e o Junar não garantem acesso a dados atualizados de acordo com a fonte de origem. O ArcGIS Open Data garante o acesso quando o conjunto de dados publicado é oriundo de dados gerenciados pelo servidor ArcGIS. O OpenDataSoft fornece acesso a dados atualizados, dado uma frequência de atualização, desde que os conjuntos de dados sejam cadastrados a partir de dados na Web acessíveis por uma URI. A frequência de atualização deve ser informada quando uma tarefa
O CKAN e o DKAN também não atendem ao R6. No Junar, não é possível realizar a extração dos dados quando um dataset é cadastrado. No entanto, quando é criado uma visualização de dados, seus processos automáticos acessam a URI do conjunto de dados e realizam a extração e transformação dos dados de origem em dados na Web. O ArcGIS Open Data não oferece opção para extração. O Socrata possibilita a extração e transformação dos dados quando é cadastrada uma URI, tal como o OpenDataSoft. Somado a isso, durante o processo de extração e transformação, o OpenDataSoft também possibilita o enriquecimento dos dados. Nenhuma das soluções analisados atendem à necessidade de extrair os dados a partir de bancos de dados convencionais.
De modo geral, todas as soluções de catalogação analisados utilizam apenas um subcon- junto do DCAT para coletar informações (metadados) sobre os conjuntos de dados e distribuições. Verificamos que falta um maior suporte delas para coletar informações sobre qualidade e versio- namento, além de prover o processo de curadoria das demais informações como das aplicações e dos consumidores. Foi possível observar que apenas o ArcGIS Open Data, OpenDataSoft e o Socrata oferecem mecanismos que podem coletar metadados estruturais de forma automática. Apenas o Socrata fornece opção para metadados de qualidade e que o CKAN e o DCAN apesar não possibilitar o gerenciamento automático de versionamento, permite o cadastro do indica- tivo da versão. O Junar, Socrata e o OpenDataSoft gerenciam a frequência de atualização dos conjuntos de dados e apresentam essa informação nos metadados.
Além disso, as soluções analisadas garantem o uso de URIs para os conjuntos de dados e distribuições, atendendo ao requisito R10. No entanto, quanto ao requisito R9, nenhuma das soluções analisadas garante a preservação dos conjuntos de dados ao longo do tempo. Elas permitem a exclusão dos dados e não preservam o acesso. É necessário manter os identificadores ativos, para que os consumidores obtenham informações acerca do conjunto de dados, bem como sobre o seu arquivamento e como é possível recuperá-los novamente.
Portanto, conclui-se que as soluções atuais apresentam lacunas quanto aos requisitos necessários para uma solução de compartilhamento de dados na Web, como o gerenciamento de versões, curadoria de metadados, comunicação com os consumidores e produtores, e a
5http://www.pentaho.com/product/data-integration 6https://www.safe.com/solutions/for-applications/socrata/
4.4. ANÁLISE DAS SOLUÇÕES EXISTENTES DE ACORDO COM OS REQUISITOS 65
preservação dos conjuntos de dados. O conjunto desses requisitos norteiam os principais serviços propostos para um Sistema Gerenciador de Dados na Web (SGDW) e que são discutidos no próximo Capítulo.
SGDW
No Capítulo anterior foram discutidas as premissas e os requisitos para o compartilha- mento de dados na Web. Neste Capítulo, apresentamos o modelo de arquitetura proposto para um Sistema Gerenciador de Dados na Web. Dessa forma, na Seção 5.1 apresentamos a visão geral de um SGDW e os detalhes do modelo de arquitetura proposto. Na Seção 5.2 discorremos sobre os principais serviços necessários para um SGDW e, por fim, a Seção 5.3 apresenta uma conclusão deste Capítulo.
5.1
Visão geral de um SGDW
Considerando as premissas e requisitos discutidos no Capítulo anterior, temos que uma solução para compartilhamento de dados na Web deve ser capaz de realizar tarefas que vão muito além da catalogação de dados. Nesse contexto, neste trabalho propomos uma solução que procura preencher as lacunas de gerenciamento de dados deixadas pelas soluções para publicação de dados disponíveis atualmente. A fim de atender aos requisitos listados anteriormente, propomos o Sistema de Gerenciador de Dados na Web (SGDW), ou seja, uma solução capaz de realizar tanto as tarefas já desempenhadas pelos ambientes de catalogação de dados quanto às tarefas relacionadas ao gerenciamento dos dados propriamente ditos.
Um Sistema Gerenciador de Dados na Web (SGDW) é uma coleção de serviços que permite aos usuários compartilhar conjuntos de dados na Web. Um SGDW facilita a definição, criação, manutenção, manipulação e compartilhamento de conjuntos de dados na Web entre diversos usuários e aplicações.
A definição de um conjunto de dados envolve a especificação dos tipos de dados, bem como das demais informações descritivas do conjunto de dados, denominadas metadados. A criação de um conjunto de dados é o processo de criar as diferentes distribuições do conjunto. A manutenção de um conjunto de dados consiste na atualização dos conjuntos de dados a fim de refletir mudanças no mundo real. A manipulação de um conjunto de dados inclui funções como
5.1. VISÃO GERAL DE UM SGDW 67
o acesso aos conjuntos de dados. O compartilhamento de um conjunto de dados permite que diversos usuários e aplicações acessem o mesmo conjunto de dados simultaneamente.
O modelo de arquitetura proposto para o SGDW é apresentado na Figura 5.1 e descrito a seguir.
Figura 5.1: Modelo de Arquitetura para um SGDW. Fonte: o autor
5.1.1
Camada de Acesso
A Camada de Acesso provê uma Interface Web e uma Interface Remota (API). Esta camada se comunica com a Camada de Serviços para permitir o uso dos serviços disponíveis.
A Interface Web é composta por uma interface gráfica que promove a interação do usuário com o restante do sistema e deve prover módulos de acesso para os consumidores e para os produtores. Para os produtores, deve ser possível gerenciar os conjuntos de dados, possibilitando a criação, publicação e preservação de conjuntos de dados, bem como permitindo a realização de análises sobre o uso dos conjuntos de dados. Para os consumidores, deve ser possível realizar buscas facetadas e aplicar filtros nos metadados e dados, acessar os conjuntos de dados, envio de feedback, cadastro do uso e monitoramento dos conjuntos de dados de seu interesse.
5.1.2
Camada de Serviços
A Camada de Serviços é a responsável pelo gerenciamento dos conjuntos de dados e metadados. De modo geral, todos os requisitos listados no Capítulo anterior são mapeados como serviços nessa camada, os quais podem ser acessados a partir da Interface Web e da Interface Remota disponíveis na Camada de Acesso.
Resumidamente, temos o serviço de Extração e Transformação de Dados, que acessa as fontes de dados de origem para permitir a criação dos conjuntos de dados juntamente com suas respectivas distribuições. Uma vez criado o conjunto de dados, o serviço de Gerenciamento de Versões ficará responsável por garantir o registro do seu histórico de versionamento, bem como a correta identificação das diferentes versões. O serviço de Gerenciamento de Atualizações garante que o conjunto de dados estará sempre atualizado conforme as atualizações em sua fonte de dados de origem. O serviço de Gerenciamento de Acesso garante o acesso aos conjuntos de dados, levando em consideração as diferentes versões e distribuições. Dessa forma, os conjuntos de dados poderão ser reusados pelos consumidores e será possível, para os produtores, obter feedbacke realizar a análise do seu uso. O serviço de Preservação garante que todos os conjuntos de dados criados estarão acessíveis, possibilitando a recuperação dos dados ou informações de como é possível recuperá-los. Por fim, o serviço de Gerenciamento de Metadados é responsável por gerenciar todos os metadados relacionados aos conjuntos de dados, distribuições, aplicações, consumidores e produtores.
Na Seção 5.2, detalharemos cada um dos serviços que compõem a Camada de Serviços.
5.1.3
Camada de Dados e Metadados
A Camada de Dados e Metadados é composta pelas fontes de dados de origem e pelo armazenamento interno dos dados e metadados. As fontes de dados de origem são as fontes de dados a partir das quais é possível extrair dados para compartilhamento na Web. Dentre essas fontes, destacamos os bancos de dados que são acessíveis por um SGBD relacional ou NoSQL, fontes de dados acessíveis por meio de uma API e arquivos. A Camada de Serviços, por meio do serviço de Extração e Transformação de Dados, se comunica com essa camada para realizar a extração dos dados e transformá-los para publicação na Web.