Data en informatie werkgroep: Slimme stadsdistributie
Tijdens de eerste thematische werkgroep worden de data en informatienoden van de reeds geïdentificeerde use cases in kaart gebracht. De Werkgroep Data en Informatie staat open voor deelname door de gehele quadruple helix. Vaste deelnemers zijn de leden van het VLOCA-trajectconsortium en stakeholders, die samen de data- en informatienoden in kaart brengen.
De verzamelde inzichten worden vervolgens verwerkt om de data- en informatiearchitectuur verder aan te vullen.
De Data en informatie werkgroep vond plaats op Fout: ongeldige tijd..
Deelnemers
| Organisatie | Deelnemer |
| Agentschap Binnenlands bestuur (VLOCA) | Fabian de la Meilleure |
| Laurien Renders | |
| Paul De Wilde | |
| Alain Glickman | |
| Stad Hasselt | Kim Bos |
| Michèle Martens | |
| Stad Leuven | Marij Lambert |
| Bpost | Wim Rosseel |
| Buki Owa | |
| Alain Van Daele | |
| FEBETRA | Isabelle De Maegt |
| VIL | Domien Stubbe |
| VOKA | Wim Pannecoucke |
| TLV | Frederic Keymeulen |
| KU Leuven Instituut voor Mobiliteit | Carolien Lavigne |
| MyCSN NV | Jan Geukens |
Aanleiding en Context
Initiatief
Het City of Things project Slimme stadsdistributie vanuit stad Hasselt gaat over de transitie naar een leefbare en veilige binnenstad. Hierbij moet enerzijds rekening gehouden worden met autovrije/autoluwe delen, maar anderzijds zijn er ook grote behoeften naar steeds meer logistieke stromen in de binnenstad. Dit laatste is een effect van snelle leveringen die men tegenwoordig als maar liever ziet gebeuren alsook de sterke groei in e-commerce welke geboost is door COVID-19. Het resultaat van deze groei in logistieke stromen zorgt dat de leefbaarheid in de stad onder druk komt te staan. Om gerichte acties te kunnen nemen, moet men zicht krijgen op leveringen die in de binnenstad gebeuren, dit geeft ruimte om te kijken naar een data gedreven innovatie. Er zijn heel wat globale mobiliteitsdoelstellingen die ook van toepassing zijn voor stadsdistributie. Zo kijkt men enerzijds naar het verminderen van negatieve effecten zoals emissies en overlast. Anderzijds kijkt men dan naar het versterken van positieve effecten, zoals het verhogen van verkeersveiligheid, stimuleren van duurzaam ondernemerschap. Om dit te kunnen bereiken wordt gekeken naar slimme oplossingen.
VLOCA
Vloca-principes
Om te beginnen werden de VLOCA-principes toegelicht:
VLOCA staat voor:
- Transparantie: alle ontwikkelingen en verworven kennis wordt transparant op de kennishub geplaatst, voor iedereen bereikbaar met zelfs de mogelijkheid om zaken aan te vullen;
- Schaalbaarheid: de use cases vormen steeds het startpunt van de analyse waarbij er steeds rekening gehouden wordt hoe men los van een bepaalde technologie een oplossing kan uitgewerkt worden;
- Technologisch agnostisch: VLOCA houdt niet vast aan één bepaalde technologie. De use cases vormen het startpunt en hierbij wordt nagedacht hoe er los van een bepaalde technologie een oplossing kan uitgewerkt worden;
- Gebruikersgericht: oplossingen worden uitgedacht in functie van het standpunt van de eindgebruiker;
- Interoperabel: de oplossingen kaderen nooit in slechts één project maar zijn bruikbaar voor huidige en toekomstige trajecten;
- Duurzaamheid: de oplossingen die gegenereerd worden zijn niet enkel bruikbaar op korte termijn, maar ook voor de toekomst.
Proces
Binnen VLOCA vertrekt men steeds vanuit de use cases die in de vorige sessies geïdentificeerd en gevalideerd werden. Daarnaast konden ook een aantal datanoden gedistilleerd worden. De opzet van de eerste thematische werkgroep is om de datanoden en informatiestromen verder in kaart te brengen en te capteren wat de metagegevens zijn. Daarnaast worden ook de andere gegevens die gekoppeld zijn aan data en informatiestromen-en bronnen geïdentificeerd. De volgende stap in het proces is de verwerking van deze informatie in de architectuur. Hierbij maken we effectief de brug van de business naar de IT zijde.
Werkgroepen
Tot nu toe hebben we de opstartvergadering en de business werkgroep tezamen met OSLO georganiseerd. Vanaf nu gaan we elk onze eigen weg (maar tegelijk ook weer niet). Hoewel de komende werkgroepen los van elkaar plaatsvinden, is er een constante uitwisseling van informatie tussen OSLO en VLOCA om een complementaire uitkomst te garanderen.
Samenvatting vorige werkgroep
Het verslag van de vorige werkgroep met een overzicht van alle use cases en concepten kan je hier terugvinden.
Oefeningen werkgroep
Toelichting use-cases
Vooraleer we in de oefeningen konden duiken, werden de twee use cases waarop we zouden werken, toegelicht.
De eerste use case was gericht op 'registratie, toegang, monitoring en reservatie'. Deze werd geselecteerd uit de volgende lijst:
| Samenvatting | Beschrijving |
| UC1: Registratie Bedrijf | Aanmaken van een nieuwe registratie als organisatie/onderneming om vanaf nu via login/paswoord alle gegevens niet meer opnieuw te moeten invoeren, alsook de kentekens, vrachtwagens en chauffeurs te kunnen registreren en linken aan mijn organisatie. |
| UC2: Aanvraag Levering | Een visuele applicatie (='Dashboard') waar de vervoerder een reservatie/registratie, om de binnenstad binnen te rijden, kan aanvragen en ifv het flankerend beleid al dan niet toestemming krijgt om de gevraagde route te kunnen gebruiken. Alternatieve 'routes' (welke wagen, tijdstip, geografische route, enz) worden ook voorgesteld. |
| UC3: Beleids Cockpit uitvoering | Het flankerend beleid moet kunnen ingevoerd worden in de 'cockpit' zodat elke aanvraag (= registratie) ifv de gevraagde routes, maar ook de type wagen, ed meer de toegestane routes kan beslist en gevisualiseerd worden via een algoritme die een 'nudging' mogelijk maakt om bvb naar een levering te streven die conform het beleid is en/of geoptimaliseerd kan worden. |
| UC4: Toegang Binnenstad | De binnenstad kan toegankelijk gemaakt worden (via paaltjes of via een ANPR camera) voor degenen die een registratie conform het beleid hebben gedaan van de levering. |
| UC5: Monitoring Dashboard | De steden krijgen een 'monitoring dashboard' die het volledige vrachtverkeer (registraties, sensoren, camera's data, ANPR, Toegangscontrole,...) grafisch en in cijfers weergeeft om zo een beter beleid te kunnen vormen, evalueren, simuleren en aanpassen. |
| UC6: Reservatie domeinen | De vervoerder/handelaar/leverancier moet een laad- en losplaats kunnen 'reserveren' , gelinkt met bestaande software die reeds eventueel bestaat, om zeker te zijn dat de levering zo optimaal zou kunnen verlopen. (Betaling ? : misschien ifv EURO normen van de (vracht)wagen) |
| UC7: Matchmaking | Door alle verzamelde data, , zoals beladingsgraad, afmetingen, drops, enz.,alsook de 'registratie' aanvragen, kan de 'waste' in de transport worden weggewerkt door de 'lege'/'beschikbare' volumes te benutten door andere vervoerders, handelaars en leveranciers. |
| UC8: Open Data | Alle data die uiteindelijk gecapteerd worden moet kunnen opengesteld worden om zo de ganse quadruple helix de mogelijkheid te bieden om 'Value Added Services' te kunnen bouwen op die data. |
| UC9 : CRM Database | Alle contact gegevens om de gebruikers van de tool te kunnen contacteren met 'informatie' of 'customized' berichten met alle optin en optouts alsook 'voorkeuren' van informatie. |
| UC10 : Helpdesk | Een helpdesk (live, FAQ, chatbot,...) |
De tweede use case betrof 'beleidscockpit uitvoering en matchmaking'. Deze werden geselecteerd uit de volgende lijst:
| Samenvatting | Beschrijving |
| UC1: Registratie Bedrijf | Aanmaken van een nieuwe registratie als organisatie/onderneming om vanaf nu via login/paswoord alle gegevens niet meer opnieuw te moeten invoeren, alsook de kentekens, vrachtwagens en chauffeurs te kunnen registreren en linken aan mijn organisatie. |
| UC2: Aanvraag Levering | Een visuele applicatie (='Dashboard') waar de vervoerder een reservatie/registratie, om de binnenstad binnen te rijden, kan aanvragen en ifv het flankerend beleid al dan niet toestemming krijgt om de gevraagde route te kunnen gebruiken. Alternatieve 'routes' (welke wagen, tijdstip, geografische route, enz) worden ook voorgesteld. |
| UC3: Beleids Cockpit uitvoering | Het flankerend beleid moet kunnen ingevoerd worden in de 'cockpit' zodat elke aanvraag (= registratie) ifv de gevraagde routes, maar ook de type wagen, ed meer de toegestane routes kan beslist en gevisualiseerd worden via een algoritme die een 'nudging' mogelijk maakt om bvb naar een levering te streven die conform het beleid is en/of geoptimaliseerd kan worden. |
| UC4: Toegang Binnenstad | De binnenstad kan toegankelijk gemaakt worden (via paaltjes of via een ANPR camera) voor degenen die een registratie conform het beleid hebben gedaan van de levering. |
| UC5: Monitoring Dashboard | De steden krijgen een 'monitoring dashboard' die het volledige vrachtverkeer (registraties, sensoren, camera's data, ANPR, Toegangscontrole,...) grafisch en in cijfers weergeeft om zo een beter beleid te kunnen vormen, evalueren, simuleren en aanpassen. |
| UC6: Reservatie domeinen | De vervoerder/handelaar/leverancier moet een laad- en losplaats kunnen 'reserveren' , gelinkt met bestaande software die reeds eventueel bestaat, om zeker te zijn dat de levering zo optimaal zou kunnen verlopen. (Betaling ? : misschien ifv EURO normen van de (vracht)wagen) |
| UC7: Matchmaking | Door alle verzamelde data, , zoals beladingsgraad, afmetingen, drops, enz.,alsook de 'registratie' aanvragen, kan de 'waste' in de transport worden weggewerkt door de 'lege'/'beschikbare' volumes te benutten door andere vervoerders, handelaars en leveranciers. |
| UC8: Open Data | Alle data die uiteindelijk gecapteerd worden moet kunnen opengesteld worden om zo de ganse quadruple helix de mogelijkheid te bieden om 'Value Added Services' te kunnen bouwen op die data. |
| UC9 : CRM Database | Alle contact gegevens om de gebruikers van de tool te kunnen contacteren met 'informatie' of 'customized' berichten met alle optin en optouts alsook 'voorkeuren' van informatie. |
| UC10 : Helpdesk | Een helpdesk (live, FAQ, chatbot,...) |
Aanpak
Het verloop van de oefening is als volgt:
- Deelnemers worden doorverwezen naar een miro bord (de link naar dit bord kan je hier terugvinden), selecteren een blauwe post-it en schrijven databronnen op
- De facilitator van de werkgroep clustert deze databronnen samen onder één gemeenschappelijke noemer
- Per databron worden eerst de metadata samen gecapteerd, vervolgens de kenmerken van de data
Use case 1
Om te beginnen werd er bekeken welke databronnen men kon onderscheiden. Deze databronnen werden vervolgens door de facilitator en in onderling overleg geclusterd. Hierbij een overzicht van de vernoemde databronnen:
| Cluster | Databronnen | Opmerkingen |
| Cluster 1 | Voertuiggegevens DIV | |
| Cluster 2 | OVAM voor afvalstoffen | |
| Cluster 3 | Sensoren bij parkeerplaatsen | |
| IOT-sensoren in de stad (luchtkwaliteit, parkeersensoren,...) | ||
| Cluster 4 | ANPR data - politie | Vergunningen zitten bij de gemeente maar controle nummerplaat bij politie voor ANPR data |
| Cluster 5 | Inname openbaar domein (databanken zoals Spotbooking) | |
| GiPOD (IoD) | Wanneer zijn welke delen van de stad niet toegankelijk? | |
| Parkeer-rechtendatabank | Reservatie van parkeerplaatsen voor verhuis bv | |
| Cluster 6 | traffic management systemen van de stad | |
| Parkeergeleidingssystemen van de stad (bv. Yunex) | ||
| Cluster 7 | GIS | |
| Parkeerzones in de stad | ||
| Cluster 8 | telecombedrijven (proximus bvb) | |
| floating car data voor druktemeting/routegeleiding | ||
| Cluster 9 | KBO | |
| Cluster 10 | data (identificatie) voor authenticatie organisatie/ondernemig | |
| Boeking (agenda) | ||
| voorkeurroutes vrachtwagens en bestelwagens | ||
| leverzones en levertijdstippen | ||
| Vergunning (autorisatie) | ||
| ANPR whitelist (vergunningen) | ||
| Cluster 11 | (voorkeurs)data van handelaren/burgers (manuele ingave?) | Type goederen, voorkeuren, etc |
| Levervoorkeuren klanten (groen transport/in hubs/tijdsvensters) | ||
| Cluster 12 | CRM-databank | Voor registratie van bedrijven |
In de volgende oefening werden een aantal vragen gesteld over de metadata:
- Wat is de naam van de databron
- Wie is de eigenaar van de data
- Welke gegevens zijn in de data verwerkt/beschikbaar
- In welke formaten worden de data opgeslagen en opgehaald
- Om de hoeveel tijd is er nieuwe data beschikbaar (data frequentie en data recentheid)
- Wat is de dekkingsgraad van de data Hoe wordt de data opgehaald (bv API – push/pull, webhook,.
De deelnemers konden vervolgens alle databronnen, (blauwe post-its) die tijdens de vorige oefening gedefinieerd werden, in het Miro bord plakken om de vragen te beantwoorden.
Dit leverde de onderstaande tabel op:
| Metadata | Cluster 1 | Cluster 2 | Cluster 3 | Cluster 4 | Cluster 5 | Cluster 6 | Cluster 7 | Cluster 8 | Cluster 9 | Cluster 10 | Cluster 11 | Cluster 12 |
| Naam van de databron | Voertuig-gegevens DIV | Voertuig gegevens OBU | Sensordata | Data transporteurs | GIS/ parkeerzones | KBO | Levervoorkeuren handelaars burgers | Inname openbaar domein | vergunningen | Voorkeursroutes | Floating car | |
| Eigenaar van de data | FOD Mobiliteit | Gewesten/ Viapass | Stad of gemeente zelf | transporteurs, leveranciers, klanten (mix) | Stad of gemeente zelf | FOD Economie | Handels(wijk)verenigingen | Stad of gemeente zelf | Stad of gemeente zelf | Stad of gemeente zelf (IoD, zwaar vrachtvervoer) | Dataprovider of dataset aangekocht door gemeente | Politie |
| Stad of gemeente (via enquêtes of stadsbreed CRM) of via burgerprofiel | Transporteurs - route optimalisatiesystemen | TomTom, Waze, Google | ||||||||||
| Welke gegevens zijn allemaal in de data verwerkt/ beschikbaar? | nummerplaat gewichten euronorm … |
Eigenaar voertuig nummerplaat Euronorm voertuig Totaal toegelaten gewicht voertuig |
Type sensor, actuele status, context van de sensor, data observations |
bedrijfsafhankelijk, maar: leveradressen, type goederen, e-cmr's, laadlijsten, chauffeur, type voertuig, transportplanning,… | Ondernemingsnummer Adres Naam … |
verzendings- en leveringsplan van laad & los plaatsen. Of hoe de inventaris zal worden getransporteerd, welke en hoeveel transportmiddelen men wenst te gebruiken, welke route verplicht te nemen, … | adres, aantal IoD's, reden inname, | Lijst van categorieën die vergunning mogen aanvragen (recht op toegang = juridisch kader/reglement) | type zone (30, 50, 70), doorrij hoogte van trajecten, obstakels, LEZ, Schoolomgevingen | Gemiddelde doorreis tijden van bepaalde tracé's, actuele congestie op verkeersassen | Nummerplaat Tijdstip registratie zone | |
| Zie ook Telraam (type voertuig dat voorbij rijdt) | geldigheidsduur (specifieke datum of voor 1 jaar of meer), aantal vergunningen per bedrijf | Maatstaven voor optimalisatie zoals volledige en tijdige leveringen, transport afstanden en tijden, aantal zones te doorkruisen, … | ||||||||||
| parkeerdata: tijdstip IN/OUT (+ overstay), geolocatie (bij sensoren met SIM-kaart) | nummerplaat | Sensor & IoT inzichten, historische financiële, operationele, ... data inzichten, ... | ||||||||||
| Voor welke zone | ||||||||||||
| In welk formaten worden de data opgeslagen en opgehaald? | JSON | bedrijfsafhankelijk: CSV, excel, op papier (cmr),… | geopackage | pdf en jpg | ||||||||
| Excel | geoJSON, polygon | |||||||||||
| Om de hoeveel tijd is er nieuwe data beschikbaar? (data frequentie en data recentheid) |
Bij inschrijving van het voertuig of wissel nummerplaat | Bij registratie van nieuwe voertuigen bij tolinner (bv. Satellic) | Real time | constante veranderingen, maar belangrijkste is op het punt dat de planning gemaakt wordt (dagelijks, mogelijks méér dan eens) | Real time | Stad of gemeente is verantwoordelijk om gegevens op te laden in IoD - GiPOD | Realtime | |||||
| gegevens worden ingeput bij registratie voertuig voor kmheffing bij een serviceprovider | historische data | |||||||||||
| Wat is de dekkingsgraad van de data? | alle BE voertuigen (quid buitenlandse voertuigen?) | alle voertuigen onderhevig aan de kmheffing > 3,5 t zowel Belgische als buitenlandse |
alle info van het bedrijf | Alle ondernemingen in BE | Op stedelijk niveau | Bij Waze kunnen specifieke area's geselecteerd worden | ||||||
| Hoe wordt de data opgehaald? (bv API - push/pull, webhook, ...) |
Streaming protocol | intern gebruik nu. API mogelijk (must have voor grote bedrijven), maar ook manuele ingave nodig voor kleine bedrijven | Webhook? | Wellicht API based - pull | ||||||||
| Kenmerken van de data | Cluster 1 | Cluster 2 | Cluster 3 | Cluster 4 | Cluster 5 | Cluster 6 | Cluster 7 | Cluster 8 | Cluster 9 | Cluster 10 | Cluster 11 | Cluster 12 |
| Is GDPR van toepassing (zijn er persoonlijke gegevens aanwezig in de data) en waarom? | De link voertuig-eigenaar is beschermd door GDPR. Mogelijk is de bruiikbare data erg beperkt | Afhankelijk van type sensor (Camera, geluid, ANPR, ... zijn GDPR gevoelig) | ja: adressen en namen van klanten, chauffeur | |||||||||
| Is de data betrouwbaar? (bv. zijn de sensoren betrouwbaar bij regenweer)? | Afhankelijk van type sensor | ja, als in: dit is de data die het transportbedrijf aangeeft voor zijn ladingen. Intern kan een planner natuurlijk 'sjoemelen' | ||||||||||
| In welke mate is de data vindbaar? Fair principe 1: Goed beschreven en geïndexeerd en metadata kunnen doorzocht worden |
afhankelijk van bedrijf tot bedrijf, welk programma ze hebben | |||||||||||
| In welke mate is de data toegankelijk? Fair principe 2: Het is duidelijk of en hoe je toegang kunt krijgen tot de (meta)data en op te halen via standaardprotocollen |
niet echt toegankelijk: bedrijven willen niet zomaar hun data afgeven. Daarnaast ook duur om dit te regelen (API inbouwen, extra tijd voor planner in registratie,...) | |||||||||||
| In welke mate is de data interoperabel? Fair principe 3: Metadata zijn zo beschreven dat machines ze kunnen interpreteren en het is duidelijk hoe die (meta)data zich tot andere (meta)data verhouden |
bedrijfsafhankelijk | |||||||||||
| In welke mate is de data beschikbaar voor (her)gebruik? Het is duidelijk hoe data gebruikt en hergebruikt mogen worden en ze zijn rijkelijk voorzien van kenmerken |
zeer onduidelijk: geen toestemming van bedrijf, in conflict met GDPR (?), klantgegevens zijn ook eigendom van de klant (en mogen niet zomaar gedeeld worden),… | |||||||||||
Use case 2
Voor de tweede use case ging men op dezelfde manier te werk als voor de eerste: databronnen werden geïdentificeerd, door de facilitator geclusterd en vervolgens werden de vragen met betrekking tot de metadata en de kenmerken van de data beantwoord.
Dit leverde de volgende twee tabellen op:
| Cluster | Databronnen | Opmerkingen |
| Cluster 1 | Voertuig specificaties i.f.v. vrachten | |
| Vrachtgoed + verpakking | ||
| Radioactiviteits detectie (ook bij vorige use case) | RA afval ziekenhuizen bv | |
| beladingsgraad bij vertrek (of vrije ruimte) | ||
| Cluster 2 | (Simulatie)modellen voor bv. emissies/type voertuig | |
| Cluster 3 | Voorkeurs routes | |
| Bestemming (leverpunt) | ||
| Transport schedules / timeframes | ||
| Cluster 4 | Transportvergunning | Eigen goederen vervoeren of derden / Europese regelgeving |
| Vergunningen: juridisch kader (reglement) | vanuit LB | |
| Tijdsvensters voor leveringen opgelegd door de stad | ||
| Vergunningen: zones met restricties | ||
| Cluster 5 | Evenementenkalender (IoD) | |
| Cluster 6 | Reistijd | |
| Transport kosten | ||
| Transport berekeningen op real-time transport data | ||
| Cluster 7 | Dataset business rules / beslissingsboom "Slimme Stadsdistributie" (te ontwikkelen) | |
| CRM Slimme Stadsdistributie: wie krijgt beloning? | ||
| Cluster 8 | Scholen: schooluren | |
| GIS: schoolstraten | ||
| Cluster 9 | Outbound transport naar klant | |
| Externe orders en zendingen | ||
| Inbound transport naar (tijdelijke) opslagplaats | ||
| Cluster 10 | Zelfde databronnen als use case 1? | |
| voorkeuren handelaars/burgers |
| Metadata | Cluster 1 | Cluster 2 | Cluster 3 | Cluster 4 | Cluster 5 | Cluster 6 | Cluster 7 |
| Naam van de databron | Voertuigen en ladingen | Leveringsvoorwaarden | Evenenemten IOD | CRM/ beslissingsboom/ algorithme | Simulatie data | Voorkeursroute/ levering | Real time data leveringen |
| Eigenaar van de data | Transport firmas | Stad of gemeente zelf | Stad of gemeente zelf | open data? | Handelsverenigingen | Stad of gemeente zelf | |
| Stad of gemeente zelf | LSP's | ||||||
| Welke gegevens zijn allemaal in de data verwerkt/ beschikbaar? | Ladingskarakteristieken: aard en gewicht lading, volume vrachtgoed | Weersverwachtingen? (Sneeuw) | duur (start en einde) | zones/tijdstippen/voertuigen met restricties (tijdelijk of permanent) | emissie per km per voertuigtype | SLA | Ophalen van (externe) transport data zoals bestellingen uit (externe) CRM systemen, zendingen, routes, locaties, picked en picking lijsten, afspraken, soort laad werk, ... uit (externe) transport systemen, diverse inzichten uit BI en AI systemen, enz. |
| Voertuig karakteristieken: voertuigtype, euronorm, laadvermogen | Locatie: Adres? Straatsegment? Parkeerplaats? |
gegevens scholen | typische beleveringsprofielen per soort handelszaak | Vervoerder afspraken | |||
| Reden inname | vracht(goed) met restricties | Klanten afspraken | |||||
| In welk formaten worden de data opgeslagen en opgehaald? | json | ||||||
| Om de hoeveel tijd is er nieuwe data beschikbaar? (data frequentie en data recentheid) |
Bij wijzigingen van voertuigen / verschillende types ladingen | Wat de transportvergunningen betreft, elke dag | Stad of gemeente is verantwoordelijk om gegevens op te laden in IoD - GiPOD | Realtime | |||
| (near) Real-time | (near) Real-time | ||||||
| Wat is de dekkingsgraad van de data? | België | ||||||
| Hoe wordt de data opgehaald? (bv API - push/pull, webhook, ...) |
Streaming protocol | ||||||
| Kenmerken van de data | Cluster 1 | Cluster 2 | Cluster 3 | Cluster 4 | Cluster 5 | Cluster 6 | Cluster 7 |
| Is GDPR van toepassing (zijn er persoonlijke gegevens aanwezig in de data) en waarom? | |||||||
| Is de data betrouwbaar? (bv. zijn de sensoren betrouwbaar bij regenweer)? | |||||||
| In welke mate is de data vindbaar? Fair principe 1: Goed beschreven en geïndexeerd en metadata kunnen doorzocht worden |
|||||||
| In welke mate is de data toegankelijk? Fair principe 2: Het is duidelijk of en hoe je toegang kunt krijgen tot de (meta)data en op te halen via standaardprotocollen |
|||||||
| In welke mate is de data interoperabel? Fair principe 3: Metadata zijn zo beschreven dat machines ze kunnen interpreteren en het is duidelijk hoe die (meta)data zich tot andere (meta)data verhouden |
|||||||
| In welke mate is de data beschikbaar voor (her)gebruik? Het is duidelijk hoe data gebruikt en hergebruikt mogen worden en ze zijn rijkelijk voorzien van kenmerken |
|||||||
Vraag & antwoord en volgende stappen
Vragen
De opname van deze sessie is te bekijken via de onderstaande link.
Volgende werkgroepen
Indien u graag zou willen deelnemen aan één van de aankomende werkgroepen, kan u hieronder een overzicht van de workshops terugvinden en u ook zo inschrijven.
De datum van de tweede thematische werkgroep zal binnenkort gecommuniceerd worden en vindt plaats via Microsoft Teams.
Inschrijvingslink volgt.
| Werkgroep | Type werkgroep | Datum | Tijd | Locatie |
|---|---|---|---|---|
| Business werkgroep | Business werkgroep | 2023-01-11 | 13u30-16u30 | Digitaal |
| Thematische werkgroep 1 | Data en informatie werkgroep | 2023-02-28 | 09u00-12u00 | Digitaal |
| Thematische werkgroep 2 | Werkgroep | 2024-10-21 | 9u30-12u | Teams |