Escolha da ferramenta de edição de planilha

[ppKrauss]

Como a edição direta de CSV no Github não é legível para humanos, o ideal é que se faça

1. Realizar validação automática, tal como https://goodtables.io , nos arquivos que requerem input humano direto
2. Ideal que seja através de um editor Web padronizado (ex. google), evitando-se o uso de ferramentas Desktop mal configuradas que adulteram o arquivo.
3. criar um guia geral de gestão das planilhas de edição direta
4. Automatizar o processo de captura dos dados do editor online, por exemplo no makefile
   wget "https://docs.google.com/spreadsheets/d/1CL6f0I9DSpqKxKC7QNJGCfyabq7mDOVab5QBGV5VLOk/gviz/tq?tqx=out:csv&sheet={de-para}" -O "$(pg_io)/de-para.csv"

Planilhas candidatas: todas da raiz preserv/data, planilhas de donor e donatedPack a cada país.

---

Ver também frictionless-py/issues/959 e comando csvformat do csvkit... Por hora a melhor solução.

[crebollobr]

https://comma-chameleon.io/

[ppKrauss]

https://comma-chameleon.io/

Assim como Octopub, o Comma Chameleon é um experimento ODI, do Open Data Institute... E o tanto o frictionless-py como GoodTables, do FrictionlessData, foram experimentos da OKF - Open Knowledge Foundation.. Mas OKF e ODI são muito parecidas, porque estão "competindo" a este nível? Precisamos entender e resolver qual apoioar.

Por outro lado o CSV kit é simplesmente uma boa ferramenta, bastante utilizada e bem mantida por uma comunidade aberta de programadores, que ambos, OKF e ODI poderiam estar apoiando! Precisamos começar a entender como tudo isso functiona e, depois de alguma curadoria e descarte dos lixos, decidir quais ferramentas (ou organizações) apoiar.

PS: quanto aos padrões e seus mantenedores, há ainda, historicamente, uma certa competição entre FrictionlessData/Tabular e o W3C tabular data standard... Na prática o pessoal do W3C deu uma banana para a OKF, não buscando alinhamento com quem usa no dia-a-dia os dados abertos, e impactando investimentos e união de esforços até hoje.

[fititnt]

Automatizar o processo de captura dos dados do editor online, por exemplo no makefile (... exemplo do Google Sheets...)

Tenho feito isso para tal tipo de planilha. O 1603_1_1 (https://docs.google.com/spreadsheets/d/1ih3ouvx_n8W5ntNcYBqoyZ2NRMdaA0LRg5F9mGriZm4/edit#gid=2095477004) que é usado no https://github.com/EticaAI/multilingual-lexicography (mas que começou no https://github.com/HXL-CPLP/Auxilium-Humanitarium-API) é editado online e ferramentas fazem o resto.

Não é preciso estar autenticado para baixar planilhas uma por uma. Porém se for fazer muitas ao mesmo tempo, o ideal é baixar o XLSX e extrair com in2csv do CSVKit)

Sobre padrões de dados

Olha, tenho usado todo tipo de ferramenta (no nosso caso as plalinhas são HXL, então tem o as CLI do padrão HXL, que inclusive trabalham com fontes remotas sem precisar baixar) mas se você quer apenas guardar os dados, se fizer isso aqui, vai funcionar com quase tudo:

1. Um cabeçalho simples (não precisa ser HXL)
2. Cada cabecalho deve, sem repetições (HXL e CSVWeb até toleram repetição, mas outras ferramentas não)
3. Não use quebras de linha no GSheets; se precisar digite manualmente \n (vai dar menos dor de cabeça; GSheet vai exportar okay, mas ferramentas que você usa vão ter um dia ruim)
4. Faça os makefile testarem se humanos fizeram erros (o CSVKit consegue validar se CSV é valido, e isso é uma rechagem rapida, mas o frictionless validate data.csv encontrará mais erros humanos)

Posso estar esquecendo mais alguma coisa, porém com essas regras, meio que o seu CSV vai poder ser "documentado" por quase qualquer outra coisa.