Una de las organizaciones incluidas en el PAD había nomenclado sus archivos utilizando espacios, ej: "base_estadistica 2015.csv". Lo cual terminaba reflejandose en un URL de descarga que incluía espacios, inválida para la herramienta pydatajson. En nuestra Guía recomendamos no incluir espacios en la nomenclatura de los archivos, pero en base a este caso concreto se estudiaron los estándares aplicables a las URL.
Por lo anterior, entiendo que deberíamos agregar en la sección " nomenclatura de archivos" (como nota al pie o incluida en el texto) la referencia a las especificaciones técnicas. Pudiendo utilizar la totalidad o parte del texto de @capitantoto :

RFC 1738 (1994):
https://www.ietf.org/rfc/rfc1738.txt
Unsafe:
Characters can be unsafe for a number of reasons. The space character is unsafe because significant spaces may disappear and insignificant spaces may be introduced when URLs are transcribed or
typeset or subjected to the treatment of word-processing programs.
The characters "<" and ">" are unsafe because they are used as the delimiters around URLs in free text; the quote mark (""") is used to delimit URLs in some systems. The character "#" is unsafe and should
always be encoded because it is used in World Wide Web and in other systems to delimit a URL from a fragment/anchor identifier that might follow it. The character "%" is unsafe because it is used for
encodings of other characters. Other characters are unsafe because gateways and other transport agents are known to sometimes modify such characters. These characters are "{", "}", "|", "", "^", "~", "[", "]", and "`". All unsafe characters must always be encoded within a URL. For example, the character "#" must be encoded within URLs even in systems that do not normally deal with fragment or anchor identifiers, so that if the URL is copied into another system that does use them, it will not be necessary to change the URL encoding.

RFC 3986 (2005)
Definitivamente los espacios en blanco no son parte de una URL válida. No figuran en la notación regular del Apéndice A, y se sugiere eliminarlos de todo input de usuarios:
http://www.ietf.org/rfc/rfc3986.txt
In practice, URIs are delimited in a variety of ways, but usually within double-quotes
http://example.com/", angle brackets http://example.com/, or just by using whitespace. These wrappers do not form part of the URI.
[...]
In some cases, extra whitespace (spaces, line-breaks, tabs, etc.) may have to be added to break a long URI across lines. The whitespace should be ignored when the URI is extracted.
[...]
For robustness, software that accepts user-typed URI should attempt to recognize and strip both delimiters and embedded whitespace.

A partir de algunas consultas y análisis de casos concretos que están surgiendo en los Planes de Apertura de diversas organizaciones que comenzaron a publicar datos geográficos, y ya que la versión 0.1 de nuestras recomendaciones no incorpora este tema, me parece que deberíamos comenzar a discutirlo.

Propongo tratar las siguientes preguntas para empezar a debatir el tema:
¿Qué formatos de archivo son los más utilizados para publicar datos geográficos? ¿Cuáles son sus ventajas y desventajas? ¿Cuál es el más recomendable? ¿Podemos establecer una escala, del más recomendado al menos?

Los formatos más difundidos sobre los que debatir, entiendo que son:

• Shapefile.
• KML.
• GeoJSON
• GML (Geography Markup Language)
• GeoPackage

En mi opinión lo ideal sería llegar a una tabla organizada a partir de los siguientes variables: Formato; Breve descripción; Nivel de apertura; Nivel de recomendación.
Espero sus contribuciones!

Actualmente los ejemplos que ponemos para nomenclatura de archivos para el caso de datos que se dividen en varias distribuciones separando por provincia (por ejemplo) promueven la creación de archivos nombrados sin ningún estándar:

acceso-informacion-publica-caba.csv
acceso-informacion-publica-jujuy-20130208.csv

Esto puede tener los siguientes problemas:

• Los nombres de los archivos podrían cambiar, si los criterios del área para estos "nombres cortos" de provincias cambian. No tendríamos una URI muy estable de esta forma.
• Las distribuciones divididas por provincia no se nombrarían homogéneamente entre distintos datasets, catálogos u organismos del estado (algunos van a poner caba y otros ciudad-de-buenos-aires, buenos-aires o ciudad-autonoma-buenos-aires)
• Es más difícil programar una rutina desatendida sobre un nombre desestandarizado que puede tener varias palabras (ciudad-autonoma-buenos-aires) que sobre alguna convención que tenga una sola palabra (ej.: si usáramos los códigos de INDEC de provincias tendríamos acceso-informacion-publica-02.csv, acceso-informacion-publica-06.csv, acceso-informacion-publica-94.csv, etc)

Posibles soluciones:

• Recomendar la adopción de los códigos de la cartografía censal de INDEC para estos casos (similar al tratamiento de una entidad interoperable )

acceso-informacion-publica-02.csv
acceso-informacion-publica-06.csv
acceso-informacion-publica-94.csv

• Definir "nombres cortos" para provincias (y tal vez departamentos?) que se recomienden siempre para nombrar archivos.

acceso-informacion-publica-caba.csv
acceso-informacion-publica-pba.csv
acceso-informacion-publica-tierrafuego.csv  # difícil este caso...

Agregar la documentación y el modelo de excel a la sección de otros catalogos

Como diferenciamos datos de informes? que tipo de recomendación deberíamos realizar desde las guías. En caso de que se decida publicarlos en el portal de datos, como los identificamos automáticamente?

https://datosgobar.github.io/paquete-apertura-datos/guia-interoperables/#direcciones-y-lugares

• Agregar aquellos campos individuales que hacen a una dirección completa, caso de que falten.
• Agregar los ejemplos de los distintos casos de direcciones, cuál es su forma canónica de escribirlos y cuándo corresponde usar cada una.
• Agregar una referencia al endpoint de georef para normalizar direcciones con un ejemplo de uso del endpoint y un link a la sección relevante de la documentación de la API.

Hoy la guía de metadatos es un poco larga y confusa porque apunta a dos tipos de usuarios muy diferentes:

• Aquellos que tienen que llenar un formulario de metadatos, generalmente en un Andino u otro tipo de portal de datos: sólo quieren entender qué deben poner en cada campo.
• Aquellos que quieren hacer una implementación propia del perfil de metadatos o consumir un data.json: quieren entender qué se debe poner en cada campo y cómo este se traduce o aparece en el data.json.

Hay que pensar un re-factor de la guía de metadatos para servir mejor a los dos tipos de público, lo que podría incluir una separación de la guía en dos.

Además debería referenciar mejor a las herramientas disponibles para producir y validar catálogos.

https://www.indec.gob.ar/clasificadores.asp

Aparte de la caracterización de un dataset usando los campos de metadatos existentes, muchas veces existe el caso en el que 1 o más documentos metodológicos son necesarios.

A veces se puede acceder a estos mediante la "Página de referencia" (landingPage) pero muchas veces no, especialmente si se usa como página de referencia a la de un portal de datos como CKAN (no es la página donde originalmente fue publicado el dataset.

Formas posibles de tratar el tema:

Documentos metodológicos linkeados en la metadata

• Agregar un campo al perfil de metadatos para linkear a una o más URLs con documentos metodológicos.
• Si se permite poner varias URLs, el campo debería contener objetos {} con la posibilidad de (al menos) poner un Título y una URL.

Documentos metodológicos como distribuciones del dataset

• Recomendar el agregado de documentos metodológicos al dataset como nuevas distribuciones
• Se debería poder marcar claramente qué distribución es un documento y cuál tiene datos? Es suficiente con ver el formato de la distribución para que el usuario entienda cuándo se enfrenta a datos y cuándo a un documento?

Contexto

Actualmente recomendamos la separación de campos en uno "primario" y uno "secundario" cuando hay hasta 2 valores en una misma columna, que refieren al mismo tipo de entidad.

Hay columnas que incluyen más de 2 valores, en cuyo caso esta recomendación deja de ser práctica y requiere recomendar alguna forma de generar listas.

Propuesta

Investigar 2 o 3 alternativas (con sus pros y contras) para generar valores que son listas.

Después de revisarlos entre ustedes dos @fpetrone @solpar , @fpetrone por favor fijate de actualizarlos en las guías y en los ejemplos de data.json de este repo.

Después porfa hay que revisar que se cambie en los siguientes lugares, preguntando a sus responsables:

• Ver con @capitantoto para actualizar en pydatajson
• Ver con @iheredia todos aquellos lugares en datos.gob.ar y Andino donde haya que actualizar también

Gracias!!

Desde la publicación del perfil 1.1 de metadatos no se actualizaron los ejemplos para reflejar la nueva estructura.

Contexto

Los datasets que son federados de otros catálogos pierden la información de qué catálogo provienen.

Propuesta

Incorporar 2 campos de metadatos:

• title o publisher.name
• homepage

Que son del catálogo de origen, a nivel dataset

• proponer sistemas (casos de uso, pros, contras)
• caracteres especiales permitidos

En la guía nos parece mejor ubicar el tema antes de hablar de cada tipo de entidad interoperable.

Corregir enlaces de: catálogo, dataset, distribución, campo, tema. Para los títulos "Portal Andino" y "campos del perfil".

Los enlaces redirigen todos a los items de "Portal Andino". Esto sucede debido a la imposibilidad de modificar los tags href generados de manera automática por el procedimiento "make docs".

Se propone diferenciar el nombre asignado a esos enlaces para cada uno de los dos apartados, o encontrar la manera de hacerlo mediante "make docs".

"Ministerio de Modernización. Secretaría de Modernización Administrativa. Oficina Nacional de Contrataciones."

Las palabras Ministerio y Secretaría, por ejemplo, podrían tener abreviaturas.

• Chequear que el formato en markdown de cursivas, negrillas, etc coincida bien con el de las guías en PDF
• Chequear que las listas en markdown queden con la misma jerarquía y separación entre elementos que en las guías en PDF
• Chequear que los anchos de las columnas de las tablas permitan leer bien los nombres de los campos y tengan sentido de proporción respecto del contenido de las columnas
• Agregar las imágenes que falten en el markdown, dentro de la carpeta assets.
• Relevar todos aquellos cambios de formato más complicados (colores, imágenes donde se complica el centrado o tamaño correcto, etc) que requieren consultas con @abenassi o @iheredia para mejorar el formato.

En el mundo de los datos abiertos, hoy por hoy estamos forzando a que quien quiera descargarse las tablas que definen el perfil de metadatos se tenga que copiar un html. Abramos las tablas y sumémoslas como CSV al repo.

Actualmente la guía no contempla recomendaciones respecto a formatos de archivos para documentos. En la experiencia de trabajo con distintas organizaciones nos han realizado consultas relacionadas a este tema. En función de ellas, considero que deberíamos tratar al menos los siguientes formatos:

• DOC/X.
• PDF.
• (X)HTML.
• ODT.
• TXT.

Pudiendo resumir el análisis en una tabla con las siguientes variables: Formato; Descripción breve; Principal funcionalidad, ej: edición, colaboración, visualización; Nivel de apertura.

1. Valores tipados booleanos
2. si/no
3. Otros de uso muy difundido como 1/0

@fpetrone dejo este issue para cuando tengamos el Geonode levantado y podamos encarar este laburo.

Después de hacer el mapeo y validarlo internamente, deberíamos sumarlo a las guías como una tabla nueva (sumamos un Anexo?) en la guía de metadatos.

Revisar y corregir "guía de uso y publicación de metadatos", específicamente el siguiente apartado:

El data.json de quienes usen el portal Andino contará con los metadatos correspondientes a los datasets y distribuciones.

Los metadatos a nivel de catálogo deberán ser completados en una planilla de cálculo y publicados en formato CSV en el directorio raíz del portal, quedando disponibles para su descarga en una URL como http://datos.[entidad].gob.ar/catalog.csv.

El resto de los metadatos generados al cargar o actualizar un dataset o una distribución en el portal, se generan a través de los formularios completados y se publican automáticamente en http://datos.[entidad].gob.ar/data.json.

La redacción de la sección http://paquete-apertura-datos.readthedocs.io/es/stable/guia_abiertos.html#fragmentacion-de-archivos puede mejorarse / actualizarse siguiendo los criterios de fragmentación de archivos que fueron madurando en la discusión con los organismos publicadores:

• Clarificar criterios "umbral" que sugieren que es deseable la fragmentación de archivos (añadir uno basado en el peso en MB del archivo)
• Clarificar pros y contras de los 3 criterios de fragmentación, y sugerir una priorización / conveniencia a priori en la selección de cuál usar
• Agregar ejemplos

Actualmente desde el equipo de Datos Argentina recomendamos la licencia Creative Commons Attribution 4.0 por lo que hay que modificar la sección Perfil de Metadatos en la Guía de Metadatos.

Plantear la discusión sobre cómo normalizar las unidades.
Pasos a seguir:

• investigar los estándares nacionales e internaciones,
• analizar el nivel de implementación actual en la APN,
• elaborar recomendaciones,
• documentar y
• comunicar

• Controlar que funcione bien el versionado

En versión 0.1, nuestra recomendación general sigue la línea de "mejor explícito que implícito" y es más bien aversa al uso profuso de abreviaturas.

Nos parece que los nombres de los campos más largos pero muy declarativos son mejores que los más cortos pero confusos, o ilegibles sin leer una descripción adicional por fuera del recurso tabular.

Sin embargo existen casos genuinos donde abreviar puede ser necesario, por ejemplo:

• Software o aplicaciones que no permiten más de X caracteres para el nombre de los campos (Carto, shp: admiten hasta 10 caracteres)
• Algoritmos o rutinas que procesan varios campos a la vez y el uso de nombres largos es contraproducente o incluso afecta la legibilidad del algoritmo

Estaría bueno que tratemos de encontrar/discutir criterios generales o listas curadas de abreviaturas de uso muy difundido a las que podamos remitirnos para abreviar las mismas entidades, siempre de la misma manera. Esto reduciría las desventajas del uso de abreviaturas bastante.

La guía de entidades interoperables habla de entidades transversales y específicas. Estas últimas no son tan claras para los usuarios por lo que sería bueno sumar algunos ejemplos. Dejo algunas opciones:

• Clasificación Internacional de Delitos con fines estadísticos
• Clasificador Internacional de Enfermedades (CIE-11)

Para la clase "Distribución", propiedad "URL de acceso" (accessURL) deberíamos agregar a la descripción un texto similar al siguiente: "De no existir un valor apropiado en los términos descriptos, deberá completarse este valor con el mismo que "URL de descarga" (downloadURL)".

Debería además considerarse cambiar la condición requerido de "Sí" a "Recomendado" o "No".

Agregar recomendaciones a las guías y pensar que efectos o no tiene sobre la posterior federación.

Contexto

Queremos poder especificar que una tabla publicada en CSV sigue el formato de "panel", con el objetivo inmediato de leerlo y transformarlo a series de tiempo.

Propuesta

Generar un documento con campos de metadatos adicionales y/o nuevos casos comprendidos en los 2 campos previstos para extensiones especiales que permita documentar paneles.

Hola,

Les pasamos los puntos que agregamos en las guías de GCBA para que analicen si son pertinentes para incorporarlas en las de Nación.

1. Guía para la publicación de datos en formatos abiertos

• Agregamos algunos tipos de formato: kml, geojson, geopackage.

• Sumamos estándares "sectoriales": WKT, GTFS, OC.

• Incluimos la sugerencia de incluir para datos geográficos dos archivos: un CSV con WKT y datos en formato propiamente geo (Geojson, shp).

• Agregamos referencia para entidades de gobierno (muy parcialmente desarrollada hasta tener devolución de SECLyT), las siglas las define un x organismo (SECLyT en GCBA).

• Incluimos una aclaración de cómo levantar un archivo CSV desde un excel para facilitar la accesibilidad.

• En los rangos horarios, hay un error de tipeo: donde va "Jueves de 8 a 12 hs y de 16 a 20 hs -> "JUE__08:12-17:00_16:00-20:00"" debería ir "Jueves de 8 a 12 hs y de 16 a 20 hs -> "JUE__08:00-12:00_16:00-20:00"".

2. Guía para la identificación y uso de entidades interoperables

• Aclaramos que los nomencladores de INDEC son dinámicos y pueden cambiar, que los citados refieren al Censo 2010.

• Desarrollamos las particularidades de CABA que ustedes mencionan, escribimos la interoperabilidad dentro de CABA, en la guía de Nación menciona que es una particularidad y los motivos. Si quieren, podemos pasarles un párrafo con la interoperabilidad de CABA o pueden referenciar directamente a la guía de GCBA.

3. Guía para el uso y la publicación de metadatos

• Agregamos Normativa aplicable a la Protección y Clasificación según Normativa como campos de la metadata de distribución.

La guía de metadatos es la con la que más estamos trabajando ahora ya que no agregamos tantos cambios. Cuando haya nuevos, abrimos otro issue.

Muchas gracias!! Cualquier duda avisen.