Raamwerk voor de Historische Geocoder

In november 2014 heeft Erfgoed & Locatie zich samen met Waag Society gebogen over de fundamenten voor de Historische Geocoder. Met de afronding van deze tweede E&L-sprint staat er een infrastructureel en conceptueel raamwerk, dat in 2015 schaalbaar en flexibel kan toegroeien naar een volwassen oplossing voor het erfgoedveld. Kort gezegd is geocoderen het verrijken van informatie met geografische coördinaten. De Historische Geocoder in ontwikkeling voegt aan deze basisfunctionaliteit extra diensten toe, zodat deze bruikbaar wordt voor transparante, duurzame en professionele inzet door de erfgoedsector.

Naast de noodzakelijke voorbereidende werkzaamheden, zoals het inrichten van de server/ontwikkelomgeving, zijn er tijdens de sprint een aantal kleinere en grotere keuzes gemaakt, over te gebruiken techniek en onderliggende inhoudelijke redeneringen.

Historische Geocoder & Geothesaurus
Het prototype voor de Historische Geocoder werkt toe naar een API die erfgoedinstellingen in staat stelt historische plaatsaanduidingen op te vragen als geo-coördinaten. De datasets waaruit de Historische Geocoder hiervoor moet gaan putten, zal bestaan uit een collectie van toponiemenlijsten en geometrieën, die we als geheel tijdens de sprint de Historische Geothesaurus hebben genoemd.

Effectief is deze Historische Geothesaurus een verzameling van bronvermeldingen die zijn gegenereerd op basis van de gebruikte bron-datasets. Uitgangspunt is een thesaurus in Linked Data vorm, opgeslagen in een RDF store en bevraagbaar met behulp van SPARQL. Eerder werd dit onderdeel ook wel aangeduid als Ontologie en Geotemporele thesaurus. Inmiddels zijn deze benamingen waarschijnlijk niet meer de meest duidelijke, omdat dit onderdeel mogelijk niet de vorm krijgt van een thesaurus in de strikte zin van het woord.

SKOS
Het vocabulaire waarin deze Historische Geothesaurus primair wordt ontwikkeld is SKOS (Simple Knowledge Organization System). SKOS stelt ontwerpers in staat met eenvoudige middelen een classificatie op te stellen en een gegevenswoordenboek bijeen te brengen. De keuze voor SKOS is gemaakt vanwege:

  • de eenvoud, lichtgewicht
  • de toereikendheid voor de doelen van E&L
  • de beheersbaarheid voor de exploitant(en) om het schema met open source middelen te beheren

Keuze voor ElasticSearch
Er is besloten om voorlopig ElasticSearch te gebruiken, in plaats van Solr:

  1. Aansluiting op een landelijke geocodeerservice – gebaseerd op Solr – lijkt nog ver weg. Het is te betwijfelen of daar tijdens de looptijd van Erfgoed & Locatie gevolg aan gegeven kan worden. Er zijn voorzichtige plannen om aansluiting te zoeken bij de PDOK geocodeerservice, maar deze dienst kent een ontwikkeltraject die naar alle waarschijnlijkheid die van Erfgoed & Locatie overstijgt.
  2. Overdracht aan de RCE in de vorm van een component die ze zelf ook in gebruik nemen – ElasticSearch – is een route die veel dichterbij ligt en meer prioriteit heeft. Deze beslissing is met name van belang voor de RCE als beoogd exploitant van E&L.

ElasticSearch is uitgebreid met Pelias: een open source geocoder API op ElasticSearch, met importscripts voor onder meer GeoNames en OpenStreetMap. Het sprintteam heeft hieraan een importer voor de Getty Thesaurus of Geographical Names toegevoegd.

Plaats-instanties: Place in Time (PiT)
Het begrip Place in Time (of Plaats-in-de-Tijd) is voor toepassing in de Historische Geocoder en de Historische Geothesaurus nieuw leven ingeblazen. Het begrip Plaats-in-de-Tijd werd door Gerard Kuys tijdens de E&L-pilot Geovocabulaires geïntroduceerd en is destijds samen met het pilotteam uitgewerkt. Zie ook de slotpresentatie van het pilotteam: www.slideshare.net/ErfGeo/20140521-eindpresentatie-pilotgroep2.

HistorischeGeocoder-PiT-TGNEen Place in Time (PiT) vertegenwoordigt de constatering van een plaatsvermelding in een bron. Deze PiT bevat een selectie uit de beschikbare bron-metadata: minimaal een plaatsaanduiding (bv. “Amstelledamme”) en een URI naar het metadata-bronrecord; indien aanwezig tevens de datering, overige provenance-informatie en de beschikbare geo-informatie. Het Geocoder-prototype vermeld in een PiT dus altijd de bron waar de gebruikte metadata van afkomstig is. Bronvermelding betekent daarom in de context van deze sprint: het opnemen in de teruggegeven zoekresultaten van de URI waar de metadata-bron kan worden gevonden.

Gebruik van TGN en BAG in het prototype
Er is voor het prototype “handmatig” een koppeling tot stand gebracht tussen de toponiemen in de TGN (The Getty Thesaurus of Geographic Names) en de geo-informatie in de BAG (Basisregistraties Adressen en Gebouwen). Deze koppeling is gebaseerd op de in de TGN aanwezige structuur. De relaties die door de Geocoder tussen de PiT’s in de Geothesaurus worden gelegd, zijn dus gebaseerd op de in de bronnen gevonden vermeldingen van relaties.

De keuze om contouren uit de BAG te koppelen aan toponiemen uit de TGN betekent overigens geenszins een inhoudelijke keuze. Deze koppeling is gemaakt om in het prototype een dataset zonder geo-informatie te kunnen voorzien van geo-informatie uit een andere dataset. Daarbij was de keuze voor TGN en BAG een relatief voor de hand liggende, omdat beide beschikbaar waren, de TGN historische plaatsaanduidingen bevat met een relatie tot een huidige plaatsaanduiding en de BAG geo-informatie kan leveren over die huidige plaatsaanduidingen.

Demo van het prototype
Voor de stakeholders die direct betrokken waren bij de sprint werd op maandag 1 december bij Waag een demo-middag gehouden. Gedemonstreerd werd een zoekvraag op de term “Amstelodamum”: deze levert als resultaat de centrumcoördinaat voor Amsterdam uit TGN en de contour van Amsterdam uit de BAG . In het zoekresultaat wordt vermeld dat de geometrie is afgeleid van een gerelateerde bron: de BAG.

Voorbeeld: Amstelledamme-Amsterdam
In de TGN staat onder meer de term Amstelledamme (http://vocab.getty.edu/tgn/term/352466). Deze vermelding bevat de tijdsaanduiding 1200-1500 (in de velden schema:startDate en schema:endDate), maar geen geo-informatie (buiten een eenvoudig puntcoördinaat). In de Geothesaurus wordt deze vermelding opgenomen als een PiT. Deze PiT “TGN:Amstelledamme” bevat de plaatsaanduiding Amstelledamme, de datering 1200-1500 en de URI naar de vermelding in de TGN.

In de Geothesaurus is ook een PiT aanwezig met de plaatsaanduiding Amsterdam, gebaseerd op de vermelding in de BAG. Deze PiT “BAG:Amsterdam” bevat de plaatsaanduiding Amsterdam, de datering 2014, als geo-informatie de contour van Amsterdam, en de URI naar de metadata-bron.

Doordat in de TGN de term Amstelledamme gerelateerd is (als skos:altLabel) aan de plaatsaanduiding Amsterdam (http://vocab.getty.edu/tgn/7006952), kan een zoekvraag aan de Geocoder op de term Amstelledamme het volgende resultaat teruggeven: de TGN-vermelding van de toponiem, met de geometrie van recent Amsterdam uit de BAG. Zodoende kan de Geocoder een PiT zónder geo-informatie voorzien van geo-informatie, omdat de plaatsaanduiding is gerelateerd aan die van een PiT mét geo-informatie.

HistorischeGeocoder-screenshotdemoAfbeelding: Demo-voorbeeld voor het begrip “Amstelodamum” uit de TGN, met contour van huidig Amsterdam uit de BAG. Kaartgegevens © OpenStreetMap-auteurs.

Decentrale benadering
De benadering is vooralsnog decentraal: de Historische Geothesaurus is een vernetwerkte verzameling plaatsaanduidingen, zonder “centrale begrippen” of “scharnierpunten”. Er zijn vermeldingen van bijvoorbeeld Amstelledamme en Amstelodamum, zonder dat deze beide afhankelijk zijn van een (bovenliggend) kernbegrip “Amsterdam”. Voor varianten van de term Amsterdam zijn centrale concepten wellicht nog niet zo problematisch, maar dit wordt anders bij vermeldingen van plaatsen waarbij de onderlinge relatie van soortgelijke termen ambigu is. Is het middeleeuwse Dorestad hetzelfde als het tegenwoordige Wijk bij Duurstede? Die laatste term duidt immers niet voor niets op “de wijk” bíj Duurstede.

Nog complexer wordt het met bijvoorbeeld het Romeinse fort Levefanum, tussen het huidige Rijswijk (Gelderland) en Wijk bij Duurstede. Moet een vermelding hiervan gerelateerd worden aan een kernconcept “Wijk bij Duurstede”, of behoeft dit een eigen kernconcept “Levefanum”? Eenzelfde randgeval is het dorp Sloten, dat tegenwoordig is opgeslokt door het uitdijende Amsterdam. Moet “Amsterdam” het kernconcept worden van het 17e-eeuwse “Sloten” of “Slooten”? Zo niet, welke instantie van de plaats Slo(o)ten zou dan wel het kernconcept moeten zijn? En hoe hangt dat concept dan weer samen met de plaats Amsterdam?

Dit soort probleemgevallen zijn te vermijden door af te zien van centrale kernconcepten, “linking pins” of “scharnierpunten”. Eén mogelijkheid is om slechts de ruimtelijke relaties van overlap of nabijheid te benoemen, ongeacht de periode. Beide probleemgevallen van Dorestad-Wijk bij Duurstede-Levefanum en Slo(o)ten-Amsterdam hebben ruimtelijke posities ten opzichte van elkaar die minder problematische relatievormen opleveren dan het gebruik van centrale kernconcepten of scharnierpunten.

De decentrale benadering lost ook een ander probleem op. Zoekt iemand op “Kerkstraat, Amsterdam”, dan wordt allicht niet alleen de huidige Kerkstraat in Amsterdam bedoeld, maar ook die in Amstelodamum en Amstelredam. In plaats van het leggen van semantische relaties (bijvoorbeeld in de vorm van <grs:Kerkstraat> skos:broader <grs:Amstelodamum>, <grs:Amstelredam>, <grs:Amsterdam>, <…>) is een betekenisloze, geografische relatie mogelijk een generiekere oplossing met grotere vrijheid. Door eenvoudigweg te kijken welke PiT’s met het label “Kerkstraat” een ruimtelijke overlap (geografische intersect) hebben met PiT’s met het label “Amsterdam”, wordt de gebruiker een vrijheid geboden die met ‘klassieke’ alignment niet haalbaar is. Iedere willekeurige combinatie van PiT’s kan zo in principe gebruikt worden.

Wordt vervolgd…
Of deze decentrale aanpak en relaties op basis van geografische nabijheid ook daadwerkelijk de beste werkwijze bieden voor de uiteindelijke Historische Geocoder, zal binnen E&L vanaf januari 2015 verder worden onderzocht. Wellicht dat hiervoor tijdens komende sprints andere effectievere oplossingen gevonden kunnen worden.

This entry was posted in Demo, Documentatie, Nieuws. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *