Bij terugmeldingen bestaat er een status “Doorgestuurd”. Deze ontstaat als een melding naar een andere registratie wordt doorverwezen. Nu schijnt het dat dat een permanente eindstatus is in de originele registratie. Ik vraag mij eigenlijk af of dat wel wenselijk en correct is.
Ik meen mij te herinneren dat de enige feedback die daarna beschikbaar is over de voortgang van de stip, bestaat uit e-mailtjes vanaf de alternatieve registratie. Maar als ik dus de stip via de originele registratie in de gaten houd, via de API of via een WFS laag, dan weet ik eigenlijk niet a) waar de stip naartoe is gestuurd, en b) wanneer de stip afgehandeld is.
Melders die hun e-mailadres hebben ingevuld bij de terugmelding ontvangen bericht dat de terugmelding is doorgestuurd naar een andere registratie. Er wordt een nieuwe melding gemaakt voor de nieuwe registratie en ook hier ontvangt de terugmelder statusberichten over.
Nou moet je het me maar niet kwalijk nemen, maar als ik eerlijk ben dan lees ik geen mening in je antwoord. Als ik tussen de regels door lees, dan vermoed ik dat je wilt zeggen dat het voldoende feedback zou moeten zijn voor iemand om de voortgang bij te houden.
Ervan uitgaande dat je dat bedoelt, ben ik het natuurlijk met je eens. Voor een incidentele, particuliere melding zal dat ruimschoots afdoende zijn. Maar ik zat meer te denken aan een situatie waarbij meldingen in bulk worden aangeboden via de API. Die API is er uiteraard niet voor niks. Als er gemiddeld 3 à 4 statuswijzigingen gemoeid zijn met een melding en je stuurt een bulkset op van laten we zeggen 100 meldingen, dan zou ik dus 400 e-mailtjes moeten gaan doorhaspelen.
En 100 meldingen om te versturen, heb ik met twee middagen werk wel bij elkaar gesprokkeld. Of stel je voor dat we op enig moment AI gaan inzetten voor automatische signalering bijvoorbeeld, dan kunnen het er makkelijk 1000-tallen worden, en er zijn bronhouders die 100k mutaties verwerken per jaar. Als die actiever met terugmeldingen zouden willen werken, dan is de vraag hoe je dat enigszins beheersbaar kunt automatiseren.
En om alvast een voorschot te nemen. Daarvoor is het, naar mijn nimmer bescheiden maar soms uiterst twijfelachtige mening, tevens van belang dat het statusgebruik bij de gemiddelde beheerder ook wordt gesaniteerd.
We vinden het belangrijk dat gebruikers terugmeldingen kunnen doen binnen de omgeving waar zij een kaart gebruiken. De API is ontwikkeld zodat software ontwikkelaars in hun applicatie terugmeldingen kunnen tonen en terugmelden mogelijk te maken.
Door meerdere meldingen één-voor-één aan te bieden aan de API, is bulk terugmelden mogelijk. Dit was echter niet de reden om deze API te ontwikkelen (zie toelichting hierboven).
Uiteraard wordt iedere valide melding gewaardeerd.
Ik heb onlangs weer een statuswijziging van een doorgestuurde terugmelding ontvangen en kan derhalve volgende meegeven:
In de begeleidende tekst van de statuswijziging is een zin opgenomen:
Blokcitaat
Uw melding is doorgestuurd naar .
Ik vermoed dat daar automatisch de naam van de doelregistratie achter had moeten staan, maar die staat daar dus niet. De bronhouder heeft ook geen moeite genomen voor een toelichting, dus dan is de informatiewaarde wel erg summier, temeer omdat het me ook volslagen onduidelijk is waarom die specifieke melding doorgestuurd zou moeten worden.
(Betreft terugmelding met nummer: BGT00188873)
Wat verder nog een nice-to-have zou zijn is dat de nieuw aangemaakte melding een referentie naar de originele melding zou kunnen krijgen. De nieuwe melding gaat hetzelfde proces in als een rechtstreekse melding, maar daarmee wordt de nieuwe e-mail erg onduidelijk. “Uw melding” is namelijk helemaal niet van toepassing.
En heden ten dage krijg ik gelijk angstaanvallen over hackpogingen als ik ineens e-mailtjes krijg van mij onbekende meldingen. Misschien dat we dat proces eens kunnen herzien om het net even wat informatiever te laten verlopen?
Ik zat ook eens te experimenteren om met Python geautomatiseerd terugmeldingen te doen met de api.
Bedenk wel dat je met een knap AI systeem, afhankelijk van het onderwerp en nacontroles met behulp van andere databronnen, zo rond de 80% true positives en 20% false positives realiseert. Wanneer je dus geautomatiseerd 100 terugmeldingen doet, moet de beheerder er 20 afkeuren. Niet erg bevorderlijk voor het werkplezier bij de bronhouders.
Kies je ervoor de zekerheidsparameters strenger in te stellen zodat er zeker géén false positives verstuurt worden, dan mis je ook veel true positives. Ofwel alleen het laagst hangend fruit wordt gemeld waardoor het later nog moeilijker wordt een knap AI systeem op te tuigen met een behoorlijke ratio true versus false positives. Puur omdat de makkelijkste true positives al uit de populatie zijn verdwenen door een net-niet optimaal systeem.
Ofwel: bezint eer ge begint. Maar het staat je natuurlijk vrij om lekker te hobby’en en te prutsen.
Deel gerust je resultaten en bevindingen (is ook een oproep aan mezelf). Wellicht kunnen we er met zijn allen wat moois van maken.