Document toolboxDocument toolbox

TECHNISCHE INFORMATIE

Owned by Dimitri Hertoghs (Deactivated)
Last updated: 18 Jan, 2023 by Dwight Van Lancker
4 min read

Binnen de Vlaamse Smart Data Space worden datasets onsloten conform de Linked Data Event Stream (LDES) specificatie. Deze specificatie bestaat op Europees niveau https://semiceu.github.io/LinkedDataEventStreams/ , maar werd door middel van een OSLO-traject ook een standaard op Vlaams niveau: https://data.vlaanderen.be/doc/applicatieprofiel/ldes .

Om het ecosysteem te ondersteunen bij het publiceren en/of consumeren van deze LDES stromen wordt er gewerkt aan verschillende herbruikbare bouwblokken.

VSDS Bouwblokken

LDES Server

Met behulp van deze component kan een dataset ontsloten worden conform de LDES specificatie. De huidige implementatie kan beschouwd worden als een REST API, waarbij via POST requests nieuwe versie-objecten (LDES members) aan de stroom kunnen worden toegevoegd. De huidige implementatie gebruikt een MongoDB database om de members en de fragmenten op te slaan.

Ter info: een versie-object = de volledige toestand van een entiteit op een bepaald moment in de tijd. Voor entiteiten die het concept van tijd niet kennen (zoals adressen, straatnamen, gemeentes, …) is het noodzakelijk om eerst een versie-object te maken vooraleer deze toe te voegen aan de LDES server. Voor entiteiten die het concept van tijd wel al kennen (zoals sensor observaties) is deze tussenstap niet nodig.

Fragmentaties

Om de hoeveelheid data die consumers moeten repliceren of om bepaalde queries te versnellen, kan de LDES server geconfigureerd worden met een aantal fragmentaties. Een fragmentatie is vergelijkbaar met indexen zoals in databases, maar dan gepubliceerd op het Web. Via configuratie wordt het RDF predicaat waarop gefragmenteerd wordt. De huidige implementatie ondersteunt 2 fragmentaties:

  • Time-based fragmentatie

Fragmentatie gebeurt op basis van een timestamp property en leidt tot een lineaire gelinkte lijst van fragmenten, waarbij elk fragment een link naar het vorige en volgende fragment heeft. Op die manier kan een client starten vanaf een gekozen fragment (bij voorkeur uiteraard bij het eerste fragment) en door het volgen van de links naar andere fragmenten meer members ontdekken.

→ Concreet zullen de oudste members aan de eerste pagina worden toegevoegd, terwijl de meest recente members telkens aan de laatste pagina worden toegevoegd.

Vereiste configuratie voor deze fragmentatie is:

  1. RDF-predicaat waarop de fragmentatie moet gebeuren

  2. Aantal LDES members per pagina

  • Geospatial fragmentatie

De geospatiale fragmentatie volgt het “Slippy Maps”-principe. Hierbij wordt via configuratie een zoom level vastgelegd en aan de hand van dit zoom level wordt de “wereld” opgedeeld in tegels. Het aantal tegels is 22n (waarbij n = zoom level). Ook voor deze fragmentatie moet een RDF-predicaat geconfigureerd worden, die gebruikt wordt om te bepalen in welke geospatiale tegel de LDES member moet worden toegevoegd.

Vereiste configuratie voor deze fragmentatie:

  1. RDF-predicaat waarop de fragmentatie moet gebeuren

  2. Zoom level

De software voor deze fragmentatie bouwblokken werd zo geschreven dat het mogelijk is om verschillende fragmentaties aan elkaar te koppelen. Bijvoobeeld de geospatiale fragmentatie gevolgd door de time-based fragmentatie → Dit betekent dat binnen elke geospatiale tegel ook nog eens een time-based fragmentatie zal gebeuren.

Caching

Eén van de grote voordelen van LDES is de mogelijkheid tot HTTP caching. Van zodra een fragment “vol” zit (lees: de paginalimiet voor dit fragment is bereikt), dan kan dat fragment niet meer veranderen waardoor het mogelijk wordt om de cache-header Cache-control: immutable toe te voegen aan het fragment. Dit zorgt ervoor dat het gecached kan worden op zowel de server als de client.

Onderstaande figuur is een voorbeeld van een time-based fragmentatie waarbij er drie “volle” fragmenten zijn, fragment vier zijn paginalimiet nog niet heeft bereikt en dus nieuwe LDES members worden aan dit fragment toegevoegd. De eerste drie fragmenten kunnen gecached worden op zowel de server als de client. Een consumer moet dus enkel het laatste fragment pollen (periodiek ophalen) om eventueel nieuwe LDES members ook naar zijn systeem te repliceren.

Alle informatie over het gebruik en installatie van de LDES server kan teruggevonden worden op GitHub: https://github.com/Informatievlaanderen/VSDS-LDESServer4J

LDES Client

Om een LDES stroom te kunnen repliceren naar een eigen systeem en in sync te kunnen blijven met de oorspronkelijke dataset werd de LDES client ontwikkeld. Voor deze client werd een software development kit (SDK) in Java ontwikkeld die volgende functionaliteiten bevat:

  • Replicatie en synchronisatie van een LDES

De LDES client wordt geconfigureerd met LDES URL en start met het ophalen van de LDES members. Deze client volgt automatisch links naar andere pagina’s (die hij nog niet heeft bezocht) om zo nieuwe LDES members op te halen. Indien alle huidige members zijn opgehaald, zal de LDES client de fragmenten die niet gecached zijn gaan pollen om eventueel nieuwe LDES members ook op te halen.

  • Bijhouden van state

De LDES client houdt zijn eigen state bij, wat betekent dat hij bijhoudt welke fragmenten hij al bezocht heeft en welke members van niet-gecachete fragmenten hij al heeft opgehaald. Indien een LDES client offline gehaald wordt, kan hij nadien terug opstarten en verder gaan waar hij geïndigd was.

De SDK kan teruggevonden worden op GitHub:

Daarnaast werden er 2 wrappers geschreven rond deze SDK die ervoor zorgen dat de LDES client op de command line gebruikt kan worden en ook in Apache Nifi.

  • CLI-versie → uitvoeren van de LDES client via de command line interface ( )

  • Apache Nifi wrapper → Uitvoeren van de LDES client in Apache Nifi ( )

LDES stromen

Er zijn reeds verschillende LDES’en beschikbaar: