Fundación CTIC

Archivo categoría Técnica

Mi primera experiencia con el Open Data

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.Pantalla de televisión que muestra la aplicación realizada en funcionamiento

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.

Captura de pantalla del navegador Layar para la parada de Jesusen BihotzaUn 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.

1 Comentario

No es Linked Data todo lo que reluce

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.

1 Comentario

Uso de Linked Data para el tratamiento de datos estadísticos

Hace unos días se presentó una aplicación que, mediante el uso de Linked Data, nos permite visualizar de manera sencilla datos de Estadísticas INE sobre equipamiento y uso de las TIC y el comercio electrónico en las empresas y hogares asturianos (2005-2010).

Lo más destacable de esta aplicación es que, gracias al uso de las tecnologías Linked Data, permite combinar datos estadísticos almacenados en decenas de hojas Excel con diferentes estructuras y nomenclatura, una tarea que anteriormente resultaba tediosa y complicada.

Utilizando tecnologías semánticas como RDF o SPARQL hemos conseguido modelar, unificar y exponer los datos, haciendo posible realizar comparaciones de los indicadores estadísticos a lo largo del tiempo (evolutivos), comparaciones entre los datos asturianos y nacionales y, además, hemos dejado la puerta abierta para, en un futuro, poder comparar los datos entre diferentes comunidades autónomas.

Como no podía ser de otra forma en un proyecto Open Data, los datos utilizados por la aplicación se han hecho públicos y son accesibles desde el portal de Reutilización de Información del Sector Público del Principado de Asturias para que cualquiera pueda acceder a ellos y utilizarlos en sus propios desarrollos.

En el siguiente vídeo podéis ver la aplicación en funcionamiento:

, , , ,

1 Comentario

Las URIs no cambian, es la gente quien las cambia.

¿Cómo reconoceremos una buena URI? Una buena URI es aquella que no cambia.
Las URIs no cambian, es la gente quien las cambia

El problema

Cada día se publica en la Web una gran cantidad de documentos, pero lamentablemente muchos de ellos dejarán de estar disponibles al cabo de un tiempo, dando lugar al gran cementerio de enlaces que todos conocemos.

El origen

Existen varios motivos por los que un enlace puede acabar desapareciendo, pero en general ninguno de ellos tiene una causa técnica, sino más bien organizativa. A veces se trata de una simple reorganización de contenidos, otras veces es material que ha quedado anticuado y alguien ha decidido deshacerse de él, o puede que simplemente sea contenido que ha quedado huérfano tras algún tipo de cambio.

Las consecuencias

Lo que está claro, es que en cualquiera de las situaciones anteriores se ha subestimado la importancia de mantener unas URIs estables y permanentes. Por un lado tendremos la frustración que puedan sufrir los usuarios directos de esos documentos porque ese enlace o esa dirección que les han pasado ya no funciona, por otro lado habría que sumar el perjuicio para cualquier otro potencial usuario de dicha información, especialmente para aquellos que pretendan explotarla y reutilizarla a través de la creación de nuevos servicios.

Cuando cambiamos o eliminamos una URI de nuestro servidor nunca podremos estar seguros de las posibles consecuencias y efectos laterales que tendrán lugar a lo largo de la cadena de distribución. Si en algún momento se llegan a perder esos enlaces se perderá también con ellos toda la cadena de valor que se ha creado sobre los mismos.

Caso peor: La Administración

Las webs de la Administración son especialmente vulnerables ante este problema, ya que generalmente utilizan una estructura basada en su propia organización interna y, dado que las Administraciones se encuentran en un proceso de constante evolución, son también frecuentes los cambios respecto a cómo se presenta dicha Administración en la Web.

Las distintas áreas administrativas suelen ser entidades provisionales por su propia naturaleza, lo que da lugar a una base muy débil a la hora de conseguir un esquema de URIs sólido y consistente. La consecuencia directa de este carácter pasajero es que tienen serias dificultades a la hora de mantener URIs persistentes e invariables, y por tanto también para preservar la información, dando en ocasiones lugar a soluciones transitorias y costosas con el objetivo de aliviar la situación.

La solución

Es por ello que las Administraciones deben tener muy presente la importancia de la gestión de datos a largo plazo, para de este modo garantizar que se cubran todas las necesidades del usuario de la información, tanto presentes como futuras. Ser capaces de preservar a lo largo del tiempo los datos que son publicados debería ser una prioridad para cualquier Administración, ya que, idealmente, una vez que publicamos un dato debería poder ser siempre referenciado mediante la URI original.

Próximamente veremos cómo utilizar las URIs para conseguir ese sistema único de identificación que deseamos.

No hay Comentarios

Cómo publicar Linked Data

Cuando nuestra administración ya ha decidido que quiere publicar sus datos de forma abierta y semántica surge la pregunta: ¿Cómo publicamos Linked Data? Recordamos ahora brevemente los principios que deben cumplir nuestros datos para ser considerados Linked Data:

  • Nuestros recursos deben ser unívocamente identificables a través de su URI. Las URIs deben estar basadas en el esquema HTTP para hacer su gestión descentralizada y para hacer su acceso ubicuo a través de la web.
  • Los recursos deben ser descritos mediante RDF que es el modelo de datos de la web semántica. De entre las diferentes representaciones RDF, al menos la serialización oficial en XML, RDF/XML, debe estar disponible para cada recurso.
  • Para crear una auténtica web de datos es necesario que los datos estén enlazados. Nuestros recursos deben incluir referencias en forma de enlaces RDF a otras fuentes de datos y, en la medida de lo posible, deberían ser referenciados desde recursos externos.

En realidad,  los principios de la web de datos son muy parecidos a los de la web tradicional de páginas. Cuando a través de una URL devolvemos descripciones de recursos en RDF ya estamos publicando linked data.

Formas de publicación RDF

A la hora de crear las descripciones en RDF de nuestros recursos tenemos varias posibilidades dependiendo de las circunstancias.

Cuando los datos a publicar son pocos y se espera que no cambien mucho con el tiempo, la forma más práctica de generarlos es mediante un recurso o fichero estático. Un ejemplo típico de esta estrategia son los recursos FOAF (“foaf.rdf”) que son colgados en los sitios web.

Otra forma de realizar las descripciones es obtenerlas de documentos ya existentes no RDF. RDFa es el estándar del W3C que permite embeber RDF en páginas web. Mediante la especificación GRDDL es posible extraer información semántica de documentos XML mediante transformaciones XSL. Existen también otras utilidades “RDF-ificadoras” que transforman en semánticos datos disponibles en otros formatos como hojas excel.

Cuando el volumen de nuestros recursos es elevado no es útil mantener una serie de ficheros descriptores estáticos para cada uno. La forma de publicación más utilizada es generar los documentos RDF de forma dinámica cuando llega una petición para una URI concreta. El W3C ha creado la especificación SPARQL, que define un lenguaje de consultas para RDF. Típicamente, un servidor semántico hará público este punto de consultas a traves del protocolo HTTP. Cuando el servidor recibe una petición para la URI de un recurso concreto esta petición es transformada en una consulta SPARQL sobre los datos de ese recurso, que son devueltos al cliente serializados en RDF/XML.

Plataformas para la publicación

Una vez que hemos definido las descripciones de nuestros recursos, ¿cómo y dónde las colgamos? De nuevo las opciones son similares a cuando publicamos en la web tradicional.

Si tenemos entre manos un proyecto grande de publicación de recursos semánticos, por cuestiones de almacenamiento y escalabilidad la mejor opción pudiera ser recurrir a plataformas especializadas que ofrezcan este tipo de servicios. Sin duda en el futuro proliferarán este tipo de soluciones aunque en la actualidad organizaciones como Talis ya ofrecen una plataforma de esta naturaleza.

Si optamos por publicar y mantener nuestros datos en nuestro propio servidor también disponemos de otras tecnologías, a menudo open source. Dos diferentes opciones son almacenar nuestros datos en un formato nativo de tripletas RDF o bien generarlos dinámicamente en base a otros formatos. Por ejemplo, Virtuoso, que es un completo servidor con soporte para almacenar modelos RDF y publicación mediante protocolo SPARQL; D2R, utilidad que mapea y publica de forma semántica los datos de bases de datos relacionales existentes; o Pubby, herramienta que genera y gestiona las URIs de nuestros recursos cuando ya se dispone de un punto SPARQL con datos publicados.

Acciones a seguir

Una vez que nuestros recursos son deferenciables (accesibles) desde la web la “visibilidad” de nuestros datos dependerá del número de recursos externos que los referencien. Para ayudar a que nuestros recursos sean más fácilmente descubiertos existen, igual que en la web tradicional, servicios de registro de datos semánticos. Uno de ellos es Ping the Semantic Web. También es buena idea apuntar nuestros recursos en páginas web que actúan como directorios para humanos, como esta lista de servicios semánticos .

Próximamente en entradas de este blog ahondaremos en algunas de las cuestiones técnicas mencionadas con algunos ejemplos y casos de uso.

, , ,

2 Comentarios

Herramienta que genera GeoRSS desde SPARQL

SPARQL ofrece gran potencia y flexibilidad en las consultas, pero a veces, determinadas herramientas de consumo de los datos no aceptan el formato obtenido directamente desde el punto de consulta SPARQL.

Mapas alimentados con GeoRSS

Mapstraction es un ejemplo de herramienta de visualización que permite representar información sobre los mapas de los principales proveedores (FreeEarth, Google. Map24. MapQuest. Microsoft. MultiMap, OpenLayers, OpenSpace, OpenStreetMap, ViaMichelin, Yahoo, etc.).
Entre los métodos de representación de los puntos, se incluye la posibilidad de alimentar los mapas desde un documento GeoRSS (RSS + Coordenadas geoespaciales).

La representación de coordenadas desde un canal GeoRSS (listado de catálogos de datos del sector público en GeoRSS) sobre un mapa es algo tan sencillo como se puede comprobar en este ejemplo de la sandbox.

Mapa alimentado desde GeoRSS

Mapa alimentado desde GeoRSS

Convertir SPARQL a GeoRSS

Ya que muchos de los datos los podemos tener accesibles desde resultados de consultas SPARQL, gracias a la sencilla estructura, este se puede transformar casi instantáneamente a otros formatos, como GeoRSS, si se dispone de la información necesaria. Este sencillo Conversor SPARQL a GeoRSS (2.0), nos permite hacer la transformación. Sólamente hay que componer la consulta SPARQL de manera que aparezcan representadas las variables necesarias para el formato GeoRSS.

Las variables necesarias son:

?title
El título de cada elemento (texto)
?description
La descripción de cada elemento (texto)
?link
La URI de cada elemento (http://…)
?date
La fecha asociada al elemento en formato YYYY-MM-DD
?lat
La latitud (coordenadas) de cada elemento en formato decimal
?long
La longitud (coordenadas) de cada elemento en formato decimal

Si se quisiera visualizar en un mapa las ciudades que cuentan con una población superior a los 5 millones de habitantes, se podría hacer la siguiente consulta en la DBPedia:

 PREFIX dbpprop: PREFIX dbpowl: PREFIX foaf: PREFIX rdfs: PREFIX geo: SELECT ?title ?description ?link ?lat ?long WHERE { ?place a dbpowl:PopulatedPlace; rdfs:label ?title; dbpprop:populationTotal ?description; foaf:page ?link; geo:lat ?lat; geo:long ?long; dbpprop:populationTotal ?population. FILTER (?population > 5000000) FILTER langMatches( lang(?title), "en" ) } 

En este ejemplo se hace la consulta de las ciudades, con su información geoespacial y en la descripción aparecerá la población. Posiblemente no aparezcan listadas todas las ciudades del mundo que cumplan ese criterio, esto podría ser debido a que la DBPedia no contiene toda la información buscada (por ejemplo, la latitud y longitud exacta de ciertos lugares).

  1. Consulta el resultado en HTML o en XML (llamadas al SPARQL endpoint).
  2. Se convierte a formato GeoRSS.
  3. Por último, se visualiza en el mapa la información en formato GeoRSS

, ,

No hay Comentarios