Use Case: Loki voor GEO Informatieverstrekking

Introductie

Loki is een experiment waarbij we de toegevoegde waarde aantonen van een chatbot voor Locatie-gebaseerde Kadaster Informatieverstrekking. Loki maakt gebruik van natuurlijke taalverwerking voor het beantwoorden van vragen. De PDOK Knowledge Graph is het kloppend hart van Loki.

Met de opkomst van virtual assistents, zoals Siri, Alexa & de Google Assistent en de ontwikkelingen omtrent de Kadaster Knowledge Graph, ontstaan er nieuwe inzichten over hoe de data van de toekomst moet worden ontsloten. Het resultaat van deze innovatie vind je door op onderstaande demonstrator te klikken! Voor een uitgebreid verhaal over hoe en waarom Loki ontwikkeld is nodigen we de lezer van harte uit om verder te lezen.

Aanpak

Zoals ieder idee begon ook het Loki project met een uitdaging. Belangrijke vragen om onszelf te stellen zijn:

  • “Wat is de huidige situatie?”
  • “Wat zijn de huidige uitdagingen?”
  • “Wat is de impact van deze uitdagingen?”
  • “Hoe gaan we die uitdagingen aanpakken?”
  • “Wat voor nut heeft de uiteindelijke oplossing?”

Bij het Kadaster beheren we verschillende (open) databronnen en stellen die ter beschikking van de gebruikers. Vaste gebruikers van onze data zijn gemeentes, provincies en overheidsinstellingen, maar ook de makelaar, accountant en iedere burger kan altijd op onze data vertrouwen. Kwaliteit van data staat hoog in ons vaandel. Tegelijkertijd is zo dat terwijl we onze databronnen al jaren aanbieden, de vraag naar informatie in de huidige digitale wereld meer en meer toeneemt. Gebruikers hebben vragen over hun huis, hun omgeving of over Nederland als geheel. Tegelijkertijd moet het gebruiksgemak omhoog. Niet alleen de techneuten of de experts in het publieke domein willen voorzien worden van informatie, maar ook de burger thuis wil zijn vragen beantwoord kunnen hebben zonder een uitgebreide kennis van APIs, Linked Data, of waar de informatie in de verschillende databronnen (van het Kadaster) te vinden is.

Met Loki proberen we voornamelijk deze laatste groep beter van informatie te kunnen voorzien. Het Kadaster wil dat iedereen een vraag kan stellen, in spraak of natuurlijke taal, en dat deze vraag niet beantwoord wordt met data, maar met antwoorden. Deze vragen zijn vaak niet gelimiteerd tot één bron, maar gaan dwars over verschillende databronnen heen. Een geavanceerd vraag/aanbod systeem, dat live met de bron data communiceert. Zo verzekeren wij kwaliteit in de data en in de antwoorden die Loki geeft.

Vervolgens is het team gaan sparren over hoe een dergelijke oplossing er in technische componenten uit zou moeten zijn. Daarbij kwamen we tot de plaat beschreven in Figuur 1:

Figuur 1 ― Initiële architectuurplaat voor Loki.

Belangrijkste uitgangspunt hier is dat het resultaat in een web-interface (deze labs.kadaster website) getoond kan worden. Visualisaties op de kaart zijn daarbij een absolute pré. De initiële focus ligt op vragen beantwoorden op basis van natuurlijke taal, waarbij er voor de spraak component gebruik gemaakt kan worden van standaard text-to-speech oplossingen zoals de Speech-to-text API van Microsoft Azure en deze te beoordelen op de kwaliteit van de resultaten op Kadaster specifieke termen, zoals adressen, postcodes en percelen. Een chatbot interface wordt gebruikt om ambiguiteit op te lossen. De ingegeven vraag wordt via natuurlijke taal verwerking (ook wel Natural Language Processing of NLP genoemd) omgezet in een SPARQL query op het PDOK SPARQL endpoint. Synoniemen worden gebruikt om tekst om te zetten in specifiek Kadaster jargon. Het resultaat van de query wordt vertaald in een antwoord en (eventueel) getoond op de kaart. Alle gesprekken met Loki en de acties die Loki op basis hiervan onderneemt worden opgeslagen. Met deze data kunnen we de herkenning van de vragen die aan Lokin gesteld worden verbeteren en inventariseren waar de behoefte zit bij de gebruikers.

Kadaster jargon

Niet veel mensen zullen hun huis beschrijven als een Verblijfsobject, zoals hij officieel in de Basisadministratie Adressen en Gebouwen (BAG) is opgenomen, net als dat weinigen naar het oorspronkelijkBouwjaar van hun huis zullen vragen. Dergelijk jargon vangen we af met synoniemen en business rules, zodat Loki begrijpt wat je wil weten.

Iteratief ontwikkelen

Bij het Kadaster Data Science team werken we volgens het Scrum/Agile proces. Door concrete doelen te stellen in korte sprints van twee weken kan er snel en dynamisch ontwikkeld worden. Iedere sprint sluiten we af met een demo waarin we de betrokken collega’s op de hoogte houden van onze voortgang. Dit zorgt er op zijn beurt weer voor dat er een continue druk is om aan het einde van twee weken iets concreets te laten zien. Ook wordt er op deze manier continu feedback opgehaald en kan er snel bijgestuurd worden als het product een grotere waarde vertegenwoordigd met een kleine wijziging.

Iteratie 1: Framework en adressen verificatie

We begonnen de eerste sprint door een framework neer te zetten voor een chatbot aangesloten op de relevante databronnen. De chatbot is gebaseerd op het Open-Source Python platform Rasa. Eerste databron in scope is de BAG, een bron die centraal staat in de PDOK Knowledge Graph en voor LOcatie-gebaseerde Kadaster Informatie (LOKI) een onmisbaar uitgangspunt biedt. Na de eerste iteratie was het mogelijk om simpele vragen over een adres uit de BAG te stellen (bijv. wat is mijn oppervlakte?). Adressen en de desbetreffende informatie verificeren we via de PDOK Locatieserver.

PDOK Locatieserver

Adressen en stadsnamen zijn voorbeelden van concepten waar vaak typfouten in ontstaan, maar tegelijkertijd van levensbelang zijn om een (unieke) locatie aan een vraag toe te wijzen. De Locatieserver van Publieke Dienstverlening Op de Kaart(PDOK) biedt een API om adressen te verificeren aan de hand van de bestaande adressen in de BAG. Deze biedt tevens standaardisatie voor de gegevens waarin ze officieel in de bron zitten. Zo kent hij Den Haag als ‘s Gravenshage en maken we mbv deze service van de Kogelaan in Zwolle de Koggelaan, in lijn met het adres wat we daar kunnen vinden.

Iteratie 2: Gecompliceerdere vragen en de DKK

Nu we de mogelijkheid hebben om ‘simpele’ vragen aan Loki te stellen breiden we zijn kennis over de verschillende vragen uit. Belangrijk speerpunt is het stellen van ‘aggregaat’ vragen, die je in staat stellen om gemiddeldes, maxima, minima en totalen aan te vragen over een straat, postcode of stad. Dit is in lijn met onze doelstelling om van Loki een Geo-platform voor iedereen te maken, inclusief de burgers geinteresseerd in self-service analyse op onze databronnen. Tevens hebben we de Kadastrale Kaart (DKK) als bron toegevoegd. Hiermee kunnen de gebruikers informatie over hun perceel opvragen.

Iteratie 3: BRT, WOZ en doorverwijzingen

Eén van de belangrijkste vragen die burgers hebben relateren zich tot de Wet waardering Onroerende Zaken (WOZ) waarde. De WOZ is momenteel te bevragen via het WOZ Waardeloket en is verder niet als open data beschikbaar. Door verwijzingen toe te voegen naar WOZ categoriën, waarmee we je een globaal beeld geven van je WOZ waarde, voorzien we gedeeltelijk aan deze behoefte. Ook voegen we verwijzingen toe naar vragen die we niet direct kunnen beantwoorden uit onze open databronnen. Daarnaast voegen we de een geometrische link met de Basisregistratie Topografie (BRT) toe, waarmee we de gebruiker in staat stellen afstanden tot de objecten in de BRT te bevragen.

Niet alle databronnen van het Kadaster zijn momenteel aan elkaar verbonden in onze Knowledge Graph. Dit is omdat niet iedere databron een administratieve link bevat met de andere bronnen. De BRT is hier een voorbeeld van. Door te kijken wat de afstand is tussen objecten in de BRT en een object in de BAG (waarvan we beiden geometriën hebben), zijn we wel in staat op deze manier een geometrische link aan te leggen. In iteratie 5 tonen we aan wat er mogelijk is als we deze eerder genoemde administratieve links wel hebben, een situatie waar we in de toekomst meer en meer naartoe bewegen.

Iteratie 4: De Knowledge Base

Zoals ieder product wat gedreven is door data valt en staat Loki met een gedegen basis aan onderliggende data. Om het gebruik van Loki te monitoren is er een database opgezet om de gesprekken tussen Loki en zijn gebruikers op te slaan. Wij gebruiken deze data op onze beurt om het model wat omgaat met de ingegeven natuurlijke taal te verbeteren. Daarnaast biedt het ons een mooie manier om de klantbehoefte van Loki in kaart te brengen. Welke vragen stellen gebruikers nu aan ons? En hoe stellen zij deze? Het development team heeft een dashboard ontwikkeld waarmee ze antwoorden op deze vragen continu in beeld brengen.

De laatste iteratie in het Loki innovatie traject richt zich op het implementeren van een databron overstijgende aanpak op een Geo-platform voor iedereen. Loki moet herkennen als gebruikers een filter toepassen op hun vraag (bijv. alle huizen met een bouwjaar voor 1600). Deze toepassing passen we ook toe op een set aan data die databron-overstijgend is. Hierbij gebruiken we een experimentele BAG-BRT link die de BRT objecten aan de panden in de BAG koppelt. Dit stelt ons in staat om vragen te stellen over de Kerken in Dordrecht (experimentele set) met informatie uit zowel de BAG en de BRT.

Een voorbeeld: “Geef mij alle kerken groter dan 500 vierkante meter in Dordrecht.”

(Voorlopig) Eindresultaat van innovatie

Na 5 iteraties van twee weken kijken we waar Loki momenteel staat en bereiden we ons voor op volgende stappen in het implementeren van deze innovatie. We nodigen iedereen uit om Loki actief te testen en gebruiken en hun feedback achter te laten. We zijn altijd benieuwd wat er beter kan. In de huidige versie van Loki zijn dit type de type vragen die Loki kan beantwoorden:

  • “Wat is de WOZ waarde van mijn huis?”
  • “Wat is het bouwjaar van mijn huis?”
  • “Wat is de gemiddelde oppervlakte in mijn straat?”
  • “Waar ligt mijn perceel?”
  • “Wat zijn de huizen in Oranje gebouwd na 2000?”
  • “Wat is het oudste huis in Haarlem?”
  • “Geef mij alle kerken gebouwd voor 1500 in Dordrecht.”

En gebruik onderstaande link om meteen te gaan testen!