3. Ecosistema de Datos en la Web

3.1 Actores y Papeles

La Web de Documentos es básicamente utilizada por dos tipos de usuarios: aquellos que publican y aquellos que consumen. El primer navegador creado por Tim Berners-Lee permitía no sólo el acceso a un documento a través de la especificación de una URL, sino también que el usuario editase esa información y la grabara, del mismo modo de lo que ocurre hoy con la Wikipedia. De esa manera, una misma persona, un mismo actor de este ecosistema, podía contar con duplicidad de papeles: consumidor y publicador de datos. Sin embargo, como regla general, vemos a esos dos papeles desempeñados por grupos de personas diferentes: un conjunto de personas tiene la tarea de publicar documentos, y otro conjunto de personas tiene interés en acceder a tales documentos. Esos dos papeles, a su vez, pueden subdividirse en conjuntos de papeles más específicos.

Para ilustrar la diversidad de papeles en el ámbito de la publicación de datos, utilizaremos una analogía entre la Web y el mundo de los libros. En dicho mundo existen dos tipos básicos de papel: los escritores y los lectores. Para que un lector pueda acceder a un texto creado por un escritor, es necesario que el escritor publique el libro. Tenemos entonces un abanico de nuevos papeles, todos ellos agrupados bajo un gran rótulo, al que denominaremos "los publicadores". Entre los publicadores tendremos, además de al propio escritor, a personas responsables de garantizar que, a partir de un texto creado por una persona, sea posible imprimirlo y distribuirlo, de modo tal de que llegue a los lectores. Se necesita de personas que se encarguen de la infraestructura de publicación, de la promoción, de la distribución, de diseñadores para la tapa del libro, de quien decida el tipo de papel, la fuente, los formatos de publicación, etc., hasta que el texto finalmente llegue a las librerías para su venta a los lectores. Es sencillo tomar conciencia de que existen distintos actores desempeñando diferentes papeles que requieren de competencias singulares a lo largo de todo el proceso. Del lado del lector, del consumidor, podríamos también identificar dos tipos de lectores: uno sólo interesado en consumir la información del libro, y otro lector que podría ser también un publicador. Este último estaría interesado en generar una nueva publicación a partir de la información consumida en el acto de leer el libro.

En el universo de la Web, también podemos considerar a esos dos grandes grupos: los publicadores y los consumidores de datos. Del lado de los publicadores, podemos listar a una serie de diferentes actores, con distintos papeles en relación a la publicación de información, que muchas veces está definida por reglas o procedimientos más allá del alcance de las funciones del creador o del publicador efectivo de los datos. Ese conjunto de papeles puede involucrar a diferentes actores dentro de una empresa u órgano del gobierno, en los cuales diferentes sectores pueden tener responsabilidad sobre la definición de licencias, creación de reglas de definición del formato de las URIs (un concepto más inclusivo que el de URL), la elección del formato de los datos y de las plataformas para la distribución de la información, el conjunto obligatorio de metadatos y documentos, la definición de estrategias que permitan la existencia, la preservación y el almacenamiento de los datos, etc.

Por el lado del consumidor de datos, podemos identificar a personas interesadas en el consumo directo de los mismos (usuarios finales), y a personas con interés en transformarlos y agregarles algún valor para, entonces sí, hacer la publicación de un nuevo conjunto de datos. Ese segundo grupo de personas está formado por desarrolladores de aplicaciones intermediarias entre los usuarios y ese nuevo conjunto de datos. Muchas veces, los usuarios finales generan la conjunción, en forma manual, de diversos conjuntos de datos, para la obtención de otro resultado deseado, en una tarea que no fue atendida por ninguna aplicación específica. La combinación de datos es algo infinito y, dependiendo de la demanda de un tipo específico de combinación, puede resultar de utilidad el desarrollo de una aplicación en particular que automatice ese proceso y facilite el trabajo de los usuarios finales.

En la siguiente sección, que habla sobre el ciclo de vida de los datos en la Web, es posible identificar el conjunto de diferentes papeles y competencias necesarias para la realización de las diversas tareas relacionadas con la publicación de los datos.

3.2 Ciclo de Vida

El ciclo de vida de los datos es el proceso de gerenciamiento de la información desde la fase de su selección hasta el momento de su archivado. Ese proceso involucra la participación de diferentes profesionales, con competencias específicas relativas a cada una de las fases. Como vimos en la sección anterior, existen diversos papeles específicos dentro de los grupos de publicadores y consumidores de datos.

Existen diversos modelos que apuntan a capturar todas las fases del ciclo de vida de los datos y las relaciones entre ellas. Algunas de las fases extraídas de estos modelos son las que listamos a continuación:

• Planeamiento ‒ es la fase inicial, en la cual se planifica la publicación de los datos. Esto incluye la selección de los datos a publicarse, la identificación de equipos y organismos que deben participar del proceso y las opciones de recolección y plataformas de publicación.

• Estructuración ‒ es la fase en la cual se define la estructura de los datos a ser distribuidos. Por ejemplo, en el caso de las tablas, cuáles campos son los que habrán de ser expuestos, y cuáles serán las características de cada campo. En el caso de la utilización de Web Semántica y Datos Conectados, qué ontologías serán utilizadas para las instancias de los datos (sección 5). También en esta fase será posible definir una nueva ontología, en caso de que fuera necesario.

• Creación y Recolección ‒ constituye la fase de adquisición de los datos propiamente dichos, que incluye datos a crearse y datos ya existentes, obtenidos a partir de planillas, bancos de datos, APIs, Web Services, etc.

• Refinado y Enriquecimiento (Transformación e Integración) ‒ es la fase en la que los datos son trabajados para mejorar su calidad, filtrando posibles incorrecciones, agregando o separando información y haciendo eventuales conexiones con datos pertenecientes a otras bases.

• Formateo ‒ es la fase en la que los datos a ser publicados son formateados de acuerdo con la plataforma elegida para su publicación.

• Descripción (Metadatos, Documentación) ‒ es la fase en la que son definidos, creados y recolectados los metadatos y los documentos que deben agregarse a los datos, de modo tal de facilitar la comprensión de la información.

• Publicación ‒ es la fase en que los datos son efectivamente subidos a la Web, en la plataforma elegida para su publicación.

• Consumo ‒ es la fase en la que los datos son consumidos por usuarios finales o por desarrolladores de aplicaciones.

• Retroalimentación ‒ es la fase en la cual se recoge información relativa a la utilización de los datos, que puede provenir, por ejemplo, de parte de los consumidores de datos o de las plataformas de distribución.

• Archivado ‒ es la fase en la que los datos son retirados de la Web.

3.3 Arquitectura

En los tiempos iniciales de la Web, la tarea más habitualmente requerida a un servidor Web era la de la obtención de una página estática (identificada en la cadena de caracteres de la URL), almacenada en un archivo y codificada en HTML. Con la expansión y el desarrollo de aplicaciones en la Web Programable, esa URL pasó a ser utilizada para efectuar requisiciones de otros tipos de tareas, como por ejemplo, un pedido de informaciones sobre los precios de un producto en particular en diferentes sitios de ventas. Ese tipo de información es elaborada de manera dinámica por la aplicación ejecutada en el servidor Web, que puede compilar los datos sobre los precios de ese producto partiendo de las diferentes formas de recolección de datos listadas más arriba. En otro ejemplo, la tarea requerida podría ser la transferencia de un monto de dinero de una cuenta bancaria hacia otra. En dicho caso, la tarea requerida no sería la obtención de una página de datos. Su devolución, seguramente, estaría determinada por el éxito o el fracaso de la realización de la transferencia de fondos.

La estructura de funcionamiento de la Web está basada en el modelo cliente-servidor, en el cual tenemos una aplicación que efectúa la requisición de alguna tarea a una aplicación en particular. El acceso a los datos por el lado del servidor resulta siempre intermediado por una aplicación. Inclusive la requisición de una página HTML estática en un servidor, acaba siendo expuesta por una aplicación desde el lado del servidor que atiende la requisición efectuada por la aplicación cliente. De esa manera, cualquier dato consumido por una aplicación ejecutada desde el lado del cliente, un navegador por ejemplo, tiene una aplicación como intermediaria, que cuenta con acceso a los datos y realiza la devolución al requirente.

Entre los tantos avances y tecnologías que han sido agregados al funcionamiento de la Web, hay tres que merecen ser resaltados en la historia lineal de la manipulación de datos: JavaScript, XMLHttpRequest y Ajax. Como ya fue dicho, en los comienzos de la Web, todos los datos contenidos en una página exhibida por un navegador eran devueltos en el código HTML resultante del procesamiento efectuado por el servidor Web en función de la requisición de una URL. No existía ningún tipo de programación ejecutada por el lado del cliente Web, del navegador, que no se tratara de la mera interpretación del código HTML para la exhibición de la página al usuario. Una vez que una página hubiese sido "cargada" y exhibida, cualquier tipo de procesamiento de datos que hubiere de resultar necesario, debía ser efectuado por el servidor, a instancias de una nueva requisición. Por ejemplo, un error en un campo de un formulario sólo era detectado luego del envío de los datos al servidor, y la devolución consistía en una nueva página completa, muchas veces casi igual a la página anterior, sólo que con el agregado de un mensaje adicional informando sobre los errores detectados.

Las nuevas requisiciones de páginas determinaban un tiempo extra de demora, en razón de la necesidad de uso de la red para una nueva comunicación y transferencia de los datos. La introducción de la capacidad de ejecutar código por el lado del cliente, a través de un lenguaje que inicialmente se llamó LiveScript y luego se renombró como JavaScript, permitió que pudiesen resolverse una serie de manipulaciones sin existir la necesidad de efectuar una nueva requisición al servidor. Con la capacidad de procesar código desde el lado del cliente, algunos procedimientos como la consistencia de campos de formularios, pasaron a ser ejecutados sin necesidad de nuevas requisiciones. Con la sofisticación de las nuevas especificaciones del código HTML, el área de diseño de las páginas también se vio expuesta a cambios, adoptándose un modo más rico de presentación, apuntando hacia páginas dinámicas en HTML (DHTML), en las cuales el código JavaScript embutido en las páginas Web pasó a encargarse de manipular la estructura de los datos exhibidos.

Aún así, la programación ejecutada del lado del cliente sólo podía encargarse de manipular los datos devueltos por el servidor luego de la requisición de una URL. Si fueren necesarios más datos, era preciso efectuar la requisición de una nueva página Web, pues el código JavaScript ejecutado dentro de una página no podía comunicarse con el mundo exterior. XMLHttpRequest puso fin a esa limitación, permitiendo que el código JavaScript incluido en las páginas Web de un navegador pudiese tener acceso a más datos del servidor, toda vez que esto fuere necesario.

Google tomó conciencia rápidamente del potencial de estas nuevas tecnologías. Aplicaciones como Gmail y Google Maps sacaron provecho de ello, para construir interfaces de usuario más ricas y parecidas a una aplicación, una aplicación Web en vez de una simple página Web. En Gmail, por ejemplo, la aplicación está verificando continuamente con el servidor la existencia de nuevos e-mails. Si los hubiere, la página es actualizada sin necesidad de recargarla. De la misma forma, Google Maps permite que un usuario consulte un mapa, y sólo las áreas requeridas son solicitadas al servidor.

La nueva técnica recibió el nombre de Ajax (Asynchronous Javascript And XML) (figura 3.1) en un artículo escrito por Jesse James Garrett [8], y el término fue inmediatamente adoptado. La técnica pasó a ser utilizada de forma amplia, y surgieron diversos toolkits en JavaScript que hicieron que su uso fuese aún más fácil e intuitivo.

Este modelo de construcción de una aplicación a través de la conjunción de datos puede observarse como tratándose de una aplicación realizando la requisición de datos a partir de la especificación de URLs y obteniéndose como devolución, ya no un código HTML, sino un conjunto de datos que será manipulado por la aplicación y presentado al usuario en la forma adecuada, dependiendo de la tarea requerida por el mismo. Podemos replicar ese modelo para la construcción de aplicaciones dentro del ámbito de los datos publicados en la Web, incluyendo aquellos datos publicados según los conceptos de la Web Semántica.

La Web puede ser considerada como un conjunto de capas de datos y capas de aplicaciones ejecutadas a partir de requisiciones identificadas por URLs. Podemos convenir en que una requisición a un servidor es la requisición de ejecución de una tarea, entregándose una URL como información de entrada para que sea interpretada en la ejecución de dicha tarea y para la devolución de los resultados. Los datos resultantes de una requisición siempre son expuestos por alguna aplicación, que puede manipular datos provenientes de archivos, bancos de datos, datos extraídos de páginas Web, datos resultantes de llamadas a Web Services o llamadas a Web APIs. En el caso más simple, volviendo a los comienzos de la Web, la aplicación por el lado del servidor es solamente un servidor de páginas almacenadas en una estructura de directorios. En una configuración más dinámica, esa aplicación puede ejecutar un código que acceda a datos de un banco de datos y los devuelva en formato HTML. En un escenario aún más sofisticado, la aplicación puede comportarse como cliente de otras aplicaciones, y devolver datos resultantes de la manipulación específica que hace a partir de ellos, obtenidos mediante requisiciones efectuadas a otras aplicaciones (Web Services y Web APIs).

Desde la perspectiva de los computadores, podemos bosquejar a la Web de Datos como una capa de datos consumidos por una capa de aplicaciones. Los datos generados por dichas aplicaciones, a su vez, pueden ser utilizados como fuentes de datos para otras aplicaciones. Estaremos, entonces, frente a una nueva capa de datos (generados por aplicaciones) que podrán ser consumidos por una nueva capa de aplicaciones, y así sucesivamente. Tenemos así un universo de capas de datos y de aplicaciones que pueden construir nuevas capas de manera infinita, en el que cada aplicación ofrece un conjunto específico de tareas. La interpretación de los datos y sus posibles significados constituye una responsabilidad de las aplicaciones, resultantes de las relaciones que éstas hacen a partir del consumo del universo de datos ubicados en las diversas capas.

Desde la perspectiva de las personas, las aplicaciones deben ofrecer interfaces en las cuales los datos resultantes de las tareas requeridas sean presentados de modo tal de que sean de fácil comprensión, correspondiéndoles este trabajo a los diseñadores de las interfaces. Por ejemplo, en el caso de conjuntos extensos de datos, los recursos como la presentación visual de gráficos y tablas en diferentes formatos pueden ayudar mucho a la comprensión del conjunto. No forma parte del alcance de la presente guía el hecho de explorar las diversas formas de exponer los datos en las interfaces de usuario.

Estamos entonces frente a una arquitectura en la cual existen datos publicados de diferentes maneras, y un conjunto de aplicaciones que ofrece otro conjunto de tareas que hacen uso de aquel conjunto de datos para generar sus resultados. La distribución de estos datos es heterogénea, e incluye acceso a datos contenidos en páginas Web, descargas de archivos almacenados en estructuras de directorio en los servidores, datos devueltos por Web Services y Web APIs. No existe una estandarización respecto de la estructura y la semántica de los datos distribuidos. Esas cuestiones son resueltas por las propias aplicaciones. La comprensión de la estructura y de la semántica de los datos está embutida en tales aplicaciones.

La idea de la Web Semántica es la de definir un modelo estándar para la representación de datos, combinado con un conjunto de vocabularios de uso común, permitiendo esto que la semántica de los datos pueda anexarse a ellos, de modo tal de construir un entorno más homogéneo en las capas de datos, facilitando así el trabajo de los desarrolladores de aplicaciones.

Como veremos en la siguiente sección, la Web Semántica (Datos Conectados) agrega a dicha arquitectura dos nuevas formas de distribución de los datos:

• Desreferenciación de Recursos – los datos, recursos presentados en el modelo de datos de la Web Semántica, son requeridos directamente mediante una URI (sección 4.1.2).

• Endpoint SPARQL ‒ un protocolo de acceso y un lenguaje de consulta que permiten la requisición de un conjunto de recursos a partir de la especificación de una consulta a una base de datos.

En la actualidad, el entorno Web, respondiendo a su característica intrínseca, posee una estructura heterogénea respecto de la publicación y distribución de datos. El tema más importante en referencia a la apertura de datos es que los mismos sean publicados, aunque se utilicen formatos propietarios, que exijan más trabajo por parte de los desarrolladores y de los consumidores de datos. Lo que los creadores de la Web Semántica ansían es el hecho de que esas diferentes formas puedan converger, con el paso del tiempo, hacia la construcción de una Web de Datos, un banco de datos mundial de informaciones interconectadas. Sobre la base de dicha Web de Datos, las aplicaciones serán capaces de construir su conjunto de tareas, con el objeto de atender las demandas de los usuarios. En la sección 5.2 haremos la presentación de cinco fases conducentes a ese camino hacia la apertura de datos.