HUGO RICARDO BAIA DA SILVA

OPENOW: UMA FERRAMENTA PARA DISPONIBILIZAÇÃO DE DADOS

ABERTOS

Trabalho de Graduação

Universidade Federal de Pernambuco

www.cin.ufpe.br

RECIFE
2019
 Hugo Ricardo Baia da Silva

OPENOW: UMA FERRAMENTA PARA DISPONIBILIZAÇÃO DE

DADOS ABERTOS

Trabalho apresentado ao Programa de Graduação em En-

genharia da Computação do Centro de Informática da Uni-
versidade Federal de Pernambuco como requisito parcial
para obtenção do grau de Bacharel em Engenharia da
Computação.

Orientador: Vinicius Cardoso Garcia

RECIFE
2019
Trabalho de graduação apresentado por Hugo Ricardo Baia da Silva ao programa de gradu-
ação em Engenharia da Computação do Centro de Informática da Universidade Federal de
Pernambuco, sob o título Openow: Uma Ferramenta para Disponibilização de Dados Aber-
tos, orientado pelo Prof. Vinicius Cardoso Garcia e aprovada pela banca examinadora formada
pelos professores:

———————————————————————–
Prof. Vinicius Cardoso Garcis
Centro de Informática/UFPE

———————————————————————–
Profª. Bernadette Farias Lóscio
Centro de Informática/UFPE

RECIFE
2019
Dedico este trabalho a minha mãe Patricia e ao meu avô
José (in memorian), por sempre apoiarem meus sonhos e
acreditarem em mim.
 Agradecimentos

Agradeço a Deus pela vida. Agradeço à minha mãe Patricia por ser a minha base ao
longo dessa jornada. Ao meu orientador, o professor Vinicius Garcia pelo apoio durante a minha
pesquisa. Ao CESAR e aos colegas de trabalho, por todo o aprendizado e desenvolvimento
profissional. Aos meus colegas de curso pelo apoio nos momentos de aprendizado e sofrimento.
Ao Centro de Informática da UFPE, professores e funcionários por serem essenciais para a
minha formação. Por fim, a todos que me apoiaram e acreditaram que eu podia chegar até aqui,
especialmente: Nacy, Nilza, Dona Nina (in memorian) e Ivonete (in memorian).
 Around here, however, we don’t look backwards for very long.
We keep moving forward, opening up new doors and doing new things,
because we’re curious... and curiosity keeps leading us down new paths.
—WALT DISNEY
 Resumo

Na era da web semântica surge a necessidade de se disponibilizar dados em formato compreensí-

vel por máquina, além de estabelecer padrões para permitir a cooperação entre os computadores.
Dentro deste contexto, os dados abertos tem o potencial de gerar diversos benefícios econômicos
e sociais. Este trabalho conduz um estudo acerca das problemáticas encontradas na área dos
dados abertos, bem como de possíveis soluções. Além disso, este trabalho detalha o desenvol-
vimento de uma ferramenta que tem como objetivo facilitar o processo de disponibilização e
consumo de dados abertos no âmbito do desenvolvimento de aplicações. Espera-se que esse tra-
balho possa ser o pontapé inicial para uma iniciativa que possa contribuir para o desenvolvimento
da área dos dados abertos.

Palavras-chave: Dados Abertos, Open Government

 Abstract

In the era of the semantic web the need arises to make data available in a machine-readable
format, in addition to establishing standards to allow cooperation between computers. Within
this context, open data has the potential to generate diverse economic and social benefits. This
work conducts a study about the problems encountered in the area of open data, as well as
possible solutions. In addition, this work details the development of a tool that aims to facilitate
the process of availability and consumption of open data in the scope of application development.
It is hoped that this work could kick-start an initiative that could contribute to the development
of the open data area.

Keywords: Open Data, Open Government

 Lista de Figuras

2.1 Riscos e barreiras da abertura de dados . . . . . . . . . . . . . . . . . . . . . . 18

2.2 Barreiras para publicação de dados abertos . . . . . . . . . . . . . . . . . . . . 19
2.3 Barreiras para reutilização de dados abertos . . . . . . . . . . . . . . . . . . . 20
2.4 Arquitetura da ferramenta Gov-SM . . . . . . . . . . . . . . . . . . . . . . . . 22

3.1 Arquitetura da Aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2 Fluxo de uso da ferramenta . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Tela de dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4 Tela de datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.5 Processo de extração dos dados . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.6 Schema criado no banco de dados . . . . . . . . . . . . . . . . . . . . . . . . 29
3.7 Tela de APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.1 Criação de um novo dataset . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2 Criação de um novo endpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
 Lista de Tabelas

3.1 Estrutura de acesso às APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1 APIs criadas para demonstração . . . . . . . . . . . . . . . . . . . . . . . . . 34

 Lista de Acrônimos

API Application Programming Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

LAI Lei de Acesso à Informação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
OGP Open Government Partnership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
SaaS Software as a Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
W3C World Wide Web Consortium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
 Sumário

1 Introdução 12
1.1 Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4 Estrutura do Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2 Fundamentação Teórica 15
2.1 Dados Abertos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.1 Definição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.2 Contexto Histórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.3 Desafios dos Dados Abertos . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3 Solução 24
3.1 Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.1 Tecnologias Utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.2 Gerenciamento de Fontes de Dados . . . . . . . . . . . . . . . . . . . 28
3.2.3 Gerenciamento das APIs . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.4 Acesso às APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4 Hands On 33
4.1 Criação dos Datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2 Criação das APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3 Acesso às APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5 Conclusão 37
5.1 Resultados Obtidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Referências 39
 12

1
Introdução

1.1 Contexto

Em março de 1989, Tim Berners-Lee apresentou uma proposta para uma nova maneira
de compartilhar conhecimento e recursos: a World Wide Web (ou apenas web) [1]. Inicialmente, a
web consistia de informações estáticas, provenientes de arquivos, e raríssimas exceções possuíam
conteúdo dinâmico. A perspectiva de uma web dinâmica projetava as possibilidades da web para
um novo patamar, iríamos sair das rudimentares Web Pages e partir para o desenvolvimento de
aplicações web.
A transformação digital vivenciada nas últimas décadas transformou nosso mundo, e
o crescimento acelerado da web a transformou em uma grande fonte de dados distribuída
e colaborativa. Porém, fazer uso dessas informações é algo complexo. Neste contexto, se
desenvolvem técnicas e ferramentas para lidar com esses dados, e muitas dessas contribuições
são provenientes de áreas como estatística, inteligência artifical, big data, business intelligence,
entre outras.
Na terceira geração da web, conhecida com era da web semântica, as máquinas passaram
a executar tarefas e a tomar decisões [2]. Assim, surge a necessidade de se disponibilizar dados
em formato compreensível por máquina, além de estabelecer padrões para permitir a cooperação
entre os computadores.
Entre as formas de se disponibilizar dados, existe o conceito de dados abertos, que será
abordado ao longo deste trabalho. Esse conceito pode ser aplicado para qualquer fonte e tipo de
informação. Apesar de muitas vezes ser associado ao setor público, corporações, organizações,
universidades e até mesmo indivíduos podem fazer uso dos benefícios trazidos pelo uso dos
dados abertos.

1.2 Motivação

Uma das aplicações mais importantes dos dados abertos é no conceito de Open Go-
vernment, onde os governos e cidadãos estão preocupados com a transparência dos trabalhos,
das políticas e da administração pública. As informações disponibilizadas tem o potencial
de aumentar a fiscalização, a participação popular e a colaboração entre governo e sociedade,
1.3. OBJETIVOS 13

gerando valor econômico e social [3]. Do mesmo modo, o uso adequado dessas informações
pode ajudar a aumentar a eficiência e efetividade dos serviços públicos [4].
Apesar da importância e relevância do uso dos dados abertos, a disponibilização desses
dados e o desenvolvimento de soluções que fazem uso desses dados ainda enfrentam diversos
desafios [5][6], dos quais podemos destacar:

 Fontes de informação descentralizadas: apesar de existirem alguns portais que

agrupem o acesso à informação, existem múltiplas fontes de dados que não são
integradas. Desse modo, para desenvolver algum tipo de aplicação é necessário lidar
com as particularidades de cada fonte de dados;

 Falta de padronização dos dados: muitas vezes, os dados disponibilizados não

seguem nenhum padrão, podendo ser disponibilizados nos mais diferentes formatos
(CSV, XML, API REST, etc..);

 Dados mortos: em alguns casos, não há garantia que os dados estão sendo atualiza-
dos;

 Comunicação em uma única direção: muitas vezes as informações são publicadas

em uma única direção e , as vezes, é útil que haja alguma forma de interagir com o
provedor da informação.

A análise dos problemas encontrados nessa área nos revela diversas oportunidades que
podem ser trabalhadas para que os objetivos sociais e econômicos dos dados abertos possam ser
alcançados.

1.3 Objetivos

Com base no que já foi exposto, o objetivo geral deste trabalho é desenvolver uma
ferramenta de apoio para facilitar a disponibilização e consumo de dados abertos, buscando
resolver ou mitigar os problemas que foram apresentados anteriormente.
São objetivos específicos deste trabalho:

 Desenvolvimento de um sistema intuivo para disponibilização de dados abertos;

 Permitir o cadastro de diferentes conjuntos de dados no sistema;

 Permitir a criação de uma Application Programming Interface (API) totalmente

customizável, intuitiva e bem documentada.
1.4. ESTRUTURA DO DOCUMENTO 14

1.4 Estrutura do Documento

O restante deste trabalho está organizado da seguinte forma: No Capítulo 2 é feito um

detalhamento da área, e então é apresentada a problemática que irá ser trabalhada. No Capítulo 3
é apresentado o detalhamento da solução desenvolvida, e no Capítulo 4 temos uma demonstração
de uso da ferramenta. Finalizando o documento, o Capítulo 5 apresenta as conclusões sobre
o desenvolvimento do projeto, enumera as contribuições realizadas e faz uma avaliação dos
resultados obtidos, propondo melhorias e possíveis trabalhos futuros.
 15

2
Fundamentação Teórica

No capítulo anterior pudemos conhecer um pouco da importância e dos benefícios dos

dados abertos. Neste capítulo vamos apresentar o conceito por trás dessa área. Nós vamos
entender o que são os dados abertos, como surgiram, e mostrar um pouco da cronologia dessa
área proeminente. Em seguida, vamos partir para o estudo das problemáticas existentes na área
dos dados abertos.
Como nem tudo são flores, essa área enfrenta algumas dificuldades e barreiras que a
impede de atingir seu máximo potencial. São vários os pontos que podem ser trabalhados, porém,
neste trabalho, vamos focar nos problemas técnicos que dificultam o processo de disponibilização
e consumo dos dados.
Por fim, vamos estudar alguns trabalhos relacionados que irão ajudar no desenvolvimento
de uma nova ferramenta que visa contribuir para mitigar os problemas encontrados. Após
os esclarecimentos providos neste capítulo, poderemos partir para o detalhamento da solução
desenvolvida, que é o tema do próximo capítulo.

2.1 Dados Abertos

2.1.1 Definição

Segundo o Open Knowledge Foundation1 , dados abertos "são dados que podem ser
livremente usados, reutilizados e redistribuídos por qualquer pessoa - sujeitos, no máximo, à
exigência de atribuição da fonte e compartilhamento pelas mesmas regras". Os dados abertos
são os alicerces de construção do conhecimento aberto e possuem aplicações nas mais diversas
áreas do conhecimento [7][8].
1 https://okfn.org/
2.1. DADOS ABERTOS 16

2.1.2 Contexto Histórico

Embora o termo “dados abertos” tenha surgido recentemente2 , a ideia por trás dele é
de longa data. No começo dos anos 40, Robert King Merton3 mostrou a importância de os
resultados de pesquisas científicas serem abertos a todos. Ainda nesse sentido, desde os anos
50, a noção de “Open Government” vem sendo debatida. Governos estão preocupados com
transparência e com a ideia de que os cidadãos tenham o “right to know”, ou seja, o direito de
saber [9].
Anos mais tarde, a ideia dos dados abertos foi impulsionada pelo advento da internet.
Em 2007, um grupo de pioneiros dos dados abertos se reuniu na Califórnia para debater e definir
o conceito de dados públicos abertos. Juntos, ele criaram alguns princípios simples que servem
como uma base para o que se tornou o movimento dos dados abertos e que nos permite definir e
avaliar os dados públicos abertos [22]. Os oito princípios são:

1. Completo: todo o conjunto de dados públicos, qualquer informação ou gravação

digital armazenada, que não possui limitações de privacidade, privilégios e segurança,
deve ser disponibilizado abertamente.

2. Primário: devem ser publicados dados em formato bruto, respeitando semântica

original e estrutura original.

3. Temporal: o dado deve ser publicado tão rápido quanto necessário para preservar
seu valor.

4. Acessível: os dados devem ser disponibilizados de forma que o maior número

possível de pessoas tenha acesso e para o maior número de propósitos possível.

5. Processável por máquina: os dados devem ser suficientemente estruturados para

permitir processamento automático.

6. Não discriminatório: os dados devem estar disponíveis para todos sem que o consu-
midor precise se cadastrar.

7. Não proprietário: os dados devem estar em um formato sobre o qual nenhuma

entidade tenha controle exclusivo.

8. Livre de licenças: os dados devem estar livres de quaisquer questões jurídicas que
possam restringir o uso, como patentes ou direitos autorais.

Nos anos seguintes, diversos governos e organizações adotaram iniciativas envolvendo

dados abertos. Em 2009, o então presidente americano, Barack Obama, assinou um memorando4
2 O termo “dados abertos” apareceu pela primeira vez em 1995,
em um documento da American scientific agency.
3 Robert
King Merton foi um sociologista Americano e um dos pais da sociologia da ciência. A teoria que leva
seu nome mostra os benefícios dos dados científicos abertos.
4 https://obamawhitehouse.archives.gov/the-press-office/

transparency-and-open-government
2.1. DADOS ABERTOS 17

que diz respeito a um governo aberto, do qual dados abertos são um dos pilares. Pouco tempo
depois, o portal de dados abertos do governo americano5 foi disponibilizado. Inicialmente com
47 datasets, após um ano já contava com mais de 250,000 datasets [18]. Desde então, diversas
plataformas foram disponibilizadas para permitir que pesquisadores, jornalistas, empreendedores,
e pessoas em geral tivessem acesso a dados que pudessem resultar em novas descobertas e
oportunidades.
Diversos países e organizações seguiram o movimento de abertura de dados, e com o
Brasil não foi diferente. A lei nº 12.527/20116 , conhecida como Lei de Acesso à Informação
(LAI)7 , regulamentou o direito constitucional de acesso às informações públicas. Além disso,
o Brasil foi membro co-fundador do Open Government Partnership (OGP)8 e, como parte dos
compromissos firmados, criou o portal brasileiro de dados abertos9 . Em 2019, o portal listava
mais de 6,000 datasets, uma quantidade bem inferior em relação a outros países.

2.1.3 Desafios dos Dados Abertos

No processo de planejamento de uma nova ferramenta de dados abertos, os pricipais

desafios relacionados a essa área precisam ser estudados. Nesta seção vamos abordar os desafios
dos dados abertos. Inicialmente de maneira mais geral, e, em seguida, de forma mais voltada ao
contexto do desenvolvimento de aplicações que fazem uso dos dados.
De acordo com os estudos conduzidos por MARTIN et al. [14], os riscos e barreiras
relacionados à abertura dos dados podem ser organizados em 7 categorias, como mostra a
Figura 2.1. Na figura, todas essas categorias de riscos e barreiras estão ligadas, através de setas,
à dificuldade e atraso no processo de abertura dos dados. As categorias são:

1. Dificuldades de acesso: Os dados devem ser acessados tanto por humanos quanto por
máquinas. Plataformas que necessitam de algum tipo de registro podem desencorajar
os usuários, por outro lado, é necessário ter informações sobre o uso dos dados.

2. Problemas de governança: O processo e abertura dos dados está, muitas vezes,

relacionado a uma decisão política e isso coloca em risco a manutenção da iniciativa.
Questões como a resistência dos servidores públicos em disponibilizar seus dados, as
políticas de atualização dos dados e a fragmentação dos dados em diferentes camadas
administrativas são alguns dos riscos dessa categoria.

3. Custos: O processo de abertura dos dados envolve um certo custo, tanto do ponto de
vista técnico quanto de recursos humanos. Ferramentas tecnológicas precisam ser
5 https://www.data.gov/
6 http://www.planalto.gov.br/ccivil_03/_ato2011-2014/2011/lei/l12527.htm
7 http://www.acessoainformacao.gov.br/
8A OGP é uma iniciativa que busca combinar a força de governos e organizações para promover governanças
transparentes e inclusivas. https://www.opengovpartnership.org/
9 http://dados.gov.br/
2.1. DADOS ABERTOS 18

construídas e pessoas precisam ser treinadas. Além disso, o retorno do investimento

é colocado em dúvida.

4. Problemas com os dados: Aqui os riscos estão relacionados a confiabilidade, quali-

dade e formato dos dados. Um dos grandes problemas é a disponibilização dos dados
em variados formatos.

5. Questões legais: Serviços que fazem uso de múltiplas bases de dados podem se
deparar com licensas e condições de uso que são incompatíveis.

6. Metadados: Metadados são usados para descrever as bases de dados. Eles são
importantes no processo de obtenção e reuso das bases de dados. Porém, carecem de
padronização e muitas vezes podem estar imcompletos.

7. Falta de habilidade para lidar com os dados: Uma das grandes questões dessa
categoria é a necessidade de um alto grau de conhecimento tecnológico para fazer
uso dos dados.

Figura 2.1: Diagrama de espinha de peixe que representa riscos e barreiras relacionados à
abertura de dados

Fonte: MARTIN et al. [14]

Além dos pontos já apresentados, o European Data Portal10 faz uma análise da maturidade
do processo de abertura dos dados na Europa [17], e destaca as principais barreiras encontradas
10 https://www.europeandataportal.eu
2.1. DADOS ABERTOS 19

por seus membros. Os desafios e problemas encontrados pelos que vão fazer uso dos dados
diferem dos encontrados por quem vai prover os dados. Como mostra a Figura 2.2 podemos
observar que os aspectos financeiros e legais são os maiores impeditivos para a publicação
de dados abertos, seguidos por questões técnicas, políticas e outras. Já no processo de reuso
dos dados disponibilizados, a Figura 2.3 mostra que as principais barreiras são de natureza
técnica e de conscientização sobre os benefícios dos dados abertos, seguidos por questões de
disponibilidade, financeiras, legais e outras.

Figura 2.2: Barreiras para publicação de dados abertos mais mencionadas pelas administrações
públicas do EU28 em 2017

Fonte: European Commission, 2017 [17]

Um elo importante de toda a cadeia que o envolve os dados abertos é o desenvolvimento

de soluções que utilizam os dados e, assim, produzem os benefícios econômicos e sociais já
mencionados. Existem diversos estudos que mostram a experiência dos desenvolvedores no
processo de uso dos dados, bem como a experiência do dono dos dados em provê-los.
Os estudos conduzido por Brito et al. são excelentes para o entendimento desta problemá-
tica no Brasil, pois apresentam as experências de integração de diferentes fontes de dados abertos
no contexto do desenvolvimento de aplicações [5][19]. Brito et al. apresentam 4 problemas
encontrados, são eles:

 Fontes de dados múltiplas e descentralizadas: Diversos portais publicam dados.

Então, o desenvolvimento de uma aplicação coerente, exige todo um processo de
2.1. DADOS ABERTOS 20

Figura 2.3: Barreiras para reutilização de dados abertos mais mencionadas pelas administrações
públicas do EU28 em 2017

Fonte: European Commission, 2017 [17]

busca e análise das bases de dados;

 Diversos padrões para publicação dos dados: Cada portal escolhe sua forma de
publicar os dados. Consequentemente, o reuso de componentes de software que
fazem o consumo dos dados é prejudicado;

 Dados mortos: Muitas vezes não há garantias sobre a atualização dos dados. Sendo
assim, o desenvolvimento de aplicações em tempo real se torna inviável;

 Comunicação unidirecional: Os portais disponibilizam os dados, porém, aplicações

mais úteis precisam de algum tipo de interação com a base de dados.

Entre os pontos apresentados, podemos perceber que um ponto que se repete é a questão
da falta de padronização na publicação dos dados. As plataformas de dados abertos disponibili-
zam na internet arquivos nos mais variados formatos (pdf, xls, json, csv, etc...). Porém, a forma
como esses dados são disponibilizados podem restringir o desenvolvimento de aplicações, pois
impõe ao desenvolvedor uma dificuldade adicional de encontrar os dados, extraí-los, analisá-los
e, então, obter informações relevantes para seu propósito.
Diversos esforços foram feitos no sentido de estabelecer algum tipo de padronização
para o provimento dos dados abertos. O World Wide Web Consortium (W3C) publicou uma
2.2. TRABALHOS RELACIONADOS 21

série de recomendações11 relacionadas a publicação e uso de dados na web. As 35 boas práticas

propostas pelo W3C tratam de questões como: formato dos dados, qualidade dos dados, acesso
aos dados, licenças, entre outros.
Os problemas apresentados vão servir de base para o desenvolvimento de uma solução
tecnológica que contribua para resolver esses problemas. Na próxima seção vamos nos aprofundar
em trabalhos que também tratam desses problemas e que apresentam novas ideias que vão ser
úteis no processo de desenvolvimento de uma solução.

2.2 Trabalhos Relacionados

Novas soluções para os dados abertos devem ser capazes de lidar com os problemas
existentes, de modo que seja possível atingir os benefícios sociais e financeiros provenientes da
abertura dos dados. Nesta seção vamos estudar dois trabalhos que apresentam propostas para
resolver alguns dos desafios e barreiras apresentados anteriormente. O elo comum que liga esses
trabalhos é a apresentação de uma proposta de plataforma de dados abertos, mas que além disso,
desconstroem a ideia de um portal que apenas disponibiliza dados. A ideia comum é a construção
de uma infraestrutura que permita melhorar o processo de disponibilização e consumo dos dados
abertos.
O ponto chave é a criação de um Software as a Service (SaaS), ou Software como Serviço,
voltado para o contexto dos dados abertos. Lóscio e Gama argumentam que essas soluções
devem prover os dados abertos como um serviço (Open Data as a Service) através de uma
infraestrutura na nuvem [21].
O trabalho de Lóscio e Gama [21], nos apresenta a ideia de um ecossistema de dados
abertos. Esse ecossistema seria derivado da ideia dos ecossitemas de negócios, que foi apre-
sentado por James F. Moore12 no começo dos anos 90. Segundo Moore, citado por Lóscio
e Gama, em um ecossistema de negócios, as empresas co-evoluem as capacidades em torno
de uma nova inovação: elas trabalham de forma cooperativa e competitiva para apoiar novos
produtos, satisfazer as necessidades dos clientes e, eventualmente, incorporar a próxima rodada
de inovações.
O ecossistema de dados abertos seria um ecossistema baseado em software, e, ao invés
de ser um mero provedor de dados através de uma API, a plataforma proveria serviços básicos
para permitir que os desenvolvedores fizessem uso desses serviços. Permitindo assim: integrar
provedores de dados com a plataforma, construir serviços na plataforma e construir aplicativos
usando esses serviços.
Ainda nesta linha de contrução de uma plataforma de dados abertos, o trabalho de Burégio
et al. é voltado para a disponibilização de dados abertos governamentais [20]. Considerando
3 dos problemas já mencionados anteriormente - fontes de dados múltiplas e descentralizadas,
11 https://www.w3.org/TR/dwbp/
12 James F. Moore é pioneiro na abordagem do ecossistema de negócios para estudar redes de organizações que,
juntas, constituem um sistema de apoio mútuo e que co-evoluem contribuições.
2.2. TRABALHOS RELACIONADOS 22

múltiplos padrões para publicação dos dados e comunicação unidirecional - Burégio et al.
apresenta uma proposta de arquitetura para aumentar o poder dos dados abertos e transformar o
governo numa máquina social. Essa máquina busca prover APIs especializadas para permitir a
criação de outros sistemas sobre ela.
A solução proposta por Burégio et al. para o desafio de integrar bases de dados he-
terogêneas consiste em um mecanismo para se obter os dados, nos mais diferentes formatos
(e.g., csv, xml, html, pdf, json, etc...), através de um extrator específico para cada tipo de dado
e, então, transformá-los em um formato desejado e mais apropriado para seu armazenamento.
Ainda segundo esse trabalho, o próximo passo é a disponibilização de um conjunto de APIs
especializadas para cada máquina social.
A Figura 2.4 mostra a arquitetura proposta por Burégio et al., nela podemos observar
os diversos serviços fornecidos pela ferramenta, que se comunicam com as máquinas sociais
através de APIs especializadas. Além disso, os cidadãos, desenvolvedores, aplicações e outras
iniciativas se comunicam com a ferramenta através dos serviços fornecidos.

Figura 2.4: Arquitetura da ferramenta Gov-SM

Fonte: Burégio et al. [20]

2.3. CONSIDERAÇÕES FINAIS 23

2.3 Considerações Finais

Neste capítulo pudemos ter uma visão geral sobre os dados abertos. Entendemos o
conceito por trás dos dados abertos, apresentamos os princípios pelos quais os dados são regidos,
e entendemos brevemente como se deu o contexto histórico dessa área. Além disso, estudamos
as dificuldades e barreiras encontradas na área e, por fim, estudamos alguns trabalhos que
tratam esse problema de forma mais específica (voltados para o desenvolvimento de soluções
tecnológicas que fazem uso dos dados).
Todo o estudo conduzido ao longo deste capítulo é de suma importância para o conjunto
do trabalho, pois serviu como o alicerce teórico que irá nortear o desenvolvimento de uma
ferramenta que visa contribuir para a área dos dados abertos. Este capítulo permitiu compreender
melhor a situação dos dados abertos, seus benefícios e suas problemáticas.
No próximo capítulo vamos detalhar a solução desenvolvida, tanto do ponto de vista
conceitual quanto técnico. Vamos apresentar a ideia por trás da ferramenta, as telas do sistema,
detalhes da arquitetura e detalhes de implementação.
 24

3
Solução

Neste capítulo apresentamos a ferramenta desenvolvida ao logo deste trabalho. A

proposta desta ferramenta é auxiliar o processo de disponibilização e uso de dados abertos.
Diante dos vários desafios apresentados nas seções anteriores, a ferramenta desenvolvida busca
facilitar o processo de abertura dos dados dos governos, organizações, empresas, ou até mesmo
de indivíduos.
A solução é uma ferramenta online, que foi batizada de Openow. Seguindo a linha dos
trabalhos relacionados que foram apresentados, essa ferramenta é mais do que um simples portal
para disponibilizar dados abertos. O Openow é uma plataforma que integra diferentes fontes de
dados e permite a criação de APIs especializadas e customizadas de forma simples e intuitiva.
Basicamente, o Openow busca atender os anseios de dois públicos principais: o consumidor e o
fornecedor dos dados.
A ferramenta desevolvida é apenas o ponto de partida para o que pode vir a ser uma grande
iniciativa na área dos dados abertos. Por isso, é muito importante contar com a colaboração
da comunidade de desenvolvedores. Portanto, o código foi disponibilizado de forma aberta na
plataforma Github1 .
Na seção 3.1 temos uma visão geral da ferramenta. Em seguida, na seção 3.2 falamos
um pouco das tecnologias utilizadas e dos detalhes de implementação adotados. Por fim, a seção
3.3 apresenta as considerações finais do capítulo.

3.1 Visão Geral

O Openow possui duas áreas principais:

 Gerenciamento de fontes de dados: A ideia desse módulo é a de centralizar as bases

de dados, ou seja, permitir que todos os dados estejam acessíveis e em um formato
comum.

 Gerenciamento das APIs: Neste módulo, a ferramenta permite a criação de APIs de

1 https://github.com/hugorbs/openow
3.1. VISÃO GERAL 25

forma dinâmica. As APIs utilizam o padrão REST2 e o usuário da ferramenta tem a

liberdade de criar endpoints3 com regras próprias utilizando os dados cadastrados no
módulo de gerenciamento de fontes de dados.

A Figura 3.1 apresenta uma visão de alto nível da arquitetura da aplicação. Nela, podemos
ver a interação entre as fontes de dados e as APIs, bem como a interação entre a aplicações que
vão fazer uso dos dados abertos e as APIs. As fontes de dados são criadas através do upload de
arquivos em diferentes formatos, em seguida, os dados dos arquivos são armazenados em um
banco de dados e podem ser acessados através de APIs especializadas. Além disso, as APIs são
criadas de forma customizada e podem acessar várias fontes de dados em uma mesma consulta.
Por fim, as mais diversas aplicações podem acessar as APIs e ter acesso aos dados.

Figura 3.1: Arquitetura da Aplicação

Fonte: O próprio autor.

2 RepresentationalState Transfer é utilizado para requisição e resposta por HTTP de recursos do servidor, seja
um pedido de criação, deleção, atualização ou recuperação.
3 Pontos de comunicação com o sistema.
3.2. IMPLEMENTAÇÃO 26

O fluxo de uso da ferramenta se dá da seguinte forma:

Figura 3.2: Fluxo de uso da ferramenta

Fonte: O próprio autor.

1. A parte interessada em prover os dados acessa a plataforma e faz upload das bases de
dados;

2. Com as bases de dados integradas ao sistema, o responsável por prover os dados cria
sua API com seus endpoints customizados.

3. O consumidor dos dados acessa o endereço base da API que foi criada dinamicamente
pelo sistema para ter acesso à informações sobre a API, ou pode acessar os dados
diretamente através dos endpoints criados.

Além dessas áreas, o sistema também possui uma página de dashboard para centralizar
informações importantes referentes aos 2 módulos principais.

Figura 3.3: Tela de dashboard

Fonte: O próprio autor.

3.2 Implementação

3.2.1 Tecnologias Utilizadas

A ferramenta foi desenvolvida utilizando a stack4 tecnológica MEAN:

4 Termo utilizado para se referir as camadas tecnológicas da aplicação.
3.2. IMPLEMENTAÇÃO 27

 MongoDB5 – Banco de dados orientado a documentos

 Express6 – Framework de desenvolvimento web para Node

 Angular7 – Framework MVC para JavaScript

 Node.js8 – Ambiente de execução JavaScript

Essa stack de desenvolvimento define desde a plataforma de desenvolvimento utilizada

até a tecnologia de banco de dados. Um diferencial desta stack é que ela é toda baseada
na liguagem de programação Javascript, ou seja, todas as camadas lidam naturalmente com
a mesma linguagem. Além disso, a manipulação dos dados fica mais fácil, pois os objetos
que são armazenados no banco de dados são os mesmos objetos que todo o resto da stack de
desenvolvimento manipula.
Na stack MEAN, cada ferramenta tem um papel essencial para o funcionamento do
sistema e o ponto central dessa stack é o Node.js, que é uma plataforma assíncrona, orientada a
eventos, para desenvolvimento de aplicações de rede escaláveis.
O MongoDB é um banco de dados NoSQL9 orientado a documentos. Os documentos são
inseridos e extraídos em formato JSON, no mesmo modelo seguido para todo o resto da pilha de
desenvolvimento, de forma que nenhuma conversão se faz necessária. Para fazer a acoplamento
entre o Node.js e o MongoDB, utilizamos o pacote npm10 chamado Mongoose11 . O Mongoose
faz a modelagem dos dados, trata da validação dos tipos e facilita as operações de CRUD12 .
O Express.js é um framework Web que executa sobre a plataforma Node.js. Essa
ferramenta provê um conjunto de funções para facilitar o desenvolvimento Web: desde o
gerenciamento de rotas à manipulação de requisições e respostas HTTP.
O Angular é um framework que funciona no lado do cliente e facilita a criação de páginas
web. A renderização das telas fica a cargo dos controladores, que estão no cliente, e agem em
conjunto com modelos e templates para gerar a tela com dados para o usuário, minimizando o
processamento feito no servidor. Com o Angular, é muito mais simples associar elementos do
HTML a modelo de dados providos do servidor e vice-versa.
Essas foram as principais tecnologias utilizadas no desenvolvimento da plataforma e
foram muito importantes no sentido de facilitar e agilizar o processo de desenvolvimento. Numa
possível evolução da plataforma, novas tecnologias podem ser integradas de forma rápida e fácil
devido à forma modular que a aplicação foi construída.
5 https://www.mongodb.com/
6 https://expressjs.com/
7 https://angular.io/
8 https://nodejs.org/en/
9 Termo utilizado para definir uma classe de banco de dados não-relacionais.
10 https://www.npmjs.com/
11 https://mongoosejs.com/
12 Create, Read, Update e Delete são as quatro operações básicas de um banco de dados persistente.
3.2. IMPLEMENTAÇÃO 28

3.2.2 Gerenciamento de Fontes de Dados

Neste módulo, o usuário pode cadastrar fontes de dados em diferentes formatos (csv,
xml). A Figura 3.7 mostra a tela que exibe as fontes de dados, chamadas de datasets no sistema.
A criação de um dataset é feita através do upload de um arquivo na plataforma. Além do arquivo,
o dataset recebe um nome e uma descrição.

Figura 3.4: Tela de datasets

Fonte: O próprio autor.

Durante a criação, o sistema extrai os dados do arquivo e cria um Schema13 de forma

dinâmica. Cada Schema é mapeado para uma coleção no MongoDB e define a forma dos
documentos naquela coleção. Enquanto isso, as informações de identificação (nome, descrição e
colunas) são armazenadas no banco de dados em uma coleção chamada databases.
Como mostrado na Figura 3.5, o sistema possui um extrator específico para cada tipo
de arquivo, de modo que cada extrator pode tratar as particularidades de determinado tipo de
arquivo. Após a extração, os dados são transformados em um formato comum e então são
armazenados no banco de dados.
A collection criada para armazenar os dados recebe o nome do dataset acrescido do
prefixo "db-". A figura Figura 3.6 mostra um exemplo de collection criada no banco de dados, a
db-sales_records. Também podemos observar outras duas coleções, a apis e a databases. Como
já mencionado, a coleção de databases armazena as informações de identificação das bases de
dados, já a coleção de apis armazena as informações das APIs do sistema.

3.2.3 Gerenciamento das APIs

O módulo de gerenciamento de APIs é onde o fornecedor dos dados irá criar a API que
será usada pelo consumidor dos dados. Tal qual no gerenciamento de fontes de dados, aqui a
API recebe um nome e uma descrição. Além disso, podem ser criados os endpoints que farão
parte da API.
13 Representação do modelo que vai ser usado no banco de dados.
3.2. IMPLEMENTAÇÃO 29

Figura 3.5: Processo de extração dos dados

Fonte: O próprio autor.

Figura 3.6: Schema criado no banco de dados

Fonte: O próprio autor.

3.2. IMPLEMENTAÇÃO 30

Figura 3.7: Tela de APIs

Fonte: O próprio autor.

Para a criação de um endpoint, é preciso fornecer um nome e uma fórmula. A fórmula é a

regra que vai determinar o retorno do endpoint e ela é constituída de identificadores e operadores.
Para validar e traduzir a fórmula, foi criado um pequeno compilador, utilizando a biblioteca
Ohm14 . Este compilador tem a seguinte gramática:
c o n s t grammar = ‘
myGrammar {
EXP = AND_EXP | VAR
AND_EXP = EXP AND EXP
VAR = ID DOT ID
ID = (UNDERSCORE | LETTER ) (UNDERSCORE | LETTER | NUMBER) *
NUMBER = d i g i t +
LETTER = "A " . . " z "
UNDERSCORE = " _ "
DOT = " . "
AND = "&&"
} ‘;
Esta gramática aceita expressões do tipo <dataset>.<column>, onde o dataset se refere
à fonte de dados e o column se refere a uma coluna da base de dados. Além disso, pode ser usado
o operador && para concatenar expressões. A ideia é que essa gramática possa ser expandida
para dar suporte a muitos outros tipos de expressões, com novos operadores e funções.
Além da gramática, foram criadas funções semânticas que transformam a fórmula do
endpoint em uma operação programática que será executada no banco de dados e, assim, retornará
os resultados desejados.
14 https://ohmlang.github.io/
3.3. CONSIDERAÇÕES FINAIS 31

3.2.4 Acesso às APIs

As APIs criadas podem ser acessadas através de endereços específicos. A Tabela 3.1
mostra um exemplo de duas APIs, uma voltada para prover dados sobre educação e outra voltada
para prover dados sobre uma determinada empresa. Cada API possui uma URL base que pode
ser acessada para se obter informações sobre os endpoints daquela API. Os endpoints podem
ser acessados através da concatenação da URL base com o caminho do endpoint. No exemplo
apresentado na Tabela 3.1, a primeira API possui dois endpoints, já a segunda API possui três
endpoints associados.
Tabela 3.1: Estrutura de acesso às APIs

API URL base Descrição Endpoints

/schools
education http://{host}/api/education Dados referentes a educação.
/universities
/revenue
company-xyz http://{host}/api/company-xyz Dados referentes a empresa XYZ /expenses
/franchises
Fonte: O próprio autor.

Para se obter informações sobre as APIs do sistema, basta acessar o endereço http://{host}/api
para que sejam listadas todas as APIs, com seus respectivos nomes, descrições e endpoints as-
sociados. Já para se obter as informações específicas de uma determinada API, basta acessar o
endereço http://{host}/api/{nome_da_api}, onde o trecho {nome_da_api} deve ser substituído
pelo nome da API buscada.

3.3 Considerações Finais

Neste capítulo apresentamos a ferramenta desenvolvida e discutimos os detalhes técnicos

que fazem parte do sistema. Pudemos perceber que a solução apresentada segue uma tendência
vista na área de TI, que é o desenvolvimento de plataformas na nuvem que provêem serviços.
Além disso, o processo de idealização e construção da ferramenta buscou absorver as ideias e
experiências que foram estudados na parte de fundamentação teórica.
A ferramenta desenvolvida dá um passo importante no sentido de facilitar o processo
de disponibilização dos dados abertos, que muitas vezes é tido como uma tarefa árdua e cheia
de desafios. Por isso, integração de diferentes conjuntos de dados e a disponibilização desses
dados de forma customizada através de uma API, visa auxiliar tanto a parte interessada em
disponibilizar os dados quanto a parte interessada em fazer uso dos dados.
Do ponto de vista de quem vai disponibilizar os dados, a utilização de uma plataforma
em nuvem que segue o modelo de SaaS ajuda a reduzir custos no processo de disponibilização
dos dados, elimina a necessidade de construção de uma infraestrutura própria, além de tornar o
processo mais rápido e fácil.
3.3. CONSIDERAÇÕES FINAIS 32

Do ponto do vista de quem vai utilizar os dados, a disponibilização de uma API bem
estruturada e documentada, ao invés da simples disponibilização de arquivos com os dados, torna
o processamento das informações muito mais fácil. Consequentemente, o desenvolvimento de
soluções que fazem uso dos dados é facilitado e, assim, os benefícios provenientes do uso de
dados abertos é, de fato, alcançado.
No próximo capítulo vamos observar uma demonstração de uso da ferramenta. Vamos
utilizar o sistema, tal qual os usuários da plataforma utilizariam, e entender melhor como se dá o
funcionamento da solução.
 33

4
Hands On

Neste capítulo vamos fazer uma pequena demonstração da ferramenta desenvolvida. Para
isso, vamos utilizar duas fontes de dados disponíveis no portal de dados abertos da prefeitura da
cidade do Recife1 . Um dos arquivos se refere as empresas que estão inscritas como contribuintes
no município do Recife, o outro arquivo contém a descrição das receitas do município em 2018.
Os arquivos possuem, aproximadamente, 470.000 e 4.000 entradas, respectivamente. Além disso,
ambos os arquivos estão no formato csv.

4.1 Criação dos Datasets

Primeiramente, vamos criar dois conjuntos de dados. Para a criação de um dataset, basta
acessar a tela de datasets através do menu lateral da plataforma e então clicar no botão de criar
um novo dataset. A Figura 4.1 mostra a tela de criação de um novo dataset. O usuário dá um
nome, uma descrição e, ao fazer upload do arquivo, tem uma prévia das colunas identificadas
pelo sistema. Após a criação, uma mensagem é exibida informando se o novo dataset foi criado
com sucesso. As bases criadas foram a empresas e a receitas. Agora que já temos as bases de
dados que vão ser usadas como exemplo, vamos partir para a criação das APIs customizadas.

Figura 4.1: Criação de um novo dataset

Fonte: O próprio autor.

1 http://dados.recife.pe.gov.br/
4.2. CRIAÇÃO DAS APIS 34

4.2 Criação das APIs

Para criar uma nova API, basta acessar a tela de APIs através do menu lateral e então
clicar no botão de criar uma nova API. O usuário pode escolher um nome, uma descrição e
pode adicionar os endpoints daquela API. A tela de criação de um novo endpoint é mostrada na
Figura 4.2. No caso do endpoint, também podemos atribuir um nome e uma descrição e, além
disso, podemos criar uma fórmula para customizar o retorno desse endpoint.

Figura 4.2: Criação de um novo endpoint

Fonte: O próprio autor.

O processo de criação da fórmula é facilitado pela presença de caixas de seleção que

auto completam o texto da fórmula. Assim, é possível selecionar as bases de dados, bem como
seus campos e, então, clicar no botão lateral que insere o valor na caixa de texto da fórmula. Na
fórmula é prossível construir expressões que concatenam campos de diferentes bases de dados.
Além disso, existem um botão abaixo da caixa de texto que permite verificar se a sintaxe do que
foi digitado está correta. Para esta demonstração, criamos duas APIs e seus nomes, endereços
base e os endpoints de acesso podem ser vistos na tabela abaixo:
Tabela 4.1: APIs criadas para demonstração

API URL base Endpoints

/razao_social
empresas_info http://{host}/api/empresas_info
/codigo
/receita_prevista
receitas_info http://{host}/api/receitas_info
/receita_orgao
Fonte: O próprio autor.
4.3. ACESSO ÀS APIS 35

4.3 Acesso às APIs

Para obter informações sobre as APIs criadas, acessamos o endereço http://{host}/api e

obtemos um json como resposta. Abaixo temos a resposta recebida:
[{
" name " : " e m p r e s a _ i n f o " ,
" active ": true ,
" d e s c r i p t i o n " : " I n f o r m a c o e s da e m p r e s a s que e s t a o
i n s c r i t a s como c o n t r i b u i n t e no M u n i c i p i o do R e c i f e " ,
" endpoints " : [{
" name " : " r a z a o _ s o c i a l " ,
" d e s c r i p t i o n " : " Razao s o c i a l e d e s c r i c a o d a s
a t i v i d a d e s das empresas "
}, {
" name " : " c o d i g o " ,
" d e s c r i p t i o n " : " Razao s o c i a l e c o d i g o d a s e m p r e s a s "
}]
}, {
" name " : " r e c e i t a s _ i n f o " ,
" active ": true ,
" d e s c r i p t i o n " : " D e s c r i c a o d a s r e c e i t a em 2 0 1 8 " ,
" endpoints " : [{
" name " : " r e c e i t a _ p r e v i s t a " ,
" d e s c r i p t i o n " : " F o n t e do r e c u r s o e r e c e i t a p r e v i s t a "
}, {
" name " : " r e c e i t a _ o r g a o " ,
" d e s c r i p t i o n " : " nome d o s o r g a o s , c o d i g o e r e c e i t a p r e v i s t a "
}]
}]
Agora, as APIs já estão prontas para serem acessadas pelo consumidor dos dados. No
momento em que ele necessitar dos dados provenientes de um determinado endpoint, basta
realizar uma requisição HTTP para o endereço do endpoint. Como forma de exemplificar,
acessamos o endpoint razao_social, cujo endereço é http://{host}/api/empresa_info/razao_social.
Este endpoint retorna os dados de razão social e descrição das atividades das empresas e foi
construído com a seguinte fórmula: "empresas.razao_social && empresas.desc_atividade".
Após a realização da consulta, obtemos um json de resposta. Abaixo temos um trecho dos dados
retornados:
{
" empresas " : [{
4.4. CONSIDERAÇÕES FINAIS 36

" r a z a o _ s o c i a l " : "EMPRESA BRASILEIRA DE CORREIOS E TELEGRAFOS" ,

" d e s c _ a t i v i d a d e " : "ADMINISTRACAO PUBLICA EM GERAL"
}, {
" r a z a o _ s o c i a l " : "COMPANHIA DE TERRENOS PRAZERES " ,
" d e s c _ a t i v i d a d e " : "CORRETAGEM NO ALUGUEL DE IMOVEIS"
}, {
" r a z a o _ s o c i a l " : "GRANDES ARMAZENS DO RECIFE S A" ,
" d e s c _ a t i v i d a d e " : "CORRETAGEM NO ALUGUEL DE IMOVEIS"
}, {
" r a z a o _ s o c i a l " : "CORELLI COMERCIO E REPRESENTACAO LTDA" ,
" d e s c _ a t i v i d a d e " : "REPRESENTANTES COMERCIAIS E AGENTES DO
COM DE MERCAD EM GERAL N/ ESPECIALIZADO"
}, {
" r a z a o _ s o c i a l " : "CDC CENTRAL DE DESPACHOS E CONTABILIDADE LTDA"
" d e s c _ a t i v i d a d e " : "ATIVIDADES DE CONTABILIDADE"
}, ...

4.4 Considerações Finais

Neste capítulo utilizamos exemplos bem simples para demonstrar o uso da ferramenta.
Pudemos perceber que a criação dos datasets e das APIs é feita de forma rápida e fácil. Além
disso, o acesso ao dados através de endpoints é feito de forma trivial, além de ser uma forma
muito utilizada por desenvolvedores de aplicações. No próximo capítulo vamos apresentar as
conclusões que tiramos sobre o trabalho desenvolvido, falar sobre os resultados obtidos e discutir
um pouco sobre os possíveis trabalhos futuros.
 37

5
Conclusão

Este trabalho pode ser dividido em três partes principais: O estudo das problemáticas na
área dos dados abertos; o estudo de possíveis soluções para algumas dessas problemáticas; e o
desenvolvimento de uma ferramenta.
Durante o estudo realizado, optou-se por focar nas problemáticas relativas ao processo
de disponibilização e consumo de dados abertos no âmbito do desenvolvimento de aplicações.
Dentro deste contexto, foram estudados trabalhos que traziam ideias muito interessantes para
mitigar ou resolver os problemas encontrados [20][21]. As soluções estudadas tratavam da
criação de plataformas online para disponibilização de serviços baseados nos dados.
Seguindo a linha dos estudos analisados neste trabalho, foi desenvolvida uma ferramenta
online com o objetivo de facilitar o processo de disponibilização e consumo dos dados abertos.
Essa ferramenta, batizada de Openow, busca oferecer mecanismos para integrar bases de dados
heterogêneas e facilitar a disponibilização e consumo dos dados através de APIs customizadas.

5.1 Resultados Obtidos

Na seção de Hands On, pudemos perceber que o processo de disponibilizar dados atra-
vés da plataforma é muito simples e rápido. Com alguns poucos cliques, até mesmo usuários
com pouca expertize tecnológica conseguem criar meios de disponibilizar seus dados na inter-
net. A ferramenta desenvolvida dá um passo importante no sentido de facilitar o processo de
disponibilização dos dados abertos, que muitas vezes é uma tarefa difícil e cheia de barreiras.
Para quem vai disponibilizar os dados, o modelo de plataforma em nuvem ajuda a reduzir
custos no processo de disponibilização dos dados, elimina a necessidade de construção de uma
infraestrutura própria, além de tornar o processo mais rápido e fácil. Já para quem vai utilizar os
dados, a disponibilização de uma API especializada facilita o processo de desenvolvimento de
soluções e iniciativas na área dos dados abertos.
Apesar dos benefícios obtidos, sabemos que ainda é pouco para a ferramenta se tornar
uma grande iniciativa dos dados abertos. Na próxima seção vamos ver alguns trabalhos que
precisam ser feitos para que a ferramenta se desenvolva e atinja os resultados almejados.
5.2. TRABALHOS FUTUROS 38

5.2 Trabalhos Futuros

Entre as várias problemáticas apresentadas na seção de Fundamentação Teórica, a

ferramenta desenvolvida trata principalmente de duas: a integração entre fontes de dados
heterogêneas e a diversidade de padrões para publicação dos dados. São muitas as questões que
podem ser trabalhadas na área dos dados abertos, e entendemos que essa ferramenta é apenas um
ponto de partida para algo maior. A ideia é que essa ferramenta possa ser evoluída até chegar em
um grau de robustez que a permita ser uma aliada poderosa no processo de abertura dos dados.
Existem vários pontos que podem ser adicionados ou aprimorados, dentre os quais
podemos destacar:

 Permitir a criação de endpoints que façam uso de outros verbos HTTP: O intuito
é que os consumidores dos dados possam interagir com a plataforma e não apenas
receber os dados;

 Ampliação da gramática de criação de fórmulas: é desejável que a ferramenta tenha

um leque variado de opções para customizar a API. A adição de funções que
manipulassem os dados retornados seria de grande valia para a ferramenta;

 Extração de dados proveniente de fontes mais complexas: lidar com fontes de dados
em outros formatos, como pdf, ou diretamente de uma conexão com algum banco de
dados;

 Seguir padrões e boas práticas: é preciso que a ferramenta dê suporte a princípios,

padrões e boas práticas já consolidados na área dos dados abertos;

 Engajamento da comunidade de desenvolvedores: para o crescimento e evolução da

plataforma, é necessária contribuição de outros desenvolvedores.
 39
Referências

[1] CERN. World Wide Web born at CERN 25 years ago. [S. l.], 12 mar. 2014. Disponível em:
https://home.cern/news/news/computing/world-wide-web-born-cern-25-years-ago. Acesso em:
5 mar. 2019.

[2] S. Aghaei, “Evolution of the World Wide Web: From Web 1.0 to Web 4.0”, International
journal of Web Semantic Technology, vol. 3, nº 1, p. 1–10, jan. 2012.

[3] Sharon S. Dawes and Natalie Helbig. 2010. Information Strategies for Open Government:
Challenges and Prospects for Deriving Public Value from Government Transparency. In
Electronic Government, Maria A. Wimmer, Jean-Loup Chappelet, Marijn Janssen, and Hans J.
Scholl (Eds.). Springer Berlin Heidelberg, Berlin, Heidelberg, 50–60.

[4] Patrice McDermott. 2010. Building open government. Government Information Quarterly
27, 4 (2010), 401–413.

[5] BRITO, Kellyton dos Santos; COSTA, Marcos Antônio da Silva; GARCIA, Vinicius
Cardoso; MEIRA, Silvio Romero do Lemos. Brazilian Government Open Data: Implementation,
Challenges, and Potential Opportunities. In: International Digital Government Research
Conference (dg.o 2014), Aguascalientes City, Mexico, June 18-21, 2014. ACM, New York, NY,
USA, 11-16.

[6] BRITO, Kellyton dos Santos; COSTA, Marcos Antônio da Silva; GARCIA, Vinicius
Cardoso; MEIRA, Silvio Romero do Lemos. Experiences Integrating Heterogeneous
Government Open Data Sources to Deliver Services and Promote Transparency in Brazil. In:
The 38th Annual International Computers, Software Applications Conference Special Sessions
2014 Industry Papers (COMPSAC), Västerås, Sweden 21–25 July, 2014.

[7] Open Knowledge International. Open Definition, 2018. Acesso em: 13 mar. 2019.
Disponível em: https://opendefinition.org/od/2.1/en/.

[8] Open Knowledge Foundation. Whats is open?. Acesso em: 13 mar. 2019. Disponível em:
https://okfn.org/opendata/.

[9] W. Parks, “Open Government Principle: Applying the Right to Know Under the
Constitution,” Georg. Wawhingt. Law Rev., vol. 26, no. 1, 1957.
[10] U.S. Government’s open data. Open Data: A History [S. l.], 4 abr. 2013. Disponível em:
https://www.data.gov/blog/open-data-history. Acesso em: 20 mar. 2019.

[11] Paris Innovation Review. A brief history of Open Data [S. l.], 29 mar. 2013. Disponível em:
http://parisinnovationreview.com/articles-en/a-brief-history-of-open-data. Acesso em: 20 mar.
2019.

[12] Martin Beno, Kathrin Figl, Jurgen Umbrich, and Axel Polleres. 2017. Open Data Hopes
and Fears: Determining the Barriers of Open Data. In 2017 Conference for E-Democracy and
Open Government (CeDEM). IEEE. https://doi.org/10.1109/cedem.2017.22
REFERÊNCIAS 40

[13] European Data Portal. 2016. Open Data Goldbook for Data Manager and Data Holders.
Available on line. (2016). https://www.europeandataportal.eu/sites/default/files/goldbook.pdf
Last checked 2018/01/19.

[14] S. Martin, M. Foulonneau, S. Turki, and M. Ihadjadene, “Risk analysis to overcome barriers
to open data,” Electronic Journal of e-Government, vol.11, pp. 348-359, 2013.

[15] A. Zuiderwijk, M. Janssen, S. Choenni, R. Meijer, R. S. Alibaks, and R. Sheikh Alibaks,

“Socio-technical impediments of open data,” Electronic Journal of eGovernment, vol. 10, pp.
156-172, 2012.

[16] European Data Portal. 2016. Open Data Goldbook for Data Manager and Data Holders.
Available on line. https://www.europeandataportal.eu/sites/default/files/goldbook.pdf

[17] European Commission. 2017. Open Data Maturity in Europe 2017. (2017).
https://www.europeandataportal.eu/sites/default/files/edpl andscapingi nsightr eportn 32 017.pd f

[18] Kundra, V. (2009). Data.gov: Pretty Advanced for a One-Year-Old. Retrieved October 01,
2014, from
http://www.whitehouse.gov/blog/2010/05/21/datagov-pretty-advanced-a-one-year-old

[19] BRITO, Kellyton dos Santos; COSTA, Marcos Antônio da Silva; GARCIA, Vinicius
Cardoso; MEIRA, Silvio Romero do Lemos. Experiences Integrating Heterogeneous
Government Open Data Sources to Deliver Services and Promote Transparency in Brazil. In:
The 38th Annual International Computers, Software Applications Conference Special Sessions
2014 Industry Papers (COMPSAC), Västerås, Sweden 21–25 July, 2014.

[20] BURÉGIO, Vanilson André de Arruda; BRITO, Kellyton dos Santos; ROSA, Nelson; DOS
SANTOS NETO, Misael Wanderley; GARCIA, Vinicius Cardoso and MEIRA, Silvio Romero
de Lemos. Towards Government as a Social Machine. In Proceedings of the 24th International
Conference on World Wide Web Companion (WWW ‘15 Companion). International World
Wide Web Conferences Steering Committee, Republic and Canton of Geneva, Switzerland,
1131-1136. doi: 10.1145/2740908.2743976

[21] LÓSCIO, B. F.; GAMA, K. S. . Towards Ecosystems based on Open Data as a Service. In:
16th International Conference on Enterprise Information Systems, 2014, Lisbon. Proceedings of
the 16th International Conference on Enterprise Information Systems, 2014. p. 659.

[22] The Annotated 8 Principles of Open Government Data. Acesso em: 13 mar. 2019.
Disponível em: https://opengovdata.org/.