vrijdag 25 juli 2014

Roadmap for smarter historical records search engines

This article describes a roadmap which developers of historical records search engines can follow to make the results better. To show the most comprehensive solution works, some insight is given in the results of the website Open Archives.

Roadmap

Generation 1 – searching within a single databaseGeneration 1 – searching within a single database

Many archive websites in the Netherlands offer historical records. These records are indexed and the search engine uses this index of meta data. Search results are listed and usually can be filtered by source type and year. By clicking a search result the record is shown, e.g. all the available meta-data and, when available, a link to a scan. The search ends here (why?!). The next step in the search process has to be taken by the user himself, maybe by clicking a linked name in the result which starts a new search, by looking at other search result or entering a new search based on gained knowledge.

Generation 2 – searching within multiple databases (portals)Generation 2 – searching within multiple databases (portals)

When a website has multiple databases (or logical datasets within a single database) from several sources, the user can search these multiple databases with one search. The Dutch playing field shows 3 categories of ‘portals’. One big supplier of an archival system (a SaaS solution) has made a separate portal site which shows all data of all customers (who also show only their own data on their own website). Another big supplier, who also offers an archival system as a SaaS, doesn’t offer a separate portal, but offers their customers the opportunity to have the search on their website include search results from other customers (archives). A third category of websites collect data from archives, for example by harvesting via the OAI-PMH protocol. This generation of search engines simply have more data to search within, but in principle don’t differ much from the 1st generation.

Generation 3 – smart re-searching after records selectionGeneration 3 – smart re-searching after records selection

A researcher/genealogists usually continues the search to get knowledge about the personal relations and to find more ‘proof’ in the form of relevant records. These kind of searches, which follow after a record is selected and shown can be executed automatically! With ‘smart re-searching’ I refer to the ability to use the meta-data of a records to do additional relevant searches. The results, being suggestion for related records, are shown with the record (e.g. on the page of the birth record the persons marriage- and death record is also shown as direct links). Smart re-search which can be executed automatically using for example the name & birth date of the person(s) mentioned, or by using the names of both parents. With smart re-search you’ll get more information from the same database (compared to the 1st generation search engines)!

Generation 4 – smart re-searching within multiple databasesGeneration 4 – smart re-searching within multiple databases

This generation of search engines merge the combination of datasets (the portals) with smart re-searching which results in getting even more information from more data. This make sense in a technical way, but also in a practical way. People may not live in one place only. They are born in one place, get married in a second place and die in a third place. This results in records being scattered over multiple archives. This generation of search engines shows a combined view of records from several archives centred about a person.

Generation 5 – smart re-searching within multiple databases and beyondGeneration 5 – smart re-searching within multiple databases and beyond

The ‘pool of databases’ which are queried for a search can be expanded even more, with external sources. By using the API’s of such external source or harvesting the required index (so not all data, just the meta-data to be used in smart re-searching) even more information is available for a smart re-search after record selection.
So, don’t stop searching after a search result is shown, this should trigger smart re-search, which should include external data sources!

The proof of the pudding is in the eating

Open Archives is an independent website which harvests open data (=data available for re-use under a free license) from archives and researchers. Archives in the Netherlands which offer open data include Erfgoed Leiden, the municipal archives of Tholen, Ede, Schouwen-Duiveland and Wassenaar, regional archive Langstraat Heusden Altena and the National Archives. The index of these datasets is used for normal querying but also smart re-searching. For smart re-searching an array of  external sources is also used, like Find-A-Grave-like sites Graftombe.nl and Dutch-Cemeteries.com, the victim register of the war graves society, the Biographic Portal of the Netherlands and the largest Dutch family tree website Genealogie Online. So Open Archives is an example of a 5th generation search engine.
An examples shows the smart re-search in action. The registration of Cornelia van Ast (a record of the archive in Leiden) is presented with:
  • a link to the birth record from Noordgoude (from the municipal archive of Schouwen-Duiveland),
  • links to 2 registrations in Tholen (from the municipal archive of Tholen),
  • a link to a family tree on Genealogie Online. a link to a photo of her grave on Dutch-Cemeteries.com, and,
  • a link to a family tree on Genealogie Online.
These highly linked results are a very useful tool for users!

chord diagram


Nice example, but are there more? To find out, all records presented on Open Archives where analyzed to count the links to other sources (from the same archive, another archive or an external source) for each record based on name & birth date (so only one method of smart re-searching). The resulting matrix (with number of links from a source to another source) can be shown in a chord diagram. This diagram shows smart re-searches do deliver results. The dynamic version of this graph can be seen on the Archives linked by historical persons page on Open Archives.
chord diagram
In this diagram the 3-letter codes are the datasets from archives, the 2-letter capital codes are external sources (these sources obviously don’t have links to archives). The ‘humps’ in the archive datasets mean that a lot of additional records were found in the same archive dataset, showing that even generation 3 is already feasible and valuable.

maandag 7 juli 2014

Inzet van de crowd en algoritmes bij Nijmeegse woningkaarten

Open Archieven heeft nu een tweede crowdsourcingsproject: de woningkaarten van Nijmegen (1920-1946).

De door het Regionaal Archief Nijmegen aangeleverde data (bestaande uit 26.458 records) bevatte per woningkaart een link naar één scan. Het idee hierachter was dat de woningkaarten dubbelzijdig zijn en de achterkant vaak leeg was. Bij een steekproef bleek mij echter dat het ook vaak voorkwam dat er meerdere scans waren gekoppeld aan één woningkaart. Het meest extreme voorbeeld was de woningkaart van Westkanaaldijk 301 (Weesinrichting Neerbosch) waaraan maar liefst 290 scans aan gekoppeld waren. Via wat ‘scripting’ heb ik per woningkaart achterhaald welke scans eraan welke woningkaart waren gekoppeld. In onderstaande grafiek (met logaritmische y-as) kan worden afgelezen hoeveel woningkaarten een bepaald aantal gekoppelde scans heeft.

 image

Als alleen de eerste scan van een woningkaart geïndexeerd zou worden (dus de eerste verticale balk in bovenstaande grafiek) zou een groot deel (35.950 scans) ongeïndexeerd blijven. Dit leek mij geen goed idee, vandaar dat alle scans zijn ingelezen in de indexeringstool van Open Archieven.

Scan bevat geen informatie

Toen alle 59.667 scans waren opgenomen kwam je bij het indexeren wel vaak een lege woningkaart tegen, te vaak… De indexeerder heeft de mogelijkheid om aan te geven dat de scan geen informatie bevat, maar dit voelt toch niet fijn als je wilt indexeren. Bij crowd-sourcing vraag je aan mensen om een relatief eenvoudige taak uit te voeren die voor de computer te lastig is. Een mens ziet eenvoudig of een kaart leeg is, maar een computer?

De uitdaging die werd opgepakt: bedenk (en maak) een algoritme die een scan van een ingevulde woningkaart kan onderscheiden van een scan van een lege woningkaart. De gekozen aanpak gaat ervan uit dat de woningkaarten een vaste structuur hebben. Er wordt uit de woningkaart een gedeelte gepakt die overeenkomt met ruwweg de 1e cel van het ‘formulier’ (hieronder weergegeven door de gele rechthoek). Het aantal kleuren van dit gedeelte wordt teruggebracht naar een zeer beperkt aantal kleuren. Hierna wordt er ‘geteld’ hoeveel zwarte pixels er in voorkomen. Wanneer dit aantal hoger is dan een bepaalde drempelwaarde, dan staat er tekst!

image Een visuele controle van de methode leerde dat het algoritme vrij goed werkte maar niet perfect is, of beter gezegd de uitgangspunten die ten grondslag liggen aan het algoritme zijn niet altijd waar. Een enkele keer begint de tekst in de 2e cel, soms is de kaart donker waardoor er meer zwart wordt ‘gezien’, soms is de structuur van de kaart net iets anders, enz.

Kwaliteit van indexeren

Om hoge kwaliteit indexen te krijgen wordt elke kaart minimaal 2 keer geïndexeerd. Als er twee maal hetzelfde is ingevoerd (door twee verschillende indexeerders) dan kan worden aangenomen dat de tekst goed is overgenomen (de kans dat twee personen dezelfde fout maken is erg klein). Komt de invoer niet overeen dan wordt de kaart voor een 3e keer ter indexering aangeboden. Is er hierna nog niet een set van 2 overeenstemmende invoersets dan kijkt een controleur er naar.

Omdat er niet volledig op het lege-kaart-detectie-algoritme kan worden vertrouwd worden de indexeerders hierbij ingeschakeld. Het algoritme zorgt voor de 1e invoer – ruim 4 duizend herkende lege kaarten - en de indexeerders voor de 2e invoer. Op deze manier krijgen indexeerders de helft minder lege kaarten te zien en wordt de uitkomst van het algoritme gecontroleerd door de indexeerder (doordat hij/zij aangeeft dat de scan geen informatie bevat).

Nu is het even afwachten totdat de indexeerders alle woonkaarten hebben geïndexeerd, dan wordt zichtbaar of het algoritme veel of weinig lege kaarten heeft gemist. Hoe dan ook is er dan weer een mooie index beschikbaar, die voor een ieder als open data beschikbaar is!

dinsdag 27 mei 2014

What's the best way to harvest an OAI-PMH data provider?



The OAI-PMH protocol defines several verbs which can be used in requests to an OAI-PMH data provider. For harvesting, the most obvious are:
  • ListIdentifiers, which returns a list of identifier of records, in combination with
  • GetRecord, which returns the record for the specified identifier
  • ListRecords, which return a set of records
Which verb to use?

Some harvesting solutions choose to do a ListIdentifiers and for each identifier do a GetRecord. Some choose to harvest with the ListRecords verb. Although both methods lead to the same content (discarding the OAI envelope header and focusing on the record), the number of HTTP requests differ, obviously. But, does this have an impact on the performance?

Which connection method to use?

As the OAI-PMH protocol harvests via the HTTP protocol there are also alternative connection methods to be inspected, like HTTP compression (accept-encoding:gzip) and connection Keep-Alive. What is the impact of these alternative connection methods on the performance of OAI-PMH harvesting?

Test method

To answer these questions the following test was conducted. Four (Dutch) OAI-PMH data provider where selected. For each data provider an harvest for about 10.000 records was done with both the ListIdentifier/GetRecord method and the ListRecords method. For each of these tests the standard connection was timed, as well as a gzipped, gzipped+keep-alive and keep-alive connection method. These 16 tests were carried out twice and an average of the elapsed times was analyzed.

Test results

The graph below shows the results of these tests, so the number of records per minute for each connection type (more=better).
The complete results as well as the graph are available in a Google Spreadsheet. For the connection type WebPageTest was uses to determine if the method was supported. The tests where carried out with 2 Perl scripts and a Bash file which, together with the resulting output, can be downloaded here.

Conclusions

  • Clearly, you get a better performance (=higher number of records per minute in a harvest) when you use the ListRecords method. So lesser HTTP requests results in faster harvests (about 2.5 - 11 times faster!!!)
  • The use of keep-alive and gzip varies per OAI-PMH data provider. In general: if a data provider supports keep-alive and/of gzip, you'd better use is, it improves performance! You mileage may vary per data provider, so test what's the best solution.

Final notes
  • Although this test was conceived to show the difference in verb usage and connection type, it also shows that some data providers perform better than others. Room for improvement...
  • For those who have inspected the used Perl scripts might wonder why the "Beeld en Geluid" and "Open Beelden" data providers receive other parameters. Well, it's seems they do not follow the OAI-PMH version 2.0 standard by the letter. It's stated that the metadataPrefix is required when doing a ListIdentifiers or ListRecords. But these two data providers do not work when you use the metadataPrefix and resumptionToken together...

donderdag 10 april 2014

Hoe veilig zijn genealogische en archief websites?

Deze week is een ernstig lek gevonden dat het veilig geachte HTTPS (en ander type verkeer op basis van SSL/TLS) een stuk onveiliger maakt. De lek in de software bibliotheek OpenSSL kreeg de naam Heartbleed. De bibliotheek is verbeterd en het is dan ook zaak dat website eigenaren de nieuwste versie (waarin het probleem is opgelost) installeren en gebruiken.

Een kleine steekproef leert dat Nederlandse genealogische en archief websites geen probleem (meer) hebben op dit punt (zie hier ook een lijst van internationale genealogische websites).

Maar…. uit deze steekproef blijkt ook dat er nog websites zijn die geen HTTPS gebruiken voor login, winkelwagen en bestelpagina’s. Terwijl het versleutelen van persoonlijke informatie toch wel een minimum beveiligingsmaatregel is! In onderstaande tabel zijn de website die geen HTTPS gebruiken rood gemarkeerd.

Website

SSL niveau (*1)

archieven.nl (*2)

-
beta.bhic.nl B
computergenealogie.org -
gahetna.nl A-
gemeentearchief.wassenaar.nl (*3) -
genealogieonline.nl A-
militieregisters.nl.geneabase.com A-
ngv.nl -
openarch.nl A-
pictura-dp.nl (*4) A-
stadsarchief.amsterdam.nl A-
stamboom.nl -
stamboomforum.nl A-
stamboomnederland.nl -
stamboomvragenforum.nl -
tresoar.nl F
uwstamboomonline.nl -
velehanden.nl -
wiewaswie.nl B

*1 Via https://www.ssllabs.com/ssltest/index.html kun je nagaan hoe de HTTPS implementatie van een website er voor staat. Hierbij wordt het Amerikaanse grade systeem gebruikt waarin A het beste is en F het slechtste.

*2 Deze score (dus geen HTTPS) lijkt van toepassing op alle archiefwebsites die gebruik maken van de software van archieven.nl (De Ree), zoals bijvoorbeeld het Zeeuws Archief

*3 Deze score (dus geen HTTPS) lijkt van toepassing op alle archiefwebsites die gebruik maken van Atlantis (DeventIt), zoals bijvoorbeeld Stadsarchief Rotterdam

*4 Deze score (A-) lijkt van toepassing op alle archiefwebsites die gebruik maken van de software van Picturae.

Werk aan de winkel

Alle website/product eigenaren die nog geen HTTPS gebruiken op die delen van de website waar persoonlijke informatie “over de lijn” gaat: ga je schamen en ga aan de slag met HTTPS!

Zijn er sites die in bovenstaande tabel ontbreken, test de website via SSLlabs en plaats het resultaat als commentaar bij dit artikel.

donderdag 3 april 2014

De WOB als middel om aan open data te komen

Met Open Archieven probeer ik archiefinstellingen te laten zien wat er met open data kan, dat het kan leiden innovatie. Het geeft me ook een goede reden om archiefinstellingen om open data te vragen. Op één zo’n verzoek reageerde het betreffende archief niet, reden voor mij om het middel Wet Openbaarheid van Bestuur (WOB) eens uit te proberen…

Stadsarchief Enschede

Op 3 december 2013 stuurde ik digitaal een WOB verzoek (PDF) naar de gemeente Enschede om historische persoonsgegevens. In dit verzoek verzocht ik hen om de meta-gegevens van de volgende openbare bronnen in machineleesbaar formaat:

  • overlijdensakten Enschede, 1811-1950
  • geboorteakten Lonneker, 1811-1910
  • overlijdensakten Lonneker, 1811-1934
  • huwelijksakten Lonneker, 1811-1934
  • bevolkingsregister Enschede-Lonneker, 1811-1936

De eerste 4 bronnen worden op de website van Stadsarchief Enschede via Atlantis ontsloten. De 5e bron zit opgesloten in PDF bestanden die het Stadsarchief op haar website deelt. Geen van deze bronnen zijn herbruikbaar…

Ik heb gevraagd of ik de gegevens “in een machine leesbaar formaat, bij voorkeur volgens een open standaard (te denken valt aan CSV en OAI/PMH volgens A2A model)” kon krijgen. Voor de aanlevering gaf ik hen verschillende mogelijkheden: via e-mail danwel CD/DVD, of door publicatie op http://opendata.enschede.nl/ en/of http://www.opencultuurdata.nl/.

Het besluit van 20 januari 2014 (PDF) luidde als volgt: “De gemeente Enschede zal de door u gevraagde gegevens in het tweede kwartaal van 2014 als open data beschikbaar stellen via de gemeentelijke website, opendata.enschede.nl. De gegeven zullen beschikbaar worden gesteld in csv-bestandsformaat”.

Dit positieve resultaat smaakte naar meer! Vandaar dat ik hierna nog 3 WOB verzoeken de digitale deur uit deed…

Gemeentearchief Venlo

Op 26 januari 2014 stuurde ik digitaal een WOB verzoek (PDF) naar de gemeente Venlo. Dit verzoek was opgesteld naar het model dat ik voor Stadsarchief Enschede had gebruikt, met die kanttekening dat Venlo geen gemeentelijke open data portaal (of beleid) heeft.

Op 4 februari ontving ik per e-mail de melding dat ik het WOB-verzoek niet per e-mail kon indienen (op grond van artikel 2:15, eerste lid, van de Algemene wet bestuursrecht) maar dat dit schriftelijk moest. OK, mijn e-mail uitgeprint, ondertekend en opgestuurd, zucht. Op 13 februari vroeg de gemeente mij, via e-mail, om mijn postadres, want die had de DIV afdeling niet overgenomen van de envelop. Zucht, gemeentes, maak het jullie zelf nou niet zo moeilijk…

Op 26 februari 2014 ontving ik de beschikking (PDF). De gemeente oordeelde dat de gevraagde meta-data geen betrekking heeft op stukken die een bestuurlijke aangelegenheid betreffen en dat het verzoek om deze reden niet kan worden aangemerkt als een verzoek om informatie die betrekking heeft op een bestuurlijke aangelegenheid in de zin van artikel 3, eerste lid, van de Wet openbaarheid van bestuur.

In mijn bezwaarschrift heb ik hen gewezen op uitspraak 201105857/1/A3 van de Raad van State, met name overweging 10. In deze overweging stelt de Raad van State dat het betoog van het college van burgemeester en wethouders van Weesp, dat meta-data niet onder artikel 3, eerste lid, van de Wet openbaarheid van bestuur valt, faalt.

Een volgende stap in dit WOB traject is een hoorzitting. Omdat ik afreizen naar Venlo vanuit Den Haag iets te veel van het goede vind heb ik aangegeven niet te komen maar wel een pleitnota te zullen indienen. Wordt dus vervolgd…

Gemeentearchief Schouwen-Duiveland

De afhandeling van WOB verzoeken verschilt per organisatie, die ervaring had ik al bij mijn WOB verzoeken inzake WieWasWie. Komt het WOB-verzoek niet verder dan de juridische afdeling dan lijkt het adagium “probeer er onderuit te komen”. Heeft een gemeente een open data beleid, dan lijkt het al makkelijker. Gemeente Schouwen-Duiveland pakte het naar mijn smaak helemaal fijn op: het gemeentearchief nodigde me uit voor een gesprek!

Uit het fijne gesprek kwam naar voren dat zij positief wilde besluiten ten aanzien van mijn WOB-verzoek. Hiervoor waren zij ook ten rade gegaan bij het Zeeuws Archief (vanwege totstandkoming dataset/eigenaarschap) en hun leverancier (voor een kosteninschatting). Zij gaven aan dat het WOB verzoek voor hen ook een prikkel was om een beleid ten aanzien van open data te ontwikkelen (waaronder deelname aan de Masterclass Open Cultuur Data), erg mooi!

Vooralsnog zal het gemeentearchief de gegevens eerst aan mij leveren (zodra de gemeente een OAI-PMH/A2A koppeling heeft ingericht), waarbij de wens is de gegevens later als open data beschikbaar te stellen.

Gemeentearchief Wassenaar

Mijn WOB verzoek aan de gemeente Wassenaar (PDF) betrof de meta-data van de geboorteakten van 1811-1902, huwelijksakten van 1811-1926 en overlijdensakten van 1811-1950 van de Burgerlijke Stand van Voorschoten en Wassenaar, alsmede de Hervormde doopboeken van Voorschoten van 1621-1811.

Op 17 februari volgde het bericht (PDF) dat het verzoek niet zou worden ingewilligd. In mijn bezwaarschift heb ik hun argumenten proberen te ontkrachten. Zo zouden de gegevens in een databank zitten waarvan de gemeente Wassenaar niet de maker is, maar wie is dan de maker, is het databankrecht van toepassing? Ook zou het verstrekken van de informatie in de vorm van open data redelijkerwijs niet gevergd kunnen worden van de gemeente Wassenaar. Waarom dan niet (het archiefbeheersysteem heeft toch wel een exportfunctie)?

Maar vooral het niet juridische argument vond ik jammer: er zou geen speciaal gemeentelijk belang zijn om deze meta-data als open data te publiceren. Een dergelijk argument gaf mij de mogelijkheid nog eens aan te geven wat open data is en waarom die voor zowel aanbieder als potentiële gebruikers grote meerwaarde kan bieden.

Na het bezwaarschrift volgde de datum van de hoorzitting (16 april). Tot mijn grote verbazing ontving ik op 31 maart een gewijzigd WOB besluit (PDF), er was nu een gedeeltelijk toekenning en wel met betrekking tot de gegevens van Voorschoten! Bij dit besluit (per e-mail) zaten ook de gevraagde gegevens van Voorschoten (in XLS/CSV formaat). Binnenkort zullen deze op Open Archieven zijn te vinden!

Hierna rees de vraag of de hoorzitting doorgang moest vinden. Na een telefoontje van de juridisch medewerker wist ik genoeg: de meta-gegevens (en afbeeldingen) van de BS akten van Wassenaar die het gemeentearchief op haar website toont zijn ter beschikking gesteld door een vrijwilliger, op voorwaarde van anonimiteit en niet verder verspreiden van de databank. Voor mij was hiermee mijn WOB-verzoek afgehandeld: een gemeente mag niet iets weggeven waarvan ze de eigenaar niet is. Nog even los van of je eigenaar kan zijn van data en of het databankrecht van toepassing is, blijft het wel raar dat de gemeente niet zelf kan beschikken over deze meta-data…

Conclusie

Ik had mijn twijfels of ik via het WOB verzoek aan historische persoonsgegevens in de vorm van open data kon komen. Maar bij 2,5 van de 3 gevallen heeft het dus gewerkt, bij de 4e is het nog te bezien. Het helpt hierbij als het verzoek terecht komt bij een persoon/afdeling die verder kijkt dan het juridische aspect maar oog heeft voor open data.

Ik heb bij deze WOB verzoeken steeds de gemeente als ingang gekozen. Ik hoop dat ook archiefinstellingen zelf open data beleid gaan vormen en (genealogische) open data ter beschikking gaan stellen (zie ook Stappenplan Open Data op de ArchiefWiki). Want dat heb ik toch liever: organisaties die het nut van open data inzien en om deze reden open data leveren, en niet omdat het ‘moet’ vanuit Den Haag of Europa of wordt ‘geëist’ via de WOB.

zondag 8 december 2013

Straatweergave Open Archieven

Van punt naar lijn

In Uitdagingen bij geocoderen historische straten ging ik nog uit van het plaatsen van een marker in de betreffende straat op een historische kaart.

image

Zo’n punt op de kaart wekt echter ten onrechte de indruk dat de locatie precies bekend is, dat je het juiste huis aanwijst. De meeste ‘adresgegevens’ in historische akten beperken zich tot straatnamen (en wellicht wijk informatie). De huisnummers in oude bevolkingsregisters komen vaak niet meer overeen met de moderne nummering. Het aanwijzen van de straat is voor de toepassing in Open Archieven dan ook genoeg, maar een straat moet je niet met een punt maar met een lijn weergeven!

Op zoek naar geometrie van straten

Een goede bron voor geometrische data is OpenStreetMaps, te vergelijken met Google Maps, maar OpenStreetMap (OSM) biedt open data, gelicenseerd onder de Open Data Commons Open Database License (ODbL).

De XML variant van de data (de ‘planet’ variant) is ongecomprimeerd ruim 400GB (gecomprimeerd zo’n 29GB). OSM maakt het echter ook mogelijk om van een bepaald gebied (een zog. bounding box) data te downloaden via de Overpass API. Voor Leiden komt dit neer om een bestand van zo’n 13MB, wat een stuk behapbaarder is. Dit bestand is voor Open Archieven geschikt gemaakt zodat op basis van een straatnaam (in OSM termen een way) een lijn kan worden getekend (op basis van 2 of meer nodes).

image

Bruikbaarheid van de data

OSM biedt veel gegevens, maar is niet compleet. Zo vond ik bijvoorbeeld de Leidse straten Hermanstraat, Brandewijnsgracht en Paradijssteeg niet in OSM. Maar als OSM gebruiker kun je ook, net als bij Geonames, zelf gegevens toevoegen! Een kwestie van een lijn tekenen en gegevens opvoeren en de straten zijn nu wel beschikbaar, voor iedereen!

Het grootste nadeel van OSM is dat alleen de huidige geometrie wordt weergegeven, historische straten vind je niet en kan je ook niet opvoeren. Een groot deel van de straten die voorkomen in historische akten zal gewoon beschikbaar zijn omdat deze nog steeds bestaan, een deel van de straten zal hernoemd zijn, maar een resterend historische/verdwenen deel zul je handmatig in je eigen dataset moeten opvoeren.

Open data slim gebruiken

Open Archieven heeft een alternatieve schrijfwijzen bestand aangelegd om de oude schrijfwijzen en namen te koppelen aan de hedendaagse varianten. Zo wordt de St. Aeachtenstraet dus herkend als Sint Aagtenstraat, de Zuytcingel als Zuidsingel en zelfs de Achtergracht (die is hernoemd) als 5e Binnenvestgracht. Het aanleggen van deze lijst is nog handwerk, op basis van oude kaarten en bronnen als Overzicht van veranderde straatnamen en verdwenen straten en stegen van Jan van Hout.

De lijst met straatnamen wordt gebruikt om in specifieke velden van de genealogische gegevens op Open Archieven te zoeken naar bekende straatnamen. Bij sommige akten is er een apart veld ‘straat’, maar er kan ook een straat opgenomen zijn in de woonplaats. Het lastige aan het woonplaats veld is dat er een woonplaats in kan zitten, een straatnaam, of combinatie, zoals “Leiden, Oranjegracht Wijk 8 No. 652”. Open Archieven herkent in dit voorbeeld “Oranjegracht” waardoor er een link gelegd kan worden naar de historische kaart met gehighlighte straat (zie voorbeeld).

woensdag 23 oktober 2013

Uitdagingen bij geocoderen historische straten

Op Open Archieven wil ik graag een historische kaart tonen met plaats indicator als er in de akte een straatnaam voorkomt.

image

Proof of concept

Deel 1 van deze uitdaging is nu (in tweevoud) te zien als proof of concept. Deze PoC's tonen een onderstreepte straatnaam die linkt naar een historische kaart. Hiervoor moest ik allereerst een goede historische kaart vinden en deze georefereren zodat deze netjes op Google Maps kan worden geprojecteerd (dit vanwege de handige toolset die je dan als ontwikkelaar ter beschikking hebt). Voor zowel Leiden als Noordwijk heb ik dit nu voor elkaar.

Deel 2 is de volgende uitdaging is om de marker op de juiste plaats te plaatsen, in de PoC's was dit "hard gecodeerd".

Deze uitdaging valt uiteen in twee onderdelen:

  • het verkrijgen van de breedte- en lengtegraad van de historische straat (uitgangspunt: ik neem genoegen met het midden van de straat, dus één punt)
  • het herkennen van de (bekende) straatnamen in de akte

Geocoding

Voor het verkrijgen van de geo-info van alle historische kaarten zou ik voor Leiden en Noordwijk zelf kunnen gaan “prikken”. Dit is echter niet echt een schaalbare  oplossing. Als er straks informatie van andere archieven op Open Archieven worden gepresenteerd komt er een boel handwerk bij.

Qua oplossing denk ik aan een combinatie van automatisch geocoden (dus een adres aanbieden aan bijvoorbeeld de Google Maps API om zo de coördinaten te verkrijgen) gecombineerd met een crowdsourcing oplossing (dus de crowd hulp vragen om punten te zetten en te controleren).

Het automatisch geocoden zal maar een beperkte set adressen herkennen, deels omdat sommige straatnamen hernoemd zullen zijn en deels omdat er nogal wat schrijfwijzen voorkomen. Een voorbeeld, de huidige Clarensteeg in Leiden op de Google Maps:

image

Op de kaart van Leiden uit 1897 is het de Klaresteeg.

image

Maar als ik de alle plaatsaanduidingen in de Leidse gegevensset bekijken dan kom ik op de volgende schrijfwijzen:

  • Claaresteeg
  • Claaresteegh
  • Clarasteeg
  • Clareasteegh
  • Clarensteeg
  • Claresteeg
  • Claresteegh
  • Klaaresteeg
  • Klarasteeg
  • Klarensteeg
  • Klarestaag
  • Klaresteeg
  • Klarsteeg
  • Klasesteeg om de hoek van de Coddesteeg

Er zal naast het 'zetten van punten' dus ook een 'herken de verschillende schrijfwijzen' functie moeten komen.

Straatnaam herkenning

Dit brengt mij ook bij de volgende uitdaging: herkennen van de straatnamen. Want in de genealogische dataset (gebaseerd op het Archive 2 All model) is er een plaatsaanduiding (Place) die een plaatsnaam kan bevatten, een plaatsnaam en straatnaam, straatnaam en huisnummer, en nog wat combinaties. Enkele voorbeelden (waarin de Clarensteeg voorkomt):

  • Klaresteeg, wijk 6 no.1026, Leyden
  • Klaresteeg, wijk 6, no 1035
  • Leiden, Klaresteeg wijk 6 no. 1029
  • Klaresteeg, kanton 2, wijk 6, no 1030
  • Klaresteeg, wijk 6 no. 1014, Leyden
  • Leiden Clarensteeg
  • Leiden, Clarensteeg
  • Clarensteeg wijk 6 nr 1026
  • Clarensteeg
  • Clarensteeg wijk 6 nr 1114

(uitgangspunt: een straatnaam is uniek in een plaats, kanton/wijk informatie hoeft niet gebruikt te worden)

Het herkennen van een straatnaam in de plaats indicatie is vooral een kwestie van een efficiënte oplossing vinden die niet te veel tijd in beslag neemt. Want stel, de akte komt uit Leiden, er zijn zo'n 300 straatnamen bekend met nog eens 3000 bekende alternatieve schrijfwijzen, dan betekent dit dus 3300 tests... Er is altijd nog de mogelijkheid om deze tests uit te voeren bij het importeren van de gegevensset en niet pas bij het opvragen van de akte (en dat elke keer weer), maar toch.

De oplossing

Leuke uitdagingen. Wellicht dat Erfgoed & Locatie hierin wat kan betekenen. Maar ik hoor ook graag van andere ontwikkelaars, geo-kenners, archivarissen en historici over de juiste aanpak bij het geocoden van historische straten!