Organizar esse repositório como um Data Package

[vitorbaptista]

Um data package é um formato simples para descrever um conjunto de dados, especificando (por exemplo) o que cada coluna significa, o conteúdo do CSV, etc., de forma legível por máquina.

A organização https://github.com/datasets aqui do GitHub reúne diversos Data Packages, por exemplo o https://github.com/datasets/gdp. No arquivo https://github.com/datasets/gdp/blob/master/datapackage.json conseguimos ver qual a licença dos dados, data de última atualização, fontes e a descrição do CSV.

Caso seja interessante, posso enviar um pull request com essa mudança :+1:

[ppKrauss]

@vitorbaptista, ótima sugestão (já acrescentei meu voto!).

---

A dúvida/discussão a seguir é em parte até pessoal, mas vale para o presente contexto.

Sou usuário e colaborador dos OKFN-datasets aqui do Github, e uso o formato tabular-data-package em outros projetos... Recentemente (final de 2015), todavia, a W3C lançou a sua recomendação para tabular-data-model: não são lá muito compatíveis, e, como o padrão W3C ainda é novo, fica a dúvida sobre até quando o já consolidado tabular-data-package seria válido como padrão de fato.

[augusto-herrmann]

Boa ideia, @vitorbaptista. Um pull request seria ótimo!

Já que você mencionou colocar descrições nas colunas, entendo que a proposta é criar um Tabular Data Package, e não apenas um Data Package.

Também gostaria de saber um pouco sobre qual seria o processo ideal para se criar o Tabular Data Package. Seria criar o JSON Table Schema "na unha" e depois validá-lo com ferramentas como o jsontableschema-py e Good Tables?

@ppKrauss, quanto à questão dos padrões Data Packages versus os produtos grupo CSV on the Web do W3C, é uma discussão bastante interessante, mas sugiro continuá-la no tópico destinado para esse assunto no fórum da OKI.

[ppKrauss]

Oi gente, uma rápida olhada no CSV, Título,URL,Município,UF,Esfera,Poder,Solução, mostra que, num primeiro momento, antes de se sugerir adendos de informação, o datapackage.json (na raiz) seguiria o modelão básico, algo como:

{
  "title": "Catálogos de dados abertos no Brasil",
  "name": "catalogos-dados-brasil",
  "description": "Um mapeamento de iniciativas (e catálogos) de dados abertos governamentais no Brasil.",
  "licenses": [
    {
      "url": "http://www.opendefinition.org/licenses/odc-pddl",
      "title": "Open Data Commons Public Domain Dedication and Licence 1.0",
      "id": "ODC-PDDL-1.0"
    }
  ],
  "resources": [
    {
      "name": "catalogos.csv",
      "path": "dados/catalogos.csv",
      "mediatype": "text/csv",
      "schema": {
        "fields": [
          {
            "name": "Título",
            "type": "string",
            "description": "Título do catálogo"
          },
          {
            "name": "URL",
            "type": "string",
            "description": "URL do catálogo"
          },
          {
            "name": "Município",
            "type": "string",
            "description": "Nome IBGE quando a esfera se aplica"
          },
          {
            "name": "UF",
            "type": "string",
            "description": "Sigla IBGE-2-letras da Unidade da Federação, quando a esfera se aplica"
          },
          {
            "name": "Esfera",
            "type": "string",
            "description": "Municipal, Estadual ou Federal"
          },
          {
            "name": "Poder",
            "type": "string",
            "description": "Executivo, Legislativo ou Judiciario"
          },
          {
            "name": "Solução",
            "type": "string",
            "description": "Sigla do sistema ou autoridade na qual o catálogo se insere como solução"
          }
        ]
   }
}

Acho que não cabe sources pois é justamente uma listagem de fontes catalográficas. Quanto à "Esfera", um catálogo do FEHIDRO poderia ser ambíguo, pois sua jurisdição/autoridade é com relação à bacia hidrográfica. O campo "Solução" pede talvez mais um CSV para descrever soluções menos conhecidas.

---

@augusto-herrmann , ótimo link (!), vou tentar acompanhar e eventualmente postar algo. O próprio Rufus, que participou do processo no W3C, e outros da discussão, reconhecem que foi uma lástima o W3C não ter preservado algumas das metas de simplicidade do padrão OKFN... A OKFN pelo visto vai manter tabular-data-package, acho que não há risco de abandonarem. O padrão W3C, por outro lado, já percebido como "muito complexo" nesta (citada) e em outras discussões, não vi sendo usado na prática, corre risco de não receber maior aderência tão cedo.

O que percebo em termos de Brasil é que, tanto da parte do governo — entidades que buscam publicar dados através de padrões abertos, e idealmente o ePING —, como das comunidades de dados abertos, terão que assumir suas próprias decisões, independente de posicionamentos OKFN ou W3C... Ao menos por hora, em 2016, enquanto as tendências globais não são nítidas.

Como o padrão OKFN é extensível (ex. fields pode ter mais atributos), alguns campos do padrão W3C podem ser resgatados. Por exemplo chave primária tem uma definição bem clara no W3C, poderíamos adotar (entendo que seria o campo "URL").

PS: não encontrei iniciativas de conversão ou assistência no "from OKFN-tabular-data-package to W3C-tabular-data-model", vale ir acompanhando isso também em paralelo.

[augusto-herrmann]

@ppKrauss, obrigado pelo primeiro rascunho do JSON table schema! Percebi um erro no atributo path, que faz referência a um arquivo inexistente, mas isso é simples de corrigir. Seria bom validá-lo com as ferramentas que mencionei anteriormente.

Quanto ao campo Solução, acho que faria sentido, sim, a sua sugestão de referenciar um outro CSV. O valor "interna", contudo, é especial pois significa uma solução desenvolvida especialmente para o portal em questão e que não necessariamente é compartilhada com nenhuma outra iniciativa.

---

Quanto ao padrão do W3C, me surpreendi pelo fato de já ter chegado ao status de recomendação, pois pelas regras do próprio W3C isso normalmente exige que se observem várias implementações independentes do padrão. Você comentou não ter visto ele ter sido usado na prática, e eu também ainda não vi, mas talvez nós estejamos apenas desinformados. De qualquer forma, concordo que o padrão do Data Procotols (OKI) é bem mais simples. Outra vantagem é que ele não depende de conectividade para validar os CSVs, o que não se pode dizer do padrão do W3C.

[ppKrauss]

@augusto-herrmann , bem percebido, corrigi o path no meu post anterior. Para validar é simples, passo-a-passo:

1. criar arquivo datapackage.json na raiz aqui do seu git
2. navegar pelo "RAW" para obter a URL.. p. ex. exemplo essa
3. copiar/colar a URL no validador, http://data.okfn.org/tools/validate ... se passar, ver também http://data.okfn.org/tools/view para conferir coerência.

---

Quanto à discussão do padrão do W3C, postei algo, sugerindo no final que esbocemos um subconjunto "SIMPLE-tabular-data-model" para não complicar a vida e resgatar aderência. Ganhei dois likes por hora, acho que não passaremos vergonha se discutirmos por lá ;-)

Também me surpreendo com a rapidez, quando lembro que CSS3-page já tem quase uma década de espera... Mas me parece diferente na demanda por "observar várias implementações independentes", pois o padrão não requer software tão especializado — qualquer linguagem (C, Python, etc.) com parsers nativos ou frameworks maduros para JSON, JSON-LD e CSV, a priori já implementaria o padrão.

A ausência de uma Adobe barrando, e, o contrário, uma Google puxando, ajuda bastante. Apesar de ser um padrão de data-interchange, há ênfase em Web Semântica, que hoje é uma prioridade do W3C. Essa pegada semântica não foi por acaso, como notamos pela escolha da editora da norma (Jeni Tennison) e pelo chair do grupo (Dan Brickley é um dos coordenadores do Schema.org).

[augusto-herrmann]

Foi colocado também no README.md o badge de validação com o Goodtables.io.

[augusto-herrmann]

Obrigado a todos pelas contribuições e sugestões!