miércoles, 24 de mayo de 2017

Comentarios sobre la guía estratégica de puesta en marcha de datos abiertos del Grupo de Datos abiertos de la FEMP

Hace unos días se publicó un primer borrador de la Guía estratégica para la puesta en marcha de una estrategia de datos abiertos a nivel municipal. Esta guía ha sido desarrollada por el grupo de trabajo sobre datos abiertos de la FEMP.

Seguramente el enlace anterior dejará de funcionar en algún momento, cuando se avance con los comentarios que todos los miembros del grupo (y cualquier entidad externa) están haciendo a dicho borrador, así que puede ser que en algún momento muchos de los comentarios que hago ahora mismo en esta entrada del blog no tengan mucho sentido. Disculpad si leéis esto y ya no se entienden algunas de las referencias que proporciono, y prometo escribir otro blog post cuando se genere la siguiente versión de la guía, anunciando que ya está disponible ;-)

Ante todo decir que la guía se ha desarrollado en un tiempo record, lo que demuestra que el grupo de gente que ha estado colaborando en ella ha trabajado muy bien para poder ofrecer una visión muy clara a aquellos municipios que están pensando en montar sus portales y APIs de datos abiertos. Kudos para todos...

Y ahora al lío. Me voy a poner el gorro académico en ocasiones, así que a veces seré un poco "quisquilloso" con algunas cosas que están escritas ahora mismo en la guía. Que no se malinterpreten los comentarios, que están centrados en las cosas que creo que habría que cambiar, sino todo lo contrario, que se entiendan como comentarios constructivos procedentes sobre todo del mundo académico y de la manera en la que habitualmente escribimos nuestros informes.

Allá vamos:

  • En primer lugar, creo que la introducción quizás necesite un buen repaso. Sobre todo por el hecho de que el hilo conductor de la introducción no deja demasiado claro cuál es el objetivo de la guía que uno está leyendo. Comienza hablando de transparencia y gobierno abierto, con referencias a la Constitución Española. A continuación se pasa a hablar de datos abiertos y se hacen en ocasiones varias relaciones causa-efecto que no está claro que sean adecuadas (por ejemplo, cuando se comienza un párrafo con un "por tanto", que no está muy relacionado con el contexto de los párrafos anteriores). Mi recomendación es que se evite hablar de transparencia en el primer párrafo, sobre todo porque muy claramente se dice en la sección 12 que transparencia no es lo mismo que datos abiertos, y que se centre mejor el mensaje en  la importancia de los datos abiertos, sobre todo desde la perspectiva de las administraciones locales.
  • En la sección 4 se habla de las funcionalidades básicas y recomendables de los portales de datos abiertos. Se hacen las siguientes observaciones sobre el listado actual:
    • Modificar "tipo Google" por "basado en palabras clave".
    • En la sección "Colabora: conjuntos de datos propuestos por ciudadanos/as", sustituir "propuestos" por "generados".
    • El nombre de "Registro de reutilización" no es claro. Quizás sea más sencillo hablar de "registro de reutilizadores/as".
  • En la sección 5.4 se habla de INSPIRE, pero no se proporciona ninguna descripción específica de esta directiva.
  • Se considera adecuado unir los textos de las leyes 18/2015 y 37/2007 sobre reutilización de la información del sector público, de la misma manera que las directivas europeas correspondientes se han presentado de manera conjunta anteriormente en esa misma sección.
  • En la sección 6 hay algunos textos que pueden ser considerados excesivamente informales para un documento de estas características (por ejemplo, "estamos en pañales", "Hay que dejar entrar a la ciudadanía en las cocinas de nuestras organizaciones"). Se sugiere utilizar un conjunto de expresiones más formal.
  • En la sección 6 también se habla de Big Data para realizar análisis sobre los datos. En mi opinión, una buena parte del tratamiento de los datos no requiere de técnicas de Big Data, y estas referencias a Big Data podrían hacer que se considerara que el foco de las administraciones públicas en sus políticas de datos abiertos debe estar centrado en el uso de Big Data y la realización de análisis predictivos, que no es en absoluto el caso en muchos de los tratamientos a realizar. Se recomienda suprimir ese párrafo. El mismo comentario es aplicable al segundo párrafo de la sección 7.3, que hablar obre recomendaciones para la contratación de sistemas de información. La referencia a Big Data puede llevar al equívoco de que se deben contratar sistemas relacionados con Big Data, cuando no son necesarios siempre en el contexto del tratamiento de datos abiertos. 
  • En la sección 7.3 se habla de la publicación en un estándar de facto como EXCEL. Se habla asimismo de CSV y XML. En mi opinión, se debería quizás hablar también de JSON, por ser un formato ampliamente utilizado por desarrolladores, y eliminar la referencia a Excel
  • De manera similar, en la sección 7.4 se habla de formatos como Excel, XML o Word, como formatos estructurados y reutilizables para aspectos relacionados con eventos y actividades. Hay que considerar que Word no es un formato estructurado y reutilizable, por lo que dicha referencia debería ser eliminada.
  • En esta misma sección se habla en el último punto de mapas. Estos no tienen nada que ver con la cartelería, y si se quiere hacer mención a este tipo de información debería quizás generarse una nueva sección 7.5
  • En el contexto de la sección 8.1 sobre herramientas, podría ser interesante añadir una referencia a herramientas o servicios de anonimización de datos, que son muy relevantes para muchos de los datos que tienen que publicar las administraciones públicas.
  • En la sección 8.2 se habla de que la evolución de las herramientas ha pasado de herramientas instaladas localmente a herramientas en la nube. No consideraría esto como una evolución, puesto que se trata de distintas estrategias. Hay administraciones locales que estarán más interesadas en instalar y mantener portales de datos abiertos de manera local, mientras que otras podrán estar interesadas en gestionar sus datos en la nube. Ambas estrategias son válidas, y no debería verse una como la evolución de la otra
  • La discusión en la sección 8.2 sobre plataformas está muy sesgada y no representa claramente la variedad de plataformas existentes. Aquí puede ser más relevante hacer una clara distinción entre las plataformas de código abierto y las propietarias, para mostrar que hay dos grandes grupos. Entre las de código abierto se pueden mencionar CKAN o DKAN, y entre las propietarias Socrata, OpenDataSoft o Data Press). Las referencias a los lugares donde están desplegadas pueden quedarse rápidamente obsoletas, por lo que puede ser preferible no hacer estas referencias tan específicas.
  • En la sección 8.3, de nuevo se utiliza un lenguaje algo informal cuando se dice que hay "miles de formatos". Se puede hablar de una gran variedad de formatos. Asimismo, en esta sección se incluye una tabla organizando estos formatos. Quizás es más recomendable no crear una categoría específica de formatos semánticos, sino incluir entre los formatos abiertos los que se incluyen como RDF y JSON-LD, puesto que no tienen por qué estar necesariamente asociados a ninguna representación semántica
  • La sección 8.6 sobre Seguridad es excesivamente larga comparada con el resto de secciones. Quizás es conveniente reducir su longitud
  • La sección 10 de referencias debería pasarse al final del documento
  • En el plan de formación de la sección 11 aparecen una serie de criterios relacionados con la gestión de los datos (datos únicos, compartidos, accesibles y abiertos, etc.). Estas consideraciones estarían mejor planteadas directamente en la sección de introducción, pues dejan claro algunos de los elementos más importantes en la gestión de datos abiertos
  • En la sección 13, sobre bibliografía recomendada, se puede añadir el MOOC sobre Web Semántica y Linked Data que se ofrece en Miriadax, y en el que he participado: https://miriadax.net/web/semantic-web-and-linked-data
  • Finalmente, en el glosario podría ser recomendable eliminar las entradas de Big Data, CKAN y Socrata, teniendo en cuenta algunos de los comentarios anteriores
Espero que estos comentarios puedan ser útiles para la generación de la siguiente versión de la guía, que espero que sea un documento de gran interés para los municipios que se estén planteando adoptar una estrategia de datos abiertos.

No hay comentarios:

Publicar un comentario