De derde ontwikkelsprint van E&L ging op maandag 5 januari 2015 van start en op maandag 26 januari werd een eerste tussentijdse demo gegeven. Tijdens de demo op 23 februari werd de sprintperiode afgerond met een presentatie van de eindresultaten. Resultaten waren onder ander een werkende demo-versie van de Historische Geocoder, inclusief API en visueel te raadplegen met een viewer, een concept-tool om plaatsnamen mee te standaardiseren en een verdere uitwerking van de gebruikte ontologie en user stories.
Geografisch vindbaar maken van content in de erfgoedsector
Een van de doelen van het project Erfgoed & Locatie is “het beter geografisch vindbaar maken van content in de erfgoedsector”. In dit stadium van de bouwfase van het project is de ontwikkeling van een Historische Geocoder API daarom erg belangrijk. De API biedt momenteel een concrete invulling van de vraag “Waar op de kaart hoort een (historische) plaatsnaam?” Het vormt een basis waarop verder in het project, en daarna, uiteenlopende tools kunnen worden gebouwd.
De bouw van de API dwingt het ontwikkelteam om allerhande kernvragen uit te werken. Zoals het vormgeven van een ontologie met een logische structuur en terminologie, waarmee de verschillende relaties tussen oude en nieuwe plaatsnamen betekenisvol kunnen worden vastgelegd. Maar ook het uitwerken van user stories, zodat duidelijk wordt wat vanuit het perspectief van bijvoorbeeld een collectiebeheerder (een medewerker van een erfgoedinstelling) nu daadwerkelijk de belangrijkste vragen zijn als het gaat om het ontsluiten van collecties op basis van geo-informatie en semantische locatiegegevens.
Demo & team
Tijdens de demo op 23 februari presenteerden leden van het ontwikkelteam de resultaten. Het team is samengesteld uit medewerkers van Digitaal Erfgoed Nederland (DEN), Waag Society, de Rijksdienst voor het Cultureel Erfgoed (RCE) en twee externe ontwikkelaars van Islands of Meaning en Grobbel & Dreis. Waag Society is de uitvoerende partij en de RCE heeft de rol van Product Owner. De middag werd geopend door Product Owner Joop Vanderheiden (RCE). Hij vertelde wat er tijdens de sprint aan werk is verricht aan het uitwerken van de ontologie en de use cases, user stories en epics.
Ontologie
Meer gedetailleerde informatie over de ontologie zal in een van de volgende blog-posts worden opgenomen.
User stories en epics voor de volgende sprint
Net als in vorige sprints werd er gewerkt volgens de scrum-methode. Binnen deze manier van agile ontwikkelen wordt gewerkt aan de hand van een epic (epos). Een epic is een verhaal dat vanuit vogelperspectief de vraagstelling van een eindgebruiker formuleert. Vanuit dit brede verhaal worden kleinere deelvragen geschreven. Op basis van deze zogeheten user stories kunnen uit te voeren werkzaamheden en taken door het sprintteam worden afgeleid, verdeeld en ingepland.
Tijdens sprint 3 zijn twee uitgangspunten geformuleerd ter voorbereiding op de eerstvolgende sprint. Daarvoor is een selectie gemaakt uit de eerder geschreven use cases. Hieruit zijn vervolgens twee epics geselecteerd en uitgewerkt om als uitgangspunt te gebruiken voor de volgende sprint.
Sprint 4 is inmiddels afgerond met als uitgangspunt de epic over het doorzoeken van data op straatnaamniveau. Een voorbeeld: een collectiebeheerder wil zijn ‘klanten’ kunnen vertellen waar een historisch adres zich op de moderne kaart bevindt. Om dit te bereiken moet er een koppeling gemaakt kunnen worden tussen historische en huidige straatnamen. De epic is uitgewerkt met een user story vanuit het perspectief van een medewerker van Erfgoed Leiden en Omstreken (ELO). Dit is in sprint 4 opgepakt in samenwerking met ELO en met gebruikmaking van een dataset met oude en nieuwe straatnamen in Leiden.
De tweede epic gaat een stap verder: hier wordt gekeken naar objectniveau (zoals gebouwen en Points of Interest). Bijvoorbeeld het kunnen achterhalen van de huidige locatie van een pand aan de hand van een oude benaming van dat pand. Hier moet een oplossing gezocht worden voor het zoeken op objectniveau. Deze epic bleek echter nog te complex om als uitgangspunt te dienen voor de eerstvolgende sprint.
Histograph: basis voor de Historische Geocoder
Het doel van de 3e sprint van E&L was het uitbouwen van het raamwerk van de Historische Geocoder tot een werkende demo-versie van de Historische Geocoder API die een onderliggende Historische Geothesaurus kan bevragen en op plaatsnaamniveau kan geocoderen. Bert Spaan en Rutger van Willigen (beiden Waag Society) gaven tijdens de demo uitleg over hun werk aan Histograph, de techniek die de basis legt voor wat binnen E&L de Historische Geocoder wordt genoemd. Om de werking van de API te kunnen demonstreren is een viewer gemaakt. Ook is er op de API een concept-tool gebouwd om plaatsnamen mee te standaardiseren.
Histograph Import
Op dit moment wordt bij het importeren van data alleen gewerkt met ND-JSON, in de toekomst moeten ook een aantal andere formaten worden ondersteund. Uiteindelijk moet het zelfs mogelijk worden voor collectiebeheerders om data zelf aan te kunnen leveren en toe te voegen. Een toe te voegen dataset bestaat voor Histograph Import uit vier onderdelen, die samen een layer vormen.
- PiTs (Plaats in Tijd of Place in Time) – opgebouwd uit (een aantal) PiT-features
- NaamFeature – plaatsnaam, straatnaam (verplicht)
- TijdFeature – numerieke tijdsbepaling (indien beschikbaar)
- GeoFeature – geo-informatie zoals puntlocatie, lijn of geometrie (indien beschikbaar)
- BronFeature – vermelding van bronhouder van de data (verplicht)
- Relaties – Reeds in de data aanwezige onderlinge relaties tussen de verschillende PiTs.
- Metadata – Meer informatie over de bron: vorm van de data en soort informatie.
- Rules – Hiermee kan het systeem zelf meer relaties afleiden tussen de objecten uit de geraadpleegde bronnen.
Histograph Core
Geïmporteerde data wordt in de Histograph Core verder onderverdeeld en doorzoekbaar gemaakt. In de graafdatabase Neo4j worden de PiTs en de relaties daartussen opgeslagen. Het gedistribueerd zoeksysteem ElasticSearch bevat de tekstuele, temporele en geo-spatiële indexen. De reasoning engine tot slot kan op basis van de geïmporteerde data nieuwe, logische relaties afleiden. Bijvoorbeeld: een plaats ligt in een gemeente, een gemeente ligt in een provincie, een provincie ligt in een land, etc.
Histograph API
Op dit moment kan met de demo-versie van de Historische Geocoder, dankzij de Histograph API, gezocht worden op basis van plaatsnaam en bron-URI. Deze bron-URI is bijvoorbeeld een URI van Geonames of de TGN – de unieke verwijzing naar de vermelding van een gevonden term in een van de beschikbare bronnen. In komende sprints zal de werking en functionaliteit van de API verder worden verbeterd en uitgebreid.
Histograph Viewer
Op basis van de ontwikkelde API is de Histograph Viewer gemaakt: een viewer voor demonstratie-doeleinden, waarmee gezocht kan worden op plaatsnaamniveau. De functionaliteit is primair bedoeld “voor eigen doeleinden, niet voor het grote publiek”. De gevonden resultaten kunnen op twee manieren worden getoond: de locaties van de gevonden resultaten worden op een kaart getoond en de relaties tussen de gevonden resultaten kunnen worden gevisualiseerd als graaf.
Plaatsnamen standaardiseren: datasets verrijken
Tot slot presenteerden Menno den Engelse (Islands of Meaning) en Petra Dreiskämper (Grobbel & Dreis) de concept-tool om plaatsnamen mee te standaardiseren die zij tijdens de sprint hebben ontwikkeld. Nadat de data door de Histograph Core is verwerkt, kan deze worden bevraagd door middel van de Histograph API. Hierdoor kunnen ingevoerde datasets ook weer geëxporteerd worden, verrijkt met nieuwe gegevens. Het ontsluiten van datasets aan de hand van gestandaardiseerde plaatsnamen is nodig om de doorzoekbaarheid van afzonderlijke collecties te vergroten en om objecten uit verschillende collecties betekenisvol aan elkaar te kunnen relateren.
De tool, met als werktitel “Plaatsnamen standaardiseren”, bevindt zich nog in concept-fase en wordt volop ontwikkeld. Op termijn moet deze tool het voor collectiebeheerders mogelijk en makkelijk maken om hun dataset(s) te importeren, te (laten) standaardiseren en vervolgens als verrijkte dataset te exporteren. Deze export bevat in elk geval een gestandaardiseerde naam uit één of meerdere van de beschikbare bronnen naar keuze: momenteel zijn dat TGN, Geonames en Gemeentegeschiedenis. Dit kan worden aangevuld met de bron-URI en met de beschikbare geo-informatie van de teruggegeven plaatsnamen (puntlocatie/coördinaten of geometrie).
Meer informatie
Hou voor meer informatie onze blog www.erfgoedenlocatie.nl en ons Twitter-account @ErfGeo in de gaten. Voor vragen kun je mailen naar erfgoedenlocatie[at]den.nl.