Modificar import_data para utilizar datapackage + metadados

[turicas]

Pré-requisitos: #78, #82 e #83 (#84 é desejável, mas pode ser feito em paralelo).

Com o objetivo de ter todos os metadados autocontidos nos repositórios dos scripts que geram datasets e parar de usar essa planilha precisaremos modificar o comando import_data (e possivelmente outras partes do backend) para utilizar os metadados vindos do datapackage e dos metadados que serão definidos em #83. Como o datapackage descreve todas as tabelas de um dataset, essa modificação implicará importar todo o dataset de uma vez só (por padrão), ou opcionalmente especificar somente a tabela de interesse.

Pendente: descrever tarefas.

[turicas]

Comentários de @ppkraus em chat.brasil.io:

1. Se um repositório git vira referência de "dataset em produção", esse git precisa ter release (versionamento) para não deixar os usuários na mão ou discussões sem sentido. Ver exemplo deste caso que tem diversos usuários externos, https://github.com/datasets/country-codes/issues/67

2. Adotar também no Brasil.IO e no datasets.ok.org.br da OKBR o uso das releases, mesmo para o que ainda estiver em teste (versões 0.x.y)... idealmente [SemVer2 adaptada para dados](https://semver.org/spec/v2.0.0.html)

3. Adotar nos datasets de produção as convenções de [tabular-data-package](https://frictionlessdata.io/specs/tabular-data-package/) que hoje já apresenta ferramentas amigáveis para compor datapackage.json (ex: http://create.frictionlessdata.io)

4. Adotar como ferramenta de controle de qualidade o [Goodtables](https://github.com/frictionlessdata/goodtables-py). Ela pluga no Github e tem seu CLI para testar em casa antes do pull-request

5. Regra de ouro do Brasil.IO: README com seção ou link para o "Preparo do dataset", mostrando a receita de composição do dataset a partir das fontes primárias de dados. Essa receita precisa ser reprodutível, o README precisa ser completo suficiente para um cara conhecedor como o Turicas reproduzir a receita (sem precisar pedir ajuda pro criador do dataset).

6. Que tal, buscar consenso em mais algumas regrinhas de "boas práticas"? 
Entre elas adotar um repositório coletivo (impessoal) que pode ser o http://dataset.OK.org.BR da OKBR
O subdominio justamente já teve configuração de redirecionamentos (para o impessoal https://github.com/datasets-br ) atualizada pelo Cuducos ... Por exemplo http://datasets.ok.org.br/state-codes e seus arquivos também redirecionam. 
Alem do nome bonitinho, ninguém fica refém da Microsoft-Github: se fizerem a divulgação dos datasets pelo datasets.ok.org.br, amanhã podem migrar sem traumas para outro como o GitLab.
Quero passar a bola para quem desejar assumir como responsável (do datasets.ok.org.br), garantindo integração com o Brasil-IO no nivel admin.

[ppKrauss]

Obrigado @turicas (!) por trazer os comentários do chat (se tirar o espaço eles viram markdown).
Dando então continuidade com algumas perguntas e uma breve apresentação de proposta agora que reparei que já estão na linha do Frictionlessdata...

Quanto ao seu comentário acima sobre import_data, o que seria esse comando?

Podemos trabalhar com o cenário de uma importação direta para o PostgreSQL e normalização/validação e adaptação final usando stored procedures?

---

Tenho usado geradores automáticos de CREATE FOREIGN TABLE ...SERVER files OPTIONS (...) que é a melhor forma de fazer SELECT sobre um arquivo CSV externo de Big Data (rápido e super confiável), pois em geral a tabela definitiva é um resultado de filtragem, de modo a fazer isso no PostgreSQL como se fosse um stream de dados, ao invés de comando COPY.
Se são vários pacotes parecidos, como no eleicoes-brasil (TSE) basta ir fazendo alter table da option filename.
PS: como os CSV são arquivos temporários em geral faço (por ex. make geral de todos os datasets) a carga CSV por git clone ou wget na pasta /tmp do Linux, onde o server psql lê por default.

Tenho também usado uma modelagem (de esquema e tabelas definitivas no SQL) que permite justamente aproveitar os dados do Datapackage Frictionlessdata em uma tabela de descrição detalhada dos datasets, copiando integralmente os dados JSON para um campo JSONb. Isso dá uma grande flexibilidade depois para conferir a semântica dos dados, fazer front-end, com títulos das colunas, etc.
A preservação opcional dos dados originais CSV, um "dump" no SQL, em JSONb, também é possível e bem econômica... Mas no Brasil.io me parece que o foco são as consultas online e os JOINS, de modo que seria desperdício, basta a tabela SQL convencional, pelo menos nas chaves primárias e campos com previsão de indexação (tabelas longas ou com "campos meio inúteis" podem usar um JSONb com todos os demais campos).

O rascunho e recursos de prova de conceito estão em https://github.com/datasets-br/sql-unifier