Linkrot kun je niet verbloemen

Open Archieven controleert steekproefsgewijs of de akten zoals deze op Open Archieven getoond worden nog bestaan bij de bron, de website van de archiefinstelling. Het idee is simpel: vraag de akte op bij het archief (technisch: een HEAD request) en controleer de HTTP response code: HTTP 200 staat voor OK, HTTP 404 staat voor niet gevonden, HTTP 410 staat voor was er ooit maar nu niet meer.

In de HTTP/1.1 specificatie (RFC 2616) die een belangrijke basis voor internet vormt, staan deze codes beschreven. Waaronder de 1XX reeks voor informatie, 2xx reeks voor succes, 3xx voor verwijzingen, 4xx voor fouten door client en 5xx voor fouten op de server. Deze HTTP codes zijn niet alleen van belang voor de vragende software (browser, script, Google spider, …) maar ook voor de eindgebruiker, die moet je uitleggen dat er iets fout is gegaan en wat er aan gedaan kan worden.

Hoe niet (meer) bestaande aktes worden weergegeven

Het probleem laat zich het beste uitleggen door middel van een voorbeeld.

Op Open Archieven komt de inschrijving van A. Wiggers in het bevolkingsregister van Breda voor (Gemeente Breda 1815-1925, Bron: boek, Deel: 1314, Periode: 1870-1879, Breda, inventaris- ­num­mer 1314, Bevolkingsregister Breda 1870-1879 deel 20, folio 57). Deze akte is via de OAI-PMH koppeling als onderdeel van de open data van het stadsarchief geharvest in 2014. In deze metadata van de akte komt ook een link voor naar de akte op de website van het stadsarchief en ook een link naar een scan van de akte (zie hiernaast).

Wanneer deze akte op de website van het archief wordt opgevraagd worden onderstaande zichtbaar in de browser:

Het gele kader is door mij toegevoegd. Dit gedeelte zie je terug op meer archiefwebsites (met dezelfde leverancier), zoals het Regionaal Archief Tilburg, Erfgoed Leiden, Regionaal Archief Alkmaar, Regionaal Archief Zutphen, West Brabants Archief. Een website bezoeker zal geen flauw benul hebben wat er aan de hand is… Dan doet het Waterlands Archief het nog het beste met tenminste de melding “geen resultaat gevonden”.

Mens en machine

De mens (de gebruik van de archiefwebsite) wordt dus niet echt goed voorgelicht als er een niet (meer) bestaande pagina wordt opgevraagd. Hopelijk worden de machines wel goed voorgelicht, zodat Open Archieven, Google, en andere kunnen bepalen dat bepaalde content niet meer bestaat. Helaas. Als je naar de HTTP-headers kijkt van alle hierboven genoemde links, via bijvoorbeeld de online tool http://testuri.org/sniffer, dan zie je in alle gevallen een HTTP 200 code, oftewel: “niets aan het handje hier heb je mooi content”. Dit is niet goed! De websites zouden in deze gevallen een HTTP 404 code moeten hebben opgeleverd (of beter: een HTTP 301 naar het nieuwe adres van de akte als die bekend is).

Door het nalaten van het geven van een duidelijke foutmelding voor de mens en het nalaten van een volgens standaard geven van de juiste HTTP code wordt er gedaan alsof er niets fout is, maar linkrot kun je niet verbloemen!

Waar is de verwijderde heen gegaan?

Dat akten worden verwijderd of op een andere wijze (lees: andere GUID) toegankelijk worden gemaakt, gebeurd, ik schreef hier in Met alleen PID’s los je linkrot niet op ook al over.

Als we naar het voorbeeld van de inschrijving van A. Wiggers, geboren in 1844, wonende te Breda in het bevolkingsregister kijken vinden we deze nu op de website van het Stadsarchief terug als Adriaan Wiggers, geboren op 01-08-1844 te Loon op Zand. Als je de bronvermeldingen en scan vergelijkt gaat het over dezelfde inschrijving. In de nieuwe versie ontbreekt dan weer wel het folio nummer. Maar dus het ergste: het GUID van deze akte is veranderd. Een redirect van de oude naar de nieuwe is er niet. En wanneer de je oude pagina opvraagt wordt je niets wijzer.

NB: het adres van de scan is niet veranderd! Dus wanneer bezoekers op Open Archieven de scan bekijken dan is deze gelukkig wel zichtbaar, ook al is de record bij de archiefinstelling verwijderd.

Harvesten en verwijderingen

Zoals gezegd is de data uit het voorbeeld open data die door het stadsarchief via onder andere OAI-PMH ter beschikking wordt gesteld. Het adres van de OAI-PMH request van dit specifieke voorbeeld is https://webservices.picturae.com/a2a/44fe3724-4282-11e6-8750-60f81db16928?verb=GetRecord&metadataPrefix=oai_a2a&identifier=21487916-86bc-f53b-9962-1f0fdf9ffe18 wat vandaag de volgende response geeft:

<OAI-PMH xmlns="http://www.openarchives.org/OAI/2.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd">
 <responseDate>2017-11-14T10:58:55Z</responseDate>
 <request>http://webservices-a2a.picturae.pro/44fe3724-4282-11e6-8750-60f81db16928/</request>
 <error code="badArgument">Error retrieving data (http://webservices.picturae.pro/genealogy/deed/21487916-86bc-f53b-9962-1f0fdf9ffe18?page=1&rows=1&apiKey=6dbd9b52-41db-11e6-a81b-00155d012a81&q=%2A%3A%2A&fq=%28deleted%3Atrue+OR+deleted%3Afalse%29) curl_error:</error>
</OAI-PMH>

<OAI-PMH xmlns="http://www.openarchives.org/OAI/2.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd">
 <responseDate>2017-11-14T13:52:12Z</responseDate>
 <request verb="GetRecord" metadataPrefix="oai_a2a" identifier="833EE389-8B07-4D83-8993-6FB691301EDA">http://api.openarch.nl/oai-pmh/</request>
 <GetRecord>
  <record>
   <header status="deleted">
    <identifier>rhe:833EE389-8B07-4D83-8993-6FB691301EDA</identifier>
    <datestamp>2017-10-29T21:17:18Z</datestamp>
    <setSpec>rhe</setSpec>
   </header>
  </record>
 </GetRecord>
</OAI-PMH>