Mejora del acceso a la Administración mediante un mejor uso de la Web

Al inicio del año 2007, CTIC Centro Tecnológico, sede de W3C en España, propone a W3C la creación de una actividad mundial específica sobre administración electrónica con el fin de identificar los retos más importantes que las administraciones públicas de todo el mundo encuentran a la hora de utilizar la Web, así como desarrollar buenas prácticas para optimizar el uso de la Web en el contexto de la administración electrónica.

La actividad mundial sobre administración electrónica (eGovernment) de W3C, liderada por CTIC, cuenta en la actualidad con un grupo de trabajo compuesto por más de 200 personas procedentes de más de 25 países que representan a administraciones públicas locales, regionales, nacionales, supranacionales, ONGDs, ciudadanos, universidades yempresas del sector privado.

Ver la publicación

Políticas de uso de servicios de participación ciudadana en el contexto de las Administraciones Públicas

En estos últimos años, la Web se ha transformado. La Web 2.0 permite que usuarios y usuarias interactúen con el propio portal o entre sí, por lo que resulta impensable mantener un portal cerrado. Quienes lo usan exigen participar, aportar información, comunicarse con personas afines, etc.

Las Administraciones Públicas que se plantean abrir servicios participativos tienen dudas sobre si realmente se puede confiar en quienes usan sus aplicaciones para cederles parte del control de la información.

En esta publicación se describe la metodología de análisis de servicios Web participativos desarrollada para el Gobierno del Principado de Asturias , dando cobertura a los principales riesgos a los que puede tener que enfrentarse una Administración Pública a la hora de establecer o gestionar servicios de este tipo.

Ver la publicación

¿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.

• 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.

La Tierra, nuestro planeta madre, una pieza fascinante del Universo para todos nosotros, incluyendo al Profesor Otto Lindenbrock. Viaje al Centro de la Tierra (de Julio Verne, 1864), sigue una trama en la que el Profesor Lindenbrock está fascinatado e incrementalmente entusiasmado por los mensajes ocultos en criptogramas escritos en un idioma extraño (rúnico) y los tesoros que se puedan encontrar tras ellos. Descifrar cada mensaje le lleva a él (su sobrino Alex, y su doncella Marta) un paso más cerca del centro de nuestro planeta donde se supone que esos tesoros se encuentran escondidos; pero, ¿cómo llegar hasta allí?

Para llegar al centro de la Tierra (el núcleo), uno tiene que atravesar varias capas, concretamente la corteza y el manto. Esas capas son muy difíciles de traspasar (es casi imposible pra ellos), pero su interés en conocer un poco más a cada paso y las cosas fascinantes que les podrían estar esperando, les animan a superar todo tipo de situaciones difíciles.

El punto de partida del viaje se esconde tras el primer mensaje: Snæfellsjökull, un volcán en Islandia. De hecho, puntos de partida prometedores deberían ser aquellos como los volcanes y los cráteres, en los que uno puede atravesar varios kilómetros “sin demasiados problemas”. El grupo tiene que resolver varios enigmas a lo largo del camino para seguir adelante. Recordad, no estaban seguros de lo que les aguardaba al final del mismo. Después de todo, no lo podían ver desde el exterior. Desde la corteza, son 6.000Km hasta el núcleo.

Volvamos al “mundo real” por un momento (después de todo, el libro es de ciencia ficción, ¿o no?). Digamos que el núcleo son los datos y que todas las capas que los envuelven son las estructuras de la Administración que envuelven a los datos para preservarlos, protegerlos, gestionarlos y (demasiado a menudo) para oscurecerlos. Pensad en departamentos TI, de seguridad y en cada artefacto organizacional que tenga algo que ver con los datos.

Ya que estamos aquí, ¿por qué no alejarse unas cuantas capas hacia arriba? El Planeta Tierra es sólo uno en una galaxia y no es el único con esta estructura. Si uno echa un vistazo a otros como Marte, la estructura es casi la misma, un núcleo y varias capas rodeándolo. Lo mismo ocurre con Mercurio, y con muchos más, incluso las lunas y satélites de los planetas parecen seguir una estructura similar. Algunos tienen un núcleo mayor que otros, algunos tienen más capas entre el núcleo y la corteza pero, en general, el fenómeno se repite.

De vuelta a nuestro contexto de administración, gobierno e información pública, reconocemos el patrón. Algunas administraciones producen más datos que otras. Algunas estructuras son más complejas que otras dependiendo del gobierno del que hablemos. Algunos gobiernos tienen más departamentos, agencias (llámalo como quieras) entre los datos y la corteza o, más concretamente, entre los datos y el pueblo. Sí, el pueblo, ahí afuera, sobre la corteza, la mayoría de ellos (nosotros) sin ni siquiera imaginar lo que el núcleo atesora.

Ha habido momentos en la historia en los que la Tierra y otros planetas han experimentado sucesos importantes, algunos de ellos bastante traumáticos, como las colisiones de meteoritos. Esto ha llevado a cambios en su estructura y también a la evolución.

Por fortuna, algunos de nosotros, el pueblo, estamos recomendando encarecidamente a las administraciones que hagan lo debido: liberar los datos del pueblo. No hablo de los sospechosos habituales opacos (datos relacionados con la seguridad nacional, con la privacidad, y similares) si no de todos aquellos datos escondidos entre demasiadas capas por ninguna razón aparente nada más que no publicarlos “por si acaso”, lo que he llamado en varias ocasiones “oscuridad por defecto“. Las cosas están cambiando de forma interesante a lo largo y ancho del mundo en el último año o dos, el gobierno está comenzando a abrir sus puertas. Las capas se están haciendo más transparentes, y la dificultad de “encontrar un volcán” por donde empezar or descifrar un enigma se convierte en algo menos necesario. Los volcanos y cráteres están por todas partes, incluso empiezan a aparecer algunos caminos pavimentados hacia el núcleo.

Aún hay mucho que hacer en el sentido de cómo mejorar los procedimientos, cómo facilitar el acceso a los datos, cómo hacer que puedan enlazarse de forma que los interesados puedan reutilizarlos, mezclarlos, visualizarlos del modo que les apetezca. El Planeta Tierra es sólo uno en una galaxia, en el Universo, pero como Charles Eames dijo: “al final, todo conecta”.

Pensad a lo grande y recordad, liberar los datos del pueblo significa devolvérselos a sus verdaderos propietarios. ¿No es eso una cosa maravillosa?

Aunque no nos es posible asistir a todos, este mes de Noviembre haremos unos pequeños altos en nuestros proyectos para participar en los siguientes eventos:

• Visualizar ‘09: Datos públicos, datos en público (12 Nov)
  • José Manuel Alonso presentará: “Hacia una Nube de Datos Públicos Enlazados“.

• FICOD ‘09 (19 Nov)
  • Carlos de la Fuente participará en la mesa redonda “O-gov: generando valor a través de la reutilización de la información del sector público“.

• Personal Democracy Forum Europe (21 Nov)
  • José Manuel Alonso participará en la mesa redonda “Transparency and Participation: Changing the Equation“.

Por supuesto, publicaremos las ponencias a la vuelta de nuestros viajes, si no antes. Atentos a nuestra cuenta en Slideshare, también enlazada desde este blog. Algunos eventos como Visualizar ‘09 tendrán streaming de vídeo en vivo. Para más información, seguid los enlaces de arriba. Y, por supuesto, si asistís, no dudéis en saludarnos. Siempre encantados de compartir unos minutos.

Hemos modelado la oferta de formación ocupacional del Servicio Público de Empleo del Principado de Asturias. Se resume en tres datasets: las acciones formativas (o cursos), los centros donde se imparten dichos cursos, y las organizaciones que imparten dichos cursos. Éstos a su vez constituyen un super-dataset.

Hemos trabajado con una foto de los datos que tomamos en Julio de 2009. Te puedes descargar todos los datos en RDF/XML en bruto (como pedía Tim Berners-Lee con su Raw Data Now!). Pero hay más formatos, o como parece ser el estándar de facto:

Por supuesto, también tienes nuestro SPARQL endpoint para filtrar los datos a tu antojo y, si te preguntas como interpretarlos, está también disponible el vocabulario que hemos utilizado para modelar toda la oferta formativa.

Para acabar, por ahora, también hemos creado algunas visualizaciones de ejemplo, en las que puedes filtrar los datos visualmente y ver los resultados en un mapa, una línea de tiempo e incluso descargarte los cursos que te interesen a tu calendario (en formato iCal).

visualizaciones de los datos en mapa, línea de tiempo y calendario

¿Quién da más? Nosotros. Hay mucho, mucho más que contar sobre estos datasets, y muchas más cosas en las que estamos trabajando intensivamente. Atentos a los próximos artículos.

Descripción del ejemplo

Desarrollo de una aplicación web Java que liste los catálogos de datos públicos disponibles y genere un mapa señalando su localización. El listado de catálogos se obtendrá realizando una consulta a un SPARQL endpoint.

Tecnologías necesarias

• Jena: Ofrece una API que permite trabajar y realizar consultas sobre modelos o grafos RDF.
• ARQ: Entre otras cosas, su API permite realizar consultas a servicios SPARQL remotos.

Implementación

Paso 1: Se define la consulta SPARQL que devuelve el conjunto de datos que necesitamos y se ejecuta contra el SPARQL endpoint:

QueryExecution qe = QueryExecutionFactory.sparqlService(sparql_enpoint_uri, query);
ResultSet rs= qe.execSelect();

La consulta que se ha ejecutado es:

prefix ds: <http://data.fundacionctic.org/vocab/catalog/datasets#>
prefix  dcterms: <http://purl.org/dc/terms/>
prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>
prefix foaf: <http://xmlns.com/foaf/0.1/>  
SELECT * FROM <http://data.fundacionctic.org/dataset-catalog>
WHERE {
 ?catalog a ds:Catalog;
 dcterms:spatial ?uriGeonames;
 dcterms:description ?description;
 rdfs:label ?name;
 foaf:homepage ?homepage.
 FILTER langMatches( lang(?name), 'es' )
 FILTER langMatches( lang(?description), 'es' )
}

Este es el SPARQL endpoint sobre el que se ha ejecutado la consulta.

Paso 2: Una vez obtenidos los datos se recorre el conjunto de resultados y para cada uno de ellos se recupera su nombre, descripción, URL de su homepage y el identificador del recurso de Geonames que indica su localización.

A continuación se obtienen los datos del recurso de Geonames para obtener los valores necesarios para la geolocalización:

Model m = ModelFactory.createDefaultModel();
m.read(uri_geonames_resource);
// creación de las propiedades para obtener la latitud y la longitud
Property lat = m.createProperty("http://www.w3.org/2003/01/geo/wgs84_pos#", "lat");
Property lon = m.createProperty("http://www.w3.org/2003/01/geo/wgs84_pos#", "long");
// obtención del valor de las propiedades
Resource geoName = m.getResource(uriResource);
lat= geoName.getProperty(lat);
lon= geoName.getProperty(lon);

Paso 3: Se muestra el listado de catálogos y se crea un mapa utilizando la API Javascript de GoogleMaps en el que se muestra su localización.

var map = new GMap2(document.getElementById("map"));
map.setCenter( new GLatLng(0,0), 1);
// para cada punto se genera un "marker"
var point= new GLatLng( lat, lon );
map.addOverlay(marker);

En estos tres sencillos pasos se ha implementado una aplicación que combina recursos remotos para obtener datos y genera una visualización en un mapa. Este es el resultado obtenido