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!

vrijdag 27 september 2013

Wijzigingsverzoek op A2A model

Open Archieven is een zoekmachine voor de genealogische gegevens van open archieven (=archieven die hun gegevens beschikbaar stellen voor hergebruik). Het maken van een dergelijke websites is leuk en nuttig.

Leuk, omdat innovatieve ideeën gerealiseerd kunnen worden, zoals de koppel-weergave bij huwelijken (zie afbeelding hieronder) en de verwijzing naar relevante gerelateerde akten en online grafzerken en stambomen.

image

Nuttig, omdat in dit proces ook fouten en omissies aan het licht komen. Enerzijds in de gegevens, deze worden teruggekoppeld aan het archief zodat de kwaliteit van de data verhoogd wordt. Anderzijds in de wijze waarop informatie beschikbaar wordt gesteld. Eén aspect hiervan wil ik in dit artikel toelichten.

Gescans akten vs. gescande registers

Erfgoed Leiden en omstreken (ELO) stelt hun genealogische gegevens beschikbaar via het OAI-PMH protocol. Binnen dit harvesting protocol wordt er gebruik gemaakt van het Archive 2 All (A2A) model. Dit A2A model beschrijft informatie in termen van personen, gebeurtenissen, bronnen, objecten en relaties hiertussen. Concreet kun je denken aan een huwelijksakte die de gegevens van het bruidspaar en hun ouders toont, de datum en plaats van het huwelijk en gegevens over de bron, waaronder of er een scan van de akte beschikbaar is.

Bij de open data van ELO zijn van de 4,1 persoonsvermeldingen zo'n 2 miljoen gekoppeld aan een scan. Is de rest van het materiaal dan niet gescand? Jawel! Echter die persoonsvermeldingen (of beter, de records/akten) zijn niet gekoppeld aan één akte maar aan een gescand register. Zo’n register kan de bezoeker digitaal doorbladeren om de betreffende akte te vinden.

In het A2A model (versie 1.7) kun je alleen aangeven dat er een gescande akte is of niet. Er kan niet worden aangegeven dat de akte zich bevind in een gescand register. En dat is jammer! Open Archieven heeft de informatie over de gescande registers nu op een andere wijze verkregen (helaas niet uit de EAD), maar ziet toch graag dat in een volgende versie van het A2A model er een mogelijkheid komt om aan te geven dat er een gescand register beschikbaar is waarin de akte gevonden kan worden. Voor de eindgebruiker is dit immers belangrijke informatie.

image

Ik stel voor om in de XSD het element A2A:Scan uit te breiden met het element A2A:ScanType van type A2A:token100 met mogelijk waarden "akte" en "register". Wanneer het scan type "register" is verwijzen de overige URI velden niet naar een "akte" maar heel "register". In de presentatie door de hergebruiker dient dit onderscheidt inzichtelijk gemaakt te worden. Ter inspiratie hieronder hoe Open Archieven een en ander toont aan haar gebruikers.

vrijdag 21 juni 2013

Hard- en software achter Coret Genealogie

Ik krijg geregeld de vraag naar het ‘server park’ waarop de services van Coret Genealogie, zoals Genealogie Online en het Stamboom Forum draaien. In juni 2009 schreef ik reeds twee artikels op Blog Coret over met name de software:

Tijd voor een vervolg, waar ook het ‘ijzer’ de revue passeert. Let op: alleen voor techies.

Hardware, dedicated

De eerste ‘server’ was een stevige thuis PC die via een consumenten Internet verbinding service leverde. Een dergelijk opstelling was genoeg om websites beschikbaar te maken.

Met de groei van services en gebruik hiervan schakelde ik over op virtual private servers. Naast de flexibiliteit kwam er door plaatsing in een commercieel datacentre ook verbeterde bandbreedte en IPv6 connectivity. Maar op een gegeven moment waren het er een stuk of 4 wat het beheer er niet makkelijker op maakte. Ook de beperktere I/O snelheid en opslag van VPS-en begon een bottleneck te worden.

De volgende stap was een stevige dedicated server in hetzelfde datacentre. Door nieuwe softwarecomponenten ontstond de behoefte om services te verdelen, wat een tweede dedicated server betekende. De specificaties zijn gekozen voor enerzijds webserver (veel opslag) en database/searchserver (veel geheugen). Een derde ‘server’ is puur voor de back-up faciliteit.

image

Software, open-source

Qua operatingsystem heb ik de voorkeur voor Linux Debian, dit is in de afgelopen 10 jaar niet veranderd. Een ontwikkel/testmachine op basis van Oracle VM VirtualBox met Debian image is ook in een handomdraai opgezet.

Qua software componenten vormen Perl en PHP ook al jaren de basis. De dynamische pagina’s die gegenereerd worden via PHP, achter de Apache webserver, worden ondersteund door Memcache. De statische content wordt geserveerd via Lighttpd.

Grootste wijzigingen de afgelopen tijd hebben zich op het vlak van databases en search enige voltrokken. Apache Solr is de full-text search server die tegenwoordig gebruikt wordt (dus niet meer Swish-e).

Lange tijd heeft MySQL dienst gedaan als database. Echter, door de overname van Oracle van MySQL wordt het open-source karakter aangetast, ook de doorontwikkeling lijkt te stagneren. Vandaar de overstap naar drop-in-replacement MariaDB, een open source fork van MySQL. Naast een relationele database is er ook de noSQL documenten database MongoDB in gebruik genomen, zodat er complexere map/reduce acties uitgevoerd kunnen worden op grote datasets.

Services

Tenslotte nog iets over de gebruikte services. In de 2 blog artikels werd er melding gemaakt van gebruik van Amazon S3 en Amazon Cloudfront (als content delivery network). Dit was een leuk experiment. Alhoewel de services van Coret Genealogie veel bezoekers hebben (ongeveer 300K unieke bezoekers en 7M paginaweergaven per maand) is het gebruik van dedicated servers in een datacentre qua kosten en performance (mits je slim gebruik maakt van caching en je bijv. Javascript & CSS bestanden minified) toch in het voordeel boven Amazon (of Google App Engine).

Andere (gratis) services, zoals Google Analytics, Google Feedburner en Scribd worden nog steeds naar tevredenheid gebruikt.

zondag 10 maart 2013

Capaciteit Genealogie Online testen met grote kwartieren

Een door Tamura Jones ontwikkelde testmethode maakt het mogelijk om met gestandardiseerde, gegenereerde “kwartierstaat” GEDCOM’s de capaciteit en kwaliteit van stamboomprogramma of –website te bepalen. Het beantwoord de vraag: wat is de grootste kwartierstaat die het stamboomprogramma of –website kan importeren, verwerken en weer exporteren?

Fan value

Tamura Jones heeft een eenvoudig programma genaamd GedFan: GEDCOM Fan Creator ontwikkeld dat correcte (qua syntax), minimale GEDCOM bestanden genereert die personen uit een kwartierstaat met het gespecificeerde aantal generaties beschrijft. Zo bestaat een GEDCOM bestand met fan value 4 dus uit 4 generaties, oftewel 15 personen: de kwartierdrager, de 2 ouders, de 4 grootouders en de 8 grootouders. Een GEDCOM met 16 generaties bevat 65.535 personen, enz.  De namen van de personen in deze bestanden bestaan uit de in het Engels uitgeschreven kwartierstaat nummer.

image

Deze bestanden dienen als import om een stamboomprogramma of –website te testen. Het grootste bestand dat goed wordt verwerkt bepaalt de maximale fan value van het stamboomprogramma of -website. Het zijn overigens geen ‘torture test’ GEDCOM’s, ook bevatten de bestanden enkel namen en relaties, geen gebeurtenissen, datum, plaatsen, media of notities.

In het artikel The Fan Value en GedFan worden testmethode en –programma nader beschreven. In het artikel Some GEDCOM Fan Values worden enkele resultaten van tests getoond, die variëren van 16- tot een fan value van 23.

Tamura Jones heeft tot nu toe stamboomprogramma’s onderworpen aan tests. Zelf heb ik WieWasWie wel eens onderworpen aan een test, de resultaten zijn verwerkt in het artikel De capaciteit van WieWasWie’s Stamboom bouwen.

Genealogie Online op de pijnbank

Omdat ik ook wel eens wil kijken wat de capaciteit is van Genealogie Online heb ik met GedFan 0.2 de test GEDCOM bestanden gegenereerd. Het grootste bestand dat ik tot nu toe heb verwerkt met Genealogie Online is het GEDCOM bestand die bestaat uit een complete kwartierstaat met 21 generaties, oftewel 2.097.151 personen. Dit bestand is 490.405 kB (oftewel 478 MB). Hieronder bespreek ik de verwerking van dit bestand als normale Genealogie Online gebruiker.

Een stamboomprogramma zal een bestand direct van de harddisk inlezen. Bij een website bestaat de eerste stap uit het transporteren van het GEDCOM naar de website.

image

Omdat de upload limiet van Genealogie Online op dit moment 100MB is heb ik het bestand eerst gecomprimeerd, een actie die ik gebruikers overigens ook aanraad. Het gecomprimeerde bestand van 38,2 MB werd in 0:01:04 ge-geupload naar Genealogie Online.

N.B. Het ‘FAN 22’ bestand is gecomprimeerd 76,8 MB, dus zou ge-upload kunnen worden. Het ‘FAN 23’ bestand is gecomprimeerd 154 MB, dus zou niet ge-upload kunnen worden.

Verwerking van het bestand door Genealogie Online

Waar een stamboomprogramma een GEDCOM bestand inleest zodat de gebruiker het daarna kan bewerken, rapporten kan maken en exporteren is het de functie van Genealogie Online om de gegevens te publiceren, te controleren en te matchen aan andere stambomen en online scans.

Na enige tijd kreeg ik een e-mail bericht van Genealogie Online dat het bestand geplaatst was en dus zonder blokkerende fouten is verwerkt.

image

Toen ik de publicatie controleerde zag ik echter geen data. Dit werd veroorzaakt door het privacy filter van Genealogie Online: als niet bepaald kan worden dat een persoon is overleden wordt er verondersteld dat de persoon leeft en dus de gegevens niet gepubliceerd mogen worden zonder toestemming (conform Wet Bescherming Persoonsgegevens). De door GedFan gegenereerde bestanden bevatten zoals eerder gezegd geen datums, dus van geen van de personen kon bepaald worden dat ze waren overleden, vandaar dat er geen persoonspagina’s waren gepubliceerd. Correct gedrag dus.

Binnen Genealogie Online kunnen gebruikers per persoon aangeven dat een persoon is overleden of dat de persoon toestemming heeft gegeven voor publicatie. In speciale gevallen (waarvan zeker is dat alle personen in het bestand zijn overleden) kan er bij een publicatie worden ingesteld dat er geen privacy filter wordt toegepast. Voor de publicatie met het FAN 21 bestand heb ik dit ingesteld, waarna het bestand nogmaals is verwerkt.

Het ‘FAN 21’ bestand is door Genealogie Online verwerkt in 5:37:41, overigens gewoon op de productiemachine, terwijl er ook andere stambomen werden geupdate. In deze tijd werd oa. het GEDCOM bestand ingelezen (duurde 1:28:45), werden (geaggreerde)  gegevens opgeslagen in MySQL en MongoDB en geïndexeerd in Solr en moesten er ruim 2 miljoen statische pagina's gecreëerd worden (duurde 3:11:33).

image

De resulterende publicatie is niet interessant omdat het geen ‘rijk’ GEDCOM bestand is, de kwaliteitscontroles leverde niets op (want geen datums), er kon niets gematched worden met andere stambomen of online scans (want geen datums en geen echte namen), er waren geen plaatsnamen, enz. Maar dit is ook niet het doel van de test. Er is een kwartierstaat van 21 generaties (ruim 20 miljoen personen) verwerkt door Genealogie Online die een werkende publicatie heeft opgeleverd!

Veel stamboomprogramma’s en –websites (waaronder WieWasWie) gaan vaak na het inlezen en ‘werken met’ deel de fout in, want de test vereist dat een GEDCOM export weer een valide GEDCOM oplevert. Genealogie Online is in wezen alleen een viewer, er worden geen gegevens bewerkt en er is dus ook geen GEDCOM export functie nodig. Er is wel een backup functionaliteit, deze download puur het (niet gecomprimeerde) geuploade bestand en dat werkt met het FAN 21 bestand.

Conclusie

Of ik nu mag zeggen dat de fan value van Genealogie Online ten hoogste 21 is weet ik niet. In de tests die Tamura beschrijft van stamboomprogramma’s is de tijd die de verwerking van het GEDCOM bestand in beslag neemt ook een factor. Als je ruim vijf en een half uur moet wachten totdat je GEDCOM is geïmporteerd in je stamboomprogramma dan kun je dat wel excessief noemen. Als Genealogie Online vijf en een half uur bezig is, is dit voor de gebruiker naar mijn mening geen ramp.

Ik ben grotendeels tevreden met de uitkomst van de test. Dit komt omdat het grootste ‘echte’ GEDCOM bestand dat thans is gepubliceerd bestaat uit 894.122 personen (Burgerlijke Stand van de Antwerpse Kempen), daarna komt een bestand met 378.439 personen (Genealogische data Golse Genen). Er is dus ruimte voor grotere bestanden! Maar dit soort miljoenen bestanden hebben zeker een impact op de live website (en dus andere gepubliceerde stambomen), tijdens de verwerking af en toe hoge load en geheugengebruik die bij het FAN 21 bestand piekte tot 10GB. Om deze reden heb ik dan ook het FAN 22 bestand nog niet durven testen.

Toen ik in 2011 dezelfde test heb uitgevoerd werd het FAN 21 bestand veel sneller verwerkt. Sindsdien zijn er echter diverse functionaliteiten toegevoegd aan Genealogie Online, deze hebben gezien de resultaten van deze test aardige impact. Dit soort capaciteitstest maakt inzichtelijk welke brokken functionaliteit ‘duur’ zijn en wellicht eens geoptimaliseerd moeten worden.