Water in de stad Workshop 2

Presentation

Onderwerp Van De Workshop

In deze workshop werd dieper ingegaan op de databeschikbaarheid.
Door te werken naar standaarden en/of principes kan een vlottere uitwisseling van data mogelijk gemaakt worden. De workshop draaide volledig rond deze standaarden en principes.

Welke bestaan er?
Welke zijn er te verkiezen waar en wanneer en voor welk type data?
Hoe worden data best bijgehouden en met welke systemen best uitgewisseld?

Of bekeken vanuit de Open Dei referentiearchitectuur ging deze workshop over de interfaces van Community (delen en samenwerken), Content/Context (datastandaarden) en Computing (opslag en gebruik). Tegelijkertijd werden ook twee andere gerelateerde initiatieven nader toegelicht bij het begin van de workshop:

OSLO en meerbepaald het OSLO traject AIR & WATER
Data broker van AIV.

Introductie OSLO (Kevin Haleydt)

Het belang van semantische interoperabiliteit

In het kader van dienstverlening dienen overheden van verschillende niveau (lokaal, regionaal, federaal, Europees) met elkaar samen te werken
Dit gaat vaak gepaard met allerhande gegevensuitwisselingen van informatie uit verschillende:
- Systemen
- Administraties
- Technische formaten…
Nood aan gemeenschappelijk semantische verstandhouding

Open Standaarden voor Linkende Organisaties

OSLO = Open Standaarden voor Linkende Organisaties
Robuuste en gedocumenteerde methodologie
Co-creatie als vertrekpunt voor gedragenheid
Online publicatie van de semantische (maar ook technische) standaarden in het Standaardenregister

Eindproduct van een OSLO traject

Semantisch
- Applicatieprofiel
- Vocabularium
Implementaties
- LBLOD
- AWV
- CRAB
- Besluitvorming
- Vlaamse Codex

Raakvlakken OSLO & VLOCA Water in de stad

Betrokkenheid OSLO in VLOCA traject vanwege synergie, maar ook teneinde dubbel werk te voorkomen
Raakvlakken met reeds bestaande OSLO trajecten:
- OSLO Openbaar Domein
  - Waterdeel
  - Watervoorkomen
- OSLO Air & Water (focus op observaties & qualiteit)
- Agentschap Wegen & Verkeer Object Type Library (OTL), namelijk deelimplementaties:
  - Rioleringen
  - Waterlopen (to be)
  - Dijken (to be)
  - Constructie-elementen (to be)
Kortom, duidelijke synergie tussen OSLO & VLOCA

Data Broker AIV (Annelies De Craene, Ziggy Vanlishout)

Sensor Data Platform

Onze Probleem is: Hoe maken we van real time sensordata een belangrijke hefboom voor duurzame groei van de Vlaamse data-economie?

huidige platformen zijn niet altijd geschikt om grote volumes sensordata aan te bieden op een

kostenefficiënte manier

smart city toepassingen zijn vandaag nog te veel maatwerk en onvoldoende schaalbaar
sensordata ontstaan in silo’s en bieden op zichzelf onvoldoende meerwaarde voor nieuwe

business modellen, niet gestandaardiseerd

een dreigende vendor lock-in op sensordata en geconsolideerde smart city markt vormt een

sterke rem op de innovatie

Sensordata zijn een groeimarkt voor de data-economie van morgen. De effect die we beogen:

Doelstellingen

Herbruikbare open source componenten aanbieden aan de markt die kostenefficiënte publicatie van grote volumes sensordata in real time toelaat - interoperabiliteit
Inzetten op open standaarden zodat sensor data sensor-agnostisch wordt en ‘loskomt’ van de leverancier vd sensor en vlot gerelateerd kan worden aan slow moving data (vb. basisregisters)
Ecosysteemvan ‘samenwerkende’ sensor dataplatformen tot stand brengen

Business voordelen

Innovatiesnelheid en time to market van Vlaamse bedrijven gevoelig verhogen. Dit is een voorwaarde voor de veerkracht van onze Vlaamse bedrijven
Realtime en gepersonaliseerde data zijn een vereiste voor digitale transformatie geworden
Self Service by design en betaalbaar te gebruiken door de gehele markt

BREAK-OUTS

De deelnemers werden verdeeld over 3 break-outs. Elke break-out kreeg een aanzet tot beslissingsboom voorgeschoteld op een MIRO-board als een eerste probeersel van een stappenplan om te komen tot de beste oplossing om data beschikbaar te maken. Deze beslissingsboom werd overlopen aan de hand van een aantal vragen over de gewenste datastandaarden, eventuele voorkeuren van dataopslagtypes en pub/sub type. Om ergens te starten werden op basis van het ingediende huiswerk van de deelnemers een genudgde classificatie gemaakt tussen 4 types data om de discussie te stimuleren:

sensor data
GIS data
modelresultaten
staalname data.

Datatypes

Het is duidelijk dat nog meer types data gezien worden door de deelnemers en dit afhankelijk van hun uitgangspunt. De voorgestelde opsplitsing is een goed begin, maar niet altijd even relevant. Tevens ging het over semantiek. Een opdeling kan nuttig zijn, maar mag ons niet vastzetten. In vele gevallen zijn de issues dezelfde voor de verschillende types. Het belangrijkste bijkomende onderscheid dat aangehaald werd is real-time versus niet-real-time of historische data.
Op die basis zouden bv. al sensordata onderscheiden kunnen worden van de andere 3 voorgestelde types. Ook alle eerder contextdata zijn niet-real-time. Een andere onderscheidingsfactor zou dan contextdata of back-end data van overheden versus andere, door data-bedrijven en sensoren geleverde data (ook wel ‘industriële data’ genoemd) kunnen zijn. En wat met data-enrichment?
Ontologische opdelingen zoals bij WaterML zijn ook mogelijk. Voor OSLO zijn de volgende 3 parameters

primordiaal: de plaats (locatie, context,...)
de observatie data
de context van het device.

Die 3 moeten samen blijven. Dit relateert ook aan het belang van unieke Ids.

Datastandaarden

Algemeen is er een vraag naar standaardisatie; de standaard zelf doet er op zich niet toe, want theoretisch kan je mappen tussen de verschillende datastandaarden, maar dat heeft dan natuurlijk zijn economische plaatje. De realiteit nu is dat er vanalles en nog wat gemaakt wordt en dat bovendien de leveranciers zelf nog een transformatie moeten doorgaan en daadwerkelijk de standaard moeten leveren. Daar staat tegenover dat flexibiliteit nodig is, want standaarden evolueren vandaag trager dan technologische evoluties in sensoren en data-opslag. Tussen beide moet een evenwicht zijn en backward compatibility is daarin zeer belangrijk.

Eigen data-opslag

Eigen data-opslag is bijvoorbeeld niet interessant voor satellietdata, waar het verplaatsen van de gigantische hoeveelheid data niet aan te raden is. Bovendien moet eigen data-opslag een duidelijk doel hebben zoals het trainen van modellen, archivering, calibratie etc. De IT infra moet flexibel genoeg zijn om de uitwisselbaarheid en opslag te ontkoppelen (cf. REST API). Wat men intern gebruikt, kan al sterk bepaald zijn door historische keuzes en de bestaande use case(s): uitwisseling, monitoring, presentatie, exploratie, onderzoek etc. Sensor data is ook meestal niet bedoeld voor 1 use case. Idealiter kan een database om met verschillende data-types. Hoe kan je flexibel omgaan met multi-gebruik met andere noden, bijvoorbeeld cross-domain. Smart data wordt belangrijk! Databases waarbij time-series verwerkt worden verschillen van databases waarbij dit niet nodig is. Zeker indien deze data snel achter elkaar (~seconde) binnenstromen. Zij die nog keuzes moeten maken, weten dan toch graag wat een goede keuze is voor data-opslag met een blik op de toekomst.

Quality control

De kwaliteit van sensordata zijn een heikel punt. Hoe kan die nagegaan worden? Speelt dit enkel maar bij sensordata of is dit even relevant -maar mogelijk minder heikel- voor de andere datatypes? Kan kwaliteitscontrole en validatie ook gestandaardiseerd worden en uitwisselbaar worden (bv. scripts)?

Data-ontsluiting (pub/sub, API)

Pub/sub system: hoewel sommigen al aangeven de AIV data-broker te willen gebruiken, dient genuanceerd te worden dat het nog een theoretisch concept is. Wat is beter? : self-hosted (Edge) versus Cloud. FIWARE kan in beide gevallen gebruikt worden, want bestaat uit standaarcomponenten. Pre-processing scripts staan best dichtbij de edge. Als de sensor/edge smart genoeg is kan daar al voorverwerking gebeuren. Daar staat tegenover dat bepaalde klanten graag raw data hebben en andere reeds verwerkte. Kunnen beide opties in bepaalde gevallen open blijven? Wat met message brokers/buffers (cf. Kafka)? In functie van de concrete toepassing, kan het nodig zijn dat informatie gebufferd wordt, omdat het verwerken ervan trager is dan de snelheid waarmee data binnen stroomt.

API: Er moet naar een interoperabel systeem van API gegaan worden (cf. OSLO verhaal). Standaardisatie is hierin belangrijk en een directe vraag aan OSLO. REST-API aub. Versiebeheer is ook een belangrijk aandachtspunt.