Lairson Emanuel R. de Alencar Oliveira - repositorio.ufpe.br · Nosso casamento foi ... nos afastar de nosso Pai Celestial e se tornou um grande amigo. Marcelo, o Grande Marcelo,

Lairson Emanuel R. de Alencar Oliveira

UM MODELO DE ARQUITETURA PARA SISTEMAS

GERENCIADORES DE DADOS NA WEB

Universidade Federal de [email protected]

<www.cin.ufpe.br/~posgraduacao>

RECIFE2017

www.cin.ufpe.br/~posgraduacao

Lairson Emanuel R. de Alencar Oliveira

UM MODELO DE ARQUITETURA PARA SISTEMASGERENCIADORES DE DADOS NA WEB

Trabalho apresentado ao Programa de Pós-graduação em

Ciência da Computação do Centro de Informática da Univer-

sidade Federal de Pernambuco como requisito parcial para

obtenção do grau de Mestre em Ciência da Computação.

Orientadora: Profa. Dra. Bernadette Farias Lóscio

RECIFE2017

Catalogação na fonte

Bibliotecária Monick Raquel Silvestre da S. Portes, CRB4-1217

O48m Oliveira, Lairson Emanuel Rodrigues de Alencar

Um modelo de arquitetura para sistemas gerenciadores de dados na Web / Lairson Emanuel Rodrigues de Alencar Oliveira. – 2017.

113 f.: il., fig. Orientadora: Bernadette Farias Lóscio. Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn,

Ciência da Computação, Recife, 2017. Inclui referências.

1. Banco de dados. 2. Web semântica. I. Lóscio, Bernadette Farias (orientadora). II. Título. 025.74 CDD (23. ed.) UFPE- MEI 2017-100

Lairson Emanuel Rodrigues de Alencar Oliveira

UM MODELO DE ARQUITETURA PARA

SISTEMASGERENCIADORES DE DADOS NA WEB

Dissertação de Mestrado apresentada ao

Programa de Pós-Graduação em Ciência da

Computação da Universidade Federal de

Pernambuco, como requisito parcial para a

obtenção do título de Mestre em Ciência da

Computação

Aprovado em: 03/03/2017.

BANCA EXAMINADORA

______________________________________________

Prof. Dr. Luciano de Andrade Barbosa

Centro de Informática / UFPE

__________________________________________

Prof. Dr. Ig Ibert Bittencourt Santana Pinto

Instituto de Computação/UFAL

__________________________________________

Profa. Dra. Bernadette Farias Lóscio

Centro de Informática / UFPE (Orientadora)

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.

Agradecimentos

Agradeço, primeiramente, ao meu bom Deus que me concedeu capacidade para chegaraté aqui.

Durante o término de minha graduação em Bach. Sistemas de Informação na UFPE, nãopensava em continuar estudando e fazer pós-graduações. Afinal, eu já estava há nove anos noensino superior e antes de ingressar em SI, já tinha passado, ininterruptamente, por outras 2graduações (que não concluí). De nove anos no ensino superior, os últimos oito eu já trabalhavae, 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 trabalhode graduação que minha antiga paixão reascendeu. Estava diante de uma profissional que, logoapós, veio a se tornar minha referência na profissão, uma professora muito inteligente, que medirecionou, 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, aindanão tinha "caído minha ficha". Mas, em oração a Deus, pude perceber que tudo que estavaacontecendo não era fruto de um projeto meu (uma vez que eu não queria mais continuarestudando). Minha certeza veio em dezembro de 2014 com a aprovação na seleção do mestradoe em cada reunião, troca de email, whatsapp, ligação, conversas e confraternizações que tive comela. Hoje, apesar de não abandonar o "professora"e "sra", agradeço imensamente a Berna, quealé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 todonosso relacionamento que meus maiores sonhos até hoje se concretizaram. Nosso casamento foirealizado 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, desdecada 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 saberda 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 queajudaram 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 nuncanos 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 Wilkerpela grande ajuda durante a realização deste trabalho.

Agradeço a todos da minha família que me apoiaram e ajudaram a construir a pessoaque sou hoje. Obrigado Mainha (Edinete Alencar), Painho (Wilson Oliveira), Lopinho (AntônioLopes), Lalá (Larissa Alencar), Tatá (Thaissa Alencar), Lulinho (Yuri Alencar), Aninha (AnaMaria), Lidinha (Ana Lídia), Júlio (Cunhado) e, em especial, a meu sobrinho Miguel Ângeloque mesmo eu ficando um pouco longe nesse momento, cada vez que o vi minhas forças foramrenovadas com abraços carinhosos e um "Titio"que encheram meu coração de alegria! Muitoobrigado 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 Pernam-buco (FACEPE) pelo financiamento, na qual possibilitou a realização deste trabalho.

Suba o primeiro degrau com fé.

Você não tem que ver toda a escada.

Você só precisa dar o primeiro passo.

— MARTIN LUTHER KING JR

Resumo

A grande quantidade de dados disponível na Web, juntamente com a facilidade deacesso e representação desses dados, criam novos desafios tanto para quem deseja publicar ecompartilhar dados na Web quanto para os que desejam usar tais dados. De modo geral, nãoexiste 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, recentementefoi proposta, pelo W3C, uma recomendação para Dados na Web, que busca um entendimentocomum entre os produtores e os consumidores e discursa sobre diferentes aspectos relacionadosao compartilhamento de dados na Web, como formatos de dados, acesso, identificadores emetadados. Ao longo dos anos, várias soluções foram desenvolvidas objetivando a publicaçãoe o compartilhamento desses dados na Web. No entanto, as soluções de publicação de dadosatuais, que são responsáveis por prover catálogos de dados e manter a interface de comunicaçãoentre os produtores e consumidores, não implementam boa parte das orientações propostaspelo W3C como boas práticas. Dado que existe uma carência de soluções que possibilitem ogerenciamento adequado dos dados compartilhados na Web, esta dissertação tem como principalobjetivo 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 atenderpara prover soluções para as limitações encontradas. Além disso, é proposta uma coleção deserviços que visam facilitar a definição, criação, manutenção, manipulação e compartilhamentodos 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

Abstract

The large amount of data available on the Web along with the ease access and repre-sentation of these data create new challenges for those who wish to share data on the Web. Ingeneral, there is no prior knowledge between the interests of who share the data, called dataproducers, and the interests of who use, called data consumers. In this context, W3C proposeda recommendation, called Data on the Web Best Practices (DWBP), that aims a common un-derstanding between data producers and data consumers. The DWBP deals with several aspectsrelated 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 publishingand sharing data on the Web. However, current data publishing solutions, which are responsiblefor providing data catalogs and maintaining the communication interface between data producersand data consumers, do not implement much of the guidelines proposed by the DWBP. Giventhe lack of solutions that allow the management of shared data on the Web, this work has asmain 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 thelimitations of existing solutions. In addition, we developed a proof of concept and we propose acollection of services that aim to facilitate the definition, creation, maintenance, manipulationand sharing of datasets on the Web among users and applications.

Keywords: Data Catalog. Best Practices. Data on the Web. DWMS. Services

Lista de Figuras

2.1 Comparação entre a publicação de dados na Web e a abordagem de bancos de dadosconvencionais. Fonte: (LÓSCIO; OLIVEIRA; BITTENCOURT, 2015) . . . . . . 22

2.2 Evolução da Web 1.0 para Web 3.0. Fonte: (DWIVEDI et al., 2011) . . . . . . . . 242.3 Contexto de Publicação dos Dados na Web. Fonte: (LÓSCIO; BURLE; CALEGARI,

2016a) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.4 Esquema de 5 estrelas para os Dados Abertos. Fonte: http://5stardata.info/en/ . . . 262.5 Dados na Web x Open Data x Linked Data. Fonte: (LÓSCIO; BURLE; CALEGARI,

2016b) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.6 Ciclo de Vida dos Dados na Web proposto por Lóscio, Oliveira e Bittencourt (2015).

Fonte: (LÓSCIO; OLIVEIRA; BITTENCOURT, 2015) . . . . . . . . . . . . . . . 292.7 Ciclo de Vida dos Dados na Web proposto pelo autor. Fonte: o autor . . . . . . . . 30

3.1 Arquitetura do CKAN. Fonte: <http://docs.ckan.org/en/latest/contributing/architecture.html> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.2 Visão geral do processo de Publicação no Junar. Fonte: <http://junar-cdn-brandings.s3.amazonaws.com/ebook/Overview-Junar-Open-Data-Portal-for-IT-Professionals-N0511.pdf> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.3 Exemplo de publicação de dados no Junar. Fonte: <http://junar-cdn-brandings.s3.amazonaws.com/ebook/Overview-Junar-Open-Data-Portal-for-IT-Professionals-N0511.pdf> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.4 Arquitetura do Socrata. Fonte: <http://open-source.socrata.com/architecture/>. . . 373.5 Arquitetura do OpenDataSoft. Fonte: <https://docs.opendatasoft.com/en/about.html>. 383.6 Arquitetura do ArcGis Open Data. Fonte: <https://blogs.esri.com/esri/arcgis/2015/

09/02/architecture-of-open-data/>. . . . . . . . . . . . . . . . . . . . . . . . . . . 393.7 Visão adaptada da arquitetura do DKAN. Fonte: <http://www.slideshare.net/DavidPortnoy/

ddod-the-lean-startup-approach-to-open-data> (adaptado pelo autor). . . . . . . . 40

4.1 Fases de um Conjunto de Dados. Fonte: o autor . . . . . . . . . . . . . . . . . . . 53

5.1 Modelo de Arquitetura para um SGDW. Fonte: o autor . . . . . . . . . . . . . . . 675.2 Fluxo de Atividades para o Serviço de Extração e Transformação de Dados. Fonte:

o autor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.3 Fluxo de Atividades para o Serviço de Criação de Conjuntos de Dados. Fonte: o autor 715.4 Fluxo de Atividades para o Serviço de Gerenciamento de Metadados. Fonte: o autor 735.5 Fluxo de Atividades para o Serviço de Gerenciamento de Versões. Fonte: o autor . 755.6 Consumo das versões dos conjuntos de dados. Fonte: o autor . . . . . . . . . . . . 76

http://docs.ckan.org/en/latest/contributing/architecture.html


http://junar-cdn-brandings.s3.amazonaws.com/ebook/Overview-Junar-Open-Data-Portal-for-IT-Professionals-N0511.pdf






http://open-source.socrata.com/architecture/

https://docs.opendatasoft.com/en/about.html

https://blogs.esri.com/esri/arcgis/2015/09/02/architecture-of-open-data/


http://www.slideshare.net/DavidPortnoy/ddod-the-lean-startup-approach-to-open-data


5.7 Fluxo de Atividades para o Serviço de Gerenciamento de Atualizações. Fonte: o autor 775.8 Fluxo de Atividades para o Serviço de Gerenciamento de Acesso. Fonte: o autor . . 795.9 Fluxo de Atividades para o Serviço de Preservação de Conjuntos de Dados. Fonte: o

autor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805.10 Fluxo de Atividades para o Serviço Gerenciamento do Uso dos Dados. Fonte: o autor 81

6.1 Arquitetura da Prova de Conceito (SGDW-v01). Fonte: o autor . . . . . . . . . . . 866.2 Arquitetura do Angular (a) e Estrutura de pastas do projeto da Interface Web do

produtor (b). Fonte: o autor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 896.3 Principais Casos de Uso da Solução. Fonte: o autor . . . . . . . . . . . . . . . . . 906.4 Tela de login do sistema do produtor. Fonte: o autor . . . . . . . . . . . . . . . . . 926.5 Token salvo na Session Storage (a) e Token gerado após simular uma requisição a

API (b). Fonte: o autor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 936.6 Cadastro de fonte de dados. Fonte: o autor . . . . . . . . . . . . . . . . . . . . . . 946.7 Tipos de SGBDs recebidos por meio da API. Fonte: o autor . . . . . . . . . . . . . 956.8 Processo de extração de dados implementado na Prova de Conceito. Fonte: o autor 956.9 Método que gerencia as conexões dinamicamente usando o Hibernate. Fonte: o autor 966.10 Método que recupera os dados a partir de uma conexão . . . . . . . . . . . . . . . 966.11 Método que converte os dados para JSON. Fonte: o autor . . . . . . . . . . . . . . 976.12 Método que armazena o arquivo no servidor. Fonte: o autor . . . . . . . . . . . . . 976.13 Formulário de criação de conjunto de dados. Fonte: o autor . . . . . . . . . . . . . 986.14 Exemplo de criação de identificador automático. Fonte: o autor . . . . . . . . . . . 996.15 Distribuições disponíveis. Fonte: o autor . . . . . . . . . . . . . . . . . . . . . . . 1006.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 . . . . . . . . 1006.17 Histórico das versões geradas de um conjunto de dados. Fonte: o autor . . . . . . . 1016.18 Acesso a uma versão específica de um conjunto de dados. Fonte: o autor . . . . . . 1016.19 Método que implementa o agendador de tarefas automático. Fonte: o autor . . . . . 1026.20 Atualização manual (não programada) de um conjunto de dados. Fonte: o autor . . 1026.21 Métodos de acesso aos conjuntos de dados . . . . . . . . . . . . . . . . . . . . . . 1036.22 Exemplo de método e rota da API. Fonte: o autor . . . . . . . . . . . . . . . . . . 1036.23 API AdminREST com os métodos, rotas e descrição, respectivamente. Fonte: o autor 1046.24 API OpenREST com os métodos, rotas e descrição, respectivamente. Fonte: o autor 1046.25 Testes da API a partir da documentação. Fonte: o autor . . . . . . . . . . . . . . . 1056.26 Tela principal da Interface Web para os consumidores. Fonte: o autor . . . . . . . . 106

Lista de Quadros

3.1 Desafios na publicação de dados na Web. . . . . . . . . . . . . . . . . . . . . . . . 423.2 Boas práticas para dados na Web. . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.3 Catálogos de Dados X Boas Práticas . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.1 Soluções Atuais X Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.1 Premissas e Requisitos para o compartilhamento de dados x Serviços do modelo dearquitetura proposto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

6.1 Serviços da Prova de Conceito x Requisitos de um SGDW . . . . . . . . . . . . . . 107

Lista de Acrônimos

WWW World Wide Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

SGDW Sistema Gerenciador de Dados na Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

API Application Programming Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

SBD Sistemas de Bancos de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

SQL Structured Query Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

HTTP Hypertext Transfer Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

ACID Atomicidade, Consistência, Isolamento e Durabilidade . . . . . . . . . . . . . . . . . . . . . 22

BASE Basically Available, Soft State, and Eventual Consistency . . . . . . . . . . . . . . . . . . 22

SPARQL SPARQL Protocol and RDF Query Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

RDF Resource Description Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

URI Universal Resource Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

ADLM Abstract Data Lifecycle Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

URL Uniform Resource Locator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

SaaS Software como Serviço . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

SoQL SODA Query Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

SGBD Sistema Gerenciador de Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

DWBP Data on the Web Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

REST Representational State Transfer (REST) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

DUV Dataset Usage Vocabulary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

WAR Web application ARchive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

SPA Single Page Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88

JS JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

CSS Cascading Style Sheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

IIS Internet Information Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

JDBC Java Database Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Sumário

1 Introdução 161.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.2 Caracterização do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . 181.3 Objetivos e Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.4 Estrutura da dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2 Fundamentação Teórica 212.1 Bancos de Dados Convencionais X Dados na Web . . . . . . . . . . . . . . . 212.2 Ecossistemas de dados na Web . . . . . . . . . . . . . . . . . . . . . . . . . . 232.3 Dados na Web x Dados Abertos x Dados Conectados . . . . . . . . . . . . . 262.4 Ciclo de Vida dos Dados na Web . . . . . . . . . . . . . . . . . . . . . . . . . 28

3 Publicação de Dados na Web 333.1 Soluções para Catalogação de Dados . . . . . . . . . . . . . . . . . . . . . . 333.1.1 CKAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.1.2 Junar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.1.3 Socrata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.1.4 OpenDataSoft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.1.5 ArcGIS Open Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.1.6 DKAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.2 Boas Práticas para Dados na Web . . . . . . . . . . . . . . . . . . . . . . . . 413.3 Soluções de Catalogação de dados X Boas Práticas . . . . . . . . . . . . . . . 48

4 Compartilhamento de Dados na Web 524.1 Conceitos básicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.2 Premissas do compartilhamento de Dados na Web . . . . . . . . . . . . . . . 544.3 Requisitos para as soluções de compartilhamento de Dados na Web . . . . . 554.3.1 Requisitos da Premissa 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.3.2 Requisitos da Premissa 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.3.3 Requisitos da Premissa 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.3.4 Requisitos da Premissa 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.4 Análise das soluções existentes de acordo com os requisitos . . . . . . . . . . 62

5 Sistemas Gerenciadores de Dados na Web - SGDW 665.1 Visão geral de um SGDW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.1.1 Camada de Acesso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.1.2 Camada de Serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685.1.3 Camada de Dados e Metadados . . . . . . . . . . . . . . . . . . . . . . . . . 685.2 Detalhamento da Camada de Serviços . . . . . . . . . . . . . . . . . . . . . . 695.2.1 Extração e Transformação dos Dados . . . . . . . . . . . . . . . . . . . . . . 705.2.2 Criação de conjuntos de dados . . . . . . . . . . . . . . . . . . . . . . . . . . 705.2.3 Gerenciamento de Metadados . . . . . . . . . . . . . . . . . . . . . . . . . . 725.2.4 Gerenciamento de Versões . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.2.5 Gerenciamento de Atualização . . . . . . . . . . . . . . . . . . . . . . . . . . 775.2.6 Gerenciamento de Acesso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785.2.7 Preservação dos Conjuntos de dados . . . . . . . . . . . . . . . . . . . . . . 805.2.8 Gerenciamento do Uso dos Dados . . . . . . . . . . . . . . . . . . . . . . . . 815.3 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

6 Prova de conceito do Modelo de Arquitetura para um SGDW 856.1 Visão geral da implementação . . . . . . . . . . . . . . . . . . . . . . . . . . 856.1.1 Arquitetura e tecnologias de implementação . . . . . . . . . . . . . . . . . . 856.1.2 Funcionalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906.1.3 Implantação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916.2 Adequação da Implementação aos Requisitos . . . . . . . . . . . . . . . . . 926.2.1 Collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 936.2.1.1 Cadastro de Fonte de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . 936.2.1.2 Extração e Transformação de Dados . . . . . . . . . . . . . . . . . . . . . . 956.2.2 Criação de Conjuntos de Dados . . . . . . . . . . . . . . . . . . . . . . . . . 986.2.2.1 Gerenciamento de URIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996.2.2.2 Gerenciamento de Distribuições . . . . . . . . . . . . . . . . . . . . . . . . . 996.2.3 Gerenciamento de metadados . . . . . . . . . . . . . . . . . . . . . . . . . . 1006.2.4 Gerenciamento de Versões . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006.2.5 Gerenciamento de Atualizações . . . . . . . . . . . . . . . . . . . . . . . . . 1016.2.6 Gerenciamento de Acesso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1036.2.7 Interface Web Consumidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1056.3 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

7 Conclusão 1087.1 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1087.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Referências 111

161616

1Introduçã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çãode dados na Web, somado a ferramentas que permitem essa publicação, contudo existem lacunasno gerenciamento adequado desses dados, considerando aspectos descritos na recomendaçãode 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 doproblema é descrita na Seção 1.2 e os objetivos são apresentados na Seção 1.3. Por fim, a Seção1.4 é apresenta a estrutura desta dissertação.

1.1 Motivação

Desde o seu surgimento, a World Wide Web (WWW), ou apenas Web, teve muitoprogresso e tem se destacado como o principal meio pelo qual usuários podem publicar, consumire compartilhar dados. O potencial da Web como plataforma para troca e compartilhamento dedados vem se intensificando, tanto pelo crescimento da publicação online de dados abertos emtodo o mundo, quanto pela crescente publicação de dados de pesquisas, pelo grande volume dedados 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 seusucesso como plataforma de compartilhamento de dados.

A origem da Web, considerada como Web 1.0, possibilitou a publicação, propagação evisibilidade dos conteúdos. Nela, poucos produtores criavam páginas interligadas e um grandenúmero de clientes acessavam essas páginas através da Internet. Assim, os usuários só podiamler 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 permitindouma participação efetiva dos usuários. Dessa forma, além de ler os conteúdos, também foipermitido aos usuários escrever, modificar e atualizar os conteúdos na Web, oferecendo suportepara colaboração. Além disso, com o avanço da tecnologia, os dados produzidos pela sociedade

1.1. MOTIVAÇÃO 17

e disponibilizados na Web vêm crescendo rapidamente e novos termos estão sendo fomentados,como a Web 3.0 e a Web 4.0 (NATH; ISWARY, 2015).

O relatório da EMC em 2014 1, que fez uma medição dos dados criados, replicadose consumidos no respectivo ano, apontou que os dados estão dobrando de tamanho a cada 2anos e estimou que até 2020 chegarão a 44 zettabytes. Contudo, grande parte desses dados nãoestão disponíveis ao público, ou não estão estruturados para facilitar a compreensão por aquelesque 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 serobtido 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 descobertade dados de forma rápida, estimulando a interação entre todos os envolvidos, assim como autilizaçã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 agentesenvolvidos 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 dadosque 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 aosconjuntos de dados tornam o processo de publicação, compartilhamento e consumo de dadosuma tarefa complexa(LÓSCIO; OLIVEIRA; BITTENCOURT, 2015). Dessa forma, é necessáriobuscar alternativas que possibilitem um entendimento comum entre os atores e promovam umamaior confiança nos dados para que os esforços dos produtores não se tornem incompatíveiscom os desejos dos consumidores de dados (LÓSCIO; BURLE; CALEGARI, 2016b).

Na busca por esse entendimento comum, o W3C publicou recentemente um documentoque estabelece boas práticas para a publicação e o consumo de dados na Web, sendo independentede domínio e de aplicação. Em outras palavras, ele é aplicável a todos os domínios, podendoainda ser estendido ou complementado por outros documentos ou normas mais especializadas.O Data on the Web Best Practices (DWBP) discursa sobre diferentes aspectos relacionadosa publicação e consumo de dados, como formatos de dados, acesso a dados, identificadoresde dados e metadados, por meio das suas 35 boas práticas. Ao seguir as boas práticas, umasé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, quaisos passos, do ponto de vista técnico, que devem ser seguidos e implementados até os dadosserem publicados.

Contudo, ainda se constitui um grande desafio a publicação de dados na Web guiada porpráticas que facilitem a compreensão, descoberta e uso dos dados. Dessa forma, neste trabalho

1http://www.emc.com/leadership/digital-universe/index.htm

1.2. CARACTERIZAÇÃO DO PROBLEMA 18

abordamos o desenvolvimento de uma solução que permita o gerenciamento de conjuntos dedados, forneça ferramentas para os atores do Ecossistema de Dados na Web e faça uso das boasprá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 odesenvolvimento de soluções para publicação de dados, como as ferramentas de catalogaçãoCKAN2, Socrata3, Junar4, OpenDataSoft5 e ArcGIS Open Data6. Porém, por não existir umframework ou metodologias padronizadas para o desenvolvimento desses softwares, não existeuma homogeneidade na publicação dos dados.

Além disso, apesar da ampla utilização, essas soluções não oferecem mecanismos para ogerenciamento adequado dos conjuntos de dados. Como limitações dessas soluções, podemosdestacar a falta de mecanismos que possibilitem o gerenciamento de versões, atualização auto-mática dos conjuntos de dados com frequências de atualização pré-definidas, gerenciamento defeedback e gerenciamento da proveniência dos conjuntos de dados.

Além dessas limitações, Oliveira et al. (2016) apontou, em um estudo realizado comos portais de dados abertos brasileiros, que na maioria dos conjuntos de dados avaliados nãoforam disponibilizados metadados adequados ou suficientes para a descrição dos conjuntos dedados. Os metadados são importantes uma vez que ajuda os consumidores a compreenderem osignificado 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)dadosafeta a descoberta e o consumo do conjunto de dados, ou seja, afeta diretamente os serviços depesquisa e descoberta para que os consumidores localizem os conjuntos de dados relevantes erelacionados para suas necessidades.

Somado a isso, também foi constatado que uma grande parcela dos dados foi publicadaem formatos de dados proprietários ou não estruturados (OLIVEIRA et al., 2016), não abordandoadequadamente 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 conjuntosde 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 seriamatualizados, 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 surgirama partir da Web 2.0, nenhum dos portais analisados forneceram mecanismos para coletar feedback

2http://ckan.org/3https://socrata.com/4http://junar.com/5https://www.opendatasoft.com/6http://opendata.arcgis.com/

1.3. OBJETIVOS E CONTRIBUIÇÕES 19

dos consumidores de dados. Segundo Lóscio, Burle e Calegari (2016a), o feedback tem benefíciostanto para os produtores quanto para os consumidores de dados, contribuindo para melhorar aintegridade dos dados publicados, bem como para incentivar a publicação de novos dados. Porfim, também foi constatado que mesmo dentro de um determinado portal, não há padronizaçãona publicação dos conjuntos de dados. Dessa forma, a falta de padronização e ausência demetadados, dificultam o consumo dos dados.

Em um outro estudo realizado por Umbrich, Neumaier e Polleres (2015), ao analisar82 portais de dados abertos, constataram que até mesmo para um mesmo formato de dadosnão é seguido um padrão na publicação. Ou seja, devido a falta de padrões para descrever osformatos de dados, um arquivo CSV pode ser publicado com os valores separados por vírgulaspor 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 queos dados sejam usados e os desenvolvedores criem aplicativos com menos esforço.

Nesse contexto, constatamos que existem diversas limitações e lacunas com o comparti-lhamento de dados na Web. Além disso, existe uma carência de ferramentas que possibilitem ogerenciamento adequado desses dados, oferecendo soluções para o gerenciamento de versões e apreservação dos conjuntos de dados, por exemplo.

Assim, surge a necessidade de uma solução que supra necessidades de produtores econsumidores de dados, padronizando serviços e provendo soluções para as limitações mencio-nadas anteriormente. De maneira geral, torna-se necessário o desenvolvimento de soluções quepreencham 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 arquiteturapara um Sistema Gerenciador de Dados na Web (SGDW). O modelo proposto leva em conside-ração os principais requisitos e funcionalidades que um sistema deste tipo deve atender a fim deprover 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 asferramentas utilizadas para publicação de dados;

� Identificar os requisitos e funcionalidades que possibilitem o gerenciamento adequadodos conjuntos de dados compartilhados na Web;

� Especificar um modelo de arquitetura para o SGDW para que atenda o adequadogerenciamento dos conjuntos de dados na Web;

1.4. ESTRUTURA DA DISSERTAÇÃO 20

1.4 Estrutura da dissertação

Os próximos capítulos estão organizados como se segue. No Capítulo 2, é apresentadoa fundamentação teórica deste trabalho. Já no Capítulo 3, abordamos aspectos relacionados apublicação de dados na Web, como as características das principais soluções atuais. No Capítulo4, apresentamos as premissas e requisitos necessários para as soluções de compartilhamento deDados na Web. O Capítulo 5 apresenta o modelo de arquitetura proposto para o SGDW, enquantoo Capítulo 6 apresenta os detalhes da prova de conceito realizada. Por fim, no Capítulo 7 é feitouma pequena discussão sobre o trabalho realizado e sugestões para os trabalhos futuros.

212121

2Fundamentaçã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 dadosna 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. Porfim, na Seção 2.4 discorremos sobre o ciclo de vida de dados na Web, descrevendo suas etapas erelacionamentos.

2.1 Bancos de Dados Convencionais X Dados na Web

Lóscio, Oliveira e Bittencourt (2015) apontam que, assim como a Web, os Sistemasde Bancos de Dados (SBD) também são caracterizados como plataformas para publicação econsumo de dados, permitindo o compartilhamento de dados por meio de funcionalidades comorecuperação de dados, suporte a acesso concorrente e simultâneo. Já a publicação de dadosna Web, dado a sua flexibilidade, possibilita a publicação e o consumo de maneira bastantesimples, sem a necessidade de sistemas para controlar o acesso concorrente aos dados, porexemplo. Dessa forma, apesar de ambas soluções apresentarem funcionalidades similares quantoa mecanismos de armazenamento e compartilhamento, existem diferenças significativas quanto afacilidade de publicação e consumo de dados, como as que são apresentadas na Figura 2.1.

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 bancosde dados convencionais. Fonte: (LÓSCIO; OLIVEIRA; BITTENCOURT, 2015)

Podemos destacar a descrição e utilização de esquemas, mecanismos de acessos econtrole de concorrência como as principais diferenças entre as soluções. Se de um lado os SBDsgeralmente 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êmcomo característica a ausência completa ou parcial de um esquema que defina a estrutura dosdados a serem armazenados (LÓSCIO; OLIVEIRA; BITTENCOURT, 2015). Assim, facilitandoo processo de publicação de dados e tornando o processo de consumo mais complexo. Dessaforma, torna-se necessário deixar a semântica dos dados explícita, uma vez que não é possívelprever todos os usuários ou aplicações que farão uso dos dados, diferentemente de quando umbanco 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 delinguagens 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 tiposde consultas podem ser realizadas, como consultas por junção, agregação, faixa de valores emú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 linguagemSPARQL Protocol and RDF Query Language (SPARQL), podendo realizar junções e consultaspor múltiplos atributos (LÓSCIO; OLIVEIRA; BITTENCOURT, 2015).

Também existem diferenças relacionadas à execução das transações. Os SBDs sãobaseados 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ãosendo interferida por nenhuma outra transação concorrente e que os dados serão persistidos no

2.2. ECOSSISTEMAS DE DADOS NA WEB 23

banco (ELMASRI; NAVATHE, 2010). Já as propriedades BASE, caracterizam-se por proverum modelo de consistência mais fraco, no qual o sistema permanece disponível, mesmo queparcialmente ocorram falhas (PRITCHETT, 2008). Somado a isso, enquanto que em SBDsa escalabilidade é uma tarefa não trivial, dado a técnicas de controle de concorrências e usomodelos de consistência mais rigorosos, o ambiente da Web permite alcançar escalabilidade deforma mais fácil (LÓSCIO; OLIVEIRA; BITTENCOURT, 2015).

Existem, portanto, diferenças significativas entre a publicação de dados na Web e aabordagem de bancos de dados convencionais. A Web, de forma geral, oferece funcionalidadeseficientes 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 é desuma importância a análise mais detalhada para entendimento deste trabalho. Dessa forma, naspró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 passapor 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çãoe visibilidade de conteúdos como sites corporativos e institucionais. Ficou conhecida comoWeb 1.0 e seu acesso se dava de modo unidirecional, ou seja, uma pequena quantidade deprodutores criavam páginas e um grande número de clientes acessam essas páginas através daInternet (NATH; ISWARY, 2015). Nath, Dhar e Basishtha (2014) acrescenta que como a Web1.0 permitia somente leitura, ela ignorou o conceito que quanto maior o número de pessoasusando um serviço em rede, então o serviço se torna mais útil para cada um usando essa rede.

Assim, com o seu rápido crescimento, a Web possibilitou novos meios para uma parti-cipação efetiva dos usuários. Com a Web 2.0, o usuário passou a não apenas ler os conteúdos,mas também escrever, modificar e atualizar os conteúdos na Internet, oferecendo suporte paracolaboração (HIREMATH; KENCHAKKANAVAR, 2016). Com o avanço da tecnologia, osdados produzidos pela sociedade e disponibilizados na Web continuam crescendo rapidamente enovos termos estão sendo fomentados, como a Web 3.0 e a Web 4.0 (NATH; ISWARY, 2015). Se-gundo Rudman e Bruwer (2016), a Web 3.0 já está em andamento e implica em uma experiênciaintegrada, em que a máquina será capaz de compreender e catalogar dados de maneira semelhanteaos 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 humanostrabalhem 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 ouhistóricos, para propor ou suportar a tomada de decisão (NATH; ISWARY, 2015).

Dessa forma, a Web vem passando por transformações ao longo dos anos, tanto acom-panhada pelo avanço da tecnologia, quanto por novas demandas, e conta com uma grande e


crescente quantidade de dados disponíveis. Porém, Isotani e Bittencourt (2015) aponta que mui-tos dados não estão disponíveis ao público ou não estão estruturados para facilitar a compreensãopor 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 adescoberta de dados de forma rápida, estimulando a interação entre todos os envolvidos, assimcomo 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éisjuntamente 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 en-volvidos na produção, distribuição e consumo de dados por meio da Web (LÓSCIO; BURLE;CALEGARI, 2016a). Em outros palavras, esse conjunto é formado por uma coleção de conjuntosde dados, por atores que interagem entre si por meio do fornecimento e do uso desses conjuntosde dados e pelo conjunto de ferramentas necessárias para garantir o bom funcionamento doecossistema. Assim, os agentes podem ser tanto usuários, quanto sistemas ou dispositivos, po-dendo atuar como produtor e consumidor de conjuntos de dados. O produtor objetiva a produçãoe o compartilhamento de dados de algum tipo e com condições específicas. Por sua vez, osconsumidores (que também podem ser eles mesmos provedores) consomem esses dados sob con-dições específicas ao longo de um intervalo de tempo (LÓSCIO; OLIVEIRA; BITTENCOURT,2015). Ambos os atores interagem uns com os outros através dos datasets que são definidos porMaali, 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ãodefinidos por Elmasri e Navathe (2010) como "fatos conhecidos que podem ser registrados epossuem significado implícito".

Nesse contexto, podemos identificar atividades voltadas aos produtores e aos consumi-dores de dados. Do lado dos produtores, podemos citar atividades relacionadas à publicação,como a definição de licenças, escolha dos formatos e plataformas para distribuição, somadoao conjunto obrigatório de metadados. Para os consumidores, podemos identificar pessoasinteressadas no consumo direto dos dados, bem como outras que têm interesse em transformaros dados, agregando algum valor, para a geração de informações úteis e relevantes, assim como


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çõesou manutenção de integridade dos dados. Em contraste a tal facilidade, porém, se faz necessáriodesenvolver soluções que possibilitem o consumo de dados por grupos de usuários previamentedesconhecidos e com diferentes requisitos (LÓSCIO; OLIVEIRA; BITTENCOURT, 2015). AFigura 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 diferentesdistribuiçõ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 gruposde consumidores de dados e contribui com atividades de pré-processamento dos dados, comoa desnecessidade de conversão de dados. Dado que os consumidores e produtores podem serdesconhecidos entre si, é necessário fornecer informações sobre os conjuntos de dados e distri-buições que podem contribuir para a confiabilidade e reutilização dos dados, ou seja, fornecermetadados sejam eles descritivos, de acesso, qualidade, proveniência, licença e informações deuso (LÓSCIO; BURLE; CALEGARI, 2016a).

Além disso, por meio da Figura 2.3 percebemos que também é importante seguir osprincípios da arquitetura Web e usar vocabulários e padrões de dados. Segundo o Lóscio, Burle eCalegari (2016a), por exemplo, é importante que um recurso, que pode ser um conjunto de dadosinteiro ou um item específico de um determinado conjunto de dados, seja publicado com umaUniversal Resource Identifier (URI) estável, para que possam referenciados e fazer links, atravésde URIs, entre dois ou mais recursos. Somado a isso, para promover a interoperabilidade entreconjuntos de dados, é importante adotar os vocabulários e padrões de dados, como o DCAT1 quefoi projetado para facilitar a interoperabilidade entre catálogos de dados na Web.

1https://www.w3.org/TR/vocab-dcat/

2.3. DADOS NA WEB X DADOS ABERTOS X DADOS CONECTADOS 26

2.3 Dados na Web x Dados Abertos x Dados Conectados

Uma série de esforços vem sendo desenvolvido em todo o mundo, objetivando o compar-tilhamento e consumo dos dados na Web, dentre eles, destacam-se a publicação de dados emformato aberto (open data) e linked data. Segundo Lóscio, Burle e Calegari (2016b), Dadosna Web é o termo mais geral que pode ser usado denotar dados publicados de acordo com osprincípios da arquitetura Web2.

Segundo Dietrich et al. (2009), os dados são abertos quando qualquer pessoa podelivremente usá-los, reutilizá-los e redistribuí-los, estando sujeito, no máximo, à exigência decreditar a sua autoria e compartilhar pela mesma licença. Isotani e Bittencourt (2015) acrescentaque dados abertos de alta qualidade são publicados e distribuídos na Internet, compartilhadosem formato aberto para que possam ser lidos por qualquer pessoa e por máquinas, permitindoo cruzamento com outros dados de diferentes fontes, para serem livremente reutilizados pelasociedade. 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 deforma conveniente e modificável.

� Reúso e Redistribuição: os dados devem ser fornecidos sob termos que permita areutilizaçã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ãoconsiderados os principais formatos. O RDF, particularmente, é recomendado pela facilidade decombinar dados neste formato com múltiplas fontes de dados, interligando-se a outras iniciativasde dados na Web. Além disso, os dados abertos podem ser classificados de acordo com a escala,baseada em estrelas, apresentada na Figura 2.4 (BERNERS-LEE, 2006).

Figura 2.4: Esquema de 5 estrelas para os Dados Abertos. Fonte: http://5stardata.info/en/

2https://www.w3.org/TR/webarch/

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 formatosnão proprietários, como o CSV ao invés de Excel, é avaliado como 3 estrelas. A medida emque os dados recebem uma identificação única (URI) e são conectados com outros dados, elessã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 (dadosconectados), ou seja, seguem o conjunto de princípios para publicar e conectar conjuntos dedados 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 dedados 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ípiosbá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 obtidaspor 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 paraidentificar, não apenas documentos Web e conteúdos digitais, mas também objetos do mundoreal e conceitos abstratos. Além disso, disponibilizar URIs HTTP para permitir a obtençãode informações e a recuperação de uma representação de um recurso, como documentos RDFe XML. Além disso, é defendido o uso de RDF como modelo para a publicação de dadosestruturados na Web, para descrever significado sobre recursos e tornar possível a implementaçãode aplicações genéricas capazes de operar sobre o espaço de dados global. Por fim, usar linksRDF para conectar não apenas os documentos da Web, mas qualquer tipo de recurso, permitindoque itens relacionados sejam descobertos (LÓSCIO; OLIVEIRA; BITTENCOURT, 2015).

Portanto, nesse contexto, de acordo com Lóscio, Burle e Calegari (2016b), dados naWeb é o termo mais geral que pode ser usado para denotar os dados publicados de acordo coma arquitetura Web e podem ser representados conforme a Figura 2.5. Por fim, Lóscio, Burle eCalegari (2016b) acrescenta que é importante notar que nem todos os dados disponíveis na Websão compartilhados abertamente. Em outras palavras, os produtores determinam a política sobrea qual os dados devem ser compartilhados, levando em conta aspectos quanto a segurança eprivacidade dos indivíduos.

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 estruturaheterogê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 depublicação e consumo de dados na Web que vão desde a seleção e publicação dos dados até ouso e feedback sobre os dados utilizados, acrescentando que o conjunto dessas fases é chamadode ciclo de vida dos dados na Web.

Os dados estão sendo criados, publicados, exportados, importados, usados, transformadose reutilizados, por diferentes partes e para diferente fins. Dessa forma, a compreensão do ciclode vida ajuda a entender melhor a natureza dos dados e a manter um consenso entre as fasesenvolvidas. 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 relacionaros atores entre si (MöLLER, 2013). A partir de uma coleção de modelos de ciclo de vidapara domínios centrados em dados, tais como bibliotecas digitais, multimídia, e-learning edesenvolvimento 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 eBittencourt (2015) instanciou o modelo genérico ADLM e propôs o ciclo que é representado naFigura 2.6. Através do ADLM, podemos observar que um ciclo de vida para domínios centradosem 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 contemplatodas as fases definidas no modelo ADLM. Assim, as fases de desenvolvimento de ontologia,


arquivamento e término não fazem parte do ciclo de vida proposto. Os autores afirmam que acriação de ontologias é uma atividade independente e por isso não foi incluída, assim como, oarquivamento e término não foram consideradas porque acredita-se que, uma vez que o dado foipublicado 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 quetodos os dados na Web estarão disponíveis em um futuro indefinido. Uma vez que é provávelque os produtores podem necessitar ou desejar remover os dados, seja para mover eles parafora do escopo publicado ou até mesmo arquivando os dados. Nesse sentido, faz-se necessárioacrescentar 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 erefinamento. A fase de término é descrita por Möller (2013) como o momento em que os dadossã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 serentendida como a fase em que os dados são arquivados, mas o acesso a suas informações e aURI são preservadas. Assim, a Figura 2.7 apresenta o ciclo definido a partir das fases descritaspor Lóscio, Oliveira e Bittencourt (2015) somado a fase de término proposta neste trabalho.


Figura 2.7: Ciclo de Vida dos Dados na Web proposto pelo autor. Fonte: o autor

A Figura 2.7 apresenta as fases do ciclo de vida dos dados na Web, por meio delapodemos visualizar todas as fases desde o planejamento até o término. A seguir todas as fasessão descritas brevemente.

� Planejamento: É a primeira fase do ciclo de vida e precede o ciclo de vida ativodos dados (MöLLER, 2013). Esta fase se estende desde o momento em que surge aintençã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 determinema 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 dedados 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 Webe, além disso, nesta fase também devem ser criados os metadados que irão descreveros dados (LÓSCIO; OLIVEIRA; BITTENCOURT, 2015). Seguindo as Boas Práticas(LÓSCIO; BURLE; CALEGARI, 2016a), é importante considerar a publicação emdiferentes formatos (distribuições), minimizando a necessidade de transformação dosdados por parte dos consumidores.

� Publicação: Compreende o momento em os dados se tornam acessíveis na Web, ouseja, 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


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 acessoaos 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 qualdeverá 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ãodisponíveis e acessíveis. Assim, esta fase consiste no momento do ciclo de vida emque 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çãode visualização, como gráficos e mapas de calor, bem como para aplicações quepermitem 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á diretamenterelacionada ao consumidor de dados. Dentre os consumidores, podemos citar desdeum desenvolvedor interessado em criar uma aplicação que faça uso dos dados, comopessoas 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 seusprodutos 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 é ocaso de consumo de dados e sim de refinamento. O consumo de dados nesta fase éessencialmente vinculado ao uso externo dos dados (MöLLER, 2013).

� Feedback: Os produtores de dados querem garantir que os dados publicados satis-façam as necessidades dos consumidores (LÓSCIO; BURLE; CALEGARI, 2016a).Dessa forma, esta fase compreende o momento em que os consumidores devemprover comentários sobre os dados e metadados utilizados, permitindo identificar me-lhorias e correções nos dados publicados, além de manter um canal de comunicaçãoentre os produtores e consumidores (LÓSCIO; OLIVEIRA; BITTENCOURT, 2015).

� Refinamento: Esta fase compreende todas as atividades relacionadas a atualizaçõesnos dados publicados ou adição de novos. Ou seja, está relacionada a garantia demanutenção dos dados previamente publicados e que podem ser realizadas a partirdos comentários de feedback coletados na fase anterior. Além disso, Lóscio, Oliveirae Bittencourt (2015) aponta que a manutenção pode ser feita gerando novas versõespara garantir que os dados não fiquem obsoletos, fazendo um correto gerenciamentodas diferentes versões e fornecendo acesso a versão correta dos dados para os con-sumidores. Contudo, Lóscio, Burle e Calegari (2016a) aponta que não existe umconsenso de quando um conjunto de dados deve ser considerado uma nova versão


ou ser alterado completamente, porém é considerado uma boa prática fornecer umhistórico completo das versões e indicar um número de versão ou data para cadaconjunto de dados.

� Término: Esta fase compreende o momento em que os produtores "removem"os dadosda Web. É possível que os dados sejam alterados e movidos para um novo conjunto dedados 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çõesque 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 daWeb, é possível que até mesmo os dados arquivados possam ser utilizados juntamentecom outros dados, sendo formados novos conjuntos de dados.

Portanto, o ciclo de vida dos dados na Web, em nosso trabalho, compreende desde a fasede planejamento até a fase de término. Durante esse processo, os atores desempenham o papelde produtor de dados e o de consumidor de dados. De modo geral, o produtor é responsávelpor informar os metadados, criar e publicar os dados. Enquanto que os consumidores são atoresque consomem os dados, podendo ser eles mesmo produtores, uma vez que podem realizarmelhorias 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 sejamseguidas até que uma nova iteração seja iniciada. Isto é, mesmo sendo um ciclo não quer dizerque os dados tenham que passar pela etapa de término para iniciar uma nova iteração ou queprecisem receber um feedback antes do produtor realizar um refinamento nos dados.

333333

3Publicação de Dados na Web

Neste capítulo abordaremos as soluções que provêm catálogos de dados e as boas práticaspara Dados na Web. Na Seção 3.1 apresentamos as características das principais soluçõesatualmente disponíveis para catalogação de dados na Web. Já na Seção 3.2 são descritas asboas práticas para dados na Web e, na Seção 3.3, analisamos os softwares a vista das melhoresprá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 asfases do processo de publicação e consumo de dados na Web. Nesse ciclo, a publicação mantéma interface de quem disponibiliza os dados com as pessoas que vão utilizá-los. Isto é, os dadosdevem 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ávelpela 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 ciclode vida, como o acesso, permitir o consumo, receber feedback e permitir o gerenciamentoda 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, bemcomo permitindo o compartilhamento e o uso deles. Exemplos desses softwares são: CKAN1,Socrata2, Junar3, OpenDataSoft4 e ArcGIS Open Data5. Nas próximas seções, descrevemos asprincipais características de cada uma dessas soluções.

1http://ckan.org/2https://socrata.com/3http://junar.com/4https://www.opendatasoft.com/5http://opendata.arcgis.com/

3.1. SOLUÇÕES PARA CATALOGAÇÃO DE DADOS 34

3.1.1 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 dedados. Por ser livre, não tem custos e tem uma curva de aprendizado muito positiva. Conta aindacom 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 oBrasil, Uruguai, Canadá, Reino Unido, Estados Unidos, Romênia, Austrália, Holanda, Itália eAlemanha.

O CKAN foi desenvolvido em Python e faz uso de outras tecnologias e linguagens, comoHTML, CSS, Javascript, PostgreSQL e SQLAlchemy. Sua arquitetura foi projetada para aceitarextensões (Plugins) que permitem estender suas funcionalidades ou modificar as já existentes,conforme apresentado numa breve visão de sua arquitetura na Figura 3.1.

Figura 3.1: Arquitetura do CKAN. Fonte:<http://docs.ckan.org/en/latest/contributing/architecture.html>

A camada Routes realiza um vínculo entre a Uniform Resource Locator (URL) que éacessada com a Views que irá processar a solicitação. A camada Views recebe a requisição deleitura ou atualização de dados e encaminha para a camada Logic. Já a camada Logic incluifunções de ação, autenticação, tarefas em segundo plano e lógica de negócios. Assim, ela secomunica com a camada Models, que mantém a abstração de acesso e consulta ao banco dedados, 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 fordirecionada para API, ela processará e retornará os dados em formato JSON. Ademais, os Plugins



implementam a mesma sequência de camadas e conseguem manter comunicação em todos osníveis do CKAN (CKAN, 2013).

3.1.2 Junar

O Junar também é outro software usado para criação de portais de catalogação de dados.Ele faz uso do conceito de Software como Serviço (SaaS), tem sua plataforma baseada emnuvem e permite a visualização dos dados em qualquer dispositivo. É usado no portal oficialde dados abertos do Chile, Costa Rica e de algumas cidades dos Estados Unidos. Segundo suadocumentação, ele oferece alta largura de banda, armazenamento escalável e uma excelenteconfiabilidade por meio da Amazon Web Services (JUNAR, 2015).

Segundo a documentação do Junar (JUNAR, 2015), principais módulos de sua soluçãoestão concentrados na coleta dos dados, aprimoramento, publicação, compartilhamento e análisesatravés de relatórios, conforme pode ser visualizado na Figura 3.2. O Junar suporta diferentesformatos 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 poruma hierarquia de usuários, permitindo que o conjunto de dados seja publicado apenas apósaprovação. Uma vez publicado, pode ser acessado pelo portal ou através da API.

Figura 3.2: Visão geral do processo de Publicação no Junar. Fonte:<http://junar-cdn-brandings.s3.amazonaws.com/ebook/

Overview-Junar-Open-Data-Portal-for-IT-Professionals-N0511.pdf>

De forma geral, o Junar possibilita a publicação de Dataset e ferramentas para gerencia-mento quando é criado um Dataview, que pode conter subconjuntos de dados ou até mesmo oDataset completo. Além disso, é possível que os administradores publiquem gráficos visandooferecer aos usuários um acesso rápido a visualização dos dados. A Figura 3.3 exemplificao 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, disponibilizaros recursos ao público.




Figura 3.3: Exemplo de publicação de dados no Junar. Fonte:<http://junar-cdn-brandings.s3.amazonaws.com/ebook/

Overview-Junar-Open-Data-Portal-for-IT-Professionals-N0511.pdf>

3.1.3 Socrata

O Socrata é um software baseado em nuvem e na ideia de SaaS, seu principal diferencialé na construção de visualizações mais elaboradas, com formatação condicional, gráficos e mapas.Ele é usado no portal oficial do Kenya, no portal do Banco Mundial, em cidades e estados dosEUA 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 eserá disponibilizada como open source. Alguns componentes do Socrata já estão disponibilizadosde forma aberta e pode ser encontrada através de seu repositório no Github6.

O Socrata faz uso de diversas tecnologias, como o Javascript e o Ruby para o frontend,Java e Scala para o backend e tecnologias de armazenamento como o Postgres e Cassandra. Suaarquitetura é apresentada na Figura 3.4 e, por meio dela, verificamos que os caminhos de leiturae escrita foram divididos, o que segundo sua documentação, tem por objetivo fornecer acessomais rápido para quem apenas utiliza os dados (SOCRATA, 2016).

6https://github.com/socrata-platform




Figura 3.4: Arquitetura do Socrata. Fonte:<http://open-source.socrata.com/architecture/>.

A partir de uma inserção, atualização ou exclusão de dados enviado para o servidor SODA,o processo é iniciado no pacote de escrita. Assim, o pedido será transformado em uma sériade operações granulares chamadas de Primary Mutator. O Data Coordinator executará essasmutações na Truth store, que mantém a abstração para operações independente da tecnologia finalutilizada para armazenamento. No caso específico da imagem acima, é mostrado um exemplocom 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. Emseguida, 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 oservidor. O servidor analisa o SoQL enviado e se estiver escrito de forma correta, envia o pedidopara o Query Coordinator. Assim, ele verifica para qual solução de armazenamento o pedidodeve ir, encaminhando o pedido para o respectivo adaptador. Por fim, o Adaptador executa aconsulta e retorna os dados através do formato C-JSON (SOCRATA, 2016).



3.1.4 OpenDataSoft

O OpenDataSoft pode ser encontrado em alguns portais de cidades como Brussels eParis, além da Córsega, Île de France e o jornal L’Équipe. Seu principal diferencial é a facilidadepara buscar, navegar e realizar filtros dentro dos datasets, que geram automaticamente o códigopara consumo via API. Somado a isso, visa facilitar a publicação dos dados exigindo poucosmetadados e a construção de visualizações automáticas.

Também é baseado em SaaS e concentra-se em prover uma plataforma voltada parausuá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 apublicação.

Figura 3.5: Arquitetura do OpenDataSoft. Fonte:<https://docs.opendatasoft.com/en/about.html>.

Em síntese, os dados podem ser coletados de forma manual ou através da capturaautomá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 dadoscomo definição de unidade, ordenação e separação de dados multivalorados. Nessa mesmaetapa de processamento, também é possível adicionar Processors que vão enriquecer os dadosou 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 eas visualizações como tabelas e mapas são criadas automaticamente a partir dos dados, quandopossível (OPENDATASOFT, 2016).

https://docs.opendatasoft.com/en/about.html


3.1.5 ArcGIS Open Data

O ArcGIS Open Data permite realizar a busca de dados por tópicos ou locais, visualizargráficos, tabelas e mapas interativos. A contar do seu lançamento em 2014, seu foco inicial foramos 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, sincronizandoautomaticamente com a versão mais recente de suas fontes. Exemplos de uso são cidades eestados nos Estados Unidos, como Columbia, Utah (geoespacial), Washington (geoespacial), eno Canadá, como Halifax.

A arquitetura do ArcGis Open Data, ilustrada na Figura 3.6, é orientada a serviços. Dadoseu foco inicial em dados geográficos, sua arquitetura se aproxima de uma infraestrutura voltadapara um sistema de informação geográfica moderno, apresentando quatro grandes camadas:armazenamento de dados, curadoria de metadados, pesquisa e acesso ao público (ESRI, 2015).

Figura 3.6: Arquitetura do ArcGis Open Data. Fonte:<https://blogs.esri.com/esri/arcgis/2015/09/02/architecture-of-open-data/>.

Na camada de armazenamento de dados, ele oferece opção para armazenamento dosdados localmente ou na nuvem, permitindo o acesso através de uma API. Cada serviço dedados do Servidor ArcGis possui uma API, que permite consultas e agregações por aspectosespaciais, temporais e por atributos, fornecendo saída em JSON. Também permite se conectarcom outras plataformas de dados abertos que utilizem CKAN e Socrata, por exemplo, paraexportar os dados e trabalhar com as visualizações e análises da ferramenta. Além disso, faz uso



do DCAT para descrever os metadados dos datasets. Quanto à consulta, acrescenta integraçãocom navegadores Web e SDKs para desenvolvedores, somado a marcações RDF para motoresde busca da Web e busca semântica. Dessa forma, permite que os dados sejam acessadospublicamente através de portais, disponibilizando bibliotecas e aparatos para construção deaplicações, além da construções de mapas e visualizações de forma automática (ESRI, 2015).

3.1.6 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údoDrupal e com o Github, respectivamente, e também são de código aberto. Todavia, analisaremoso DKAN dado sua maior popularidade e que o JKAN tem o objetivo de prover uma soluçãoleve 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 NuCivic7 e foi desenvolvido a partir doCKAN 2.08 e Drupal 79. Sua principal linguagem é o PHP, faz uso do Sistema Gerenciadorde Banco de Dados (SGBD) MySQL e do MariaDB10 e está disponível sob a segunda versãoda licença GNU General Public License11. Por ser um distribuição do CKAN e Drupal, podeobter benefícios inerentes a cada um dos softwares, por exemplo, todos os módulos adicionaisdisponí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ãobaseada em SaaS, que é paga e apresenta módulos adicionais que a diferem da versão gratuita(NUCIVIC, 2015).

Figura 3.7: Visão adaptada da arquitetura do DKAN. Fonte: <http://www.slideshare.net/DavidPortnoy/ddod-the-lean-startup-approach-to-open-data>

(adaptado pelo autor).

De forma geral, conforme apresentado na Figura 3.7, o DKAN utiliza-se do Drupal

7http://www.nucivic.com/8http://ckan.org9https://www.drupal.org/drupal-7.0

10https://mariadb.org/11http://www.gnu.org/licenses/old-licenses/gpl-2.0.html



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 paragerenciamento dos datasets, motor de busca, geolocalização e para prover a API. Por tambémser disponibilizado como uma extensão do Drupal, ele também pode ser facilmente adicionadoem 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 temado DKAN, pesquisa e outros elementos. O componente dataset é um módulo que fornece opçãopara publicação dos conjuntos de dados e de recursos, tal como o CKAN, ou seja, os conjuntosde dados contêm os metadados e os recursos os dados. No entanto, no DKAN os metadadosestão disponíveis em RDF, que é compatível com o DCAT, bem como em JSON. Por fim, odatastore é um módulo que fornece a capacidade de armazenar arquivos e disponibilizar os seuscomponentes 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çõesgovernamentais e não-governamentais já disponibilizam uma variedade de dados na Web, algunsabertamente, alguns com restrições de acesso, abrangendo muitos domínios como educação,economia, segurança, patrimônio cultural, comércio eletrônico e dados científicos. Desenvolve-dores, jornalistas e outros manipulam esses dados para criar visualizações e realizar análises dedados. A experiência neste domínio revela que é necessário abordar várias questões importantesa 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 heteroge-neidade dos dados e a falta de padrões para descrição e acesso aos conjuntos de dados tornam oprocesso de publicação, compartilhamento e consumo de dados uma tarefa complexa. Portanto,buscam-se alternativas que possibilitem um entendimento comum entre os atores desse contexto,promovendo uma maior confiança nos dados e aumentando o potencial de inovação. Ou seja,publicar dados de forma que possam ser facilmente compreendidos e utilizados por consumido-res, assim como, publicados em formatos que possam ser facilmente processados por aplicações,por exemplo. Pois, sem esse entendimento e confiança, os esforços dos provedores podem serincompatí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 compilouum conjunto de casos de uso12 que representam cenários de como os dados são comumentepublicados e como eles são usados na Web. A partir desses casos de uso, foi possível identificaros principais desafios enfrentados pelos produtores e consumidores de dados, assim como, foipossível definir um conjunto de requisitos. Tais desafios e requisitos guiaram o desenvolvimentodo documento DWBP (LÓSCIO; BURLE; CALEGARI, 2016a), que estabelece boas práticas

12https://www.w3.org/TR/dwbp-ucr/


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 oucomplementado por outros documentos ou normas mais especializadas. De forma geral, osdesafios 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 DescriçãoMetadados Permitir que os seres humanos entendam os metadados, interpretando a natu-

reza e a estrutura dos dados, e que as máquinas também possam processá-losLicença Permitir que os seres humanos compreendam as informações da licença e que

as máquinas possam detectar automaticamenteProveniência Permitir que os seres humanos conheçam a origem ou o histórico do con-

junto de dados e e que as máquinas possam processar automaticamente taisinformações

Qualidade Documentar a qualidade dos dados, para facilitar o processo de seleção dosconjuntos de dados e chaces de reutilização

Versionamento Permitir que versões dos dados sejam geradas e seja possível o acesso a cadaversão

Identificação Fornecer identificadores únicos para os conjuntos de dados e distribuiçõesFormato Escolher formatos que permitam o uso e o reusoVocabulários A fim de melhorar a interoperabilidade e manter terminologia comum entre os

produtores e consumidoresAcesso Permitir o fácil acesso aos dados usando a infraestrutura da Web tanto para

seres humanos quanto para máquinasPreservação A fim de indicar corretamente se os dados foram removidos ou arquivadosFeedback Receber feedback dos consumidores e assegurar que os dados atendem as

necessidades deleEnriquecimento Enriquecer, melhorar ou refinar os dados brutos agregando valorRepublicação Permitir que os dados utilizados possam ser republicados

Fonte: (LEE; LÓSCIO; ARCHER, 2015)

Assim, o DWBP desenvolveu as boas práticas partindo dos desafios apresentados noQuadro 3.1 e dos diferentes requisitos de casos de uso relacionados a cada desafio, descritosem Lee, Lóscio e Archer (2015). No total, são 35 boas práticas que discursam sobre diferentesaspectos 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-seque ao seguir as boas práticas, uma série de benefícios distintos possam ser alcançados, taiscomo 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, quaisos passos, do ponto de vista técnico, que devem ser seguidos e implementados até os dadosserem publicados.


Conforme descrito em Lóscio, Burle e Calegari (2016a), cada boa prática (BP) tem umresultado pretendido com a aplicação da prática. Esse resultado indica o que é possível fazerquando 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 poderefletir em uma melhora no próprio conjunto de dados. Além disso, apresenta uma seção parapossíveis formas de implementação da prática, a motivação para o uso e os testes que podemser 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ãoalcançados com o uso dela. No Quadro 3.2 é apresentado o conjunto de boas práticas e qual odesafio ao qual ela está relacionada.


Quadro 3.2: Boas práticas para dados na Web.

Boa Prática DesafioBP1: Provide metadata Metadados

BP2: Provide descriptive metadata Metadados

BP3: Provide structural metadata Metadados

BP4: Provide data license information Licença

BP5: Provide data provenance information Proveniência

BP6: Provide data quality information Qualidade

BP7: Provide a version indicator Versionamento

BP8: Provide version history Versionamento

BP9: Use persistent URIs as identifiers of datasets Identificação

BP10: Use persistent URIs as identifiers within datasets Identificação

BP11: Assign URIs to dataset versions and series Identificação

BP12: Use machine-readable standardized data formats Formato

BP13: Use locale-neutral data representations Formato

BP14: Provide data in multiple formats Formato

BP15: Reuse vocabularies, preferably standardized ones Vocabulários

BP16: Choose the right formalization level Vocabulários

BP17: Provide bulk download Acesso

BP18: Provide Subsets for Large Datasets Acesso

BP19: Use content negotiation for serving data available in multiple formats Acesso

BP20: Provide real-time access Acesso

BP21: Provide data up to date Acesso

BP22: Provide an explanation for data that is not available Acesso

BP23: Make data available through an API Acesso

BP24: Use Web Standards as the foundation of APIs Acesso

BP25: Provide complete documentation for your API Acesso

BP26: Avoid Breaking Changes to Your API Acesso

BP27: Preserve identifiers Preservação

BP28: Assess dataset coverage Preservação

BP29: Gather feedback from data consumers Feedback

BP30: Make feedback available Feedback

BP31: Enrich data by generating new data Enriquecimento

BP32: Provide Complementary Presentations Enriquecimento

BP33: Provide Feedback to the Original Publisher Republicação

BP34: Follow Licensing Terms Republicação

BP35: Cite the Original Publication RepublicaçãoFonte: (LÓSCIO; BURLE; CALEGARI, 2016a)

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 fornecimentode metadados é um requisito fundamental. Dessa forma, os metadados ajudam os consumidoresa compreenderem o significado dos dados, sua estrutura, licença, organização que gerou osdados, métodos de acesso e agendamento de futuras atualizações dos conjuntos de dados. Dessa


forma, os resultados esperados com as BPs relacionadas a metadados versam sobre a capacidadede compreender os metadados (BP 1), assim como de interpretar a natureza dos conjuntos dedados e suas distribuições (BP 2) e interpretar o esquema deles (BP 3). Para se atingir essas trêsboas práticas, também é necessário fornecer acesso para que seja possível o processamento pormá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, segundoo Lóscio, Burle e Calegari (2016a), a licença pode ser especificada nos metadados ou em umdocumento ao qual ele está vinculado (BP 4). Somado a isso, é a importante informar a origemdos dados (BP 5), uma vez que os dados podem ter sido oriundos de um produtor diferente doqual está publicando. Dessa forma, informar metadados de proveniência é uma forma de confiarna integridade e credibilidade dos dados que estão sendo compartilhados.

Ademais, a qualidade dos conjuntos de dados também impactam na qualidade dasaplicações que o utilizam. Dessa forma, é importante informar metadados de qualidade, contendodiferentes tipos de dimensões de qualidade (BP 6), como as que estão presentes no Data QualityVocabulary13.

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 sendoalterados. Vale ressaltar que os conjuntos de dados podem se comportar como séries temporaise, 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 deveser tratado como uma série temporal e não como uma versão diferente. Portanto, é consideradouma boa prática atribuir e indicar o número de versão ou data para cada conjunto de dados (BP7) 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 porexemplo o HTTP (ou HTTPS) URIs, que é a base para comunicação de dados na Web. Dessaforma, Lóscio, Burle e Calegari (2016a) estabelece como boa prática o uso de URIs persistentescomo identificadores de conjuntos de dados (BP 9), para as versões individuais geradas e, sendouma série temporal, também para a série global (BP 11). Além disso, é necessário que se tenhacuidado na identificação, pois embora as URIs tenham a função puramente de identificar umrecurso, não seria aconselhado que uma URI como http://example.com/dataset.csv retornassequalquer coisa diferente de um CSV. Somado a isso, também é importante que URIs persistentessejam utilizadas como identificadores dentro dos conjuntos de dados (BP 11), ou seja, incluirlinks para outras URIs de forma que outros recursos possam ser descobertos, tornando os dadosmais valiosos.

Quanto aos formatos dos dados, Lóscio, Burle e Calegari (2016a) afirma que o formatono qual os dados são disponibilizados é fundamental para tornar os dados utilizáveis pelosconsumidores. Assim, encoraja a disponibilização dos dados em mais de um formato (BP 14),

13https://www.w3.org/TR/vocab-dqv/


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), comoCSV, XML, HDF5, JSON, RDF / XML, JSON-LD, Turtle e outros. Também é aconselhado usarrepresentaçõ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). Emoutras palavras, é preferível que se utilize representações consideradas neutras como os tiposde 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 osconsumidores, é considerado uma boa prática o reúso de vocabulários (BP 15), dando preferênciaaos padronizados. Os vocabulários definem os conceitos e atributos utilizados para descrever erepresentar uma área de interesse, como por exemplo, o vocabulário DCAT 14 que é utilizado paraexpressar os metadados relacionados aos conjuntos de dados e faz de uso de outros vocabuláriosdifundidos como o Dublin Core15, FOAF16 e o SKOS17. Também é preferível que se opte porum nível de semântica formal que possa encaixar os dados e as aplicações mais prováveis (BP16), ajudando assim a estabelecer especificações precisas que transmitem significado detalhado epodendo 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 aproveitemos benefícios da infra-estrutura da Web para uso e compartilhamento de dados. Por padrão, aWeb oferece acesso aos dados através de métodos HTTP, o que permite acesso em um nível detransação atômica. Lóscio, Burle e Calegari (2016a) aponta que o acesso pode ser realizadoatravés de bulk download simples de um arquivo e através de uma API, onde os dados sãodistribuídos em vários arquivos ou requer métodos de recuperação mais sofisticados, não sendoesses métodos básicos mutualmente exclusivos.

Na abordagem de bulk download (BP 17), geralmente os dados são pré-processados peloservidor e é fornecido apenas um arquivo para download. Em alguns casos, como quando osconjuntos de dados são grandes, pode-se oferecer opções através de APIs para efetuar operaçõese realizar download de subconjuntos dos dados (BP 18). Vale salientar que através das APIstambém pode ser efetuado o download de todos os dados, assim como os subconjuntos dedados também podem ser disponibilizados em arquivos físicos menores para download. Nessesentido, também é considerado uma boa prática o uso da negociação de conteúdo para permitiro 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

14https://www.w3.org/TR/vocab-dcat/15http://dublincore.org/documents/dcmi-terms/16http://xmlns.com/foaf/spec/17https://www.w3.org/TR/skos-reference/


(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 Webem tempo real ou quase em tempo real (BP 20), através de um sistema automatizado que permitao acesso imediato. Nesse caso, também são consideradas as taxas de atualização e latência porcausa de etapas de pós processamento de dados, por exemplo. Quando os dados não são emtempo real, é considerado uma boa prática fornecer os dados atualizados, deixando a frequênciade 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 podemser acessados e quem pode acessar (BP 22) (LÓSCIO; BURLE; CALEGARI, 2016a).

Uma API oferece uma maior flexibilidade e capacidade de processamento para osconsumidores 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 (BP23), 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 dispostosa continuar a utilizá-la. Por fim, é importante que se evite alterações na API para não quebrar ocó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 oURI de um conjunto de dados mesmo ele não estando disponível e fornecer informações sobre oseu arquivamento (BP 27). Antes do arquivamento, Lóscio, Burle e Calegari (2016a) sugere aavaliação da cobertura do conjunto de dados (BP 28), verificando se os recursos utilizados já sãopreservados em algum lugar ou devem ser fornecidos juntamente com o respectivo conjunto dedados que será preservado.

Com os dados publicados na Web, os consumidores podem acessá-los e criar suaspró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 maneiraseficazes 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 menosum 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 sendoabordadas, evitará o envio de problemas duplicados e promoverá o senso de comunidade entreeles. Consequentemente, através do feedback, os produtores também poderão melhorar aqualidade dos dados.

O enriquecimento de dados consiste no conjunto de processos que podem ser utilizadospara 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ãoaumentar o seu valor (BP 31). Também é aconselhável enriquecer os dados através de represen-

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 sertomados para evitar o enriquecimento que distorce os resultados estatísticos ou enriquecimentoque permitam identificar indivíduos, comprometendo a privacidade.

Os consumidores também podem combinar os dados existentes com outros conjuntosde dados e criar aplicativos ou visualizações, por exemplo. Tais dados, portanto, podem serdisponibilizados novamente na Web através da republicação. Sendo assim, quando utilizar osdados, encontrar um erro ou elogios ou sugestões, é importante fornecer feedback para o produtororiginal dos dados (BP 33). No contexto da republicação, é considerado uma boa prática seguiros requisitos da licença original do conjunto de dados (BP 34), assim como citar a publicaçãooriginal em seus metadados (BP 35), para que se mantenha a proveniência, reconheça a fonte dedados e torne os dados confiáveis.

A partir do uso das boas práticas, os produtores de dados podem alcançar benefícios comoCompreensã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 teruma melhor compreensão da estrutura, significado e a natureza do conjunto de dados. Sendoassim, quanto maior o número de boas práticas forem utilizadas, maiores serão os benefíciosalcançados. Considerando que a publicação de dados na Web é um processo incremental, osníveis de benefícios poderão aumentar após algumas iterações do processo de publicação dedados (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 gerencia-mento dos portais de dados abertos brasileiros, como ausência de controle de versão, dificuldadeem 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. Britoet 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 epublicaçã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álogosde dados estão adequados as Boas Práticas para Dados na Web. Ou seja, ao invés de consideraros conjuntos de dados ou portais de dados específicos como evidências, usamos os principaissoftwares 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 Datae OpenDataSoft. Vale salientar que nossa avaliação se deu a partir da análise da documentação


dos softwares e da utilização das ferramentas por meio do modo demo. Porém, para o Junarque não dispõe de ferramenta online para testes, verificou-se que os portais de dados, que seutilizam dele para gerar o catálogo, apresentam as mesmas funções e tipos de acesso sem muitaspersonalizações. Assim, considerou-se o acesso aos portais como evidência complementar asua documentação que apresenta as telas e processos de publicação de dados. Para algumasboas 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ãodiretamente relacionadas aos dados em si e não as soluções. Outrossim, as BP33, B34, BP35 seaplicam a situações de republicação de dados e dependem do consumidor. Enquanto que a BP31diz respeito ao processo de enriquecimento dos dados, que não faz parte das funções básicas docatá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 deboas práticas são atendidas por todas as soluções, como prover metadados, prover informaçõesde licença e prover os dados em diferentes formatos. É importante frisar que os formatos dedados dependem do formato que o produtor deseja publicar, mas para análise foi considerado sea 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 emdiferentes formatos do que foi publicado, ou seja, fazem uso da negociação de conteúdo paradisponibilizar os dados em formatos distintos.

O desafio de Vocabulários também foi evidenciado como um dos mais importantes nassoluçõ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 adados é um consenso entre as soluções. Também é por meio das APIs que as soluções permitema obtenção de subconjuntos de dados.

No entanto, nenhuma das soluções apresenta alternativa para tratar dados em temporeal. Todavia, vale salientar que o ArcGIS Open Data é o único que apresenta referência quantoa essa boa prática, indicando que quando ele é integrado ao ArcGIS for Server, pode realizara publicação de dados geográficos em tempo real para consumo. Por fim, todos eles usamURIs persistentes como identificadores para os conjuntos de dados e apresentam visualizaçõescomplementares de forma automática, permitindo gerar gráficos, tabelas interativas e síntesesestatísticas.


Quadro 3.3: Catálogos de Dados X Boas Práticas

BP Catálogos de dados

BP1 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


BP10 -

BP11 SOCRATA


BP13 OPENDATASOFT (parcial)

BP14 SOCRATA, Junar, ARCGIS, OPENDATASOFT

BP15 CKAN, SOCRATA, DKAN, Junar, OPENDATASOFT

BP16 -


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




BP27 Nenhum dos softwares.

BP28 -

BP29 CKAN, SOCRATA, DKAN

BP30 CKAN, SOCRATA, OPENDATASOFT

BP31 -


BP33 OPENDATASOFT

BP34 -

BP35 -

Fonte: o autor

Observamos também que nenhuma das soluções implementam a BP27. Quando umconjunto de dados não está mais disponível nas soluções, é retornado apenas uma mensagem deerro 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


consumidores, como por formulários de contato, sem deixá-lo de forma pública para que outrosanalisem.

Todas as soluções analisadas são compatíveis com o DCAT, indicando que seus meta-dados são cobertos por ele. Todavia, algumas soluções oferecem apenas uma cobertura parciale 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 umaversão legível por humanos para os metadados estruturais, ou seja, não disponibilizam metadadosque descrevam o esquema e a estrutura interna dos conjuntos de dados. Assim como o ARCGISe o OpenDataSoft implementam as BP4 e BP5 de forma parcial por não oferecer uma maneirapara 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 à listadas versões dos conjuntos de dados. Por fim, o OpenDataSoft implementa a BP13 parcialmentepois não oferece uma maneira de representar os metadados de localidade ou idioma para acessolegível por máquina.

Outras características só foram encontradas no Socrata, tais como informação de quali-dade dos dados e a atribuição de URIs para as versões dos conjuntos de dados. No entanto, oSocrata não disponibiliza o indicativo das versões e, apesar de não listar as versões, o CKAN e oDKAN 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 deuma aplicação adicional (DataSync18). Ainda sim, é necessário utilizar conectores que gerem oarquivo que poderá ser publicado por DataSync. Contrapondo-se, o Junar permite que a frequên-cia de atualização seja seguida quando os dados são consumidos através de uma API. Apesar denão apresentar a informação de quando os dados serão atualizados para os consumidores, atravésdos 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 oseu potencial, é necessário resolver questões em aberto conforme apontado nos resultados danossa 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 pelosprincipais softwares de catálogos de dados. Dessa forma, ficou evidente que existe a necessidadede 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 signi-ficativa nesse cenário, pois uma solução desta natureza pode ajudar na comunicação entre osprincipais atores do ecossistema de dados na Web, assim como pode suprir tais necessidadesaparentes no contexto de publicação e gerenciamento de dados, que não são atendidas pelassoluções atuais.

18https://github.com/socrata/datasync

525252

4Compartilhamento de Dados na Web

Neste capítulo, serão descritos os principais requisitos identificados para as soluçõesde soluções de compartilhamento de Dados na Web. De modo geral, buscamos entender osprincipais desafios para publicação e consumo dos dados na Web e, a partir do estudo dessesdesafios, foram elencadas premissas para o compartilhamento de dados na Web. Tais premissasguiaram a definição dos requisitos que uma solução de compartilhamento de Dados na Web deveter para prover um gerenciamento adequado dos conjuntos de dados.

Dessa forma, a Seção 5.1 apresenta conceitos básicos fundamentais para o entendimentodeste 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 naWeb apresentadas na Seção 5.3. Por fim, na Seção 5.4 é realizado uma discussão do Capítulo pormeio 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 registradose possuem significado implícito. Preferencialmente, os dados de um conjunto de dados devemestar 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 dis-tribuição pode ser vista como uma instância do conjunto de dados em um formato de dadosespecífico, ou seja, os dados do conjunto de dados em um determinado momento representadosem um formato de dados específico. Além dos dados, cada distribuição contém uma descriçãoda 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 docompartilhamento de dados na Web, além de informações sobre os tipos de dados, torna-sefundamental compartilhar informações sobre licença, versionamento, proveniência, qualidade e

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 demudanças entre versões deverá ser armazenado. Apesar de não existir um consenso de quandouma nova versão deve ser gerada, neste trabalho assumimos que uma versão será gerada pararefletir 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 doconjunto de dados.

Um conjunto de dados pode sofrer atualizações em seus dados de acordo com umafrequência de atualização pré-definida ou pode ser atualizado para refletir mudanças que acon-tecem no mundo real. É necessário manter a data da última atualização do conjunto de dadosdevidamente atualizada de acordo com as mudanças efetuadas nos dados.

Em nosso contexto de compartilhamento de dados na Web, admitimos três fases para umconjunto 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 produtordefine quais dados deseja publicar, cadastra informações por meio dos metadados e inicia oprocesso de extração dos dados. Quando o conjunto de dados é compartilhado na Web, oconjunto de dados passa para o estado Publicado. Em determinados casos, dado a conflitos deinteresse distintos, um conjunto de dados só pode ser publicado após a validação de um outroresponsável que integra a equipe do produtor. Dessa forma, uma vez criado, o conjunto dedados deve ser validado e publicado na Web. Uma vez publicado na Web, o conjunto de dadosdeve estar disponível para acesso ao longo do tempo. No entanto, um produtor pode sinalizar adescontinuação dele e, nesse caso, o conjunto de dados passa para o estado Preservado. Nesseestado, será possível obter acesso aos dados ou informações de como acessá-los uma vez queserá possível acessar a URI original que estará preservada. Um conjunto de dados preservadopode voltar a ser disponibilizado ao público e, assim, voltar ao estado publicado.

4.2. PREMISSAS DO COMPARTILHAMENTO DE DADOS NA WEB 54

4.2 Premissas do compartilhamento de Dados na Web

Desde o seu surgimento, a Web tem se destacado como um importante meio para a troca ecompartilhamento de informações. A Web possibilita o compartilhamento de dados, i.e. o acessoe a leitura de dados, de maneira bastante simples, sem a exigência de sistemas para controlar oacesso concorrente aos dados, por exemplo. Por outro lado, a facilidade de compartilhamentoem grande escala requer soluções flexíveis que possibilitem o consumo de dados por grupos deusuários previamente desconhecidos (LÓSCIO; BURLE; CALEGARI, 2016a). Isso implica queos dados devem ser compartilhados de maneira a atender aos requisitos de um conjunto amplo eheterogê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 emoutros sistemas já existentes. Isso traz consequências importantes como a necessidade de manteros dados sempre atualizados com relação aos dados de origem e a necessidade de realizartransformações nos dados antes da sua publicação na Web. Outro fator importante que deve serconsiderado diz respeito à evolução dos conjuntos de dados ao longo do tempo, os quais podemsofrer atualizações tanto na sua descrição quanto nos seus dados. Em muitos casos, observamosque, após a publicação inicial na Web, os conjuntos de dados permanecem inalterados e nãorefletem as mudanças ocorridas no mundo real. Entretanto, é importante que os conjuntos dedados continuem "vivos". Finalmente, como estamos falando de compartilhamento de dados naWeb, é 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 disponibilizadoscomo JSON, XML, RDF, CSV e HTML. É muito comum, que a disponibilização de arquivospara download seja considerada como um caso de dados na Web. Porém, para termos dadosna Web é importante que os conjuntos de dados e, preferencialmente, os itens de dados sejamidentificados por meio de URIs.

A fim de obter um melhor entendimento sobre os requisitos para as soluções de compar-tilhamento de dados na Web, fizemos um estudo detalhado dos trabalhos gerados pelo DWBPWorking Group do W3C. Especificamente, os documentos de Uses Cases1 e de Boas Práticas2 auxiliam o entendimento desse novo cenário de compartilhamento de dados, uma vez queelencam e discutem os principais desafios a serem enfrentados na publicação e no consumo dedados na Web. A partir desse estudo, elencamos quatro premissas para o compartilhamento deDados na Web. A definição dessas premissas foi fundamental para termos um claro entendimentodos requisitos para o adequado compartilhamento de dados na Web.

Premissa 1: Não existe um conhecimento prévio entre os responsáveis pela disponibili-

zaçã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;

1https://www.w3.org/TR/dwbp-ucr/2https://www.w3.org/TR/dwbp/

4.3. REQUISITOS PARA AS SOLUÇÕES DE COMPARTILHAMENTO DE DADOS NAWEB 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 Da-dos na Web

Considerando as premissas elencadas na seção anterior e as Boas Práticas para Dados naWeb (LÓSCIO; BURLE; CALEGARI, 2016a), temos que as várias soluções que lidam com ocompartilhamento 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 dedados, ou seja, a disponibilização dos dados em diferentes formatos;

R3. Prover múltiplos meios de acesso aos conjuntos de dados, que podem ser desdeo 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 doecossistema 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 emdados 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 metada-dos);

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 dedados, distribuições, versões e, preferencialmente, para os itens de cada conjunto dedados;

A seguir, cada requisito é descrito.


4.3.1 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 sejamcompreendidos, por exemplo. A fase de Criação de um conjunto de dados, no ciclo de vidados dados na Web, compreende a extração dos dados das fontes até a sua transformação parao formato adequado para publicação na Web, juntamente com a definição de metadados quefacilitem entendimento dos dados. Nesse sentido, torna-se necessário fornecer mecanismosque permitam a criação de conjuntos de dados associados à descrição necessária para a suacompreensão por terceiros.

Os metadados também são fundamentais para auxiliar a descoberta e a reutilização dedados. Dessa forma, quanto mais completo o conjunto de metadados melhor para uma adequadadescrição dos conjuntos de dados e suas distribuições. Preferencialmente, metadados devem serpadronizados a partir do reúso de vocabulários existentes (ex: DCAT3 e DCMI4). Além disso,devem ser fornecidos de modo que possibilitem tanto a compreensão por usuários quanto o seuprocessamento 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 disponibiliza-dos é 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 processadopor máquina, por exemplo. É importante destacar que existe uma grande variedade de formatosde dados disponível para publicação e troca de dados, no entanto nem todo formato provê aestrutura adequada que facilite o uso e o reúso. Por exemplo, um documento de texto puro podeser facilmente lido por máquinas, mas pode apresentar problemas no uso por diferentes sistemasoperacionais, uma vez que cada sistema operacional têm seu próprio método de informar aocomputador 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 comouma imagem para máquinas.

É necessário promover a criação de distribuições considerando formatos que possamser utilizados por um público amplo. Seja por meio de uma API ou uma interface Web, com odownload em massa, é necessário disponibilizar os conjuntos de dados em diferentes distribuições

3https://www.w3.org/TR/vocab-dcat/4http://dublincore.org/

4.3. REQUISITOS PARA AS SOLUÇÕES DE COMPARTILHAMENTO DE DADOS NAWEB 57para alcançar um maior número possível de consumidores. Fornecendo os dados em mais de umformato, os custos de transformação de dados serão reduzidos, contribuindo para um aumentono número de aplicativos capazes de processar os dados.

Portanto, é necessário possibilitar a criação de múltiplas distribuições para um conjuntode 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 odownload de arquivos até o acesso por meio de APIs

O compartilhamento de dados na Web permite que seres humanos e máquinas usufruamdos benefícios da infraestrutura da Web, que permite um fácil acesso aos dados por meio dosmétodos HTTP. Assim, é importante possibilitar tanto o download em massa dos dados, bemcomo 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 diferen-tes mecanismos de acesso a fim de atender aos requisitos dos diferentes grupos de consumidoresinteressados no conjunto de dados.

As APIs são adequadas para todos os tipos de dados na Web. Quando desenvolvidasde 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 adisponibilização de APIs para permitir a consulta e recuperação dos dados de forma automáticapor aplicações, por exemplo. Ainda que um produtor crie um conjunto de dados a partir doupload de um arquivo, as soluções devem permitir que esses dados também sejam acessadospor meio de uma API. Vale salientar que uma boa documentação da API e uma manutençãoque vise sua preservação complementa este requisito. A preservação da API visa evitar a suaquebra ao longo do tempo, considerando que alterações podem ser necessárias. Assim, novasversões devem ser geradas ao invés de realizar manutenções que venham alterar as chamadas ouestrutura, 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 osdados em um único arquivo, i.e. os dados serão pré-processados e será gerado um único arquivopara 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 ecos-sistema 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 dosdados 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,

4.3. REQUISITOS PARA AS SOLUÇÕES DE COMPARTILHAMENTO DE DADOS NAWEB 58como 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 me-canismos para obter informações sobre as aplicações que usam os conjuntos de dados, comopor 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 eprodutores, além de ajudar na discussão de novas ideias.

Uma outra alternativa é suportar o cadastro de consumidores, uma vez que os produtorespodem desejar saber quem baixou os dados e como eles o usaram. Os próprios consumidorestambé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 deformulários de contato como meio para os consumidores enviem feedback. No entanto, é comumque um feedback vindo de um retorno não estruturado esteja incompleto. Nesse sentido, torna-se importante obter feedback dos consumidores de forma estruturada que permita identificarpossíveis falhas nos dados publicados, a necessidade de publicação de novos dados e possibilitarclassificação dos dados, por exemplo.

Dessa forma, deve-se manter canais de comunicação entre os produtores e consumidorespara coletar o feedback e, adicionalmente, disponibilizar o feedback coletado para todos, parapermitir a troca de experiências, preocupações e dúvidas da comunidade.


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 afonte de origem. Assim, à medida que ocorrerem atualizações nas fontes de origem, os dadospublicados na Web também devem ser atualizados. Para que o consumidor tenha ciência dequando os dados são atualizados, é importante informar a frequência de atualização por meiodos 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 é in-formado uma frequência de atualização por meio dos metadados, sem garantia que os dadosestão sendo atualizados conforme informado na frequência. Comumentemente, o próprio pro-dutor é responsável por essa atualização, sendo necessário um grande esforço dele para seguira frequência informada. O cenário se torna mais crítico uma vez que muitos conjuntos dedados apresentam determinadas frequências de atualização nas fontes que não são refletidas nosconjuntos de dados na Web.

Dessa forma, é fundamental garantir que os conjuntos de dados serão atualizados de

4.3. REQUISITOS PARA AS SOLUÇÕES DE COMPARTILHAMENTO DE DADOS NAWEB 59acordo com sua a frequência pré-definida e que esse processo seja apoiado por ferramentas quepermitam a atualização dos dados de forma automática. De modo geral, a garantia de atualizaçãose dá ao passo que a fonte de dados de origem pode ser acessada para extrair os dados necessáriosde forma automática. Após a extração, os dados são atualizados e uma nova versão do conjuntode dados é gerada. Esse processo deve ser repetido de acordo com a frequência de atualizaçãodefinida para cada conjunto de dados.

R6. Prover mecanismos para a extração e transformação dos dados de origem em dadosna Web

Para possibilitar a publicação dos conjuntos de dados e garantir que estarão atualiza-dos conforme sua fonte de dados de origem, mecanismos que permitam realizar a extraçãoe transformação dos dados tornam-se necessários. De modo geral, deve ser possível extrairos dados automaticamente a partir de diferentes fontes de dados e, posteriormente, realizar atransformaçã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 partirde diferentes tipos de fontes de origem, como bancos de dados convencionais ou até mesmoarquivos. Além da extração dos dados, também são necessários mecanismos para realizartarefas de transformação e limpeza nos dados, a fim de melhorar a qualidade dos dados antes dasua publicação na Web. É importante ressaltar que, em alguns casos, os dados foram criadospreviamente sem uma intenção de compartilhamento, logo podem apresentar problemas comoausência de valores ou valores inconsistentes. Nesse processo, o enriquecimento de dados podeser 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 preenchendovalores ausentes ou gerando novos dados por técnicas de inferência, por exemplo.

Também é importante prover alternativas para problemas estruturais, como a ausênciade 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, adescrição dos campos e tipos de dados usados têm que ser disponibilizados em um arquivoseparado. No entanto, como é opcional, nem sempre é disponibilizado e torna o entendimentodos 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 paraapoiar o produtor nessa atividade e garantir uma melhor descrição dos dados.


R7. Prover mecanismos para o gerenciamento de versões de conjuntos de dados


Como se sabe, os conjuntos de dados podem ser alterados ao longo do tempo, seja pararealizar 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ãopoucos os meios disponibilizados pelas ferramentas atuais para garantir um gerenciamento deversões adequado.

A partir do gerenciamento de versões, situações comuns, como quando os dados sofrematualizações, não deve acarretar na exclusão das distribuições dos conjuntos de dados da Web parapublicação de novas distribuições. Pois, esse procedimento desconsidera a possível utilizaçãoatual dos dados já publicados. Nesses casos, uma nova versão do conjunto de dados deveria sergerada, permitindo o acesso tanto a versão anterior quanto a nova versão, tornando o conjunto dedados confiável

Também deve ser possível o controle de versões até mesmo para os conjuntos de dadosque possibilitam o acesso em tempo real aos dados, o que pode ser controlado por meio da data ehora. É importante deixar claro a abordagem que é utilizada no controle das versões, informandoquando uma nova versão é gerada.

Portanto, este requisito considera que uma solução de compartilhamento de dados naWeb deve ser capaz de fornecer serviços para o gerenciamento automático de versões, provendoacesso 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 fundamentalpara 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 entendermelhor o significado dos dados e sua estrutura, além de outras questões, como a licença e aqualidade dos dados. Somado a isso, também são fundamentais para a descoberta e reutilizaçãodos conjuntos de dados.

As soluções de compartilhamento de dados na Web devem ser apoiadas por um processode 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 disponi-bilidade e qualidade dos metadados (, 2016). É fundamental que todos os metadados sejamacessíveis por humanos e por máquinas, e.g. possibilitando a recuperação das informações viaInterface Web e via Interface Remota.

A curadoria de metadados deve garantir que todas as informações sobre os conjuntos dedados, 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íveisao longo do tempo, para que possam ser adequadamente utilizados. Além disso, acrescentaque é necessário uma gestão eficiente e a preservação para que eles possam ser descobertos ereutilizados. Sem a gestão dessas informações, os conjuntos de dados são esquecidos ou só são

4.3. REQUISITOS PARA AS SOLUÇÕES DE COMPARTILHAMENTO DE DADOS NAWEB 61utilizados uma única vez. Nesse sentido, a curadoria de metadados pode ser entendida comoum processo contínuo que gerencia os metadados e sua utilização, tanto melhorando quantoenriquecendo 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 osconjuntos de dados acessíveis para preservar o seu acesso e apresentar informações sobre o seupossível arquivamento. Em geral, quando um conjunto de dados não está mais acessível, todosque estão consumindo os dados, ao solicitar um novo acesso, serão redirecionados para o erroHTTP 404. Este erro é um código de resposta HTTP que indica que houve a comunicação com oservidor, mas ele não encontrou o que foi pedido. Assim, o consumidor de dados não saberá se aindisponibilidade é temporária, permanente, planejada ou acidental.

Isso não quer dizer, no entanto, que um conjunto de dados não possa ser removidoda 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 oarquivamento e possibilitar o acesso ao arquivo que contém os dados ou como um usuário podesolicitar o acesso. Portanto, a garantia de preservação dos conjuntos de dados é um requisito dassoluções de compartilhamento de dados na Web, que deverão manter o acesso a URI originaldos conjuntos de dados.


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 gerenciamentode dados na Web garantam o uso de URIs persistentes como identificadores de conjuntos dedados, 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 comoidentificadores dentro dos conjuntos de dados, i.e. que dados possam ter links para outras URIsde 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

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 queseja possível "dereferenciar"a URI de um conjunto de dados mesmo ele não estando disponível efornecer informações sobre o seu arquivamento, por exemplo.

4.4 Análise das soluções existentes de acordo com os requisi-tos

No Capítulo 3 fizemos uma análise das soluções de catalogação de dados frente àsrecomendações de boas práticas. Nesta seção, fazemos novamente uma breve análise dassoluções, porém, considerando os requisitos elencados neste Capítulo, o que complementaa análise anteriormente realizada. Por exemplo, enquanto na análise anterior verificamos seconstavam 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 Quadro4.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 AtendeFonte: o autor

De forma geral, verificamos que as soluções existentes tem um foco maior na publicaçãodos 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 queas soluções analisadas utilizam apenas um subconjunto do DCAT para descrever os conjuntosde dados. Ainda sim, o CKAN, DKAN e o Junar não permitem o cadastro de metadadosestruturais. O ArcGIS Open Data, OpenDataSoft e o Socrata, oferecem mecanismos paracoletar os metadados estruturais, identificando automaticamente os tipos de dados e permitindoque 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 demetadados 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


de forma automática. O produtor de dados tem que carregar os arquivos em diferentes formatoscomo "recursos". No entanto, identificamos que o conceito de recursos dessas soluções divergedo que consideramos como distribuição, uma vez que por meio dos recursos é possível até mesmoque o produtor de dados disponibilize outros conjuntos de dados. Também identificamos que oJunar apresenta o conceito de recursos para um conjunto de dados, que neste caso podem sergráficos ou visualizações de dados (data view), mas não apresentam o conceito de distribuições enão disponibiliza os dados em múltiplos formatos. As demais soluções possibilitam a criação demú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 dosdados no maior número de formatos.

O CKAN e o DKAN permitem realizar o download dos dados em massa, mas nãopermitem 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 permitira criação de subconjuntos de forma automática, quando mais de um subconjunto é disponibilizadocomo recurso, o DKAN possibilita o pré-processamento dos dados no servidor gerando um únicoarquivo 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 consumidoresrealizem filtros e acessem subconjuntos de dados. No entanto, apenas o Socrata e o Junar permiteo download de subconjuntos de dados criados dinamicamente pelo consumidor. Portanto, oSocrata e o Junar se aproximam mais do que se espera de uma solução de compartilhamento dedados na Web quanto ao acesso aos dados.

De modo geral, as soluções adotam poucos mecanismos para comunicação entre osprodutores e consumidores. O DKAN não apresenta mecanismos para comunicação. O CKAN eo ArcGIS Open Data permitem que os consumidores cadastrem comentários em cada conjuntode dados. O OpenDataSoft permite que seja cadastrado o reúso do conjunto de dados, seja umaaplicação ou os dados usados, permite que seja cadastrado um título, descrição, URL e umaimagem. O Junar permite que os consumidores criem visualizações dos dados, realizando filtrosnos dados, e descrevendo o uso delas e é disponibilizado para os demais consumidores, apósaprovação do produtor. Neste requisito, mais uma vez, podemos destacar o Socrata, pois além depermitir que comentários sejam cadastrados nos conjuntos de dados, permite que eles enviemmensagens para o produtor e também salvem as visualizações dos dados para disponibilizarpara todos. Além disso, ele também permite que os consumidores efetuem o cadastro, o quepossibilita 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ãogarantem acesso a dados atualizados de acordo com a fonte de origem. O ArcGIS Open Datagarante o acesso quando o conjunto de dados publicado é oriundo de dados gerenciados peloservidor ArcGIS. O OpenDataSoft fornece acesso a dados atualizados, dado uma frequênciade atualização, desde que os conjuntos de dados sejam cadastrados a partir de dados na Webacessíveis por uma URI. A frequência de atualização deve ser informada quando uma tarefa


agendada for criada dentro da plataforma, para que a ferramenta possa executar a extração eatualização dos dados. O Socrata garante o acesso a dados atualizados quando são acessados porserviços online ou por meio do uso da ferramenta DataSync. Essa ferramenta permite selecionararquivos que deverão ser atualizados online, sendo necessário executar processos adicionaispara extração dos dados e para criar tarefas agendadas no sistema operacional para processara sincronização dos dados. Assim, para acesso a bancos de dados relacionais, por exemplo, énecessário usar ferramentas como o Pentaho Kettle5 e o FME Server6 para realizar as atividadesde extração dos dados e, posteriormente, salvar o arquivo no sistema operacional para o DataSyncenviar os dados para a plataforma online.

O CKAN e o DKAN também não atendem ao R6. No Junar, não é possível realizara extração dos dados quando um dataset é cadastrado. No entanto, quando é criado umavisualização de dados, seus processos automáticos acessam a URI do conjunto de dados erealizam a extração e transformação dos dados de origem em dados na Web. O ArcGIS OpenData não oferece opção para extração. O Socrata possibilita a extração e transformação dos dadosquando é cadastrada uma URI, tal como o OpenDataSoft. Somado a isso, durante o processode 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 bancosde dados convencionais.

De modo geral, todas as soluções de catalogação analisados utilizam apenas um subcon-junto do DCAT para coletar informações (metadados) sobre os conjuntos de dados e distribuições.Verificamos que falta um maior suporte delas para coletar informações sobre qualidade e versio-namento, além de prover o processo de curadoria das demais informações como das aplicações edos consumidores. Foi possível observar que apenas o ArcGIS Open Data, OpenDataSoft e oSocrata 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 apesarnão possibilitar o gerenciamento automático de versionamento, permite o cadastro do indica-tivo da versão. O Junar, Socrata e o OpenDataSoft gerenciam a frequência de atualização dosconjuntos 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 dadose distribuições, atendendo ao requisito R10. No entanto, quanto ao requisito R9, nenhuma dassoluções analisadas garante a preservação dos conjuntos de dados ao longo do tempo. Elaspermitem a exclusão dos dados e não preservam o acesso. É necessário manter os identificadoresativos, para que os consumidores obtenham informações acerca do conjunto de dados, bem comosobre o seu arquivamento e como é possível recuperá-los novamente.

Portanto, conclui-se que as soluções atuais apresentam lacunas quanto aos requisitosnecessários para uma solução de compartilhamento de dados na Web, como o gerenciamentode versões, curadoria de metadados, comunicação com os consumidores e produtores, e a

5http://www.pentaho.com/product/data-integration6https://www.safe.com/solutions/for-applications/socrata/


preservação dos conjuntos de dados. O conjunto desses requisitos norteiam os principais serviçospropostos para um Sistema Gerenciador de Dados na Web (SGDW) e que são discutidos nopróximo Capítulo.

666666

5Sistemas Gerenciadores de Dados na Web -SGDW

No Capítulo anterior foram discutidas as premissas e os requisitos para o compartilha-mento de dados na Web. Neste Capítulo, apresentamos o modelo de arquitetura proposto paraum Sistema Gerenciador de Dados na Web. Dessa forma, na Seção 5.1 apresentamos a visãogeral de um SGDW e os detalhes do modelo de arquitetura proposto. Na Seção 5.2 discorremossobre os principais serviços necessários para um SGDW e, por fim, a Seção 5.3 apresenta umaconclusão deste Capítulo.

5.1 Visão geral de um SGDW

Considerando as premissas e requisitos discutidos no Capítulo anterior, temos que umasolução para compartilhamento de dados na Web deve ser capaz de realizar tarefas que vão muitoalém da catalogação de dados. Nesse contexto, neste trabalho propomos uma solução que procurapreencher as lacunas de gerenciamento de dados deixadas pelas soluções para publicação dedados disponíveis atualmente. A fim de atender aos requisitos listados anteriormente, propomoso Sistema de Gerenciador de Dados na Web (SGDW), ou seja, uma solução capaz de realizartanto as tarefas já desempenhadas pelos ambientes de catalogação de dados quanto às tarefasrelacionadas ao gerenciamento dos dados propriamente ditos.

Um Sistema Gerenciador de Dados na Web (SGDW) é uma coleção de serviços quepermite 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 entrediversos usuários e aplicações.

A definição de um conjunto de dados envolve a especificação dos tipos de dados, bemcomo das demais informações descritivas do conjunto de dados, denominadas metadados. Acriação de um conjunto de dados é o processo de criar as diferentes distribuições do conjunto. Amanutenção de um conjunto de dados consiste na atualização dos conjuntos de dados a fim derefletir mudanças no mundo real. A manipulação de um conjunto de dados inclui funções como

5.1. VISÃO GERAL DE UM SGDW 67

o acesso aos conjuntos de dados. O compartilhamento de um conjunto de dados permite quediversos 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 aseguir.

Figura 5.1: Modelo de Arquitetura para um SGDW. Fonte: o autor

5.1.1 Camada de Acesso

A Camada de Acesso provê uma Interface Web e uma Interface Remota (API). Estacamada 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áriocom o restante do sistema e deve prover módulos de acesso para os consumidores e para osprodutores. Para os produtores, deve ser possível gerenciar os conjuntos de dados, possibilitandoa criação, publicação e preservação de conjuntos de dados, bem como permitindo a realização deanálises sobre o uso dos conjuntos de dados. Para os consumidores, deve ser possível realizarbuscas facetadas e aplicar filtros nos metadados e dados, acessar os conjuntos de dados, envio defeedback, cadastro do uso e monitoramento dos conjuntos de dados de seu interesse.

5.1. VISÃO GERAL DE UM SGDW 68

Já a Interface Remota (API) deve permitir a recuperação dos dados e metadados pormeio de protocolos de comunicação remota. Essa interface deve ser projetada para ser simples econcisa, permitindo a recuperação dos dados e metadados armazenados. Dessa forma, ao invésde limitar a recuperação de informação apenas por páginas HTML, a interface remota permiteo desenvolvimento de aplicações que se apropriem dos dados para agregação de valor e deutilidade para as informações, apesar de requerer conhecimentos técnicos de programação. Elatambém deve possibilitar que os desenvolvedores consultem os conjuntos de dados disponíveisno sistema.

5.1.2 Camada de Serviços

A Camada de Serviços é a responsável pelo gerenciamento dos conjuntos de dados emetadados. De modo geral, todos os requisitos listados no Capítulo anterior são mapeados comoserviços nessa camada, os quais podem ser acessados a partir da Interface Web e da InterfaceRemota disponíveis na Camada de Acesso.

Resumidamente, temos o serviço de Extração e Transformação de Dados, que acessaas fontes de dados de origem para permitir a criação dos conjuntos de dados juntamente comsuas respectivas distribuições. Uma vez criado o conjunto de dados, o serviço de Gerenciamentode Versões ficará responsável por garantir o registro do seu histórico de versionamento, bemcomo a correta identificação das diferentes versões. O serviço de Gerenciamento de Atualizaçõesgarante que o conjunto de dados estará sempre atualizado conforme as atualizações em sua fontede dados de origem. O serviço de Gerenciamento de Acesso garante o acesso aos conjuntos dedados, levando em consideração as diferentes versões e distribuições. Dessa forma, os conjuntosde dados poderão ser reusados pelos consumidores e será possível, para os produtores, obterfeedback e realizar a análise do seu uso. O serviço de Preservação garante que todos os conjuntosde dados criados estarão acessíveis, possibilitando a recuperação dos dados ou informações decomo é possível recuperá-los. Por fim, o serviço de Gerenciamento de Metadados é responsávelpor gerenciar todos os metadados relacionados aos conjuntos de dados, distribuições, aplicações,consumidores e produtores.

Na Seção 5.2, detalharemos cada um dos serviços que compõem a Camada de Serviços.

5.1.3 Camada de Dados e Metadados

A Camada de Dados e Metadados é composta pelas fontes de dados de origem e peloarmazenamento interno dos dados e metadados. As fontes de dados de origem são as fontes dedados a partir das quais é possível extrair dados para compartilhamento na Web. Dentre essasfontes, 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 doserviço de Extração e Transformação de Dados, se comunica com essa camada para realizar aextração dos dados e transformá-los para publicação na Web.

5.2. DETALHAMENTO DA CAMADA DE SERVIÇOS 69

O armazenamento interno deve oferecer um Repositório de Metadados e um Repositóriode Conjuntos de Dados. O primeiro armazenará todos os metadados associados aos conjuntos dedados, aplicações, produtores e consumidores, enquanto que o segundo repositório pode ser vistacomo 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 consumidoresnã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 arquite-tura apresentada na seção anterior. Os serviços foram especificados de acordo com os requisitoslevantados 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 umindicador de versão, que pode ser a data ou um número, também permite listar todas as versõesgeradas, seguindo as recomendações da recomendação DWBP.

Somado a isso, nos serviços descritos a seguir, consideramos que os conjuntos dedados 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 dedados 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 deorigem 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 dedados de origem é um arquivo;

Vale salientar que independente da fonte de dados, os conjuntos de dados devem serarmazenados no repositório de dados do SGDW para que seja possível prover todos os serviçosde gerenciamento.

Para cada cenário, também devemos considerar aspectos inerentes a cada tipo de fonte dedados de origem para possibilitar a extração dos dados. Para os conjuntos de dados do CenárioA, em que as fontes de dados são os bancos de dados, como bancos de dados acessíveis porum SGBD, deve ser necessário obter o host, usuário, senha e o nome do banco de dados paraestabelecer uma conexão com a fonte de dados. Para os conjuntos de dados do Cenário B, deveser 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 partirde arquivos, estes devem ser carregados no sistema.


5.2.1 Extração e Transformação dos Dados

O serviço de Extração e Transformação de Dados deve intermediar as requisições deobtenção e transformação dos dados. Este serviço deve ter por objetivo automatizar a obtençãodos 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. Apartir da fonte de dados, deve-se verificar a necessidade de estabelecer ou não uma conexãopara 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árioestabelecer a conexão, os dados devem ser recuperados a partir dos arquivos. À medida queos 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óriode dados. Dessa forma, o processo de enriquecimento pode utilizar técnicas de inferência parapreencher valores ausentes ou gerar novos dados como, por exemplo, dados de localização apartir de dados de coordenadas. Do mesmo modo, a transformação dos dados deve possibilitarprocessos de limpeza nos dados, como a remoção de registros duplicados, e atividades quepermitam transformar os dados originais em dados na Web, como alterar as abreviações dosEstados Brasileiros em seus respectivos nomes.

5.2.2 Criação de conjuntos de dados

O serviço de Criação de Conjuntos de dados permite que o produtor defina quais dadosdeseja publicar, cadastre informações por meio de metadados e dê início ao processo de extração


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óscadastrar 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 dadospreviamente cadastrada e um teste é realizado para verificar se é possível estabelecer a conexãocom a fonte de dados. Se a fonte de dados permitir o acesso, o produtor definirá quais os dadosque devem ser coletados. Sendo de uma fonte de dados acessíveis por um SGBD relacional, oprodutor 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 osdados 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 abordadoscomo boas práticas e definidos no serviço de Gerenciamento de Metadados, como os metadadosdescritivos, estruturais, de proveniência, acesso, qualidade, versão e licença. Deste modo, oprodutor 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 apartir dos dados armazenados e do cadastro do produtor, respectivamente. Além disso, o produtor


deverá informar a frequência de atualização do conjunto de dados, que será utilizada pelo serviçode 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 disponibilizadossubconjuntos dos dados. Assim, o produtor poderá definir critérios para selecionarsubconjuntos ú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ãodisponibilizados, i.e. quais as distribuições do conjunto de dados. Os dados devemestar disponíveis em múltiplos formatos, como XML, RDF, CSV e JSON, para quesejam 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 pormeio da API. O Gerenciamento de Distribuições permitirá que tais formatos sejamgerados sem a necessidade de conversão por parte do produtor. Assim, independentedo formato original dos dados, deve ser possível recuperar os dados em formatosdistintos 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 osdemais serviços como o Gerenciamento de Atualizações, para dados acessíveis por conexõescadastradas, e o Gerenciamento de Acesso.

5.2.3 Gerenciamento de Metadados

O serviço de Gerenciamento de Metadados é responsável por gerir as informações quedescrevem os conjuntos de dados, distribuições, subconjuntos, produtores e consumidores. Esteserviço deve prover o uso de termos padronizados para descrever os metadados objetivandoaumentar a interoperabilidade, reduzir ambiguidade e redundância nos termos utilizados. Alémdisso, também deve ser apoiado por um processo de curadoria que além de garantir a descriçãoadequada dos conjuntos de dados, também possibilite o enriquecimento, análise e preservaçãodos 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 problemasquanto a utilização de esquemas conceituais diferentes, a atribuição de sintaxes diferentes a


conceitos correspondentes e quanto às diferentes interpretações para os dados. Somado a isso, acuradoria de metadados também ajuda a lidar com a variabilidade dos níveis de qualidade e adiversidade de tipos de metadados. Mais detalhes sobre processos de curadoria de metadadossão apresentados em Higgins (2008), Ball (2012), (2016).

De forma geral, o Gerenciamento de Metadados recebe requisições e garante que osconjuntos de dados estarão adequadamente descritos por meio dos metadados. O fluxo deatividades 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 é umaatualização ou criação de metadados, por exemplo, se a requisição é de criação ou atualização deconjunto de dados. Não sendo uma atualização, os metadados serão criados a partir do conjuntomínimo de metadados necessário para descrever adequadamente o novo item, que pode serum conjunto de dados ou um consumidor, por exemplo. Posteriormente, os metadados devemser coletados e, sendo possível, enriquecidos antes de serem armazenados no repositório demetadados (, 2016). No caso de uma atualização automática realizada por outros serviços doSGDW, 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, metadadosespecíficos são atualizados de forma automática. No entanto, para atualizações realizadas porum produtor em um conjunto de dados, por exemplo, é necessário recuperar os metadadosnecessários para uma adequada descrição antes de armazená-los.

O conjunto mínimo de metadados deve ser obtido a partir do conjunto de processosda curadoria de metadados, que deve levar em conta o reúso de vocabulários utilizados nessecontexto, como o DCAT1 e o DCMI2, além das boas práticas de Dados na Web do W3C. Dessa

1https://www.w3.org/TR/vocab-dcat/2http://dublincore.org/


forma, ao descrever um conjunto de dados, será garantido que os metadados necessários para aadequada descrição deles estão sendo cobertos. Por exemplo, de acordo com o DWBP deverão sercoletados 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), datade publicação (dct:issued), publicador (dct:publisher) e categoria (dcat:theme).

5.2.4 Gerenciamento de Versões

Dado que os conjuntos de dados podem ser alterados ao longo do tempo, tanto por umacorreção, melhoria ou inserção de novos dados, o serviço de Gerenciamento de Versões mantémas diferentes versões de um mesmo conjunto de dados e possibilita o acesso a elas. Não existeconsenso sobre quando uma nova versão deve ser gerada, mas assumimos que uma nova versãodo conjunto de dados deverá ser gerada para cada alteração nos dados ou metadados do conjuntode dados. De modo geral, o fluxo de atividades deste serviço é ilustrado na Figura 5.5.


Figura 5.5: Fluxo de Atividades para o Serviço de Gerenciamento de Versões. Fonte: oautor

Quando for realizado qualquer tipo de alteração de dados em um conjunto de dados, ogerenciamento 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 sofreras atualizações) e a nova versão que será gerada. Posteriormente, as alterações são persistidase a nova versão será gerada. Dessa forma, novos identificadores são gerados para garantiracesso à versão anterior e a nova. Por fim, o serviço de Curadoria de Metadados realiza asalteraçõ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 oprodutor 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çãodos conjuntos de dados. Em outras palavras, a garantia de que o consumidor poderá sempreutilizar a versão de dados mais recente, parte do pressuposto que será fornecido acesso a fontede dados de origem. Dessa forma, quando um conjunto de dados for atualizado conforme sua


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, é importantearmazenar apenas a diferença dos dados, ou seja, os novos dados. Sendo de exclusão, as linhasdevem ser marcadas como não ativas. Sendo de alteração, a linha antiga deve ser marcada comoinativa e a linha alterada inserida como uma nova. No processo de recuperação de versõesanteriores a atual, todas as alterações que foram realizadas devem ser recuperadas de um logde alterações e desfeitas até a versão desejada. Quando a atualização envolver a estrutura doconjunto 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 aosdados, 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 sofrematualizações ou exclusões, geralmente eles apresentam a necessidade de inserir novos dados deforma frequente, como é o caso dos dados obtidos a partir de sensores. Para esses casos, deve serarmazenado a data/hora que eles foram obtidos e versioná-los a partir dela. Para o caso de alterara estrutura, ele deverá ser armazenado e uma nova versão deverá ser gerada, também permitindoa 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 garantiro acesso a última versão disponível do conjunto de dados dados. Sendo especificada, deve serretornado 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 maisatual é a X-v4. Dessa forma, quando for solicitado os dados do conjunto de dados X e não forespecificado nenhuma versão, deve ser retornado os dados da versão mais recente. Para tornar oconjunto 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 queseja especificado a versão desejada para garantir a recuperação dos respectivos dados. Somado a


isso, quando os dados forem consumidos por meio da API e o consumidor não desejar trabalharsempre com os dados mais atuais, a versão do conjunto de dados atual, no momento do uso,deverá ser informada.

5.2.5 Gerenciamento de Atualização

O serviço de Gerenciamento de Atualização tem por objetivo garantir que os conjuntosde dados serão atualizados dado sua frequência de atualização pré-definida. Quando os conjuntosde dados são criados a partir de uma fonte de dados que permita acesso ao banco de dados ouAPI na Web, é possível mantê-los atualizados dado a frequência de atualização. A Figura 5.7mostra 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 deatualização para os conjuntos de dados que serão criados a partir de acessos à bancos de dadosou APIs. Dessa forma, o serviço de gerenciamento de atualização garante o monitoramento eintegraçã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 dedados tem que ser atualizado. Se estiver no momento de atualização, ele se conecta ao serviço deExtração e Transformação de dados para obter os dados atualizados. Posteriormente, é realizadouma chamada ao serviço de Gerenciamento de Versões que verifica as alterações realizadas egera uma nova versão, bem como para o serviço de Curadoria de Metadados que atualiza osmetadados. Geralmente, as frequências de atualização são consideradas por hora, diariamente,


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 oscenários descritos anteriormente:

� Cenário A:

Ele poderá ser considerado atualizado, uma vez que não houve alteração na fonte dedados 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 deverificação de atualizações e permanecer a última data de alteração, informando quenã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 arquivoatualizado. 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 aorigem (quem gera o arquivo) e o servidor onde o SGDW estará instalado. Assim, aferramenta deve permitir que o produtor crie um vínculo do arquivo offline com oconjunto de dados, enviando os dados para que sejam extraídos e transformados.

Para que o produtor possa acompanhar todas as atualizações realizadas, é importantemanter um log de erros e alertas, para que seja possível saber os motivos da não atualização.

5.2.6 Gerenciamento de Acesso

O serviço de gerenciamento de acesso garante que os dados armazenados no repositóriode dados poderão ser recuperados por meio de download em massa e por meio de uma API. Noprocesso de criação de um conjunto de dados, o produtor pode definir como o conjunto de dadose os subconjuntos serão disponibilizados.

O processo de desenvolvimento de APIs, de forma manual pelos produtores, apresentaum custo associado ao tempo de desenvolvimento, por exemplo. Dessa forma, é necessáriofacilitar a criação automática de APIs para acesso aos conjuntos de dados. Com os conjuntos dedados criados e os dados armazenados, este serviço garante a criação de forma padronizada eautomática das APIs nos Cenários A, B e C.

Assim, por meio das APIs, os consumidores poderão recuperar os dados e metadadosenviando requisições HTTP, usando os métodos GET e POST, a partir de URIs exclusivas dosconjuntos de dados. Usando o método GET, deve ser possível recuperar dados e metadados a


partir de métodos já definidos na API. Além disso, deve ser reservada a possibilidade de realizarbuscas avançadas e personalizadas enviando requisições POST, especificando os parâmetrosdesejados. Assim, será possível recuperar subconjuntos dos dados, sejam os definidos peloprodutor ou a partir dos filtros realizados pelos consumidores. Somado a isso, deve ser possívelacessar as diferentes versões de um conjunto de dados.

É importante ressaltar que a API deve ser bem documentada, garantindo que todasos métodos, funções e opções sejam conhecidas pelos consumidores para que seja possívelseu uso. Uma API também deve prever uma manutenção de forma que todos os métodos eacesso disponibilizados sejam preservados ao longo do tempo. Assim, tendo necessidade dealterações das respostas, métodos ou acesso, uma nova API ou uma nova versão dela deve serdisponibilizada, mantendo todos os acessos anteriores ativos.

Quanto ao download em massa dos dados, o SGDW deve garantir que será possívelrealizar o download dos subconjuntos dos dados de forma separada ou ainda, a partir de umpré-processamento do lado do servidor, permitir o download de todos os dados em um únicoarquivo. Também é necessário que download em massa seja permitido tanto através da InterfaceWeb 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 receberos 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: oautor

Os consumidores enviam as requisições para o sistema que valida os parâmetros recebidos


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 solicitadosubconjuntos dos dados, os dados são filtrados conforme os parâmetros informados e a versãoescolhida. Dessa forma, os dados serão recuperados e serão formatados de acordo com o formatoescolhido pelo consumidor ou, caso não seja definido um formato, os dados serão formatados emJSON. Por fim, verifica-se o tipo de retorno dos dados, sendo gerado um arquivo para downloadno formato escolhido ou imprimindo a saída.

5.2.7 Preservação dos Conjuntos de dados

Como dito anteriormente, um conjunto de dados apresenta três fases: criado; publicadoe preservado. Dentre elas, a preservação é a fase quando o produtor sinaliza a intenção dedescontinuar 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 con-juntos de dados compartilhados na Web pelo produtor terão sua URI preservada, possibilitandoo acesso aos metadados e/ou aos dados. De modo geral, para preservação de um conjunto dedados, é 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 sina-lizando o desejo de preservá-lo. Dessa forma, serão interrompidos os serviços de atualizaçãoautomática e versionamento. Uma vez que o conjunto de dados não será mais atualizado, oprodutor 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 informadoo tipo de preservação (se arquivamento ou completa remoção) e uma descrição do motivo dapreservação. Um conjunto de dados pode ser descontinuado devido a sua completa remoção oudevido ao seu arquivamento. Se for removido, a URI de acesso será preservada e os dados não


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 deresposta HTTP 410, indicando que o recurso está intencionalmente indisponível e que o produtordeseja que o acesso ao conjunto de dados seja removido. Essa resposta se estenderá para todasas URIs do conjunto de dados, i.e. para as distribuições, versões e subconjuntos. Já quando oconjunto 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.

5.2.8 Gerenciamento do Uso dos Dados

Rastrear o uso dos conjuntos de dados permite ao produtor saber se os dados estão sendousados ou não, além de possibilitar a identificação de possíveis melhorias, falhas e correçõesnos dados. No entanto, os consumidores carecem de maneiras eficazes para descrever e discutirexperiê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 sobreas aplicações geradas a partir dos dados, receber comentários de feedback e permitir o cadastrodos consumidores de conjuntos de dados específicos. O fluxo de atividades deste serviço éapresentado na Figura 5.10.

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, realizara avaliação de um conjunto de dados ou cadastrar uma aplicação. Caso o consumidor desejerealizar seu cadastro ou efetuar login, será possível gerenciar as aplicações e comentários defeedback cadastrados em sua área. Para realizar o cadastro de um aplicação, o consumidor


deve preencher as informações necessárias sobre a aplicação, como os conjuntos de dados queusou 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ériospré-definidos ou para a avaliação geral de um conjunto de dados. Por fim, se for um comentáriode feedback, os consumidores poderão solicitar novos dados ou correções, informar ausência demetadados 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 dedados estão sendo usados e para a representação de feedback. De uma perspectiva de interfacede usuário, o DUV exemplifica maneiras de coletar feedback, como registro no site, formuláriosde 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 sercoletados os dados que são usados, uma descrição do que a aplicação faz, o problema que ajudaa resolver e a URI de acesso ou download(OLIVEIRA; LÓSCIO, 2014). Somado a isso, outrosmetadados 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 conformedescritos no DUV. Assim, os consumidores devem ter a possibilidade de realizar a classificaçãodos conjuntos de dados preenchendo formulários que apresentem critérios pré-definidos e umintervalo discreto de valores. Por exemplo, um formulário que permita que o consumidorinforme o nível de qualidade do conjunto de dados considerando uma avaliação por estrelas eselecionando uma opção de 1 a 5 estrelas.

Somado a isso, os conjuntos de dados podem apresentar inconsistências de metadadospreenchidos pelo produtor ou apresentar erros nos dados. Assim, deve ser possível que umconsumidor envie feedback para preencher metadados ausentes ou inconsistentes, assim comocomentários sobre erros detectados nos dados. Para tanto, deve ser fornecido um formulário quecolete o motivo do feedback (se inconsistência, ausência, comentário, solicitação, sugestão), otexto de comentário, o consumidor que está comentando e o conjunto de dados ou distribuiçãorelacionada, por exemplo.

Também deve ser possível que um consumidor possa realizar seu cadastro no SGDWpara acompanhar conjuntos de dados desejados, gerenciar as aplicações cadastradas e receberalertas. Por exemplo, um consumidor pode receber alertas de novos conjuntos de dados de seuinteresse ou avisos de respostas de um comentário de feedback. Para o cadastro do consumidor,pode ser coletado o nome, e-mail, 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 devemacompanhar o uso dos conjuntos de dados a partir de estatísticas, como estatísticas de acessoe download, ter a possibilidade de visualizar as aplicações cadastradas e os interesses dosconsumidores.

3https://www.w3.org/TR/vocab-duv/

5.3. CONCLUSÃO 83

5.3 Conclusão

Considerando as premissas e requisitos discutidos no capítulo anterior, temos que umasolução para compartilhamento de dados na Web deve ser capaz de realizar tarefas que vãomuito além da catalogação de dados. Nesse contexto, neste trabalho propomos um modelo dearquitetura que procura preencher as lacunas de gerenciamento do conjuntos de dados deixadaspelas 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çãocapaz de realizar tanto as tarefas já desempenhadas pelos ambientes de catalogação de dadosquanto às tarefas relacionadas ao gerenciamento dos dados propriamente ditos. Para tanto, foiproposto um modelo de arquitetura para um SGDW que é composto por uma camada de Dados eMetadados, uma camada de Serviços e uma camada de Acesso.

A camada de Dados e Metadados deve permitir o armazenamento dos dados e metadadosdos conjuntos de dados e a camada de Acesso deve prover interfaces que permitam o uso dosserviços disponíveis. Já a camada de Serviços deve ser composta por serviços que permitem ogerenciamento dos conjuntos de dados e metadados. Cada serviço proposto atende um ou maisdos requisitos detalhados no Capítulo anterior. O Quadro 5.1 apresenta os requisitos elencadospara o compartilhamento de dados e os serviços do modelo de arquitetura proposto que atendemaos requisitos.

5.3. CONCLUSÃO 84

Quadro 5.1: Premissas e Requisitos para o compartilhamento de dados x Serviços do modelo dearquitetura proposto

Premissa Requisitos ServiçosPremissa 1: Não existe umconhecimento prévio entreos responsáveis peladisponibilização dos dados eos interessados em fazer usodos dados

R1. Prover mecanismos para a criação de conjun-tos de dados auto-descritivos

Criação de conjuntosde dados

R2. Possibilitar a criação de múltiplas distribui-ções para um mesmo conjunto de dados, ou seja, adisponibilização dos dados em diferentes formatos

Gerenciamento deDistribuições

R3. Prover múltiplos meios de acesso aos conjun-tos de dados, que podem ser desde o download dearquivos até o acesso por meio de APIs

Gerenciamento deAcesso

R4. Prover mecanismos para a criação de canaisde comunicação entre os atores do ecossistema dedados na Web

Gerenciamento doUso dos Dados

Premissa 2: Os conjunto dedados podem ter origem emfontes de dados já existentes

R5. Garantir o acesso a dados atualizados deacordo com a fonte de origem

Gerenciamento deAtualização

R6. Prover mecanismos para a extração e transfor-mação dos dados de origem em dados na Web

Extração e Transfor-mação de Dados

Premissa 3: Os conjuntos dedados não são estáticos, ouseja, podem sofreratualizações na descrição ounos dados ao longo tempo

R7. Prover mecanismos para o gerenciamento deversões de conjuntos de dados

Gerenciamento deVersões

R8. Prover mecanismos para o gerenciamento demetadados (curadoria de metadados)

Gerenciamento deMetadados

R9. Garantir a preservação dos conjuntos de dadosao longo do tempo

Preservação dos Con-juntos de Dados

Premissa 4: Os princípios ar-quiteturais da Web devem serseguidos

R10. Garantir o uso de identificação única, pormeio de URIs, para os conjuntos de dados, distri-buições, versões e, preferencialmente, para os itensde cada conjunto de dados

Gerenciamento deURIs

Fonte: o autor

858585

6Prova de conceito do Modelo de Arquite-tura para um SGDW

Neste Capítulo apresentaremos os detalhes de implementação da prova de conceitorealizada para o modelo de arquitetura proposto no Capítulo anterior. Para isto, a Seção 6.1apresenta uma visão geral da implementação da solução desenvolvida e na Seção 6.2 discorremossobre 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 adequadamenteos conjuntos de dados na Web, foi desenvolvida uma solução, como prova de conceito, queimplementa 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 provade conceito, foi desenvolvida a solução SGDW-v01 que provê acesso a uma interface Webpara os consumidores, acessível por meio da URI <http://sgdw2.cloudapp.net/>, uma interfaceWeb para os produtores, acessível por meio da URI <http://sgdw2.cloudapp.net/produtor>, eacesso a uma interface remota por meio da URI <http://sgdw2.cloudapp.net:8080/>. Duranteo desenvolvimento da solução, foi usado o Git como framework de gerência de configuraçãoe o código foi disponibilizado em um repositório público do GitHub, acessível por <https://github.com/dass-cin/sgdw>.

6.1.1 Arquitetura e tecnologias de implementação

De modo geral, baseado na arquitetura Web, o SGDW-v01 foi desenvolvido em duasgrandes partes, sendo uma com tecnologias client-side (executadas no navegador do cliente) e aoutra com tecnologias server-side (executadas no servidor), sendo as interações com os usuáriosrealizadas por intermédio de requisições HTTP, via navegador Web. Em outras palavras, o ladodo cliente se comunica com o lado do servidor por meio do uso de uma API REST que é expostapelo servidor. A arquitetura do SGDW-v01 está ilustrada na Figura 6.1.

http://sgdw2.cloudapp.net/

http://sgdw2.cloudapp.net/produtor

http://sgdw2.cloudapp.net:8080/

https://github.com/dass-cin/sgdw

https://github.com/dass-cin/sgdw

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 dadosnas fontes de origem até a realização de consultas e recuperação dos dados. Para ser uma soluçãomultiplataforma e de fácil instalação, o desenvolvimento foi fundamentado no uso da linguagemde programação Java. Foi utilizado o Gradle1 para o gerenciamento do projeto, controle dedependências e compilação da aplicação. Assim, foi possível automatizar a geração do arquivoWeb application ARchive (WAR), que é usado para implantar a aplicação no servidor.

Para armazenar os metadados e os dados, foi utilizado o MongoDB2, um banco de dadosmulti-plataforma orientado a documentos, que oferece um alto desempenho, disponibilidade eescalabilidade. No MongoDB, os dados são armazenados em coleções de dados que não exigemque todos os dados apresentem o mesmo esquema, permitindo uma maior flexibilidade noarmazenamento. Internamente, uma instância do MongoDB armazena os dados em documentosBSON, que são são arquivos JSON codificados em formato binário (MONGODB, 2017).

A Camada de Serviços foi desenvolvida usando o Spring3, um framework open source1https://gradle.org/2https://www.mongodb.com/3https://spring.io/


para plataforma Java baseado no padrão de projeto de injeção de dependências4. Esse padrãoestá fundamentado no uso de abstrações, sejam classes abstratas ou interfaces, para quebraro forte acoplamento entre as classes e inverter a dependência. Assim, ao invés de dependerde uma classe concreta, dependemos de uma abstração, o que torna o cenário desacoplado, defácil manutenção e evolução. É também por meio do Spring que as APIs são construídas, oque permite que todos os dados recebidos por meio delas sejam mapeados em classes Java, e asrotinas 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 oMongo-Java-Driver5, que é o driver oficial disponibilizado pela MongoDB. Já para extraçãodos dados das fontes de dados de origem, foi utilizado o Hibernate6 que é um framework para omapeamento objeto-relacional escrito na linguagem Java. Assim, o Hibernate é responsável porrealizar 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: PostgreSQL7,MySQL8, SQL Server9 e o Oracle10.

Foram desenvolvidas duas APIs, uma direcionada para atividades de cadastro e ge-renciamento dos conjuntos de dados pelo produtor (AdminREST) e outra que permite acessoaos metadados e conjuntos de dados para os consumidores (OpenREST). Cada API tem rotasespecíficas, que serão descritas na Subseção 6.2.6, e permitem acesso aos serviços a partir derequisições HTTP. Para acessar a API AdminREST, no entanto, é necessário fornecer um tokenválido, que é gerado quando o produtor efetua login no sistema. Assim, a partir das requisiçõesrecebidas na API, os serviços são executados e podem recuperar dados ou metadados, assimcomo 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 denegócio do SGDW-v01. A Camada de Persistência, por sua vez, é responsável por persistir osconjuntos de dados no MongoDB, além de permitir a conexão e coleta dos dados das fontes deorigem. Para que os produtores e consumidores possam utilizar os serviços, são disponibilizadasduas 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 Webindependentes que fornecem as interfaces para os produtores e consumidores. Enquanto umaaplicação permite a consulta e acesso aos conjuntos de dados por meio de uma Interface Webpara os consumidores, a outra aplicação permite que o produtor gerencie o cadastro de fontesde dados de origem e dos conjuntos de dados a serem publicados, assim como possa realizaratualizações manuais nos conjuntos de dados.

4https://docs.spring.io/spring/docs/current/spring-framework-reference/html/overview.html5https://github.com/mongodb/mongo-java-driver6http://hibernate.org/orm/7https://www.postgresql.org/8https://www.mysql.com/9https://www.microsoft.com/pt-br/sql-server/

10https://www.oracle.com/database/


Tanto a aplicação para os consumidores quanto a aplicação dos produtores foram im-plementadas como Single Page Application (SPA)11, ou seja, cada uma como uma aplicaçãoWeb 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 paradesenvolvimento de um SPA. Por exemplo, em sua estrutura, o BlurAdmin usa outros fra-

meworks como AngularJS12 e Bootstrap13, que são usados como framework de JavaScript (JS) eCascading Style Sheets (CSS), respectivamente.

No desenvolvimento das aplicações, foi usado o Node.js14 e, para gerenciar as dependên-cias das aplicações, os seus pacotes Bower15 e Gulp16. O Node.js é uma plataforma construídasobre o motor JavaScript do Google Chrome para construir aplicações rápidas e escaláveis17. OBower é usado para gerenciar as versões corretas das bibliotecas e suas respectivas dependênciasda interface. Todas as versões dos pacotes são especificados no arquivo bower.json, como asversões do Angular e o do Bootstrap. Já o Gulp é usado para compilar as aplicações, concatenartodos os arquivos JS e CSS e, após, fazer a minificação do código. Além disso, o Gulp é usadopara gerar o código final que deve ser usado no ambiente de produção, ou seja, ele separa empastas 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 cons-truída no servidor. O Angular também utiliza a injeção de dependências nos componentes dasaplicaçõ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 denovos componentes, facilita a organização dos arquivos, conforme pode ser observado na Figura6.2.

11https://msdn.microsoft.com/en-us/magazine/dn463786.aspx12https://angularjs.org/13http://getbootstrap.com/14https://nodejs.org/en/15https://bower.io/16http://gulpjs.com/17http://nodebr.com/o-que-e-node-js/


Figura 6.2: Arquitetura do Angular (a) e Estrutura de pastas do projeto da Interface Webdo produtor (b). Fonte: o autor

Como dito anteriormente, o Angular permite o desenvolvimento de aplicações como conceito de SPA, assim os arquivos são dinamicamente carregados e adicionados à páginaconforme necessário, ou seja, conforme as ações dos usuários. Para tanto, o framework oferecemó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 Figura6.2 (a), temos o module que é usado registrar os componentes da aplicação, como controllers eservices, e definir os processos de inicialização e configuração (config). De acordo com uma rotasolicitada, a view e o controller correspondentes são carregados. As diretivas (directives) sãousadas para estender o HTML e criar novas tags. Já os services são utilizados para realizar alógica de comunicação com a API e retornar os dados para o controller, que utiliza o scope paraconstruir as views.

Para desenvolvimento de um novo módulo da interface, conforme pode ser visto naFigura 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 "nomeda-pasta.controller.js". No primeiro deve ser configurado qual a rota que corresponde ao módulo, osegundo deve conter o HTML (template) padrão do módulo e no controller, deve conter a lógicapara construção da tela. Quando a view precisar de dados externos para sua construção, como oscarregados por meio da API, deve ser criado um quarto arquivo (“nomedapasta.service.js”) comas 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 criadodeve ser adicionado no arquivo “pages.module.js”. Dessa forma, essa estrutura faz com que asdependências do componente sejam inseridas dentro de sua respectiva pasta e que o componenteseja adicionado automaticamente ao menu principal do aplicação.

Portanto, para desenvolver as interfaces Web do SGDW-v01, visando o desenvolvi-mento evolutivo da solução, usamos frameworks open source para auxiliar no desenvolvimento.Também buscamos facilitar e automatizar tarefas repetitivas no desenvolvimento, como a conca-tenação de arquivos, minificação de arquivos e o gerenciamento de dependências. Além disso, a


estrutura adotada permite que novos componentes sejam adicionados de forma fácil e organizada.

6.1.2 Funcionalidades

Na Figura 6.3 é ilustrado o diagrama de casos de uso das principais funcionalidades doSGDW-v01.

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 dainterface administrativa ou API, e assim obter autorização (token) para acessar as funcionalidadesdo sistema. Ao realizar o cadastro de uma fonte de dados, o produtor deverá informar os dadosnecessários para permitir o acesso a ela. No processo de criação de um conjunto de dados, oprodutor deverá informar os metadados solicitados pela ferramenta, selecionar uma fonte dedados 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 sistemaque atualize o conjunto de dados a partir dos dados da fonte cadastrada.


Todos os casos de uso do consumidor também são casos de uso do produtor. Assim, eletambém pode consultar os conjuntos de dados, visualizar o históricos de versões e os metadadosdos conjuntos de dados. Somado a isso, também pode recuperar os conjuntos de dados nosdiferentes formatos disponíveis, assim como os metadados e os dados de qualquer versão geradado conjunto de dados. Vale salientar que a interface Web foi construída a partir das APIsdisponíveis, portanto, as ações dos produtores e consumidores podem ser realizadas tanto pelainterface Web quanto por meio de requisições na API.

6.1.3 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 umainstância do Windows Server 2016, com um disco de armazenamento de 128GB, 3.5 GB dememória ram e um núcleo para processamento. Na máquina virtual foram instalados o Javaversão 8.12118, o Java SE Development Kit 8u12119 e o MongoDB Community versão 3.4.220.

Também foi instalado o Internet Information Services (IIS)21, que é o servidor Webdo Windows, sendo configurado para ser executado na porta 80 (HTTP). O IIS foi usado parahospedar os arquivos da interface Web. Já a aplicação server-side, foi configurada para executarinternamente o Jetty22, 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 aaplicação na porta 8080.

Quando a aplicação server-side é executada pela primeira vez, é criado um arquivomongoconfig.properties na raiz do sistema operacional (e.g. "c:)̈ para que seja informado ocaminho para a conexão com o MongoDB. Posteriormente, ao ser novamente executado, trêsnovas coleções são criadas, sendo a collector_users a coleção que contém os dados para acessodos produtores, a collector_conf que armazena os metadados dos conjuntos de dados e dosistema 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 daURI <http://sgdw2.cloudapp.net/>, enquanto que a interface para os produtores pode ser acessadapor meio da URI <http://sgdw2.cloudapp.net/produtor> e a API de acesso aos dados pode seracessada por meio da URI <http://sgdw2.cloudapp.net:8080/>. À medida que os conjuntos dedados são criados, duas novas coleções são inseridas, sendo uma com o nome do conjunto dedados, para armazenar todos os dados obtidos, e outra com o nome do conjunto de dados seguidode "_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

18https://www.java.com/pt_BR/download/win10.jsp19http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html20https://www.mongodb.com/download-center21https://www.iis.net/22http://www.eclipse.org/jetty/download.html


http://sgdw2.cloudapp.net/produtor

http://sgdw2.cloudapp.net:8080/

6.2. ADEQUAÇÃO DA IMPLEMENTAÇÃO AOS REQUISITOS 92

servidores, uma vez que foram desenvolvidas independentes do código uma da outra, apenas porconsumo da API. Porém, por questão de custos e por se tratar de uma prova de conceito, foramdisponibilizados 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 tarefasque permitam gerenciar adequadamente os conjuntos de dados. Dessa forma, um SGDWapresenta alguns requisitos específicos, conforme discutido no Capítulo 3. Assim, a prova deconceito apresentada teve por objetivo mostrar que é possível implementar a arquitetura propostae que os serviços propostos de fato atende os requisitos listados anteriormente. Esta seção discutea 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 meioda API quanto pela interface Web do produtor ou consumidor.

Para acessar as funcionalidades inerentes ao módulo do produtor, é necessário realizarlogin 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 osaplicativos da Web podem armazenar dados localmente no navegador do usuário. A Figura 6.5mostra o token armazenado na sessão do cliente e o token quando é gerado via API, utilizando aferramenta Postman 24 para simular a requisição. Vale salientar que, por questões de segurança,

23http://www.w3schools.com/html/html5_webstorage.asp24https://www.getpostman.com/apps


tanto é verificado se consta um token válido na sessão do navegador quanto se o token armazenadoainda continua válido no servidor.

Figura 6.5: Token salvo na Session Storage (a) e Token gerado após simular umarequisição a API (b). Fonte: o autor

A seguir, todos os serviços da prova de conceito são descritos. Para as funcionalidadesda aplicação do produtor, assumimos que já foi realizado o login na ferramenta.

6.2.1 Collector

Em nossa prova de conceito, o Serviço Collector é o responsável por realizar o gerencia-mento das fontes de dados e a extração dos dados.

6.2.1.1 Cadastro de Fonte de Dados

Como dito anteriormente, o procedimento de obtenção dos dados ocorre de formadiferente para cada tipo de fonte. No entanto, para nossa prova de conceito, consideramosas fontes de dados acessíveis por um SGBD relacional. Nesse caso, para estabelecer umaconexão com a fonte de dados, é necessário informar uma string de conexão Java Database


Connectivity (JDBC)25, o usuário, a senha e o nome do banco de dados. Após informar osdados, o sistema efetua um teste de conexão com os dados informados. Se os dados permitiremestabelecer uma conexão, a fonte de dados é cadastrada. Caso não seja possível estabelecer aconexão, uma mensagem de erro é informada e o cadastro não é realizado. O formulário paracadastro 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 atual-mente26, sendo o Oracle, MySQL, SQL Server e PostgreSQL. Para cada SGBD, é necessárioinformar 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 quenovos SGBDs são configurados na API eles já são adicionados automaticamente a interface. AFigura 6.7 ilustra o retorno dos tipos de SGBDs recebidos por meio da API.

25http://www.oracle.com/technetwork/java/javase/jdbc/index.html26http://db-engines.com/en/ranking


Figura 6.7: Tipos de SGBDs recebidos por meio da API. Fonte: o autor

6.2.1.2 Extração e Transformação de Dados

Uma vez cadastrada e estabelecida uma conexão com a fonte de dados, é possível realizara extração dos dados. No entanto, este processo só ocorre no momento da criação dos conjuntosde dados, dado que o produtor deve especificar um comando SQL para que o Collector execute aconsulta 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 arequisição com a configuração informada e realiza a conexão com o SGBD. Com a conexãorealizada, executa o comando SQL para obter os dados e persistir no MongoDB. Após obtertodos os dados, o DataTransformer realiza a transformação dos dados, conforme ilustrado naFigura 6.8.

Figura 6.8: Processo de extração de dados implementado na Prova de Conceito. Fonte: oautor

Em síntese, o Collector tem como objetivo automatizar a obtenção dos dados preparando-


os para publicação na Web e o DataTransformer transforma os dados automaticamente para osformatos CSV, XML e JSON. A Figura 6.9 mostra o método que gera as propriedades da conexãodinamicamente a partir das fontes de dados e a Figura 6.10 mostra o método que recupera osdados 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


Para transformações dos dados, foram utilizadas algumas bibliotecas, como a bibliotecaGSON27 do Google para transformar os dados para JSON. Para transformar os dados em formatoXML utlizamos a API do JDOM28 e para o CSV foi desenvolvido um algoritmo que utilizaquebras de linhas e o ponto e vírgula como separador entre colunas. A Figura 6.11 mostra ométodo que transforma os dados no formato JSON e a Figura 6.12 mostra o método utilizadopara 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

27https://github.com/google/gson28http://www.jdom.org/


Vale salientar que para evitar o consumo excessivo de memória do servidor desprendidona conversão dos dados em formatos específicos, optamos por armazenar os dados nos trêsformatos logo após sua recuperação da fonte de dados de origem. Dessa forma, sempre que umconjunto de dados for recuperado, ainda que por vários consumidores ao mesmo tempo, apenasuma requisição HTTP será processada no servidor. Sendo este procedimento, portanto, umadecisão arquitetural para diminuir o consumo de memória.

6.2.2 Criação de Conjuntos de Dados

Este Serviço permite que o produtor crie conjuntos de dados auto-descritivos. De modogeral, para a prova de conceito, é utilizado apenas um subconjunto do DCAT e DCMI paradescrição sumária dos conjuntos de dados. No processo de criação, a solução permite que oprodutor informe quais dados serão publicados a partir de uma fonte de dados previamentecadastrada. 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


Dado a extração dos dados de forma automática pela solução, só é possível efetuar ocadastro do conjunto de dados se for possível executar a consulta informada, ou seja, o sistemase conecta a fonte de dados informada e processa a consulta para verificar se existe 1 ou maisdados. Se a quantidade de dados obtida a partir da execução da consulta de teste for maior quezero, o Collector inicia a recuperação dos dados e persiste no repositório de dados.

6.2.2.1 Gerenciamento de URIs

No processo de criação do conjunto de dados, a aplicação Web realiza comunicação como servidor para criar um identificador persistente para o conjunto de dados. Assim, é enviadoo 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 seusrespectivos itens, como distribuições e versões, tanto por meio da interface Web quanto por meioda 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

6.2.2.2 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 formatosdisponíveis. Com a estrutura adotada no desenvolvimento da prova de conceito, novos formatospodem ser facilmente adicionados e também é possível conceder a opção para o produtorselecionar os formatos desejados dentre os disponíveis.

Na Figura 6.16 é possível visualizar as distribuições disponíveis após o cadastro de umconjunto 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.


Figura 6.15: Distribuições disponíveis. Fonte: o autor

6.2.3 Gerenciamento de metadados

Conforme descrito anteriormente e apresentado na Figura 6.13 (criação de conjunto dedados), nesta prova de conceito utilizamos um subconjunto de metadados do DCAT e DCMI. Estesubconjunto 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 pararealizar o cadastro de um conjunto de dados. Na Figura 6.16 são ilustrados os metadadosarmazenados no MongoDB e os metadados que são exibidos por meio da API, ambos no formatoJSON.

Figura 6.16: Metadados exibidos por meio de uma consulta no MongoDB (a) e osmetadados recuperados por meio da API pública do sistema (b). Fonte: o autor

6.2.4 Gerenciamento de Versões

Desenvolvemos um gerenciamento de versões automatizado que considera cada alteraçãoem um conjunto de dados como uma nova versão do mesmo. Assim, tornou-se possível manterum histórico com todas as versões geradas do conjunto de dados, bem como possibilitar arecuperação dos dados das respectivas versões.

Dado que o gerenciamento é automático, o sistema utiliza, como código indicador deversão, uma tag com um timestamp gerado a partir da data e hora do momento em que o conjunto


de dados foi alterado. Além disso, a menos que seja especificada uma versão, o sistema sempreretornará os dados mais recentes do conjunto de dados quando ele for referenciado. Ao acessar adescrição de um conjunto de dados via interface Web, o sistema lista todas as versões geradas,conforme pode ser visto na Figura 6.17.

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 nohistórico de versões acima e acessar a versão desejada clicando na descrição da versão. Dessaforma, o sistema vai permitir acesso a versão desejada, possibilitando visualizar os metadados daversão e recuperar os respectivos, conforme pode ser visto na Figura 6.18.

Figura 6.18: Acesso a uma versão específica de um conjunto de dados. Fonte: o autor

6.2.5 Gerenciamento de Atualizações

Este serviço garante que o conjunto de dados permanece atualizado de acordo com afrequência de atualização definida na criação do conjunto de dados. Para tanto, este serviço fazuso do agendador de tarefas do Spring, por meio da anotação @Schedule, que permite especificar


quando um método deve ser executado dado uma configuração de data e hora. Assim, a anotação@Schedule foi utilizada com o padrão cron que permite especificar uma sequência de seis camposrepresentando 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 osdias a cada uma hora. A Figura 6.19 ilustra o agendador de tarefas criado. Quando o métodoatualizarDatasetsAuto() é 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 conjuntode 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 deatualização, também é possível efetuar a atualização manual. Assim, sendo necessário refletiralteraçõ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 6.20.

Figura 6.20: Atualização manual (não programada) de um conjunto de dados. Fonte: oautor


6.2.6 Gerenciamento de Acesso

Nesta versão da solução, o serviço de gerenciamento de acesso permite que os dadosarmazenados no MongoDB sejam recuperados por meio de download em massa e por meio deAPIs. Apesar de ainda não ser possível definir os subconjuntos de dados ao criar um conjunto dedados, é possível recuperar subconjuntos a partir da API, assim como utilizá-la para realizar odownload dos dados no formato indicado. A interface Web do produtor e consumidor fornecelinks 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 dedados, o sistema automaticamente permitirá a recuperação deles por meio da API, assim comopermitirá o download dos dados nos formatos configurados no sistema. A Figura 6.21 mostratais 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 anotação @RestController emuma classe Java, definindo os mapeamentos entre as rotas da API e ações, além do verbos HTTPnecessá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 <http://sgdw.azurewebsites.net:8080/admin>. Umavez que ela é voltada para atividades de cadastro e gerenciamento dos conjuntos de dados peloprodutor, para acessá-la é necessário fornecer um token que é obtido após o login. Conformepode 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 seencarrega de mapeá-los na classe NovoDataset. Se o token informado for válido, o conjunto de

http://sgdw.azurewebsites.net:8080/admin


dados pode ser criado, caso não, um código HTTP 401 (acesso não autorizado) é retornado. A APIOpenREST, acessível por <http://sgdw.azurewebsites.net:8080/open>, é aberta e não necessita detoken. A documentação das APIs foi publicada em <http://sgdw.azurewebsites.net:8080>, sendodescrita 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 Swagger29 que é um framework de29http://swagger.io/

http://sgdw.azurewebsites.net:8080/open

http://sgdw.azurewebsites.net:8080


código aberto criado para auxiliar a projetar, construir, documentar e consumir APIs. Além deusar o Swagger para documentar a API, também utilizamos para possibilitar a execução de testesde consumo. Assim, por meio da documentação, uma rota pode ser acessada e testes podem serprocessados, como mostra a Figura 6.25.

Figura 6.25: Testes da API a partir da documentação. Fonte: o autor

Por fim, acessando a URI <http://sgdw.azurewebsites.net:8080/api-docs> é possívelobter metadados da API, incluindo sua versão. Para o desenvolvimento da API, assumimos comopremissa que todas as alterações nas rotas, métodos ou ações devem ser encapsuladas em novasversõ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.

6.2.7 Interface Web Consumidor

Os consumidores poderão acessar os conjuntos de dados por meio da URI <http://sgdw2.cloudapp.net/>. O desenvolvimento da Interface Web para o consumidor seguiu a mesma diretrizdo desenvolvimento da Interface Web para o produtor, ou seja, com o uso das mesmas tecnologiase frameworks. Em síntese, para os consumidores é possível realizar filtros nos conjuntos dedados, efetuar download dos dados, acessar os dados e metadados por meio da API e acessartodas as versões dos conjuntos de dados. A Figura 6.26 exibe a tela principal da Interface Webpara os consumidores.

http://sgdw.azurewebsites.net:8080/api-docs



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 quegerencie adequadamente os conjuntos de dados na Web, ou seja, por meio da prova de conceitoimplementada 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 permiteatender, por meio de um conjunto de serviços, os requisitos listados no modelo de arquiteturaproposto. A seguir, no Quadro 6.1, são elencados os serviços do SGDW-v01 e quais os requisitosao qual cada um deles está relacionado.

Dos requisitos elencados, três não foram atendidos em nossa prova de conceito, sendo orequisito de prover mecanismos para a criação de canais de comunicação entre os produtores econsumidores, garantir a preservação dos conjuntos de dados ao longo do tempo e o gerenci-amento de metadados. Consideramos que o requisito de gerenciamento de metadados não foiatendido na prova de conceito uma vez que ele não foi encapsulado como um serviço e aindanão é apoiado por um processo de curadoria. Dessa forma, quando um serviço precisa criar, usarou 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 caracte-rísticas necessárias para o requisito foram atendidas. Assim, o Serviço de Criação de Conjuntosde Dados não atende completamente ao requisito correspondente pois não permite a especifi-cação de subconjuntos de dados. O Serviço de Collector só foi implementado para fontes dedados relacionais, não considerando as fontes de dados não relacionais e os dados presentes emarquivos, por exemplo. Somado a isso, o Serviço de Gerenciamento de Versões só considera asatualizações nos dados e não é gerado uma versão para atualizações nos metadados, ainda queem 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-

6.3. CONCLUSÃO 107

Quadro 6.1: Serviços da Prova de Conceito x Requisitos de um SGDW

Serviço Requisito Adequação do Serviço ao Re-quisito

Criação de Conjuntos de Da-dos

R1. Prover mecanismos para a criação deconjuntos de dados auto-descritivos;

Parcial

Gerenciamento de Distribui-ções

R2. Possibilitar a criação de múltiplas distri-buições para um mesmo conjunto de dados,ou seja, a disponibilização dos dados emdiferentes formatos;

Atende

Gerenciamento de Acesso R3. Prover múltiplos meios de acesso aosconjuntos de dados, que podem ser desde odownload de arquivos até o acesso por meiode APIs;

Atende

Não implementado R4. Prover mecanismos para a criação decanais de comunicação entre os atores doecossistema de dados na Web;

Não atende

Gerenciamento de Atualiza-ção

R5. Garantir o acesso a dados atualizadosde acordo com a fonte de origem;

Parcial

Collector R6. Prover mecanismos para a extraçãoe transformação dos dados de origem emdados na Web;

Parcial

Gerenciamento de Versões R7. Prover mecanismos para o gerencia-mento de versões de conjuntos de dados;

Parcial

Não implementado R8. Prover mecanismos para o gerencia-mento de metadados (curadoria de metada-dos);

Não atende

Preservação R9. Garantir a preservação dos conjuntosde dados ao longo do tempo;

Parcial

Gerenciamento de URIs R10. Garantir o uso de identificação única,por meio de URIs, para os conjuntos dedados, distribuições, versões e, preferenci-almente, para os itens de cada conjunto dedados;

Atende

Fonte: o autor

buições de forma automática. Além disso, a estrutura do sistema que foi adotada permite quenovos formatos possam ser adicionados e automaticamente disponibilizados para que sejamconsumidos. Também foram desenvolvidos métodos de acesso que permitem a recuperaçãodos dados por meio de download em massa e por meio de API. Assim como, foi garantido aidentificação única para os conjuntos de dados, versões e distribuições.

Portanto, com a prova de conceito foi possível explorar o modelo de arquitetura propostoe verificar que é possível implementar um SGDW. Além disso, ela também foi usada para definira infraestrutura necessária para o desenvolvimento evolutivo do SGDW. Por fim, foi possívelobservar que o modelo de arquitetura adotado é flexível ao ponto de viabilizar a implementaçãode novos serviços que não foram atendidos.

108108108

7Conclusão

7.1 Considerações Finais

Neste trabalho foi apresentado e especificado um modelo de arquitetura para um Sis-tema Gerenciador de Dados na Web (SGDW). O modelo proposto leva em consideração osprincipais requisitos e funcionalidades que um sistema deste tipo deve atender para prover umgerenciamento adequado dos conjuntos de dados publicados na Web.

Foi apresentada uma visão geral da fundamentação teórica desta dissertação, discutindoos principais assuntos relacionados ao contexto de Dados na Web. Assim, discorremos sobreos ecossistemas de dados na Web e analisamos o ciclo de vida dos dados na Web. A partir daanálise realizada, verificamos a necessidade de alteração do ciclo referenciado na literatura epropomos uma nova instância do ciclo de vida dos dados na Web.

Somado a isso, apresentamos as principais soluções para catalogação de dados atualmentee suas respectivas características. Em seguida, discorremos sobre as Boas Práticas para Dadosna Web recomendada pelo W3C e fizemos uma análise para verificar a adequação das soluçõesas boas práticas. O resultado da análise apontou que desafios voltados a qualidade dos dados,versionamento, preservação, enriquecimento e republicação dos dados são poucos exploradospelas principais soluções de catálogos de dados.

Buscamos entender os principais desafios para publicação e consumo dos dados na Web e,a partir do estudo desses desafios, as premissas para o compartilhamento de dados na Web foramapresentadas. Dessa forma, guiados pelas premissas, definimos os requisitos que uma soluçãode compartilhamento de dados na Web deve ter para prover um gerenciamento adequado dosconjuntos de dados. Assim, foram estabelecidas 4 premissas e 10 requisitos. Para complementara análise anteriormente realizada, fizemos uma nova análise das soluções de catalogação de dadosverificando o atendimento delas aos requisitos listados. Os resultados discutidos no Capítulo 4mostraram que as soluções atuais apresentam lacunas quanto aos requisitos de gerenciamentode versões, gerenciamento de metadados, comunicação entre consumidores e produtores e apreservação dos conjuntos de dados.

É importante destacar que as premissas guiaram a definição dos requisitos discutidos e as

7.2. TRABALHOS FUTUROS 109

análises realizadas, no Capítulo 3 e 4, permitiram identificarmos as lacunas presentes no cenárioatual pelas principais soluções de catalogação de dados. Assim, foi apresentado um modelo dearquitetura para um SGDW que procurou preencher as lacunas de gerenciamento de conjuntosde dados deixadas pelas soluções para publicação de dados disponíveis atualmente, além deatender aos requisitos listados anteriormente.

O modelo de arquitetura apresentado para o SGDW foi baseado em serviços, com oobjetivo de realizar tanto as tarefas já desempenhadas pelos ambientes de catalogação de dadosquanto às tarefas relacionadas ao gerenciamento dos dados propriamente ditos. Ao todo, foramdefinidos e discutidos os 13 principais serviços para um SGDW.

Por fim, mostramos que é possível desenvolver uma solução que gerencie adequadamenteos conjuntos de dados na Web. Por meio de uma prova de conceito, desenvolvemos umasolução que implementou os requisitos de extração dos dados, criação de conjunto de dadosauto-descritivos, gerenciamento de atualizações automáticas e gerenciamento de versões. Foidesenvolvido um sistema serve-side que concentrou todos os serviços desenvolvidos e forneceacesso a eles por meio de uma API, que é consumida por duas aplicações client-side, um para osprodutores e outra para os consumidores. A partir da prova de conceito, dado a natureza evolutivae open source do SGDW, também foi possível definir o arcabouço tecnológico necessário paracontinuar o desenvolvimento após o período desta dissertação.

Assim, conclui-se que o presente trabalho conseguiu atingir seus objetivos, propondoum modelo de arquitetura para um SGDW e mostrando, por meio da prova de conceito, que épossível desenvolver uma solução que forneça meios para gerenciar adequadamente os conjuntosde dados na Web, atendendo aos requisitos identificados. Durante o decorrer desta dissertação,foram gerados as seguintes publicações como resultados intermediários:

� Oliveira M., Oliveira L., Lima G. and Lóscio B. (2016). Enabling a Unified Viewof Open Data Catalogs. In Proceedings of the 18th International Conference on

Enterprise Information Systems - Volume 2: ICEIS, ISBN 978-989-758-187-8, pages230-239. DOI: 10.5220/0005835202300239

� Oliveira M., Oliveira H., Oliveira L., and Lóscio B. (2016). Open Government DataPortals Analysis: The Brazilian Case. In Proceedings of the 17th International

Digital Government Research Conference on Digital Government Research (dg.o

’16), Yushim Kim and Monica Liu (Eds.). ACM, New York, NY, USA, 415-424. DOI:https://doi.org/10.1145/2912160.2912163

7.2 Trabalhos Futuros

Como proposta de extensão para esta pesquisa, apresentamos algumas direções que serãoexploradas em trabalhos futuros, como a complementação de serviços na arquitetura, integraçãocom novas fontes de dados de origem e implementação dos demais serviços definidos.

7.2. TRABALHOS FUTUROS 110

Sabe-se que os conjuntos de dados podem apresentar, por exemplo, aspectos que osdefinam como séries temporais ou espaciais, ou seja, quando os conjuntos de dados seguemobservações sequenciais ao longo do tempo ou espaço. Este é um importante serviço que deveser estudado para que seja adicionado na arquitetura e implementado na solução. Assim, serápossível estabelecer como as séries poderão ser criadas e apresentadas aos consumidores.

Além disso, no escopo deste trabalho, consideramos apenas a extração de dados de umaúnica fonte de dados de origem. Porém, sabemos que existem conjuntos de dados que podem sermistos, ou seja, com dados provenientes de mais de uma fonte de dados. Assim, é necessárioestudar as características desses conjuntos de dados e adicionar ao requisito de extração de dados.Ademais, novos tipos de fontes de dados também devem ser adicionados e implementados.

Uma outra característica importante para um SGDW não entrou no escopo deste trabalho,a necessidade de um SGDW ser integrado a um ou mais SGDW. Como nem todas as fontesde dados de origem podem permitir o acesso externo para extração de dados, o requisito degerenciamento de atualização pode ser comprometido. Uma alternativa para contornar esseproblema pode ser utilizar o SGDW no servidor local. Assim, seria instalado uma instância doSGDW no servidor da fonte de dados de origem para que poder usar os serviços dele, incluindoa extração dos dados. Para permitir o acesso aos dados pelos consumidores, cada SGDW localdeverá se comunicar de forma exclusiva com o SGDW online.

Somado a isso, também é necessário realizar um levantamento para melhorar a abordagemde como garantir que os conjuntos de dados armazenados externamente terão sua frequênciade atualização refletida na Web. Assim, deve ser levado em consideração aspectos quanto amaterialização ou virtualização dos dados, por exemplo. Já que hoje consideramos apenas amaterialização de dados para todos os casos, mas podem ter situações que os dados não precisemser materializados no servidor do SGDW, ou seja, possibilitando o acesso acesso virtual aosdados.

Não só novos serviços devem ser adicionados ao SGDW, mas também os demais requisi-tos e serviços levantados devem ser implementados, como os subconjuntos de dados, curadoria demetadados e o gerenciamento de uso, que inclui descrições das aplicações, fórum e classificaçãodos conjuntos de dados, por exemplo.

111111111

Referências

, M. I. d. S. . METADATA CURATION ENVIRONMENT FOR SUPPORTING DATACOLLECTION ECOSYSTEMS. Tese (Qualificação Doutorado) — Universidade Federal dePernambuco, 2016.

BALL, A. Review of the State of the Art of the Digital Curation of Research Data. [S.l.]:University of Bath, 2012. <http://opus.bath.ac.uk/18774/2/erim1rep091103ab11.pdf>. Acessoem 20 de janeiro de 2017.

BERNERS-LEE, T. Linked Data. 2006. <https://www.w3.org/DesignIssues/LinkedData.html>.Acesso em 02 de dezembro de 2016.

BRITO, K. d. S. et al. Is brazilian open government data actually open data?: An analysis of thecurrent scenario. Int. J. E-Planning Res., IGI Global, Hershey, PA, USA, v. 4, n. 2, p. 57–73, abr.2015. ISSN 2160-9918. Disponível em: <http://dx.doi.org/10.4018/ijepr.2015040104>.

CATTEAU, O.; VIDAL, P.; BROISIN, J. A generic representation allowing for expression oflearning object and metadata lifecycle. In: Sixth IEEE International Conference on AdvancedLearning Technologies (ICALT’06). [S.l.: s.n.], 2006. p. 30–32. ISSN 2161-3761.

CKAN. CKAN - User Guide. [S.l.]: Open Knowledge Foundation, 2013. <http://docs.ckan.org/en/latest/>. Acesso em 20 de dezembro de 2016.

DIETRICH, D. et al. Open Data Handbook. [S.l.]: Open Knowledge Foundation, 2009.<http://opendatahandbook.org/guide/en/>. Acesso em 05 de dezembro de 2016.

DWIVEDI, A. et al. Current security considerations for issues and challenges of trustworthysemantic web. International Journal of Advanced Networking and Applications, EswarPublications, v. 3, n. 1, p. 978, 2011.

ELMASRI, R.; NAVATHE, S. Fundamentals of Database Systems. 6th. ed. USA:Addison-Wesley Publishing Company, 2010. ISBN 0136086209, 9780136086208.

ESRI. ArcGIS Open Data. [S.l.]: ESRI, 2015. <http://doc.arcgis.com/en/open-data/>. Acessoem 21 de dezembro de 2016.

GALIB, S. M. et al. Clustered and smarter web mining using semantic web. In: 2015 18thInternational Conference on Computer and Information Technology (ICCIT). [S.l.: s.n.], 2015. p.111–115.

GAMA, K.; LÓSCIO, B. F. Towards ecosystems based on open data as a service. In:Proceedings of the 16th International Conference on Enterprise Information Systems. [S.l.: s.n.],2014. p. 659–664. ISBN 978-989-758-028-4.

HIGGINS, S. The dcc curation lifecycle model. In: Proceedings of the 8th ACM/IEEE-CS JointConference on Digital Libraries. New York, NY, USA: ACM, 2008. (JCDL ’08), p. 453–453.ISBN 978-1-59593-998-2. Disponível em: <http://doi.acm.org/10.1145/1378889.1378998>.

HIREMATH, B.; KENCHAKKANAVAR, A. Y. An alteration of the web 1.0, web 2.0 and web3.0: A comparative study. Imperial Journal of Interdisciplinary Research, v. 2, n. 4, 2016.

http://opus.bath.ac.uk/18774/2/erim1rep091103ab11.pdf

https://www.w3.org/DesignIssues/LinkedData.html

http://dx.doi.org/10.4018/ijepr.2015040104

http://docs.ckan.org/en/latest/

http://docs.ckan.org/en/latest/

http://opendatahandbook.org/guide/en/

http://doc.arcgis.com/en/open-data/

http://doi.acm.org/10.1145/1378889.1378998

REFERÊNCIAS 112

ISOTANI, S.; BITTENCOURT, I. Dados Abertos Conectados: Em busca da Webdo Conhecimento. NOVATEC, 2015. ISBN 9788575224496. Disponível em: <http://ceweb.br/livros/dados-abertos-conectados/>.

JACOBS, I.; WALSH, N. Architecture of the World Wide Web. [S.l.], 2004.Https://www.w3.org/TR/webarch/.

JUNAR. Junar - Users Manual. [S.l.]: Junar, 2015. <http://junar.github.io/junar-manual/en/build/html/index.html>. Acesso em 20 de dezembro de 2016.

LEE, D.; LÓSCIO, B. F.; ARCHER, P. Data on the Web Use Cases and Requirements. [S.l.],2015. Https://www.w3.org/TR/dwbp-ucr/.

LÓSCIO, B. F.; BURLE, C.; CALEGARI, N. Data on the Web Best Practices. [S.l.], 2016.Https://www.w3.org/TR/dwbp/.

LÓSCIO, B. F.; BURLE, C.; CALEGARI, N. Data on the web best practices: Challenges andbenefits. In: Open Data Reserach Symposium (ODRS 2016). [S.l.: s.n.], 2016.

LÓSCIO, B. F.; OLIVEIRA, M. I. S.; BITTENCOURT, I. I. Publicação e Consumode Dados na Web: Conceitos e Desafios. Tópicos em Gerenciamento de Dadose Informações (Mini Cursos - SBBD 2015), d, p. 39–69, 2015. Disponível em:<http://dexl.lncc.br/sbbd2015/anais/ShortCourses.pdf>.

LóSCIO, B. F.; STEPHAN, E. G.; PUROHIT, S. Data on the Web Best Practices: DatasetUsage Vocabulary. [S.l.], 2016.

MAALI, F.; ERICKSON, J.; ARCHER, P. Data catalog vocabulary (DCAT). [S.l.], 2014.

MöLLER, K. Lifecycle models of data-centric systems and domains: The abstractdata lifecycle model. Semant. web, IOS Press, Amsterdam, The Netherlands, TheNetherlands, v. 4, n. 1, p. 67–88, jan. 2013. ISSN 1570-0844. Disponível em:<http://dl.acm.org/citation.cfm?id=2595053.2595060>.

MONGODB. MongoDB 3. Manual. [S.l.]: MongoDB, 2017. <https://docs.mongodb.com/>.Acesso em 10 de fevereiro de 2017.

NATH, K.; DHAR, S.; BASISHTHA, S. Web 1.0 to Web 3.0 - Evolution of the Web andits various challenges. In: 2014 International Conference on Reliability Optimization andInformation Technology (ICROIT). [S.l.: s.n.], 2014. p. 86–89.

NATH, K.; ISWARY, R. What comes after Web 3.0? Web 4.0 and the future. In: InternationalConference on Computing and Communication Systems (I3CS15). [S.l.]: Research Gate, 2015.II.

NUCIVIC. NuCivic Guide to DKAN. [S.l.]: NuCivic, 2015. <http://www.nucivic.com/wp-content/uploads/2015/06/NuCivicGuidetoDKAN.pdf>. Acesso em 22 de dezembro de 2016.

OLIVEIRA, L. E. R. d. A.; LÓSCIO, B. F. Uma abordagem para captura de informações sobreaplicações que fazem uso de dados abertos. Revista Brasileira de Administração Científica, v. 5,n. 2, p. 127, 2014. ISSN 2179-684X. Disponível em: <http://sustenere.co/journals/index.php/rbadm/article/view/SPC2179-684X.2014.002.0010>.

http://ceweb.br/livros/dados-abertos-conectados/

http://ceweb.br/livros/dados-abertos-conectados/

http://junar.github.io/junar-manual/en/build/html/index.html

http://junar.github.io/junar-manual/en/build/html/index.html

http://dexl.lncc.br/sbbd2015/anais/ShortCourses.pdf

http://dl.acm.org/citation.cfm?id=2595053.2595060

https://docs.mongodb.com/

http://www.nucivic.com/wp-content/uploads/2015/06/NuCivicGuidetoDKAN.pdf

http://www.nucivic.com/wp-content/uploads/2015/06/NuCivicGuidetoDKAN.pdf

http://sustenere.co/journals/index.php/rbadm/article/view/SPC2179-684X.2014.002.0010

http://sustenere.co/journals/index.php/rbadm/article/view/SPC2179-684X.2014.002.0010

REFERÊNCIAS 113

OLIVEIRA, M. I. S. et al. Open government data portals analysis: The brazilian case. In:Proceedings of the 17th International Digital Government Research Conference on DigitalGovernment Research. New York, NY, USA: ACM, 2016. (dg.o ’16), p. 415–424. ISBN978-1-4503-4339-8. Disponível em: <http://doi.acm.org/10.1145/2912160.2912163>.

OPENDATASOFT. OpenDataSoft documentation. [S.l.]: OpenDataSoft, 2016. <https://docs.opendatasoft.com/en/>. Acesso em 21 de dezembro de 2016.

PRITCHETT, D. Base: An acid alternative. Queue, ACM, New York, NY, USA, v. 6, n. 3, p.48–55, maio 2008. ISSN 1542-7730. Disponível em: <http://doi.acm.org/10.1145/1394127.1394128>.

RUDMAN, R.; BRUWER, R. Defining web 3.0: opportunities and challenges. TheElectronic Library, v. 34, n. 1, p. 132–154, 2016. Disponível em: <http://dx.doi.org/10.1108/EL-08-2014-0140>.

SOCRATA. Socrata - System Architecture. [S.l.]: Socrata, 2016. <http://open-source.socrata.com/architecture/>. Acesso em 21 de dezembro de 2016.

UMBRICH, J.; NEUMAIER, S.; POLLERES, A. Quality assessment and evolution of open dataportals. In: Proceedings of the 2015 3rd International Conference on Future Internet of Thingsand Cloud. Washington, DC, USA: IEEE Computer Society, 2015. (FICLOUD ’15), p. 404–411.ISBN 978-1-4673-8103-1. Disponível em: <http://dx.doi.org/10.1109/FiCloud.2015.82>.

[heading=bay]

http://doi.acm.org/10.1145/2912160.2912163

https://docs.opendatasoft.com/en/

https://docs.opendatasoft.com/en/

http://doi.acm.org/10.1145/1394127.1394128

http://doi.acm.org/10.1145/1394127.1394128

http://dx.doi.org/10.1108/EL-08-2014-0140

http://dx.doi.org/10.1108/EL-08-2014-0140



http://dx.doi.org/10.1109/FiCloud.2015.82

Documents

Lairson Emanuel R. de Alencar Oliveira - repositorio.ufpe.br · Nosso casamento foi ... nos afastar de nosso Pai Celestial e se tornou um grande amigo. Marcelo, o Grande Marcelo,