Deze richtlijnen worden momenteel opgemaakt in een co-creatie proces. Aanbeveling dus onder voorbehoud. Deze worden momenteel geregeld geüpdatet. Naar het einde van 2021 toe worden deze richtlijnen gefinaliseerd.
Minimale vereisten
Er zijn verschillende manieren om data te delen. Een belangrijke minimale vereiste is dat de data structuur niet verandert in de tijd. Een voorbeeld: een excel sheet blijft bestaan met altijd dezelfde kolommen. Er worden terloops geen kolommen tussen bestaande kolommen toegevoegd. Uiteraard kunnen rijen aangevuld worden als er nieuwe observaties binnen komen. Indien er toch een aanpassing gebeurd van de data, dan moet dit op één of andere manier duidelijk gemaakt worden:
- Er wordt een uitleg voorzien welke veranderingen er gedaan zijn (bv: een modelsimulatie werd opnieuw gerund met andere input parameters/ meta-data)
- Er wordt meegedeeld waar deze nieuwe data te vinden zijn (naam bestand, versioneringsnummer,...)
Naargelang de manier waarop data opslag gebeurd, kunnen deze 2 vuistregels een andere vorm aannemen.
We illustreren dit:
Excel, csv, ...
Een excel, csv bestand, ... blijft hetzelfde doorheen de tijd. Elke kolom specifieert een parameter, elke rij een observatie. Definities van kolomnamen kunnen bijgehouden worden in een afzonderlijke sheet met elke rij een kolomnaam, met een uitleg in de cellen ernaast.
Een bijkomende sheet zou gebruikt kunnen worden om de meta-data van de data sheet te benoemen: locatie staalname, apparatuur gebruikt, calibratie parameters, etc. Indien er zaken zouden veranderen, kan deze meta-data sheet aangepast worden. Kolommen die eventueel toegevoegd worden, hebben zo ook meer context: bv. er werd een andere sensor gebruikt, die nu meer parameters kan registreren.
Indien er nu een copy (met andere naam, versienummer,...) gemaakt wordt van een excel bestand waar er een kolom bij kwam, dan kan er makkelijk nagegaan worden wat deze excel net inhoudt of hoe deze verschilt tov de vorige versie obv de extra gegevens in de kolom-definitie en of meta-data sheet.
Onderstaande figuren illustreren dit.
Voorbeeld data tabbladen opdeling
Voorbeeld excel data
Voorbeeld kolom definitie excel
Voorbeeld meta-data in excel
json, xml, ...
Onderstaande figuur illustreert hoe dezelfde data kan bijgehouden worden in json formaat (of gelijkwaardig). De bijgevoegde metadata laat toe om aan te tonen indien er een verandering gebeurde in de data dit toe te wijzen aan bv een verandering van sensor, of locatie. Indien de data nu gedeeld wordt, kan er achterhaald worden waarom bepaalde data veranderd zijn, objectief gezien, zonder dit manueel gevraagd moet worden aan de verdeler van de data.
Voorbeeld json metadata en data opslag voor transparantere data deling
Eens dit principe voldaan is, kan de data veilig gedeeld worden zonder dat er verwarring onstaat over welke data net gedeeld wordt.
In de VLOCA aanbevelingen worden suggesties gedaan hoe dit best kan gebeuren.
VLOCA aanbevelingen
Maak je linked data vindbaar met een URI
In een notendop zijn er 3 vuistregels mbt linked data[1]:
- Gebruik URI als unieke identifiers
- Sla je data als triplets op (onderwerp, eigenschap, waarde)
- Publiceer je data op het web
Waarom een URI? een ID (bv:54112), zoals we die kennen in een database bv, is enkel uniek in de context van die specifieke database. Een URI (vaak URL's) zijn per definitie al uniek, gezien het ze voorkomt dat er dubbele adressen zijn.
Ontsluit je database met een API
Een database kan een grote hoeveelheid data bijhouden, en een API maakt het gemakkelijk om deze data te consulteren. Via een web request kan data opgevraagd worden obv enkele simpele zoektermen. Deze worden dan door de API vertaald naar een database query, die de opgevraagde data teruggeeft in een bepaald vooraf afgesproken formaat.
Het voordeel hier is dat je je eigen database kan structureren zoals je wenst, maar toch data kan aanbieden naar buiten toe op een gecontroleerde en overzichtelijke manier:
- gecontroleerd: je beslists zelf welke delen van de database opgevraagd kunnen worden
- overzichtelijk: de gebruiker vraagt met enkele eenvoudige key-value pairs de data op zonder heel de database structuur te moeten kennen of bekijken
Ontsluit je data via een broker
Indien het request-response paradigma minder geschikt is voor de toepassing, kan de data ontsloten worden via een broker.
Voor de pro's en con's van het broker (pub-sub) en request-response paradigma, zie volgende pagina. In de meeste gevallen wordt een broker (pub-sub) systeem verkozen in IoT toepassingen.
Gebruik yyyy-mm-dd (ISO8601) in je datum voorbeelden
Kwestie van de verwarring tussen month-first versus day-first niet te hebben is het mss goed in de voorbeelden datums als yyyy-mm-dd voor te stellen.
Wat is de effectieve use case van huidige json/xml voorbeeld?
In het geval van het json/xml voorbeeld is de structuur wss in de praktijk gelinkt aan een api/dbase/xsd... met een bepaalde versie (v1,...) al dan niet op basis van het data model van een (open) standaard. Veranderingen in het data model zouden dan versionering hebben? Gaat het hier over een illustratie van een wijziging in data model of van de meta data van een sensor volgens het voorbeeld data model?
> Indien de data nu gedeeld wordt, kan er achterhaald worden waarom bepaalde data veranderd zijn, objectief gezien
ahv het achterliggende schema of de data zelf? Hoe precies?
Verder is het mss nuttig te adviseren om bestaande data modellen te gebruiken om data te delen?
Reactie: Wat is de effectieve use case van huidige json/xml voorbeeld?
Goede opmerking, ik begrijp waar je naartoe wil. Het voorbeeld was een zeer low level voorbeeld om de reflex te hebben om meta-data op een of andere manier bij te houden. We spreken hier nog niet over koppeling aan bestaan data model, wat uiteraard wel goed zou zijn om te doen.