Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br <www.cin.ufpe.br/~posgraduacao>
RECIFE 2017
Lairson Emanuel R. de Alencar Oliveira
UM MODELO DE ARQUITETURA PARA SISTEMAS
GERENCIADORES DE DADOS NA WEB
Trabalho apresentado ao Programa de Pós-graduação em Ciência da Computação do Centro de Informática da Univer-sidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre em Ciência da Computação.
Orientadora: Profa. Dra. Bernadette Farias Lóscio
RECIFE 2017
Catalogação na fonte
Bibliotecária Monick Raquel Silvestre da S. Portes, CRB4-1217
O48m Oliveira, Lairson Emanuel Rodrigues de Alencar
Um modelo de arquitetura para sistemas gerenciadores de dados na Web / Lairson Emanuel Rodrigues de Alencar Oliveira. – 2017.
113 f.: il., fig.
Orientadora: Bernadette Farias Lóscio.
Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn, Ciência da Computação, Recife, 2017.
Inclui referências.
1. Banco de dados. 2. Web semântica. I. Lóscio, Bernadette Farias (orientadora). II. Título.
025.74 CDD (23. ed.) UFPE- MEI 2017-100
Lairson Emanuel Rodrigues de Alencar Oliveira
UM MODELO DE ARQUITETURA PARA
SISTEMASGERENCIADORES DE DADOS NA WEB
Dissertação de Mestrado apresentada ao Programa de Pós-Graduação em Ciência da Computação da Universidade Federal de Pernambuco, como requisito parcial para a obtenção do título de Mestre em Ciência da Computação
Aprovado em: 03/03/2017.
BANCA EXAMINADORA
______________________________________________ Prof. Dr. Luciano de Andrade Barbosa
Centro de Informática / UFPE
__________________________________________ Prof. Dr. Ig Ibert Bittencourt Santana Pinto
Instituto de Computação/UFAL
__________________________________________ Profa. Dra. Bernadette Farias Lóscio
Centro de Informática / UFPE
Agradecimentos
Agradeço, primeiramente, ao meu bom Deus que me concedeu capacidade para chegar até aqui.
Durante o término de minha graduação em Bach. Sistemas de Informação na UFPE, não pensava em continuar estudando e fazer pós-graduações. Afinal, eu já estava há nove anos no ensino superior e antes de ingressar em SI, já tinha passado, ininterruptamente, por outras 2 graduações (que não concluí). De nove anos no ensino superior, os últimos oito eu já trabalhava e, dado a rotina de trabalho + estudo, eu acreditava que era o momento de ’descansar’ um pouco.
Porém, foi também durante o término de minha graduação, ao desenvolver o meu trabalho de graduação que minha antiga paixão reascendeu. Estava diante de uma profissional que, logo após, veio a se tornar minha referência na profissão, uma professora muito inteligente, que me direcionou, orientou com paciência e me ajudou a dar meus primeiros passos academicamente. Talvez no dia que ela cogitou a possibilidade de fazer o mestrado acadêmico, ainda não tinha "caído minha ficha". Mas, em oração a Deus, pude perceber que tudo que estava acontecendo não era fruto de um projeto meu (uma vez que eu não queria mais continuar estudando). Minha certeza veio em dezembro de 2014 com a aprovação na seleção do mestrado e em cada reunião, troca de email, whatsapp, ligação, conversas e confraternizações que tive com ela. Hoje, apesar de não abandonar o "professora"e "sra", agradeço imensamente a Berna, que além de minha orientadora e referência profissional, se tornou minha querida amiga.
Agradeço à minha infindável namorada e esposa, Wanessa Botelho. Foi durante todo nosso relacionamento que meus maiores sonhos até hoje se concretizaram. Nosso casamento foi realizado durante o mestrado e no meio de um turbilhão de coisas, sempre regamos nosso amor. Para ela, que com paciência, ternura e um coração imenso, me apoiou incondicionalmente, desde cada momento tenso do mestrado a momentos eufóricos de alegria, meu muito e muito obrigado! Hoje, ao término do mestrado e eminência de iniciar o doutorado, me conforta o coração saber da grande mulher que tenho ao meu lado para viver todos os momentos e desafios que virão. Obrigado por todo cuidado, carinho, cumplicidade e amor!
Agradeço à todos os meus amigos que me ajudaram nesta dissertação, desde aqueles que ajudaram com orações até aqueles que me ajudaram com orientações e duvidas. Em especial, agradeço a todos os meus amigos da Primeira Igreja Batista em Cidade Universitária (PIB-CDU) e dois amigos que me acompanharam desde o início do mestrado, a Jônatas (Jon!) e Marcelo (Grande Marcelo!). Jon me mostrou que mesmo diante a tantas atividades, não devemos nunca nos afastar de nosso Pai Celestial e se tornou um grande amigo. Marcelo, o Grande Marcelo, umas das pessoas mais inteligentes e esforçada que conheci, além de se tornar um grande amigo, também se tornou, junto a Berna, minha referência profissional. Também agradeço ao Wilker pela grande ajuda durante a realização deste trabalho.
Suba o primeiro degrau com fé. Você não tem que ver toda a escada. Você só precisa dar o primeiro passo. — MARTIN LUTHER KING JR
ao compartilhamento de dados na Web, como formatos de dados, acesso, identificadores e metadados. Ao longo dos anos, várias soluções foram desenvolvidas objetivando a publicação e o compartilhamento desses dados na Web. No entanto, as soluções de publicação de dados atuais, que são responsáveis por prover catálogos de dados e manter a interface de comunicação entre os produtores e consumidores, não implementam boa parte das orientações propostas pelo W3C como boas práticas. Dado que existe uma carência de soluções que possibilitem o gerenciamento adequado dos dados compartilhados na Web, esta dissertação tem como principal objetivo propor um modelo de arquitetura para um Sistema de Gerenciamento de Dados na Web (SGDW). Pretende-se identificar os principais requisitos que um sistema desse tipo deve atender para prover soluções para as limitações encontradas. Além disso, é proposta uma coleção de serviços que visam facilitar a definição, criação, manutenção, manipulação e compartilhamento dos conjuntos de dados na Web entre diversos usuários e aplicações.
Abstract
The large amount of data available on the Web along with the ease access and repre-sentation of these data create new challenges for those who wish to share data on the Web. In general, there is no prior knowledge between the interests of who share the data, called data producers, and the interests of who use, called data consumers. In this context, W3C proposed a recommendation, called Data on the Web Best Practices (DWBP), that aims a common un-derstanding between data producers and data consumers. The DWBP deals with several aspects related to sharing data on the Web, such as data format, data access, data identifiers and metadata. Besides, over the years, a broad of solutions have been developed for the purpose of publishing and sharing data on the Web. However, current data publishing solutions, which are responsible for providing data catalogs and maintaining the communication interface between data producers and data consumers, do not implement much of the guidelines proposed by the DWBP. Given the lack of solutions that allow the management of shared data on the Web, this work has as main objective to propose an architectural model for a Data on the Web Management System (DWMS). We also identify the main requirements that a DWMS must meet to overcome the limitations of existing solutions. In addition, we developed a proof of concept and we propose a collection of services that aim to facilitate the definition, creation, maintenance, manipulation and sharing of datasets on the Web among users and applications.
2016b) . . . 28 2.6 Ciclo de Vida dos Dados na Web proposto porLóscio, Oliveira e Bittencourt(2015).
Fonte: (LÓSCIO; OLIVEIRA; BITTENCOURT,2015) . . . 29 2.7 Ciclo de Vida dos Dados na Web proposto pelo autor. Fonte: o autor . . . 30
3.1 Arquitetura do CKAN. Fonte: <http://docs.ckan.org/en/latest/contributing/architecture. html> . . . 34 3.2 Visão geral do processo de Publicação no Junar. Fonte: <http://junar-cdn-brandings.
s3.amazonaws.com/ebook/Overview-Junar-Open-Data-Portal-for-IT-Professionals-N0511. pdf> . . . 35 3.3 Exemplo de publicação de dados no Junar. Fonte: <http://junar-cdn-brandings.s3.
amazonaws.com/ebook/Overview-Junar-Open-Data-Portal-for-IT-Professionals-N0511. pdf> . . . 36 3.4 Arquitetura do Socrata. Fonte: <http://open-source.socrata.com/architecture/>. . . 37 3.5 Arquitetura do OpenDataSoft. Fonte: <https://docs.opendatasoft.com/en/about.html>. 38 3.6 Arquitetura do ArcGis Open Data. Fonte: <https://blogs.esri.com/esri/arcgis/2015/
09/02/architecture-of-open-data/>. . . 39 3.7 Visão adaptada da arquitetura do DKAN. Fonte: <http://www.slideshare.net/DavidPortnoy/
ddod-the-lean-startup-approach-to-open-data> (adaptado pelo autor). . . 40
4.1 Fases de um Conjunto de Dados. Fonte: o autor . . . 53
5.1 Modelo de Arquitetura para um SGDW. Fonte: o autor . . . 67 5.2 Fluxo de Atividades para o Serviço de Extração e Transformação de Dados. Fonte:
o autor . . . 70 5.3 Fluxo de Atividades para o Serviço de Criação de Conjuntos de Dados. Fonte: o autor 71 5.4 Fluxo de Atividades para o Serviço de Gerenciamento de Metadados. Fonte: o autor 73 5.5 Fluxo de Atividades para o Serviço de Gerenciamento de Versões. Fonte: o autor . 75 5.6 Consumo das versões dos conjuntos de dados. Fonte: o autor . . . 76
5.7 Fluxo de Atividades para o Serviço de Gerenciamento de Atualizações. Fonte: o autor 77
5.8 Fluxo de Atividades para o Serviço de Gerenciamento de Acesso. Fonte: o autor . . 79
5.9 Fluxo de Atividades para o Serviço de Preservação de Conjuntos de Dados. Fonte: o autor . . . 80
5.10 Fluxo de Atividades para o Serviço Gerenciamento do Uso dos Dados. Fonte: o autor 81 6.1 Arquitetura da Prova de Conceito (SGDW-v01). Fonte: o autor . . . 86
6.2 Arquitetura do Angular (a) e Estrutura de pastas do projeto da Interface Web do produtor (b). Fonte: o autor . . . 89
6.3 Principais Casos de Uso da Solução. Fonte: o autor . . . 90
6.4 Tela de login do sistema do produtor. Fonte: o autor . . . 92
6.5 Tokensalvo na Session Storage (a) e Token gerado após simular uma requisição a API (b). Fonte: o autor . . . 93
6.6 Cadastro de fonte de dados. Fonte: o autor . . . 94
6.7 Tipos de SGBDs recebidos por meio da API. Fonte: o autor . . . 95
6.8 Processo de extração de dados implementado na Prova de Conceito. Fonte: o autor 95 6.9 Método que gerencia as conexões dinamicamente usando o Hibernate. Fonte: o autor 96 6.10 Método que recupera os dados a partir de uma conexão . . . 96
6.11 Método que converte os dados para JSON. Fonte: o autor . . . 97
6.12 Método que armazena o arquivo no servidor. Fonte: o autor . . . 97
6.13 Formulário de criação de conjunto de dados. Fonte: o autor . . . 98
6.14 Exemplo de criação de identificador automático. Fonte: o autor . . . 99
6.15 Distribuições disponíveis. Fonte: o autor . . . 100
6.16 Metadados exibidos por meio de uma consulta no MongoDB (a) e os metadados recuperados por meio da API pública do sistema (b). Fonte: o autor . . . 100
6.17 Histórico das versões geradas de um conjunto de dados. Fonte: o autor . . . 101
6.18 Acesso a uma versão específica de um conjunto de dados. Fonte: o autor . . . 101
6.19 Método que implementa o agendador de tarefas automático. Fonte: o autor . . . 102
6.20 Atualização manual (não programada) de um conjunto de dados. Fonte: o autor . . 102
6.21 Métodos de acesso aos conjuntos de dados . . . 103
6.22 Exemplo de método e rota da API. Fonte: o autor . . . 103
6.23 API AdminREST com os métodos, rotas e descrição, respectivamente. Fonte: o autor 104 6.24 API OpenREST com os métodos, rotas e descrição, respectivamente. Fonte: o autor 104 6.25 Testes da API a partir da documentação. Fonte: o autor . . . 105
Lista de Acrônimos
WWW World Wide Web . . . 16
SGDW Sistema Gerenciador de Dados na Web . . . 19
API Application Programming Interface. . . 22
SBD Sistemas de Bancos de Dados . . . 21
SQL Structured Query Language. . . 22
HTTP Hypertext Transfer Protocol. . . 22
ACID Atomicidade, Consistência, Isolamento e Durabilidade . . . 22
BASE Basically Available, Soft State, and Eventual Consistency. . . 22
SPARQL SPARQL Protocol and RDF Query Language. . . 22
RDF Resource Description Framework. . . 22
URI Universal Resource Identifier. . . 25
ADLM Abstract Data Lifecycle Model . . . 28
URL Uniform Resource Locator. . . 34
SaaS Software como Serviço . . . 35
SoQL SODA Query Language. . . 37
SGBD Sistema Gerenciador de Banco de Dados . . . 40
DWBP Data on the Web Best Practices. . . 17
REST Representational State Transfer (REST). . . 47
DUV Dataset Usage Vocabulary. . . 82
WAR Web application ARchive. . . 86
SPA Single Page Application. . . 88
JS JavaScript. . . 88
CSS Cascading Style Sheets . . . 88
IIS Internet Information Services. . . 91
2.1 Bancos de Dados Convencionais X Dados na Web . . . 21
2.2 Ecossistemas de dados na Web . . . 23
2.3 Dados na Web x Dados Abertos x Dados Conectados . . . 26
2.4 Ciclo de Vida dos Dados na Web . . . 28
3 Publicação de Dados na Web 33 3.1 Soluções para Catalogação de Dados . . . 33
3.1.1 CKAN . . . 34
3.1.2 Junar . . . 35
3.1.3 Socrata . . . 36
3.1.4 OpenDataSoft . . . 38
3.1.5 ArcGIS Open Data . . . 39
3.1.6 DKAN . . . 40
3.2 Boas Práticas para Dados na Web . . . 41
3.3 Soluções de Catalogação de dados X Boas Práticas . . . 48
4 Compartilhamento de Dados na Web 52 4.1 Conceitos básicos . . . 52
4.2 Premissas do compartilhamento de Dados na Web . . . 54
4.3 Requisitos para as soluções de compartilhamento de Dados na Web . . . 55
4.3.1 Requisitos da Premissa 1 . . . 56
4.3.2 Requisitos da Premissa 2 . . . 58
4.3.3 Requisitos da Premissa 3 . . . 59
4.3.4 Requisitos da Premissa 4 . . . 61
4.4 Análise das soluções existentes de acordo com os requisitos . . . 62
5 Sistemas Gerenciadores de Dados na Web - SGDW 66 5.1 Visão geral de um SGDW . . . 66
5.1.2 Camada de Serviços . . . 68
5.1.3 Camada de Dados e Metadados . . . 68
5.2 Detalhamento da Camada de Serviços . . . 69
5.2.1 Extração e Transformação dos Dados . . . 70
5.2.2 Criação de conjuntos de dados . . . 70
5.2.3 Gerenciamento de Metadados . . . 72
5.2.4 Gerenciamento de Versões . . . 74
5.2.5 Gerenciamento de Atualização . . . 77
5.2.6 Gerenciamento de Acesso . . . 78
5.2.7 Preservação dos Conjuntos de dados . . . 80
5.2.8 Gerenciamento do Uso dos Dados . . . 81
5.3 Conclusão . . . 83
6 Prova de conceito do Modelo de Arquitetura para um SGDW 85 6.1 Visão geral da implementação . . . 85
6.1.1 Arquitetura e tecnologias de implementação . . . 85
6.1.2 Funcionalidades . . . 90
6.1.3 Implantação . . . 91
6.2 Adequação da Implementação aos Requisitos . . . 92
6.2.1 Collector . . . 93
6.2.1.1 Cadastro de Fonte de Dados . . . 93
6.2.1.2 Extração e Transformação de Dados . . . 95
6.2.2 Criação de Conjuntos de Dados . . . 98
6.2.2.1 Gerenciamento de URIs . . . 99 6.2.2.2 Gerenciamento de Distribuições . . . 99 6.2.3 Gerenciamento de metadados . . . 100 6.2.4 Gerenciamento de Versões . . . 100 6.2.5 Gerenciamento de Atualizações . . . 101 6.2.6 Gerenciamento de Acesso . . . 103
6.2.7 Interface Web Consumidor . . . 105
6.3 Conclusão . . . 106
7 Conclusão 108 7.1 Considerações Finais . . . 108
7.2 Trabalhos Futuros . . . 109
Neste capítulo é apresentada uma introdução sobre os principais aspectos relacionados à publicação e ao consumo de dados na Web. De modo geral, existe uma tendência de publicação de dados na Web, somado a ferramentas que permitem essa publicação, contudo existem lacunas no gerenciamento adequado desses dados, considerando aspectos descritos na recomendação de Boas Práticas do W3C e problemas em aberto na literatura. Inicialmente, na Seção 1.1, abordaremos uma breve motivação para o desenvolvimento deste trabalho. A caracterização do problema é descrita na Seção 1.2 e os objetivos são apresentados na Seção 1.3. Por fim, a Seção 1.4 é apresenta a estrutura desta dissertação.
1.1
Motivação
Desde o seu surgimento, a World Wide Web (WWW), ou apenas Web, teve muito progresso e tem se destacado como o principal meio pelo qual usuários podem publicar, consumir e compartilhar dados. O potencial da Web como plataforma para troca e compartilhamento de dados vem se intensificando, tanto pelo crescimento da publicação online de dados abertos em todo o mundo, quanto pela crescente publicação de dados de pesquisas, pelo grande volume de dados que são gerados pelas redes sociais e pelo paradigma de Web das Coisas (do inglês, Web of Things) (LÓSCIO; BURLE; CALEGARI,2016a). Porém, devido a esse grande crescimento e à flexibilidade oferecida pela Web, novos desafios precisam ser enfrentados para garantir o seu sucesso como plataforma de compartilhamento de dados.
A origem da Web, considerada como Web 1.0, possibilitou a publicação, propagação e visibilidade dos conteúdos. Nela, poucos produtores criavam páginas interligadas e um grande número de clientes acessavam essas páginas através da Internet. Assim, os usuários só podiam ler as informações que eram publicadas pelos produtores (NATH; DHAR; BASISHTHA,2014). Porém, com o seu rápido crescimento, novos paradigmas para Web foram surgindo e permitindo uma participação efetiva dos usuários. Dessa forma, além de ler os conteúdos, também foi permitido aos usuários escrever, modificar e atualizar os conteúdos na Web, oferecendo suporte para colaboração. Além disso, com o avanço da tecnologia, os dados produzidos pela sociedade
1.1. MOTIVAÇÃO 17
e disponibilizados na Web vêm crescendo rapidamente e novos termos estão sendo fomentados, como a Web 3.0 e a Web 4.0 (NATH; ISWARY,2015).
O relatório da EMC em 2014 1, que fez uma medição dos dados criados, replicados e consumidos no respectivo ano, apontou que os dados estão dobrando de tamanho a cada 2 anos e estimou que até 2020 chegarão a 44 zettabytes. Contudo, grande parte desses dados não estão disponíveis ao público, ou não estão estruturados para facilitar a compreensão por aqueles que podem acessá-los e manipulá-los ou, ainda, não são facilmente descobertos (ISOTANI;
BITTENCOURT,2015). Dessa forma, não se alcança de forma ágil o valor que poderia ser
obtido a partir desses dados, ou seja, extraindo informações e conhecimentos úteis para sociedade, por exemplo. Assim, é importante a criação de ecossistemas de dados, que permitam a descoberta de dados de forma rápida, estimulando a interação entre todos os envolvidos, assim como a utilização dos dados para geração de valor (GAMA; LÓSCIO,2014).
Nesse cenário, com uma grande e crescente quantidade de dados disponíveis na Web, podemos considerar os Ecossistemas de Dados na Web como sendo o conjunto de agentes envolvidos na produção, distribuição e consumo dos dados por meio da Web (LÓSCIO; BURLE; CALEGARI,2016a). Assim, dentre os agentes temos os produtores e os consumidores de dados que interagem uns com os outros através dos conjuntos de dados.
No entanto, a heterogeneidade dos dados e a falta de padrões para descrição e acesso aos conjuntos de dados tornam o processo de publicação, compartilhamento e consumo de dados uma tarefa complexa(LÓSCIO; OLIVEIRA; BITTENCOURT,2015). Dessa forma, é necessário buscar alternativas que possibilitem um entendimento comum entre os atores e promovam uma maior confiança nos dados para que os esforços dos produtores não se tornem incompatíveis com os desejos dos consumidores de dados (LÓSCIO; BURLE; CALEGARI,2016b).
Na busca por esse entendimento comum, o W3C publicou recentemente um documento que estabelece boas práticas para a publicação e o consumo de dados na Web, sendo independente de domínio e de aplicação. Em outras palavras, ele é aplicável a todos os domínios, podendo ainda ser estendido ou complementado por outros documentos ou normas mais especializadas. O Data on the Web Best Practices (DWBP) discursa sobre diferentes aspectos relacionados a publicação e consumo de dados, como formatos de dados, acesso a dados, identificadores de dados e metadados, por meio das suas 35 boas práticas. Ao seguir as boas práticas, uma série de benefícios distintos poderão ser alcançados, tais como a compreensão, processabilidade, descoberta, reúso, acesso e interoperabilidade (LÓSCIO; BURLE; CALEGARI,2016a). Porém, ainda existem desafios a serem enfrentados, seja para avaliar se tais benefícios são alcançados, disponibilidade de ferramentas de publicação que implementem as orientações, bem como, quais os passos, do ponto de vista técnico, que devem ser seguidos e implementados até os dados serem publicados.
Contudo, ainda se constitui um grande desafio a publicação de dados na Web guiada por práticas que facilitem a compreensão, descoberta e uso dos dados. Dessa forma, neste trabalho
frameworkou metodologias padronizadas para o desenvolvimento desses softwares, não existe uma homogeneidade na publicação dos dados.
Além disso, apesar da ampla utilização, essas soluções não oferecem mecanismos para o gerenciamento adequado dos conjuntos de dados. Como limitações dessas soluções, podemos destacar a falta de mecanismos que possibilitem o gerenciamento de versões, atualização auto-mática dos conjuntos de dados com frequências de atualização pré-definidas, gerenciamento de feedbacke gerenciamento da proveniência dos conjuntos de dados.
Além dessas limitações,Oliveira et al.(2016) apontou, em um estudo realizado com os portais de dados abertos brasileiros, que na maioria dos conjuntos de dados avaliados não foram disponibilizados metadados adequados ou suficientes para a descrição dos conjuntos de dados. Os metadados são importantes uma vez que ajuda os consumidores a compreenderem o significado dos dados, sua estrutura e questões como termos de licença, qualidade dos dados, métodos de acesso e atualização dos conjuntos de dados(LÓSCIO; BURLE; CALEGARI,2016a).
Umbrich, Neumaier e Polleres(2015) complementa que a baixa qualidade dos (meta)dados
afeta a descoberta e o consumo do conjunto de dados, ou seja, afeta diretamente os serviços de pesquisa e descoberta para que os consumidores localizem os conjuntos de dados relevantes e relacionados para suas necessidades.
Somado a isso, também foi constatado que uma grande parcela dos dados foi publicada em formatos de dados proprietários ou não estruturados (OLIVEIRA et al.,2016), não abordando adequadamente os princípios de publicação dos dados na Web (LÓSCIO; BURLE; CALEGARI, 2016a). Um outro ponto observado, foi a ausência de controle de versão formal nos conjuntos de dados. Embora os conjuntos de dados apresentassem informação sobre a última atualização, torna-se difícil determinar a frequência de atualização e a próxima vez que os dados seriam atualizados, uma vez que não existiam políticas de atualização padrão.
Apesar da importância reconhecida do feedback e sistemas de colaboração que surgiram a partir da Web 2.0, nenhum dos portais analisados forneceram mecanismos para coletar feedback
2http://ckan.org/ 3https://socrata.com/ 4http://junar.com/
5https://www.opendatasoft.com/ 6http://opendata.arcgis.com/
1.3. OBJETIVOS E CONTRIBUIÇÕES 19
dos consumidores de dados. SegundoLóscio, Burle e Calegari(2016a), o feedback tem benefícios tanto para os produtores quanto para os consumidores de dados, contribuindo para melhorar a integridade dos dados publicados, bem como para incentivar a publicação de novos dados. Por fim, também foi constatado que mesmo dentro de um determinado portal, não há padronização na publicação dos conjuntos de dados. Dessa forma, a falta de padronização e ausência de metadados, dificultam o consumo dos dados.
Em um outro estudo realizado porUmbrich, Neumaier e Polleres (2015), ao analisar 82 portais de dados abertos, constataram que até mesmo para um mesmo formato de dados não é seguido um padrão na publicação. Ou seja, devido a falta de padrões para descrever os formatos de dados, um arquivo CSV pode ser publicado com os valores separados por vírgulas por uns e separados com caracteres por outros, por exemplo. De acordo comBrito et al.(2015), a centralização de dados e a padronização dos dados publicados é necessário para permitir que os dados sejam usados e os desenvolvedores criem aplicativos com menos esforço.
Nesse contexto, constatamos que existem diversas limitações e lacunas com o comparti-lhamento de dados na Web. Além disso, existe uma carência de ferramentas que possibilitem o gerenciamento adequado desses dados, oferecendo soluções para o gerenciamento de versões e a preservação dos conjuntos de dados, por exemplo.
Assim, surge a necessidade de uma solução que supra necessidades de produtores e consumidores de dados, padronizando serviços e provendo soluções para as limitações mencio-nadas anteriormente. De maneira geral, torna-se necessário o desenvolvimento de soluções que preencham as lacunas de gerenciamento de dados na Web das soluções atualmente disponíveis.
1.3
Objetivos e Contribuições
O principal objetivo desta dissertação é propor e especificar um modelo de arquitetura para um Sistema Gerenciador de Dados na Web (SGDW). O modelo proposto leva em conside-ração os principais requisitos e funcionalidades que um sistema deste tipo deve atender a fim de prover um gerenciamento adequado dos conjuntos de dados publicados na Web.
Para alcançar o objetivo geral acima, foram definidos os seguintes objetivos específicos:
Levantar os desafios e problemas na publicação de dados na Web, considerando as ferramentas utilizadas para publicação de dados;
Identificar os requisitos e funcionalidades que possibilitem o gerenciamento adequado dos conjuntos de dados compartilhados na Web;
Especificar um modelo de arquitetura para o SGDW para que atenda o adequado gerenciamento dos conjuntos de dados na Web;
21 21 21
2
Fundamentação Teórica
Neste capítulo serão abordados conceitos essenciais para o entendimento desta disserta-ção. Na Seção 2.1, apresentamos uma comparação entre banco de dados convencionais e dados na Web. Na Seção 2.2, apresentamos os conceitos acerca dos ecossistemas de dados na Web. Na Seção 2.3 discutimos os conceitos de dados na Web, dados abertos e dados conectados. Por fim, na Seção 2.4 discorremos sobre o ciclo de vida de dados na Web, descrevendo suas etapas e relacionamentos.
2.1
Bancos de Dados Convencionais X Dados na Web
Lóscio, Oliveira e Bittencourt (2015) apontam que, assim como a Web, os Sistemas
de Bancos de Dados (SBD) também são caracterizados como plataformas para publicação e consumo de dados, permitindo o compartilhamento de dados por meio de funcionalidades como recuperação de dados, suporte a acesso concorrente e simultâneo. Já a publicação de dados na Web, dado a sua flexibilidade, possibilita a publicação e o consumo de maneira bastante simples, sem a necessidade de sistemas para controlar o acesso concorrente aos dados, por exemplo. Dessa forma, apesar de ambas soluções apresentarem funcionalidades similares quanto a mecanismos de armazenamento e compartilhamento, existem diferenças significativas quanto a facilidade de publicação e consumo de dados, como as que são apresentadas na Figura 2.1.
de dados convencionais. Fonte: (LÓSCIO; OLIVEIRA; BITTENCOURT,2015)
Podemos destacar a descrição e utilização de esquemas, mecanismos de acessos e controle de concorrência como as principais diferenças entre as soluções. Se de um lado os SBDs geralmente registram seus dados de forma estruturada, suportando ou não a padronização de um único esquema para toda uma coleção de dados, os dados publicados na Web, por sua vez, têm como característica a ausência completa ou parcial de um esquema que defina a estrutura dos dados a serem armazenados (LÓSCIO; OLIVEIRA; BITTENCOURT,2015). Assim, facilitando o processo de publicação de dados e tornando o processo de consumo mais complexo. Dessa forma, torna-se necessário deixar a semântica dos dados explícita, uma vez que não é possível prever todos os usuários ou aplicações que farão uso dos dados, diferentemente de quando um banco de dados é projetado (LÓSCIO; OLIVEIRA; BITTENCOURT,2015).
Além disso, os SBDs oferecem mecanismos de acesso aos dados por meio de Application Programming Interface (API) ou drivers, como o JDBC ou ODBC, que permitem o uso de linguagens declarativas como Structured Query Language (SQL) (ELMASRI; NAVATHE,2010). Já os dados na Web são acessados através do protocolo Hypertext Transfer Protocol (HTTP), fornecendo acesso no formato de serviços usando padrões Web Services ou Rest Services (LÓSCIO; OLIVEIRA; BITTENCOURT, 2015). Somado a isso, nos SBDs diversos tipos de consultas podem ser realizadas, como consultas por junção, agregação, faixa de valores e múltiplos atributos, enquanto que na Web geralmente é realizada consulta por palavras-chave. Contudo, a depender do modelo de dados adotado, consultas mais ricas podem ser realizadas, como em bases de dados Resource Description Framework (RDF) que utiliza a linguagem SPARQL Protocol and RDF Query Language(SPARQL), podendo realizar junções e consultas por múltiplos atributos (LÓSCIO; OLIVEIRA; BITTENCOURT,2015).
Também existem diferenças relacionadas à execução das transações. Os SBDs são baseados nos princípios ACID, Atomicidade, Consistência, Isolamento e Durabilidade (ACID), enquanto na Web destaca-se o BASE, Basically Available, Soft State, and Eventual Consistency (BASE). Resumidamente, as propriedades ACID visam garantir a confiabilidade das transações, ou seja, garantir que as transações sejam atômicas, mantendo a integridade dos dados, não sendo interferida por nenhuma outra transação concorrente e que os dados serão persistidos no
2.2. ECOSSISTEMAS DE DADOS NA WEB 23
banco (ELMASRI; NAVATHE,2010). Já as propriedades BASE, caracterizam-se por prover um modelo de consistência mais fraco, no qual o sistema permanece disponível, mesmo que parcialmente ocorram falhas (PRITCHETT,2008). Somado a isso, enquanto que em SBDs a escalabilidade é uma tarefa não trivial, dado a técnicas de controle de concorrências e uso modelos de consistência mais rigorosos, o ambiente da Web permite alcançar escalabilidade de forma mais fácil (LÓSCIO; OLIVEIRA; BITTENCOURT,2015).
Existem, portanto, diferenças significativas entre a publicação de dados na Web e a abordagem de bancos de dados convencionais. A Web, de forma geral, oferece funcionalidades eficientes e menos complexas para a publicação de dados (LÓSCIO; OLIVEIRA;
BITTEN-COURT, 2015). Todavia, os dados na Web apresentam características peculiares que é de
suma importância a análise mais detalhada para entendimento deste trabalho. Dessa forma, nas próximas seções, serão abordados aspectos inerentes aos dados na Web.
2.2
Ecossistemas de dados na Web
Desde seu surgimento, a Web vem evoluindo para atender a novas demandas e passa por transformações frequentes, como o suporte a novas formas de serviços e comércio (NATH;
DHAR; BASISHTHA,2014). Em sua origem, a Web possibilitou a publicação, propagação
e visibilidade de conteúdos como sites corporativos e institucionais. Ficou conhecida como Web 1.0 e seu acesso se dava de modo unidirecional, ou seja, uma pequena quantidade de produtores criavam páginas e um grande número de clientes acessam essas páginas através da Internet (NATH; ISWARY,2015). Nath, Dhar e Basishtha(2014) acrescenta que como a Web 1.0 permitia somente leitura, ela ignorou o conceito que quanto maior o número de pessoas usando um serviço em rede, então o serviço se torna mais útil para cada um usando essa rede.
Assim, com o seu rápido crescimento, a Web possibilitou novos meios para uma parti-cipação efetiva dos usuários. Com a Web 2.0, o usuário passou a não apenas ler os conteúdos, mas também escrever, modificar e atualizar os conteúdos na Internet, oferecendo suporte para colaboração (HIREMATH; KENCHAKKANAVAR,2016). Com o avanço da tecnologia, os dados produzidos pela sociedade e disponibilizados na Web continuam crescendo rapidamente e novos termos estão sendo fomentados, como a Web 3.0 e a Web 4.0 (NATH; ISWARY,2015). Se-gundoRudman e Bruwer(2016), a Web 3.0 já está em andamento e implica em uma experiência integrada, em que a máquina será capaz de compreender e catalogar dados de maneira semelhante aos seres humanos. Em outras palavras, a Web 3.0 também é conhecida como Web Semântica, em que a informação tem um significado bem definido e permite que computadores e humanos trabalhem em cooperação (GALIB et al.,2015). A Web 4.0, será uma Web inteligente e dinâmica, que suportará as interações dos indivíduos, utilizando os dados disponíveis, instantâneos ou históricos, para propor ou suportar a tomada de decisão (NATH; ISWARY,2015).
Dessa forma, a Web vem passando por transformações ao longo dos anos, tanto acom-panhada pelo avanço da tecnologia, quanto por novas demandas, e conta com uma grande e
Figura 2.2: Evolução da Web 1.0 para Web 3.0. Fonte: (DWIVEDI et al.,2011)
Portanto, entendemos por Ecossistema de Dados na Web o conjunto de agentes en-volvidos na produção, distribuição e consumo de dados por meio da Web (LÓSCIO; BURLE; CALEGARI,2016a). Em outros palavras, esse conjunto é formado por uma coleção de conjuntos de dados, por atores que interagem entre si por meio do fornecimento e do uso desses conjuntos de dados e pelo conjunto de ferramentas necessárias para garantir o bom funcionamento do ecossistema. Assim, os agentes podem ser tanto usuários, quanto sistemas ou dispositivos, po-dendo atuar como produtor e consumidor de conjuntos de dados. O produtor objetiva a produção e o compartilhamento de dados de algum tipo e com condições específicas. Por sua vez, os consumidores (que também podem ser eles mesmos provedores) consomem esses dados sob con-dições específicas ao longo de um intervalo de tempo (LÓSCIO; OLIVEIRA; BITTENCOURT, 2015). Ambos os atores interagem uns com os outros através dos datasets que são definidos por
Maali, Erickson e Archer(2014) como “um conjunto de dados, publicado ou curado por um
único agente, e disponível para acesso ou download em um ou mais formatos”. Já os dados são definidos porElmasri e Navathe(2010) como "fatos conhecidos que podem ser registrados e possuem significado implícito".
Nesse contexto, podemos identificar atividades voltadas aos produtores e aos consumi-dores de dados. Do lado dos produtores, podemos citar atividades relacionadas à publicação, como a definição de licenças, escolha dos formatos e plataformas para distribuição, somado ao conjunto obrigatório de metadados. Para os consumidores, podemos identificar pessoas interessadas no consumo direto dos dados, bem como outras que têm interesse em transformar os dados, agregando algum valor, para a geração de informações úteis e relevantes, assim como
2.2. ECOSSISTEMAS DE DADOS NA WEB 25
para a geração de novos dados (LÓSCIO; BURLE; CALEGARI,2016a).
Devido à flexibilidade da Web, os dados podem ser publicados e consumidos de maneira simples, sem a exigência de sistemas para controlar o acesso concorrente aos dados, transações ou manutenção de integridade dos dados. Em contraste a tal facilidade, porém, se faz necessário desenvolver soluções que possibilitem o consumo de dados por grupos de usuários previamente desconhecidos e com diferentes requisitos (LÓSCIO; OLIVEIRA; BITTENCOURT,2015). A Figura 2.3 ilustra o contexto de publicação dos dados na Web.
Figura 2.3: Contexto de Publicação dos Dados na Web. Fonte: (LÓSCIO; BURLE;
CALEGARI,2016a)
SegundoLóscio, Burle e Calegari(2016a), os dados devem ser publicados em diferentes distribuições, que são a forma física específica de um conjunto de dados. Tais distribuições, facilitam o compartilhamento de dados em grande escala, permitindo o uso por vários grupos de consumidores de dados e contribui com atividades de pré-processamento dos dados, como a desnecessidade de conversão de dados. Dado que os consumidores e produtores podem ser desconhecidos entre si, é necessário fornecer informações sobre os conjuntos de dados e distri-buições que podem contribuir para a confiabilidade e reutilização dos dados, ou seja, fornecer metadados sejam eles descritivos, de acesso, qualidade, proveniência, licença e informações de uso (LÓSCIO; BURLE; CALEGARI,2016a).
Além disso, por meio da Figura 2.3 percebemos que também é importante seguir os princípios da arquitetura Web e usar vocabulários e padrões de dados. Segundo oLóscio, Burle e Calegari(2016a), por exemplo, é importante que um recurso, que pode ser um conjunto de dados inteiro ou um item específico de um determinado conjunto de dados, seja publicado com uma Universal Resource Identifier(URI) estável, para que possam referenciados e fazer links, através de URIs, entre dois ou mais recursos. Somado a isso, para promover a interoperabilidade entre conjuntos de dados, é importante adotar os vocabulários e padrões de dados, como o DCAT1que foi projetado para facilitar a interoperabilidade entre catálogos de dados na Web.
creditar a sua autoria e compartilhar pela mesma licença.Isotani e Bittencourt(2015) acrescenta que dados abertos de alta qualidade são publicados e distribuídos na Internet, compartilhados em formato aberto para que possam ser lidos por qualquer pessoa e por máquinas, permitindo o cruzamento com outros dados de diferentes fontes, para serem livremente reutilizados pela sociedade. Assim, um dado é considerado aberto quando apresenta as seguintes características (DIETRICH et al.,2009):
Disponibilidade e Acesso: os dados devem estar disponíveis como um todo e de forma conveniente e modificável.
Reúso e Redistribuição: os dados devem ser fornecidos sob termos que permita a reutilização e a redistribuição, assim como, a combinação com outros.
Participação Universal: todos podem usar, reusar e redistribuir sem restrições de áreas de atuação, pessoas ou grupos.
Geralmente são disponibilizados em formatos como JSON, XML, CSV e RDF, que são considerados os principais formatos. O RDF, particularmente, é recomendado pela facilidade de combinar dados neste formato com múltiplas fontes de dados, interligando-se a outras iniciativas de dados na Web. Além disso, os dados abertos podem ser classificados de acordo com a escala, baseada em estrelas, apresentada na Figura 2.4 (BERNERS-LEE,2006).
Figura 2.4: Esquema de 5 estrelas para os Dados Abertos. Fonte: http://5stardata.info/en/
2.3. DADOS NA WEB X DADOS ABERTOS X DADOS CONECTADOS 27
Segundo essa classificação, um dado publicado na Web em qualquer formato (imagem, tabela ou documento) e associado a uma licença que permita o seu uso e reuso sem restrições é avaliado como sendo 1 Estrela. Quando é disponibilizado como dados estruturados, por exemplo, excel ao invés de uma imagem escaneada, é avaliado como sendo 2 estrelas. Usando formatos não proprietários, como o CSV ao invés de Excel, é avaliado como 3 estrelas. A medida em que os dados recebem uma identificação única (URI) e são conectados com outros dados, eles são avaliados como 4 estrelas e, por fim, se estiver conectado com dados já disponíveis na Web, fornecendo um contexto, ele recebe a avaliação de 5 estrelas (BERNERS-LEE,2006).
Uma parte dos dados disponíveis na Web segue os princípios de linked data (dados conectados), ou seja, seguem o conjunto de princípios para publicar e conectar conjuntos de dados estruturados na Web, sendo classificados como linked data (BERNERS-LEE, 2006). Além disso, quando os conjuntos de dados são publicados na Web seguindo os princípios de dados abertos e os princípios de linked data, eles são classificados como linked open data (BERNERS-LEE,2006). Os Princípios de Linked Data são resumidos em quatro princípios básicos (BERNERS-LEE,2006):
1. Usar URIs como nome para recursos;
2. Usar URIs HTTP para que as pessoas possam encontrar esses nomes;
3. Quando uma URI for acessada, garantir que informações úteis possam ser obtidas por meio dessa URI, as quais devem estar representadas no formato RDF;
4. Incluir links para outras URIs de forma que outros recursos possam ser descobertos.
Assim, para publicar dados como linked data é necessário fazer uso de URIs para identificar, não apenas documentos Web e conteúdos digitais, mas também objetos do mundo real e conceitos abstratos. Além disso, disponibilizar URIs HTTP para permitir a obtenção de informações e a recuperação de uma representação de um recurso, como documentos RDF e XML. Além disso, é defendido o uso de RDF como modelo para a publicação de dados estruturados na Web, para descrever significado sobre recursos e tornar possível a implementação de aplicações genéricas capazes de operar sobre o espaço de dados global. Por fim, usar links RDF para conectar não apenas os documentos da Web, mas qualquer tipo de recurso, permitindo que itens relacionados sejam descobertos (LÓSCIO; OLIVEIRA; BITTENCOURT,2015).
Portanto, nesse contexto, de acordo comLóscio, Burle e Calegari(2016b), dados na Web é o termo mais geral que pode ser usado para denotar os dados publicados de acordo com a arquitetura Web e podem ser representados conforme a Figura 2.5. Por fim,Lóscio, Burle e Calegari(2016b) acrescenta que é importante notar que nem todos os dados disponíveis na Web são compartilhados abertamente. Em outras palavras, os produtores determinam a política sobre a qual os dados devem ser compartilhados, levando em conta aspectos quanto a segurança e privacidade dos indivíduos.
Figura 2.5: Dados na Web x Open Data x Linked Data. Fonte: (LÓSCIO; BURLE; CALEGARI,2016b)
2.4
Ciclo de Vida dos Dados na Web
O ambiente da Web, como é de sua característica intrínseca, apresenta uma estrutura heterogênea em relação à publicação e compartilhamento dos dados (ISOTANI; BITTENCOURT, 2015). Lóscio, Oliveira e Bittencourt (2015) aponta que existem várias fases no processo de publicação e consumo de dados na Web que vão desde a seleção e publicação dos dados até o uso e feedback sobre os dados utilizados, acrescentando que o conjunto dessas fases é chamado de ciclo de vida dos dados na Web.
Os dados estão sendo criados, publicados, exportados, importados, usados, transformados e reutilizados, por diferentes partes e para diferente fins. Dessa forma, a compreensão do ciclo de vida ajuda a entender melhor a natureza dos dados e a manter um consenso entre as fases envolvidas. Além disso, auxilia na comparação das funcionalidades de diferentes plataformas, na comunicação entre os atores envolvidos, através de uma terminologia comum, e a relacionar os atores entre si (MöLLER, 2013). A partir de uma coleção de modelos de ciclo de vida para domínios centrados em dados, tais como bibliotecas digitais, multimídia, e-learning e desenvolvimento de ontologias,Möller(2013) propôs o Abstract Data Lifecycle Model (ADLM). O ADLM é um modelo genérico para representação de ciclo de vida para dados e metadados, estabelecendo um conjunto comum de fases, características e papéis. Por ser um modelo genérico, ele pode ser usado para construção de novos modelos de ciclo de vida centrados em dados.
Com o propósito de criar um ciclo de vida para dados na Web, Lóscio, Oliveira e Bittencourt(2015) instanciou o modelo genérico ADLM e propôs o ciclo que é representado na Figura 2.6. Através do ADLM, podemos observar que um ciclo de vida para domínios centrados em dados deve ser composto pelas fases de desenvolvimento de ontologia, planejamento, criação, arquivamento, refinamento, publicação, acesso, uso externo, feedback e término. No entanto, Lóscio, Oliveira e Bittencourt(2015) observa que o contexto de Dados na Web não contempla todas as fases definidas no modelo ADLM. Assim, as fases de desenvolvimento de ontologia,
2.4. CICLO DE VIDA DOS DADOS NA WEB 29
arquivamento e término não fazem parte do ciclo de vida proposto. Os autores afirmam que a criação de ontologias é uma atividade independente e por isso não foi incluída, assim como, o arquivamento e término não foram consideradas porque acredita-se que, uma vez que o dado foi publicado na Web, ele sempre estará disponível.
Figura 2.6: Ciclo de Vida dos Dados na Web proposto porLóscio, Oliveira e Bittencourt
(2015). Fonte: (LÓSCIO; OLIVEIRA; BITTENCOURT,2015)
Contudo,Lóscio, Burle e Calegari(2016a) reconhece que não é realista assumir que todos os dados na Web estarão disponíveis em um futuro indefinido. Uma vez que é provável que os produtores podem necessitar ou desejar remover os dados, seja para mover eles para fora do escopo publicado ou até mesmo arquivando os dados. Nesse sentido, faz-se necessário acrescentar a fase de término ao modelo proposto porLóscio, Oliveira e Bittencourt(2015), que considera apenas as fases planejamento, criação, publicação, acesso, consumo, feedback e refinamento. A fase de término é descrita porMöller(2013) como o momento em que os dados são removidos do sistema e também é apresentada no modelo deCatteau, Vidal e Broisin(2006), em que afirma que a etapa de término representa a retirada dos dados. Essa fase também é equivalente a fase de arquivamento apresentada no ciclo de vida descrito emIsotani e Bittencourt (2015). No entanto, a fase de término em nosso ciclo de vida dos dados na Web, deve ser entendida como a fase em que os dados são arquivados, mas o acesso a suas informações e a URI são preservadas. Assim, a Figura 2.7 apresenta o ciclo definido a partir das fases descritas porLóscio, Oliveira e Bittencourt(2015) somado a fase de término proposta neste trabalho.
Figura 2.7: Ciclo de Vida dos Dados na Web proposto pelo autor. Fonte: o autor
A Figura 2.7 apresenta as fases do ciclo de vida dos dados na Web, por meio dela podemos visualizar todas as fases desde o planejamento até o término. A seguir todas as fases são descritas brevemente.
Planejamento: É a primeira fase do ciclo de vida e precede o ciclo de vida ativo dos dados (MöLLER,2013). Esta fase se estende desde o momento em que surge a intenção de publicar os dados até a seleção dos dados que serão publicados (LÓSCIO;
OLIVEIRA; BITTENCOURT,2015). Por não existirem regras que determinem
a prioridade dos dados a serem publicados,Lóscio, Oliveira e Bittencourt(2015) aponta que é importante levar em consideração o potencial de utilização dos dados e, sempre que possível, fazer uma consulta prévia junto aos potenciais consumidores de dados para identificar a relevância dos dados.
Criação: Esta fase compreende a etapa de extração dos dados de fontes de dados já existentes até a sua transformação para o formato adequado para publicação na Web e, além disso, nesta fase também devem ser criados os metadados que irão descrever os dados (LÓSCIO; OLIVEIRA; BITTENCOURT,2015). Seguindo as Boas Práticas (LÓSCIO; BURLE; CALEGARI,2016a), é importante considerar a publicação em diferentes formatos (distribuições), minimizando a necessidade de transformação dos dados por parte dos consumidores.
Publicação: Compreende o momento em os dados se tornam acessíveis na Web, ou seja, serão disponibilizados na Web sob uma licença.Lóscio, Oliveira e Bittencourt (2015) acrescenta que podem ser usadas ferramentas de catalogação de dados, que
2.4. CICLO DE VIDA DOS DADOS NA WEB 31
serão descritas na próxima sessão, ou APIs e que o produtor dos dados também deverá disponibilizar as informações necessárias para que o consumidor tenha fácil acesso aos dados. Outrossim, também é importante seguir Boas Práticas como, por exemplo, manter os dados atualizados conforme frequência de atualização pré-definida, a qual deverá ser disponibilizada juntamente com os dados como um metadado (LÓSCIO;
OLIVEIRA; BITTENCOURT,2015;LÓSCIO; BURLE; CALEGARI,2016a).
Acesso: Após os dados serem publicados, é necessário informar que eles estão disponíveis e acessíveis. Assim, esta fase consiste no momento do ciclo de vida em que os usuários ganham acesso aos dados (LÓSCIO; OLIVEIRA; BITTENCOURT, 2015).
Consumo:Denota o momento em que os dados são consumidos, seja para a criação de visualização, como gráficos e mapas de calor, bem como para aplicações que permitem o cruzamento e a realização de análises sobre os dados (LÓSCIO; OLI-VEIRA; BITTENCOURT,2015). Isto é, esta etapa do ciclo de vida está diretamente relacionada ao consumidor de dados. Dentre os consumidores, podemos citar desde um desenvolvedor interessado em criar uma aplicação que faça uso dos dados, como pessoas interessads em transformar os dados para geração de informações relevantes, como também grandes empresas interessada em usar os dados para melhoria de seus produtos e serviços e, até mesmo, um outro sistema que consuma os dados. Ademais, vale salientar que se os dados forem usados e alterados pelo próprio produtor, não é o caso de consumo de dados e sim de refinamento. O consumo de dados nesta fase é essencialmente vinculado ao uso externo dos dados (MöLLER,2013).
Feedback: Os produtores de dados querem garantir que os dados publicados satis-façam as necessidades dos consumidores (LÓSCIO; BURLE; CALEGARI,2016a). Dessa forma, esta fase compreende o momento em que os consumidores devem prover comentários sobre os dados e metadados utilizados, permitindo identificar me-lhorias e correções nos dados publicados, além de manter um canal de comunicação entre os produtores e consumidores (LÓSCIO; OLIVEIRA; BITTENCOURT,2015).
Refinamento: Esta fase compreende todas as atividades relacionadas a atualizações nos dados publicados ou adição de novos. Ou seja, está relacionada a garantia de manutenção dos dados previamente publicados e que podem ser realizadas a partir dos comentários de feedback coletados na fase anterior. Além disso,Lóscio, Oliveira e Bittencourt(2015) aponta que a manutenção pode ser feita gerando novas versões para garantir que os dados não fiquem obsoletos, fazendo um correto gerenciamento das diferentes versões e fornecendo acesso a versão correta dos dados para os con-sumidores. Contudo,Lóscio, Burle e Calegari (2016a) aponta que não existe um consenso de quando um conjunto de dados deve ser considerado uma nova versão
BURLE; CALEGARI,2016a). Por fim, com o ambiente dinâmico e heterogêneo da Web, é possível que até mesmo os dados arquivados possam ser utilizados juntamente com outros dados, sendo formados novos conjuntos de dados.
Portanto, o ciclo de vida dos dados na Web, em nosso trabalho, compreende desde a fase de planejamento até a fase de término. Durante esse processo, os atores desempenham o papel de produtor de dados e o de consumidor de dados. De modo geral, o produtor é responsável por informar os metadados, criar e publicar os dados. Enquanto que os consumidores são atores que consomem os dados, podendo ser eles mesmo produtores, uma vez que podem realizar melhorias e refinamentos nos dados a fim de publicá-los novamente (LÓSCIO; OLIVEIRA;
BITTENCOURT, 2015). Apesar de ser um ciclo, é passível que nem todas as etapas sejam
seguidas até que uma nova iteração seja iniciada. Isto é, mesmo sendo um ciclo não quer dizer que os dados tenham que passar pela etapa de término para iniciar uma nova iteração ou que precisem receber um feedback antes do produtor realizar um refinamento nos dados.
33 33 33
3
Publicação de Dados na Web
Neste capítulo abordaremos as soluções que provêm catálogos de dados e as boas práticas para Dados na Web. Na Seção 3.1 apresentamos as características das principais soluções atualmente disponíveis para catalogação de dados na Web. Já na Seção 3.2 são descritas as boas práticas para dados na Web e, na Seção 3.3, analisamos os softwares a vista das melhores práticas.
3.1
Soluções para Catalogação de Dados
O Ciclo de Vida dos Dados na Web, descrito no Capítulo 2 compreende e descreve as fases do processo de publicação e consumo de dados na Web. Nesse ciclo, a publicação mantém a interface de quem disponibiliza os dados com as pessoas que vão utilizá-los. Isto é, os dados devem ser disponibilizados nos chamados catálogos de dados (MAALI; ERICKSON; ARCHER, 2014), que podem ser entendidos como um mecanismo, ferramenta ou serviço que é responsável pela gestão e publicação de dados e metadados na Web.
Além da publicação, os catálogos também devem dar suporte a outras etapas do ciclo de vida, como o acesso, permitir o consumo, receber feedback e permitir o gerenciamento da manutenção dos conjuntos de dados. Existem vários softwares que provêm tais catálogos, permitindo a publicação dos dados e metadados, tornando os conjuntos de dados acessíveis, bem como permitindo o compartilhamento e o uso deles. Exemplos desses softwares são: CKAN1, Socrata2, Junar3, OpenDataSoft4e ArcGIS Open Data5. Nas próximas seções, descrevemos as principais características de cada uma dessas soluções.
1http://ckan.org/ 2https://socrata.com/ 3http://junar.com/
4https://www.opendatasoft.com/ 5http://opendata.arcgis.com/
HTML, CSS, Javascript, PostgreSQL e SQLAlchemy. Sua arquitetura foi projetada para aceitar extensões (Plugins) que permitem estender suas funcionalidades ou modificar as já existentes, conforme apresentado numa breve visão de sua arquitetura na Figura 3.1.
Figura 3.1: Arquitetura do CKAN. Fonte:
<http://docs.ckan.org/en/latest/contributing/architecture.html>
A camada Routes realiza um vínculo entre a Uniform Resource Locator (URL) que é acessada com a Views que irá processar a solicitação. A camada Views recebe a requisição de leitura ou atualização de dados e encaminha para a camada Logic. Já a camada Logic inclui funções de ação, autenticação, tarefas em segundo plano e lógica de negócios. Assim, ela se comunica com a camada Models, que mantém a abstração de acesso e consulta ao banco de dados, para realizar as ações pretendidas. Assim, quando algo é consultado, a camada View envia, recebe e processa a resposta da camada Logic. Do mesmo modo, se a requisição for direcionada para API, ela processará e retornará os dados em formato JSON. Ademais, os Plugins
3.1. SOLUÇÕES PARA CATALOGAÇÃO DE DADOS 35
implementam a mesma sequência de camadas e conseguem manter comunicação em todos os níveis do CKAN (CKAN,2013).
3.1.2
Junar
O Junar também é outro software usado para criação de portais de catalogação de dados. Ele faz uso do conceito de Software como Serviço (SaaS), tem sua plataforma baseada em nuvem e permite a visualização dos dados em qualquer dispositivo. É usado no portal oficial de dados abertos do Chile, Costa Rica e de algumas cidades dos Estados Unidos. Segundo sua documentação, ele oferece alta largura de banda, armazenamento escalável e uma excelente confiabilidade por meio da Amazon Web Services (JUNAR,2015).
Segundo a documentação do Junar (JUNAR,2015), principais módulos de sua solução estão concentrados na coleta dos dados, aprimoramento, publicação, compartilhamento e análises através de relatórios, conforme pode ser visualizado na Figura 3.2. O Junar suporta diferentes formatos de dados para publicação. A partir da obtenção deles, que pode ser de diferentes fontes, são fornecidas as ferramentas necessárias para administração dos dados, que é controlada por uma hierarquia de usuários, permitindo que o conjunto de dados seja publicado apenas após aprovação. Uma vez publicado, pode ser acessado pelo portal ou através da API.
Figura 3.2: Visão geral do processo de Publicação no Junar. Fonte: <http://junar-cdn-brandings.s3.amazonaws.com/ebook/ Overview-Junar-Open-Data-Portal-for-IT-Professionals-N0511.pdf>
De forma geral, o Junar possibilita a publicação de Dataset e ferramentas para gerencia-mento quando é criado um Dataview, que pode conter subconjuntos de dados ou até mesmo o Datasetcompleto. Além disso, é possível que os administradores publiquem gráficos visando oferecer aos usuários um acesso rápido a visualização dos dados. A Figura 3.3 exemplifica o processo de publicação de dados no Junar, que a partir da coleta de um conjunto de dados, permite criar os recursos de dados que são as Dataviews e os gráficos, para, assim, disponibilizar os recursos ao público.
Figura 3.3: Exemplo de publicação de dados no Junar. Fonte: <http://junar-cdn-brandings.s3.amazonaws.com/ebook/ Overview-Junar-Open-Data-Portal-for-IT-Professionals-N0511.pdf>
3.1.3
Socrata
O Socrata é um software baseado em nuvem e na ideia de SaaS, seu principal diferencial é na construção de visualizações mais elaboradas, com formatação condicional, gráficos e mapas. Ele é usado no portal oficial do Kenya, no portal do Banco Mundial, em cidades e estados dos EUA como Chicago, Nova York, Austin, Maryland e Illinois. Apesar de ser pago, o Socrata está desenvolvendo uma versão Community Edition, que compartilha o mesmo núcleo da plataforma e será disponibilizada como open source. Alguns componentes do Socrata já estão disponibilizados de forma aberta e pode ser encontrada através de seu repositório no Github6.
O Socrata faz uso de diversas tecnologias, como o Javascript e o Ruby para o frontend, Java e Scala para o backend e tecnologias de armazenamento como o Postgres e Cassandra. Sua arquitetura é apresentada na Figura 3.4 e, por meio dela, verificamos que os caminhos de leitura e escrita foram divididos, o que segundo sua documentação, tem por objetivo fornecer acesso mais rápido para quem apenas utiliza os dados (SOCRATA,2016).
3.1. SOLUÇÕES PARA CATALOGAÇÃO DE DADOS 37
Figura 3.4: Arquitetura do Socrata. Fonte: <http://open-source.socrata.com/architecture/>.
A partir de uma inserção, atualização ou exclusão de dados enviado para o servidor SODA, o processo é iniciado no pacote de escrita. Assim, o pedido será transformado em uma séria de operações granulares chamadas de Primary Mutator. O Data Coordinator executará essas mutações na Truth store, que mantém a abstração para operações independente da tecnologia final utilizada para armazenamento. No caso específico da imagem acima, é mostrado um exemplo com o Postgres. Após o processamento do coordenador de dados ser concluído, o Secondary Watcher verifica se existem mudanças no armazenamento que não foram sincronizadas. Em seguida, o adaptador para o armazenamento secundário, neste caso o Elastic Search Adaptor, importa os dados a partir do primário (SOCRATA,2016).
No pacote de leitura, um pedido em SODA Query Language (SoQL) é enviado para o servidor. O servidor analisa o SoQL enviado e se estiver escrito de forma correta, envia o pedido para o Query Coordinator. Assim, ele verifica para qual solução de armazenamento o pedido deve ir, encaminhando o pedido para o respectivo adaptador. Por fim, o Adaptador executa a consulta e retorna os dados através do formato C-JSON (SOCRATA,2016).
publicação.
Figura 3.5: Arquitetura do OpenDataSoft. Fonte: <https://docs.opendatasoft.com/en/about.html>.
Em síntese, os dados podem ser coletados de forma manual ou através da captura automática, informando uma URL que permita acesso aos dados. Após carregar os dados, é possível realizar alterações neles, na estrutura do dataset e definir aspectos para os dados como definição de unidade, ordenação e separação de dados multivalorados. Nessa mesma etapa de processamento, também é possível adicionar Processors que vão enriquecer os dados ou normalizá-los. Após o processamento, é possível preencher os metadados disponíveis, disponíveis como subconjunto do DCAT. Com os dados publicados, a API é disponibilizada e as visualizações como tabelas e mapas são criadas automaticamente a partir dos dados, quando possível (OPENDATASOFT,2016).
3.1. SOLUÇÕES PARA CATALOGAÇÃO DE DADOS 39
3.1.5
ArcGIS Open Data
O ArcGIS Open Data permite realizar a busca de dados por tópicos ou locais, visualizar gráficos, tabelas e mapas interativos. A contar do seu lançamento em 2014, seu foco inicial foram os dados geográficos, porém ele vem melhorando significativamente desde então e, inclusive, é até possível integrar com outras plataformas de dados abertos como o CKAN, sincronizando automaticamente com a versão mais recente de suas fontes. Exemplos de uso são cidades e estados nos Estados Unidos, como Columbia, Utah (geoespacial), Washington (geoespacial), e no Canadá, como Halifax.
A arquitetura do ArcGis Open Data, ilustrada na Figura 3.6, é orientada a serviços. Dado seu foco inicial em dados geográficos, sua arquitetura se aproxima de uma infraestrutura voltada para um sistema de informação geográfica moderno, apresentando quatro grandes camadas: armazenamento de dados, curadoria de metadados, pesquisa e acesso ao público (ESRI,2015).
Figura 3.6: Arquitetura do ArcGis Open Data. Fonte:
<https://blogs.esri.com/esri/arcgis/2015/09/02/architecture-of-open-data/>.
Na camada de armazenamento de dados, ele oferece opção para armazenamento dos dados localmente ou na nuvem, permitindo o acesso através de uma API. Cada serviço de dados do Servidor ArcGis possui uma API, que permite consultas e agregações por aspectos espaciais, temporais e por atributos, fornecendo saída em JSON. Também permite se conectar com outras plataformas de dados abertos que utilizem CKAN e Socrata, por exemplo, para exportar os dados e trabalhar com as visualizações e análises da ferramenta. Além disso, faz uso
Drupal e com o Github, respectivamente, e também são de código aberto. Todavia, analisaremos o DKAN dado sua maior popularidade e que o JKAN tem o objetivo de prover uma solução leve e sem backend, visando apenas fornecer links que permitam realizar o download dos dados, sendo executado através do Github.
O desenvolvimento do DKAN é liderado por NuCivic7e foi desenvolvido a partir do CKAN 2.08 e Drupal 79. Sua principal linguagem é o PHP, faz uso do Sistema Gerenciador de Banco de Dados (SGBD) MySQL e do MariaDB10 e está disponível sob a segunda versão da licença GNU General Public License11. Por ser um distribuição do CKAN e Drupal, pode obter benefícios inerentes a cada um dos softwares, por exemplo, todos os módulos adicionais disponíveis para o Drupal podem ser adicionados ao DKAN. Na forma padrão do software, ele é disponibilizado gratuitamente através de download. No entanto, também apresenta uma versão baseada em SaaS, que é paga e apresenta módulos adicionais que a diferem da versão gratuita (NUCIVIC,2015).
Figura 3.7: Visão adaptada da arquitetura do DKAN. Fonte: <http:
//www.slideshare.net/DavidPortnoy/ddod-the-lean-startup-approach-to-open-data> (adaptado pelo autor).
De forma geral, conforme apresentado na Figura 3.7, o DKAN utiliza-se do Drupal
7http://www.nucivic.com/ 8http://ckan.org
9https://www.drupal.org/drupal-7.0 10https://mariadb.org/
3.2. BOAS PRÁTICAS PARA DADOS NA WEB 41
para o gerenciamento de conteúdos, usuários e modularidade do software, e usa o CKAN para gerenciamento dos datasets, motor de busca, geolocalização e para prover a API. Por também ser disponibilizado como uma extensão do Drupal, ele também pode ser facilmente adicionado em sites já publicados. Seus três componentes principais são o DKAN distro, dataset e datastore. A distro é a distribuição do DKAN que agrupa todos os componentes necessários, como o tema do DKAN, pesquisa e outros elementos. O componente dataset é um módulo que fornece opção para publicação dos conjuntos de dados e de recursos, tal como o CKAN, ou seja, os conjuntos de dados contêm os metadados e os recursos os dados. No entanto, no DKAN os metadados estão disponíveis em RDF, que é compatível com o DCAT, bem como em JSON. Por fim, o datastoreé um módulo que fornece a capacidade de armazenar arquivos e disponibilizar os seus componentes através de uma API (NUCIVIC,2015).
3.2
Boas Práticas para Dados na Web
Existe um crescente interesse em publicar e consumir dados na Web. Organizações governamentais e não-governamentais já disponibilizam uma variedade de dados na Web, alguns abertamente, alguns com restrições de acesso, abrangendo muitos domínios como educação, economia, segurança, patrimônio cultural, comércio eletrônico e dados científicos. Desenvolve-dores, jornalistas e outros manipulam esses dados para criar visualizações e realizar análises de dados. A experiência neste domínio revela que é necessário abordar várias questões importantes a fim de satisfazer os requisitos tanto dos produtores de dados como dos consumidores de dados (LÓSCIO; BURLE; CALEGARI,2016b).
Além disso, segundoLóscio, Oliveira e Bittencourt(2015), nos últimos anos, a heteroge-neidade dos dados e a falta de padrões para descrição e acesso aos conjuntos de dados tornam o processo de publicação, compartilhamento e consumo de dados uma tarefa complexa. Portanto, buscam-se alternativas que possibilitem um entendimento comum entre os atores desse contexto, promovendo uma maior confiança nos dados e aumentando o potencial de inovação. Ou seja, publicar dados de forma que possam ser facilmente compreendidos e utilizados por consumido-res, assim como, publicados em formatos que possam ser facilmente processados por aplicações, por exemplo. Pois, sem esse entendimento e confiança, os esforços dos provedores podem ser incompatíveis com os desejos dos consumidores de dados (LÓSCIO; BURLE; CALEGARI, 2016b).
Na busca por esse entendimento comum, um grupo de trabalho do W3C compilou um conjunto de casos de uso12 que representam cenários de como os dados são comumente publicados e como eles são usados na Web. A partir desses casos de uso, foi possível identificar os principais desafios enfrentados pelos produtores e consumidores de dados, assim como, foi possível definir um conjunto de requisitos. Tais desafios e requisitos guiaram o desenvolvimento do documento DWBP (LÓSCIO; BURLE; CALEGARI,2016a), que estabelece boas práticas
Licença Permitir que os seres humanos compreendam as informações da licença e que as máquinas possam detectar automaticamente
Proveniência Permitir que os seres humanos conheçam a origem ou o histórico do con-junto de dados e e que as máquinas possam processar automaticamente tais informações
Qualidade Documentar a qualidade dos dados, para facilitar o processo de seleção dos conjuntos de dados e chaces de reutilização
Versionamento Permitir que versões dos dados sejam geradas e seja possível o acesso a cada versão
Identificação Fornecer identificadores únicos para os conjuntos de dados e distribuições Formato Escolher formatos que permitam o uso e o reuso
Vocabulários A fim de melhorar a interoperabilidade e manter terminologia comum entre os produtores e consumidores
Acesso Permitir o fácil acesso aos dados usando a infraestrutura da Web tanto para seres humanos quanto para máquinas
Preservação A fim de indicar corretamente se os dados foram removidos ou arquivados Feedback Receber feedback dos consumidores e assegurar que os dados atendem as
necessidades dele
Enriquecimento Enriquecer, melhorar ou refinar os dados brutos agregando valor Republicação Permitir que os dados utilizados possam ser republicados
Fonte: (LEE; LÓSCIO; ARCHER,2015)
Assim, o DWBP desenvolveu as boas práticas partindo dos desafios apresentados no Quadro 3.1 e dos diferentes requisitos de casos de uso relacionados a cada desafio, descritos emLee, Lóscio e Archer(2015). No total, são 35 boas práticas que discursam sobre diferentes aspectos relacionados à publicação e consumo de dados, como formatos de dados, acesso a dados, identificadores de dados e metadados. SegundoLóscio, Burle e Calegari (2016a), espera-se que ao seguir as boas práticas, uma série de benefícios distintos possam ser alcançados, tais como a compreensão, processabilidade, descoberta, reúso, acesso e interoperabilidade. Porém, ainda existem desafios a serem enfrentados, seja para avaliar se tais benefícios são alcançados, disponibilidade de ferramentas de publicação que implementem as orientações, bem como, quais os passos, do ponto de vista técnico, que devem ser seguidos e implementados até os dados serem publicados.
3.2. BOAS PRÁTICAS PARA DADOS NA WEB 43
Conforme descrito emLóscio, Burle e Calegari(2016a), cada boa prática (BP) tem um resultado pretendido com a aplicação da prática. Esse resultado indica o que é possível fazer quando um produtor segue as recomendações e está relacionado a como um consumidor de dados (um humano ou um software) pode manipular um conjunto de dados na Web, assim como pode refletir em uma melhora no próprio conjunto de dados. Além disso, apresenta uma seção para possíveis formas de implementação da prática, a motivação para o uso e os testes que podem ser realizados para verificar se a prática foi implementada de forma adequada. No restante, ainda apresenta as evidências que comprovam a relevância da prática e os benefícios que serão alcançados com o uso dela. No Quadro 3.2 é apresentado o conjunto de boas práticas e qual o desafio ao qual ela está relacionada.
BP10: Use persistent URIs as identifiers within datasets Identificação BP11: Assign URIs to dataset versions and series Identificação BP12: Use machine-readable standardized data formats Formato BP13: Use locale-neutral data representations Formato BP14: Provide data in multiple formats Formato BP15: Reuse vocabularies, preferably standardized ones Vocabulários BP16: Choose the right formalization level Vocabulários BP17: Provide bulk download Acesso BP18: Provide Subsets for Large Datasets Acesso BP19: Use content negotiation for serving data available in multiple formats Acesso BP20: Provide real-time access Acesso BP21: Provide data up to date Acesso BP22: Provide an explanation for data that is not available Acesso BP23: Make data available through an API Acesso BP24: Use Web Standards as the foundation of APIs Acesso BP25: Provide complete documentation for your API Acesso BP26: Avoid Breaking Changes to Your API Acesso BP27: Preserve identifiers Preservação BP28: Assess dataset coverage Preservação BP29: Gather feedback from data consumers Feedback BP30: Make feedback available Feedback BP31: Enrich data by generating new data Enriquecimento BP32: Provide Complementary Presentations Enriquecimento BP33: Provide Feedback to the Original Publisher Republicação BP34: Follow Licensing Terms Republicação BP35: Cite the Original Publication Republicação
Fonte: (LÓSCIO; BURLE; CALEGARI,2016a)
Segundo oLóscio, Burle e Calegari(2016a), a Web é um espaço de informação aberta, sendo caracterizada pela ausência de um contexto específico, o que significa que o fornecimento de metadados é um requisito fundamental. Dessa forma, os metadados ajudam os consumidores a compreenderem o significado dos dados, sua estrutura, licença, organização que gerou os dados, métodos de acesso e agendamento de futuras atualizações dos conjuntos de dados. Dessa
