En l'era digital actual, la informació és un actiu estratègic que impulsa la innovació, la transparència i la col·laboració en tots els sectors de la societat.
No obstant això, existeixen encara molts reptes tant per a publicadors de dades com per a consumidors dels mateixos. Aspectes com el manteniment de les APIs (Application Programming Interfícies) que ens permeten accedir i consumir els conjunts de dades publicades o la correcta replicació i sincronització de conjunts de dades canviants segueixen sent desafiaments molt rellevants per a aquests actors.
Els Linked Data Event Streams (LDES) són un nou mecanisme de publicació de dades que poden ajudar a solucionar aquests reptes.
Destil·lant els aspectes claus de LDES
Quan des de la Universitat de Gant es va començar a treballar en un nou mecanisme per a la publicació de dades obertes, la pregunta a la qual pretenien donar resposta era: Quin és la millor API possible que podem dissenyar per exposar conjunts de dades obertes?
En l'actualitat, els organismes publicadors de dades recorren a múltiples mecanismes per publicar els seus diferents conjunts de dades. D'una banda, és fàcil trobar-nos API s. Destaquen les de tipus SPARQL, estàndard per a consulta de dades enllaçades ( Link Data ), però també de tipus REST o de tipus WFS, per a l'accés a conjunts de dades amb component geoespacial. D'altra banda, és molt comú que trobem la possibilitat d'accedir a bolcats de dades en diferents formats (i.i. CSV, JSON, XLS, etc.) que puguem descarregar per a la seva utilització.
En el cas dels bolcats de dades, és molt fàcil trobar-nos amb problemes de sincronització. Això ocorre quan, després d'un primer bolcat, es produeix un canvi que requereix la modificació del conjunt de dades original com, per exemple, el canvi del nom d'un carrer en una llista de carrers prèviament descarregada. Davant aquest canvi, si el tercer opta per modificar el nom del carrer sobre el bolcat inicial en lloc d'esperar al fet que el publicador actualitzi les seves dades en el repositori mestre per realitzar un nou bolcat, les dades manejades pel tercer quedaran desincronizados enfront dels manejats pel publicador. D'igual forma, si és el publicador el que actualitza el seu repositori mestre però aquests canvis no són descarregats pel tercer, tots dos manejaran diferents versions del conjunt de dades.
D'altra banda, si el publicador ofereix l'accés a les dades a través d'APIs de consulta, en lloc de mitjançant bolcats de les dades als tercers, se solucionen els problemes de sincronització, però la construcció i manteniment d'un alt i variat volum de les mateixes suposa un elevat esforç als publicadors de dades.
LDES cerca solucionar aquestes diferents problemàtiques aplicant el concepte de Linked Data a un event stream o flux de dades. Segons la definició que apareix en la seva pròpia especificació , un Linked Data Event Stream (LDES) és una col·lecció d'objectes immutables on cada objecte està descrit en ternes RDF.
En primer lloc, el fet que els LDES apostin per Linked Data aporta principis de disseny que permeten combinar dades diverses i/o pertanyents a diferents fonts, així com la seva consulta a través de mecanismes semàntics que permeten llegibilitat tant per humans com per màquines. En resum, aporta interoperabilitat i consistència entre conjunts de dades, i facilita per tant la seva cerca i descobriment.
D'altra banda, els event streams o fluxos de dades, permeten als consumidors replicar la història dels conjunts de dades, així com sincronitzar els canvis recents. Qualsevol nou registre afegit a un conjunt de dades o qualsevol modificació dels registres existents (en definitiva, qualsevol canvi), es registra com un nou esdeveniment incremental en el LDES que no alterarà els esdeveniments anteriors. Per tant, poden publicar-se i consumir-se dades com una seqüència d'esdeveniments, la qual cosa és útil per a dades que canvien amb freqüència, com a informació en temps real o informació que sofreix actualitzacions constants, ja que permet la sincronització de les últimes actualitzacions sense necessitat de fer una nova descàrrega completa de tot el repositori mestre després de cada modificació.
En un modelo de este tipo, el editor solo necesitará desarrollar y mantener una API, el LDES, en lugar de múltiples APIs como WFS, REST o SPARQL. Los diferentes terceros que deseen utilizar los datos publicados se conectarán (cada tercero implementará su cliente LDES) y recibirán los eventos de los streams a los que se hayan suscrito. Cada tercero creará a partir de la información recabada las APIs específicas que considere oportunas en base al tipo de aplicaciones que quieran desarrollar o fomentar. En definitiva, el publicador no tendrá que resolver todas las potenciales necesidades que tenga cada tercero en la publicación de datos, sino que dando un interfaz LDES (API base mínima) cada tercero se centrará en su problemática.
A més, per facilitar l'accés en grans volums de dades o a dades que poden estar distribuïts en diferents fonts, com un inventari de punts de recarrega elèctrica a Europa, LDES aporta la capacitat de fragmentació dels conjunts de dades. A través de l'especificació TREE (en anglès, arbre), LDES permet establir diferents tipus de relacions entre fragments de dades. Aquesta especificació permet publicar col·leccions d'entitats, anomenats membres, i ofereix la capacitat de generar una o més representacions d'aquestes col·leccions. Aquestes representacions s'organitzen com a vistes, distribuint els membres a través de pàgines o nodes interconnectats mitjançant relacions. Així, si desitgem que les dades es puguin consultar a través d'índexs temporals, es podrà establir una fragmentació temporal i accedir solament a les pàgines d'un interval temporal. D'igual forma, es podran plantejar índexs alfabètics o geoespacials i així un consumidor podrà accedir només a aquelles dades necessàries sense la necessitat de realitzar el “bolcat” del conjunt de dades complet.
Quines conclusions podem extreure de LDES?
En aquest post hem observat el potencial de LDES com a mecanisme per a la publicació de dades. Alguns dels aprenentatges més rellevants són:
- LDES persigue facilitar la publicación de datos a través de APIs base mínimas que sirvan como punto de conexión para cualquier tercero que desee consultar o construir aplicaciones y servicios sobre conjuntos de datos.
- La construcción de un servidor LDES, no obstante, tiene cierto nivel de complejidad técnica a la hora de establecer la arquitectura necesaria para el manejo de los flujos de datos publicados y su adecuada consulta por parte de consumidores de datos.
- El diseño de LDES permite la gestión tanto de datos con una elevada tasa de cambios (i.e. datos provenientes de sensores), como datos con una baja tasa de cambios (i.e. datos provenientes de un callejero). Ambos escenarios pueden manejar cualquier modificación del conjunto de datos como un flujo de datos.
- LDES soluciona de forma eficient la gestió de registres històrics, versions i fragments de conjunts de dades. Per a això es recolza en l'especificació TREE podent establir diferents tipus de fragmentació sobre el mateix conjunt de dades.
