Toekomstige doorontwikeling:

Conceptueel model Digitale Delta Api (Uni-API)

Terugblik

De oorspronkelijke gedachte achter de Digitale Delta was uit uitwisselen van meetgegevens op een uniforme manier, de DD-API. Al snel kwam er een andere variant bij, de DD-OPER, waarbij de zoekpaden vaster kwamen te liggen dan bij de DD-API.

Bij introductie was echter uitgegaan van een relatief beperkte set data: de data die werd opgehaald via de sensoren, in de vorm van tijdreeksen.

Daarna werden ecologische metingen toegevoegd, waaraan andere eisen worden gesteld door complexiteit. Het resultaat was een afsplitsing: de DD-ECO-API, die uit noodzaak was geboren, omdat:

- De benodigde selectiemogelijkheden bij statische koppelingen zoals in de DD-API enorm zouden zijn geweest en de implementatie ervan ingewikkeld

- Er veel meer informatie per meting moet worden vastgelegd, die kunnen verschillen per onderzoek

Bij export in tijdreeksenformaat is er verlies van vitale data. Bij deze metingen gaat met meer om waarnemingen, zonder vaste tijdinterval.

Daarna kwamen nog andere toevoegingen, in de vorm van rooster-data. Tot slot kwam daar nog een verbindende API bij: de C-API, om over verschillende soorten API's (en bronnen) heen metingen te kunnen ophalen.

Er zijn dus ondertussen al drie verschillende varianten van de DD-API. Het tempo van ontwikkeling verschilt enorm tussen de verschillende API's.

De DD-API staat ongeveer stil in ontwikkeling, de DD-GRID-API is bijna klaar voor een eerste implementatie, en de DD-ECO-API is volop in ontwikkeling.

Tijd voor een her-evaluatie.

Stapje terug

Waarin verschillen metingen van de verschillende API's?

Het antwoord is:

- Details die worden vastgelegd

- Zoekmogelijkheden

 

Dus eigenlijk hebben we het over een uitvoerformaat!!

 

Waarom niet alle beschikbare informatie rond een meting vastleggen, de zoekmogelijkheden flexibel maken, en kunnen aangeven welk formaat geƫxporteerd moet worden? Het is prima mogelijk om vanuit metingen tijdreeksen en roosters te genereren, maar de andere kant op betekend verlies van informatie.

Voortschrijdend inzicht

Er is ondertussen nog meer veranderd. In de beginperiode van de DD-API was er een stuk minder gestandaardiseerd dan nu op gebied van data-uitwisseling. Er lagen ook veel minder eisen.

In de huidige situatie moeten we ons meer houden aan standaards. Dat betekend overheidsstandaards, Europese standaards, INSPIRE, ISO, NEN, etc. Een selectie van standaards die gaan worden gebruikt in de Digitale Delta API zijn o.a.:

- REST: REST

- OGC WFS: OGC WFS

- OGC O&M: OGC Observations & Measurements

- IM Metingen: IM Metingen

- NEN 3610: NEN 3610

- JSON

- INSPIRE

 

Er zijn ondertussen, naast eisen, ook standaarden die ons kunnen helpen (goedgekeurd door Kennisplatform API's):

- OData: OData v4 voor zoekmechanismen

- OAUTH2: OAuth 2.0 voor authenticatie

Verder hebben we ons verbonden aan het zoveel mogelijk voldoen aan de Aquo standaarden en aan Kennisplatform API. Doen we dit allemaal, dan kunnen we metingen en aanverwante informatie gestructureerd uitwisselen. Er zijn dan ook geen verschillende DD-* varianten nodig: alles kan met een eenduidige API.

Er speelt nog meer. Bijvoorbeeld Semantic Web: Semantic Web. Aquo en RWS richten zich daarop. Hier worden de betekenissen van entiteiten en eigenschappen vastgelegd. Hiermee voorkomen we definitie-verschillen en bevorderen een uniforme uitwisseling.

Over OData

OData is een van de componenten binnen Kennisplatform API. Het is een krachtig, gestandaardiseerde zoekmechanisme dat gebruikt kan worden vanuit diverse systemen, zoals ArcGIS, SAP, Power BI, Tableau en zelfs Excel. Het is o.a. ISO en Oasis standaard. De discovery functie wordt gebruikt om de beschikbare entiteiten te vinden. Het kan worden uitgebreid met o.a. eigen functies.

Proof of Concept

Het Architecture Board is begonnen met nadenken hierover: het streven naar een Digitale Delta API. Hieruit gaat een Proof of Concept komen.

Maar niet alleen dat: het wordt een open source referentie-implementatie. Deze zal gebruik maken van een databron met chemische, fysische en ecologische metingen. En hoe past een en ander in een Semantic Web.

Deze Proof of Concept is in privetijd ontwikkeld door een zeer betrokken voorstaander van de Digitale Delta API.

Doorontwikkeling zal bij voldoende acceptatie voorzien worden van Budget zodat we kunnen werken naar het de oplevering in 2023.

Uitwerking

- OData wordt gebruikt als zoek-basis

- Geen closed-source libraries of componenten

- OS onafhankelijk (dus Windows, Linux, MacOS)

- Eerste Proof of Concept wordt gemaakt in .NET Core/Standard. Overzetten naar Python moet redelijk eenvoudig gaan.

- De Proof of Concept vult de database niet. Het vullen is altijd afhankelijk van de aanbieder van de data.

 

Voor deze Proof of Concept wordt gebruik gemaakt van een PostgreSQL database, een snelle, platform-onafhankelijke database waarvoor geen licentie nodig is. Met kleine aanpassingen zijn andere databases echter ook te gebruiken.

Database model

Een conventioneel database model is onbruikbaar voor een generiek concept als dit. In een conventioneel model zouden alle velden uitgeschreven zijn in de tabel. Dat zou leiden tot veel niet-gebruikte velden, veel schema mutaties, en grote schema's. Daarnaast zou dit niet alleen voor metingen, maar ook voor parameters, grootheden, eenheden, etc. moeten gebeuren.

Daarom is er een onconventioneel database model gebruikt. Hierin worden entiteit-typen (metingen, parameters, etc.) vastgelegd. Bij een entiteit-type wordt ook vastgelegd welke eigenschap-types bij deze entiteit horen. Op deze manier ontstaat een definitie van welke eigenschappen bij welke entiteiten kunnen worden vastgelegd: er ontstaat een virtueel datamodel. Entiteiten kunnen weer relaties hebben met andere entiteiten, maar eigenschappen kunnen ook weer verwijzen naar andere entiteiten.

Daarnaast heeft iedere entiteit-type en eigenschap-type een middel om naar Aquo te verwijzen, door middel van een RDF-definitie.

 

Database schema van Linked Snowflake

Figuur 1:Voorlopig database schema

Van datamodel naar OData

Een datamodel (al dan niet virtueel) is belangrijk voor OData. De discovery functie van OData ($metadata) geeft aan de buitenwereld aan welke functionaliteit en welke entiteiten en eigenschappen bekend zijn binnen het systeem. OData maakt daarvoor gebruik van een definitie in CSDL (Conceptual Schema Definition Language) geschreven. In deze Proof of Concept gebruiken we daarvoor de JSON-representatie, omdat die eenvoudiger op te bouwen is dan de XML-versie.

De Proof of Concept maakt tijdens het opstarten gebruik van het database schema om een CSDL te genereren. Deze wordt aan OData gevoed, die daaruit de metadata voor discovery aanmaakt. Deze informatie wordt ook gebruikt om de OData URL, met daarin het filter, te controleren.

 

Digitale Delta

Let's connect the water systems

 

 

>> Digitale Delta

>> Onderhoud & Beheer

>> Community

>> Doorontwikkeling