Lairson Emanuel R. de Alencar Oliveira

Transcrição

1 Lairson Emanuel R. de Alencar Oliveira UM MODELO DE ARQUITETURA PARA SISTEMAS GERENCIADORES DE DADOS NA WEB Universidade Federal de Pernambuco < RECIFE 2017

2 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 Universidade 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

3 Catalogação na fonte Bibliotecária Monick Raquel Silvestre da S. Portes, CRB O48m Oliveira, Lairson Emanuel Rodrigues de Alencar Um modelo de arquitetura para sistemas gerenciadores de dados na Web / Lairson Emanuel Rodrigues de Alencar Oliveira f.: il., fig. Orientadora: Bernadette Farias Lóscio. Dissertação (Mestrado) Universidade Federal de Pernambuco. CIn, Ciência da Computação, Recife, Inclui referências. 1. Banco de dados. 2. Web semântica. I. Lóscio, Bernadette Farias (orientadora). II. Título CDD (23. ed.) UFPE- MEI

4 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 (Orientadora)

5 Dedico esta dissertação a minha esposa, Wanessa Botelho, a toda minha família, amigos e professores que de alguma maneira contribuíram para sua realização.

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

7 Agradeço a todos da minha família que me apoiaram e ajudaram a construir a pessoa que sou hoje. Obrigado Mainha (Edinete Alencar), Painho (Wilson Oliveira), Lopinho (Antônio Lopes), Lalá (Larissa Alencar), Tatá (Thaissa Alencar), Lulinho (Yuri Alencar), Aninha (Ana Maria), Lidinha (Ana Lídia), Júlio (Cunhado) e, em especial, a meu sobrinho Miguel Ângelo que mesmo eu ficando um pouco longe nesse momento, cada vez que o vi minhas forças foram renovadas com abraços carinhosos e um "Titio"que encheram meu coração de alegria! Muito obrigado aos demais familiares que contribuíram e não estou citando aqui. Por fim, agradeço à Fundação de Amparo à Ciência e Tecnologia do Estado de Pernambuco (FACEPE) pelo financiamento, na qual possibilitou a realização deste trabalho.

8 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

9 Resumo A grande quantidade de dados disponível na Web, juntamente com a facilidade de acesso e representação desses dados, criam novos desafios tanto para quem deseja publicar e compartilhar dados na Web quanto para os que desejam usar tais dados. De modo geral, não existe um conhecimento prévio entre os interesses de quem publica os dados, os produtores, e os interesses de quem consome os dados, os consumidores. Nesse contexto, recentemente foi proposta, pelo W3C, uma recomendação para Dados na Web, que busca um entendimento comum entre os produtores e os consumidores e discursa sobre diferentes aspectos relacionados 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. Palavras-chave: Catalogação de Dados. Boas Práticas. Dados na Web. SGDW. Serviços

10 Abstract The large amount of data available on the Web along with the ease access and representation 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 understanding 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. Keywords: Data Catalog. Best Practices. Data on the Web. DWMS. Services

11 Lista de Figuras 2.1 Comparação entre a publicação de dados na Web e a abordagem de bancos de dados convencionais. Fonte: (LÓSCIO; OLIVEIRA; BITTENCOURT, 2015) Evolução da Web 1.0 para Web 3.0. Fonte: (DWIVEDI et al., 2011) Contexto de Publicação dos Dados na Web. Fonte: (LÓSCIO; BURLE; CALEGARI, 2016a) Esquema de 5 estrelas para os Dados Abertos. Fonte: Dados na Web x Open Data x Linked Data. Fonte: (LÓSCIO; BURLE; CALEGARI, 2016b) Ciclo de Vida dos Dados na Web proposto por Lóscio, Oliveira e Bittencourt (2015). Fonte: (LÓSCIO; OLIVEIRA; BITTENCOURT, 2015) Ciclo de Vida dos Dados na Web proposto pelo autor. Fonte: o autor Arquitetura do CKAN. Fonte: < html> Visão geral do processo de Publicação no Junar. Fonte: < s3.amazonaws.com/ebook/overview-junar-open-data-portal-for-it-professionals-n0511. pdf> Exemplo de publicação de dados no Junar. Fonte: < amazonaws.com/ebook/overview-junar-open-data-portal-for-it-professionals-n0511. pdf> Arquitetura do Socrata. Fonte: < Arquitetura do OpenDataSoft. Fonte: < Arquitetura do ArcGis Open Data. Fonte: < 09/02/architecture-of-open-data/> Visão adaptada da arquitetura do DKAN. Fonte: < ddod-the-lean-startup-approach-to-open-data> (adaptado pelo autor) Fases de um Conjunto de Dados. Fonte: o autor Modelo de Arquitetura para um SGDW. Fonte: o autor Fluxo de Atividades para o Serviço de Extração e Transformação de Dados. Fonte: o autor Fluxo de Atividades para o Serviço de Criação de Conjuntos de Dados. Fonte: o autor Fluxo de Atividades para o Serviço de Gerenciamento de Metadados. Fonte: o autor Fluxo de Atividades para o Serviço de Gerenciamento de Versões. Fonte: o autor Consumo das versões dos conjuntos de dados. Fonte: o autor

12 5.7 Fluxo de Atividades para o Serviço de Gerenciamento de Atualizações. Fonte: o autor Fluxo de Atividades para o Serviço de Gerenciamento de Acesso. Fonte: o autor Fluxo de Atividades para o Serviço de Preservação de Conjuntos de Dados. Fonte: o autor Fluxo de Atividades para o Serviço Gerenciamento do Uso dos Dados. Fonte: o autor Arquitetura da Prova de Conceito (SGDW-v01). Fonte: o autor Arquitetura do Angular (a) e Estrutura de pastas do projeto da Interface Web do produtor (b). Fonte: o autor Principais Casos de Uso da Solução. Fonte: o autor Tela de login do sistema do produtor. Fonte: o autor Token salvo na Session Storage (a) e Token gerado após simular uma requisição a API (b). Fonte: o autor Cadastro de fonte de dados. Fonte: o autor Tipos de SGBDs recebidos por meio da API. Fonte: o autor Processo de extração de dados implementado na Prova de Conceito. Fonte: o autor Método que gerencia as conexões dinamicamente usando o Hibernate. Fonte: o autor Método que recupera os dados a partir de uma conexão Método que converte os dados para JSON. Fonte: o autor Método que armazena o arquivo no servidor. Fonte: o autor Formulário de criação de conjunto de dados. Fonte: o autor Exemplo de criação de identificador automático. Fonte: o autor Distribuições disponíveis. Fonte: o autor 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 Histórico das versões geradas de um conjunto de dados. Fonte: o autor Acesso a uma versão específica de um conjunto de dados. Fonte: o autor Método que implementa o agendador de tarefas automático. Fonte: o autor Atualização manual (não programada) de um conjunto de dados. Fonte: o autor Métodos de acesso aos conjuntos de dados Exemplo de método e rota da API. Fonte: o autor API AdminREST com os métodos, rotas e descrição, respectivamente. Fonte: o autor API OpenREST com os métodos, rotas e descrição, respectivamente. Fonte: o autor Testes da API a partir da documentação. Fonte: o autor Tela principal da Interface Web para os consumidores. Fonte: o autor

13 Lista de Quadros 3.1 Desafios na publicação de dados na Web Boas práticas para dados na Web Catálogos de Dados X Boas Práticas Soluções Atuais X Requisitos Premissas e Requisitos para o compartilhamento de dados x Serviços do modelo de arquitetura proposto Serviços da Prova de Conceito x Requisitos de um SGDW

14 Lista de Acrônimos WWW World Wide Web SGDW Sistema Gerenciador de Dados na Web API Application Programming Interface SBD Sistemas de Bancos de Dados SQL Structured Query Language HTTP Hypertext Transfer Protocol ACID Atomicidade, Consistência, Isolamento e Durabilidade BASE Basically Available, Soft State, and Eventual Consistency SPARQL SPARQL Protocol and RDF Query Language RDF Resource Description Framework URI Universal Resource Identifier ADLM Abstract Data Lifecycle Model URL Uniform Resource Locator SaaS Software como Serviço SoQL SODA Query Language SGBD Sistema Gerenciador de Banco de Dados DWBP Data on the Web Best Practices REST Representational State Transfer (REST) DUV Dataset Usage Vocabulary WAR Web application ARchive SPA Single Page Application JS JavaScript CSS Cascading Style Sheets IIS Internet Information Services JDBC Java Database Connectivity

15 Sumário 1 Introdução Motivação Caracterização do Problema Objetivos e Contribuições Estrutura da dissertação Fundamentação Teórica Bancos de Dados Convencionais X Dados na Web Ecossistemas de dados na Web Dados na Web x Dados Abertos x Dados Conectados Ciclo de Vida dos Dados na Web Publicação de Dados na Web Soluções para Catalogação de Dados CKAN Junar Socrata OpenDataSoft ArcGIS Open Data DKAN Boas Práticas para Dados na Web Soluções de Catalogação de dados X Boas Práticas Compartilhamento de Dados na Web Conceitos básicos Premissas do compartilhamento de Dados na Web Requisitos para as soluções de compartilhamento de Dados na Web Requisitos da Premissa Requisitos da Premissa Requisitos da Premissa Requisitos da Premissa Análise das soluções existentes de acordo com os requisitos Sistemas Gerenciadores de Dados na Web - SGDW Visão geral de um SGDW Camada de Acesso

16 5.1.2 Camada de Serviços Camada de Dados e Metadados Detalhamento da Camada de Serviços Extração e Transformação dos Dados Criação de conjuntos de dados Gerenciamento de Metadados Gerenciamento de Versões Gerenciamento de Atualização Gerenciamento de Acesso Preservação dos Conjuntos de dados Gerenciamento do Uso dos Dados Conclusão Prova de conceito do Modelo de Arquitetura para um SGDW Visão geral da implementação Arquitetura e tecnologias de implementação Funcionalidades Implantação Adequação da Implementação aos Requisitos Collector Cadastro de Fonte de Dados Extração e Transformação de Dados Criação de Conjuntos de Dados Gerenciamento de URIs Gerenciamento de Distribuições Gerenciamento de metadados Gerenciamento de Versões Gerenciamento de Atualizações Gerenciamento de Acesso Interface Web Consumidor Conclusão Conclusão Considerações Finais Trabalhos Futuros Referências 111

17 16 1 Introdução 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

18 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 , 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 1

19 1.2. CARACTERIZAÇÃO DO PROBLEMA 18 abordamos o desenvolvimento de uma solução que permita o gerenciamento de conjuntos de dados, forneça ferramentas para os atores do Ecossistema de Dados na Web e faça uso das boas práticas estabelecidas pelo W3C para publicação e consumo dos dados. 1.2 Caracterização do Problema O crescente interesse no uso da Web para compartilhamento de dados tem motivado o desenvolvimento de soluções para publicação de dados, como as ferramentas de catalogação CKAN 2, Socrata 3, Junar 4, OpenDataSoft 5 e ArcGIS Open Data 6. Porém, por não existir um framework ou 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 automática dos conjuntos de dados com frequências de atualização pré-definidas, gerenciamento de feedback e 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

20 1.3. OBJETIVOS E CONTRIBUIÇÕES 19 dos consumidores de dados. Segundo Ló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 por Umbrich, 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 com Brito 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 compartilhamento 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 mencionadas 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 consideraçã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 1.4. ESTRUTURA DA DISSERTAÇÃO Estrutura da dissertação Os próximos capítulos estão organizados como se segue. No Capítulo 2, é apresentado a fundamentação teórica deste trabalho. Já no Capítulo 3, abordamos aspectos relacionados a publicação de dados na Web, como as características das principais soluções atuais. No Capítulo 4, apresentamos as premissas e requisitos necessários para as soluções de compartilhamento de Dados na Web. O Capítulo 5 apresenta o modelo de arquitetura proposto para o SGDW, enquanto o Capítulo 6 apresenta os detalhes da prova de conceito realizada. Por fim, no Capítulo 7 é feito uma pequena discussão sobre o trabalho realizado e sugestões para os trabalhos futuros.

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

23 2.1. BANCOS DE DADOS CONVENCIONAIS X DADOS NA WEB 22 Figura 2.1: Comparação entre a publicação de dados na Web e a abordagem de bancos 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

24 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 participaçã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). Segundo Rudman 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 acompanhada pelo avanço da tecnologia, quanto por novas demandas, e conta com uma grande e

25 2.2. ECOSSISTEMAS DE DADOS NA WEB 24 crescente quantidade de dados disponíveis. Porém, Isotani e Bittencourt (2015) aponta que muitos 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. Gama e LÓscio (2014) apontam a importância de criar 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. Conforme podemos verificar na Figura 2.2, desde sua origem, a Web foi baseada em papéis de produtor e consumidor. Hoje, tais papéis juntamente com os dados são a base para formar um Ecossistema de Dados na Web. 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 envolvidos 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, podendo 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 condiçõ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 por Elmasri 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 consumidores 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

26 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) Segundo Ló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 distribuiçõ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 o Ló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 DCAT 1 que foi projetado para facilitar a interoperabilidade entre catálogos de dados na Web. 1

27 2.3. DADOS NA WEB X DADOS ABERTOS X DADOS CONECTADOS Dados na Web x Dados Abertos x Dados Conectados Uma série de esforços vem sendo desenvolvido em todo o mundo, objetivando o compartilhamento e consumo dos dados na Web, dentre eles, destacam-se a publicação de dados em formato aberto (open data) e linked data. Segundo Lóscio, Burle e Calegari (2016b), Dados na Web é o termo mais geral que pode ser usado denotar dados publicados de acordo com os princípios da arquitetura Web 2. Segundo Dietrich et al. (2009), os dados são abertos quando qualquer pessoa pode livremente usá-los, reutilizá-los e redistribuí-los, estando sujeito, no máximo, à exigência de 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: 2

28 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 com Ló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.

29 2.4. CICLO DE VIDA DOS DADOS NA WEB 28 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,

30 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 por Ló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 por Ló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 por Möller (2013) como o momento em que os dados são removidos do sistema e também é apresentada no modelo de Catteau, 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 em Isotani 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 por Lóscio, Oliveira e Bittencourt (2015) somado a fase de término proposta neste trabalho.

31 2.4. CICLO DE VIDA DOS DADOS NA WEB 30 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

32 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 satisfaç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 melhorias 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 consumidores. 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

33 2.4. CICLO DE VIDA DOS DADOS NA WEB 32 ou ser alterado completamente, porém é considerado uma boa prática fornecer um histórico completo das versões e indicar um número de versão ou data para cada conjunto de dados. Término: Esta fase compreende o momento em que os produtores "removem"os dados da Web. É possível que os dados sejam alterados e movidos para um novo conjunto de dados ou até mesmo arquivados, a depender da necessidade do produtor. No entanto, é importante que os consumidores sejam alertados sobre esse procedimento. Assim, é importante seguir as boas práticas mantendo a URI e apresentando informações que identifiquem seu arquivamento ou para onde os dados foram movidos (LÓSCIO; 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.

34 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: CKAN 1, Socrata 2, Junar 3, OpenDataSoft 4 e ArcGIS Open Data 5. Nas próximas seções, descrevemos as principais características de cada uma dessas soluções

35 3.1. SOLUÇÕES PARA CATALOGAÇÃO DE DADOS CKAN O CKAN é uma solução open source que permite a exposição de catálogos de dados, bem como oferece funções para publicação, armazenamento e gerenciamento dos conjuntos de dados. Por ser livre, não tem custos e tem uma curva de aprendizado muito positiva. Conta ainda com uma API para acesso automatizado, pré-visualização de dados, gráficos e mapas, somado à busca de datasets geolocalizada. É utilizado por diversos países em todo o mundo, como o Brasil, Uruguai, Canadá, Reino Unido, Estados Unidos, Romênia, Austrália, Holanda, Itália e Alemanha. O CKAN foi desenvolvido em Python e faz uso de outras tecnologias e linguagens, como 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: < 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

36 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) 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: < Overview-Junar-Open-Data-Portal-for-IT-Professionals-N0511.pdf> De forma geral, o Junar possibilita a publicação de Dataset e ferramentas para gerenciamento quando é criado um Dataview, que pode conter subconjuntos de dados ou até mesmo o Dataset completo. 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.

37 3.1. SOLUÇÕES PARA CATALOGAÇÃO DE DADOS 36 Figura 3.3: Exemplo de publicação de dados no Junar. Fonte: < Overview-Junar-Open-Data-Portal-for-IT-Professionals-N0511.pdf> 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 Github 6. 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). 6

38 3.1. SOLUÇÕES PARA CATALOGAÇÃO DE DADOS 37 Figura 3.4: Arquitetura do Socrata. Fonte: < 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).

39 3.1. SOLUÇÕES PARA CATALOGAÇÃO DE DADOS OpenDataSoft O OpenDataSoft pode ser encontrado em alguns portais de cidades como Brussels e Paris, além da Córsega, Île de France e o jornal L Équipe. Seu principal diferencial é a facilidade para buscar, navegar e realizar filtros dentro dos datasets, que geram automaticamente o código para consumo via API. Somado a isso, visa facilitar a publicação dos dados exigindo poucos metadados e a construção de visualizações automáticas. Também é baseado em SaaS e concentra-se em prover uma plataforma voltada para usuários não-técnicos, ou seja, que seja simples para compartilhar, publicar e reutilizar dados. Uma visão de sua arquitetura é apresentada na Figura 3.5, que mostra o processo da coleta a publicação. Figura 3.5: Arquitetura do OpenDataSoft. Fonte: < 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).

40 3.1. SOLUÇÕES PARA CATALOGAÇÃO DE DADOS 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: < 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

41 3.1. SOLUÇÕES PARA CATALOGAÇÃO DE DADOS 40 do DCAT para descrever os metadados dos datasets. Quanto à consulta, acrescenta integração com navegadores Web e SDKs para desenvolvedores, somado a marcações RDF para motores de busca da Web e busca semântica. Dessa forma, permite que os dados sejam acessados publicamente através de portais, disponibilizando bibliotecas e aparatos para construção de aplicações, além da construções de mapas e visualizações de forma automática (ESRI, 2015) DKAN Além das soluções já apresentadas, existem outras alternativas como o DKAN e JKAN, que se utilizam do CKAN para gerar portais com integrações com o gerenciador de conteúdo 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 NuCivic 7 e foi desenvolvido a partir do CKAN e Drupal 7 9. Sua principal linguagem é o PHP, faz uso do Sistema Gerenciador de Banco de Dados (SGBD) MySQL e do MariaDB 10 e está disponível sob a segunda versão da licença GNU General Public License 11. 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: // (adaptado pelo autor). De forma geral, conforme apresentado na Figura 3.7, o DKAN utiliza-se do Drupal

42 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. Desenvolvedores, 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, segundo Lóscio, Oliveira e Bittencourt (2015), nos últimos anos, 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. 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 consumidores, 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 uso 12 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 12

43 3.2. BOAS PRÁTICAS PARA DADOS NA WEB 42 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. De forma geral, os desafios e requisitos versam sobre questões técnicas, como formatos de dados, e não-técnicas, como escolha de uma licença, sendo apresentados no Quadro 3.1. Quadro 3.1: Desafios na publicação de dados na Web. Desafio Metadados Licença Proveniência Qualidade Versionamento Identificação Formato Vocabulários Acesso Preservação Feedback Enriquecimento Republicação Descrição Permitir que os seres humanos entendam os metadados, interpretando a natureza e a estrutura dos dados, e que as máquinas também possam processá-los Permitir que os seres humanos compreendam as informações da licença e que as máquinas possam detectar automaticamente Permitir que os seres humanos conheçam a origem ou o histórico do conjunto de dados e e que as máquinas possam processar automaticamente tais informações Documentar a qualidade dos dados, para facilitar o processo de seleção dos conjuntos de dados e chaces de reutilização Permitir que versões dos dados sejam geradas e seja possível o acesso a cada versão Fornecer identificadores únicos para os conjuntos de dados e distribuições Escolher formatos que permitam o uso e o reuso A fim de melhorar a interoperabilidade e manter terminologia comum entre os produtores e consumidores Permitir o fácil acesso aos dados usando a infraestrutura da Web tanto para seres humanos quanto para máquinas A fim de indicar corretamente se os dados foram removidos ou arquivados Receber feedback dos consumidores e assegurar que os dados atendem as necessidades dele Enriquecer, melhorar ou refinar os dados brutos agregando valor 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 em Lee, 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. Segundo Ló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.

44 3.2. BOAS PRÁTICAS PARA DADOS NA WEB 43 Conforme descrito em Ló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.

45 3.2. BOAS PRÁTICAS PARA DADOS NA WEB 44 Quadro 3.2: Boas práticas para dados na Web. Boa Prática BP1: Provide metadata BP2: Provide descriptive metadata BP3: Provide structural metadata BP4: Provide data license information BP5: Provide data provenance information BP6: Provide data quality information BP7: Provide a version indicator BP8: Provide version history BP9: Use persistent URIs as identifiers of datasets BP10: Use persistent URIs as identifiers within datasets BP11: Assign URIs to dataset versions and series BP12: Use machine-readable standardized data formats BP13: Use locale-neutral data representations BP14: Provide data in multiple formats BP15: Reuse vocabularies, preferably standardized ones BP16: Choose the right formalization level BP17: Provide bulk download BP18: Provide Subsets for Large Datasets BP19: Use content negotiation for serving data available in multiple formats BP20: Provide real-time access BP21: Provide data up to date BP22: Provide an explanation for data that is not available BP23: Make data available through an API BP24: Use Web Standards as the foundation of APIs BP25: Provide complete documentation for your API BP26: Avoid Breaking Changes to Your API BP27: Preserve identifiers BP28: Assess dataset coverage BP29: Gather feedback from data consumers BP30: Make feedback available BP31: Enrich data by generating new data BP32: Provide Complementary Presentations BP33: Provide Feedback to the Original Publisher BP34: Follow Licensing Terms BP35: Cite the Original Publication Fonte: (LÓSCIO; BURLE; CALEGARI, 2016a) Desafio Metadados Metadados Metadados Licença Proveniência Qualidade Versionamento Versionamento Identificação Identificação Identificação Formato Formato Formato Vocabulários Vocabulários Acesso Acesso Acesso Acesso Acesso Acesso Acesso Acesso Acesso Acesso Preservação Preservação Feedback Feedback Enriquecimento Enriquecimento Republicação Republicação Republicação Segundo o Ló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

46 3.2. BOAS PRÁTICAS PARA DADOS NA WEB 45 forma, os resultados esperados com as BPs relacionadas a metadados versam sobre a capacidade de compreender os metadados (BP 1), assim como de interpretar a natureza dos conjuntos de dados e suas distribuições (BP 2) e interpretar o esquema deles (BP 3). Para se atingir essas três boas práticas, também é necessário fornecer acesso para que seja possível o processamento por máquinas. Dado que podem existir restrições quanto ao compartilhamento e reutilização dos dados, é importante informar a licença dos conjuntos de dados. No contexto de dados na Web, segundo o Lóscio, Burle e Calegari (2016a), a licença pode ser especificada nos metadados ou em um documento ao qual ele está vinculado (BP 4). Somado a isso, é a importante informar a origem dos dados (BP 5), uma vez que os dados podem ter sido oriundos de um produtor diferente do qual está publicando. Dessa forma, informar metadados de proveniência é uma forma de confiar na integridade e credibilidade dos dados que estão sendo compartilhados. Ademais, a qualidade dos conjuntos de dados também impactam na qualidade das aplicações que o utilizam. Dessa forma, é importante informar metadados de qualidade, contendo diferentes tipos de dimensões de qualidade (BP 6), como as que estão presentes no Data Quality Vocabulary 13. Os conjuntos de dados também podem mudar ao longo do tempo e, assim, Lóscio, Burle e Calegari (2016a) acrescenta que é importante manter versões dos dados que estão sendo alterados. Vale ressaltar que os conjuntos de dados podem se comportar como séries temporais e, nesse caso, não são consideradas várias versões do mesmo conjunto de dados. Por exemplo, quando se tem os mesmos tipos de dados para diferentes regiões ou para diferentes anos, ele deve ser tratado como uma série temporal e não como uma versão diferente. Portanto, é considerado uma boa prática atribuir e indicar o número de versão ou data para cada conjunto de dados (BP 7) e manter um histórico de todas as versões geradas (BP 8). Os identificadores são amplamente utilizados nos sistemas de informação, como por exemplo o HTTP (ou HTTPS) URIs, que é a base para comunicação de dados na Web. Dessa forma, Lóscio, Burle e Calegari (2016a) estabelece como boa prática o uso de URIs persistentes como identificadores de conjuntos de dados (BP 9), para as versões individuais geradas e, sendo uma série temporal, também para a série global (BP 11). Além disso, é necessário que se tenha cuidado na identificação, pois embora as URIs tenham a função puramente de identificar um recurso, não seria aconselhado que uma URI como retornasse qualquer coisa diferente de um CSV. Somado a isso, também é importante que URIs persistentes sejam utilizadas como identificadores dentro dos conjuntos de dados (BP 11), ou seja, incluir links para outras URIs de forma que outros recursos possam ser descobertos, tornando os dados mais valiosos. Quanto aos formatos dos dados, Lóscio, Burle e Calegari (2016a) afirma que o formato no qual os dados são disponibilizados é fundamental para tornar os dados utilizáveis pelos consumidores. Assim, encoraja a disponibilização dos dados em mais de um formato (BP 14), 13

47 3.2. BOAS PRÁTICAS PARA DADOS NA WEB 46 visando a utilização por um público amplo e processados facilmente por softwares. Dessa forma, é considerado boa prática disponibilizar os dados em formato legível por máquina (BP 12), como CSV, XML, HDF5, JSON, RDF / XML, JSON-LD, Turtle e outros. Também é aconselhado usar representações de dados que não são influenciados por localidades ou, quando não for possível, fornecer metadados sobre a localidade ou idioma usado pelos valores dos dados (BP 13). Em outras palavras, é preferível que se utilize representações consideradas neutras como os tipos de dados xsd:integer e xsd:date do esquema XML. Pois, a partir desses tipos neutros, não é necessário estabelecer regras de intercâmbio que variam de acordo com idiomas ou localização (LÓSCIO; BURLE; CALEGARI, 2016a). Visando uma maior interoperabilidade e consenso entre os produtores de dados e os consumidores, é considerado uma boa prática o reúso de vocabulários (BP 15), dando preferência aos padronizados. Os vocabulários definem os conceitos e atributos utilizados para descrever e representar uma área de interesse, como por exemplo, o vocabulário DCAT 14 que é utilizado para expressar os metadados relacionados aos conjuntos de dados e faz de uso de outros vocabulários difundidos como o Dublin Core 15, FOAF 16 e o SKOS 17. Também é preferível que se opte por um nível de semântica formal que possa encaixar os dados e as aplicações mais prováveis (BP 16), ajudando assim a estabelecer especificações precisas que transmitem significado detalhado e podendo servir de base para tarefas raciocínio automatizado (LÓSCIO; BURLE; CALEGARI, 2016a). O desafio de acesso aos dados é o que mais apresenta orientações de boas práticas. Proporcionar fácil acesso aos dados na Web, permite que os humanos e as máquinas aproveitem os benefícios da infra-estrutura da Web para uso e compartilhamento de dados. Por padrão, a Web oferece acesso aos dados através de métodos HTTP, o que permite acesso em um nível de transação atômica. Lóscio, Burle e Calegari (2016a) aponta que o acesso pode ser realizado através de bulk download simples de um arquivo e através de uma API, onde os dados são distribuídos em vários arquivos ou requer métodos de recuperação mais sofisticados, não sendo esses métodos básicos mutualmente exclusivos. Na abordagem de bulk download (BP 17), geralmente os dados são pré-processados pelo servidor e é fornecido apenas um arquivo para download. Em alguns casos, como quando os conjuntos de dados são grandes, pode-se oferecer opções através de APIs para efetuar operações e realizar download de subconjuntos dos dados (BP 18). Vale salientar que através das APIs também pode ser efetuado o download de todos os dados, assim como os subconjuntos de dados também podem ser disponibilizados em arquivos físicos menores para download. Nesse sentido, também é considerado uma boa prática o uso da negociação de conteúdo para permitir o download dos dados em vários formatos (BP 19). Por exemplo, a partir de uma mesma URI, usando a negociação de conteúdo, podemos obter os dados em JSON, XML, CSV, HTML e RDF

48 3.2. BOAS PRÁTICAS PARA DADOS NA WEB 47 (LÓSCIO; BURLE; CALEGARI, 2016a). Uma parte dos dados disponíveis na Web vem de sensores, por exemplo, que fornecem dados em tempo real. Dessa forma, é considerado uma boa prática torná-lo disponível na Web em tempo real ou quase em tempo real (BP 20), através de um sistema automatizado que permita o acesso imediato. Nesse caso, também são consideradas as taxas de atualização e latência por causa de etapas de pós processamento de dados, por exemplo. Quando os dados não são em tempo real, é considerado uma boa prática fornecer os dados atualizados, deixando a frequência de atualização explícita (BP 21). Eventualmente, se os dados não estiverem mais disponíveis, é importante fornecer uma explicação do porquê eles estão indisponíveis, como os dados podem ser acessados e quem pode acessar (BP 22) (LÓSCIO; BURLE; CALEGARI, 2016a). Uma API oferece uma maior flexibilidade e capacidade de processamento para os consumidores de dados, permitindo também o uso de dados em tempo real e realização de filtros. Sendo assim, considera-se uma boa prática disponibilizar uma API para acesso aos dados (BP 23), construindo a partir de padrões da Web (BP 24), como o Representational State Transfer (REST) (REST), e fornecendo uma documentação completa (BP 25). Dessa forma, a API estará mais completa e fácil de entender, o que permitirá que os desenvolvedores estejam mais dispostos a continuar a utilizá-la. Por fim, é importante que se evite alterações na API para não quebrar o código de quem está utilizando (BP 26) (LÓSCIO; BURLE; CALEGARI, 2016a). Tendo em vista que é provável que os produtores podem remover os dados da Web, é importante preservar seus identificadores. Assim, espera-se que seja possível dereferenciar o URI de um conjunto de dados mesmo ele não estando disponível e fornecer informações sobre o seu arquivamento (BP 27). Antes do arquivamento, Lóscio, Burle e Calegari (2016a) sugere a avaliação da cobertura do conjunto de dados (BP 28), verificando se os recursos utilizados já são preservados em algum lugar ou devem ser fornecidos juntamente com o respectivo conjunto de dados que será preservado. Com os dados publicados na Web, os consumidores podem acessá-los e criar suas próprias experiências. No entanto, os produtores de dados muitas vezes não tem o feedback dos consumidores sobre como os conjuntos de dados são usados e não oferecem maneiras eficazes para discutir essas experiências (LóSCIO; STEPHAN; PUROHIT, 2016). Dessa forma, Lóscio, Burle e Calegari (2016a) aponta como uma boa prática o fornecimento de pelo menos um mecanismo para receber feedback (BP 29) e sugere que eles estejam disponíveis ao público (BP 30). Assim, o produtor demonstrará aos consumidores que suas preocupações estão sendo abordadas, evitará o envio de problemas duplicados e promoverá o senso de comunidade entre eles. Consequentemente, através do feedback, os produtores também poderão melhorar a qualidade dos dados. O enriquecimento de dados consiste no conjunto de processos que podem ser utilizados para melhorar ou complementar os dados, visando tornar os dados mais valiosos. Dessa forma, sugere-se que os dados sejam enriquecidos através da geração de novos dados, quando estes vão aumentar o seu valor (BP 31). Também é aconselhável enriquecer os dados através de represen-

49 3.3. SOLUÇÕES DE CATALOGAÇÃO DE DADOS X BOAS PRÁTICAS 48 tações complementares, como visualizações, tabelas, aplicativos Web ou sínteses estatísticas (BP 32). Por fim, conforme Lóscio, Burle e Calegari (2016a) salienta, cuidados devem ser tomados para evitar o enriquecimento que distorce os resultados estatísticos ou enriquecimento que permitam identificar indivíduos, comprometendo a privacidade. Os consumidores também podem combinar os dados existentes com outros conjuntos de dados e criar aplicativos ou visualizações, por exemplo. Tais dados, portanto, podem ser disponibilizados novamente na Web através da republicação. Sendo assim, quando utilizar os dados, encontrar um erro ou elogios ou sugestões, é importante fornecer feedback para o produtor original dos dados (BP 33). No contexto da republicação, é considerado uma boa prática seguir os requisitos da licença original do conjunto de dados (BP 34), assim como citar a publicação original em seus metadados (BP 35), para que se mantenha a proveniência, reconheça a fonte de dados e torne os dados confiáveis. A partir do uso das boas práticas, os produtores de dados podem alcançar benefícios como Compreensão, Processabilidade, Descoberta, Reúso, Acesso, Interoperabilidade e Confiança. Dessa forma, é possível melhorar a compreensão dos dados através do uso de metadados, vocabulários, feedback e enriquecimento. Ou seja, será possível para os seres humanos ter uma melhor compreensão da estrutura, significado e a natureza do conjunto de dados. Sendo assim, quanto maior o número de boas práticas forem utilizadas, maiores serão os benefícios alcançados. Considerando que a publicação de dados na Web é um processo incremental, os níveis de benefícios poderão aumentar após algumas iterações do processo de publicação de dados (LÓSCIO; BURLE; CALEGARI, 2016b). 3.3 Soluções de Catalogação de dados X Boas Práticas Conforme apontado anteriormente, Oliveira et al. (2016) cita problemas no gerenciamento dos portais de dados abertos brasileiros, como ausência de controle de versão, dificuldade em determinar a frequência de atualização, indisponibilidade de metadados adequados, publicações em formatos de dados proprietários e falta de mecanismos para coleta de feedback. Brito et al. (2015), acrescenta também que a falta de padronização dos dados dificulta sua utilização. Lóscio, Oliveira e Bittencourt (2015) acrescenta que a tarefa de gerir a publicação dos dados, coletando e publicando, não é simples e nem barata. Também aponta que durante o processo, é necessário conhecimento tanto de Informática no que tange as operações de armazenamento e publicação, quanto conhecimentos mais específicos em relação à natureza dos dados. Nesse sentido, realizamos uma análise de como os softwares que provêm os catálogos de dados estão adequados as Boas Práticas para Dados na Web. Ou seja, ao invés de considerar os conjuntos de dados ou portais de dados específicos como evidências, usamos os principais softwares de catalogação para verificar se eles implementam as boas práticas. Sendo assim, consideramos em nossa análise os softwares CKAN, Socrata, DKAN, Junar, ArcGIS Open Data e OpenDataSoft. Vale salientar que nossa avaliação se deu a partir da análise da documentação

50 3.3. SOLUÇÕES DE CATALOGAÇÃO DE DADOS X BOAS PRÁTICAS 49 dos softwares e da utilização das ferramentas por meio do modo demo. Porém, para o Junar que não dispõe de ferramenta online para testes, verificou-se que os portais de dados, que se utilizam dele para gerar o catálogo, apresentam as mesmas funções e tipos de acesso sem muitas personalizações. Assim, considerou-se o acesso aos portais como evidência complementar a sua documentação que apresenta as telas e processos de publicação de dados. Para algumas boas práticas não foi possível realizar a avaliação, pois elas não dizem respeito aos softwares. Portanto, não foi possível realizar a avaliação da BP10, BP16, BP22 e da BP28 pois elas estão diretamente relacionadas aos dados em si e não as soluções. Outrossim, as BP33, B34, BP35 se aplicam a situações de republicação de dados e dependem do consumidor. Enquanto que a BP31 diz respeito ao processo de enriquecimento dos dados, que não faz parte das funções básicas do catálogo de dados. Em suma, o resultado da análise é apresentado no Quadro 3.3. Por meio da avaliação realizada, percebemos que, de certo modo, algumas orientações de boas práticas são atendidas por todas as soluções, como prover metadados, prover informações de licença e prover os dados em diferentes formatos. É importante frisar que os formatos de dados dependem do formato que o produtor deseja publicar, mas para análise foi considerado se a ferramenta não apresentava limitações quanto aos principais formatos usados nesse contexto. Exceto pelo CKAN e DKAN, as outras ferramentas permitem o download dos dados em diferentes formatos do que foi publicado, ou seja, fazem uso da negociação de conteúdo para disponibilizar os dados em formatos distintos. O desafio de Vocabulários também foi evidenciado como um dos mais importantes nas soluções de catálogos de dados, constatou-se que foram reutilizados vocabulários existentes, como o DCAT, para publicar os metadados dos conjuntos de dados. O uso de APIs para acesso a dados é um consenso entre as soluções. Também é por meio das APIs que as soluções permitem a obtenção de subconjuntos de dados. No entanto, nenhuma das soluções apresenta alternativa para tratar dados em tempo real. Todavia, vale salientar que o ArcGIS Open Data é o único que apresenta referência quanto a essa boa prática, indicando que quando ele é integrado ao ArcGIS for Server, pode realizar a publicação de dados geográficos em tempo real para consumo. Por fim, todos eles usam URIs persistentes como identificadores para os conjuntos de dados e apresentam visualizações complementares de forma automática, permitindo gerar gráficos, tabelas interativas e sínteses estatísticas.

51 3.3. SOLUÇÕES DE CATALOGAÇÃO DE DADOS X BOAS PRÁTICAS 50 Quadro 3.3: Catálogos de Dados X Boas Práticas BP Catálogos de dados BP1 CKAN, SOCRATA, DKAN, Junar, ARCGIS, OPENDATASOFT BP2 CKAN, SOCRATA, DKAN, Junar, ARCGIS, OPENDATASOFT BP3 CKAN (parcial), SOCRATA, Junar (parcial), ARCGIS BP4 CKAN, SOCRATA, DKAN, ARCGIS (parcial), OPENDATASOFT (parcial) BP5 CKAN, SOCRATA, DKAN, ARCGIS (parcial), OPENDATASOFT (parcial) BP6 SOCRATA BP7 CKAN, DKAN BP8 SOCRATA (parcial), DKAN BP9 CKAN, SOCRATA, DKAN, Junar, ARCGIS, OPENDATASOFT BP10 - BP11 SOCRATA BP12 CKAN, SOCRATA, DKAN, Junar, ARCGIS, OPENDATASOFT BP13 OPENDATASOFT (parcial) BP14 SOCRATA, Junar, ARCGIS, OPENDATASOFT BP15 CKAN, SOCRATA, DKAN, Junar, OPENDATASOFT BP16 - BP17 CKAN, SOCRATA, DKAN, Junar, ARCGIS, OPENDATASOFT BP18 CKAN, SOCRATA, DKAN, Junar, ARCGIS BP19 SOCRATA, Junar, ARCGIS, OPENDATASOFT BP20 ARCGIS BP21 SOCRATA (parcial), Junar BP22 - BP23 CKAN (parcial), SOCRATA, DKAN (parcial), Junar, ARCGIS, OPENDATASOFT BP24 CKAN, SOCRATA, DKAN, Junar, ARCGIS, OPENDATASOFT BP25 CKAN, SOCRATA, DKAN, Junar, ARCGIS, OPENDATASOFT BP26 CKAN, SOCRATA, DKAN, Junar, ARCGIS, OPENDATASOFT BP27 Nenhum dos softwares. BP28 - BP29 CKAN, SOCRATA, DKAN BP30 CKAN, SOCRATA, OPENDATASOFT BP31 - BP32 CKAN, SOCRATA, DKAN, Junar, ARCGIS, OPENDATASOFT BP33 OPENDATASOFT BP34 - BP35 - Fonte: o autor Observamos também que nenhuma das soluções implementam a BP27. Quando um conjunto de dados não está mais disponível nas soluções, é retornado apenas uma mensagem de erro 404 (NOT FOUND). Logo, os identificadores não são mantidos e preservados nas soluções. De forma geral, as soluções disponibilizam opções muito simples para receber feedback dos

52 3.3. SOLUÇÕES DE CATALOGAÇÃO DE DADOS X BOAS PRÁTICAS 51 consumidores, como por formulários de contato, sem deixá-lo de forma pública para que outros analisem. Todas as soluções analisadas são compatíveis com o DCAT, indicando que seus metadados são cobertos por ele. Todavia, algumas soluções oferecem apenas uma cobertura parcial e disponibilizam os metadados igualmente em formatos legíveis por humanos e por máquinas. Dessa forma, o CKAN e o Junar implementam a BP3 parcialmente pois não disponibilizam uma versão legível por humanos para os metadados estruturais, ou seja, não disponibilizam metadados que descrevam o esquema e a estrutura interna dos conjuntos de dados. Assim como o ARCGIS e o OpenDataSoft implementam as BP4 e BP5 de forma parcial por não oferecer uma maneira para representar os metadados de licença e proveniência legíveis por máquina. Do mesmo modo, a BP8 é implementado parcialmente pelo Socrata por não possibilitar acesso por máquina à lista das versões dos conjuntos de dados. Por fim, o OpenDataSoft implementa a BP13 parcialmente pois não oferece uma maneira de representar os metadados de localidade ou idioma para acesso legível por máquina. Outras características só foram encontradas no Socrata, tais como informação de qualidade dos dados e a atribuição de URIs para as versões dos conjuntos de dados. No entanto, o Socrata não disponibiliza o indicativo das versões e, apesar de não listar as versões, o CKAN e o DKAN dispõem de opção para informar a versão. Quanto ao fornecimento de dados atualizados, ou seja, quando é informado uma periodicidade de atualização e é seguido de forma automática, apesar do Socrata informar a periodicidade nos metadados, a atualização só é garantida através de uma aplicação adicional (DataSync 18 ). Ainda sim, é necessário utilizar conectores que gerem o arquivo que poderá ser publicado por DataSync. Contrapondo-se, o Junar permite que a frequência de atualização seja seguida quando os dados são consumidos através de uma API. Apesar de não apresentar a informação de quando os dados serão atualizados para os consumidores, através dos metadados, ele mostra a data da última consulta que foi realizada a fonte de dados. Portanto, a fim de se buscar que a publicação e o consumo de dados na Web atinja todo o seu potencial, é necessário resolver questões em aberto conforme apontado nos resultados da nossa análise. Em outras palavras, os desafios voltados à qualidade dos dados, versionamento, preservação, enriquecimento e republicação dos dados são desafios poucos explorados pelos principais softwares de catálogos de dados. Dessa forma, ficou evidente que existe a necessidade de uma solução que atenda aos requisitos necessários para um software inserido nesse cenário. Nesse sentido, espera-se que a solução proposta neste trabalho possa contribuir de forma significativa nesse cenário, pois uma solução desta natureza pode ajudar na comunicação entre os principais atores do ecossistema de dados na Web, assim como pode suprir tais necessidades aparentes no contexto de publicação e gerenciamento de dados, que não são atendidas pelas soluções atuais. 18

53 52 4 Compartilhamento de Dados na Web Neste capítulo, serão descritos os principais requisitos identificados para as soluções de soluções de compartilhamento de Dados na Web. De modo geral, buscamos entender os principais desafios para publicação e consumo dos dados na Web e, a partir do estudo desses desafios, foram elencadas premissas para o compartilhamento de dados na Web. Tais premissas guiaram a definição dos requisitos que uma solução de compartilhamento de Dados na Web deve ter para prover um gerenciamento adequado dos conjuntos de dados. Dessa forma, a Seção 5.1 apresenta conceitos básicos fundamentais para o entendimento deste capítulo. Na Seção 5.2 elencamos as premissas do compartilhamento de Dados na Web, que foram usadas para definir os requisitos para as soluções de compartilhamento de Dados na Web apresentadas na Seção 5.3. Por fim, na Seção 5.4 é realizado uma discussão do Capítulo por meio da análise das soluções existentes de acordo com os requisitos identificados. 4.1 Conceitos básicos A seguir, apresentamos alguns conceitos básicos relacionados a conjuntos de dados. Semelhante à definição de bancos de dados(elmasri; NAVATHE, 2010), um conjunto de dados (dataset) é uma coleção de dados. Dados são fatos conhecidos que podem ser registrados e possuem significado implícito. Preferencialmente, os dados de um conjunto de dados devem estar relacionados e devem ter um público interessado em seu conteúdo. Um conjunto de dados pode estar associado a uma ou mais distribuições. Uma distribuição pode ser vista como uma instância do conjunto de dados em um formato de dados específico, ou seja, os dados do conjunto de dados em um determinado momento representados em um formato de dados específico. Além dos dados, cada distribuição contém uma descrição da estrutura de seus dados, definida de acordo com o formato de dados da distribuição. Um conjunto de dados também possui uma descrição, ou seja, o conjunto de informações (metadados) que são necessárias para a sua compreensão. Considerando a abrangência do compartilhamento de dados na Web, além de informações sobre os tipos de dados, torna-se fundamental compartilhar informações sobre licença, versionamento, proveniência, qualidade e

54 4.1. CONCEITOS BÁSICOS 53 uso dos conjuntos de dados. Uma ou mais versões podem estar associadas a um conjunto de dados. Cada versão é um novo conjunto de dados e deve ser devidamente identificada, bem como o histórico de mudanças entre versões deverá ser armazenado. Apesar de não existir um consenso de quando uma nova versão deve ser gerada, neste trabalho assumimos que uma versão será gerada para refletir mudanças na descrição do conjunto de dados e para cada atualização de dados realizada, seja inserindo novos dados, alterando os existentes, removendo dados ou alterando a estrutura do conjunto de dados. Um conjunto de dados pode sofrer atualizações em seus dados de acordo com uma frequência de atualização pré-definida ou pode ser atualizado para refletir mudanças que acontecem no mundo real. É necessário manter a data da última atualização do conjunto de dados devidamente atualizada de acordo com as mudanças efetuadas nos dados. Em nosso contexto de compartilhamento de dados na Web, admitimos três fases para um conjunto de dados conforme apresentado na Figura 4.1. Figura 4.1: Fases de um Conjunto de Dados. Fonte: o autor O conjunto de dados pode ser Criado, que compreende o momento em que o produtor define quais dados deseja publicar, cadastra informações por meio dos metadados e inicia o processo de extração dos dados. Quando o conjunto de dados é compartilhado na Web, o conjunto de dados passa para o estado Publicado. Em determinados casos, dado a conflitos de interesse distintos, um conjunto de dados só pode ser publicado após a validação de um outro responsável que integra a equipe do produtor. Dessa forma, uma vez criado, o conjunto de dados deve ser validado e publicado na Web. Uma vez publicado na Web, o conjunto de dados deve estar disponível para acesso ao longo do tempo. No entanto, um produtor pode sinalizar a descontinuação dele e, nesse caso, o conjunto de dados passa para o estado Preservado. Nesse estado, será possível obter acesso aos dados ou informações de como acessá-los uma vez que será possível acessar a URI original que estará preservada. Um conjunto de dados preservado pode voltar a ser disponibilizado ao público e, assim, voltar ao estado publicado.

55 4.2. PREMISSAS DO COMPARTILHAMENTO DE DADOS NA WEB Premissas do compartilhamento de Dados na Web Desde o seu surgimento, a Web tem se destacado como um importante meio para a troca e compartilhamento de informações. A Web possibilita o compartilhamento de dados, i.e. o acesso e a leitura de dados, de maneira bastante simples, sem a exigência de sistemas para controlar o acesso concorrente aos dados, por exemplo. Por outro lado, a facilidade de compartilhamento em grande escala requer soluções flexíveis que possibilitem o consumo de dados por grupos de usuários previamente desconhecidos (LÓSCIO; BURLE; CALEGARI, 2016a). Isso implica que os dados devem ser compartilhados de maneira a atender aos requisitos de um conjunto amplo e heterogêneos de usuários, os quais podem ter diferentes necessidades, requisitos e expectativas. Além disso, os conjuntos de dados que são oferecidos na Web podem ter origem em outros sistemas já existentes. Isso traz consequências importantes como a necessidade de manter os dados sempre atualizados com relação aos dados de origem e a necessidade de realizar transformações nos dados antes da sua publicação na Web. Outro fator importante que deve ser considerado diz respeito à evolução dos conjuntos de dados ao longo do tempo, os quais podem sofrer atualizações tanto na sua descrição quanto nos seus dados. Em muitos casos, observamos que, após a publicação inicial na Web, os conjuntos de dados permanecem inalterados e não refletem as mudanças ocorridas no mundo real. Entretanto, é importante que os conjuntos de dados continuem "vivos". Finalmente, como estamos falando de compartilhamento de dados na Web, é importante levar em consideração os princípios arquiteturais da Web (JACOBS; WALSH, 2004). De acordo com Jacobs e Walsh (2004), todos os recursos na Web devem ter identificadores únicos e podem ter várias representações, como quando os mesmos dados são disponibilizados como JSON, XML, RDF, CSV e HTML. É muito comum, que a disponibilização de arquivos para download seja considerada como um caso de dados na Web. Porém, para termos dados na Web é importante que os conjuntos de dados e, preferencialmente, os itens de dados sejam identificados por meio de URIs. A fim de obter um melhor entendimento sobre os requisitos para as soluções de compartilhamento de dados na Web, fizemos um estudo detalhado dos trabalhos gerados pelo DWBP Working Group do W3C. Especificamente, os documentos de Uses Cases 1 e de Boas Práticas 2 auxiliam o entendimento desse novo cenário de compartilhamento de dados, uma vez que elencam e discutem os principais desafios a serem enfrentados na publicação e no consumo de dados na Web. A partir desse estudo, elencamos quatro premissas para o compartilhamento de Dados na Web. A definição dessas premissas foi fundamental para termos um claro entendimento dos requisitos para o adequado compartilhamento de dados na Web. Premissa 1: Não existe um conhecimento prévio entre os responsáveis pela disponibilização dos dados e os interessados em fazer uso dos dados; Premissa 2: Os conjunto de dados podem ter origem em fontes de dados já existentes;

56 4.3. REQUISITOS PARA AS SOLUÇÕES DE COMPARTILHAMENTO DE DADOS NA WEB 55 Premissa 3: Os conjuntos de dados não são estáticos, ou seja, podem sofrer atualizações na descrição ou nos dados ao longo tempo; Premissa 4: Os princípios arquiteturais da Web devem ser seguidos. 4.3 Requisitos para as soluções de compartilhamento de Dados na Web Considerando as premissas elencadas na seção anterior e as Boas Práticas para Dados na Web (LÓSCIO; BURLE; CALEGARI, 2016a), temos que as várias soluções que lidam com o compartilhamento de dados na Web deveriam ser capazes de atender aos seguintes requisitos: Requisitos da Premissa 1: R1. Prover mecanismos para a criação de conjuntos de dados auto-descritivos; R2. Possibilitar a criação de múltiplas distribuições para um mesmo conjunto de dados, ou seja, a disponibilização dos dados em diferentes formatos; R3. Prover múltiplos meios de acesso aos conjuntos de dados, que podem ser desde o download de arquivos até o acesso por meio de APIs; R4. Prover mecanismos para a criação de canais de comunicação entre os atores do ecossistema de dados na Web; Requisitos da Premissa 2: R5. Garantir o acesso a dados atualizados de acordo com a fonte de origem; R6. Prover mecanismos para a extração e transformação dos dados de origem em dados na Web; Requisitos da Premissa 3: R7. Prover mecanismos para o gerenciamento de versões de conjuntos de dados; R8. Prover mecanismos para o gerenciamento de metadados (curadoria de metadados); R9. Garantir a preservação dos conjuntos de dados ao longo do tempo; Requisitos da Premissa 4: R10. Garantir o uso de identificação única, por meio de URIs, para os conjuntos de dados, distribuições, versões e, preferencialmente, para os itens de cada conjunto de dados; A seguir, cada requisito é descrito.

57 4.3. REQUISITOS PARA AS SOLUÇÕES DE COMPARTILHAMENTO DE DADOS NA WEB Requisitos da Premissa 1 R1. Prover mecanismos para a criação de conjuntos de dados auto-descritivos Em um ambiente onde produtores e consumidores não são previamente conhecidos, os metadados são fundamentais para permitir que o significado e estrutura dos dados sejam compreendidos, por exemplo. A fase de Criação de um conjunto de dados, no ciclo de vida dos dados na Web, compreende a extração dos dados das fontes até a sua transformação para o formato adequado para publicação na Web, juntamente com a definição de metadados que facilitem entendimento dos dados. Nesse sentido, torna-se necessário fornecer mecanismos que permitam a criação de conjuntos de dados associados à descrição necessária para a sua compreensão por terceiros. Os metadados também são fundamentais para auxiliar a descoberta e a reutilização de dados. Dessa forma, quanto mais completo o conjunto de metadados melhor para uma adequada descrição dos conjuntos de dados e suas distribuições. Preferencialmente, metadados devem ser padronizados a partir do reúso de vocabulários existentes (ex: DCAT 3 e DCMI 4 ). Além disso, devem ser fornecidos de modo que possibilitem tanto a compreensão por usuários quanto o seu processamento automático por aplicações. R2. Possibilitar a criação de múltiplas distribuições para um mesmo conjunto de dados, ou seja, a disponibilização dos dados em diferentes formatos Segundo Lóscio, Burle e Calegari (2016a), o formato em que os dados são disponibilizados é fundamental para facilitar sua reutilização. Um conjunto de dados pode ser considerado "inútil"se não estiver disponível em um formato de dados que possa ser facilmente processado por máquina, por exemplo. É importante destacar que existe uma grande variedade de formatos de dados disponível para publicação e troca de dados, no entanto nem todo formato provê a estrutura adequada que facilite o uso e o reúso. Por exemplo, um documento de texto puro pode ser facilmente lido por máquinas, mas pode apresentar problemas no uso por diferentes sistemas operacionais, uma vez que cada sistema operacional têm seu próprio método de informar ao computador que se chegou ao fim do texto, como o MS Windows e variantes do Unix. Outrossim, uma tabela em PDF pode ser bem compreendida por humanos, mas é interpretada apenas como uma imagem para máquinas. É necessário promover a criação de distribuições considerando formatos que possam ser utilizados por um público amplo. Seja por meio de uma API ou uma interface Web, com o download em massa, é necessário disponibilizar os conjuntos de dados em diferentes distribuições

58 4.3. REQUISITOS PARA AS SOLUÇÕES DE COMPARTILHAMENTO DE DADOS NA WEB 57 para alcançar um maior número possível de consumidores. Fornecendo os dados em mais de um formato, os custos de transformação de dados serão reduzidos, contribuindo para um aumento no número de aplicativos capazes de processar os dados. Portanto, é necessário possibilitar a criação de múltiplas distribuições para um conjunto de dados de forma que obstáculos tecnológicos não sejam criados para seu uso ou processamento. R3. Prover múltiplos meios de acesso aos conjuntos de dados, que podem ser desde o download de arquivos até o acesso por meio de APIs O compartilhamento de dados na Web permite que seres humanos e máquinas usufruam dos benefícios da infraestrutura da Web, que permite um fácil acesso aos dados por meio dos métodos HTTP. Assim, é importante possibilitar tanto o download em massa dos dados, bem como fornecer métodos mais sofisticados, como o acesso por meio de uma API (LÓSCIO; BURLE; CALEGARI, 2016a). Em outras palavras, é fundamental que sejam oferecidos diferentes mecanismos de acesso a fim de atender aos requisitos dos diferentes grupos de consumidores interessados no conjunto de dados. As APIs são adequadas para todos os tipos de dados na Web. Quando desenvolvidas de forma pontual pelos produtores, tem o ônus do tempo de desenvolvimento e trabalho gasto, contrapondo-se a facilidade de publicar arquivos para download. No entanto, é importante a disponibilização de APIs para permitir a consulta e recuperação dos dados de forma automática por aplicações, por exemplo. Ainda que um produtor crie um conjunto de dados a partir do upload de um arquivo, as soluções devem permitir que esses dados também sejam acessados por meio de uma API. Vale salientar que uma boa documentação da API e uma manutenção que vise sua preservação complementa este requisito. A preservação da API visa evitar a sua quebra ao longo do tempo, considerando que alterações podem ser necessárias. Assim, novas versões devem ser geradas ao invés de realizar manutenções que venham alterar as chamadas ou estrutura, uma vez que possivelmente ela já estará sendo consumida por vários usuários. Para o download em massa dos dados, deve ser possível efetuar o download de todos os dados em um único arquivo, i.e. os dados serão pré-processados e será gerado um único arquivo para download. Por exemplo, deve ser possível recuperar todos os subconjuntos criados em único arquivo, que nesse caso representa o conjunto de dados completo. R4. Prover mecanismos para a criação de canais de comunicação entre os atores do ecossistema de dados na Web Rastrear o uso dos conjuntos de dados e as aplicações que fazem uso desses dados ainda é um grande desafio. As informações sobre o uso dos dados podem tanto ajudar na seleção dos dados a serem publicados quanto contribuir para a melhoria da qualidade dos dados já publicados. Assim, é um requisito prover mecanismos para realizar o acompanhamento do uso dos dados,

59 4.3. REQUISITOS PARA AS SOLUÇÕES DE COMPARTILHAMENTO DE DADOS NA WEB 58 como o rastreamento de aplicações que usam os dados e recebimento de feedback. Dessa forma, uma solução de compartilhamento de dados na Web deve fornecer mecanismos para obter informações sobre as aplicações que usam os conjuntos de dados, como por exemplo, os dados que são utilizados e o problema que ajuda a resolver. Essas informações podem ajudar na busca por aplicações que satisfaçam às necessidades de consumidores e produtores, além de ajudar na discussão de novas ideias. Uma outra alternativa é suportar o cadastro de consumidores, uma vez que os produtores podem desejar saber quem baixou os dados e como eles o usaram. Os próprios consumidores também podem ter interesse no cadastro para recebimento de alertas ou alterações nos dados. Assim, deve ser fornecido uma opção para coletar interesses e dados de contato dos consumidores. Geralmente, só são disponibilizados opções para cadastro de comentários ou envio de formulários de contato como meio para os consumidores enviem feedback. No entanto, é comum que um feedback vindo de um retorno não estruturado esteja incompleto. Nesse sentido, tornase importante obter feedback dos consumidores de forma estruturada que permita identificar possíveis falhas nos dados publicados, a necessidade de publicação de novos dados e possibilitar classificação dos dados, por exemplo. Dessa forma, deve-se manter canais de comunicação entre os produtores e consumidores para coletar o feedback e, adicionalmente, disponibilizar o feedback coletado para todos, para permitir a troca de experiências, preocupações e dúvidas da comunidade Requisitos da Premissa 2 R5. Garantir o acesso a dados atualizados de acordo com a fonte de origem Os conjuntos de dados podem ter origem em fontes de dados existentes e, por isso, é importante garantir que os dados que são publicados na Web estejam sincronizados com a fonte de origem. Assim, à medida que ocorrerem atualizações nas fontes de origem, os dados publicados na Web também devem ser atualizados. Para que o consumidor tenha ciência de quando os dados são atualizados, é importante informar a frequência de atualização por meio dos dados e que seja definida de acordo com a frequência de atualização da fonte de origem. No entanto, atualmente, os conjuntos de dados são publicados e algumas vezes é informado uma frequência de atualização por meio dos metadados, sem garantia que os dados estão sendo atualizados conforme informado na frequência. Comumentemente, o próprio produtor é responsável por essa atualização, sendo necessário um grande esforço dele para seguir a frequência informada. O cenário se torna mais crítico uma vez que muitos conjuntos de dados apresentam determinadas frequências de atualização nas fontes que não são refletidas nos conjuntos de dados na Web. Dessa forma, é fundamental garantir que os conjuntos de dados serão atualizados de

60 4.3. REQUISITOS PARA AS SOLUÇÕES DE COMPARTILHAMENTO DE DADOS NA WEB 59 acordo com sua a frequência pré-definida e que esse processo seja apoiado por ferramentas que permitam a atualização dos dados de forma automática. De modo geral, a garantia de atualização se dá ao passo que a fonte de dados de origem pode ser acessada para extrair os dados necessários de forma automática. Após a extração, os dados são atualizados e uma nova versão do conjunto de dados é gerada. Esse processo deve ser repetido de acordo com a frequência de atualização definida para cada conjunto de dados. R6. Prover mecanismos para a extração e transformação dos dados de origem em dados na Web Para possibilitar a publicação dos conjuntos de dados e garantir que estarão atualizados conforme sua fonte de dados de origem, mecanismos que permitam realizar a extração e transformação dos dados tornam-se necessários. De modo geral, deve ser possível extrair os dados automaticamente a partir de diferentes fontes de dados e, posteriormente, realizar a transformação dos dados de origem para publicá-los na Web. Para tanto, devem ser oferecidas soluções que permitam a extração de dados a partir de diferentes tipos de fontes de origem, como bancos de dados convencionais ou até mesmo arquivos. Além da extração dos dados, também são necessários mecanismos para realizar tarefas de transformação e limpeza nos dados, a fim de melhorar a qualidade dos dados antes da sua publicação na Web. É importante ressaltar que, em alguns casos, os dados foram criados previamente sem uma intenção de compartilhamento, logo podem apresentar problemas como ausência de valores ou valores inconsistentes. Nesse processo, o enriquecimento de dados pode ser utilizado para melhorar, aperfeiçoar ou aprimorar os dados que são extraídos. Assim, é necessário prover mecanismos que permitam enriquecer os conjuntos de dados preenchendo valores ausentes ou gerando novos dados por técnicas de inferência, por exemplo. Também é importante prover alternativas para problemas estruturais, como a ausência de metadados estruturais. Por exemplo, apesar do CSV ser um dos formatos mais utilizados, ele permite a descrição opcional do nome dos campos de dados em um cabeçalho. Assim, a descrição dos campos e tipos de dados usados têm que ser disponibilizados em um arquivo separado. No entanto, como é opcional, nem sempre é disponibilizado e torna o entendimento dos dados mais difícil, além de dificultar a verificação de consistência da estrutura. Nesse sentido, os mecanismos de extração também devem suportar a extração de informações estruturais para apoiar o produtor nessa atividade e garantir uma melhor descrição dos dados Requisitos da Premissa 3 R7. Prover mecanismos para o gerenciamento de versões de conjuntos de dados

61 4.3. REQUISITOS PARA AS SOLUÇÕES DE COMPARTILHAMENTO DE DADOS NA WEB 60 Como se sabe, os conjuntos de dados podem ser alterados ao longo do tempo, seja para realizar uma melhoria, uma correção ou até mesmo a inserção de novos dados. Dessa forma, é importante manter versões dos conjuntos de dados e possibilitar o acesso a elas. No entanto, são poucos os meios disponibilizados pelas ferramentas atuais para garantir um gerenciamento de versões adequado. A partir do gerenciamento de versões, situações comuns, como quando os dados sofrem atualizações, não deve acarretar na exclusão das distribuições dos conjuntos de dados da Web para publicação de novas distribuições. Pois, esse procedimento desconsidera a possível utilização atual dos dados já publicados. Nesses casos, uma nova versão do conjunto de dados deveria ser gerada, permitindo o acesso tanto a versão anterior quanto a nova versão, tornando o conjunto de dados confiável Também deve ser possível o controle de versões até mesmo para os conjuntos de dados que possibilitam o acesso em tempo real aos dados, o que pode ser controlado por meio da data e hora. É importante deixar claro a abordagem que é utilizada no controle das versões, informando quando uma nova versão é gerada. Portanto, este requisito considera que uma solução de compartilhamento de dados na Web deve ser capaz de fornecer serviços para o gerenciamento automático de versões, provendo acesso correto a todas as versões geradas e permitindo acesso aos dados mais recentes. R8. Prover mecanismos para o gerenciamento de metadados (curadoria de metadados) Como mencionado anteriormente, os metadados desempenham um papel fundamental para o compartilhamento de dados na Web, dado que ela é um espaço de informação aberta, caracterizada pela ausência de um contexto específico. Assim, a partir dos é possível entender melhor o significado dos dados e sua estrutura, além de outras questões, como a licença e a qualidade dos dados. Somado a isso, também são fundamentais para a descoberta e reutilização dos conjuntos de dados. As soluções de compartilhamento de dados na Web devem ser apoiadas por um processo de curadoria de metadados que estabeleça os elementos de metadados essenciais neste contexto. Também devem definir meios para automatizar as tarefas de curadoria, garantindo a disponibilidade e qualidade dos metadados (, 2016). É fundamental que todos os metadados sejam acessíveis por humanos e por máquinas, e.g. possibilitando a recuperação das informações via Interface Web e via Interface Remota. A curadoria de metadados deve garantir que todas as informações sobre os conjuntos de dados, distribuições, aplicações, produtores e consumidores estão disponíveis. Segundo (2016), os metadados precisam ser mantidos e preservados, bem como estar altamente disponíveis ao longo do tempo, para que possam ser adequadamente utilizados. Além disso, acrescenta que é necessário uma gestão eficiente e a preservação para que eles possam ser descobertos e reutilizados. Sem a gestão dessas informações, os conjuntos de dados são esquecidos ou só são

62 4.3. REQUISITOS PARA AS SOLUÇÕES DE COMPARTILHAMENTO DE DADOS NA WEB 61 utilizados uma única vez. Nesse sentido, a curadoria de metadados pode ser entendida como um processo contínuo que gerencia os metadados e sua utilização, tanto melhorando quanto enriquecendo eles. R9. Garantir a preservação dos conjuntos de dados ao longo do tempo A priori, uma vez os dados publicados na Web, devem estar disponíveis. No entanto, é possível que os dados não estejam mais disponíveis em um futuro indefinido e, para esses casos, é necessário manter informações sobre seu armazenamento ou como encontrá-los novamente. Nesse sentido, é necessário fornecer mecanismos que sejam capazes de manter todos os conjuntos de dados acessíveis para preservar o seu acesso e apresentar informações sobre o seu possível arquivamento. Em geral, quando um conjunto de dados não está mais acessível, todos que estão consumindo os dados, ao solicitar um novo acesso, serão redirecionados para o erro HTTP 404. Este erro é um código de resposta HTTP que indica que houve a comunicação com o servidor, mas ele não encontrou o que foi pedido. Assim, o consumidor de dados não saberá se a indisponibilidade é temporária, permanente, planejada ou acidental. Isso não quer dizer, no entanto, que um conjunto de dados não possa ser removido da Web ou ser arquivado. Porém, é necessário preservar o acesso a cada conjunto de dados, mantendo cada URI acessível, para que seja possível identificar o que aconteceu com os dados. Para o acesso aos conjuntos de dados arquivados, é importante apresentar informações sobre o arquivamento e possibilitar o acesso ao arquivo que contém os dados ou como um usuário pode solicitar o acesso. Portanto, a garantia de preservação dos conjuntos de dados é um requisito das soluções de compartilhamento de dados na Web, que deverão manter o acesso a URI original dos conjuntos de dados Requisitos da Premissa 4 R10. Garantir o uso de identificação única, por meio de URIs, para os conjuntos de dados, distribuições, versões e, preferencialmente, para os itens de cada conjunto de dados Os identificadores são amplamente utilizados nos sistemas de informação, como o URIs, que é a base para comunicação de dados na Web. É necessário que as soluções de gerenciamento de dados na Web garantam o uso de URIs persistentes como identificadores de conjuntos de dados, distribuições, versões e para cada item que compõe um conjunto de dados. De modo geral, também é importante que URIs persistentes sejam utilizadas como identificadores dentro dos conjuntos de dados, i.e. que dados possam ter links para outras URIs de forma que outros recursos possam ser descobertos, tornando os dados mais valiosos, como, por exemplo, um recurso RDF. Além disso, tendo em vista que é provável que os produtores

63 4.4. ANÁLISE DAS SOLUÇÕES EXISTENTES DE ACORDO COM OS REQUISITOS 62 podem remover os dados da Web, é importante preservar seus identificadores. Espera-se que seja possível "dereferenciar"a URI de um conjunto de dados mesmo ele não estando disponível e fornecer informações sobre o seu arquivamento, por exemplo. 4.4 Análise das soluções existentes de acordo com os requisitos No Capítulo 3 fizemos uma análise das soluções de catalogação de dados frente às recomendações de boas práticas. Nesta seção, fazemos novamente uma breve análise das soluções, porém, considerando os requisitos elencados neste Capítulo, o que complementa a análise anteriormente realizada. Por exemplo, enquanto na análise anterior verificamos se constavam metadados sobre o versionamento, nesta análise consideramos se a solução provê mecanismos para o gerenciamento das versões. O resultado da análise é apresentado no Quadro 4.1. Quadro 4.1: Soluções Atuais X Requisitos CKAN DKAN SOCRATA JUNAR ArcGIS Open Data OPENDATASOFT R1 Parcial Parcial Atende Parcial Parcial Parcial R2 Não Atende Não Atende Atende Não Atende Atende Atende R3 Parcial Parcial Atende Atende Parcial Parcial R4 Parcial Não Atende Atende Parcial Parcial Parcial R5 Não Atende Não Atende Atende Não Atende Parcial Parcial R6 Não Atende Não Atende Parcial Parcial Não Atende Parcial R7 Parcial Parcial Não Atende Não Atende Não Atende Não Atende R8 Parcial Parcial Parcial Parcial Parcial Parcial R9 Não Atende Não Atende Não Atende Não Atende Não Atende Não Atende R10 Atende Atende Atende Atende Atende Atende Fonte: o autor De forma geral, verificamos que as soluções existentes tem um foco maior na publicação dos dados, i.e. no processo de disponibilização dos conjuntos de dados para uso na Web, compreendendo também os metadados, por meio de um catálogo. Quanto ao R1, verificamos que as soluções analisadas utilizam apenas um subconjunto do DCAT para descrever os conjuntos de dados. Ainda sim, o CKAN, DKAN e o Junar não permitem o cadastro de metadados estruturais. O ArcGIS Open Data, OpenDataSoft e o Socrata, oferecem mecanismos para coletar os metadados estruturais, identificando automaticamente os tipos de dados e permitindo que o produtor realize alterações ou acrescentem informações como a descrição dos dados. Consideramos que o Socrata atende ao R1 dado que ele é o que apresenta o maior número de metadados descritos no guia de boas práticas. Quanto ao R2, o CKAN e DKAN não possibilitam a criação de múltiplas distribuições

64 4.4. ANÁLISE DAS SOLUÇÕES EXISTENTES DE ACORDO COM OS REQUISITOS 63 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

65 4.4. ANÁLISE DAS SOLUÇÕES EXISTENTES DE ACORDO COM OS REQUISITOS 64 agendada for criada dentro da plataforma, para que a ferramenta possa executar a extração e atualização dos dados. O Socrata garante o acesso a dados atualizados quando são acessados por serviços online ou por meio do uso da ferramenta DataSync. Essa ferramenta permite selecionar arquivos que deverão ser atualizados online, sendo necessário executar processos adicionais para extração dos dados e para criar tarefas agendadas no sistema operacional para processar a sincronização dos dados. Assim, para acesso a bancos de dados relacionais, por exemplo, é necessário usar ferramentas como o Pentaho Kettle 5 e o FME Server 6 para realizar as atividades de extração dos dados e, posteriormente, salvar o arquivo no sistema operacional para o DataSync enviar os dados para a plataforma online. 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 subconjunto 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 versionamento, 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 indicativo 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

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

67 66 5 Sistemas Gerenciadores de Dados na Web - SGDW No Capítulo anterior foram discutidas as premissas e os requisitos para o compartilhamento 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

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

69 5.1. VISÃO GERAL DE UM SGDW 68 Já a Interface Remota (API) deve permitir a recuperação dos dados e metadados por meio de protocolos de comunicação remota. Essa interface deve ser projetada para ser simples e concisa, permitindo a recuperação dos dados e metadados armazenados. Dessa forma, ao invés de limitar a recuperação de informação apenas por páginas HTML, a interface remota permite o desenvolvimento de aplicações que se apropriem dos dados para agregação de valor e de utilidade para as informações, apesar de requerer conhecimentos técnicos de programação. Ela também deve possibilitar que os desenvolvedores consultem os conjuntos de dados disponíveis no sistema 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 feedback e 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 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.

70 5.2. DETALHAMENTO DA CAMADA DE SERVIÇOS 69 O armazenamento interno deve oferecer um Repositório de Metadados e um Repositório de Conjuntos de Dados. O primeiro armazenará todos os metadados associados aos conjuntos de dados, aplicações, produtores e consumidores, enquanto que o segundo repositório pode ser vista como uma base de dados intermediária para o armazenamento dos dados dos conjuntos de dados. Assim, com a utilização de bases separadas, o processo de busca de dados pelos consumidores não é afetado pelos processos internos de atualização e inserção de novos dados. 5.2 Detalhamento da Camada de Serviços Esta seção descreve em detalhes os serviços presentes na Camada de Serviços da arquitetura apresentada na seção anterior. Os serviços foram especificados de acordo com os requisitos levantados no Capítulo anterior e levando em consideração as Boas Práticas para Dados na Web (DWBP) propostas pelo W3C. Por exemplo, o Gerenciamento de Versões além de utilizar um indicador de versão, que pode ser a data ou um número, também permite listar todas as versões geradas, seguindo as recomendações da recomendação DWBP. Somado a isso, nos serviços descritos a seguir, consideramos que os conjuntos de dados têm apenas uma fonte de dados de origem. Para um melhor entendimento dos serviços, classificamos os conjuntos de dados a partir de três cenários, sendo: Cenário A: Conjuntos de dados criados a partir de bancos de dados, i.e. a fonte de dados de origem do conjunto de dados é um banco de dados; Cenário B: Conjuntos de dados criados a partir de APIs, i.e. a fonte de dados de origem do conjunto de dados é uma API disponível na Web; Cenário C: Conjuntos de dados criados a partir de arquivos offline, i.e. a fonte de dados de origem é um arquivo; Vale salientar que independente da fonte de dados, os conjuntos de dados devem ser armazenados no repositório de dados do SGDW para que seja possível prover todos os serviços de gerenciamento. Para cada cenário, também devemos considerar aspectos inerentes a cada tipo de fonte de dados de origem para possibilitar a extração dos dados. Para os conjuntos de dados do Cenário A, em que as fontes de dados são os bancos de dados, como bancos de dados acessíveis por um SGBD, deve ser necessário obter o host, usuário, senha e o nome do banco de dados para estabelecer uma conexão com a fonte de dados. Para os conjuntos de dados do Cenário B, deve ser necessário obter a URI da API e os parâmetros que permitam o acesso a fonte de dados. Enquanto que para os conjuntos de dados do Cenário C, em que os dados são extraídos a partir de arquivos, estes devem ser carregados no sistema.

71 5.2. DETALHAMENTO DA CAMADA DE SERVIÇOS Extração e Transformação dos Dados O serviço de Extração e Transformação de Dados deve intermediar as requisições de obtenção e transformação dos dados. Este serviço deve ter por objetivo automatizar a obtenção dos dados, preparando-os para publicação na Web. Figura 5.2: Fluxo de Atividades para o Serviço de Extração e Transformação de Dados. Fonte: o autor De modo geral, o fluxo de atividades para este serviço é ilustrado na Figura 5.2. A partir da fonte de dados, deve-se verificar a necessidade de estabelecer ou não uma conexão para recuperar os dados. Sendo uma fonte de dados que necessite estabelecer uma conexão, como para banco de dados ou API, a recuperação dos dados é iniciada. Não sendo necessário estabelecer a conexão, os dados devem ser recuperados a partir dos arquivos. À medida que os dados são recuperados das fontes, eles devem ser armazenados em uma área temporária até que a extração seja concluída. Concluída a extração, eles devem ser persistidos no repositório de dados. Dessa forma, o processo de enriquecimento pode utilizar técnicas de inferência para preencher valores ausentes ou gerar novos dados como, por exemplo, dados de localização a partir de dados de coordenadas. Do mesmo modo, a transformação dos dados deve possibilitar processos de limpeza nos dados, como a remoção de registros duplicados, e atividades que permitam transformar os dados originais em dados na Web, como alterar as abreviações dos Estados Brasileiros em seus respectivos nomes Criação de conjuntos de dados O serviço de Criação de Conjuntos de dados permite que o produtor defina quais dados deseja publicar, cadastre informações por meio de metadados e dê início ao processo de extração

72 5.2. DETALHAMENTO DA CAMADA DE SERVIÇOS 71 dos dados. Antes de criar o conjunto de dados, o produtor deve informar os dados necessários para se comunicar com a fonte de dados, i.e. deve cadastrar a fonte de dados previamente. Após cadastrar e selecionar a fonte de dados de origem, o serviço de criação de conjuntos de dados é iniciado e o fluxo de atividades segue conforme ilustrado na Figura 5.3. Figura 5.3: Fluxo de Atividades para o Serviço de Criação de Conjuntos de Dados. Fonte: o autor Conforme mostrado na Figura 5.3, inicialmente o produtor seleciona a fonte de dados previamente cadastrada e um teste é realizado para verificar se é possível estabelecer a conexão com a fonte de dados. Se a fonte de dados permitir o acesso, o produtor definirá quais os dados que devem ser coletados. Sendo de uma fonte de dados acessíveis por um SGBD relacional, o produtor deverá informar um comando SQL para seleção dos dados, como uma view ou um select. Sendo a fonte de dados uma API ou um arquivo carregado, o produtor poderá escolher dentre os dados coletados. Posteriormente, o produtor deve definir como os dados serão disponibilizados. Por fim, o serviço de Extração e Transformação de Dados é executado para obter os dados e, assim, criar o conjunto de dados com as configurações definidas. Os metadados definidos para o conjunto de dados compreendem todos os abordados como boas práticas e definidos no serviço de Gerenciamento de Metadados, como os metadados descritivos, estruturais, de proveniência, acesso, qualidade, versão e licença. Deste modo, o produtor deverá cadastrar os metadados descritivos e de licença, enquanto que o serviço poderá oferecer sugestões para os metadados estruturais e o de proveniência, que poderão ser obtidos a partir dos dados armazenados e do cadastro do produtor, respectivamente. Além disso, o produtor

73 5.2. DETALHAMENTO DA CAMADA DE SERVIÇOS 72 deverá informar a frequência de atualização do conjunto de dados, que será utilizada pelo serviço de Gerenciamento de Atualização. De modo geral, o serviço de Criação é subdividido em três componentes, sendo: Gerenciamento de subconjuntos: Sendo o conjunto de dados muito grande, é necessário que sejam disponibilizados subconjuntos dos dados. Assim, o produtor poderá definir critérios para selecionar subconjuntos úteis dos dados. Por exemplo, um conjunto de dados de todo o Brasil, poderiam ser separados em diferentes subconjuntos por região ou Estado. Gerenciamento de distribuições: Em seguida, o produtor deverá informar quais os formatos em que os dados serão disponibilizados, i.e. quais as distribuições do conjunto de dados. Os dados devem estar disponíveis em múltiplos formatos, como XML, RDF, CSV e JSON, para que sejam acessados por um número maior de consumidores. Por padrão, sempre será sugerido o maior número de formatos possíveis e os dados serão disponibilizados por meio da API. O Gerenciamento de Distribuições permitirá que tais formatos sejam gerados sem a necessidade de conversão por parte do produtor. Assim, independente do formato original dos dados, deve ser possível recuperar os dados em formatos distintos que promovam o reúso dos dados. Gerenciamento de URIs Também é necessário definir as URIs de acesso ao conjunto de dados e as distribuições. Dessa forma, este serviço deve garantir que as URIs geradas são únicas e persistentes. A partir do momento que um conjunto de dados é criado, deve ser possível utilizar os demais serviços como o Gerenciamento de Atualizações, para dados acessíveis por conexões cadastradas, e o Gerenciamento de Acesso Gerenciamento de Metadados O serviço de Gerenciamento de Metadados é responsável por gerir as informações que descrevem os conjuntos de dados, distribuições, subconjuntos, produtores e consumidores. Este serviço deve prover o uso de termos padronizados para descrever os metadados objetivando aumentar a interoperabilidade, reduzir ambiguidade e redundância nos termos utilizados. Além disso, também deve ser apoiado por um processo de curadoria que além de garantir a descrição adequada dos conjuntos de dados, também possibilite o enriquecimento, análise e preservação dos metadados (HIGGINS, 2008; BALL, 2012;, 2016). O processo de curadoria de metadados também permite lidar com diferentes questões, como a heterogeneidade estrutural, sintática e semântica. Ou seja, permite lidar com problemas quanto a utilização de esquemas conceituais diferentes, a atribuição de sintaxes diferentes a

74 5.2. DETALHAMENTO DA CAMADA DE SERVIÇOS 73 conceitos correspondentes e quanto às diferentes interpretações para os dados. Somado a isso, a curadoria de metadados também ajuda a lidar com a variabilidade dos níveis de qualidade e a diversidade de tipos de metadados. Mais detalhes sobre processos de curadoria de metadados são apresentados em Higgins (2008), Ball (2012), (2016). De forma geral, o Gerenciamento de Metadados recebe requisições e garante que os conjuntos de dados estarão adequadamente descritos por meio dos metadados. O fluxo de atividades deste serviço é apresentado na Figura 5.4. Figura 5.4: Fluxo de Atividades para o Serviço de Gerenciamento de Metadados. Fonte: o autor Ao receber uma requisição, o serviço de Gerenciamento de Metadados verifica se é uma atualização ou criação de metadados, por exemplo, se a requisição é de criação ou atualização de conjunto de dados. Não sendo uma atualização, os metadados serão criados a partir do conjunto mínimo de metadados necessário para descrever adequadamente o novo item, que pode ser um conjunto de dados ou um consumidor, por exemplo. Posteriormente, os metadados devem ser coletados e, sendo possível, enriquecidos antes de serem armazenados no repositório de metadados (, 2016). No caso de uma atualização automática realizada por outros serviços do SGDW, como o Gerenciamento de Versionamento e o Gerenciamento de Atualização, não é necessário preencher o conjunto mínimo de metadados, uma vez que, nesse caso, metadados específicos são atualizados de forma automática. No entanto, para atualizações realizadas por um produtor em um conjunto de dados, por exemplo, é necessário recuperar os metadados necessários para uma adequada descrição antes de armazená-los. O conjunto mínimo de metadados deve ser obtido a partir do conjunto de processos da curadoria de metadados, que deve levar em conta o reúso de vocabulários utilizados nesse contexto, como o DCAT 1 e o DCMI 2, além das boas práticas de Dados na Web do W3C. Dessa

75 5.2. DETALHAMENTO DA CAMADA DE SERVIÇOS 74 forma, ao descrever um conjunto de dados, será garantido que os metadados necessários para a adequada descrição deles estão sendo cobertos. Por exemplo, de acordo com o DWBP deverão ser coletados metadados descritivos, estruturais, de proveniência, acesso, qualidade, versão, licença, uso, republicação e metadados dos atores do ecossistema. Dentre os metadados descritivos, podemos citar título (dct:title), descrição (dct:description), palavras-chave (dcat:keywords), data de publicação (dct:issued), publicador (dct:publisher) e categoria (dcat:theme) Gerenciamento de Versões Dado que os conjuntos de dados podem ser alterados ao longo do tempo, tanto por uma correção, melhoria ou inserção de novos dados, o serviço de Gerenciamento de Versões mantém as diferentes versões de um mesmo conjunto de dados e possibilita o acesso a elas. Não existe consenso sobre quando uma nova versão deve ser gerada, mas assumimos que uma nova versão do conjunto de dados deverá ser gerada para cada alteração nos dados ou metadados do conjunto de dados. De modo geral, o fluxo de atividades deste serviço é ilustrado na Figura 5.5.

76 5.2. DETALHAMENTO DA CAMADA DE SERVIÇOS 75 Figura 5.5: Fluxo de Atividades para o Serviço de Gerenciamento de Versões. Fonte: o autor Quando for realizado qualquer tipo de alteração de dados em um conjunto de dados, o gerenciamento de versões deve garantir que a versão anterior a atualização poderá ser recuperada. Para tanto, será coletado e armazenado as diferenças entre a versão armazenada (antes de sofrer as atualizações) e a nova versão que será gerada. Posteriormente, as alterações são persistidas e a nova versão será gerada. Dessa forma, novos identificadores são gerados para garantir acesso à versão anterior e a nova. Por fim, o serviço de Curadoria de Metadados realiza as alterações necessárias nos metadados, incluindo o identificador de versão e a data de atualização. É fundamental que todo esse processamento seja realizado de forma automática, para que o produtor não tenha a necessidade de realizar alterações nos metadados, por exemplo. O gerenciamento de versões está diretamente relacionado à frequência de atualização dos conjuntos de dados. Em outras palavras, a garantia de que o consumidor poderá sempre utilizar a versão de dados mais recente, parte do pressuposto que será fornecido acesso a fonte de dados de origem. Dessa forma, quando um conjunto de dados for atualizado conforme sua

77 5.2. DETALHAMENTO DA CAMADA DE SERVIÇOS 76 frequência de atualização, deve ser gerado uma nova versão do conjunto de dados. Esse procedimento poderá acarretar em uma grande e crescente quantidade de dados. Portanto, em um cenário ideal, se a alteração for para adicionar novos dados, é importante armazenar apenas a diferença dos dados, ou seja, os novos dados. Sendo de exclusão, as linhas devem ser marcadas como não ativas. Sendo de alteração, a linha antiga deve ser marcada como inativa e a linha alterada inserida como uma nova. No processo de recuperação de versões anteriores a atual, todas as alterações que foram realizadas devem ser recuperadas de um log de alterações e desfeitas até a versão desejada. Quando a atualização envolver a estrutura do conjunto de dados, este deverá ser armazenado e uma nova versão deverá ser gerada. Os dados também pode ser oriundos de fontes que forneçam acesso em tempo real aos dados, ou seja, dados que tenham uma frequência de atualização extremamente pequena e à medida que são coletados, também já são disponibilizados. Tais dados praticamente não sofrem atualizações ou exclusões, geralmente eles apresentam a necessidade de inserir novos dados de forma frequente, como é o caso dos dados obtidos a partir de sensores. Para esses casos, deve ser armazenado a data/hora que eles foram obtidos e versioná-los a partir dela. Para o caso de alterar a estrutura, ele deverá ser armazenado e uma nova versão deverá ser gerada, também permitindo a recuperação das versões a partir da data/hora. Para quem consome os dados e não especifica a versão desejada, o serviço deve garantir o acesso a última versão disponível do conjunto de dados dados. Sendo especificada, deve ser retornado a respectiva versão. A Figura 5.6 mostra o processo de consumo das versões. Figura 5.6: Consumo das versões dos conjuntos de dados. Fonte: o autor No exemplo da Figura 5.6, o conjunto de dados X tem 4 versões e sua versão mais atual é a X-v4. Dessa forma, quando for solicitado os dados do conjunto de dados X e não for especificado nenhuma versão, deve ser retornado os dados da versão mais recente. Para tornar o conjunto de dados confiável, as versões anteriores devem ser disponibilizadas aos consumidores. Para tanto, é necessário listar todas as versões geradas e permitir o acesso a elas de modo que seja especificado a versão desejada para garantir a recuperação dos respectivos dados. Somado a

78 5.2. DETALHAMENTO DA CAMADA DE SERVIÇOS 77 isso, quando os dados forem consumidos por meio da API e o consumidor não desejar trabalhar sempre com os dados mais atuais, a versão do conjunto de dados atual, no momento do uso, deverá ser informada Gerenciamento de Atualização O serviço de Gerenciamento de Atualização tem por objetivo garantir que os conjuntos de dados serão atualizados dado sua frequência de atualização pré-definida. Quando os conjuntos de dados são criados a partir de uma fonte de dados que permita acesso ao banco de dados ou API na Web, é possível mantê-los atualizados dado a frequência de atualização. A Figura 5.7 mostra como acontece o fluxo de atividades deste serviço. Figura 5.7: Fluxo de Atividades para o Serviço de Gerenciamento de Atualizações. Fonte: o autor No processo de criação dos conjuntos de dados, é necessário informar uma frequência de atualização para os conjuntos de dados que serão criados a partir de acessos à bancos de dados ou APIs. Dessa forma, o serviço de gerenciamento de atualização garante o monitoramento e integração com os demais serviços para a atualização automática dos dados. Em outras palavras, o serviço monitora a frequência de atualização e verifica o momento em que cada conjunto de dados tem que ser atualizado. Se estiver no momento de atualização, ele se conecta ao serviço de Extração e Transformação de dados para obter os dados atualizados. Posteriormente, é realizado uma chamada ao serviço de Gerenciamento de Versões que verifica as alterações realizadas e gera uma nova versão, bem como para o serviço de Curadoria de Metadados que atualiza os metadados. Geralmente, as frequências de atualização são consideradas por hora, diariamente,

79 5.2. DETALHAMENTO DA CAMADA DE SERVIÇOS 78 semanalmente, mensalmente, trimestralmente, semestralmente e anualmente. Durante o processamento para gerar uma nova versão, o serviço pode detectar que os dados podem não ter sido alterados. Nesse caso, as seguintes ações serão consideradas para os cenários descritos anteriormente: Cenário A: Ele poderá ser considerado atualizado, uma vez que não houve alteração na fonte de dados de origem. Cenário B: Não é possível identificar se os dados foram de fato atualizados ou não. Ou seja, a API pode coletar os dados de uma outra fonte de dados e não ter sido atualizada. Sendo assim, o serviço deve atualizar os metadados com a informação da data de verificação de atualizações e permanecer a última data de alteração, informando que não houve alterações a partir das verificações realizadas. Cenário C: A garantia de atualização depende de processos secundários que gere o arquivo atualizado. Para garantir que os dados presente no arquivo gerado serão publicados, é necessário a utilização de uma ferramenta de processamento de arquivos entre a origem (quem gera o arquivo) e o servidor onde o SGDW estará instalado. Assim, a ferramenta deve permitir que o produtor crie um vínculo do arquivo offline com o conjunto de dados, enviando os dados para que sejam extraídos e transformados. Para que o produtor possa acompanhar todas as atualizações realizadas, é importante manter um log de erros e alertas, para que seja possível saber os motivos da não atualização Gerenciamento de Acesso O serviço de gerenciamento de acesso garante que os dados armazenados no repositório de dados poderão ser recuperados por meio de download em massa e por meio de uma API. No processo de criação de um conjunto de dados, o produtor pode definir como o conjunto de dados e os subconjuntos serão disponibilizados. O processo de desenvolvimento de APIs, de forma manual pelos produtores, apresenta um custo associado ao tempo de desenvolvimento, por exemplo. Dessa forma, é necessário facilitar a criação automática de APIs para acesso aos conjuntos de dados. Com os conjuntos de dados criados e os dados armazenados, este serviço garante a criação de forma padronizada e automática das APIs nos Cenários A, B e C. Assim, por meio das APIs, os consumidores poderão recuperar os dados e metadados enviando requisições HTTP, usando os métodos GET e POST, a partir de URIs exclusivas dos conjuntos de dados. Usando o método GET, deve ser possível recuperar dados e metadados a

80 5.2. DETALHAMENTO DA CAMADA DE SERVIÇOS 79 partir de métodos já definidos na API. Além disso, deve ser reservada a possibilidade de realizar buscas avançadas e personalizadas enviando requisições POST, especificando os parâmetros desejados. Assim, será possível recuperar subconjuntos dos dados, sejam os definidos pelo produtor ou a partir dos filtros realizados pelos consumidores. Somado a isso, deve ser possível acessar as diferentes versões de um conjunto de dados. É importante ressaltar que a API deve ser bem documentada, garantindo que todas os métodos, funções e opções sejam conhecidas pelos consumidores para que seja possível seu uso. Uma API também deve prever uma manutenção de forma que todos os métodos e acesso disponibilizados sejam preservados ao longo do tempo. Assim, tendo necessidade de alterações das respostas, métodos ou acesso, uma nova API ou uma nova versão dela deve ser disponibilizada, mantendo todos os acessos anteriores ativos. Quanto ao download em massa dos dados, o SGDW deve garantir que será possível realizar o download dos subconjuntos dos dados de forma separada ou ainda, a partir de um pré-processamento do lado do servidor, permitir o download de todos os dados em um único arquivo. Também é necessário que download em massa seja permitido tanto através da Interface Web quanto da Interface Remota. Por fim, para recuperação dos dados em múltiplos formatos é necessário a utilização da negociação de conteúdo, ou seja, ao solicitar um recurso, o consumidor (cliente) negocia o formato com o SGDW (servidor) especificando o formato que deseja receber os dados. De modo geral, o fluxo de atividades para este serviço é apresentado na Figura 5.8. Figura 5.8: Fluxo de Atividades para o Serviço de Gerenciamento de Acesso. Fonte: o autor Os consumidores enviam as requisições para o sistema que valida os parâmetros recebidos

81 5.2. DETALHAMENTO DA CAMADA DE SERVIÇOS 80 e efetua a busca pelo conjunto de dados desejado. Uma vez encontrado o conjunto de dados, verifica-se qual a versão desejada, se é uma versão específica ou a atual. Sendo solicitado subconjuntos dos dados, os dados são filtrados conforme os parâmetros informados e a versão escolhida. Dessa forma, os dados serão recuperados e serão formatados de acordo com o formato escolhido pelo consumidor ou, caso não seja definido um formato, os dados serão formatados em JSON. Por fim, verifica-se o tipo de retorno dos dados, sendo gerado um arquivo para download no formato escolhido ou imprimindo a saída Preservação dos Conjuntos de dados Como dito anteriormente, um conjunto de dados apresenta três fases: criado; publicado e preservado. Dentre elas, a preservação é a fase quando o produtor sinaliza a intenção de descontinuar o conjunto de dados. No entanto, é necessário garantir que ele continuará acessível, permitindo obter informações que permitirão recuperar os dados ou saber como recuperá-los. Para tanto, o serviço de Preservação dos conjuntos de dados, garante que todos os conjuntos de dados compartilhados na Web pelo produtor terão sua URI preservada, possibilitando o acesso aos metadados e/ou aos dados. De modo geral, para preservação de um conjunto de dados, é necessário seguir o fluxo de atividades da Figura 5.9. Figura 5.9: Fluxo de Atividades para o Serviço de Preservação de Conjuntos de Dados. Fonte: o autor Quando desejar descontinuar um conjunto de dados, o produtor deve atualizá-lo sinalizando o desejo de preservá-lo. Dessa forma, serão interrompidos os serviços de atualização automática e versionamento. Uma vez que o conjunto de dados não será mais atualizado, o produtor deve informar os motivos que levaram a descontinuação dele, por meio dos metadados, para que essa informação seja disponibilizada aos consumidores. Assim, deverá ser informado o tipo de preservação (se arquivamento ou completa remoção) e uma descrição do motivo da preservação. Um conjunto de dados pode ser descontinuado devido a sua completa remoção ou devido ao seu arquivamento. Se for removido, a URI de acesso será preservada e os dados não

82 5.2. DETALHAMENTO DA CAMADA DE SERVIÇOS 81 poderão mais ser acessados. Sendo arquivado, a última versão dos dados será arquivada e poderá ser acessada. Para todos os conjuntos de dados removidos, o acesso a sua URI retornará um código de resposta HTTP 410, indicando que o recurso está intencionalmente indisponível e que o produtor deseja que o acesso ao conjunto de dados seja removido. Essa resposta se estenderá para todas as URIs do conjunto de dados, i.e. para as distribuições, versões e subconjuntos. Já quando o conjunto de dados for arquivado, além de apresentar informações sobre o arquivamento, será possibilitado o acesso a última versão do conjunto de dados Gerenciamento do Uso dos Dados Rastrear o uso dos conjuntos de dados permite ao produtor saber se os dados estão sendo usados ou não, além de possibilitar a identificação de possíveis melhorias, falhas e correções nos dados. No entanto, os consumidores carecem de maneiras eficazes para descrever e discutir experiências com outros consumidores e enviar feedback para os produtores. De modo geral, o serviço de Gerenciamento do Uso dos Dados deve possibilitar a coleta de informações sobre as aplicações geradas a partir dos dados, receber comentários de feedback e permitir o cadastro dos consumidores de conjuntos de dados específicos. O fluxo de atividades deste serviço é apresentado na Figura Figura 5.10: Fluxo de Atividades para o Serviço Gerenciamento do Uso dos Dados. Fonte: o autor De modo geral, os consumidores poderão cadastrar comentários de feedback, realizar a avaliação de um conjunto de dados ou cadastrar uma aplicação. Caso o consumidor deseje realizar seu cadastro ou efetuar login, será possível gerenciar as aplicações e comentários de feedback cadastrados em sua área. Para realizar o cadastro de um aplicação, o consumidor

83 5.2. DETALHAMENTO DA CAMADA DE SERVIÇOS 82 deve preencher as informações necessárias sobre a aplicação, como os conjuntos de dados que usou no desenvolvimento e qual o problema que a aplicação ajuda a resolver. Se o feedback for uma avaliação de um conjunto de dados, pontuações devem ser informadas para os critérios pré-definidos ou para a avaliação geral de um conjunto de dados. Por fim, se for um comentário de feedback, os consumidores poderão solicitar novos dados ou correções, informar ausência de metadados ou apresentar dúvidas acerca do conjunto de dados. O Dataset Usage Vocabulary (DUV) 3 especifica uma série de conceitos fundamentais para rastrear como os conjuntos de dados estão sendo usados e para a representação de feedback. De uma perspectiva de interface de usuário, o DUV exemplifica maneiras de coletar feedback, como registro no site, formulários de contato, classificação e avaliação de qualidade, pesquisas e cadastros de comentários. Para as aplicações geradas a partir dos conjuntos de dados, geralmente devem ser coletados os dados que são usados, uma descrição do que a aplicação faz, o problema que ajuda a resolver e a URI de acesso ou download(oliveira; LÓSCIO, 2014). Somado a isso, outros metadados podem ser coletados, como categoria da aplicação, licença, sistema operacional, palavras-chave e o quem desenvolveu a aplicação. Dessa forma, além das aplicações, é importante que sejam coletados feedback conforme descritos no DUV. Assim, os consumidores devem ter a possibilidade de realizar a classificação dos conjuntos de dados preenchendo formulários que apresentem critérios pré-definidos e um intervalo discreto de valores. Por exemplo, um formulário que permita que o consumidor informe o nível de qualidade do conjunto de dados considerando uma avaliação por estrelas e selecionando uma opção de 1 a 5 estrelas. Somado a isso, os conjuntos de dados podem apresentar inconsistências de metadados preenchidos pelo produtor ou apresentar erros nos dados. Assim, deve ser possível que um consumidor envie feedback para preencher metadados ausentes ou inconsistentes, assim como comentários sobre erros detectados nos dados. Para tanto, deve ser fornecido um formulário que colete o motivo do feedback (se inconsistência, ausência, comentário, solicitação, sugestão), o texto de comentário, o consumidor que está comentando e o conjunto de dados ou distribuição relacionada, por exemplo. Também deve ser possível que um consumidor possa realizar seu cadastro no SGDW para acompanhar conjuntos de dados desejados, gerenciar as aplicações cadastradas e receber alertas. Por exemplo, um consumidor pode receber alertas de novos conjuntos de dados de seu interesse ou avisos de respostas de um comentário de feedback. Para o cadastro do consumidor, pode ser coletado o nome, , senha e os temas de interesse para os conjuntos de dados. Para o produtor, deve ser possível receber alertas quanto a cada comentário de feedback cadastrado, além de ter a possibilidade de respondê-los. Somado a isso, os produtores devem acompanhar o uso dos conjuntos de dados a partir de estatísticas, como estatísticas de acesso e download, ter a possibilidade de visualizar as aplicações cadastradas e os interesses dos consumidores. 3

84 5.3. CONCLUSÃO Conclusão 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 um modelo de arquitetura que procura preencher as lacunas de gerenciamento do conjuntos de dados deixadas pelas soluções disponíveis atualmente. A fim de atender aos requisitos listados anteriormente, propomos um modelo de arquitetura para um SGDW, ou seja, uma arquitetura para 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. Para tanto, foi proposto um modelo de arquitetura para um SGDW que é composto por uma camada de Dados e Metadados, uma camada de Serviços e uma camada de Acesso. A camada de Dados e Metadados deve permitir o armazenamento dos dados e metadados dos conjuntos de dados e a camada de Acesso deve prover interfaces que permitam o uso dos serviços disponíveis. Já a camada de Serviços deve ser composta por serviços que permitem o gerenciamento dos conjuntos de dados e metadados. Cada serviço proposto atende um ou mais dos requisitos detalhados no Capítulo anterior. O Quadro 5.1 apresenta os requisitos elencados para o compartilhamento de dados e os serviços do modelo de arquitetura proposto que atendem aos requisitos.

85 5.3. CONCLUSÃO 84 Quadro 5.1: Premissas e Requisitos para o compartilhamento de dados x Serviços do modelo de arquitetura proposto Premissa Requisitos Serviços Premissa 1: Não existe um conhecimento prévio entre os responsáveis pela disponibilização dos dados e os interessados em fazer uso dos dados Premissa 2: Os conjunto de dados podem ter origem em fontes de dados já existentes Premissa 3: Os conjuntos de dados não são estáticos, ou seja, podem sofrer atualizações na descrição ou nos dados ao longo tempo Premissa 4: Os princípios arquiteturais da Web devem ser seguidos R1. Prover mecanismos para a criação de conjuntos de dados auto-descritivos R2. Possibilitar a criação de múltiplas distribuições para um mesmo conjunto de dados, ou seja, a disponibilização dos dados em diferentes formatos R3. Prover múltiplos meios de acesso aos conjuntos de dados, que podem ser desde o download de arquivos até o acesso por meio de APIs R4. Prover mecanismos para a criação de canais de comunicação entre os atores do ecossistema de dados na Web R5. Garantir o acesso a dados atualizados de acordo com a fonte de origem R6. Prover mecanismos para a extração e transformação dos dados de origem em dados na Web R7. Prover mecanismos para o gerenciamento de versões de conjuntos de dados R8. Prover mecanismos para o gerenciamento de metadados (curadoria de metadados) R9. Garantir a preservação dos conjuntos de dados ao longo do tempo R10. Garantir o uso de identificação única, por meio de URIs, para os conjuntos de dados, distribuições, versões e, preferencialmente, para os itens de cada conjunto de dados Fonte: o autor Criação de conjuntos de dados Gerenciamento Distribuições Gerenciamento Acesso Gerenciamento Uso dos Dados Gerenciamento Atualização de de do de Extração e Transformação de Dados Gerenciamento Versões Gerenciamento Metadados de de Preservação dos Conjuntos de Dados Gerenciamento URIs de

86 85 6 Prova de conceito do Modelo de Arquitetura para um SGDW Neste Capítulo apresentaremos os detalhes de implementação da prova de conceito realizada para o modelo de arquitetura proposto no Capítulo anterior. Para isto, a Seção 6.1 apresenta uma visão geral da implementação da solução desenvolvida e na Seção 6.2 discorremos sobre a adequação da implementação aos requisitos listados para um SGDW. 6.1 Visão geral da implementação Visando mostrar que é possível desenvolver uma solução que gerencie adequadamente os conjuntos de dados na Web, foi desenvolvida uma solução, como prova de conceito, que implementa os requisitos de extração dos dados, criação de conjunto de dados auto-descritivos, gerenciamento de atualizações automáticas e versionamento. Como resultado dessa prova de conceito, foi desenvolvida a solução SGDW-v01 que provê acesso a uma interface Web para os consumidores, acessível por meio da URI < uma interface Web para os produtores, acessível por meio da URI < e acesso a uma interface remota por meio da URI < Durante o desenvolvimento da solução, foi usado o Git como framework de gerência de configuração e o código foi disponibilizado em um repositório público do GitHub, acessível por <https: //github.com/dass-cin/sgdw> Arquitetura e tecnologias de implementação De modo geral, baseado na arquitetura Web, o SGDW-v01 foi desenvolvido em duas grandes partes, sendo uma com tecnologias client-side (executadas no navegador do cliente) e a outra com tecnologias server-side (executadas no servidor), sendo as interações com os usuários realizadas por intermédio de requisições HTTP, via navegador Web. Em outras palavras, o lado do cliente se comunica com o lado do servidor por meio do uso de uma API REST que é exposta pelo servidor. A arquitetura do SGDW-v01 está ilustrada na Figura 6.1.

87 6.1. VISÃO GERAL DA IMPLEMENTAÇÃO 86 Figura 6.1: Arquitetura da Prova de Conceito (SGDW-v01). Fonte: o autor No lado do servidor, temos todas as funcionalidades que vão desde a extração dos dados nas fontes de origem até a realização de consultas e recuperação dos dados. Para ser uma solução multiplataforma e de fácil instalação, o desenvolvimento foi fundamentado no uso da linguagem de programação Java. Foi utilizado o Gradle 1 para o gerenciamento do projeto, controle de dependências e compilação da aplicação. Assim, foi possível automatizar a geração do arquivo Web application ARchive (WAR), que é usado para implantar a aplicação no servidor. Para armazenar os metadados e os dados, foi utilizado o MongoDB 2, um banco de dados multi-plataforma orientado a documentos, que oferece um alto desempenho, disponibilidade e escalabilidade. No MongoDB, os dados são armazenados em coleções de dados que não exigem que todos os dados apresentem o mesmo esquema, permitindo uma maior flexibilidade no armazenamento. Internamente, uma instância do MongoDB armazena os dados em documentos BSON, que são são arquivos JSON codificados em formato binário (MONGODB, 2017). A Camada de Serviços foi desenvolvida usando o Spring 3, um framework open source

88 6.1. VISÃO GERAL DA IMPLEMENTAÇÃO 87 para plataforma Java baseado no padrão de projeto de injeção de dependências 4. Esse padrão está fundamentado no uso de abstrações, sejam classes abstratas ou interfaces, para quebrar o forte acoplamento entre as classes e inverter a dependência. Assim, ao invés de depender de uma classe concreta, dependemos de uma abstração, o que torna o cenário desacoplado, de fácil manutenção e evolução. É também por meio do Spring que as APIs são construídas, o que permite que todos os dados recebidos por meio delas sejam mapeados em classes Java, e as rotinas temporais sejam executadas, o que permite manter os conjuntos de dados atualizados. Para comunicação e armazenamento dos dados a partir da aplicação, foi utilizado o Mongo-Java-Driver 5, que é o driver oficial disponibilizado pela MongoDB. Já para extração dos dados das fontes de dados de origem, foi utilizado o Hibernate 6 que é um framework para o mapeamento objeto-relacional escrito na linguagem Java. Assim, o Hibernate é responsável por realizar as consultas SQL e faz o mapeamento em classes Java. A versão atual do SGDW-v01, apesar de ser uma prova de conceito, não se limita apenas a consultas de um único SGBD, sendo possível estabelecer comunicação com quatro dos SGBDs mais populares: PostgreSQL 7, MySQL 8, SQL Server 9 e o Oracle 10. Foram desenvolvidas duas APIs, uma direcionada para atividades de cadastro e gerenciamento dos conjuntos de dados pelo produtor (AdminREST) e outra que permite acesso aos metadados e conjuntos de dados para os consumidores (OpenREST). Cada API tem rotas específicas, que serão descritas na Subseção 6.2.6, e permitem acesso aos serviços a partir de requisições HTTP. Para acessar a API AdminREST, no entanto, é necessário fornecer um token válido, que é gerado quando o produtor efetua login no sistema. Assim, a partir das requisições recebidas na API, os serviços são executados e podem recuperar dados ou metadados, assim como realizar atividades de extração ou atualização dos conjuntos de dados, por exemplo. Portanto, no lado do servidor, temos a Camada de Serviços com todas as regras de negócio do SGDW-v01. A Camada de Persistência, por sua vez, é responsável por persistir os conjuntos de dados no MongoDB, além de permitir a conexão e coleta dos dados das fontes de origem. Para que os produtores e consumidores possam utilizar os serviços, são disponibilizadas duas APIs REST, sendo uma com acesso público e outra com acesso restrito. O lado do cliente se divide em duas partes principais, sendo duas aplicações Web independentes que fornecem as interfaces para os produtores e consumidores. Enquanto uma aplicação permite a consulta e acesso aos conjuntos de dados por meio de uma Interface Web para os consumidores, a outra aplicação permite que o produtor gerencie o cadastro de fontes de dados de origem e dos conjuntos de dados a serem publicados, assim como possa realizar atualizações manuais nos conjuntos de dados

89 6.1. VISÃO GERAL DA IMPLEMENTAÇÃO 88 Tanto a aplicação para os consumidores quanto a aplicação dos produtores foram implementadas como Single Page Application (SPA) 11, ou seja, cada uma como uma aplicação Web executada em apenas uma página com grande parte de seu código no cliente, em JavaScript. Para tanto, construímos o layout do SGDW-v01 a partir do BlurAdmin, que é um framework open source que fornece uma estrutura base com os principais componentes configurados para desenvolvimento de um SPA. Por exemplo, em sua estrutura, o BlurAdmin usa outros frameworks como AngularJS 12 e Bootstrap 13, que são usados como framework de JavaScript (JS) e Cascading Style Sheets (CSS), respectivamente. No desenvolvimento das aplicações, foi usado o Node.js 14 e, para gerenciar as dependências das aplicações, os seus pacotes Bower 15 e Gulp 16. O Node.js é uma plataforma construída sobre o motor JavaScript do Google Chrome para construir aplicações rápidas e escaláveis 17. O Bower é usado para gerenciar as versões corretas das bibliotecas e suas respectivas dependências da interface. Todas as versões dos pacotes são especificados no arquivo bower.json, como as versões do Angular e o do Bootstrap. Já o Gulp é usado para compilar as aplicações, concatenar todos os arquivos JS e CSS e, após, fazer a minificação do código. Além disso, o Gulp é usado para gerar o código final que deve ser usado no ambiente de produção, ou seja, ele separa em pastas o código estável em produção do código que é utilizado no desenvolvimento da aplicação. Para utilizar e manipular os dados, as aplicações fazem requisições à API REST construída no servidor. O Angular também utiliza a injeção de dependências nos componentes das aplicações, dessa forma todas as dependências de cada componente da aplicação ficam explícitas. A injeção de dependências, juntamente com a estrutura que adotamos para desenvolvimento de novos componentes, facilita a organização dos arquivos, conforme pode ser observado na Figura

90 6.1. VISÃO GERAL DA IMPLEMENTAÇÃO 89 Figura 6.2: Arquitetura do Angular (a) e Estrutura de pastas do projeto da Interface Web do produtor (b). Fonte: o autor Como dito anteriormente, o Angular permite o desenvolvimento de aplicações com o conceito de SPA, assim os arquivos são dinamicamente carregados e adicionados à página conforme necessário, ou seja, conforme as ações dos usuários. Para tanto, o framework oferece módulos que possibilitam ter apenas uma página index e outras páginas de conteúdos (views) que são carregadas de acordo com uma rota específica (routes). Conforme ilustrada na Figura 6.2 (a), temos o module que é usado registrar os componentes da aplicação, como controllers e services, e definir os processos de inicialização e configuração (config). De acordo com uma rota solicitada, a view e o controller correspondentes são carregados. As diretivas (directives) são usadas para estender o HTML e criar novas tags. Já os services são utilizados para realizar a lógica de comunicação com a API e retornar os dados para o controller, que utiliza o scope para construir as views. Para desenvolvimento de um novo módulo da interface, conforme pode ser visto na Figura 6.2 (b) deve ser criado uma nova pasta com o nome do novo módulo e, basicamente, ser adicionado três arquivos: "nomedapasta.module.js", "nomedapasta.view.html"e "nomedapasta.controller.js". No primeiro deve ser configurado qual a rota que corresponde ao módulo, o segundo deve conter o HTML (template) padrão do módulo e no controller, deve conter a lógica para construção da tela. Quando a view precisar de dados externos para sua construção, como os carregados por meio da API, deve ser criado um quarto arquivo ( nomedapasta.service.js ) com as funções para realizar a comunicação com a API que serão usadas pelo controller. Por fim, para que o componente seja adicionado a rota principal da aplicação, o nome do módulo criado deve ser adicionado no arquivo pages.module.js. Dessa forma, essa estrutura faz com que as dependências do componente sejam inseridas dentro de sua respectiva pasta e que o componente seja adicionado automaticamente ao menu principal do aplicação. Portanto, para desenvolver as interfaces Web do SGDW-v01, visando o desenvolvimento evolutivo da solução, usamos frameworks open source para auxiliar no desenvolvimento. Também buscamos facilitar e automatizar tarefas repetitivas no desenvolvimento, como a concatenação de arquivos, minificação de arquivos e o gerenciamento de dependências. Além disso, a

91 6.1. VISÃO GERAL DA IMPLEMENTAÇÃO 90 estrutura adotada permite que novos componentes sejam adicionados de forma fácil e organizada Funcionalidades SGDW-v01. Na Figura 6.3 é ilustrado o diagrama de casos de uso das principais funcionalidades do Figura 6.3: Principais Casos de Uso da Solução. Fonte: o autor Como pode ser visto na Figura 6.3, o produtor pode efetuar login, seja por meio da interface administrativa ou API, e assim obter autorização (token) para acessar as funcionalidades do sistema. Ao realizar o cadastro de uma fonte de dados, o produtor deverá informar os dados necessários para permitir o acesso a ela. No processo de criação de um conjunto de dados, o produtor deverá informar os metadados solicitados pela ferramenta, selecionar uma fonte de dados e informar os dados que deverão ser extraídos da fonte de dados selecionada. Também é reservado ao produtor atualizar os conjuntos de dados de forma manual, informando ao sistema que atualize o conjunto de dados a partir dos dados da fonte cadastrada.

92 6.1. VISÃO GERAL DA IMPLEMENTAÇÃO 91 Todos os casos de uso do consumidor também são casos de uso do produtor. Assim, ele também pode consultar os conjuntos de dados, visualizar o históricos de versões e os metadados dos conjuntos de dados. Somado a isso, também pode recuperar os conjuntos de dados nos diferentes formatos disponíveis, assim como os metadados e os dados de qualquer versão gerada do conjunto de dados. Vale salientar que a interface Web foi construída a partir das APIs disponíveis, portanto, as ações dos produtores e consumidores podem ser realizadas tanto pela interface Web quanto por meio de requisições na API Implantação O sistema foi publicado na Web usando os serviços da Amazon Web Services(AWS) que é uma plataforma de serviços em nuvem. Assim, foi criada uma máquina virtual com uma instância do Windows Server 2016, com um disco de armazenamento de 128GB, 3.5 GB de memória ram e um núcleo para processamento. Na máquina virtual foram instalados o Java versão , o Java SE Development Kit 8u e o MongoDB Community versão Também foi instalado o Internet Information Services (IIS) 21, que é o servidor Web do Windows, sendo configurado para ser executado na porta 80 (HTTP). O IIS foi usado para hospedar os arquivos da interface Web. Já a aplicação server-side, foi configurada para executar internamente o Jetty 22, que é um servidor HTTP e Servlet Container escrito em Java. Portanto, quando o arquivo WAR da aplicação é executado, o servidor Jetty é iniciado juntamente com a aplicação na porta Quando a aplicação server-side é executada pela primeira vez, é criado um arquivo mongoconfig.properties na raiz do sistema operacional (e.g. "c: ) para que seja informado o caminho para a conexão com o MongoDB. Posteriormente, ao ser novamente executado, três novas coleções são criadas, sendo a collector_users a coleção que contém os dados para acesso dos produtores, a collector_conf que armazena os metadados dos conjuntos de dados e do sistema e a collector_origin_conf que armazerá as conexões com as fontes de dados relacionais. Dessa forma, a interface para acesso dos consumidores pode ser acessada por meio da URI < enquanto que a interface para os produtores pode ser acessada por meio da URI < e a API de acesso aos dados pode ser acessada por meio da URI < À medida que os conjuntos de dados são criados, duas novas coleções são inseridas, sendo uma com o nome do conjunto de dados, para armazenar todos os dados obtidos, e outra com o nome do conjunto de dados seguido de "_history"para armazenar as versões do respectivo conjunto de dados. Vale salientar que as interfaces e a aplicação server-side poderiam ter seus próprios

93 6.2. ADEQUAÇÃO DA IMPLEMENTAÇÃO AOS REQUISITOS 92 servidores, uma vez que foram desenvolvidas independentes do código uma da outra, apenas por consumo da API. Porém, por questão de custos e por se tratar de uma prova de conceito, foram disponibilizados na mesma máquina virtual. 6.2 Adequação da Implementação aos Requisitos Conforme discutido no Capítulo anterior, um SGDW deve ser capaz de realizar tarefas que permitam gerenciar adequadamente os conjuntos de dados. Dessa forma, um SGDW apresenta alguns requisitos específicos, conforme discutido no Capítulo 3. Assim, a prova de conceito apresentada teve por objetivo mostrar que é possível implementar a arquitetura proposta e que os serviços propostos de fato atende os requisitos listados anteriormente. Esta seção discute a adequação dos serviços implementados quanto aos requisitos necessários para um SGDW. É importante lembrar que é possível acessar todos os serviços listados nesta Seção tanto por meio da API quanto pela interface Web do produtor ou consumidor. Para acessar as funcionalidades inerentes ao módulo do produtor, é necessário realizar login no sistema informando um usuário e senha, conforme observado na Figura 6.4. Figura 6.4: Tela de login do sistema do produtor. Fonte: o autor Quando informado um usuário e senha válidos, o servidor gera um token e este é armazenado na Session Storage23 do navegador do cliente. A Session Storage é o local onde os aplicativos da Web podem armazenar dados localmente no navegador do usuário. A Figura 6.5 mostra o token armazenado na sessão do cliente e o token quando é gerado via API, utilizando a ferramenta Postman 24 para simular a requisição. Vale salientar que, por questões de segurança,

94 6.2. ADEQUAÇÃO DA IMPLEMENTAÇÃO AOS REQUISITOS 93 tanto é verificado se consta um token válido na sessão do navegador quanto se o token armazenado ainda continua válido no servidor. Figura 6.5: Token salvo na Session Storage (a) e Token gerado após simular uma requisição a API (b). Fonte: o autor A seguir, todos os serviços da prova de conceito são descritos. Para as funcionalidades da aplicação do produtor, assumimos que já foi realizado o login na ferramenta Collector Em nossa prova de conceito, o Serviço Collector é o responsável por realizar o gerenciamento das fontes de dados e a extração dos dados Cadastro de Fonte de Dados Como dito anteriormente, o procedimento de obtenção dos dados ocorre de forma diferente para cada tipo de fonte. No entanto, para nossa prova de conceito, consideramos as fontes de dados acessíveis por um SGBD relacional. Nesse caso, para estabelecer uma conexão com a fonte de dados, é necessário informar uma string de conexão Java Database

95 6.2. ADEQUAÇÃO DA IMPLEMENTAÇÃO AOS REQUISITOS 94 Connectivity (JDBC) 25, o usuário, a senha e o nome do banco de dados. Após informar os dados, o sistema efetua um teste de conexão com os dados informados. Se os dados permitirem estabelecer uma conexão, a fonte de dados é cadastrada. Caso não seja possível estabelecer a conexão, uma mensagem de erro é informada e o cadastro não é realizado. O formulário para cadastro das fontes de dados é ilustrado na Figura 6.6. Figura 6.6: Cadastro de fonte de dados. Fonte: o autor Nesta versão, é possível realizar o cadastro dos quatros SGBDs mais utilizados atualmente 26, sendo o Oracle, MySQL, SQL Server e PostgreSQL. Para cada SGBD, é necessário informar sua respectiva string de conexão JDBC: Oracle: jdbc:oracle:thin:@<host>:<port>:<sid> MySQL: jdbc:mysql://<host>:<port>/<db> SQL Server: jdbc:microsoft:sqlserver://<host>:<port>[;databasename=<db>] PostgreSQL: jdbc:postgresql://<host>:<port>/<db> Como a interface é construída a partir do consumo da API do servidor, à medida que novos SGBDs são configurados na API eles já são adicionados automaticamente a interface. A Figura 6.7 ilustra o retorno dos tipos de SGBDs recebidos por meio da API

96 6.2. ADEQUAÇÃO DA IMPLEMENTAÇÃO AOS REQUISITOS 95 Figura 6.7: Tipos de SGBDs recebidos por meio da API. Fonte: o autor Extração e Transformação de Dados Uma vez cadastrada e estabelecida uma conexão com a fonte de dados, é possível realizar a extração dos dados. No entanto, este processo só ocorre no momento da criação dos conjuntos de dados, dado que o produtor deve especificar um comando SQL para que o Collector execute a consulta e obtenha os dados que serão publicados. De modo geral, após informar quais os dados devem ser extraídos e de qual fonte, é enviada uma requisição para o serviço de extração de dados. O serviço de extração recebe a requisição com a configuração informada e realiza a conexão com o SGBD. Com a conexão realizada, executa o comando SQL para obter os dados e persistir no MongoDB. Após obter todos os dados, o DataTransformer realiza a transformação dos dados, conforme ilustrado na Figura 6.8. Figura 6.8: Processo de extração de dados implementado na Prova de Conceito. Fonte: o autor Em síntese, o Collector tem como objetivo automatizar a obtenção dos dados preparando-

97 6.2. ADEQUAÇÃO DA IMPLEMENTAÇÃO AOS REQUISITOS 96 os para publicação na Web e o DataTransformer transforma os dados automaticamente para os formatos CSV, XML e JSON. A Figura 6.9 mostra o método que gera as propriedades da conexão dinamicamente a partir das fontes de dados e a Figura 6.10 mostra o método que recupera os dados a partir da conexão gerada. Figura 6.9: Método que gerencia as conexões dinamicamente usando o Hibernate. Fonte: o autor Figura 6.10: Método que recupera os dados a partir de uma conexão

98 6.2. ADEQUAÇÃO DA IMPLEMENTAÇÃO AOS REQUISITOS 97 Para transformações dos dados, foram utilizadas algumas bibliotecas, como a biblioteca GSON 27 do Google para transformar os dados para JSON. Para transformar os dados em formato XML utlizamos a API do JDOM 28 e para o CSV foi desenvolvido um algoritmo que utiliza quebras de linhas e o ponto e vírgula como separador entre colunas. A Figura 6.11 mostra o método que transforma os dados no formato JSON e a Figura 6.12 mostra o método utilizado para salvar o arquivo no servidor. Figura 6.11: Método que converte os dados para JSON. Fonte: o autor Figura 6.12: Método que armazena o arquivo no servidor. Fonte: o autor

99 6.2. ADEQUAÇÃO DA IMPLEMENTAÇÃO AOS REQUISITOS 98 Vale salientar que para evitar o consumo excessivo de memória do servidor desprendido na conversão dos dados em formatos específicos, optamos por armazenar os dados nos três formatos logo após sua recuperação da fonte de dados de origem. Dessa forma, sempre que um conjunto de dados for recuperado, ainda que por vários consumidores ao mesmo tempo, apenas uma requisição HTTP será processada no servidor. Sendo este procedimento, portanto, uma decisão arquitetural para diminuir o consumo de memória Criação de Conjuntos de Dados Este Serviço permite que o produtor crie conjuntos de dados auto-descritivos. De modo geral, para a prova de conceito, é utilizado apenas um subconjunto do DCAT e DCMI para descrição sumária dos conjuntos de dados. No processo de criação, a solução permite que o produtor informe quais dados serão publicados a partir de uma fonte de dados previamente cadastrada. Na Figura 6.13 é apresentado o formulário de cadastro dos conjuntos de dados. Figura 6.13: Formulário de criação de conjunto de dados. Fonte: o autor

100 6.2. ADEQUAÇÃO DA IMPLEMENTAÇÃO AOS REQUISITOS 99 Dado a extração dos dados de forma automática pela solução, só é possível efetuar o cadastro do conjunto de dados se for possível executar a consulta informada, ou seja, o sistema se conecta a fonte de dados informada e processa a consulta para verificar se existe 1 ou mais dados. Se a quantidade de dados obtida a partir da execução da consulta de teste for maior que zero, o Collector inicia a recuperação dos dados e persiste no repositório de dados Gerenciamento de URIs No processo de criação do conjunto de dados, a aplicação Web realiza comunicação com o servidor para criar um identificador persistente para o conjunto de dados. Assim, é enviado o título do conjunto de dados e o sistema devolve o identificador a partir dele. Dessa forma, esse identificador é utilizado para gerar as URIs de acesso para cada conjunto de dados e seus respectivos itens, como distribuições e versões, tanto por meio da interface Web quanto por meio da API. A Figura 6.14 exemplifica o processo de criação de identificador automático. Figura 6.14: Exemplo de criação de identificador automático. Fonte: o autor Gerenciamento de Distribuições Para as distribuições, conforme informado anteriormente, por uma decisão arquitetural, optamos por gerar as distribuições logo após a recuperação dos dados e nos três formatos disponíveis. Com a estrutura adotada no desenvolvimento da prova de conceito, novos formatos podem ser facilmente adicionados e também é possível conceder a opção para o produtor selecionar os formatos desejados dentre os disponíveis. Na Figura 6.16 é possível visualizar as distribuições disponíveis após o cadastro de um conjunto de dados. Assim como os demais itens da interface, o acesso às distribuições também é gerado dinamicamente consumindo a API e verificando os formatos disponíveis.

101 6.2. ADEQUAÇÃO DA IMPLEMENTAÇÃO AOS REQUISITOS 100 Figura 6.15: Distribuições disponíveis. Fonte: o autor Gerenciamento de metadados Conforme descrito anteriormente e apresentado na Figura 6.13 (criação de conjunto de dados), nesta prova de conceito utilizamos um subconjunto de metadados do DCAT e DCMI. Este subconjunto compreende tanto metadados descritivos quanto metadados de licença, proveniência, cobertura e de atualização. Vale salientar que é necessário informar todos os metadados para realizar o cadastro de um conjunto de dados. Na Figura 6.16 são ilustrados os metadados armazenados no MongoDB e os metadados que são exibidos por meio da API, ambos no formato JSON. Figura 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 Gerenciamento de Versões Desenvolvemos um gerenciamento de versões automatizado que considera cada alteração em um conjunto de dados como uma nova versão do mesmo. Assim, tornou-se possível manter um histórico com todas as versões geradas do conjunto de dados, bem como possibilitar a recuperação dos dados das respectivas versões. Dado que o gerenciamento é automático, o sistema utiliza, como código indicador de versão, uma tag com um timestamp gerado a partir da data e hora do momento em que o conjunto

102 6.2. ADEQUAÇÃO DA IMPLEMENTAÇÃO AOS REQUISITOS 101 de dados foi alterado. Além disso, a menos que seja especificada uma versão, o sistema sempre retornará os dados mais recentes do conjunto de dados quando ele for referenciado. Ao acessar a descrição de um conjunto de dados via interface Web, o sistema lista todas as versões geradas, conforme pode ser visto na Figura Figura 6.17: Histórico das versões geradas de um conjunto de dados. Fonte: o autor Desejando recuperar os dados de alguma versão específica, é possível realizar filtros no histórico de versões acima e acessar a versão desejada clicando na descrição da versão. Dessa forma, o sistema vai permitir acesso a versão desejada, possibilitando visualizar os metadados da versão e recuperar os respectivos, conforme pode ser visto na Figura Figura 6.18: Acesso a uma versão específica de um conjunto de dados. Fonte: o autor Gerenciamento de Atualizações Este serviço garante que o conjunto de dados permanece atualizado de acordo com a frequência de atualização definida na criação do conjunto de dados. Para tanto, este serviço faz uso do agendador de tarefas do Spring, por meio da que permite especificar

103 6.2. ADEQUAÇÃO DA IMPLEMENTAÇÃO AOS REQUISITOS 102 quando um método deve ser executado dado uma configuração de data e hora. Assim, a foi utilizada com o padrão cron que permite especificar uma sequência de seis campos representando segundo, minuto, hora, dia, mês e dia da semana. Como uma hora é a menor unidade de tempo possível para a frequência de atualização, adotada nesta prova de conceito, configuramos o padrão do cron para ser executado todos os dias a cada uma hora. A Figura 6.19 ilustra o agendador de tarefas criado. Quando o método atualizardatasetsauto() é chamado, o sistema verifica cada conjunto de dados cadastrado e se é necessário atualizá-lo. Sendo necessário, os dados são extraídos, uma nova versão do conjunto de dados é gerada e os metadados são atualizados. Figura 6.19: Método que implementa o agendador de tarefas automático. Fonte: o autor Além da atualização automática dos conjuntos de dados a partir de sua frequência de atualização, também é possível efetuar a atualização manual. Assim, sendo necessário refletir alterações das fontes de dados no conjunto de dados publicado antes da atualização automática, o produtor pode acessar o conjunto de dados e informar que deseja processar uma atualização, conforme mostra a Figura Figura 6.20: Atualização manual (não programada) de um conjunto de dados. Fonte: o autor

104 6.2. ADEQUAÇÃO DA IMPLEMENTAÇÃO AOS REQUISITOS Gerenciamento de Acesso Nesta versão da solução, o serviço de gerenciamento de acesso permite que os dados armazenados no MongoDB sejam recuperados por meio de download em massa e por meio de APIs. Apesar de ainda não ser possível definir os subconjuntos de dados ao criar um conjunto de dados, é possível recuperar subconjuntos a partir da API, assim como utilizá-la para realizar o download dos dados no formato indicado. A interface Web do produtor e consumidor fornece links que permitem acessar os dados e metadados por meio da API de forma fácil. Com o uso deste serviço, sempre que o produtor realizar o cadastro de um conjunto de dados, o sistema automaticamente permitirá a recuperação deles por meio da API, assim como permitirá o download dos dados nos formatos configurados no sistema. A Figura 6.21 mostra tais opções a partir das interfaces Web. Figura 6.21: Métodos de acesso aos conjuntos de dados Também utilizamos o Spring para construir a API com os padrões arquiteturais REST. De modo geral, o Spring permite construir uma API usando a em uma classe Java, definindo os mapeamentos entre as rotas da API e ações, além do verbos HTTP necessários para processar as requisições. Figura 6.22: Exemplo de método e rota da API. Fonte: o autor A API AdminREST é acessível por < Uma vez que ela é voltada para atividades de cadastro e gerenciamento dos conjuntos de dados pelo produtor, para acessá-la é necessário fornecer um token que é obtido após o login. Conforme pode ser visto na Figura 6.22, o token deve ser enviado juntamente com os demais dados, ou seja, no exemplo ilustrado o token é enviado junto aos dados do novo conjunto de dados e o Spring se encarrega de mapeá-los na classe NovoDataset. Se o token informado for válido, o conjunto de

105 6.2. ADEQUAÇÃO DA IMPLEMENTAÇÃO AOS REQUISITOS 104 dados pode ser criado, caso não, um código HTTP 401 (acesso não autorizado) é retornado. A API OpenREST, acessível por < é aberta e não necessita de token. A documentação das APIs foi publicada em < sendo descrita dinamicamente com todas as rotas, métodos e as ações que cada rota e o método produz. As figuras 6.23 e 6.24 demonstram as rotas da API AdminREST e OpenREST, respectivamente. Figura 6.23: API AdminREST com os métodos, rotas e descrição, respectivamente. Fonte: o autor Figura 6.24: API OpenREST com os métodos, rotas e descrição, respectivamente. Fonte: o autor A documentação foi construída com o auxílio do Swagger 29 que é um framework de 29

106 6.2. ADEQUAÇÃO DA IMPLEMENTAÇÃO AOS REQUISITOS 105 código aberto criado para auxiliar a projetar, construir, documentar e consumir APIs. Além de usar o Swagger para documentar a API, também utilizamos para possibilitar a execução de testes de consumo. Assim, por meio da documentação, uma rota pode ser acessada e testes podem ser processados, como mostra a Figura Figura 6.25: Testes da API a partir da documentação. Fonte: o autor Por fim, acessando a URI < é possível obter metadados da API, incluindo sua versão. Para o desenvolvimento da API, assumimos como premissa que todas as alterações nas rotas, métodos ou ações devem ser encapsuladas em novas versões. Dessa forma, é previsto a manutenibilidade e preservação da API e, consequentemente, sem necessidade de alterações ou quebras dos consumidores que estiverem usando-a Interface Web Consumidor Os consumidores poderão acessar os conjuntos de dados por meio da URI < cloudapp.net/>. O desenvolvimento da Interface Web para o consumidor seguiu a mesma diretriz do desenvolvimento da Interface Web para o produtor, ou seja, com o uso das mesmas tecnologias e frameworks. Em síntese, para os consumidores é possível realizar filtros nos conjuntos de dados, efetuar download dos dados, acessar os dados e metadados por meio da API e acessar todas as versões dos conjuntos de dados. A Figura 6.26 exibe a tela principal da Interface Web para os consumidores.

107 6.3. CONCLUSÃO 106 Figura 6.26: Tela principal da Interface Web para os consumidores. Fonte: o autor 6.3 Conclusão Este Capítulo teve por objetivo mostrar que é possível desenvolver uma solução que gerencie adequadamente os conjuntos de dados na Web, ou seja, por meio da prova de conceito implementada mostramos que é possível implementar a arquitetura proposta no Capítulo anterior. Dessa forma, como resultado da prova de conceito, desenvolvemos o SGDW-v01 que permite atender, por meio de um conjunto de serviços, os requisitos listados no modelo de arquitetura proposto. A seguir, no Quadro 6.1, são elencados os serviços do SGDW-v01 e quais os requisitos ao qual cada um deles está relacionado. Dos requisitos elencados, três não foram atendidos em nossa prova de conceito, sendo o requisito de prover mecanismos para a criação de canais de comunicação entre os produtores e consumidores, garantir a preservação dos conjuntos de dados ao longo do tempo e o gerenciamento de metadados. Consideramos que o requisito de gerenciamento de metadados não foi atendido na prova de conceito uma vez que ele não foi encapsulado como um serviço e ainda não é apoiado por um processo de curadoria. Dessa forma, quando um serviço precisa criar, usar ou atualizar metadados, ele realiza todos os procedimentos diretamente no repositório de dados. Alguns serviços atendem parcialmente os requisitos, uma vez que nem todas as características necessárias para o requisito foram atendidas. Assim, o Serviço de Criação de Conjuntos de Dados não atende completamente ao requisito correspondente pois não permite a especificação de subconjuntos de dados. O Serviço de Collector só foi implementado para fontes de dados relacionais, não considerando as fontes de dados não relacionais e os dados presentes em arquivos, por exemplo. Somado a isso, o Serviço de Gerenciamento de Versões só considera as atualizações nos dados e não é gerado uma versão para atualizações nos metadados, ainda que em nossa prova de conceito os metadados só são atualizados quando os dados são atualizados. Com a prova de conceito foi possível estabelecer formatos padrões para gerar as distri-