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.

Datos (enlazados) y estadística pública (después de las jornadas JECAS2016)

Los días 22 y 23 de septiembre de 2016 estuve en las Jornadas de Estadística de las Comunidades Autónomas (JECAS2016), que se celebraron en Madrid. Existen varias razones por las que quería estar presente en esas jornadas. Primero, llevo trabajando con institutos de estadística y con datos estadísticos ofrecidos por estos institutos durante varios años, desde nuestros primeros “pinitos” con nuestro portal http://geo.linkeddata.es/ hasta algunos de los trabajos que he hecho en el Grupo de Periodismo de Datos de Medialab-Prado, incluyendo también los trabajos en la API de Localidata. También hemos trabajado en el grupo en herramientas para visualizar y validar datos en RDF DataCube (https://github.com/oeg-upm/geostatistics-conformance-tests, https://github.com/oeg-upm/statistics-service). Y Finalmente, ahora mismo estoy trabajando como experto para Eurostat/DIGICOM, ayudando en la organización de un evento sobre el uso de datos enlazados estadísticos para uno de los roadmaps que se están desarrollando ahora mismo sobre la adopción de Linked Data en la estadística pública.

Hay dos sesiones que me han interesado especialmente dentro de las jornadas (teniendo en cuenta mi perfil informático, claro). La sesión C sobre métodos y procesos estadísticos, donde se habló bastante del uso de Big Data en la estadística pública, y la sesión H sobre difusión de la información, donde di una de las ponencias sobre el trabajo que hemos estado haciendo con el Instituto Aragonés de Estadística en la generación de Linked Data estadístico sobre sus datos de estadística local.

En la primera de las sesiones (la de métodos y procesos estadísticos, y Big Data) puedo destacar (de forma completamente subjetiva, por mis propios intereses), las presentaciones hechas desde Canarias (donde se presentó uno de los trabajos hechos por Localidata en la extracción y reconciliación de establecimientos comerciales a partir de APIs), Navarra (donde se presentaron algunos resultados del uso de datos de telefonía para caracterizar turistas y excursionistas) y Euskadi (donde se presentó una prueba de concepto relacionada con el uso de datos Web para determinar costes hoteleros). Lo más importante de todas estas ponencias fue la discusión sobre los límites y oportunidades que todas estas fuentes de datos ofrecen a la hora de integrarlos en la estadística pública. Supongo que Alberto González Yanes publicará algo en su blog en algún momento (y si no, ya aprovecho para decirle que lo haga ;-))

En la segunda de las sesiones (sobre difusión estadística) se habló mucho de datos sobre municipios (muy interesante y actual la tecnología y metodología utilizada por el ICANE para la generación de sus fichas municipales <https://www.icane.es/munreport>). También hubo dos presentaciones relacionadas con R. De mi presentación, simplemente dejo aquí el enlace a la presentación en slideshare (dejo que otros comenten sobre ella, y especialmente recomiendo las conclusiones). 

En definitiva, me alegro de haber asistido a las jornadas, y eso que me perdí la parte social (vamos, la cena y la after-cena), que como le digo siempre a mis alumnos de doctorado, es una de las partes que uno no se debe perder en cualquier conferencia o evento, porque es cuando uno puede hablar de mil cosas más en un entorno más distendido. Pero es lo que tiene “jugar en casa” ;-) 

Accediendo a datos a través de APIs

Preparado para las III Jornadas de Periodismo de Datos.

Después de la experiencia del año pasado, en las II Jornadas de Periodismo de Datos, contando cómo se puede utilizar la línea de comandos para hacer algunas cosas interesantes con ficheros de datos muy grandes, este año vamos a avanzar un poquito más y demostrar que cualquier periodista también puede acceder muy fácilmente a datos que estén disponibles en una API, y no sólo utilizar los datos que estén disponibles en ficheros Excel o similares.

Primero tendremos que ver lo que es una API. Eso sí, como nos vayamos a la definición de Wikipedia, nos vamos a quedar igual, así que nada mejor que ver algunos ejemplos de APIs para entender mucho mejor lo que nos pueden ofrecer:

• La de datos abiertos de Zaragoza: http://www.zaragoza.es/ciudad/risp/api.htm
• La de datos de Localidata: http://datos.localidata.com/
• La de datos de la EMT, en Madrid: http://opendata.emtmadrid.es/
• Y la de datos abiertos de Aragón: http://opendata.aragon.es/portal/desarrolladores/api-aragodbpedia

Claro que hay muchas más, y no todas son de datos abiertos gubernamentales (Open Government Data), sino que también hay muchas con datos que no se pueden reutilizar libremente para fines comerciales, o con restricciones de uso importantes (por ejemplo, las de Google Places, la de Twitter, la de FourSquare, etc.). Si os aburrís, podéis seguir mirando y buscando APIs en http://www.programmableweb.com/. Seguro que os sorprendéis viendo lo que se puede encontrar aquí.

1. Calentando motores... Registrándonos en las APIs para poder usarlas

Es bastante habitual que sea necesario registrarnos para usar una API, incluso aunque sea de datos abiertos. 

• En el caso de las APIs que son de pago, la razón para solicitar el registro está muy clara: es una forma de poder contabilizar el número de peticiones, limitar la frecuencia de dichas peticiones según el tipo de pago que se realice, ofrecer analíticas más detalladas de los usuarios de la API, etc.
• En el caso de las APIs de datos abiertos, no hay que asustarse y pensar que nos están engañando y que los datos no son realmente abiertos, o que quieren saber necesariamente quiénes somos. Normalmente se trata de dar una buena calidad de servicio, y poder determinar los distintos tipos de usuarios que manejan nuestra API (esporádicos, usuarios intensivos, etc.).

A continuación os dejo los enlaces donde os podéis registrar para cada una de las APIs. La mala noticia es que en casi todos los casos alguien tiene que revisar vuestra petición, así que necesitaríamos esperar unos días. La buena noticia es que, para que hoy podamos hacer nuestras pruebas, ya he generado yo algunos usuarios (ojo, que los datos de identificación que os doy sólo funcionarán durante unas horas, y luego ya tendréis que trabajar con vuestros propios usuarios y claves.

• Zaragoza: en esta API no hay que registrarse (aunque podría establecerse algún mecanismo de autenticación y autorización en el futuro si es necesario para asegurar la calidad de servicio ofrecida).
• Es recomendable, no obstante, registrarse en https://www.zaragoza.es/ciudad/risp/listado_Aplicacion para hacer saber a los encargados de la API el uso que se está haciendo de los datos y recibir avisos.
• Localidata: https://localidata.3scale.net/signup 
• Si os dais de alta os pasaremos una API key
• EMT: http://opendata.emtmadrid.es/Formulario
• Moraleja: cuida dónde pones tus passwords, porque si no no podrás enseñarlo en las JPD_15 ;-(
• Aragón: https://opendataaragon.3scale.net/signup
• Usaremos primero la siguiente API key: e103dc13eb276ad734e680f5855f20c6
• Y luego utilizaremos la siguiente: ccedf913242b23abf4fc1c82044c61f1

2. Comenzando a utilizar cada una de las APIs...

Vamos ahora a mostrar algunos ejemplos muy sencillos de llamadas típicas a cada una de estas APIs. Basta con que hagáis click en cada uno de los enlaces que tenemos a continuación:

• Un hotel en Zaragoza: http://www.zaragoza.es/api/recurso/turismo/alojamiento/109
• ¿Y esto son datos estructurados de buena calidad? Probemos a añadirle un .json o .csv a esta URI.
• La lista de hoteles NH en Madrid: http://datos.localidata.com/recurso/comercio/Provincia/Madrid/Municipio/madrid/Local/Label/nh?api_key=<<tu_API_Key>>
• Los datos de la comarca Cinco Villas en Aragón: http://opendata.aragon.es/recurso/territorio/Comarca/Cinco_Villas?api_key=e103dc13eb276ad734e680f5855f20c6 
• ¿Ha pasado algo raro con esta última?
• ¿Y si probamos con http://opendata.aragon.es/recurso/territorio/Comarca/Cinco_Villas?api_key=ccedf913242b23abf4fc1c82044c61f1? (os explicaré por qué ha pasado esto, para que entendamos las limitaciones de acceso para asegurar la calidad de servicio de la API).

3. Añadiendo un poquito más de complejidad al asunto...

Cada API no sólo tiene sus propias categorías de datos, que además no tienen por qué ser las mismas, sino que tiene sus propias características y funcionalidades. Vamos a ver algunas de las características principales de cada una de ellas. Ahh, y para los muy friquis recomiendo tener instalado algún plugin para trabajar con APIs REST, como por ejemplo el Advanced REST Client de Chrome, o el REST Client de Firefox.

3.1 Zaragoza (https://www.zaragoza.es/ciudad/risp/api.htm)

Para navegar por los datos que están ahora mismo disponibles en la API (no son aún todos los del catálogo de datos abiertos de la ciudad), se puede utilizar esta interfaz, que usa Swagger.

Es bastante intuitivo de utilizar, y vamos a hacer algunas pruebas con él, por ejemplo, con el dataset de Quejas y Sugerencias, que es mi preferido. Esto lo haremos en vivo durante la presentación, y luego subiré aquí el vídeo de la presentación.

Las características principales de esta API son las siguientes:

• Todas las consultas son de tipo GET.
• En el campo q se puede utilizar la sintaxis FIQL para buscar por los valores de cualquier campo. Por ejemplo, para buscar los hoteles NH en Zaragoza se puede usar la siguiente URL: http://www.zaragoza.es/api/recurso/turismo/alojamiento?q=title%3D%3DNH* (en la interfaz es más fácil de escribir, pues basta con poner en q lo siguiente: title==NH*
• Hay una gran diversidad de formatos en los que se pueden obtener los datos: HTML, JSON, CSV, RDF, JSON-LD, GeoCSV, etc. 

Por cierto, que si ya os tiráis a la piscina y os atrevéis hasta con GitHub, podéis colaborar con los responsables de la API en https://github.com/zaragoza-sedeelectronica

3.2 Localidata (http://datos.localidata.com)

Aquí podéis ver una descripción de la API, que no utiliza Swagger, pero proporciona también una información muy parecida, describiendo todas las operaciones de la API.

Todas las consultas son de tipo GET, y cada una de ellas tiene un coste distinto.

Los formatos en los que se puede obtener la información son también múltiples: HTML, CSV, JSON, GeoJSON, JSON-LD, y RDF/Turtle. 

Y también tenemos varias vistas disponibles (parámetro _view): ampliada, coordenadas, simple y tabla

3.3 EMT (http://opendata.emtmadrid.es/)

Aquí también se pueden obtener los datos directamente desde la Web, utilizando las llamadas que hay codificadas, y que no necesitan de usuario y password.

De hecho, los resultados se pueden descargar en JSON, y cargar por ejemplo en OpenRefine.

La principal diferencia de esta API es que casi todas las llamadas son de tipo POST, por lo que es conveniente utilizar un cliente REST como los que hemos comentado en alguna de las secciones anteriores. El servidor actual está en https://openbus.emtmadrid.es:9443/emt-proxy-server/last/<<operación>>

3.4 Aragón (http://opendata.aragon.es/portal/desarrolladores/api-aragodbpedia)

En este caso, la API es muy similar a la que hemos presentado anteriormente para Localidata, pues utiliza la misma tecnología. 

Los formatos que se ofrecen son HTML, CSV, JSON y RDF/Turtle, y los datos están enlazados con la DBpedia española.

También se ofrecen varias vistas (parámetro _view): simple, ampliada y completa.

Igual que antes, podéis también colaborar en GitHub en https://github.com/aragonopendata.

4. Sacándole aún más partido a las APIs

Y ahora voy a incluir aquí algunos enlaces de posts anteriores en los que he explicado qué se puede hacer con algunas de estas APIs, y que espero que os sirvan de ayuda:

• Visualizando datos de distritos de Madrid con DataWrapper
• Mostrando datos básicos de distritos de Madrid con CartoDB
• Mostrando datos de la API de Localidata en Google Maps
• Enlazando barrios de Madrid de la Wikipedia con la API de Localidata
• ¿Qué farmacias tengo cerca de Medialab-Prado?
• Enlazando el callejero de Zaragoza con los autores de la Biblioteca Nacional de España

Enlazando el callejero de Zaragoza con datos.bne.es (4/4)

Este es el cuarto y último del conjunto de posts sobre el proceso de enlazado del callejero de Zaragoza con datos.bne.es. Ahora vamos a lanzar un proceso de crowdsourcing para validar los 81927 enlaces potenciales que hemos encontrado con datos de la Biblioteca Nacional (http://datos.bne.es/) en el post anterior.

Lanzando un proyecto de crowdsourcing para refinar los resultados obtenidos

¿Por qué necesitamos utilizar una herramienta de crowdsourcing? Pues porque la cantidad de datos que tenemos que validar es tan grande que no tenemos más remedio que utilizar la fuerza de la gente para realizar este tipo de tarea. Vamos a dividir el proceso en lo que se denominan "micro-tareas", donde cada persona va a tener que comprobar un posible enlace, y decir cuánto está de acuerdo con ese enlace. 

¿Con quién contamos para hacer esta tarea? Podemos seleccionar un grupo muy selecto de anotadores de muy buena calidad (lo que normalmente será costoso y representará un cuello de botella en nuestro proceso) o podemos dejar que estas tareas las realicen muchísimos anotadores, quizás de menor calidad, pero en mayor cantidad (lo que normalmente será menos costoso).

Podríais pensar que cualquiera nos podría engañar si utilizamos el segundo de los casos. Por supuesto, y los anotadores de mala calidad son muy habituales en este tipo de contextos basados en micro-tareas, pero para ello contamos con la posibilidad de establecer un conjunto de preguntas de control en el proceso (preguntas que no se pueden fallar, y que si se fallan hacen que un anotador quede automáticamente descalificado) y además asignaremos la misma tarea a varios anotadores, por lo que si varios anotadores coinciden en el mismo juicio podemos suponer que los resultados son adecuados. 

Creando las tareas en CrowdFlower

Vamos a utilizar la herramienta CrowdFlower para realizar esta tarea de curación de los enlaces que hemos encontrado.

Durante el #OpenDataDay de Madrid grabaremos un vídeo para explicar cómo funciona esta herramienta, y actualizaré esta entrada de blog. Nos vemos mañana enlazando las calles (de Zaragoza y de Madrid).

Enlazando el callejero de Zaragoza con datos.bne.es (3/4)

Este es el tercero del conjunto de posts sobre el proceso de enlazado del callejero de Zaragoza con datos.bne.es. Ahora vamos a hacer la reconciliación de los nombres de las calles con autores, obras y temas procedentes del portal de datos abiertos de la Biblioteca Nacional (http://datos.bne.es/).

Reconciliando con autores, obras y temas de la Biblioteca Nacional

El portal de datos abiertos de la Biblioteca Nacional contiene una gran cantidad de información sobre autores, obras y temas, todos los cuales están disponibles para ser consultados a través de un portal Web muy sencillo (como se puede ver en la figura, donde estamos buscando información de Cervantes), así como utilizando tecnologías de Linked Data.

En todo momento se puede decidir si se busca y navega por autores, obras o temas, que son los tres tipos de recursos principales que se consideran en este repositorio de datos. 

Accediendo a la información de un autor

Si seleccionamos la primera opción para Cervantes (que claramente representa al Miguel de Cervantes en el que todos estamos pensando), obtendremos la página de descripción de este prolífico autor de la literatura española.

Para nuestros propósitos hay algo importante en lo que nos podemos fijar, que es la URL que aparece en nuestro navegador (http://datos.bne.es/autor/XX1718747.html), que se corresponde con la página de descripción de Cervantes. 

De aquí se puede obtener el identificador (URI) que se usa dentro de la BNE para referirse a este autor (http://datos.bne.es/autor/XX1718747). Por ejemplo, ¿qué ocurre si añadimos .ttl a esta dirección? Obtendremos los datos que se ven en esta página en formato RDF Turtle (http://datos.bne.es/autor/XX1718747.ttl)

Realizando búsquedas de autores

Asimismo, también podemos invocar un servicio para realizar búsquedas de autores. Esto se consigue con consultas como la siguiente:

http://datos.bne.es/find/resultados/?s=CERVANTES&type=Autor&format=json

En esta consulta estamos buscando elementos de tipo Autor que contengan la palabra CERVANTES y obtenemos los resultados en formato JSON.

A continuación tenemos un ejemplo del resultado que se obtiene:

Para Cervantes podemos ver que tenemos 418 hits, ordenados según su ranking de puntuación (que indica cómo de importante es el recurso encontrado). El primer resultado (hit) se refiere a Miguel de Cervantes Saavedra, y de este recurso obtenemos información como su URI, nombre, una descripción, fechas de nacimiento y muerte, etc. Este es uno de los servicios que utilizaremos a continuación.

Buscando obras y temas

De la misma manera en que buscamos autores, podemos buscar obras y temas. Por ejemplo, para obtener las obras en las que aparece la palabra Cervantes (por ejemplo, porque tratan de la vida y obra de este autor), utilizaremos la siguiente llamada:

http://datos.bne.es/find/resultados/?s=CERVANTES&type=Obra&format=json

Y para obtener los temas en los que aparece la palabra Cervantes utilizaremos una llamada parecida:

http://datos.bne.es/find/resultados/?s=CERVANTES&type=Tema&format=json

Ya estamos en disposición de comenzar con las reconciliaciones.

Comenzando a reconciliar con Open Refine

Teniendo en cuenta que los servicios de búsqueda anteriormente mencionados no ofrecen sus datos en JSON de acuerdo con el esquema necesario para que se pueda activar el servicio de reconciliación usado por Open Refine, lo que debemos es utilizar la funcionalidad "Add Column by fetching URLs..." que se nos ofrece para cualquier columna. Vamos a utilizar la columna title_ext para nuestro propósito.

Vamos a comenzar primero obteniendo las obras. Para ello, vamos a crear una columna Autores_BNE usando la siguiente expresión:

http://datos.bne.es/find/resultados/?s="+value.trim().escape("url")+"&type=Autor&format=json

El "throttle delay" es una buena práctica cuando estamos haciendo este tipo de consultas masivas (se van a lanzar 3478 consultas) para no realizar un ataque de denegación de servicio a este servicio. De esta manera las consultas se van espaciando en el tiempo. Aunque tardemos un poco más, es una buena práctica cuando accedemos a este tipo de servicios y APIs (y en el caso de APIs habitualmente tenemos limitaciones de número de llamadas que podemos realizar). 

Una vez realizado este proceso, hacemos lo mismo con obras y temas, creando las columnas Obras_BNE y Temas_BNE. Nos quedará algo como lo que aparece a continuación:

Filtrando los resultados obtenidos

Después de este proceso ya tenemos unas grandes cantidades de datos en JSON en las columnas Autores_BNE, Obras_BNE y Temas_BNE. Ahora es el momento de filtrar esta información para poder seguir trabajando con ellos. En concreto, lo que nos interesa en primera instancia para luego poder validar adecuadamente los resultados obtenidos es la URI del autor, obra o tema (para poder así visitar la página de la BNE en cualquier momento y comprobar si la relación es correcta), el score que esa entidad tiene (que representa su importancia) y su nombre.

Para ello, debemos crear nuevas columnas basadas en los datos que tenemos. Esto se hace utilizando la funcionalidad "Add Column based on this column...", escribiendo como expresión a utilizar una expresión como la siguiente:
forEach(value.parseJson().hits.hits,h,h._score.toNumber().round()+" "+h._source.id+" "+h._source.label).join(";;;;")

De esta manera crearemos columnas cuyos valores sean del estilo:
93 XX160612 Fosfatos de Bu-Craa (El Aaiún);;;;52 XX131502 Instituto Mixto de Bachillerato "General Alonso" (El Aaiún)

Diviendo las columnas con múltiples valores

Para poder seguir con los siguientes pasos de limpieza de los datos, podemos dividir las columnas con múltiples valores que hemos generado anteriormente, convirtiéndolas en múltiples filas. Para ello utilizamos la opción de "Split multi-valued cells...", y estableciendo como separador la siguiente secuencia de caracteres ;;;;

Como se puede observar, el número de filas ha crecido muchísimo (se ha multiplicado por 10).

Ahora vamos a realizar una "transposición" de las columnas en filas, con el objetivo de que podamos tratar cada uno de estos valores de uno en uno. Esto se hace utilizando la opción "Transpose cells across columns into rows", seleccionando las tres últimas columnas y denominando a las dos nuevas columnas tipo y valor. El resultado será algo parecido a lo que aparece a continuación:

A continuación conviene rellenar los espacios en blanco que se han generado en las columnas id, title y title_ext para poder trabajar adecuadamente. Esto se hace con la función "Fill Down", y obtendremos una vista similar a la siguiente:

Generando tantas columnas como atributos queremos tratar

Finalmente, dividimos cada columna en varias, para atender a los distintos atributos que hemos ido generando en cada caso. Para ello utilizamos la opción de "Split into several columns...", y renombramos las columnas con los nombres score, idBNE y labelBNE.

Y generamos la URI de BNE creando una nueva columna URI_BNE con la siguiente expresión:
"http://datos.bne.es/"+cells["tipo"].value.toLowercase()+"/"+cells["idBNE"].value

Con todo este procesado, ya tenemos un fichero de 81297 filas donde se relacionan calles con autores, obras y temas. Ahora habrá que validarlo de manera que podamos determinar todos los valores que son adecuados para entender a qué autores están dedicadas nuestras calles, así como con qué obras y temas están relacionadas.

El script completo en Open Refine se encuentra disponible en https://gist.github.com/ocorcho/ce3954b766a0c1651c7b

Enlazando el callejero de Zaragoza con datos.bne.es (2/4)

Este es el segundo del conjunto de posts sobre el proceso de enlazado del callejero de Zaragoza con datos.bne.es. Ahora vamos a hacer un tratamiento inicial del fichero CSV que nos hemos descargado de la API de datos abiertos de Zaragoza.

Haciendo un tratamiento inicial del CSV en Open Refine

Para ello, lanzamos Open Refine (uy, se me olvidó decir que había que instalar primero Open Refine en vuestro ordenador, aunque seguro que muchos de los que me seguís ya lo tenéis instalado). Vamos a crear un proyecto en Open Refine, cargando el CSV que hemos descargado anteriormente:

Para los más arriesgados, podéis utilizar directamente la URL que usamos anteriormente para obtener el CSV, como muestro en la figura siguiente:

Una vez cargados los datos, tendremos una pantalla como la siguiente. Ahora es importante seleccionar la codificación de caracteres correcta para que las letras con tilde aparezcan bien, y ya podemos dar nombre a nuestro proyecto. Con el español suelen funcionar bien ISO-8859-1 o UTF-8.

Lo que podemos ya ver es que el id de cada calle es una URI que sigue la Norma Técnica de Interoperabilidad propuesta en el BOE del 4 de marzo del 2013. De hecho, en Zaragoza también se utiliza el vocabulario para la representación de callejeros que se ha propuesto en el contexto de la norma UNE 178301:2015 sobre Open Data y Smart Cities. Podéis encontrar más detalles sobre la norma aquí.

Ahora podemos eliminar las tres columnas de la izquierda, que no aportan mucho, y ya tenemos el conjunto de datos preparado para la siguiente fase (tratar con las 3478 calles de Zaragoza).

Enlazando el callejero de Zaragoza con datos.bne.es (1/4)

Hacía mucho tiempo que tenía ganas de escribir este conjunto de posts, porque es un trabajo que he estado realizando durante algún tiempo. Y el catalizador ha sido la propuesta del proyecto A quién dedica las calles Madrid, por Antonio Delgado, con motivo del Hackaton del Open Data Day de Madrid del 2015.

Este conjunto de posts está dividido en varios pasos (una entrada por cada uno de ellos):

• Obteniendo un fichero CSV con las calles de Zaragoza.
• Haciendo un tratamiento inicial del CSV en Open Refine.
• Reconciliando con autores, obras y temas de la Biblioteca Nacional.
• Lanzando un proyecto de crowdsourcing para refinar los resultados obtenidos.

Así que ya podemos empezar...

Obteniendo el fichero de calles de Zaragoza

En primer lugar, vamos a recopilar todos los nombres de calles de Zaragoza, junto con sus identificadores. Accedemos al catálogo de datos del portal de datos abiertos de Zaragoza, y buscamos el callejero en su buscador:

El callejero está disponible en distintos formatos (PDF, DWG, XML, Excel, CSV, JSON, SOAP). Además, el callejero también está disponible en la API de datos de Zaragoza, así que hay para todos los gustos. Como a mí me encanta usar APIs, os cuento cómo descargarse un CSV con todas las calles de Zaragoza.

Una vez en la página que describe la API de datos de Zaragoza (para los freaks, ya veréis que es Swagger), podemos seleccionar la opción de Callejero, como se muestra a continuación:

Luego, nos vamos a la primera de las opciones, y podremos ver cómo funciona la API cuando hacemos una consulta a la URL http://www.zaragoza.es/api/recurso/urbanismo-infraestructuras/callejero/via. Por defecto, nos mostrará sólo 50 filas, y en formato JSON. 

Vamos a descargarnos un CSV, y a descargarnos todas las filas (como no creo que haya más de 5000 calles, le pongo como parámetro 5000).

http://www.zaragoza.es/api/recurso/urbanismo-infraestructuras/callejero/via.csv?start=0&rows=5000

En principio, se debería ir haciendo de poquito en poquito, y se puede automatizar con un script, pero eso os lo cuento otro día.

Y ya tenemos el CSV con el que vamos a trabajar. Si no lo has podido conseguir, escríbeme y vemos dónde nos hemos quedado.