El momento de los Servicios Abiertos

Ya hemos defendido antes la necesidad de generar lo que hemos llamado una Infraestructura Digital Pública (IDP), sugiriendo que los gobiernos deberían avanzar en proporcionar a los ciudadanos capacidades digitales abiertas, libres de restricciones, para que podamos hacer con ellas lo que se nos ocurra, siempre que estemos dentro de la ley. Estas capacidades estarían montadas sobre una infraestructura física nacional y, esencialmente, incluir datos, servicios, software y conocimiento.

Se ha escrito mucho en los últimos años sobre datos abiertos. El crecimiento de sus partidarios y un creciente apoyo de los gobiernos (principalmente desde el punto de vista de la transparencia, pero también buscando proporcionar infraestructura), hacen que el futuro de los datos abiertos sea, por lo menos, promisorio. Probablemente en diez años el ermino “datos abiertos” ya no se utilizará. Los “Datos cerrados de gobierno” serán la principal preocupación, porque los datos públicos serán, por defecto, abiertos.

En el camino del desarrollo de la IDP, proponemos ir un paso más allá y avanzar hacia Servicios Abiertos de Gobierno.

Bus Stop - Vince Alongi, Flickr - CC-BYLa definición de Servicio Abierto de Gobierno que proponemos es ligeramente diferente a la propuesta para [Servicio Abierto de Software] propuesta por la OKFN. Mientras los Servicios Abiertos de Software pretenden ser la versión “open source” de los servicios en línea, los Servicios Abiertos de Gobierno son más la versión servicio de los Datos Abiertos: servicios en línea para exponer datos y realizar cómputo, sin restricciones y con resultados verificables.

Veamos un ejemplo como motivación. En Montevideo, los horarios de buses son abiertos. Es posible saber, para cada línea de ómnibus, sus tiempos de partida y llegada a ciertos puntos de control (los relojitos en la figura). Para el software que hemos desarrollado para usuarios finales, hemos estimado, además, los tiempos previstos de arribo a cada parada intermedia entre los puntos de control, utilizando una regla de tres simple. Si alguien quiere desarrollar un sistema similar, debería bajar nuestros datos abiertos e implementar la regla de interpolación. No demasiado difícil. Así es cómo funcionan los datos abiertos después de todo, ¿o no?

Sí, así funcionan. Pero, si vemos el problema desde el punto de vista de un desarrollador de software, algo luce subóptimo. ¿Por qué bajar los datos? Y, más importante aún: ¿por qué replicar un algoritmo que alguien ya desarrolló? Si nosotros, como gobierno de la ciudad, publicásemos un servicio abierto que, dada una línea y una parada, retornase el tiempo estimado de arribo, sería mucho más fácil desarrollar una aplicacción para los ciudadanos de Montevideo (algo que es, después de todo, la razón por la que liberamos los datos). De hecho, esto es exactamente lo que está comenzando a suceder. Luego de que basamos nuestra aplicación “A qué hora pasa?” en servicios RESTful (incluso cuando no publicamos su especificación), una aplicación de terceros ya los está usando, y sabemos que hay algunas otras en camino.

Hay algunas características adicionales de los datos que hacen que los Servicios Abiertos sean no solamente convenientes, sino además necesarios:

  • Datos en tiempo real: esto es información que se despacha inmediatamente de recogerse. Consideremos, por ejemplo, los horarios de arribo de bueses de Transport for London. La aproximación con datos abiertos no es plausible: uno de las características más importantes de estos datos es su disponibilidad inmediata. De hecho, el sitio web de transporte de Londres incluye una sección para desarrolladores que provee servicios para verificar la hora de arribo.
  • Big data: tomemos aquí a “Big Data” como lo opuesto a small data: los datos que no pueden guardarse y procesarse utilizando un sólo laptop o servidor. Se supone que los datos abiertos deberían hacer las cosas más fáciles a la gente; si se necesita una supercomputadora para analizar datos abiertos, entonces ya no son abiertos. Un buen ejemplo es la enorme sección de datos del National Climatic Data Center; si no fuera por sus servicios, el acceso a los datos sería casi imposible.

Como vimos, ya existen varios ejemplos de servicios sobre datos abiertos. Sin embargo, deberíamos comenzar a pensar no solamente en servicios sobre datos abiertos, sino directamente en servicios abiertos. Igual que como se hizo con los datos abiertos, sugerimos los siguientes principios para los Servicios Abiertos:

  • Los Servicios Abiertos deberán basarse en datos abiertos. Los servicios abiertos nunca deberían sustituir a los datos abiertos. Nunca. Su propósito es hacer las cosas más fáciles, no impedir el acceso.
  • Los Servicios Abiertos deberían ser verificables. Como los Servicios Abiertos incluyen datos abiertos y algoritmos, deberíamos tener una forma de verificar que los resultados coinciden con lo que se espera, y no son modificados durante su procesamiento. La forma más obvia es publicar el algoritmo y los procesos además de los datos (en el caso de los buses, el algoritmo de interpolación). Pero también podría haber otras formas de verificación: en el caso de los datos en tiempo real, podríamos simplemente verificar que el bus está dónde el servicio dice, yendo hasta el lugar.
  • Los Servicios Abiertos deberían ser abiertos para todos, sin limitaciones, excepto por razones de seguridad. Sin registros, sin justificación. Exactamente el mismo principio que aplicamos para los datos abiertos.
  • Los Servicios Abiertos deberían ser accesible con estándares abiertos, sobre los que ninguna entidad tenga control absoluto.(*).

Los gobiernos están abriendo nuestros datos. Los gobiernos están abriendo nuestro código. Es tiempo de abrir nuestro código aplicado a nuestros datos. Es tiempo de Servicios Abiertos.

(*) Estuve tentado a agregar: “y utilizando servicios RESTful”, pero la gente de la web Semántica no estaría contenta, y tengo amigos ahí.