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!