"A simplicidade é o último grau de sofisticação." Leonardo da Vinci
Antes de mergulhar nas ferramentas e metodologias mais aclamadas para a publicação de dados abertos, é importante voltarmos aos objetivos desse modelo de publicação: por que publicar dados abertos?
Publicar dados abertos é, antes de tudo, um esforço para tornar os dados mais fáceis de se utilizar e cruzar, de forma a tornar possível o uso por desenvolvedores. Nós não sabemos quem vai utilizar, nem sabemos com quais outros dados os nossos serão cruzados; daí a exigência de que os tornemos simples e bem documentados.
Nessa parte do curso o aluno será orientado a buscar a simplicidade para agilizar a publicação de dados e conhecer ferramentas que facilitam esse trabalho.
Dentre as formas de se publicar dados abertos, a que consideramos mais simples é utilizar formatos de planilha. Abaixo, segue lista de formatos abertos para esta finalidade (exeção para xls e xlsx, que são fechados):
Como estamos falando de dados abertos, aconselhamos enfaticamente a publicação desses dados em formatos abertos (formatos que não impõem restrição tecnológica - mais informações). Para exemplificar uma restrição tecnológica, pode-se imaginar uma situação em que um usuário do Corel Draw, por exemplo, (programa de criação/edição gráfica de imagens baseadas em vetores) tenta abrir um arquivo criado por esse programa, de extensão de arquivo do tipo "CDR", em um outro programa de vetores que não reconhece o formato Corel Draw.
Por fim, se queremos publicar dados em formatos simples e tamanhos pequenos, façamos como o http://datos.gub.uy/ : csv compactado!
Como é de conhecimento de todos, o canal mais democrático e de maior permeabilidade da atualidade é a web! É na web que qualquer pessoa do mundo pode ter acesso aos dados que disponibilizamos com qualquer navegador.
Considerando que queremos facilitar o trabalho dos nossos consumidores e que para isso selecionamos a web, é fundamental seguir a sua arquitetura e algumas considerações do seu criador (Sir Tim Berners Lee) e de pesquisadores como Roy Fielding, que defendem sua utilização de forma simples e direta, ou seja:
- Disponibilizar arquivos em uma URL fixa, para que qualquer pessoa possa encontrá-los e compartilhá-los com terceiros;
- Não utilizar abstrações adicionais de outros protocolos, de modo a permitir que qualquer aplicação possa chegar ao arquivo sem maiores complicações.
Atualmente qualquer web service que siga o estilo arquitetural REST ou ferramenta pronta de catalogação permite que se compartilhe dados em URLs que apontem diretamente para o dado.
Por último, pode ser vantajoso padronizar URLs de acesso aos arquivos de dados, uma vez que essa abordagem facilita o trabalho de crawlers, desenvolvedores, de mecanismos de busca e de muitas outras pessoas, quando procuram nossos dados.
Um grande exemplo de organização da informação nas URLs é o caso do governo do Reino Unido:
- Página inicial do governo eletrônico do Reio Unido: https://www.gov.uk/
- Página inicial para serviços de direção, transporte e viagens: https://www.gov.uk/browse/driving
- Página inicial para serviços de trabalho e pensão: https://www.gov.uk/browse/working
- Página inicial da parceria Reino Unido e Brasil: https://www.gov.uk/government/world/brazil
Esse exemplo não demonstra a organização nas URLs de conjuntos de dados, mas mostra que nas páginas do governo britânico existe na nomenclatura das páginas de serviços, uma padronização. Ainda mostra, além dessa padronização, a tentativa de agregar significado às URLs, para que elas sejam intuitivas para quem for utilizar.
Para facilitar o processo de busca dos dados publicados em formatos abertos, utilizamos catálogos de dados abertos.
A única descrição encontrada sobre o que é um catálogo de dados está aqui: http://www.w3.org/TR/vocab-dcat/#class-catalog
"A data catalog is a curated collection of metadata about datasets." W3C
Considerando que essa foi a única definição encontrada, vamos criar a nossa:
Um catálogo de dados abertos é um mecanismo, ferramenta ou serviço que faz a gestão e publicação na web de dados abertos e seus metadados, ou ainda somente esses metadados (em casos nos quais os dados estão hospedados em outro lugar).
A funcionalidade básica de um catálogo de dados é então permitir: a busca, inclusão, alteração e exclusão desses metadados. As soluções de catálogo mais conhecidas, no entanto, têm incorporado cada vez mais funcionalidades:
- Integração com sistemas de gestão de conteúdo (CMS como wordpress, joomla, drupal, plone, etc.) ou ter seus próprios sistemas de gestão de conteúdo
- Possibilidade de visualização dos dados catalogados
- Controle de acesso a partes dos conjuntos de dados disponibilizados (acesso)
- Controle de acesso descentralizado para inclusão e edição de metadados, permitindo delegação por organizações e usuários
- Hospedagem de arquivos
- Transformação de arquivos
- APIs de acesso automatizado
- Harvesting de metadados e federação de catálogos
- Socrata (Socrata)
- Junar Open Data Platform (Junar)
- CKAN (Open Knowledge Foundation)
Observações:
- Essas são as soluções de mercado de maior destaque atualmente. Na verdade, devo esclarecer que são as únicas que conheço. Caso haja alguma outra que seja importante e eu não tenha colocado, por favor me avise!
- Não tive a oportunidade de testar as soluções Socrata e Junar como publicador, só como usuário.
- Sotware como serviço
- API para acesso automático
- Pré visualização de dados tabulares
- Construção de visualizações mais elaboradas (formatação condicional, gráficos e mapas)
- Kenya
- Programa de Desenvolvimento das Nações Unidas https://data.undp.org/
- Banco Mundial
- Estados Unidos (até 2013)
- Dezenas de cidades e estados nos Estados Unidos e no Mundo
- Software como serviço
- API para acesso automático
- Pré visualização de dados tabulares
- Visualização de dashboards pré elaborados
- Sotware Open Source - https://github.com/okfn/ckan
- Software como serviço
- API para acesso automático
- Pré visualização de dados tabulares
- Construção de visualizações (gráficos e mapas)
- Busca de datasets geolocalizada
- Reino Unido
- Estados Unidos
- Alemanha
- public.data.eu
- Brasil
- Dezenas de países, estados e cidades no mundo
O que é uma API ?
API quer dizer Application Programming Interface (Interface de Programação de Aplicação).
"Generally speaking, an application programming interface specifies how some software components should interact with each other." Wikipedia
Ou seja, é um componente de interoperabilidade. Na prática uma API é uma biblioteca, em alguma linguagem de programação, que encapsula ou abstrai a uma rotina, interagimos com a API enviando a ela a operação que queremos fazer.
O que chamamos de APIs quando falamos de dados abertos, na verdade, são Web APIs. As web APIs funcionam sobre a mesma filosofia: é declarado um conjunto de operações que a API realiza e o desenvolvedor a chama utilizando HTTP, ou SOAP, mas recomendamos nos ater ao HTTP pela simplicidade que isso traz aos desenvolvedores.
Embora uma API seja uma maneira mais rica de publicar dados, recomendamos também considerar algumas questões antes de entrar de cabeça nessa moda ou durante seu processo de adoção.
Você realmente precisa de uma API ?
- Você quer disponibilizar uma planilha ou uma base inteira ?
- Qual o tamanho da base ? Não seria mais fácil convertê-la para um grande arquivo ?
- Você pode arcar com os custos de manutenção de uma API?
- Sua infraestrutura aguentaria um grande aumento de carga ?
Isole a base de produção da base aberta Essa afirmação pode parecer óbvia, mas nunca é demais lembrar coisas importantes. A parte de segurança não é tão arriscada, o principal problema é a concorrência das buscas com as atividades normais do sistema que está em produção.
Lembre-se das URLs API boa é RESTful, é API padronizada, criar uma API que não siga as melhores práticas na web pode ser uma dor de cabeça para você e não atender as necessidades dos desenvolvedores.
Infelizmente não existem maneiras fáceis e nem tempo hábil para colocar isso dentro de uma postagem. O que pode e vai fazer muito mais diferença é incluir aqui agumas coisas que devem ser levadas em consideração ao se desenvolver (ou terceirzar o desenvolvimento de) uma API:
Além disso, estamos pesquisando no Brasil, soluções de software livre que transformem bases em APIs com um conjunto de definições, já encontramos (e desenvolvemos) algumas, mas ainda não encontramos nenhuma com interface gráfica e de fácil configuração.
Como já falamos de catálogos de dados e de APIs, trazemos essa novidade interessante: a Open Knowledge Foundation iniciou o desenvolvimento de um "Protocolo de Interoperabilidade para catálogo de dados":
Data Catalog Interoperability Protocol
O protocolo propõe:
- A definição de representações comuns em JSON e RDF para entidades centrais de catálogos de dados; e
- Um protocolo somente de leitura para realizar a interoperabilidade básica entre catálogos;
Dessa forma, um catálogo central mundial poderia reunir todos datasets dos catálogos que seguissem esses padrões !
Há vários meios por onde entrar em contato com pessoas interessadas em dados abertos, ficar por dentro do que está acontecendo e aprender mais sobre o assunto.
Para os que dominam o idioma inglês, sugerimos a utilizar o sistema de perguntas e respostas da "Escola de Dados" ou "School of Data" da Open Knowledge Foundation: http://ask.schoolofdata.org/, uma iniciativa nova onde já podem ser encontradas muitas perguntas relevantes sobre dados abertos, dados e assuntos correlatos. A Fundação também possui listas de discussão relacionadas à escola de dados e a dados governamentais abertos.
Em idioma português, temos no Brasil a lista do GT de Dados Abertos do W3C e as listas de discussão da INDA, que são 5 listas. Uma para assuntos gerais e quatro assuntos específicos. Há ainda a lista de discussões da Open Knowledge Foundation no Brasil.
Em espanhol, a OKF mantém uma lista sobre dados abertos para a América Latina e também listas focadas nos seguintes países: Argentina, Equador, Uruguai e México.
Todo o conteúdo deste repositório e deste curso está disponível sobre licença Creative Commons Atribuição (by)
