maandag 4 januari 2016

Archieven: geef ons vaste URL’s, die werken!

Op 1 juli 2015 schreef ik het artikel Archieven: geef ons vaste URL’s!. Bij nader inzien, had ik de titel moet uitbreiden met "die werken", hieronder het waarom.

Handle systeem

Eén van de technologieën die ingezet kan worden om vaste URL's te implementeren is het Handle systeem:
The Handle System is a technology specification for assigning, managing, and resolving persistent identifiers for digital objects and other resources on the Internet.
In simpele termen: je registreert het adres van een digitaal object bij het Handle systeem, dit resulteert in een uniek adres dat via handle.net beschikbaar wordt gesteld en dat doorverwijst naar het geregistreerde adres. Wanneer nu het digitale object verhuist (nieuwe domeinnaam, nieuwe website technologie, enz.) dan kun je het nieuwe adres doorgeven aan het Handle systeem. Het handle.net adres (de persistent identifier) blijft ongewijzigd, maar verwijst door naar het vernieuwde adres. Zo lang je - als gebruiker - de handle.net adressen gebruikt èn de organisatie zorgt dat de verwijzingen blijven kloppen, heb je vaste URL's, die werken.

Vind de vaste URL's

Het Nationaal Archief biedt al heel wat open data aan, waaronder nadere toegangen met historische persoonsgegevens. Interessant materiaal dus om op te nemen op Open Archieven! In Archieven: geef ons vaste URL’s! noemde ik GaHetNa, de website van het Nationaal Archief, als voorbeeld van een website die vaste URL's biedt. Elk pagina behorend bij een record (als rij in een database tabel) in de nadere toegang toont ook weer de vaste URL (zie voorbeeld):


PS 1. Waarom wordt de vaste URL in een te klein invoerveld getoond?

PS 2. Waarom gebruikt het Nationaal Archief proxy.handle.net en de rest van de wereld (de canonical name) hdl.handle.net?

PS 3. Als hdl.handle.net als domeinnaam wordt gebruikt dan kan er ook https gebruikt worden (https://hdl.handle.net/), wat de betrouwbaarheid verhoogd! Alleen jammer dat gahetna.nl nog geen https is...


Je zou verwachten dat de open nadere toegangen, die beschikbaar wordt gesteld in CSV bestanden (en beschrijvende XML bestanden), ook de vaste URL's bevatten. Helaas, niet helemaal...

Bij records waar ook een afbeelding (scan of foto) beschikbaar is, wordt er in het CSV bestand wel een vaste URL opgenomen naar de afbeelding, niet naar het record. Het aparte is trouwens dat op pagina's op GaHetNa waar een afbeelding wordt getoond geen vaste URL wordt getoond (vergelijk pagina zonder afbeelding en pagina met afbeelding).

Elk record in het CSV bevat altijd wel een UUID. Door deze UUID achter het adres http://proxy.handle.net/10648/ (of beter: https://hdl.handle.net/10648/) te plakken blijk je de vaste URL te krijgen (is helaas ongedocumenteerd).

Bij het inlezen van de open data van het Nationaal Archief op Open Archieven besloot ik om voor de links terug naar GaHetNa de vaste URL's te gebruiken. Dus op bijv. de registratie van gevangene Arnoldus Hermanus Pastoor (met foto!) een link naar http://proxy.handle.net/10648/bc95b636-a2cc-102e-9b80-0050569c51dd in plaats van http://www.gahetna.nl/collectie/index/nt00422/bc95b636-a2cc-102e-9b80-0050569c51dd. Althans dat was het idee...

Vind de niet-werkende vast URL's

Bij het verwerken van de open data viel het mij op dat sommige vaste URL's niet naar de gewenste pagina's leiden! De verwijzing leidt hierbij niet naar een herkenbare "404 Page not found" maar naar de index van alle indexen. Analyse van 47 nadere toegangen met 632.315 (afgeleide) vaste URL's leerde dat 167.942 (27%) vaste URL's niet naar de juiste URL doorverwijzen. Hieronder een weergave per nadere toegang.


Correctie niet-werkende vaste URL's

Alle niet-werkende vaste URL's hebben last van hetzelfde probleem. Een voorbeeld: de vaste URL
http://proxy.handle.net/10648/964aeb04-ff17-102c-aa81-005056a23d00 leidt de gebruiker naar http://www.gahetna.nl/collectie/index#/nt00212/964aeb04-ff17-102c-aa81-005056a23d00 in plaats van http://www.gahetna.nl/collectie/index/nt00212/964aeb04-ff17-102c-aa81-005056a23d00 (voor diegenen die het verschil niet zien, hieronder een hint).

Westerdam. Publiek wacht voor hek (18 juli 1947), door D. Moedrik / Anefo, CC-BY licentie Nationaal Archief

Dit euvel is vrij eenvoudig op te lossen. Het Nationaal Archief dient van alle niet-werkende vaste URL's (download overzicht) bij het Handle systeem het correcte adres van het digitale object door te geven. Maar ook adviseer ik hen (en andere organisaties die met vaste URL's werken of gaan werken) om een controle proces rondom vaste URL's in te richten. Dan hebben we vaste URL's, die blijven werken!

PS 4. weer een mooi voorbeeld dat laat zien dat open data kan leiden tot kwaliteitsverbetering!

maandag 7 december 2015

Alternatieven voor toegankelijk maken van beeldmateriaal

De traditionele wijze van het toegankelijk maken van beeldmateriaal is het door mensen laten beschrijven van de beelden. Dit is een arbeidsintensieve klus, zou het niet anders kunnen? In dit artikel beschrijf ik twee alternatieve werkwijzen om beeldmateriaal toegankelijk te krijgen.

Het beschrijven van een foto vergt tijd en kennis, het is werk dat is weggelegd voor specialisten in combinatie van lokale kennisdragers. Het bereiken van een grotere groep mensen die kunnen helpen kan bijvoorbeeld via Flickr of Wikipedia. Bij Flickr The Commons kunnen organisaties foto’s plaatsen en kunnen gebruikers van Flickr daar commentaar bij zetten (maar het systeem heeft natuurlijk een andere focus). Wikipedia gebruikt rechtenvrije foto’s die beschikbaar zijn op WikiMedia. Doordat afbeeldingen gebruikt worden in artikelen kom je via een omweg tot een beschrijving van foto’s. Nadeel van deze werkwijze is dat de set foto’s waarschijnlijk niet gestructureerd en eenduidig worden beschreven. Ook zit er nog “handwerk” in het vergaren van de beschrijvingen in het eigen collectiebeheersysteem.

Metadata Games

Een eerste alternatief dat ik wil belichten is het open source crowdsourcing game platform Metadata Games. Dit platform biedt diverse spelvormen aan, voor web en mobiel, die vooral zijn gericht op het beschrijven van afbeeldingen, video en audio.

Eén van de spellen is “Guess What!”. In dit spel zijn er twee spelers. Speler 1 ziet een afbeelding en geeft hier een korte beschrijving van. Speler 2 ziet 9 afbeeldingen en moet afgaande op de beschrijving de juiste foto kiezen. Nadat de foto is geraden draaien de rollen om.

Deze gamification is een leuke laagdrempelige manier om een set foto’s te laten beschrijven. Hierbij biet het platform ook een "beheerachterkant" die het uploaden van fotosets en het exporteren van de resultaten mogelijk maakt.

Machine learning en neuraal netwerken

Een tweede alternatief verminderd de input van de mens in grote mate: het laat de computer de foto’s beschrijven! Dit is geen toekomstmuziek. Gebruikers van Google Photo kunnen in hun eigen collectie (die veelal geen beschrijving hebben behalve wat EXIF data die wellicht datum/tijd/breedtegraad/lengtegraad bevatten) eenvoudig zoeken naar “strandfoto’s met het gezin”, het zoekresultaat is veelal goed te noemen. We komen hiermee op het terrein van machine learning en neurale netwerken.

Deze technologie ontwikkelt zich snel. Even zelf een neuraal netwerk trainen voor het beschrijven van een foto collectie behoort – met enige technische kennis - dan ook tot de mogelijkheden. Een kleine proof-of-concept, op basis van een fotoset van het Regionaal Archief Tilburg (beschikbaar gesteld onder een Creative Commons BY-NC-SA licentie), een open-source neuraal netwerk en een Engelstalige basis trainingsset, leert dat dit alternatief het onderzoeken waard is.


a couple of horses standing next to each other

Via http://lab.coret.org/neural/ kun je het resultaat zien. Sommige beschrijvingen zijn best aardig. Besef je dat een computer deze beschrijvingen heeft samengesteld!

De beschrijvingen zitten er ook nog wel eens naast: een strand wordt aangezien voor sneeuw, mannen en vrouwen worden niet echt onderscheiden, er worden ten onrechte frisbees en kloktorens genoemd en er worden er moderne voorwerpen als mobiele telefoon en laptop herkend in de historische foto’s.

Maar bij de soms wat hilarische teksten moet je je bedenken dat het neurale netwerk gebruikt maakt van bepaalde “kennis”, een set van beschreven foto’s die als input heeft gediend. Ik ben benieuwd wat de kwaliteit zal zijn als er een Nederlandstalige historische fotoset met beschrijvingen als trainingsset wordt gebruikt!


Toegankelijker door steekwoorden

Via beide bovenbeschreven alternatieven zal sommige informatie niet boven water komen, denk aan de datum en namen van personen, gebouwen, voertuigen en plaatsen. Wellicht moeten de alternatieven dan ook vooral ingezet worden om de foto’s te voorzien van steekwoorden (tags). Met deze steekwoorden worden beeldcollecties, die beschrijving en steekwoorden ontberen, al een stuk toegankelijker.

Nu nog een innovatieve opdracht- of werkgever vinden waar ik bovenstaande alternatieven verder kan uitwerken...

dinsdag 18 augustus 2015

RHC's letten onvoldoende op privacy van hun website bezoekers

Bij de workshop Gebruik Google Analytics komen vragen aan bod als "wat willen we meten?" en "wat kunnen we met al die cijfers?", maar ook "hoe zit het met privacy?" en "hoe zit het met de cookie wet?". Een digitale rondgang langs de websites van de 12 voormalige Rijksarchieven, nu Regionale Historische Centra (RHC's), leert dat ze allemaal gebruik maken van Google Analytics om websitestatistieken te verzamelen. Maar hebben zij Google Analytics zo geïmplementeerd dat de privacy van bezoekers niet geschaad wordt?


Anonimiseren van het IP adres

Als een bezoeker een webpagina (of Javascript bestand, afbeelding, ...) opvraagt dan krijgt de website de beschikking over het IP-adres van (de computer/het netwerk van) de bezoeker. Een IP-adres kan herleidbaar zijn tot een persoon en is daarmee een persoonsgegeven, de Wet Bescherming Persoonsgegevens (WBP) is dus van toepassing. Google Analytics biedt de mogelijkheid om het IP-adres van de websitebezoeker te 'anonimiseren', door een deel van het IP adres (het laatste octet) niet te verwerken. Sommige rapportage functionaliteit van Google Analytics wordt hierdoor beperkt, maar het komt de privacy van de website bezoekers ten goede.

Onderstaande tabel laat zien dat maar 4 van de 12 RHC's deze privacy maatregel hebben geïmplementeerd.

Ja Brabants Historische Informatie Centrum, Groninger Archieven, Historisch Centrum Overijssel, Nationaal Archief (GaHetNa)
NeeDrents Archief, Gelders Archief, Het Utrechts Archief, Nieuw Land Erfgoedcentrum, Noord-Hollands Archief, Tresoar, Regionaal Historisch Centrum Limburg, Zeeuws Archief
Tabel 1: wordt het IP adres geanonimiseerd?
Let op: Het College bescherming persoonsgegevens (CBP) acht het resterende deel van het IP-adres nog steeds een persoonsgegeven. Desalniettemin wordt het 'anonimiseren' door het CPB voorgeschreven.

Netwerkverkeer versleutelen

Internetverkeer dat niet wordt versleuteld kan worden afgeluisterd en worden gemanipuleerd. Versleuteling van internetverkeer via HTTPS komt de privacy ten goede. Als een website Google Analytics gebruikt is er verkeer tussen de browser van de bezoeker en Google. Bij een website die HTTPS gebruikt wordt het verkeer naar Google Analytics automatisch ook over HTTPS geleid. Als een website echter HTTP gebruikt, dus niet versleuteld is, kun je Google Analytics opdracht geven om over HTTPS te communiceren zodat dat deel van het netwerkverkeer alsnog versleuteld is.

Onderstaande tabel toont aan dat maar één RHC de eigen website geheel via HTTPS aanbiedt, de andere RHC's bieden hun website alleen onversleuteld via HTTP aan. Van deze laatste groep zorgen 2 RHC's ervoor dat verkeer naar Google Analytics vanaf hun HTTP website alsnog wordt versleuteld. Bij de overige 9 RHC's wordt het verkeer naar Google Analytics niet versleuteld.

Ja Historisch Centrum Overijssel (gehele website via HTTPS),
Brabants Historische Informatie Centrum, Groninger Archieven
NeeDrents Archief, Gelders Archief, Het Utrechts Archief, Nationaal Archief (GaHetNa), Nieuw Land Erfgoedcentrum, Noord-Hollands Archief, Tresoar, Regionaal Historisch Centrum Limburg, Zeeuws Archief
Tabel 2: is het netwerkverkeer naar Google Analytics versleuteld?
Zie ook: Onderzoek: Geen veilig versleuteld webverkeer mogelijk met meeste websites van archieforganisaties

Informeren over gebruik

Google Analytics gebruikt voor het volgen van bezoekers cookies. Op 3 februari 2015 is de Telecommunicatiewet (in de volksmond ook wel cookie-wet genoemd) aangenomen door de Eerste Kamer. De belangrijkste wijziging die in de wet is doorgevoerd nadat de wet in 2013 door de Tweede Kamer werd aangenomen is dat het plaatsen van cookies om een website te verbeteren nu wel toegestaan worden, zonder dat een expliciete melding en/of toestemming nodig is bij binnenkomst op de website. Gelukkig valt ook Google Analytics onder deze uitzondering! Een website hoeft dus niet vooraf expliciet om toestemming te vragen voor de cookies van Google Analytics mits de privacy maatregelen zijn geïmplementeerd. Het is echter nog wel verplicht om de bezoekers te informeren over het gebruik van Google Analytics in bijvoorbeeld een separate cookie pagina of disclaimer pagina.

Van de 12 RHC's maken maar 2 RHC's melding van het gebruik van Google Analytics.

Ja Brabants Historische Informatie Centrum, Gelders Archief
NeeDrents Archief, Groninger Archieven, Het Utrechts Archief, Historisch Centrum Overijssel, Nationaal Archief (GaHetNa), Nieuw Land Erfgoedcentrum, Noord-Hollands Archief, Regionaal Historisch Centrum Limburg, Tresoar, Zeeuws Archief
Tabel 3: wordt de bezoeker geïnformeerd over gebruik Google Analytics?

Let op: als er geen privacy maatregelen genomen worden, worden de Google Analytics cookies als tracking cookies gezien waar de bezoeker vooraf toestemming voor dient te geven. De Autoriteit Consument & Markt (ACM) handhaaft de cookie-wet en kan boetes tot maximaal EUR 450.000,- uitdelen.

Bewerkersovereenkomst met Google afsluiten

Omdat het gedrag van bezoekers wordt vastgelegd, tezamen met een IP adres, worden er persoonsgegevens verwerkt. Bij gebruik van Google Analytics wordt de verwerking door de website eigenaar uitbesteed aan een derde partij zijnde Google. Dit betekent dat er conform de WBP een bewerkersovereenkomst tussen website eigenaar en Google afgesloten moet worden!
In een bewerkersovereenkomst worden de afspraken vastgelegd die de verantwoordelijke (=website eigenaar) met de bewerker (= Google) maakt over de bescherming en de beveiliging van persoonsgegevens. Dit klikt lastiger dan het is, Google voorziet in de mogelijkheid om deze overeenkomst af te sluiten door het zetten van een enkel vinkje. Als bezoeker kun je niet controleren of er een bewerkersovereenkomst is, een website eigenaar moet dit echter wel kunnen aantonen aan bijvoorbeeld het CBP. Melding maken van de afgesloten bewerkersovereenkomst bij de paragraaf over het gebruik van Google Analytics wordt aangeraden, zie als voorbeeld de disclaimer van Open Archieven.

Van de 2 RHC's die melding maken van het gebruik van Google Analytics maakt er geen één melding van een bewerkersovereenkomst. Waarschijnlijk hebben dus ook geen van de RHC's de wettelijk verplichte  bewerkersovereenkomst met Google afgesloten.

Ja-
NeeBrabants Historische Informatie Centrum, Drents Archief, Gelders Archief, Groninger Archieven, Het Utrechts Archief, Historisch Centrum Overijssel, Nationaal Archief (GaHetNa), Nieuw Land Erfgoedcentrum, Noord-Hollands Archief, Regionaal Historisch Centrum Limburg, Tresoar, Zeeuws Archief
Tabel 4: wordt de bezoeker geïnformeerd over de bewerkersovereenkomst?

Delen van gegevens verhinderen

Het verzamelen van (persoons)gegevens voor een bepaald doel mag, zo ook de webstatistieken via Google Analytics. Echter de gegevens mogen niet gedeeld worden en dus voor een ander doel gebruikt worden. Standaard doet Google Analytics dit, maar ook dit is eenvoudig aan te passen. Deze verplichte privacy maatregel kun je als bezoeker, net als bij de bewerkersovereenkomst, niet controleren. Een website-eigenaar kan er wel melding van maken op de cookie of disclaimer pagina, dit zorgt voor transparantie.

Geen van de RHC's maakt melding van het feit dat ze Google hebben opgedragen geen gegevens te delen. Waarschijnlijk heeft dan ook geen van de RHC's deze privacy maatregel getroffen.

Ja-
NeeBrabants Historische Informatie Centrum, Drents Archief, Gelders Archief, Groninger Archieven, Het Utrechts Archief, Historisch Centrum Overijssel, Nationaal Archief (GaHetNa), Nieuw Land Erfgoedcentrum, Noord-Hollands Archief, Regionaal Historisch Centrum Limburg, Tresoar, Zeeuws Archief
Tabel 5: wordt er gemeld dat is ingesteld dat Google de (persoons)gegevens niet deelt?

Conclusie: RHC's letten onvoldoende op privacy van hun website bezoekers

Geen van de 12 RHC websites voldoet volledig aan privacy eisen die door het CBP gesteld worden aan het gebruik van Google Analytics. De RHC's gaan dus niet goed om met de privacy van hun websitebezoekers!

De websites van de RHC's vormen een 'steekproef' van de websites in de hele archiefsector. Omdat het geen aselecte steekproef is kan de conclusie niet zo maar doorgetrokken worden naar de gehele archiefsector. Maar het onderbuik gevoel zegt dat de implementatie van Google Analytics op de meeste websites van archiefinstellingen niet voldoet aan de Nederlandse wetgeving. Een risico voor archiefinstellingen (qua boetes en imago) en hun website bezoekers (qua privacyschending).


Wilt u meer informatie over de workshop Gebruik Google Analytics of implementatie-check en -ondersteuning neem dan contact op met Bob Coret.

zondag 8 maart 2015

Hoe het CBG gegevensverlies veroorzaakt

Tijdens het schrijven van het artikel Het gezwalk van WieWasWie werkte de “verbeterde GEDCOM export” niet. Een nieuwe poging vandaag geeft geen foutmelding maar een bestand dat gedownload wordt. Tijd om naar de “verbeterde GEDCOM export” te kijken!

Er is geen overzicht van aangebrachte verbeteringen in de GEDCOM export. Dus enerzijds zal ik de GEDCOM vergelijken met een GEDCOM zoals Tamura Jones deze in zijn review van 10-02-2013 heeft opgenomen in WieWasWie GEDCOM, anderzijds zal ik de GEDCOM tegen de GEDCOM specificatie houden.

Geen GEDCOM!

Wat allereerst opvalt is dat het “verbeterde GEDCOM bestand” nog steeds geen header bevat, dit is verplicht volgens de GEDCOM specificatie, en dus is het bestand geen geldig GEDCOM bestand. Een programma die dit bestand probeert in te lezen weet bijvoorbeeld niet welke versie GEDCOM dit is en welke character encoding wordt gebruikt. Dit vergroot dus de kans dat de import faalt.

Betere datums

Waar in het oude bestand datums in de vorm dd-mm-yyyy werden genoteerd wordt er nu het juiste GEDCOM formaat gebruikt.

Compleetheid bestand

Ik heb een kleine stamboom gemaakt waarbij ik alle velden heb ingevuld om te kijken of alle gegevens in het export bestand terecht komen. Het scheelt dat je in de stamboombouwfunctionaliteit van WieWasWie niet veel kan invullen, dus wat er ingaat komt er bijna ook allemaal weer uit, met één uitzondering: de afbeeldingen.

GEDCOM staat op zich toe dat er binaire objecten in worden opgenomen, dit is echter niet gangbaar. Wat wel gangbaar is, is dat het GEDCOM bestand referenties bevat naar de bestanden. De WieWasWie gebruiker heeft geen mogelijkheid om de foto’s te downloaden en er zijn dus geen referenties naar foto’s. Deze informatie gaat dus verloren.

What’s in a NAME?

Niet alle informatie van de naam komt helaas om de juiste plek. Zo wordt de naam Alida Helena (Alie) van Buuren als volgt “vertaald”:

1 NAME Alida Helena/Buuren/
2 NICK Alie
2 SPFX van


De waarde bij NAME is incorrect, deze dient compleet te zijn, het tussenvoegsel moet er dus ook in zitten. Het is nu sterk afhankelijk van de GEDCOM import van het programma waar de gegevens in worden gelezen.

Laten we eens kijken hoe bovenstaande persoon in het door WieWasWie aanbevolen StamboomNederland terecht komt:
image

Zoals ik al had verwacht komt het tussenvoegsel niet goed over in StamboomNederland, maar ook de roepnaam blijkt verloren te zijn gegaan. Je zou toch denken dat het CBG dit zou hebben getest, te meer daar zij, als eigenaar van StamboomNederland en exploitatiepartij van WieWasWie, de overstap van WieWasWie naar StamboomNederland promoten.

Bronvermeldingen

Een mogelijk sterk punt van de stamboombouwfunctionaliteit van WieWasWie was het feit dat bronnen gekoppeld worden aan personen in de stamboom. Ik zeg mogelijk, omdat de implementatie van deze functionaliteit op WieWasWie zich beperkte tot het koppelen van een document aan een persoon. Het koppelen van de geboorteakte aan de geboorte, of de huwelijksakte aan het huwelijk was niet mogelijk. Met interesse keek ik dus ook uit naar hoe de bronnen in het export bestand terecht zouden komen.

0 @I2@ INDI
1 NAME Catharina/Brizée/
1 SEX F
1 SOUR f2729761-670e-4e92-82d4-23932372dad3
1 SOUR
https://www.wiewaswie.nl/personen-zoeken/zoeken/document/srcid/1872790

Bovenstaand stukje is valide volgens de GEDCOM specificatie, tenminste als het hier daadwerkelijk om 2 bronvermeldingen gaat. Wat de eerste “SOUR” (=source/bron) is weet ik niet, één of ander intern technisch nummer waar ik niets mee kan.

De tweede “SOUR” linkt naar de meta-data van de overlijdensakte uit de Burgerlijke Stand op WieWasWie. Het opnemen van de URL is echt de meest minimale bronvermelding die je kunt bieden, waarbij deze ook niet echt toekomst vast is (het is geen persistente URL) en eigenlijk ook onjuist is. Immers, de originele bron van het overlijden is een BS Overlijden akte uit 1812 uit Amersfoort (SOUR) die zich bevindt bij Archief Eemland in Amersfoort (REPO). De digitale afbeelding hiervan is slechts een afgeleide, welke uiteraard wel bij de SOUR opgenomen kan worden (in FILE of NOTE).

Juist op het punt van bronvermeldingen had ik verwacht dat het Centraal Bureau van Genealogie het goede voorbeeld zou geven, wellicht aangevuld met de kennis en kunde van de deelnemende archieven in WieWasWie die ook graag bronvermeldingen zien. Helaas, weer te optimistisch gedacht.

Voor gebruikers die overstappen naar StamboomNederland is de minimale bronvermelding niet zo erg. Immers, StamboomNederland kan helemaal niet omgaan met bronnen uit GEDCOM bestanden. StamboomNederland neemt het GEDCOM en noemt dat de bron. Erg kwalijk!
image


Conclusie

Het bestand dat via de exportfunctie van de stamboombouwfunctionaliteit kan worden gedownload voldoet niet aan de GEDCOM specificatie (welke dan ook…) en mag dus geen GEDCOM bestand heten. Noem je het wel een GEDCOM bestand dan werk je moedwillig mee aan de onterecht negatieve beeldvorming van GEDCOM en bewijs je je gebruikers een slechte dienst.

In plaats van een handleiding hoe deze bestanden in StamboomNederland zijn te importeren zou het het CBG sieren om stamboomonderzoekers te waarschuwen voor mogelijk gegevensverlies door hun ondermaatse GEDCOM export (WieWasWie) en ondermaatse GEDCOM import (StamboomNederland).

dinsdag 10 februari 2015

Een stukje geschiedenis van het A2A model

Eén van de resultaten van het WieWasWie project die ik graag promoot is het A2A datamodel. Het A2A datamodel is een generiek meta data formaat dat gebruikt wordt voor de uitwisseling en ontsluiting van verschillende bronnen met historische persoonsgegevens.

Archieven kunnen hun archiefgegevens (de indexen/nadere toegangen) beschikbaar stellen voor harvesting in het A2A model. Op deze wijze stellen sommige archieven hun data (alleen) beschikbaar aan WieWasWie. Sommige archieven die open data bieden, zoals Erfgoed Leiden, Regionaal Archief Tilburg en gemeentearchieven Schouwen-Duiveland, bieden de door ontwikkelaars vrij te hergebruiken data ook via het A2A model aan. Om deze reden noem ik het ook het "Archive 2 All" model. Deze open standaard (zie http://www.den.nl/standaard/386/) is dus belangrijk voor de archiefsector, hetgeen door de overdracht een extra verantwoordelijkheid van het Centraal Bureau voor Genealogie is geworden.

Eén van de personen die betrokken was bij de totstandkoming van het A2A model was Maurits Meijer. Maurits werkte bij Mindbus (de partij die het WieWasWie platform heeft ontwikkeld en beheerd) en is onder andere de beheerder geweest van het door Mindbus ontwikkelde systeem Digitale Stamboom (eigendom van Erfgoed Delft). Zijn bachelor scriptie aan de universiteit van Leiden was getiteld "Uitwisselingssysteem historische persoonsgegevens" en ging over het ontwerp en de bouw van een uitwisselingssysteem voor historische persoonsgegevens. Zijn scriptie vormt een deel van de geschiedenis van het A2A model en heb ik daarom hieronder (met toestemming) gepubliceerd.

Uw browser kan geen PDF bestanden weergeven! Download het PDF bestand Uitwisselingssysteem historische persoonsgerelateerde data en open het in uw PDF reader.

Uitwisselingssysteem historische persoonsgegevens, Maurits Meijer, 1 mei 2012.

donderdag 11 december 2014

Google op de juiste wijze souffleren

Websites als Genealogie Online krijgen veel verkeer via Google (de 67,8% in onderstaande taartdiagram staat voor 427K sessie in de afgelopen maand).

imageDit gebeurt niet allemaal vanzelf, je kunt hier zelf heel wat invloed op hebben. Zo heeft biedt Genealogie Online meerdere sitemaps aan Google, waaronder één van bijna 25M items! Hierdoor haalt de Googlebot zo’n 1,4M pagina per dag op:

image

Ook bevatten veel van de Coret Genealogie pagina’s microdata zoals gedefinieerd door schema.org, waardoor Google ook beter de inhoud begrijpt. Zo weet Google dat er op Genealogie Online heel wat Persons zijn te vinden, op het Stamboom Forum genealogische Events en in de Stamboom Gids Reviews van genealogische websites.

Je kunt Google ook vertellen hoe de zoekmachine van je website werkt. Dit is handig om de statistieken in Google Analytics te krijgen over interne zoekopdrachten, maar Google gebruikt het ook in de zoekmachine. Zoek je op Google bijvoorbeeld op “genealogieonline” dan krijg je naast de beschrijving en belangrijke pagina’s ook een zoekvak. Als je in dit zoekvak een zoekterm intypt en op de zoekknop klikt wordt direct de zoekfunctie van Genealogie Online aangeroepen.

image

imageAls je als website niet aan Google uitlegt hoe je zoekfunctie werkt kun je alsnog zo’n zoekvak zien, maar die leidt dan tot een zoekactie binnen alle door Google geïndexeerde pagina van je website (dus “site:www.mijnwebsite.nl zoekterm”).

Nieuw is dat Google Search in de resultaten op smartphones nu ook aangeeft dat de website “voor mobiel” geschikt is. Zo ver ik weet heb ik dit Google niet expliciet verteld, dus de Googlebot heeft ook naar de CSS van mijn websites gekeken en (goed) geconcludeerd dat door de responsive design van de website het ook goed op een mobiel te bekijken is.

donderdag 25 september 2014

#opendata verrijken met #opendata

De gemeente Enschede heeft een eigen Open Data portal waar ze diverse open data sets ten toon en beschikbaar stellen. Naar aanleiding van een WOB verzoek mijnerzijds hebben zij ook datasets van het Stadsarchief Enschede toegevoegd. De historische gegevens van de Burgerlijke Stand van Lonneker en Enschede zijn nu ook beschikbaar voor hergebruik.

De dataset is opgedeeld in 6 delen:

  • Geboorteakten Enschede (1811-1910)
  • Geboorteakten Lonneker (1811-1910)
  • Huwelijksakten Enschede (1811-1935)
  • Huwelijksakten Lonneker (1811-1934)
  • Overlijdensakten Enschede (1811-1960)
  • Overlijdensakten Lonneker (1811-1934)

Het verwerken van de geboorte- en overlijdensakten – beschikbaar gesteld in HTML, JSON, XML, CSV, TSV, TAG, maar niet A2A – voor opname in Open Archieven ging redelijk voorspoedig.

De datasets bevatten helaas niet alle meta-data van de akten. Zo ontbreken het opmerkingen veld èn is er geen link naar een thumbnail of viewer van de scan van de akte. Met wat kunst- en vliegwerk kan er wel een link worden gelegd naar de akte op de website van het Stadsarchief Enschede (behalve bij de geboorteakten van Enschede lukt dit nog niet).

Ambigue data

Bij de huwelijksakten liep ik tegen een probleem aan. Men heeft er voor gekozen om de ouders van de bruid en bruidegom met de rol ‘Vader’ en ‘Moeder’ aan te duiden. Zie hieronder een voorbeeld van deze data:

image

Voor de presentatie en de slimme zoekfunctionaliteit op Open Archieven en ook voor de OAI-PMH data provider (waarmee alle open data voor harvesting beschikbaar is volgens A2A model) is het van belang te weten wie de ouders van wie zijn.

image
De uitdaging was dus om de juiste vader en moeder bij bruid en bruidegom te krijgen. Eén deel is makkelijk, daar de familienaam van de vader in deze tijd (1811-1935) werd doorgegeven aan het kind. Het probleem was hiermee gehalveerd, nu alleen nog de juiste moeders bij bruid en bruidegom krijgen!

Om dit te bereiken worden de geboorte- en overlijdensakten gebruikt. Deze akten bevatten immers ook relatiegegevens (kind-vader-moeder en overledene-vader-moeder). Door nu binnen deze geboorte- en overlijdensakten (fonetisch) te zoeken naar bruidegom+vader van de bruidegom+moeder 1 of moeder 2 en bruid+vader van de bruid+moeder 1 of moeder 2 valt de juiste combinatie te achterhalen. Overigens hoeven in veel gevallen niet alle combinaties getest te worden.

image

Het is geen perfecte oplossing. Immers bruid of bruidegom kan geboren zijn voor 1811 of na 1910, zijn overleden voor 1811 of na 1960, maar nog waarschijnlijker ze zijn geboren of overleden buiten Lonneker en Enschede, in al deze gevallen zullen er dus geen geboorte- of overlijdensakten gevonden worden voor het ‘afleiden van ouderschap’. Onderstaande tabel toont de resultaten van deze “verrijkingsaanpak”:

Huwelijksakten Ouderparen gevonden Ouderparen niet gevonden
Enschede 10.879 (61%) 7.042 (39%)
Lonneker 8.258 (77%) 2.502 (23%)
Totaal 19.137 (67%) 9.544 (33%)

Dat 2 op de 3 huwelijksakten “verrijkt” kon worden met behulp van (als open data beschikbaar gestelde) geboorte- en huwelijksakten is toch leuk!
 
image