No estado de Minas Gerais lançamos recentemente uma nova versão do nosso Portal de Dados Abertos e estamos com a proposta de adotar as especificações do projeto Frictionless Data para documentação dos nossos conjuntos de dados.
Para além dos benefícios mencionados pelo @vitorbaptista na aula, um dos grandes benefícios que esperamos em utilizar um padrão de documentação legível por máquina armazenado em texto simples é a possibilidade de versionamento das próprias documentações em um Git público (eg. Conjunto de dados no CKAN vs Github).
A lógica é que o repositório representaria a versão canônica da documentação para fins de gerenciamento da mesma que seria espelhada no CKAN para consumo do público em geral.
Além do valor em si do histórico de versões, acreditamos que a produção de forma pública pode combater a tendência da documentação de ficar obsoleta e ainda prover, “de graça”, um canal próprio para feedback e colaboração com o público especializado.
Ainda não começamos o trabalho de divulgação desse padrão para os órgãos e entidades tendo em vista que não conseguimos finalizar a concepção e o desenvolvimento de um processo automatizado de replicação, como um conjunto de dados no CKAN, de um Git público que armazena um data package válido (ie. datapackage.json).
Seria interessante ouvir a opinião dos colegas e do @vitorbaptista sobre essa estratégia do ponto de vista macro bem como indicação de experiências similares/projetos/ferramentas que possam servir de inspiração para desenvolvimento do fluxo de replicação.
A extensão do CKAN ckanext-datapackager parece ser uma opção para a criação inicial de um conjunto de dados no CKAN a partir de um data package.
Essa discussão proveniente desse issue descreve de maneira muito próxima o fluxo que estávamos considerando. A única coisa que senti falta nos casos de uso foi uma “carga incremental” que fizesse a criação/alteração/exclusão de recursos e metadados de tal forma que o conjunto de dados fosse alterado para representar o estado atual do data package sem necessidade do usuário publicador realizar essas alterações manualmente.
Bom dia, @fjuniorr. No fluxo que você está pensando os conjuntos de dados seriam criados/atualizados no GitHub e essas modificações replicadas no CKAN? Nesse caso, os publicadores trabalhariam somente no GitHub?
Eu gosto da ideia, mas depende de uma equipe de publicadores técnica o suficiente para criar e atualizar os datapackage.json. Você poderia usar esse fluxo GitHub → CKAN só para alguns conjuntos de dados, para que publicadores com menos conhecimento técnico possam criá-los ou atualizá-los.
No GitHub, o fluxo seria:
- Atualiza ou adiciona um
datapackage.json em um repositório (e.x. “dados-abertos-mg”)
- Um processo iria ler esse
datapackage.json e decidir se ele já existe ou não no CKAN
2.1 Caso já exista, ele precisaria sobrescrever o conjunto de dados no CKAN com os dados do datapackage
2.2. Caso não exista, ele iria criar um novo conjunto de dados e potencialmente atualizar o datapackage.json com a URL para os dados no CKAN
É isso que você imaginou?
Imagino ser possível fazer um ETL para automatizar esse processo usando o Data Package Pipelines. Você deve conseguir usar o datapackage-pipelines-github para extrair os datapackage.json do repositório no GitHub e salvá-lo no CKAN usando o datapackage-pipelines-ckan. Nessa arquitetura, você ainda consegue adicionar validação com o datapackage-pipelines-goodtables. Recomendo fazer alguns testes para confirmar que esses pacotes ainda funcionam, visto que alguns não são atualizados há alguns anos.
Se não funcionar com o datapackage pipelines, você vai precisar escrever código. O ckanext-datapackager é próximo do que você precisa, mas ele não suporta sobrescrever um conjunto de dados já existente. Ele só permite criar um conjunto de dados novo, ou baixar um existente como data package. Precisaria existir uma função para sobrescrever um conjunto de dados na pasta ./ckanext/datapackager/logic/action. Ela provavelmente será bem parecida com a package_create_from_data_package() que está no create.py naquela pasta.
O aplicativo de linha de comando do CKAN também pode te ajudar nessa integração, ao facilitar o acesso à API do CKAN.
Resumindo, acho um fluxo interessante, com o porém de exigir uma equipe de publicadores técnica e um programador para implementá-la, caso queira automatizar o fluxo GitHub → CKAN. Caso não, também é possível usar o GitHub só para o desenvolvimento dos data packages, fazendo a atualização pro CKAN manualmente.
1 Like