Con motivo del XII encuentro iberoamericano de Ciudades Digitales, que se celebra en Bilbao los días 28, 29 y 30 de septiembre del presente año, pensamos que podría ser buena idea la realización de una aplicación de ejemplo, basada en open data, vistosa a la vez que útil.

Se optó por realizar un display en tiempo real de las paradas de transporte público más próximas al Palacio de Congresos Euskalduna, donde se celebra el congreso. La aplicación muestra al usuario el tiempo restante para la llegada del próximo vehículo de transporte público a una determinada parada. Se basa en la información proporcionada por los transportes de la ciudad de Bilbao, concretamente metro, autobús y tranvía, publicada en sus respectivas páginas Web.

A nivel personal, el objetivo principal de esta primera toma de contacto con open data era aprender qué es open data y que mejor forma que enfrentándose a los problemas de utilizar este movimiento y analizando las posibles soluciones.

Los primeros problemas

El principal problema encontrado a la hora de trabajar con los datos publicados, fue el formato en el que se presentan al usuario. El W3C recomienda la liberación de datos útiles y en formatos abiertos que permitan la reutilización automatizada.

Para realizar la aplicación optamos por almacenar los diversos horarios en una base de datos. Por lo tanto, el primer hito a realizar era la búsqueda de los horarios en la Web. En esta ocasión los datos se liberaban en formato PDF, que a pesar de ser un formato libre, no presentaba una estructura idónea, la información se distribuía en diversas tablas que no eran homogéneas entre sí, lo que impedía el tratamiento automático. En consecuencia, una labor que podría ser prácticamente automática se convierte en una labor un tanto tediosa y que nos exige mucho más tiempo del estimado en un principio.

Un segundo objetivo era hacer una aplicación de realidad aumentada. En esta ocasión, se encontraron pequeñas dificultades a la hora de indicar la geoposición de cada una de las paradas con las que hemos trabajado, esto se debe a que no existe ningún fichero que nos proporcione la ubicación exacta de las mismas. Esta información es de vital importancia cuando utilizados un navegador de realidad aumentada, como es Layar.

Un buen ejemplo en la liberación de datos abiertos relativos a los horarios de transporte público es el Ayuntamiento de Gijón, ya que dispone de un servicio Web que facilita la realización de este tipo de aplicaciones. Este servicio Web proporciona los datos en tres formatos diferentes: JSON, XML o SOAP. De esta forma, con una decena de líneas de código podríamos hacer la consulta que nos devolviesen los datos sin apenas transformaciones

Conclusiones

Cuanto más bien estructurados y enriquecidos estén los datos, más sencillo será reutilizarlos y construir aplicaciones que los traten automáticamente. Entre los formatos de datos más adecuados para desarrollar una aplicación de este tipo estarían XML y JSON, aunque lo ideal sería que los datos se publicasen empleando el modelo RDF, que se consultarían empleando el lenguaje SPARQL.

Para esta aplicación de ejemplo, si los datos publicados hubiesen estado en un formato más adecuado que en documentos PDF, habríamos empleado muchas menos horas en su realización. La consecuencia directa de emplear menos horas en el tratamiento de datos es la disponibilidad de más horas y atención en la programación propiamente dicha de las aplicaciones.

Echando un vistazo al mapa nacional de las iniciativas Open Data, observamos que cada vez hay mayor preocupación dentro de las Administraciones Públicas por la transparencia y por ofrecer los datos públicos a sus verdaderos dueños: la ciudadanía y las empresas. Los catálogos de datos públicos crecen como setas, y algunas administraciones empiezan a notar la creciente demanda de información específica, lo que fomenta la aparición de aplicaciones realmente útiles para la sociedad.

Algo que realmente llama la atención es el compromiso de las distintas iniciativas de hacer Open Data realmente abierto, usando formatos estándar. Todas buscan la excelencia tecnológica, con la vista puesta en las 5 estrellas de Tim Berners-Lee, lo que nos congratula enormemente y motiva para seguir apostando por la base de la Web del futuro próximo, las tecnologías Linked Data que ayudan a crear la Web de los Datos. Pero, entre esta vorágine tecnológica, nos encontramos con un problema… no todos lo hacen bien y esto pone en peligro el crecimiento de la Web de los Datos.

Después de varios posts argumentando el uso de Linked Data, no hace falta insistir en las bondades de estas tecnologías 5 estrellas y cada vez surgen más aplicaciones de última generación, que hacen uso de la semántica estos datos enlazados y se aprovechan de la gran potencia de estos mecanismos de asociación conceptual, combinación y enriquecimiento de la información. El problema surge cuando se desconoce y, por lo tanto, malinterpreta el funcionamiento de la representación semántica –usando RDF– y los conceptos básicos ligados a este modelo. Hemos observado la proliferación de conjuntos de datos que se proclaman erróneamente “semánticos” y en “formato” RDF.

El concepto y las tecnologías Linked Data, no son triviales y son desconocidas para la mayoría de los desarrolladores clásicos. Si estos pretendieran entrar en materia e intentaran usar datos que supuestamente están representados erróneamente mediante estas tecnología, se encontrarían con una situación frustrante y contraproducente para ellos y el futuro del Linked Government Data.

Pero, ¿por qué se hace mal? Básicamente, no se aplica la esencia del Linked Data. Para ilustrar algunos de los problemas comunes y que sea algo más comprensible, se llevará al plano del XML tradicional.

Confusión RDF y XML

El RDF es una infraestructura para describir semánticamente recursos, es decir, dotar de sentido a lo que representamos para que las máquinas lo comprendan. Aunque la información RDF se puede representar en distintos formatos: XML, N3, Turtle… Muchos creen que el RDF es simplemente XML, no es así.

El XML es un formato para representar información en forma de árbol, mientras que RDF representa grafos. XML es útil para la interoperabilidad sintáctica, pero RDF ofrece una dimensión más, la interoperabilidad semántica.

No se representa correctamente la información

Para representar de forma correcta la información se debería atomizar, indicando los tipos de datos representados (numérico, textual, fecha,…). Además, siempre que sea posible, toda la información que no literal (fechas, nombres, descripciones textuales, etc.) se deberían representar cualquier recurso (objeto real o concepto) como tal. De esta forma, podemos acceder directamente a la información que nos interesa y procesarla de forma automática.

Sería similar a un desarrollador que pretende hacer una aplicación que lee el siguiente XML:

<elemento>
  <![CDATA[<fecha>2001-01-03</fecha>]]>
</elemento>

La herramienta de análisis del documento, no podría tener acceso directo a elemento2… Esto es algo obvio, ¿no? Pero tampoco sabría que la información útil es de tipo fecha. Habría que hacer un procesamiento léxico y sintáctico.

Solución:

Especificar correctamente los tipos de datos que se representan. Por ejemplo, un curso titulado “Técnico en Software Ofimático”, del servicio de empleo del Principado de Asturias representa el inicio y fin indicando el tipo de tipos representado, en este caso una fecha.

...
<x:Accion-Formativa rdf:about="http://risp.asturias.es/empleo/oferta-formativa/Accion-Formativa/2010_123">
  ...
  <cal:dtstart rdf:datatype="http://www.w3.org/2001/XMLSchema#date">2010-03-19</cal:dtstart>
  ...

No se definen esquemas (vocabularios)

Lo ideal sería utilizar vocabularios (esquemas) estándar, aunque si no existieran se definirían ad-hoc. De esta forma se dota de semántica a la información. Si no se especifica un vocabulario asociado a la representación de la información, ésta no tiene sentido semántico. Puede que tenga sentido para el propio productor de la información, pero para el resto, sólo vería un contenido (aunque con sintaxis correcta) sin sentido. Ni hablar del tratamiento automatizado.

Llevándolo al plano del desarrollo usando XML sería como ofrecer el documento siguiente y no ofrecer un esquema XSD ni información relativa a la estructura que se sigue:

<info>
  <elem0001>1000292</elem0001>
  <elem0002>New York</elem0002>
  <elem0001>2001-03-02</elem0001>
  <elem0001>2014-02-12</elem0001>
  <elem0003 att00x="disabled">true</elem0003>
  ...

Inútil, ¿no? ¿Qué significa 1000292? ¿y 2001-03-02?…

Solución:

Usar vocabularios estándar o ampliamente utilizados como, por ejemplo, el Dades Obertes de la Generalitat de Catalunya que utiliza una representación basada en el estándar VCard para representar la información de contacto de sus equipamientos públicos.

Estos vocabularios se pueden especializar en función de los requisitos de la organización, como lo ha hecho con los centros municipales el Ajuntament de Barcelona, quienen han adaptado el esquema de VCard para sus necesidades. Después de modificarlo, lo han documentado y expuesto para que pueda ser también reutilizado (http://bcn.cat/data/v8y/xvcard#).

No se identifican los recursos

La mayoría de los recursos definidos mediante RDF deberían tener asociadas URIs resolubles para acceder a ellos desde las aplicaciones o desde otros recursos. Si se identifican con URIs (direcciones Web unívocas) a las que no se pueden acceder, perdemos la mitad del Linked Data (en concreto, el “Linked”).

No tendría sentido tener que descargarse el documento para tratarlo localmente.

Solución:

Identificar los recursos mediante URIs resolubles. Un ejemplo de esto, puede verse en los las ofertas de empleo publicadas en el Datos Abiertos de la ciudad de Zaragoza. Cada oferta de empleo tiene asociada un URI (por ejemplo, una oferta de Oficial Conductor es http://www.zaragoza.es/datosabiertos/id/empleo/Oferta/455).

Gracias a esto, podemos enlazar los datos entre sí. Por ejemplo, podemos ver en las definiciones de los datasets del Open Data de Euskadi que se hace referencia a la zona geográfica del propio dataset usando enlaces a recursos de una base de datos especializada sobre lugares poblados, Geonames. En este caso, http://sws.geonames.org/3104469/ define a la provincia de Vizcaya.

Conclusiones

Estos y otros problemas nos lo encontramos en muchos de los catálogos de datos 4 o 5 estrellas. Está claro que no es sencillo y pueden cometerse errores, pero habría que respetar al menos la esencia del Linked Data. No es necesario tratar de publicar todos los conjuntos de datos en RDF, ni accesibles desde un SPARQL endpoint (para hacer consultas sobre RDF), pero aquellos que se publiquen deberían poder usarse de la forma que se esperaría.

Cuando publicamos un conjunto de datos en Linked Data, entre otras, deberíamos plantearnos las siguientes preguntas:

• ¿Puede ser combinado con un conjunto de datos del mismo tipo procedente de otra administración, esto es, hacer Linked Data?
• El vocabulario usado, ¿está claramente especificado y es reutilizable?
• ¿Puede un agente reutilizador usar los datos sin falta de descargarse ficheros?
• ¿Se puede acceder a cada uno de los recursos definidos mediante una dirección Web (URI)?
• ¿Se podrá acceder dentro de un año a estos recursos de la misma forma?
• ¿Están los recursos Linked Data enlazados entre sí?

Todas estas preguntas deberían tener respuestas afirmativas.