Functional Advisory Board session - 10 maart 2021

(Dutch only)

De notes van het Functional Advisory Board.

Volgende FAB-overleg is op 24 maart

Attendees

(in alfabetische volgorde)

• Gemeente Den Bosch
• Gemeente Eindhoven
• Gemeente Helmond
• Gemeente Nijmegen
• Gemeente Utrecht
• Universiteit Wageningen
• Kadaster (initiator)

Notes

Onderwerpen:

1. Mededelingen

   • Master student Universiteit Wageningen sluit aan bij dit overleg en houdt zich bezig met het ontwikkelen van een fit-for-purpose governance model voor het sensorenregister.

   • De governance groep van het sensorenregister kijkt naar een ontvangen oproep van BZK voor een opschalingsanalyse van het sensorenregister.

   • De voorbereidingen voor een informatiesessie voor bestuurders op 14 april a.s. zijn gestart

   • Amsterdam meldt dat er een meldingsplicht komt voor sensoren, zie verordening meldingsplicht sensoren.

2. Stand van zaken huidige en komende sprint (zie bord)

   Het bord is bijgewerkt.

   In de komende 2 weken zal wederom de meeste aandacht gaan naar het datamodel en het bijwerken van de code rond de afspraken die zijn neergelegd in het datamodel. Verder zal aandacht besteedt worden aan het naar productie brengen van de applicatie aan zowel Kadasterzijde als bij de gemeente Tilburg.

3. Stand van zaken rond het Datamodel (Kadaster en Nijmegen)

   • Er wordt nog gezocht naar een handzame invoerlijst voor 'Sensortypes', bij voorkeur een ISO-lijst. Er zijn wel hele uitgebreide lijsten beschikbaar (honderden types) maar het lijkt ons niet wenselijk om bij het invoeren van sesnoren te moeten kiezen uit een hele lange lijst. We zorgen er wel voor dat in de userinterface de lijst makkelijk aangepast kan worden.

   • Voor het MVP is ervan uitgegaan dat de 'LegalEntity' (bv een overheidsorganisatie) voor het datamodel niet de hoogste prioriteit heeft en is daarom niet verder uitgewerkt.

   • Er is een korte uitleg over het gebruik van events gepresenteerd. SenRNet maakt gebruik van een 'event-driven' architectuur.

   • In events is het "vergeten" van informatie (is een recht) een moeilijk iets dus je moet zorgen dat er geen verboden (lees: privacy gevoelige) informatie in events komen te staan. Let wel: In de registry node van een specifieke gemeente (organisatie) kan wel private info voorkomen. In de viewer (publishing node) absoluut niet.

   Vraag van gemeente Den Bosch: Bij wijziging van een sensor, bv een verplaatsing ('relocate'), zou het handig zijn als de datastream behouden kan blijven. Ook bijvoorbeeld bij het vervangen van een sensor omdat deze kapot is. Is dit mogelijk binnen de huidige scope van het MVP?

   Antw: Dat zal in het MVP geen keuze mogelijkheid zijn. Ook niet door middel van het kopiëren van een sensor.

   Vraag Den Bosch: Moet je bij verwijderen van een sensor niet standaard archiveren in plaats van verwijderen? De historie wil je immers niet kwijt zijn.

   Antw: Verwijderen betekent in een event-driven architectuur dat je altijd kunt terugkijken in de event-lijst naar wat er gebeurd is. Let wel op het verschil tussen meta-data en meetdata. Sensorenregister kent alleen de meta-data. Het voordeel van events is dat je alle gebeurtenissen hebt vastgelegd en je kunt altijd terugkijken en andere views gaan creëren m.b.t. de events.

4. Doornemen opleverdocument MVP

   Het MVP document is gezamenlijk doorgenomen:

   • De status van de DPIA is op dit moment 'Concept'. Zodra het document gereviewd is zal het binnen de FAB-groep worden gedeeld.

   • Verzocht wordt om voor de volgende keer issue #146 door te nemen. Het betreft het documenteren van de Architectural Decision Records (ADR's). De vraag is welke ADR je mist of welke teveel is. Welke andere zaken zouden we hier nog moeten vastleggen? Help ons met het aanvullen/verbeteren van deze lijst. We gaan zelf nog alle closed issues doorlopen in de GitHub repositories om te kijken of we hier nog (ADR-)zaken uit kunnen halen.

5. Wvttk en Afsluiting

   Geen bijzonderheden.