Los planteamientos de Daniel Torres Burriel sobre cómo ve él las iniciativas Open Data desde su perspectiva de un diseñador, que son de lectura obligada para comprender lo que viene a continuación, me dan pie a iniciar una conversación sobre un tema que ya me había planteado en varias ocasiones: la relación entre el Open Data y el mundo de los diseñadores, así como las oportunidades de interacción y colaboración entre ambos.
Empiezo pues agradeciendo a Daniel el haber abierto el debate público sobre la materia y a continuación paso a expresar mis opiniones en cuanto a sus comentarios:
PDFs: El cementerio donde reposan los datos
Creo que nadie duda de ello, si bien es cierto que se sigue (y se seguirá) publicando información en PDF, mucha, claramente demasiada. El origen de este fenómeno suele ser que toda esa información normalmente ya estaba previamente en ese formato, ya que durante muchos años los PDFs fueron la forma cómoda (y pésima) de crear contenidos para las Webs de la Administración.
Pero, aunque siempre será algo mejor tener datos públicos en un mal formato que no tener ningún dato publicado, esto no debería ser tomado nunca como una solución definitiva, sino como una mera transición para publicar inmediatamente la información disponible a la vez que se trabaja en la mejora de esos formatos. El problema surge cuando lo que debería ser una solución (muy) temporal se convierte en el formato final y es entonces cuando los PDFs se convierten en el lugar a dónde van a morir los datos.
Modelos de representación de los datos
No tengo claro si he entendido bien el concepto de lo que propones como interfaz de consumo, por eso no estoy seguro de si es algo que realmente ya existe o algo que habría que hacer o si simplemente lo que pides es imposible.
Tal y como yo lo veo, cualquier dato que se exponga al final no es más que un dato, lo que al final sumará multitud de datos de las más variadas fuentes y dominios de información. Sí lo que pides es unas pautas generales de presentación de datos me atrevería a afirmar que eso es imposible más allá de todo el compendio que existe ya sobre el tratamiento general de la información y su visualización, pero eso también es una ciencia por sí misma que hay que saber aplicar en cada caso para saber sacarle partido a la información y aflorar las historias que esconde.
No hay más reglas ni puede haberlas. Si no lo he entendido bien por favor ayúdame a interpretarlo mejor, porque me encantaría poder buscarle una solución.
Los datos como entidades vivas
Sin lugar a dudas los datos son entidades vivas, y además existe cierta relación directa entre la frecuencia de actualización de los datos y su valor, es decir, generalmente los datos más vivos y que por su naturaleza se actualizan con mayor frecuencia son los que pueden aportar un mayor potencial en cuanto a beneficio social y económico.
Esa realidad se debe reflejar en los sistemas que gestionen los datos, pero el hecho de que un conjunto de datos se presente como fichero no quiere decir que ese datos estén condenados a la estaticidad de por vida. Al fin y al cabo un fichero tan solo refleja el estado de ese conjunto de datos en un momento determinado y por tanto podría ser también una solución válida aquella que aportase un fichero por cada versión de los datos, siempre que se combinase con un sistema adecuado de gestión de versiones, a través de una configuración apropiada de las URIs por ejemplo.
Cuestión aparte es que hay ciertos datos especialmente dinámicos a los que se les podría sacar mucho más partido a través de una API, e intuyo que por ahí van tus peticiones. En eso no puedo más que coincidir, con un algunos de matices:
- Una API podría no ser siempre la mejor opción.
- Para cumplir con los principios del Open Data esa API debería ser un complemento y nunca un sustituto del acceso completo a los datos en bruto.
- Habrá que seleccionar cuidadosamente cuáles son los datos que se abren por este medio, ya que crear y mantener una infraestructura que de soporte a ciertos datos especialmente dinámicos puede resultar bastante caro, y por supuesto estaríamos hablando de dinero público.
Patrones de datos
Nuevamente no se si el concepto de patrón de diseño se podría aplicar a la explotación de los datos, está claro que sí debe aplicarse, y de hecho ya se hace, para el diseño de los modelos de datos, pero precisamente el potencial de la explotación de los datos se basa en que no hay patrones establecidos y la creatividad y la imaginación con los que somos capaces de combinarlos son los únicos elementos que definen los límites.
Evidentemente para poder sacar provecho de esos datos habrá que tener ciertos conocimientos que provienen de distintas disciplinas (cálculo, estadística, bases de datos, algoritmos, programación, visualización, etc.) que en conjunto se vienen denominando Data Science, y por supuesto contando siempre también con especialistas de la materia en cuestión que se esté tratando en cada momento (sanidad, educación, transportes, medio ambiente, etc.)
Lo que si que es cierto es que en general existe una ausencia muy preocupante de los famosos “code books“ que deberían acompañar siempre a cualquier conjunto de datos para facilitar su explotación. Cuando tratamos con datos muy simples con estructuras mínimas es fácil que con poco esfuerzo cualquiera deduzca esas estructuras y pueda sacarles partido, pero en la mayoría de casos intentar hacer algo productivo con unos datos en crudo que no cuentan con ninguna documentación puede evolucionar fácilmente hacia una misión imposible, o cuando menos conllevará unos considerables esfuerzos superfluos que se podrían y deberían haberse evitado fácilmente.
La crítica final
Me alegra ver que todo el mundo esté últimamente ávido de datos, pero las iniciativas Open Data son carreras de fondo en la que hay que seguir una serie de pasos, entre los cuales se encuentra la necesidad de proporcionar un catálogo para que la información salga de los archivadores y los discos duros de la administración y se haga visible a todo el mundo.
Por muy poco acertada que pueda acabar siendo una iniciativa Open Data en su ejecución, que las hay, creo que llegar a compararlo con el despotismo ilustrado podría ser cuando menos un poco exagerado. Sobre todo si tenemos en cuenta que en este caso el Gobierno de Aragón lleva ya bastante tiempo trabajando tanto internamente, impartiendo formación a sus servidores públicos, como externamente llamando a la participación de todo el mundo, además de haber mostrado en repetidas ocasiones su voluntad de seguir haciéndolo en el futuro próximo.
Está claro que la colaboración entre todos los agentes implicados (Gobierno, Ciudadanos, Empresas, Profesionales, Universidad, etc.), incluyendo por supuesto a los diseñadores, es una herramienta fundamental para el éxito del Open Data, y por eso sería estupendo que el evento UX de referencia en España, al que acudirán muchos de esos diseñadores, adoptase un modelo más flexible, participativo e inclusivo,que las tradicionales conferencias y mesas redondas para abrirse más a la colaboración e intercambio de ideas con otros profesionales, como por ejemplo los del mundo del Open Data.
Personalmente me gustaría saber más sobre las inquietudes de diseñadores y profesionales de la UX acerca del Open Data, puesto que además ya forman parte de él cuando aplican RDFa, schema o microdatos a los diseños Web por ejemplo, pero es que si nunca hablamos, y cuando lo hacemos no es de forma constructiva, difícilmente nos vamos a poder entender.
Hola Carlos.
Para no dejar morir el debate, te aporto en este comentario mis impresiones acerca de los comentarios de tu post en los que parece que falta un poco más de luz a la vista de mis argumentos.
En relación al modelo de representación de datos, que yo llamé “interfaz de consumo”, lo que quería decir esa precisamente eso, algo que facilite a los usuarios finales el consumo de los datos a través de las posibilidades de éstos. Me explico. Se trata de algo parecido a lo que utilizamos cuando hablamos de patrones de diseño, es decir, guías, directrices, modelos, ejemplos, origen de los datos, y en general toda la información de contexto que explique la procedencia, método de obtención, tratamiento y/o gestión de los datos desde su origen hasta el momento en el que quedan abiertos. Para hacerlo un poco más comprensible: unos meta-datos enriquecidos que aporten la información de contexto tanto del dato como de su gestión hasta que quedan abiertos. ¿Para qué? Para aportar esa información al ciudadano, pero también a quienes quieran “hacer cosas” con esos datos, y éstos sean de ese modo algo más que datos. No se si me explico.
Por otra parte, cuando hablo de patrones no quiero decir, y ahí no me he expresado nada bien, de proponer cómo mostrarlos o cómo tratarlos, sino que desde el origen de los datos sería interesante conocer cómo se han utilizado, para qué, cuándo, de qué forma… A eso es a lo que me refiero con la expresión “modelos de utilización”. No tiene por qué implicar que los datos deban ser así tratados, sino que se trata simplemente de explicar cómo se han utilizado hasta la apertura.
Y por último, la crítica final, como todo mi post, se trata de un elemento que debe ser valorado tal y como lo describo: se trata de una impresión desde el exterior. Y efectivamente, yo que asisto desde el exterior a este show no puedo decir otra cosa que no sea que lo percibo como un bienintencionado ejercicio que deriva en autobombo. Es mi impresión que, ni tiene por qué ser compartida, ni pretendo que sea aceptada. Es sólo mi impresión.
No entraré a valorar el uso de expresiones más o menos compartidas. De verdad. Poner un foro de discusión que tiene 4 hilos de conversación (y no es metáfora, sino real) y organizar un evento de presentación (en el caso de Aragón Open Data) cerrado al público me parece francamente mejorable.
Aunque insisto en que me parece mejor eso que nada, pero saber aceptar las críticas razonadas también es un ejercicio para el debe de los responsables de todo esto.
Hola Daniel,
Después de que lo que comentas me reafirmo en que lo que estás reclamando cuando hablas de interfaces de consumo y modelos de utilización es básicamente una mejor documentación de los datos, y en eso también tengo que darte la razón. Generalmente, y salvo honrosas excepciones, los datos suelen estar muy mal documentados y no se hace uso de la buena costumbre que supone adjuntar el utilísimo “code book” correspondiente a cada conjunto de datos.
Para muestra un botón, sólo hace falta ver los datos comparativos de centros hospitalarios en EEUU por ejemplo con toda su completa descripción de variables, fuentes, periodos de captura, etc. http://www.medicare.gov/HospitalCompare/Data/AboutData/About.aspx y luego ir a descargarlos al Catálogo de EEUU y ver que vienen con su completa documentación de casi 40 páginas http://www.healthdata.gov/data/dataset/hospital-compare Así da gusto, aunque estaría todavía mejor si la documentación estuviera también referenciada como metadato independiente en el catálogo.
En cuanto a las críticas a mi siempre me parecen útiles, tan sólo quise matizar que si además de argumentadas se presentan de una manera positiva es más fácil que se tengan en consideración y sean apreciadas. Hay que recordar que detrás de cada proyecto hay una serie de personas, y por mi experiencia en proyectos Open Data podría asegurar que lo que tienen prácticamente todos en común es la implicación e ilusión de aquellos que los llevan a cabo. A veces salen bien y otras no tanto, pero en este último caso suele ser por decisiones que se toman a otros niveles, no por la voluntad de la gente que está directamente implicada.
En el caso de Aragón, tal y como se confirma con el comentario de José María Subero, yo veo una voluntad real y manifiesta de mejorar, colaborar y abrirse a la participación. El que se haga un evento de presentación interna me parece lógico, necesario y normal, porque se ha demostrado que la difusión y “evangelización” en este tipo de proyectos es tan necesaria de puertas para afuera como hacia adentro, y la aproximación en ambos casos puede diferir en varios aspectos. Estoy seguro de que habrá más eventos, tanto internos y externos, como de colaboración, de hecho tenéis una oportunidad estupenda de colaborar organizando algo el próximo Open Data Day (23 Febrero) y montar algún tipo de coloquio informal para hablar de estas cosas. Y por cierto, si este debate lo hubieras llevado al foro de discusión ahora ya tendría 5 hilos y al menos uno de ellos bien interesante.
Un saludo y gracias por alimentar el debate.
hola a los dos,
Lo primero que me gustaría es daros las gracias por preocuparos por el estado de los datos abiertos y por usar vuestro tiempo en compartir vuestras opiniones públicamente.
Por la parte que me toca tras haber estado coordinando técnicamente la puesta en marcha del proyecto de datos abiertos del Gobierno de Aragón me gustaría añadir un par de cosas. Respecto al tema del interfaz del consumo, lo primero que me gustaría explicar es que los datos no son homogéneos en el origen. Diferentes departamentos tienen diferentes formas de presentar sus datos, esto puede suceder tanto por las propias características de los datos de los departamentos como por el propio orden interno de los departamentos. Para poder manejar esto lo que se ha creado es una estructura de metadatos común a todos los datasets, que la hemos basado en el vocabulario DCAT que es el estandar que se está eligiendo a nivel europeo. La estructura de los metadatos está explicada dentro de la Web en el siguiente enlace:
http://opendata.aragon.es/i/estructuraMetadatos.pdf
Además, dentro de esta estructura existen campos específicos (Propiedad RDF ) donde se pueden explicar las características específicas de cada uno de los dataset.
En cuanto a mejoras de interfaz te puedo adelantar que estamos trabajando para que algunos de los datos se puedan previsualizar antes de ser descargados, en principio estamos motando previsualización sobre formatos XLS y CSV además de sobre los formatos cartográficos, pero no se hasta donde podremos llegar porque las fuentes son muy diversas y muchas veces los datos no están georreferenciados (una previsualización por ejemplo con un polígono de todo Aragón como ámbito de cobertura entendemos que tampoco tiene mucho sentido). Además para mejorar el tema de la diversidad de las fuentes también nos estamos pensando como montar una capa que permita devolver diferentes estructuras de mismos formatos en iguales estructuras de iguales formatos, lo cual debería simplificar el tema de la interfaz al usuario, pero este problema no es trivial y veremos hasta donde podemos llegar.
Respecto a lo que se comenta de modelos de utilización tal y como se explica en este post, en efecto, no se muestran modelos de utilización. Muchas veces estos no existen, ya que la propia información se crea para ser mostrada y otras veces no existe una trazabilidad sobre los propios datasets y su utilización. Sería interesante poder contar con un elemento de trazabilidad de los datos
Respecto al tema del componente orgánico y la actualización estamos de acuerdo, el descargable que se ofrece debe ir cambiando a medida que se modifica. Pienso que el dato que se debe ofrecer es el actual y aunque el histórico también tiene interés, ahí están los reutilizadores para ir haciéndose sus bibliotecas de datos, aunque esto es una opinión personal.
En este punto creo que es importante entender que la web pretende ser un catálogo y, por tanto sirve para recoger, abrir y mejorar la información del Gobierno de Aragón (y de otras entidades que quieran utilizar este canal como forma de publicar sus datos). Es decir, en el 99% de los casos la información ya existía antes de open data, era muy diferente y en cada lugar las metodologías y estructuras que se seguían pueden ser desde muy complejas hasta inexistentes. Por ello, parte del trabajo, tal y como lo hemos entendido pasa por dotar de una estructura mínima que permita buscar por igual toda la información, al margen de ayudar e intentar hacer ver donde se puede mejorar la información.
Por último, respecto al tema central sobre el que se articula esta discusión también me gustaría decir que somos bastante conscientes de que el producto que estamos ofreciendo tiene carencias, sabemos que se puede mejorar tanto tecnológicamente, como legalmente como en los contenidos y en esto estamos trabajando. Los recursos y apoyos que tenemos son los que son, por supuesto nos gustaría contar con más y que hubiera más persona implicadas, pero también creo que el punto de partida ha sido bastante digno y en este punto me gustaría poner en valor la aplicación de visualización de presupuestos que hemos sacado como ejemplo de reutilización de datos y que habla por si misma (http://presupuesto.aragon.es/). Evidentemente, sabemos que no se puede contentar a todo el mundo y aceptamos las críticas razonadas de buen grado, que ha habido algunas, de hecho de las críticas razonadas son de las que más estamos aprendiendo y por eso son bienvenidas. Además, realmente tampoco creo que estemos tan en desacuerdo sobre el fondo del tema.
De verdad, muchas gracias por molestaros por el tema
Hola José,
Lo primero felicitaros porque como ya he comentado anteriormente creo que habéis conseguido sacar un catálogo simple, directo y práctico que además tiene “personalidad propia”, lo que no es fácil con el número de iniciativas que existen ya en marcha.
Creo que la poca documentación existente sobre los conjuntos de datos (me refiero a documentación sobre su naturaleza, no a los metadatos que los describen) es un problema general que tenemos que sufrir en prácticamente todas las iniciativas, pero como bien apuntas viene heredado de las distintas fuentes originales y poco se puede hacer en el catálogo para remediarlo, ya que su función es recopilar y catalogar.
En cuanto a descripción que haces de la ejecución de la parte técnica me surgen algunas dudas. Está muy bien utilizar DCAT para los metadatos y documentarlo, pero como no encuentro ninguna otra documentación al respecto me preguntaba si tenéis también definido algún esquema de URIs y si utilizáis la negociación de contenido para servir el RDF en base a las peticiones de los agentes de usuario, ya que sin esquema de URIs implementado ni negociación de contenido habilitada la utilidad del DCAT es bastante limitada, puesto que la verdadera finalidad del RDF, y lo que lo distingue de otros formatos como el XML, es que el contenido sea a la vez “autodescriptivo” y “autodescubrible”, condiciones ambas necesarias para que el concepto del “Linked Data” se haga realidad y funcione. Si no hay esquema de URIs implementado y funcionando mediante negociación, la segunda condición se cae, por lo que ese RDF perdería gran parte de su valor.
Por otro lado la ausencia de un esquema de URIs estable y documentado desde el comienzo del proyecto daría lugar a que la reutilización automatizada sea técnicamente más complicada, y eso se pondría claramente de manifiesto sobre todo cuando el catálogo vaya creciendo y además empecéis a tener la necesidad de versionar los conjuntos de datos para mantener el histórico, que en este caso discrepo claramente contigo, debe ser siempre mantenido por el propio catálogo.
En cualquier caso, enhorabuena por haber sacado adelante el proyecto y por las mejoras que tenéis previstas en cuanto a visualización y demás. Seguiremos de cerca su evolución.
hola Carlos, intento contestarte aunque hayan pasado ya unos días
Lo primero que me gustaría resaltar es que como Gestor de Contenidos estamos usando CKAN, que por lo que conocemos es el único gestor de contenidos creado específicamente para la gestión de datos abiertos. Es un desarrollo de la OKF que siguen evolucionando y documentando; en nuestro caso hemos instalado la versión 1.8. Al trabajar sobre este producto, en lo que se refiere a las URIs que vamos generando se crean a partir del identificador que se otorga a cada dataset, que es el nombre del propio dataset. Esto se realiza según la estructura de URIs propia de CKAN, que nos pareció válida para seguir en su momento.
Sin embargo la parte interesante de haber trabajado con CKAN viene de la utilidad del API, existe documentación en la siguiente dirección (http://docs.ckan.org/en/ckan-1.5/api.html) y a falta de que elaboremos nuestra propia documentación en español y que la subamos a la web puede ayudar bastante. Ahí se ven todos los parámetros de consulta que se pueden realizar, diferenciando en 2 APIs, una que devuelve la id de la versión concreta de los dataset y que permite ver, por ejemplo, si existen actualizaciones del dataset (versión 2 del API) y otra que devuelve un id “público”, permanente y reusable con la parte final del URI de cada dataset (versión 1 del API, por defecto).
Espero que con esto se pueda trabajar mejor y, como te comento, seguimos trabajando para mejorar la documentación de las opciones que facilita nuestro portal.
Hola José, es estupendo poder contar con las capacidades de importación y exportación de metadatos y datasets a través de la API de CKAN, a ver si en un futuro os animáis también con el tema de la negociación de contenido para servir el RDF del DCAT y gestionar el versionado y así poder añadir capacidades Linked Data al catálogo.
Está claro que estáis trabajando un montón y seguro que continuaréis añadiendo mejoras poco a poco, así que habrá que seguiros atentamente.
Un Saludo!