"Parsed text" is een vooraf gedefinieerde eigenschap. Deze eigenschap is van te voren gedefinieerd (ook bekend als een speciale eigenschap) en komt met extra beheersprivileges, maar kan worden gebruikt net als elk andere door de gebruiker gedefinieerde eigenschap.
D
Introductie (Waarom?)
Via het VLAIO CityOfThings project Databroker werd het belang van het organiseren van data delen aangetoond, met de stad Gent als project leider. Op https://vimeo.com/399147417 werd door KCVS een introductiefilmpje geplaatst die het concept en het belang van een databroker beter beschrijft, met onderstaande context :
"Steden en gemeenten staan momenteel voor tal van grote uitdagingen, waaronder klimaatverandering, een vergrijzende bevolking, mobiliteit, globalisering en digitalisering. Slimme steden of ‘smart cities’ zoeken naar technologieën zoals IoT, die hen kunnen helpen het leven duurzamer en aangenamer te maken. Daarbij worden data als sleutel gezien om relevante toepassingen voor de maatschappij van de toekomst te voorzien. De nood om de waarde van historische en real-time (stads)data ten volle te exploiteren, voedt de nood aan een databroker die deze data toegankelijk maakt. Stad Gent leverde, samen met Digipolis Gent, de steden Antwerpen, Brugge, Genk en Roeselare, IMEC en het Kenniscentrum Vlaamse Steden, een project op dat zowel praktisch als juridisch een gids vormt voor alle Vlaamse steden en gemeenten. Deze gids zorgt ervoor dat de steden en gemeenten in staat zijn om zo’n databroker te implementeren en te exploiteren. "
Een open databroker vormt de basis van een open stad architectuur. Vandaar dat we in dit VLOCA traject willen verder gaan op de resultaten van dit traject en zien hoe dit kan gekaderd worden binnen een continue evolutie van de open stad architectuur binnen een VLOCA context, en dus ook gekoppeld worden aan andere trajecten.
Werkwijze (Hoe?)
Er werd beslist om in dit traject 2 workshops te organizeren. In de eerste workshop is het de bedoeling om een aantal actoren in het landschap die actueel bezig zijn met open databroker (en city) platformen aan het woord te laten en informatie te delen. Daarbij natuurlijk de steden die meegewerkt hebben aan het VLAIO CoT databroker project, de steden Brugge/Roeselare/Leuven die hier een aanbesteding voor een open smart city data platform voor lopen hebben, en Antwerpen die met ACPAAS een draaiend open smart city platform heeft.
Workshops
Werkgroep Type werkgroep Datum Tijd Locatie Data Broker Workshop 1 Business werkgroep 2021-02-03 Data Broker Workshop 2 Functionele werkgroep 2021-03-03
Op basis van de informatie en feedback uit de eerste workshop werd een eerste versie gemaakt van de open smart city referentie architectuur. Deze werd dan besproken in de tweede workshop met dezelfde stakeholders.
Resultaat (Wat?)
Bijdragen aan dit VLOCA traject
Datum
3 februari 2021
Deelnemers
Reinhard Stoop
Fraiponts Hans
Vlieberg Hans
De Craene Annlies
Limpens Geert
Nulens Lode
Rosseau Bart
Vanlishout Ziggy
Lenaerts Pieter
Lefever Stefan
Steijns Silke
Ottevaere Justine
Van Cauwenberghe Mieke
Libin Guy-Paul
Dumarey Nathalie
Scheenaerts Bart
Cornelissen Koen
Buyle Raf
Wyns Bart
Triangle Koen
Agenda
Intro & Context VLOCA
Voor meer info omtrent de intro & context van VLOCA klik hier
Voorstelling Architectuur Databroker Gent
COT VLAIO Traject in samenwerking met Brugge, Roeselare, A’pen en Gent
Vooral gewerkt in de richting van een bestek en dus geen implementatie in het COT project
Gedefinieerde uitdagingen situeren zich in 3 domeinen:
Technisch
Data zit toch vaak in silo's
Doel is om data te ontsluiten via een open source technologie stack gebaseerd op open Standaarden
Juridisch
Functioneel & Use cases
Definities opgesteld van:
Statische en real time data
Interoperabiliteit
Stabiliteit & performantie
Praktisch
Sensor data
Linked open data / semantisch en context gedefinieerd
Flexibele APIs
Overzicht bieden en register van de data
Daarnaast ook alle mogelijk contracten tussen de verschillende stakeholders in kaart gebracht
E.g. Platform eigenaar vs. service leverancier
E.g. Data leverancier vs. platform eigenaar
...
Voorstelling Aanbesteding Brugge (en partner steden)
De vraag is ook gesteld aan andere steden om deel te nemen
Op dit moment hebben 7-8 tal steden aangegeven deel te nemen
Bestekken kunnen ook worden gedeeld, eens het aanbestedingstraject is afgerond er een keuze is gemaakt
Voorstelling Architectuur ACPAAS & GIP Antwerpen
Operationele implementatie van een IoT pipeline voor Antwerpen
ACPAAS streeft naar generieke herbruikbare bouwblokken
Eilanden binnen domeinen open breken
Real time data en statische data
Streven naar een generiek data platform
Domein overschrijdend de data beschikbaar stellen
Steden / Gebruikers / politie / gezondheid
Platform is gegroeid uit synchronisity
Open Source / Zero licencing insteek voor de Componenten
Verschillende data stromen reeds beschikbaar:
Milieu
Cutler project: Pluvio meters, Grondwaterpeilmeter,...
KMI: Weersvoorspellingen
VMM : Luchtkwaliteit
VITO : Hittevoorspellingsdata
Weerstationsdata
Mobiliteit:
Velo stations
BEMobile: filebarometer
Bird/Circ (beschikbaarheid)
Poppy (beschikbaarheid & trips)
De Lijn
NMBS
Fietstellingen (signco)
Cambio
Blue-bike
Scooty trips
MOW Fietsverbindingen (tunnels en veer)
Overige
Afval Bigbelly
Afval ondergrondse sorteerstraten
Infra – Slimme fonteinen
Infra – DigAnt Parkings
Open discussie 1
Open source heeft ook een lopende kost – deze mag men niet onderschatten
Open data standaardisatie heeft ook een kost – update van de Standaarden heeft financiële impact
Elke data set heeft zijn kost
Maturiseren en onderhouden van data heeft ook een kost
Hoe gaan we DUET en andere zaken koppelen met bestaande platformen -> regelgeving en Standaarden zijn nodig om daar rond te werken
Met als doel om te aligneren wat er al bestaat
1 taal te spreken naar de toekomst toe
Doel is om die taal te definiëren
Er wordt door de steden naar Vlaanderen gekeken voor ontzorging
Als elke stad dezelfde kosten moet doen om te maturiseren en te operationaliseren -> grote kosten en dit kan beter op Vlaams niveau worden gebundeld
Rode draad doorheen de genoemde trajecten
OASC MIMS
Bestek van Brugge laat toe om kosten-delend te zijn
E.g. Telraam / Luftadata connecties moeten maar 1 keer gebeuren en bij voorkeur via NGSI LD en kunnen over heel Vlaanderen hergebruikt worden
Dit kan er wel voor zorgen dat de kosten makkelijk kunnen worden gedeeld
Welke standaard gaan we allemaal spreken om een zo groot mogelijk schaalvoordeel te realiseren?
NGSI-v2 - NGSI LD ? – dit is nog nader te bepalen
Quid 1 uniform platform voor heel Vlaanderen i.p.v. platformen per stad?
Droomscenario voor iedere stad
Optimaal mogelijk landschap om maximaal synergie te creëren
Afspraken rond Standaarden lijken hier noodzakelijk
Federated approach kan hier ook wel werken
Samen zitten met de vendors om hen te nudgen om de data aan te bieden in NGSI (LD)
E.g. Qweriu is bereid om dit te doen
Dat zorgt ervoor dat deze sensoren makkelijker worden onboard op een platform
Binnen OASC kan er worden gediscuteerd, maar het is aan de grotere overheid om knopen door te hakken
Nood aan het vastleggen van Standaarden die kan worden gecomminiceerd naar de toeleverancier
Een oproep naar Vlaanderen om rond standaardisatie knopen door te hakken want diverse steden zijn dit individueel aan het opstarten met alle risico's vandien
Toelichting relanceprojecten 'Smart City Sensor Platform' en 'MAAS'
Past in het AIV Relanceplan - sensordata platform & Vlaamse dataspace
Sensordata zijn een groeimarkt voor de data economie van morgen
Herbruikbare open source Componenten aanbieden aan de markt
Doelstellingen:
Open source Componenten aanbieden aan de markt
Kostenefficiënte publicaties van grote volumes van sensor data in real time toelaten
Interoperabiliteit staat centraal
Inzetten op open standaard – Sensor komt los van de leverancier
Ecosysteem van samenwerkende dataplatformen
Business voordelen
Innovatiesnelheid en time to market van Vlaamse bedrijven verhogen
Veerkracht van de vlaamse bedrijven
Realtime en gepersonaliseerde data zijn vereist voor digitale transformatie
Self service by design en betaalbaar te gebruiken door de gehele markt
Data publicatie raamwerk staat centraal – daarrond:
Datadiensten
Publishing component provider
Archiving infrastructuur
Data integratiediensten
Smart city service providers
Digipolis
Toepassingen
MaaS
Digital twins
Open discussie 2
Quid datanuts bedrijf en verhouding naar het ecosysteem
Datanuts is traject dat in volle ontwikkeling is
Focus op relance en de relatie met datanuts bedrijf zal in verdere fase nog worden uitgekristalliseerd
Datanutsbedrijf heeft dezelfde doelstellingen als gas/water = utilities voor data
Definiëring naar een gemeenschappelijke standaard / selecteren van de open source Componenten ?
Hoe ziet AIV dit evolueren?
Quid CEF - generieke bouwblokken van uit Europa?
2 sporenbeleid
Fit gap analyse en welke Componenten behoren door tot de kern. Dit moeten worden gemanaged door de overheid
Andere Componenten aankopen via gealligneerde tenders op de markt. Afspraken maken op gebied van interoperapbiliteit
Zou het zo ver gaan dat er een centraal IoT platform komt dat door de steden kan worden gebruikt? 2 pistes bekeken door AIV hieromtrent:
Kiezen voor 1 platform - sensor platform. Risico = 1 nieuwe koker met gebrek aan interop en dus te nauw gedefinieerd
Of het speelveld definiëren in een blauwdruk waar verder op kan worden gebouwd door eenieder (cfr. datanuts bedrijf)
Wat zou het ideale scenario zijn voor een datanutsbedrijf volgens de steden?
Volledig ontzorging rond data integratie, translatie, opvolging, beheer en onderhoud
Geen bijkomende budgetten voor steden opzetten = het walhalla voor de steden
Datanutsbedrijf = gatekeeper / bewaker in het geval van mislopen van bestekken of wijzigingen in formats
Data security en privacy ook meegenomen door datanutsbedrijf
Tussen Standaarden en platform zitten nog zaken die aandacht nodig hebben
Ontzorging bieden door data gestandaardiseerd te publiceren ( OSLO )
Toegankelijk (of beter toegankelijk) maken van data door open source Componenten (e.g.: open source Componenten folder)
Er zou moeten een levend ecosysteem zijn
Eigen platform in de markt zetten en hoe ziet AIV de relatie ten opzichte van de Componenten die al in de markt worden gezet?
En het definiëren van de Standaarden op basis van contracten van een leverancier die het platform gaat uitbuiten
Quid link tussen relance en de platformbouwers die het vandaag in de markt zetten
Samenwerking met AIV en hoe kan het 1 verhaal worden?
Brugge start reeds met een deel van het ecosysteem en er zijn geen afspraken met het ecosysteem dit zal worden gerealiseerd met het relanceplan
Wat als er wordt gewerkt naar een centraal sensordataplatform?
Want dan gaat het sensorplatform naast de initiatieven staan die vandaag al worden opgezet
Als er 1 platform is - dan zou Brugge daar ook gebruik van maken
Maar de dynamiek tussen het ecosysteem en de koppeling naar de markt is nog niet duidelijk. Dat moet nog worden uitgeklaard
Het gaat eigenlijk over een selectie van Standaarden + open source Componenten die key zijn en die implementeren en uitbreiden naar de behoeftes
Die worden dan ook als managed software beheerd door AIV -> een Vlaamse open source project
Specs worden samen opgesteld en getest en de testen beschikbaar stellen
De implementatie gebeurt door de steden zelf
Private spelers kunnen deze zaken ook opnemen op initiatief van de steden
Data governance zou een gedeeld probleem moeten zijn, zodat de industriële partijen weten waarop ze moeten inhaken
Het gaat om koppelstukken die ervoor zorgt dat de zaken aan elkaar kunnen worden gekoppeld
De behoefte van maximale ontzorging is noodzakelijk en belangrijk voor de steden
Minimaal moeten we kennisdeling stimuleren - dit kan aan de hand van een open source community
Datum
03 maart 2021
Deelnemers
Bart Wyns
Danny Willen
Annelies De Craene
Annelien Dierick
Helena Schulpé
Rik Hendrix
Geert Limpens
Lode Nulens
Mathias Van Compernolle
Justine Ottevaere
Philippe Michiels
Reinhard Stoop
Bart Scheenaerts
Silke Steijns
Stefan Lefever
Luc Stinissen
Dimitri Van Baelen
Barbara Van Broeckhoven
Mieke Van Cauwenberghe
Triangle Koen
Ziggy Vanlishout
Tim Guily
Presentatie
| VLOCA Traject Data Broker - Tweede Sessie - Presentatie
Agenda
Inleiding & reflectie vorige workshop
We proberen in deze workshop richting te geven aan wat een Databroker betekent en vertalen wat dit betekent voor Vlaanderen en de Steden -> streven naar samenwerking en verbinding. Doel van het databroker VLOCA traject is om Smart City bouwstenen te definiëren en te selecteren die voldoen aan VLOCA standaarden, silo's binnen de overheden vermijden en net data te activeren en te connecteren die leidt tot Smart Data Management. We willen daarbij niet alleen binnen de stad te kijken, maar ook breder zodat data kan worden geconnecteerd met andere platformen/databronnen (eg stedelijke data connecteren met modellen/simulatie data of met vb. een mobilidata databroker). Doelstelling van deze databroker sessie was ook om een aantal principes te aligneren in het kader van de relance nota. Linken van de behoeftes van steden met regio’s en die op elkaar afstemmen.
Welke rol speelt een databroker:
In Gent Databroker gaat het over een city (of things) data broker, met aandacht voor het economische, technische, legale en functionele plaatje. Daarbij zijn specifieke keuzes gemaakt voor bijvoorbeeld het gebruik van Linked Data
Aanbesteding Brugge gaat over een smart city data platform
In Antwerpen heeft ACPAAS ook het doel om te evolueren naar een generiek data platform
Deze initiatieven geven aan dat er verschillende ambities en initiatieven zijn die elkaar kunnen versterken.
Maar er zijn veel uitdagingen en vragen:
Software/data engineering en onderhoud
Open Source is goed, maar vraagt ook onderhoud
Evolutie van standaarden: hoe managen?
Data governance & architecture?
Waar kan Vlaanderen de steden ontzorgen?
Kan er sprake zijn van totale ontzorging?
Meer genuanceerd: welke elementen worden beter op regionaal niveau opgelost en welke lokaal?
Hoe kunnen de steden aligneren met de regionale ontzorging?
En bijvoorbeeld zich groeperen om economies of scale te krijgen?
Conflicteert het initiatief van B/R/L met relance plan? (sensorplatform bijvoorbeeld)
We kunnen daar vandaag al enkele richtinggevende antwoorden op geven:
Relanceplan gaat geen monoliet platform in de markt zetten
Focus op
Standaarden
Open source componenten en tools
Drempelverlagend voor publicatie van open linked data
Het [Data-nutsbedrijf] kan zeker een rol spelen in realisatie van het relance plan, maar is nog in volle definitie
Data governance zou een gedeeld probleem moeten zijn (regionale, lokale overheden ism industrie)
Ontzorging van steden op de goeie plaatsen is de uitdaging
Doelstelling van deze workshop:
Terminologie afstemmen rond databroker
Aangeven waar een databroker een rol opneemt in het federated landschap
Aantonen dat allignering met de verschillende initiatieven mogelijk is
Smart Data Management vraagt een holistische benadering
Nood aan een gelijkaardige terminologie:
Big Data is een vrij complex gegeven en evolueert door heen de tijd (3v’s -> 17v’s)
Daarom nood om een eenduidige definitie rond termen en concepten af te spreken voor Vlaanderen
Deze definities en termen zijn open voor co-creatie dus er is een uitnodiging om hier feedback over te geven op de kennishub
Terminologie
De terminologie rond een data broker vereist eenduidigheid. In dit traject kunnen we hier over co-creëeren.
Wat is een smart data architecture (regionaal/gefedereerd niveau)?
Wat is een smart city (data) platform?
Wat zijn belangrijke data eigenschappen en hun doelstellingen?
Wat zijn belangrijke data management capabilities?
Wat zijn belangrijke data definities?
Dit kunnen we tracken en definiëren op Termen en concepten
Wat is smart data (zie slide): From Big data to Smart Data
Smart data management en Smart Data governance zijn belangrijk
Samenwerking is nodig met het data landschap en hier kan een data broker een belangrijke rol spelen
Daarom dat het nuttig is dat VLOCA hier draaiboeken voor maakt en dit zorgt ervoor dat niet iedereen op zijn eiland werkt, maar dat we op een gestructureerd manier samen werken waardoor data makkelijk kan vloeien en kan samen werken om uiteindelijke meerwaarde te creëren in nuttige applicaties.
Het beheren van Smart data houdt veel capabilities in
Ook hier gaan we een aantal definities in VLOCA rond voorstellen - hierdoor kan er naar worden verwezen in aanbestedingen met als doel dat we uniforme termen gebruik en implementeren.
Terminologie is belangrijk in dit verhaal en zorgen dat we dezelfde mentale concepten begrijpen
Wat is een data broker (component) ?
Inzoomen op een data broker: wat is het en wat is het niet? Een eerste aanzet is te vinden op Data broker .
Er bestaan hierin verschillende instanties met een ander niveau van detail: City Data Broker, Regional Data Broker, Departementale Data Broker, Mobiliteits Data Broker, ...
Alsook verschillende maturiteitsniveau ’s.
De term wordt vaak breed gebruikt. De vraag is dan hoe dit te kaderen en plaatsen in het landschap.
Databrokerage is een element van heel veel capabilities van een Smart City omdat dat broker veel domeinen aanraken hebben we in VLOCA een stap terug gezet en is er gekeken naar een breder concept: Smart Data Management.
Tijdens de sessie wordt een eerste conceptuele versie van hoe dit vandaag is gedefinieerd voorgesteld en feedback is welkom.
Een aantal principes/domeinen van Smart Data Management worden besproken in de slides (eg. Dat Capture, Storage to scale, Process & Transform, Compute domein, Service laag,...).
De Databroker maakt dus een onderdeel uit van een smart data management. En Smart Data management wordt gekoppled aan een virtual Smart Data Platform. (Virtual = omdat het bestaat uit verschillende tenants/Instantiaties)
Verschillende data bronnen moeten over verschillende lagen/gebruikers kunnen worden gedeeld. Via een Virtueel Smart Data platform en een federated aanpak wordt dit gefaciliteerd.
Data Publishing
Een belangrijke data management capability is data publishing, en is 1 van de speerpunten in het relance plan van AIV.
Hoe verhoudt zich dat tot voorgaande topics en waar komen ze samen?
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.
Wat zijn de doelstellingen en welk effect beoogt AIV met het ‘sensor data platform’ dossier?
Sensordata zijn een groeimarkt voor de data-economie van morgen.
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 sensoragnoistisch wordt en loskomt van de leverancier van de sensor en vlot gerelateerd kan worden aan slow moving data (vb basisregisters)
¨*Ecosysteem van samenwerkende sensordata platformen tot stand brengen
Business voordelen
Innovatiesnelheid en time to market van Vlaamse bedrijven gevoelig verhogen -> veerkracht van de Vlaamse bedrijven stimuleren
Realtime en gepersonaliseerde data zijn een vereist voor digitale transformatie
Self service by design en betaalbaar te gebruiken door de gehele markt (incl KMO)
Zowel aan publicatie als aan gebruikers kant zorgen duurzaam data publiceren op een interoperabele manier
Verder bouwen op OSLO
Hergebruik toelaten en ervoor zorgen dat de data vindbaar is voor mens en machine
Hoe wilt AIV dit bereiken?
Standaarden ontwikkelen en implementeren dus ook voor LDES
Ecosysteem en community
Samenwerking publieke, private en academische wereld (inclusief de developers community)
Governance
Bouwblokken aanbieden als managed services
Walk trough door het Functionele Architectuur Ontwerp (ontwerp - nog niet finaal) - Volgende domeinen werden besproken (voor details zie slides)
Ruwe datastroom publiceren als interoperabele linked data stroom, linked Data event streams zijn het uitgangspunt
LDES(Linked Data Even Stream) Projecties voor verschillende doelen, afgeleide datastromen creëren die terug worden gepubliceerd als linked data even streams. Hierbij is mapping tussen APIs ook belangrijk. Het systeem is modulair, dus er kan worden gekozen welke componenten uit de projectie client wel of niet worden geïmplementeerd.
Verschillende LDES clients voor verschillende doelen zijn mogelijk. Bijvoorbeeld: In sommige use cases is het belangrijk om data op te slaan om bijvoorbeeld YTT scenario’s toe te laten.
Vindbaarheid, herkomst van de data. Belangrijk dat de data vindbaar is voor mens en machine inclusief de bijsluiter van de data. (cfr een metadatacatalogus)
Ontsluiten van data voor een fit for purpose manier. Hiervoor ook afstemmen op gebied van de opslagmethode
Open Discussie
AS IS => terugkoppeling naar de platformen uit de eerste aanbesteding: ACPAAS , Smart City Data Platform aanbesteding Brugge, VLAIO Data Broker Gent
Welke componenten zitten hier in. Wat is het City Data Brokering doel, en hoe kunnen deze platformen ook ingeschakeld worden in een Regional Data Broker?
TO BE => Waar willen we naar toe en welke realiteit van data brokerage op bv regionaal niveau ambiëren we?
Hoe gaan we verder, waar werken we samen aan (bv op de kennishub). Is er nood aan nog een workshop?
Reinhard Stoop:
Men gaat niet uit van 1 groot platform, maar modulair en federated aanpak is een goede zaak. Dus verschillende platform ipv 1 groot platform ?
Dat is inderdaad het doel en een samenspel van interoperabele componenten en dus geen grote monoliet
Sensoren die lichten moeten aansturen hebben een andere SLA bv. wegens operationaliteit
Sommige datastromen hebben een bepaalde SLA en belang -> waardoor ze op een andere manier moeten worden behandeld en mogelijks afgescheiden datastreams nodig hebben
Zit er in de data governance aspect van Vlaanderen ook iets rond standaarden on edge waardoor het doorvertalen en omzettingen vermeden wordt en dat de data dan al direct op de juiste manier beschikbaar gesteld door sensorleveranciers
We moeten het hergebruik van standaarden proberen aan te moedigen en dit moeten we doen via VLOCA
Hierdoor een VLOCA compliant score uit denken die kan worden toegepast in aanbestedingen
Ook de volledigheid van de data is belangrijk omdat je geen informatie mag missen voor modellen
Fit for purpose vs fit for model - dit kan andere requirements hebben
Danny Willen:
Hasselt is bezig met een referentie architectuur voor een breed data platform en hiervoor onderzoekt hij ook het concept van de Databroker:
Zou voornamelijk de service laag vervullen en de data capturing / misschien wat governance
Wat verrast rond processing en ML dat die als een capability van data broker worden gezien
Gaat de databroker toch verder dan pub sub van de data en dus ook verwerking van data meenemen?
Klopt, de definities zijn uitlopend, maar puur volgens de term van brokerage is data brokerage een middelman die connecties legt
Maar het Smart Data Management gaat net breder en neemt diverse domeinen mee, zodat die kunnen worden vertaald naar een technische architectuur en technische componenten.
Voor Urban Digital Twins zijn modellen belangrijk en daarom benadert deze voorstellen het breder
Hoe ga je van dit concept naar materialisatie?
Welk deel laten we afdekken door een databroker van Vlaanderen en welk deel moeten de Steden zelf ontwikkelen?
VLOCA = conceptuele architectuur oefening
Maar er wordt gesproken over tenants - dus wil dit dan toch zeggen dat er een implementatie komt waar de lokale overheden van kunnen afnemen?
Er zullen centrale componenten waar lokale overheden kunnen van afnemen -> vermijden van het wiel opnieuw uit te vinden
Maar VLOCA is inderdaad een conceptuele oefeningen, implementatie zal in andere projecten gebeuren
De ambitie moet zijn om naar een open ecosysteem te evolueren om samen te werken. Er is de visie om te evolueren naar een makkelijkere en gedeelde manier van data te delen
Leeft het idee om dit te implementeren?
Ja, de volgende stappen zijn:
De technische architectuur beschrijft de componenten
En de kwantitatieve en kwalitatieve componenten beschrijven
Omdat je dan op basis van de behoeftes consequenties kan definiëren en deze zaken mee nemen in aanbestedingen
Wil Vlaanderen een platform aanbieden?
Er is te bekijken op welke manier dit past in het relance plan en hoe dit wordt geïmplementeerd
Tim Guily:
Het is een combinatie van verschillende platformen of componenten?
Beiden - aaneenschakeling van componenten die een platform kunnen worden
Is de markt klaar voor deze aanpak? omdat er wordt geraakt aan een aantal business modellen van industrie spelers:
Want Steden willen wel nog met mature producten over blijven on the long run en niet werken met POCs
Voldoende vinger aan de pols bij de markt om te voelen dat ze er klaar voor zijn?
Business impact is belangrijk, maar daarom dat we ook een VLOCA compliant score aanmaken zodat in aanbesteden er kan worden geëvalueerd in welke mate aanbestedingen in lijn zijn met de visie
Op deze manier kan er stap voor stap worden geëvolueerd naar Smart Data Management
Bepaalde zaken moeten ook een wetgevend kader krijgen (eg OSLO)
En imec krijgt in Coock Open Stad wel positieve signalen van de markt/industrie om mee te werken
Toevoeging van Reinhard via de chat:
Wat de vraag 'wat ontbreekt nog?" betreft denk ik dat zeker GIS als geo data met eigen specifieke standaarden nog zijn plaats moeten krijgen , ook in het compute onderdeel zou dit een plaats moeten krijgen. GIS analyse is vrij specifiek. In een stedelijke omgeving is geo vrij key niet enkel als context element maar ook als datakey, als analyse element en als outcome , wie wat , waar .
Na deze gesprekken werd er teruggekoppeld naar waar we zijn geëndigd in de vorige Workshop.
Voorbeeldaanbesteding Brugge / Roeselare / Leuven:
Bestaat uit componenten en een modulair platform
De vraag is dus hoe kan Brugge hierop aligneren
Voor elke component is er een korte toelichting gegeven in het bestek
Niet alles is must have voor Brugge omdat bepaalde
Zij willen eerst (1) data stromen hebben en ze daarna (2) onboarden en daarna (3) ontsluiten (naar een Urban Digital Twin / open data platform)
Hoe past een smart data platform met een Digital Twin / Modellen / Mobilidata platform? -> zijn zaken die in het Urban Digital Twin VLOCA traject worden opgenomen
Korte update van Reinhard over GIP Antwerpen - Generieke IoT data Platform
In het kader van Europees project gebouwd
Open Source en operationaliseren van dit platform kost geld
Er wordt nu een evaluatie gedaan van het platform om te bekijken in welke vorm dit wordt verder gezet
Zij willen ook beslissingen nemen rond standaarden en welke componenten ze zelf willen aanmaken
Ze willen dus een aantal beslissingen nemen en stappen zetten rond mobiliteit en water
Leuven vindt dat ze nu een groot risico nemen om te starten met een Smart Data Platform. Want de oplossingen zijn belangrijk (in en output van data). Maar ook het gebruiken van het Smart Data platform en de ontwikkeling - want hoe meer het wordt gebruikt hoe duurder het wordt. Er zijn 2 dingen waarop moeten worden gewerkt en waar steden ondersteuning voor nodig hebben: oplossingen (=input en output / use cases) en het platform zelf – te bekijken hoe deze beide paarden aan hetzelfde tempo kunnen blijven lopen.
Bevat componenten
Bouwlagen +
Een data formaat is de organizatie van informatie volgens een aantal ge-predefinieerde specificaties.
Voorbeelden van data formaten zijn tekst bestanden, binaire bestanden, AVRO data bestanden, Parquet bestandsformaten, ...
Een data formaat is dus een fysische representatie (serialisatie) van data (waarden) die meestal geoptimaliseerd is voor efficientie van data opslag of data uitwisseling. De specificatie kan impliciet of expliciet (bv. volgens een officiele standaard) zijn.
Data kan op die manier aangeboden worden als :
gestructeerde data. Deze data heeft een gepredefinieerd data formaat meestal als de structuur van een verzameling alvorens die opgeslagen wordt. Het beste voorbeeld hier is de relationele database, waar de data geformatteerd is in precies gedefinieerde velden, om gemakkelijk opgevraagd te kunnen worden, bijvoorbeeld door SQL. Voorbeelden can zulke data formaten zijn RDF, Parquet, Avro. Deze data worden vaak opgeslagen in data warehouses.
semi-gestrucutureerde data. Is gestructureerde data die niet voldoet aan de formele structuur van een relationele database, maar wel tagging of andere markers gebruikt om verschillende elementen van elkaar te scheiden. De data heeft een zelf-beschrijvend formaat. Voorbeelden van zule data formaten zijn JSON, CSV, XML, NGSI-LD, ...
ongestructureerde data. Dit is data die wordt opgeslagen zonder data formaat. Voorbeelden zijn text en binaire blobs, video, email, ... Deze data wordt vaak opgeslagen in data lakes. +
Data governance is een data management activiteit die instaat voor het waarborgen van data kwaliteit gedurende de volledige levenscyclus van de data in een organisatie. +
+++/// PAGINA IN OPMAAK \\\+++ Doel en doelgroep Finaliteit:
Antwoord op datagovernanceact --> weten hoe met data omgaan voor specifieke use cases en hoe bewaken?
Generiek model specifiek ingevuld
Inleiding Vragen die we adhv data governance model willen beantwoorden:
Welke data wel en welke data niet toegangkelijk en bruikbaar (met vemelding van specifieke databronnen per traject), onderscheid per gebruiker? Matrix welke data mag door wie gebruikt worden?
Hoe verschilt een data governance model van principes? Mix van generieke en specifieke bepalingen?
Wie is de eigenaar van de data?
(FAIR) Data-principes
Sector specifieke bepalingen
Bescherming van gegevens, de persoonlijke levenssfeer en de integriteit van het individu/ Persoonsgegevens indien van toepassing: privacyvriendelijkere gegevensverwerking/ GDPR
Commercieel vertrouwelijke gegevens
Uitwerking van architectuur volgens "open door ontwerp en door standaardinstellingen"
Datagovernancemodel is niet-discriminerend, transparant, evenredig en objectief gerechtvaardigd
Hebruik van data om verder onderzoek en gebruik te bevorderen.
Afdwingbaarheid/ contract voor data gebruik/ commitment?
Kan worden bewezen dat privacy en vertrouwelijkheid werd gewaarborgd?
Concurrerend klimaat voor gegevensdeling : neutraliteit van de aanbieders van databemiddelingsdiensten?
Willen wij aangeven welke data aanbieders data-altruïstisch is of moet dit eigen zijn aan partnerschap/ VLOCA 'charter'/ vrijwillige registratie?
Kan een toelating tot gebruik van data worden ingetrokken?
Reglement met informatie, technische en beveiligingsvereisten, en stappenplannen voor communicatie en interoperabiliteitsnormen?
Willen we definities opnemen in het datagovernancemodel? (bv art. 2 datagovernanceverorderdening)
Toepassingsgebied? (bv art. 3 datagovernanceverordening)
Vergoeding (art. 6)
Toezicht op naleving? (art. 14)
(rol van ) VLOCA als/ voor erkende org voor Data altruïsme? (art. 17)
Transparantievereisten (art. 20)
Hoort data lineage thuis in een datagovernancemodel?
Datagovernanceverordening
De Europese Datagovernanceverordening van 30 mei 2022 kwam tot stand om ...
Het moet ook de versterking van de open strategische autonomie van de Unie waarborgen, en tegelijk het internationale vrije verkeer van gegevens bevorderen .
Gegevens zijn de hoeksteen van die transformatie: datagestuurde innovatie
Verkleinen van de digitale kloof.
Neutraliteit van de toegang tot en de overdraagbaarheid en interoperabiliteit van gegevens moeten worden gewaarborgd en lock-in-effecten moeten worden vermeden.
FAIR -data principes.
Voor het ontwerp, de totstandkoming en de handhaving van het gelijke speelveld in de data-economie is goede governance nodig waaraan alle belanghebbenden van een gemeenschappelijke Europese gegevensruimte moeten deelnemen en waarin zij vertegenwoordigd moeten zijn.
Deze verordening moet gericht zijn op de verdere ontwikkeling van de digitale interne markt zonder grenzen en een betrouwbare en veilige datasamenleving en -economie waarin mensen centraal staan .
Rechtspersonen die doeleinden van algemeen belang wensen te ondersteunen door op basis van data-altruïsme op een bepaalde schaal relevante gegevens beschikbaar te stellen en die aan de in deze verordening neergelegde vereisten voldoen, moeten zich kunnen registreren als “in de Unie erkende organisatie voor data-altruïsme” en moeten dat label kunnen gebruiken .
Een Uniebreed governancekader moet als doel hebben vertrouwen te scheppen bij personen en ondernemingen wat betreft de toegang tot, de controle over, alsook het delen, het gebruik en het hergebruik van gegevens , met name door passende mechanismen in te stellen die het voor datasubjecten mogelijk maken om hun rechten te kennen en op zinvolle wijze uit te oefenen , alsook inzake het hergebruik van bepaalde soorten gegevens die in het bezit zijn van openbare lichamen, het verlenen van diensten door aanbieders van databemiddelingsdiensten aan datasubjecten, gegevenshouders en gegevensgebruikers, alsmede het verzamelen en verwerken van gegevens die door natuurlijke en rechtspersonen voor altruïstische doeleinden beschikbaar worden gesteld . Een grotere transparantie ten aanzien van het doel van het gebruik en de wijze van opslag van gegevens door ondernemingen kan met name helpen om het vertrouwen te versterken .
Er zijn technieken die analyses van databanken met persoonsgegevens mogelijk maken, zoals anonimisering, differentiële privacy, generalisering, onderdrukking en randomisering, het gebruik van synthetische gegevens of soortgelijke methoden, en andere geavanceerde methoden om de privacy te beschermen , die kunnen bijdragen tot een privacyvriendelijkere gegevensverwerking .
Aansporen om gegevens te genereren en beschikbaar te stellen overeenkomstig het beginsel “open door ontwerp en door standaardinstellingen” (“open by design and by default”).
Commercieel vertrouwelijke gegevens zijn gegevens die beschermd zijn door bedrijfsgeheimen, beschermde knowhow en alle andere informatie waarvan de ongeoorloofde openbaarmaking gevolgen zou hebben voor de marktpositie of de financiële gezondheid van de onderneming.
Bescherming van gegevens, de persoonlijke levenssfeer en de integriteit van het individu.
Elke lidstaat daarom kunnen beslissen of gegevens toegankelijk worden gemaakt voor hergebruik, en over het doel en de reikwijdte van die toegang .
Voorwaarden moeten niet-discriminerend, transparant, evenredig en objectief gerechtvaardigd zijn en mogen de mededinging niet beperken.
De voorwaarden voor hergebruik moeten zodanig worden ontworpen dat zij wetenschappelijk onderzoek bevorderen .
Openbare lichamen moeten vergoedingen kunnen aanrekenen voor het hergebruik van gegevens, maar moeten, in overeenstemming met de staatssteunregels, ook hergebruik tegen een gereduceerde vergoeding of kosteloos hergebruik kunnen toestaan, bijvoorbeeld voor bepaalde categorieën hergebruik, zoals niet-commercieel hergebruik voor wetenschappelijke onderzoeksdoeleinden, of hergebruik door kmo's en start-ups, maatschappelijke organisaties en onderwijsinstellingen, om dergelijk hergebruik ten behoeve van onderzoek en innovatie te stimuleren en ondernemingen te ondersteunen die een belangrijke bron van innovatie vormen en het oorgaans moeilijker vinden om zelf relevante gegevens te verzamelen.
Technische middelen om een beveiligde verwerkingsomgeving beschikbaar te stellen of de technische middelen om privacy en vertrouwelijkheid te waarborgen indien toegang tot het hergebruik van gegevens die binnen het toepassingsgebied van deze verordening vallen, werd verleend.
Van databemiddelingsdiensten wordt verwacht dat zij een sleutelrol spelen in de data-economie , met name bij het ondersteunen en bevorderen van vrijwillige praktijken voor het delen van gegevens tussen ondernemingen of bij het faciliteren van gegevensdeling in het kader van verplichtingen op basis van het Unierecht of het nationale recht. Zij kunnen een facilitator worden van de uitwisseling van aanzienlijke hoeveelheden relevante gegevens.
Aanbieders van databemiddelingsdiensten moeten aanvullende specifieke instrumenten en diensten aan gegevenshouders en datasubjecten kunnen aanbieden met het specifieke doel de gegevensuitwisseling te faciliteren , zoals tijdelijke opslag, curatie, conversie, anonimisering en pseudonimisering. Tegelijkertijd moeten anbieders van databemiddelingsdiensten de mogelijkheid krijgen om de uitgewisselde gegevens aan te passen , bijvoorbeeld door ze om te zetten in een specifiek format, teneinde de bruikbaarheid van de gegevens voor de gegevensgebruiker te verbeteren wanneer de gegevensgebruiker dat wenst, of teneinde de interoperabiliteit te verbeteren .
Het is belangrijk om voor een concurrerend klimaat voor gegevensdeling te zorgen. Een belangrijk element om het vertrouwen en de controle van gegevenshouders, datasubjecten en gegevensgebruikers met betrekking tot databemiddelingsdiensten te versterken, is de neutraliteit van de aanbieders van databemiddelingsdiensten met betrekking tot de tussen gegevenshouders of datasubjecten en gegevensgebruikers uitgewisselde gegevens. Daarom is het noodzakelijk dat aanbieders van databemiddelingsdiensten uitsluitend optreden als tussenpersoon bij de transacties en de uitgewisselde gegevens niet voor andere doeleinden gebruiken .
Er is een groot potentieel voor doeleinden van algemeen belang bij het gebruik van gegevens die vrijwillig door datasubjecten beschikbaar worden gesteld op basis van hun geïnformeerde toestemming of, wanneer het niet-persoonsgebonden gegevens betreft, die door gegevenshouders beschikbaar worden gesteld. Tot dergelijke doeleinden behoren gezondheidszorg, bestrijding van de klimaatverandering, mobiliteitsverbetering, facilitering van de ontwikkeling, productie en verspreiding van officiële statistieken, verbetering van openbare diensten, of openbare besluitvorming. Steun voor wetenschappelijk onderzoek moet ook worden beschouwd als een doeleinde van algemeen belang.
Om datasubjecten en gegevenshouders te helpen om erkende organisaties voor data-altruïsme eenvoudig te identificeren en aldus hun vertrouwen in die organisaties te vergroten, moet er een gemeenschappelijk logo worden ingevoerd dat in de hele Unie herkenbaar is. Het gemeenschappelijke logo moet vergezeld gaan van een QR-code met een link naar het openbaar Unieregister van erkende organisaties voor data-altruïsme.
Om het vertrouwen te bevorderen en extra rechtszekerheid en gebruikersvriendelijkheid te bieden bij het proces inzake het verlenen en intrekken van toestemming, met name in het kader van wetenschappelijk onderzoek en statistisch gebruik van gegevens die uit altruïsme beschikbaar worden gesteld, moet een Europees toestemmings formulier voor data-altruïsme worden ontwikkeld en gebruikt in de context van het altruïstisch delen van gegevens. Dat formulier moet datasubjecten meer transparantie verschaffen over het feit dat hun gegevens zullen worden geraadpleegd en gebruikt in overeenstemming met hun toestemming en met volledige inachtneming van de regels inzake gegevensbescherming. Het formulier moet ook het verlenen en intrekken van toestemming faciliteren en worden gebruikt om het data-altruïsme van ondernemingen te stroomlijnen en die ondernemingen een mechanisme te bieden om hun toelating tot het gebruik van de gegevens in te trekken.
Reglement op te stellen voor erkende organisaties voor data-altruïsme met daarin informatie, technische en beveiligingsvereisten, en stappenplannen voor communicatie en interoperabiliteitsnormen die die organisaties in acht moeten nemen.
Daar de doelstellingen van deze verordening, te weten het hergebruik binnen de Unie van bepaalde categorieën gegevens die in het bezit zijn van openbare lichamen en de vaststelling van een aanmeldings- en toezichtskader voor de verstrekking van databemiddelingsdiensten, een kader voor de vrijwillige registratie van entiteiten die voor altruïstische doeleinden gegevens beschikbaar stellen en een kader voor de oprichting van een Europees Comité voor gegevensinnovatie, ...
Data Lineage is metadata die aangeeft waar data vandaan komt en hoe deze werd berekend. Ook waar de data naartoe gaat kadert daar onder. +
Data Ownership (eigenaarschap) refereert zowel naar het bezit van de data als de verantwoordelijkheid voor de informatie die de data levert. Het gaat over het wettelijk recht hebben over de data. Daarbij gepaard moet dus ook geregeld worden hoe de data kan verkregen worden (onder welke voorwaarden), gebruikt worden, verrijkt worden, en opnieuw verdeeld worden. Dit kan geregeld worden in licenties of andere overeenkomsten. Open Data is data die onder een open licentie gedeeld wordt. Data Sovereignty is een term die ook een legaal karakter heeft, maar gaat eerder over het concept dat de data die iemand verzamelt, opslaat en verwerkt onderworpen is aan de wetten van de regio (land) waar de data fysisch gelokaliseerd is. +
Data Portability is een concept om gebruikers te beschermen tegen het opslaan van hun data in silo's. Daarbij moet het mogelijk zijn om via standaard formaten de data uit te lezen en over te dragen naar een andere plaats. Dit recht op data porteerbaarheid werd ingeschreven in de GDPR wetgeving. Dit gaat voornamelijk ook persoonlijke data. De persoonsdata moet in een machine-leesbaar formaat worden aangeleverd door de organisaties die dit in gebruik hebben. Dit machine-leesbaar formaat kan bijvoorbeeld XML, JSON, CSV, ... zijn. De doelstelling hiervan is dat het hergebruik van de data gemakkelijk is. +
Data Kwaliteit beschrijft of data geschikt is voor het doel in de specifieke context (bijvoorbeeld data analyse). Hoe bepaal je of de data voldoet aan de kwaliteitseisen ?
Er worden (niet exhaustief) een 5-tal subparameters gebruikt :
Accuraatheid : is de informatie correct in zijn details. Heeft de data calibratie/validatie nodig en is dit al gebeurd ?
Compleetheid : Hoe compleet is de data, hoe uitgebreid of is er nog aggregatie/verfijning nodig om tot het doel te komen?
Betrouwbaarheid : Is de data tegenstrijdig met andere betrouwbare bronnen.
Relevantie : Heb je de data echt nodig ?
Timeliness : Hoe up-to-date is de informatie ? Kan deze gebruikt worden voor real-time rapportering ? +
Een data schema beschrijft de structuur van een data model. Dat kan bijvoorbeeld de structuur zijn van een database, waar het schema (in tekst en grafisch) de tabellen, velden, relaties, indezes, ... beschrijft.
Een voorbeeld van een data schema taal is SHACL. SHACL kan gebruikt worden om de structuur van data (opgeslagen in RDF of JSON of gelijkaardige formaten) te beschrijven. SHACL bevat een RDF vocabularium van klassen, eigenschappen en mogelijkheden om de integriteit van data elementen te beschrijven. Dit draagt sterk bij tot het verhogen van de Data Kwaliteit.
Andere voorbeelden zijn XML schema's of RDFS. +
Data Space in Flanders – how to support the Flemish data economy
Data spaces are not a new concept. The idea that data can be shared across organisations, that this has high societal potential, and that it is not easy to achieve, has been around for at least 25 years. It was already the underlying tenet of the Electronic Data Interchange (EDI) efforts at the end of the 90's and beginning of the 00's and was also the prime motivation for developing a semantic web. Even though the issue may have been in part solved for rather business data that does not change a lot (which we'll call "slow moving" in this paper), the emergence of fast moving data that emanated from e.g. Internet of Things sensors has introduced new challenges to the sharing of data.
Data spaces
We define a data space as "a set of data coming from a variety of data sources". A data space is an essential concept in allowing the sharing of data between various actors in a data ecosystem, by which we refer to "a loose set of interacting actors that directly or indirectly consume, produce, or provide data and other related resources." [1] There is therefore an inherent relation between a data ecosystem and a data space: the data space is composed of a data which is exchanged between the members of the data ecosystem.
Data spaces are defined by the applications that use them. An application will need a number of data sources to function and it is this set of data sources to which we refer as a data space. There is therefore not one data space, but an almost unlimited number of data spaces, represented by all the combinations of existing data sources. In a data ecosystem, we count 3 types of participants:
Data consumers
Developers
End-users
Data providers
Open data providers
Closed data providers
Data space federators
When we refer to organisations in a data spaces, we aim to denote government organisations, not for profit organisations or private companies. Data consumers are the actors that define the data space through their data needs. Among the data consumers, we count both the developers that build applications and the end-users that use the applications that are built by the developers. In terms of data providers, we mainly see organisation or private entities that provide open data or closed data.
Principles
FAIR Data
SMART data
Data Sovereignity
Federation vs centralisation
How can data spaces benefit the economy?
From a macro-economic point of view, there are costs to a lack of interoperability. A lack of interoperability will lead to fewer competitors and a winner-takes all logic. As entry barriers are introduced, a few winners will develop market power and keep competitors from entering in a market. Fewer competitors mean that dominating companies can controle prices, which leads to inflation and a general higher cost for society and especially for consumers. High market power has been calculated to be as high as 9% of GDP. Making sure that interoperability exists between organisations in terms of data sharing can lower entry barriers to new companies and thus allow a beneficial effect on prices. The market has a very limited incentive to making sure that such interoperability exists, which means that governmental actors has a substantial role to play.
Related initiatives
GAIA-X
IDSA
BDVA
FIWare
CEF
EIF
Sensor data platform
Datanutsbedrijf
Vlaams actieplan Artificiële Intelligentie
SolidLab
Living-in.eu
NxtPort
ETP Alice
Cases
Environment
Logistics
Mobility
Health
How can data spaces be implemented in Flanders?
↑ https://www.gaia-x.eu/pdf/Gaia-X_Architecture_Document_2103.pdf
Data karakteristieken (niet exhaustief)
Historisch gezien is data steeds belangrijker geworden, en werden de uitdagingen steeds groter.
In 2001, werden de karakteristieken van Big Data samengevat onder de 3 V's : Data Volume, Verocity en Variety.
Daar kwam later een 4e V bij namelijk Variety.
De 5 V's werden later Volume, Variety, Value, Variability, Velocity.
In 2014 werden dan de 10 V's van big data opgesteld, door het toevoegen van Validity, Venue, Vocabulary en Vagueness.
En tegenwoordig spreken we over de 14 V's + 1C van Big Data (+ Complexity, Viscoscity, Virality, Visualization, Volatility, Validity)
De uitdaging van deze tijd is om van big data smart data te maken. Smart Data wordt o.a. hier omschreven : https://ec.europa.eu/social/BlobServlet?docId=17367&langId=en .
Schematisch ziet deze evolutie er als volgt uit :
Enkele belangrijke karakteristieken worden hier verder omschreven :
data velocity
data variety
data volume
data veracity
data quality
data protection
data security
data semantics
data ownership
Lijst met data management capabilities (niet exhaustief)
Versioning
Querying
Verifying
Aggregation
Archiving
Merging
Joining
Storing
Publishing
Brokering
Registering
Authentication
Licensing
Discovery
Annotation
Modeling
Governance
Architecture
Enkele fundamentele smart data attributen/begrippen en hun relaties en Semantic Web data technologieen
Data Format (data serialization)
Data Syntax
Technical Scheme
Data Scheme
Data Taxonomie
Data Ontology
Data Vocabulary +
Data Variety is de verscheidenheid aan data in een data verzameling, of in een probleem domein. Een grote verscheidenheid maakt het heel moeilijk om de data te uniformiseren, en dus qua IT systemen te optimaliseren. Het is 1 van de grootste uitdagingen in cross-domein applicaties. Verscheidenheid kan bijvoorbeeld uitgedrukt worden in data formaten of structuren, die het meer of minder mogelijk maken om data binnen te lezen in machines.
Er bestaan 3 types data :
gestructureerde data : verwijst naar data die voorgedefineerd and geformatteerd is (heeft dus een data formaat ), meestel in een structuur due gemakkelijk kan weggeschreven worden in een opslag medium. Een mooi voorbeeld hier is een relationele database. De data wordt zo in tabellen geformatteerd dat deze gemakkelijk kunnen opgeslagen en bevraagd worden (bv via SQL). Gestructureerde data is dus vrij rigide in zijn data formaat en hangt af van de creatie van een data model dat definieert welke data types moeten gebruikt worden en hoe die moeten opgeslagen en verwerkt worden. Voorbeelden zijn RDF, Parquet, Avro. Deze data wordt vaak opgeslagen in data warehouses.
semi-gestructureerde data : dit is gestructureerde data die niet echt past in een formele structuur van een relationele database, maar wel nog tagging of andere markering gebruikt om elementen te scheiden van elkaar. Het is data met een "zelf-beschrijvend formaat". Een typisch voorbeeld zijn smartphone foto's die ongestructureerde beeld data bevatten, maar met metadata met de opnamentijd, locatie en andere geindentificeerde informatie. Typische data formaten zijn JSON, CSV, XML,... IoT data bijvoorbeeld die in het formaat JSON-LD is, kan beschouwd worden als semi-gestructureerd.
ongestructureerde data : dit is data die opgeslagen wordt als een "blob", zonder formaat en structuur en die dus onbehandeld blijft to deze gebruikt wordt. Voorbeelden zijn CSV, TSV, Excel, email, text blobs, sociale media posts, IoT sensor data, satelietbeelden, ... Deze data wordt vaak opgeslagen in data lakes.
Data Velocity (snelheid) refereert naar de snelheid waarop data wordt gegenereerd, verdeeld, verzameld en aangeboden. Hoe snel komt data binnen ? Een voorbeeld is Facebook waar elke dag een tsunami van foto's binnen komt om te verwerken, opslaan, terug ophalen,... Ook aggregatie van datastromen (zoals bijvoorbeeld verkeerslichten) kan voor heel wat data zorgen op een korte tijd. Hoge snelheids data vereist specifieke verwerkingstechnieken en systemen (zoals streaming technologie). Tegenwoordig is het ook mogelijk om "on-the-fly" analyze uit te voeren op hoge snelheids data. +
Data Veracity gaat over de (on)zekerheidsfactor, waarheidsgetrouwheid van de data. Is de data die aangeleverd wordt accuraat genoeg, is ze betrouwbaar, is de kwaliteit hoog genoeg voor mijn doeleinden ? Veel big data wordt niet gebruikt, omdat de informatie die uit de data komt niet als betrouwbaar gezien wordt. Het beheren van data veracity, door bijvoorbeeld context toe te voegen aan de data of de data semantisch te linken met bestaande definities, ... is een grote uitdaging. Data governance kan hier ook een grote rol in spelen. Of aangeleverde data een bepaald doel dient (om bv. in AI gebruikt te worden) is een enorme uitdaging, maar fundamenteel voor het succes van data intelligence.
Dit gaat ook over de informatie over de herkomst en betrouwbaarheid van de databron : is de databron gekend, de context van de data productie, werd de data door iemand anders aangepast, ...
enkele voorbeelden van oorzaken van Data Veracity :
Bugs : data wordt verkeerd getransformeerd door een bug
Abnormaliteiten : 2 naast elkaar liggende weerstations vertonen totaal verschillende waarden
Fake Data : valse berichten verspreid in sociale media
Data Lineage : een organizatie krijgt data van verschillende bronnen en ontdekt dat 1 van de bronnen zeer onnauwkeurig is, maar beschikt niet over de Data Lineage informatie om te weten waar die bron is verwerkt op verschillende plaatsen. +