Mogelijk onjuist in "afgeleide" resources en gerelateerde resources

[CathyDingemanse]

Beschrijf de bug
Er zijn in verschillende issues problemen geconstateerd met "mogelijk onjuist": #430, #429, #369, #368, #329, #328 etc.
en de featurebeschrijving: #410.

Allerlei oplossingen die hiervoor die hiervoor zijn geïmplementeerd lijken het probleem slechts deels op te lossen. We kunnen wel concluderen dat het probleem blijft opduiken, ofwel op een andere plek, of in een andere context of variant.

De informatie zit in gerelateerde resources van een "afgeleide" resource (adres), waardoor het heel lastig wordt dit aan consumers op een begrijpelijke en juiste manier te communiceren. Pogingen daartoe hebben geleid tot een hele complexe oplossing voor mogelijk onjuist, die door consumers die het nodig hebben niet goed te begrijpen is.
Daarom moeten we op een andere manier naar de problematiek gaan kijken.

Ik stel voor om de complexiteit te reduceren door de gebruikersview toe te passen, en de essentiële complexiteit (van het domein) terug te brengen in de oplossing voor de degenen die dat nodig hebben.
80-20 regel toepassen (hoewel ik denk dat het eerder 95% - 5% betreft, door onze afnemers op te splitsen in 2 groepen:

1. afnemers voor wie mogelijk onjuist relevant is, bijvoorbeeld Als medewerker vergunningen en burgerzaken wil ik net zo'n informatierijke toelichting voor gecontateerd als voor mogelijkOnjuist #128 Als medewerker vergunning wil ik weten of het object (adres, VBO of Pand) waarop een vergunning is aangevraagd "gecontateerd" en/of "in onderzoek" is #13. Voor deze groep geldt dat mogelijk onjuist belangrijk is, en dat men goed inzicht wil hebben in wat er aan de hand is. Deze afnemers zijn zich allemaal bewust van het belang van mogelijk onjuist in de BAG en impact er van op hun dienstverlening.
2. • afnemers voor wie mogelijk onjuist niet relevant is, omdat dit geen impact zal hebben op hun taakuitvoering. Er worden geen brieven uit een mailingbestand gehaald of dienstverlening gestaakt omdat er iets niet klopt met het adres of de woonplaats oid (energietransitie, vaccinatie, bevolkingsonderzoek, gebiedsontwikkeling, handhaving, rampenbestrijding, stadsbeheer). In de praktijk wordt mogelijk onjuist door hen genegeerd, omdat een handelingsperspectief ontbreekt. Men heeft het met de gegevens in onderzoek te doen, totdat deze worden gecorrigeerd (of niet) door bronhouder.

Het probleem is een compromis dat geen van beide doelgroepen goed bedient. Voor groep 1 is de functionaliteit niet duidelijk genoeg, en groep 2 moet met een onnodig complexe API aan de slag.

Voorgestelde oplossing
Beide groepen apart bedienen.

Prioriteit
Laag