Data en informatie werkgroep: Veelzijdige InfoSchermen voor Updates en Acties van Lokale Ondernemers (VISUALO)
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 | |
| Alain Glickman | |
| Provincie Oost-Vlaanderen | Pieter-Jan Fieremans |
| Provincie Vlaams-Brabant | Alexander Leysen |
| VERA | Hans Hubin |
| Kenny Stevens | |
| Jan Potemans | |
| Erika Van Essche | |
| Stad Dendermonde | Jan De Backer |
| Stad Halle | Kasper Vanbeginne |
Aanleiding en Context
Initiatief
Met het Visualo-project willen de initiatiefnemers, waaronder stad Halle, een gezond en aantrekkelijk stadscentrum creëren waar lokale verkopers, horeca, organisaties en de mensen die er wonen samen kunnen komen en de stad op een andere manier kunnen beleven. Aan de hand van verschillende technologieën en gerichte communicatie zal het aanbod van lokale handelaren gepromoot worden om zo interactie met de inwoners te verhogen.
Men wil dus specifiek inzetten op lokale handelszaken die een grote impact gevoeld hebben door corona. Daarnaast is hun aanbod weinig bekend bij inwoners en nog minder bij bezoekers. Digitale infoschermen in het straatbeeld zouden een oplossing kunnen zijn maar tonen vooral advertenties voor multinationals en webshops. Daarnaast stelt men vast dat lokale besturen zich vaak beperkingen tot aankondigingen voor evenementen.
Het doel van het project is de creatie van een gebruiksvriendelijke app voor handelaars, een performant platform voor de centrum manager en het weergeven van advertenties op slimme infoborden. Hieronder een opsomming van de vereisten per doelgroep:
Presentatie Slide 9
VLOCA
Vloca-principes
Presentatie Slide 9
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.
Architectuurschema's
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 interacties:
| Samenvatting | Beschrijving |
| UC1: Digitale Scherm | Digitale Scherm die al dan niet interactief' een advertentie van de lokale winkels laat zien |
| UC2: Media Centrale | Een pseudo media centrale die de advertenties controleert, toekent en 'factureert' ifv regels en GRP (Reach, frequentie, enz.) |
| UC3: App | Een app die gemakkelijk door de lokale adverteerder toelaat om zijn eigen advertentie te kunnen inplannen en projecteren. |
| UC4: Inzichten | Rapportage van performantie van campagnes met inzichten van wat heeft gewerkt en wat niet (Tips en Tricks), incl beleidsrapportering. |
| UC5: Schaalbaarheid | Oplossing is uitbreidbaar (en interoperabel) naar andere steden en gemeenten zonder veel aanpassingen |
| UC6:CRM | Marketing Communicatie tool om gerichte of informatieve contacten met de klanten of prospecten te kunnen doen |
| UC7:Helpdesk | Meldingen en klachten alsook vragen en opmerkingen (FAQ, reviews, ...) |
Er werd gekozen voor UC1: Digitale scherm. Binnen deze use case kan men de volgende business capabilities onderscheiden:
| Beschrijving | |
| UC1 | Digitale Scherm die al dan niet 'interactief' een advertentie van de lokale winkels laat zien |
| BC1.2 | Als beheerder wil ik de burger interactieve opzoek mogelijkheden (via touchscreen of via handgebaren...) kunnen aanbieden |
| BC1.3 | Als beheerder wil ik aan de bezoeker een snelle begeleiding, kortingen of reservering bvb via touchscreen of QR codes kunnen aanbieden |
| BC1.4 | Als beleid wil ik de burgers kunnen bevragen om hun mening op bepaalde vragen te stellen |
| BC1.7 | Als wandelaar wil ik het scherm ook kunnen terugvinden op een stadsapp bvb op mijn gsm of zelfs thuis via een website |
| BC1.8 | Als wandelaar wil ik de info/korting/enz kunnen delen met derden (vrienden, familie,...) |
| BC1.10 | Als wandelaar wil ik via een QR code kunnen gebruiken om tot een 'website' te komen waar ik de advertenties kan 'swipen' om de 'net verdwenen' advertentie te kunnen terugvinden, of de handelaar te kunnen contacteren direct via gsm, enz. |
| BC4.9 | Als stad wil ik de digitale schermen ook kunnen gebruiken om mijn beleid en andere info te verspreiden aan de wandelaars in de binnenstad |
De tweede use case was gericht op inzichten:
| Samenvatting | Beschrijving |
| UC1: Digitale Scherm | Digitale Scherm die al dan niet interactief' een advertentie van de lokale winkels laat zien |
| UC2: Media Centrale | Een pseudo media centrale die de advertenties controleert, toekent en 'factureert' ifv regels en GRP (Reach, frequentie, enz.) |
| UC3: App | Een app die gemakkelijk door de lokale adverteerder toelaat om zijn eigen advertentie te kunnen inplannen en projecteren. |
| UC4: Inzichten | Rapportage van performantie van campagnes met inzichten van wat heeft gewerkt en wat niet (Tips en Tricks), incl beleidsrapportering. |
| UC5: Schaalbaarheid | Oplossing is uitbreidbaar (en interoperabel) naar andere steden en gemeenten zonder veel aanpassingen |
| UC6:CRM | Marketing Communicatie tool om gerichte of informatieve contacten met de klanten of prospecten te kunnen doen |
| UC7:Helpdesk | Meldingen en klachten alsook vragen en opmerkingen (FAQ, reviews, ...) |
Binnen deze tweede use case konden opnieuw een aantal business capabilities geïdentificeerd worden:
| ID | Beschrijving |
| UC4 | Rapportage van performantie van campagnes met inzichten van wat heeft gewerkt en wat niet (Tips en Tricks), incl beleidsrapportering. |
| BC4.1 | Als beleid wil ik het aantal passanten kunnen meten en ook rapporteren aan de adverteerders |
| BC4.2 | Als beleid wil ik het aantal 'viewers' kunnen capteren en tellen en ook rapporteren aan de (potentiele) adverteerders |
| BC4.3 | Als beleid wil ik de gezichtsuitdrukkingen van de 'viewers' kunnen meten en ook rapporteren aan de (potentiele) adverteerders |
| BC4.4 | Als adverteerders wil de ROI van een campagne kunnen meten en berekenen door de binnenstappers en besteders te bepalen van de 'viewers' |
| BC4.5 | Als adverteerder (en medewerker) wil ik de mogelijkheid hebben om (experimentele) AB testen te kunnen doen (vergelijken van verschillende advertenties op de commerciële resultaten van de adverteerder) |
| BC4.6 | Als adverteerder wil ik weten welke segmenten ik kan bereiken op welk moment in welke straat segment die evt in mijn doelgroep zitten |
| BC4.7 | Als beleid wil ik de schermtijd (in piek momenten bvb) kunnen rapporteren ifv lokale business, overheid, instellingen, corporates, global brands, enz |
| BC4.8 | Als beleid wil ik dat de winkels in de zijstraten ook visibiliteit kunnen krijgen dankzij de digitale schermen in de hoofdstraten |
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 |
| Cluster 1 | Lijst van handelszaken |
| KBO | |
| Ambulante handelaars (food trucks, markten) | |
| Overzicht van ondernemers | |
| Cluster 2 | Bron van wie publiceert: handelaar/overheid |
| Cluster 3 | ANPR gegevens voor bv druktemeting |
| Handhaving/ Campagnes adhv GAS-boetes inzichten: bv aantal sluikstorten | |
| Politie gegevens | |
| Cluster 4 | Kaart van de stad |
| GIS | |
| Lijst/kaart van musea en andere toeristische bezienswaardigheden | |
| Cluster 5 | Camera en AI: type gebruiker gekoppeld aan opzoekingen |
| Camera data uit scherm | |
| Data voor koppelingen volgens type gebruiker (gebruikersprofiel) | |
| Cluster 6 | Indien informatie van bv openbaar vervoer, deze specifiek databron |
| Info De Lijn (uurtabellen) | |
| Info NMBS (uurtabellen) | |
| Cluster 7 | Uit databank |
| Sportkalender | |
| Agenda met events in de stad | |
| Aanbod, recreatieve plaatsen en publieke voorzieningen op kaart | |
| Cluster 8 | In een use case waar we bv de weersvoorspelling voor de komende 3 uur willen weergeven: databron kmi |
| KMI weersvoorspelling | |
| Cluster 9 | info over lokale overheid |
| Voor beleidsinformatie koppeling met deze databron | |
| Childfocus | |
| Cluster 10 | Stadsapp |
| Cluster 11 | RFID |
| Cluster 12 | Databron: digitale weergave van het scherm op bv app |
| Data bron input informatie van de handelaar (product, prijs, korting etc) | |
| Databron: afspeellijst advertenties, wat moet wanneer getoond worden? | |
| advertentie met nodige info (hyperlinks, telefoon, adres, ...) | |
| Cluster 13 | Voor reservering, koppeling met specifieke databank/reservatie tool van aanbieder |
| Cluster 14 | Afvalkalender |
| Cluster 15 | Hoogtepunten nieuws |
| RSS feeds | |
| Nieuws van hogere overheden | |
| Cluster 16 | IOT/ Real time dashboard (luchtkwaliteit, ...) |
| Cluster 17 | Indien bv parkeergelegenheid dient weer gegeven te worden, koppeling met de API van parkeermonitoring |
| parkeerdrukte | |
| vrije parkeerplaatsen |
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 per databron (blauwe post-its) die tijdens de vorige oefening gedefinieerd werden in het Miro bord de vragen te beantwoorden.
Dit leverde de onderstaande tabel op:
| Clusters 1 tot 5 | |||||
| Metadata | Cluster 1 | Cluster 2 | Cluster 3 | Cluster 4 | Cluster 5 |
| Naam van de databron | KBO/handelaars | overzicht evenementen/sportkalender/.. | Weer | Overheidinfo | Parkeerdata en/of mobiliteitsgegevens |
| UIT databank | Luchtkwaliteit | LBLOD | |||
| kompas databank | omgevingsinformatie (weer, luchtkwaliteit,...) | ||||
| Hoeveelheid opgewekte electriciteit door lokale zonnepanelen | |||||
| Eigenaar van de data | Kruispuntbank en locatus | Lokaal bestuur en verenigingen | Open source of stad | Lokaal bestuur | Lokaal bestuur |
| Alternatief via eigen platform of CRM | Parkeerbeheerder | ||||
| Welke gegevens zijn allemaal in de data verwerkt/ beschikbaar? | Adres | Oplijsting events | Pluviometers, wind, temperatuur, vochtigheid | openingsuren, aanvraag documenten | Parkeertickets per parkeerautomaat |
| BTW-nummer | PM 2/10, Co2, No2, Etc | Actuele bezetting parkeertoren/parking | |||
| Activiteit | |||||
| Zaakvoerders | |||||
| In welk formaten worden de data opgeslagen en opgehaald? | excell | CSV-JSON | CSV-JSON | LBLOD | CSV-JSON |
| CSV-JSON | |||||
| Om de hoeveel tijd is er nieuwe data beschikbaar? (data frequentie en data recentheid) |
Bij opstart of faillissement handelszaak | vaste evenementen = jaarlijkse niet-vast = maandelijks? |
Kan real time maar niet altijd nodig | gemengd = statisch en dynamisch | |
| Wat is de dekkingsgraad van de data? | Heel Vlaanderen voor VKBO | grondgebied stad/gemeente | Meestal beperkt, zeer locatie gevoelig | lokaal en regionaal | Locatie-gebonden (parking, parkeerzone,...) |
| Hoe wordt de data opgehaald? (bv API - push/pull, webhook, ...) |
MAGDA (manuele excel tabel met mutaties) | API, MQTT, SQL-query |
API | API | |
| Kenmerken van de data | Cluster 1 | Cluster 2 | Cluster 3 | Cluster 4 | Cluster 5 |
| Is GDPR van toepassing (zijn er persoonlijke gegevens aanwezig in de data) en waarom? | Beperkt. Naam zaakvoerders en adresgegevens | nee, overzicht als "doorverwijzing" naar eventpagina ed. | Neen | Neen | |
| Is de data betrouwbaar? (bv. zijn de sensoren betrouwbaar bij regenweer)? |
Hoge betrouwbaarheidsgraad (maar niet perfect) | ja | Is overheidsinformatie dus normaal betrouwbaar | ||
| Problemen met type activiteit (NACE) | |||||
| Problemen met niet doorgegeven faillissementen | |||||
| In welke mate is de data vindbaar? Fair principe 1: Goed beschreven en geïndexeerd en metadata kunnen doorzocht worden |
1: goed | 1: goed | Ja | ||
| 2 Naam in KBO is niet per se naam van winkel … | |||||
| 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 |
2: gemiddeld bestuur heeft de toegang |
1: goed | Vrije data vanuit bestuur | ||
| 2 Geen API voor mutaties dacht ik … |
|||||
| 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 |
1: goed | 1: goed | 1: goed | ||
| 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 |
Ja | ||||
| Clusters 6 tot 10 | |||||
| Metadata | Cluster 6 | Cluster 7 | Cluster 8 | Cluster 9 | Cluster 10 |
| Naam van de databron | Stadsapp | Handhaving | Camera's in schermen | Kaarten | KMI |
| Eigenaar van de data | Lokaal bestuur | Stad of politie | Scherm beheerder | Stad | |
| Geopunt - digitaal vlaanderen | |||||
| Open street map | |||||
| Welke gegevens zijn allemaal in de data verwerkt/ beschikbaar? | Evenementen, handelaren, dienst uren, afval kalender | #overtredingen #boetes |
Zeer divers, tellingen, emoties, AI mogelijkheden | Puntlocaties en polygonen (individueel pand tot weergave sportaccommodatie) | |
| Toeristische trekpleisters | |||||
| Openbare toiletten | |||||
| Parken, parkings, haltes openbaar vervoer, fietsstallingen, AEDs/EHBO, apotheken | |||||
| In welk formaten worden de data opgeslagen en opgehaald? | Excel | CSV-JSON | JSON | ||
| 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, ...) |
Manueel | API | API | ||
| Kenmerken van de data | Cluster 6 | Cluster 7 | Cluster 8 | Cluster 9 | Cluster 10 |
| Is GDPR van toepassing (zijn er persoonlijke gegevens aanwezig in de data) en waarom? | Ja maar politie is verantwoordelijk (opsporingsberichten) | Ja, camerabeelden zijn altijd een verwerking van persoonsgegevens | Nee | ||
| Is de data betrouwbaar? (bv. zijn de sensoren betrouwbaar bij regenweer)? |
Ja | ||||
| 2: hangt af van lokaal bestuur | |||||
| In welke mate is de data vindbaar? Fair principe 1: Goed beschreven en geïndexeerd en metadata kunnen doorzocht worden |
1: goed | ||||
| 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 |
1: goed | ||||
| 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 |
1: goed | ||||
| 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 |
1: goed | ||||
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 | Ingebouwde camera | |
| Cluster 2 | Tevredenheidsenquête via scherm | |
| percentage verdeelde schermtijd, handelaar vs stad, bron platform | ||
| Cluster 3 | QR-codes met doorverwijzingen | |
| Cluster 4 | Geluidssensor (straatlawaai, incident) | |
| Cluster 5 | Weersinformatie linkken aan drukte voor context aan handelaar | |
| Cluster 6 | Betaal terminal data | |
| Omzet in aantallen en waarde handelaars | ||
| Cluster 7 | Marktcijfers/ trends (GfK, AC Nielsen, Agoria, ... ) | |
| Historische cijfers (situatie voor scherm) | ||
| Cluster 8 | Demografische gegevens | Clearchannel gebruik telecom data om te bepalen wie bereikt wordt met schermen |
| Cluster 9 | Proximus/ google | |
| betaalverkeer | ||
| drukte (passanten) | ||
| monitoring gsm-gebruik | ||
| Inzicht naar handelaar drukte uit wifi data | ||
| inzicht naar handelaar drukte uit nobiliteitsdata | ||
| Wifi cijfers drukte in de stad databron fluvius/RTF/Proximus | ||
| lijst inwoners --> van waar komen passanten? | ||
| Cluster 10 | Bluetooth meting voor druktemeting | |
| WiFi/Bluetooth-scanner in scherm | ||
| Cluster 11 | Verkoop bij ondernemers die gelinkt kan worden aan promo via scherm | |
| "Actiecodes" handelaars --> hoeveel uit het scherm? | ||
| Cluster 12 | Toestand bezette schermtijd algemeen | |
| Touchinput van scherm | ||
| Eventuele drukknoppen onder of naast het scherm | ||
| Cluster 13 | Aantal navigaties -> goede indicatie of het scherm naar een actie geleid heeft (naar de winkel te stappen) | |
| Cluster 14 | gemiddelde tijd gebruik scherm | |
| verschil advertentie openbare info | ||
| aantal clicks per advertentie | ||
| aantal opzoekingen | ||
| passantentelling | ||
| Aantal gebruikers van het scherm (aantal keren aangeklikt) | ||
| Aantal gepost advertenties | ||
| Meest bekeken pagina's bron platform | ||
| Aantal QR Code scans | ||
| Toestand bezette schermtijd per gebruiker | Hoeveel airtime is er over? | |
| Metadata | Cluster 1 | Cluster 2 | Cluster 3 | Cluster 4 | Cluster 5 | Cluster 6 |
| Naam van de databron | Passantentellingen externe data | Passantentellingen via sensoren aan scherm | Passanten tellingen via sensoren andere locatie |
Verkoop data handelaars |
Marktcijfers (trends) | Geïnde acties bij handelaars |
| Eigenaar van de data | Open source, stad of 3de partij of on site | Open source, stad | Open source, stad of 3de partij | handelaars | Lokaal bestuur of derde partij | |
| Rol van de boekhouder | ||||||
| Welke gegevens zijn allemaal in de data verwerkt/ beschikbaar? | Aantallen, modaliteiten | aantal passanten | vraag wat wil de handelaar ter beschikking stellen, aantal kopers , gemiddelde aankoopsom ? | #bezoeker #marktkramers |
||
| leeftijdscategorie (camera) | ||||||
| geslacht (camera) | ||||||
| mood (bv. happy) (camera) | ||||||
| aantal vrachtwagens (camera) | ||||||
| aantal fietsers (camera) | ||||||
| returning visitor (WiFi of Bluetooth) | ||||||
| aantal auto's (camera) | ||||||
| In welk formaten worden de data opgeslagen en opgehaald? | CSV, JSON | Via platform? | ||||
| Om de hoeveel tijd is er nieuwe data beschikbaar? (data frequentie en data recentheid) |
Real time of bepaalde intervallen | Real time of bepaalde intervallen | Real time of bepaalde intervallen | kwartaal | Sporadisch wanneer de metingen worden uitgevoerd | |
| Wat is de dekkingsgraad van de data? | Lokaal - stad/gemeente | Beperkt maar wel zeer lokaal (waar het scherm staat) | Meestal groter maar niet altijd relevant | Digitale maturiteit handelaar | ||
| Hoe wordt de data opgehaald? (bv API - push/pull, webhook, ...) |
API | API, MQTT | API, MQTT | Manuale uploads? | API? | |
| Metadata | Cluster 1 | Cluster 2 | Cluster 3 | Cluster 4 | Cluster 5 | Cluster 6 |
| Kenmerken van de data | ||||||
| Is GDPR van toepassing (zijn er persoonlijke gegevens aanwezig in de data) en waarom? | Ja maar dit wordt zogoed als altijd geanonimiseerd dus ok | Ja maar dit wordt zogoed als altijd geanonimiseerd dus ok | Ja maar dit wordt zogoed als altijd geanonimiseerd dus ok | Ja, persoonsgegevens bv marktkramers | Ja, indien terugkoppeling op klantnaam | |
| Is de data betrouwbaar? (bv. zijn de sensoren betrouwbaar bij regenweer)? | Dient bewaakt te worden - niet onze data | Gezien het hier over 1 sensor op een specifiek locatie gaat zou dit vrij betrouwbaar moeten zijn | Invraag te stellen naar gelang systeem | Tellingen kunnen afwijken, aantal marktkramers niet | 2. kortingscodes kunnen gedeeld worden | |
| In welke mate is de data vindbaar? Fair principe 1: Goed beschreven en geïndexeerd en metadata kunnen doorzocht worden |
1 | |||||
| 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 |
1 | |||||
| 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 |
1 | |||||
| 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 |
Hoge mate aangezien externe data | |||||
Vraag & antwoord en volgende stappen
Vragen
De opname van deze sessie is te bekijken via deze link.
Volgende werkgroepen
Indien u graag zou willen deelnemen aan één van de aankomende werkgroepen, kan u via de onderstaande link een overzicht van de workshops terugvinden en u ook zo inschrijven.
De tweede thematische werkgroep zal plaatsvinden op 30 maart om 13u00 via Microsoft Teams.
Inschrijvingslink: VLOCA-Visualo.
Andere werkgroepen
| Werkgroep | Type werkgroep | Datum | Tijd | Locatie |
|---|---|---|---|---|
| Business werkgroep | Business werkgroep | 2022-11-07 | 09u00-12u00 | Vlaamse Overheid Herman Teirlinckgebouw (Brussel) |
| Thematische werkgroep 1 | Data en informatie werkgroep | 2023-03-02 | 13u00-16u00 | Digitaal |
| Thematische werkgroep 2 | Functionele werkgroep | 2023-03-30 | 13u00-16u00 | Digitaal |