¿Qué formatos y estándares deberíamos seguir?

[fesja]

Al hacer, por ejemplo, la lista de municipios de España,

¿en qué formatos la dejamos? Json, CSV, XML...

Y, ¿qué estándar deberíamos seguir? Me refiero en cuanto a estructura y naming de los campos. Idealmente deberíamos hacer lo mismo que "los que lo hace bien". Ahora solo falta que los que tenéis más experiencia defináis ese entrecomillado ;)

No pensemos solo en este ejemplo de tipo, si no en cualquiera. ¿Cuál debería ser nuestra referencia?

[jpaulet]

Intentaré poner un poco de luz a "los que lo hace bien" con algunas referencias:

1 - W3C working draft "Publishing Open Government Data" (https://www.w3.org/TR/gov-data/):

Elección del formato adecuado para los datos

Hay muchos diferentes formatos de datos , pero que funcionarán mejor con sus datos ? El formato principal para los datos legible por humanos es ( X ) HTML .

Los datos en bruto es más probable que se produzca usando formatos adaptados a los datos específicos , los instrumentos utilizados , o estándares de la industria . El W3C ha sido pionero en XML y RDF , que permiten una excelente manipulación y juegos de herramientas estandarizadas . archivos XML y RDF se pueda acceder como bases de datos, utilizando SPARQL , XQuery , JavaScript y muchos otros lenguajes de programación . Cuando sea posible , el uso establecido estándares abiertos y herramientas que permiten la producción fácil y eficiente y la publicación de los datos. Consulte la sección referencias para obtener una lista de las herramientas actuales . También hay que tener en cuenta el poder de los datos vinculados .

Otro buen punto de referencia son los 10 principios de datos abiertos para administraciones (http://sunlightfoundation.com/policy/documents/ten-open-data-principles/), ya sé que está muy visto pero siempre es bueno recordarlo:

1. Completos: Todos los datos se pone a disposición del público . Los datos públicos son datos que no está sujeto a limitaciones de privacidad , seguridad o privilegio válidos .
2. Primarios: Los datos se recogieron como en la fuente, con el más alto nivel posible de granularidad , no en formas agregadas o modificadas .
3. Oportunos:Los datos se pone a disposición tan pronto como sea necesario para preservar el valor de los datos.
4. Accesibles: Los datos están disponibles para la gama más amplia de usuarios para la más amplia gama de propósitos.
5. Procesables por maquinas: Los datos se estructura razonablemente para permitir el procesamiento automatizado.
6. No discriminan: Los datos están disponibles para cualquier persona , sin necesidad de registro.
7. No propietarios: Los datos están disponibles en un formato sobre el que ninguna entidad tiene el control exclusivo .
8. Licencias libre: Los datos no está sujeta a ningún derecho de autor , patentes, marcas o regulación secreto comercial . privacidad razonable , se puede permitir restricciones de seguridad y privilegios.
9. Permanentes: Los datos deben estar disponibles a traves del tiempo.
10. Costes de Uso: Los datos deben ser (dentro de lo posible), gratis para todo el mundo.

Con esto, los formatos que son legibles por maquinas son: XLS, CSV, JSON, XML

Si el propósito es cumplir con las 5 estrellas del Linked Open Data , el formato tendria que ser RDF, pero personalmente creo que puede hacer el desarrollo mas lento, por tanto en un inicio, me decantaria por los formatos anteriormente mencionados.

Leyendo de CodeForAmerica (https://www.codeforamerica.org/practices/open/open-data/#publishing) recomiendan:

• Priorización de datos para la liberación (Issue ya creada)
• Seleccione una plataforma de datos abierta (CKAN, Junar...)
• Publicar sus datos (lo que nos atañe)

También es un buen punto de referencia los diferentes niveles de certificación de datos abiertos de la OpenDataInstitute (https://certificates.theodi.org/en/about/badgelevels) que aconsejan diferentes niveles de calidad de datos.

Por último, otra muy buena guia es la del OpenData HandBook: http://opendatahandbook.org/

En resumen, debemos elegir entre: XLS,CSV,JSON,XML y RDF (semántico y linkable pero más complejo).

• XLS lo descartaría (formato "antiguo" y propietario de MS). Se podria usar .ods (formato abierto), pero es un archivo 'difícil' y complejo de generar.
• CSV pueden ser un formato muy útil, ya que es compacto y por lo tanto adecuado para transferir grandes conjuntos de datos con la misma estructura . Sin embargo , el formato es tan 'espartano' que los datos son a menudo inútiles sin documentación ya que puede ser casi imposible de adivinar el significado de las diferentes columnas. Es un formato poco amigable des de el punto de vista humano

Y entre XML y JSON aconsejaría usar JSON ya que existen muchas herramientas para procesar datos a este formato (csv2json, xls2json...) además de ser un formato muy usado y soportado a la hora de crear APIs.

JSON es un formato de archivo simple que es muy fácil para cualquier lenguaje de programación para leer . Su simplicidad significa que por lo general es más fácil para los ordenadores para procesar que otros , cómo XML.

Aquí una guia para JSON: https://project-open-data.cio.gov/v1.1/schema/ (convención de nombres, campos, etc.). Pero el tema de nombre de campos y campos mínimos se tendría que discutir ampliamente.

Otras opiniones?

[amfeli]

Hablando siempre de datos cartográficos (es a lo que me dedico), los formatos se han ido estableciendo por su legibilidad y universalidad. En el caso de datos vectoriales se usa el formato llamado "shapefile" (https://www.esri.com/library/whitepapers/pdfs/shapefile.pdf, ojo que es un formato de una empresa pero no tiene por el momento rival) y en el caso de datos raster bien un ascii raster (http://resources.esri.com/help/9.3/arcgisdesktop/com/gp_toolref/spatial_analyst_tools/esri_ascii_raster_format.htm) bien el geotiff (un tiff con metadatos de georreferenciación, http://landsathandbook.gsfc.nasa.gov/pdfs/geotiff_spec.pdf). Para tablas suele usarse un simple CSV.

[fesja]

@jpaulet brutal respuesta!

Me ha encantado los diferentes niveles de certificación de datos abiertos de la OpenDataInstitute (https://certificates.theodi.org/en/about/badgelevels). Creo que deberíamos ser Gold Platinum. Eso sería marcar el nivel bien alto. Lo veo factible.

Yo apuesto por dejarlos en JSON (usado en programación) y CSV (usado para excels). La guía que has puesto de JSON nos puede servir de ayuda. Cuando nos metamos, fuente por fuente, discutiremos más sobre eso.

@amfeli genial, gracias!

[inigoflores]

Yo voto también por JSON, aunque me someto a lo que digan los expertos como @jpaulet :)

Otro punto a tener en cuenta es la necesidad de estandarizar en la medida de lo posible la codificación de caracteres (p.e. tener todo en UTF-8). Cada fuente trae un encoding diferente, y resulta tedioso tener que andar convirtiendo de uno a otro.

[jalbertoroman]

Para datos geográficos, es bueno tener en cuenta que Github tiene soporte nativo para geojson y topojson: https://help.github.com/articles/mapping-geojson-files-on-github/ Topojson en algunos casos es un 80% más ligero.

[amfeli]

Una pregunta que creo que es esencial en esta discusión ¿qué perfil de usuario sería el destinatario de esta información? Lo digo porque dentro los usuarios de Sistemas de Información Geográfica no usamos los formatos que estais planteando ni los SIG tienen herramientas cómodas (a veces ni siquiera incómodas) para usarlos.

[fesja]

@amfeli daba por hecho que los polígonos deben ir como has dicho, en shapefile. Para la información en tablas JSON y CSV como parece que decimos la mayoría.

Los perfiles de usuarios serán desarrolladores principalmente y luego estadistas y periodistas.

[hllorens]

Podría copiar el comentario de @inigoflores puesto que pienso exáctamente igual. Json y utf-8 (preferiblemente).

Tener además rdf sería ideal pero a veces resulta muy complejo. Una alternativa más flexible parecida a lo que hacen muchos proveedores de datos abiertos mundiales como http://data.worldbank.org/ es tener una API (REST) en la cual cada usuario puede elegir entre unos formatos (rdf, json, csv). Esto es, independientemente de como se guarden en el servidor, luego se ofrecen mecanismos para que el usuario acceda en diferentes formatos. Los usuarios "no-programadores" probablemente prefieran csv para luego usar el excel o similares, mientras que los "programadores" es probable que prefieran el json.

[inigoflores]

Yo no tengo experiencia con RDF, pero llevo tantos años leyendo comentarios negativos sobre el formato, que se me han quitado incluso las ganas de probarlo. Algunos ejemplos:

• https://news.ycombinator.com/item?id=2175161
• https://github.com/mhausenblas/rdfxml.info/blob/master/input/RDF-XML%20sucks%20-%20praise%20and%20damnation.txt

Luego está la opinión de Linus Torvalds sobre XML, que es de todos conocida:

XML is crap. Really. There are no excuses. XML is nasty to parse for humans, and it's a disaster to parse even for computers. There's just no reason for that horrible crap to exist.

[jpaulet]

Cómo en resumen estamos bastante de acuerdo en los formatos de datos a usar: CSV y JSON me he tomado la licencia de crear (más bien traducir y adaptar) varios archivos para la estandarización de algunos conceptos y así poder hacer la colaboración mas fácil. Me he basado en el portal "Data Protocols - Lightweight Standards and Patterns for (Open) Data" que es parte de la "Open Knowledge Foundation" una de las instituciones mas reconocidas a nivel global. Como el formato es: "Licensed under CC Attribution license v3" ( Share — copy and redistribute the material in any medium or format, Adapt — remix, transform, and build upon the material - for any purpose, even commercially. ) creo que no les importará ;) .

Por tanto, tenemos (en inicio) estas recomendaciones a la hora de crear datos en:

• CSV: https://github.com/jpaulet/DatosAbiertos/blob/master/csv.pdf (también estan en .odt y puedo compartirlo en otros formatos)
• JSON: https://github.com/jpaulet/DatosAbiertos/blob/master/json.pdf (también estan en .odt y puedo compartirlo en otros formatos)

Deberemos definir a que otros formatos los transformamos (podemos facilmente tranformarlo en XML, XLS, etc.). Para esto, también es bueno definir que librerias / herramientas podemos usar de forma común. He creado también un listado que puede irse expandiendo o modificando, todas ellas son de codigo libre:

• Herramientas / Librerias: https://github.com/jpaulet/DatosAbiertos/blob/master/herramientas.pdf

Espero que os parezca bien, y esto no son tótems, solo guías sobre como podemos ir funcionando para estandarizar conceptos.

Si hace falta se pueden añadir a algun repositorio con conceptos comunes y definiciones de este proyecto.

Luego, como bien dice @hllorens también se puede tener una API que sirva diferentes formatos de archivos.

En general, un BUEN portal de datos tiene los siguientes servicios:

Catálogo de datos: Para la consulta/descarga.

Punto de acceso SPARQL: Ofrece a los desarrolladores/profesionales una granpotencia y flexibilidad a la hora de construir aplicaciones de calidad. Además de ofrecer datos de gran calidad en formato “Linked Data”.

Catálogo de Aplicaciones. Que han sido desarrolladas reutilizando los conjuntos de datos publicados en formatos abiertos.

API (RestApi): Servicio pensado para desarrolladores que armoniza el acceso y la documentación de los diferentes conjuntos de datos disponibles.

Consulta Ciudadana: Foro que fomenta el diálogo y participación de cualquier parte interesada en los temas relativos.

Opcional: Buscador facetado basado en Apache SOLR que expone los datos en formatos reutilizables (JSON, XML).

Pero debemos ir paso a paso, de momento el catalogo de datos, luego veremos si activamos una API y un endpoint y luego todo lo otro (creo yo).

Vamos que esto se anima!

Links: http://dataprotocols.org

[fesja]

@jpaulet buena iniciativa! Si te parece, podemos meter esta info en el wiki directamente así está todo en el repo. ¿Qué te parece? ¿Lo haces tú o te echo una mano?

Lo ideal es hacer un primer ejemplo con una fuente, y luego que el resto siga ese ejemplo. A ver si definimos las 10 primeras fuentes y nos organizamos! Voy a contestar en el otro hilo.

Por cierto, escríbeme un email y hablamos; o escríbeme por Slack si estás.

[fesja]

Copio conversación en #6

@tinproject

En mi opinión no habría que utilizar Shapefiles, ya que aunque es un estándar de facto, es un formato propietario. En su lugar lo propio sería usar GeoJSON (http://geojson.org) que se renderiza directamente por GitHub y además está en proceso de estandarización por el W3C.

@martgnz

No he dicho que tengamos que usar shapefiles. Pero lamentablemente las administraciones sirven este tipo de ficheros. La idea es crear un makefile que se baje los shapefiles, los convierta con ogr2ogr o similar y tengas un GeoJSON o TopoJSON como resultado. Si no hacemos un proceso reproducible con los datos (como esto) será imposible controlar para el usuario la simplificación o las propiedades del JSON.

pregunta, ¿los geojson se pueden usar en los programas/librerías más comunes? Lo pregunto por desconocimiento y para confirmar que si elegimos ese formato cualquiera los podrá usar :)

Estoy de acuerdo en que el proceso debe ser reproducible, si no, dentro de un año nos vamos a volver locos como no tengamos scripts y sea todo manual.

[martgnz]

Sí, GeoJSON es el formato más común, y se puede usar con Leaflet y similares.

TopoJSON es un derivado que reduce mucho el tamaño del archivo (tanto como pasar de 2mb a 300kb) y se usa mucho con D3.

[fesja]

@amfeli entonces hay un sector cuyos programas necesitan shapefiles y no les vale con geojson?

[amfeli]

Es lo que se usa más con mucha diferencia pero las costumbres se cambian y la mayoría de los SIG usan GDAL, no veo que usar GeoJSON sea un problema.