vrijdag 1 april 2016

Eerste blik op #opendata portaal van @Picturae_NL

Ook Picturae heeft voor haar klanten een open data portaal gerealiseerd. Zij hebben voor de makkelijke weg gekozen en daar ben ik erg blij mee!

Het open data portaal is namelijk een implementatie van het open-source data portal platform CKAN. Deze software wordt ook gebruikt door bijvoorbeeld data.overheid.nl, rotterdamopendata.nl en data.amsterdam.nl.
CKAN is a powerful data management system that makes data accessible – by providing tools to streamline publishing, sharing, finding and using data. CKAN is aimed at data publishers (national and regional governments, companies and organizations) wanting to make their data open and available.
Het open data portaal kan doorzocht worden, datasets kunnen per organisatie of per tag of per formaat bekeken worden, Van elke dataset is er een beschrijving, een URL, een datum van aanmaken en laatste wijziging en natuurlijk de (open) licentie. Het enige wat ik qua inrichting nog mis zijn de contactpersonen (naam en e-mail adres) bij de archieven, zodat hergebruikers eenvoudig in contact kunnen treden wanneer ze vragen hebben of juist willen melden dat ze iets moois met de data hebben gedaan.

CKAN biedt naast een website ook een API. Dit laatste betekent dat ontwikkelaars niet de informatie van de website hoeven te scrapen maar dat de informatie eenvoudig opgevraagd kan worden en als JSON wordt geretourneerd. Het in elkaar zetten van een script die alle nieuwe en aangepaste bestanden download is dan ook zeer simpel (veel eenvoudiger dan bij het "open data portaal" van De Ree waar ik eerder een eerste blik en tweede blik op wierp).

Op het moment van schrijven worden er genealogische open datasets aangeboden van 6 organisaties:
Per organisatie wordt er voor elk registertype een bestand aangeboden. Dit zijn alle gecomprimeerde XML bestanden die voldoen aan het (open) A2A datamodel. De hierboven genoemde organisaties hebben allemaal voor CC0 als licentie gekozen, mooi!

Het downloaden van de 74 bestanden duurde nog geen 2 minuten! Na nog eens enkele minuten was 2,1GB aan bestanden lokaal gedecomprimeerd en was er 37GB aan open data (=machineleesbare data die voldoet aan open standaard en hergebruikt mag worden)! Deze genealogische datasets worden nu al door Open Archieven verwerkt zodat deze zijn doorzoekbaar op Open Archieven

Het open data portaal geeft overigens nog 6 "datasets" weer. Dit zijn adressen van de OAI-PMH data providers van de 6 organisaties waarmee dezelfde data kan worden geharvest. Waar downloadbare datasets - die op een frequente basis bijgewerkt worden door Picturae - een download van het type "alles in een keer" mogelijk maken, kun je via OAI-PMH ook alleen de records opvragen die sinds een bepaalde datum zijn gewijzigd. Voor wie deze OAI-PMH data providers wil bekijken: ze zijn opgenomen in de OAI-PMH Browser.

Ik hoop dat de andere Picturae klanten ook deze wijze van publiceren van open data gaan gebruiken!

dinsdag 15 maart 2016

Tweede blik op #opendata portaal van @geldersarchief / @deree_groningen

Downloaden

In Eerste blik op #opendata portaal van @geldersarchief / @deree_groningen beschreef ik de moeizame procedure om de bestanden te downloaden. Sinds gisteren is men er in Groningen achter dat de rate limit (hoe vaak je binnen een bepaald tijdsbestek mag downloaden) stond ingesteld op maximaal 100 bestanden per uur. Dit is gelukkig nu hersteld, er geldt nu een rate limit van 100 per minuut, waardoor het downloaden sneller gaat (met sporadisch nog een bestand van 0 bytes of een HTTP 500 foutmelding).

Helaas zijn de bestanden, waarvan het de bedoeling is dat mensen deze makkelijk kunnen downloaden, nog steeds met een key (die elke dag anders is!) in de URL "beveiligd" tegen downloaden...

Verwerking

Nu de bijna 9 duizend bestanden zijn gedownload kan ik over gaan tot controle en verwerking van de bestanden. De bestanden zijn conform de XSD van A2A, oftewel, de syntax klopt. Dit betekent echter niet dat alle bestanden goed zijn!

Hieronder een voorbeeld:

<a2a:A2A xmlns:a2a="http://Mindbus.nl/A2A" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Version="1.7" xsi:schemaLocation="http://Mindbus.nl/A2A http://Mindbus.nl/A2A/A2AAllInOne_v.1.7.xsd"><a2a:Event eid="Event1"><a2a:EventType>Trouwen</a2a:EventType><a2a:EventDate><a2a:LiteralDate>21-10-1731</a2a:LiteralDate><a2a:Year>1731</a2a:Year><a2a:Month>10</a2a:Month><a2a:Day>21</a2a:Day></a2a:EventDate><a2a:EventPlace><a2a:Place>Zutphen</a2a:Place></a2a:EventPlace></a2a:Event><a2a:Source><a2a:SourcePlace><a2a:Country>Nederland</a2a:Country><a2a:Place>Zutphen</a2a:Place></a2a:SourcePlace><a2a:SourceIndexDate><a2a:From>1731-10-21</a2a:From><a2a:To>1731-10-21</a2a:To></a2a:SourceIndexDate><a2a:SourceDate><a2a:LiteralDate>21-10-1731</a2a:LiteralDate><a2a:Year>1731</a2a:Year><a2a:Month>10</a2a:Month><a2a:Day>21</a2a:Day></a2a:SourceDate><a2a:SourceType>DTB Trouwen</a2a:SourceType><a2a:SourceReference><a2a:Place>Arnhem</a2a:Place><a2a:InstitutionName>Gelders Archief</a2a:InstitutionName><a2a:Archive>0176</a2a:Archive><a2a:RegistryNumber>1912.18</a2a:RegistryNumber><a2a:DocumentNumber/></a2a:SourceReference><a2a:SourceAvailableScans><a2a:Scan><a2a:OrderSequenceNumber>1</a2a:OrderSequenceNumber><a2a:UriViewer>http://www.geldersarchief.nl/zoeken/?mivast=37&amp;miadt=37&amp;miaet=18&amp;micode=0176_1912.18&amp;minr=24643340&amp;miview=ldt</a2a:UriViewer><a2a:UriPreview>http://files.archieven.nl/php/get_thumb.php?adt_id=37&amp;toegang=0176&amp;file=1912.18\1912.18-0001.pdf</a2a:UriPreview></a2a:Scan></a2a:SourceAvailableScans><a2a:SourceLastChangeDate>2011-06-15</a2a:SourceLastChangeDate><a2a:RecordIdentifier>102821035</a2a:RecordIdentifier><a2a:RecordGUID>{A0881A04-6ADA-47A3-9F3D-9388F00DE11A}</a2a:RecordGUID></a2a:Source></a2a:A2A>


Opdracht: zoek in bovenstaand stuk XML de persoonsnamen op...

Helaas, bovenstaand A2A record bevat geen persoonsnamen. Oftewel een incompleet stuk data, waar ik niets mee kan.

Geen link naar website archief

Als je de akte die in bovenstaand stuk XML wordt beschreven wilt bekijken op de website van het Gelders Archief of archieven.nl, dan heb je ook een uitdaging, of beter gezegd, ook daar heb je niet genoeg informatie voor. 

Vaak zie je dat de URL van de akte op de website van het archief wordt weergegeven in het element SourceDigitalOriginal, deze wordt echter niet geleverd. Vaak is het ook mogelijk om een link te construeren op basis van de waarde in de element RecordGUID of RecordIdentifier. Of dit hier mogelijk is weet ik niet, het is niet gedocumenteerd. 

Afbeeldingen beschikbaar?
Gelukkig bevat de data set ook A2A records met persoonsnamen, deze stromen nu Open Archieven binnen. En daar wordt het volgende euvel zichtbaar... (en dan doel ik niet op personen die #### heten).

De A2A records bevatten ook links naar de scans (en viewer). Een voorbeeld van zo'n URL is:
http://files.archieven.nl/php/get_thumb.php?adt_id=37&toegang=0207A&file=1410-03\004525767_00168.jpg

En deze scan ziet er als volgt uit:


Waarom links naar dit soort "afbeelding nog niet beschikbaar" afbeeldingen opnemen als de afbeelding nog niet beschikbaar is !?!?!

Conclusie

De kwaliteit van de open data en het open data portaal is nog niet zoals je mag verwachten. Deze ondermaatse kwaliteit straalt wel af op leverancier en archief! Dat is jammer en niet nodig.

maandag 14 maart 2016

Inbreng voor eerstvolgende bijeenkomst van de #A2A werkgroep

Graag wil ik voor de eerstvolgende bijeenkomst van de werkgroep die zich bezig houdt met de open standaard A2A het volgende inbrengen op de onderdelen (ook wel: beheerobjecten):
  • A2AAllInOne_v.1.7.xsd
  • Documentatie v 1.8
  • Beheerprocedure
Voor de volgende onderdelen zijn er geen opmerkingen:
  • RecordCollectionA2A.xsd
  • Schematrons
NB: Interesse voor deelname aan de A2A werkgroep kan gemeld worden bij de beheerder van deze open standaard, het CBG (via jeroen.balkenende@cbg.nl).



ID: 1

Component: Beheerprocedure

Issue: Er ontbreekt een beheerprocedure voor A2A (of deze is niet openbaar), er is geen roadmap bekend (huidige initiële versie 1.7 is van 7 april 2011).

Change: Maak en publiceer beheerprocedure, organiseer werkgroep, beheer open standaard.



ID: 2

Component: Beheerprocedure

Issue: Niet één plaats waar beheerobjecten beschikbaar is.
Issue: Niet één, openbare plaats, waar issues gemeld kunnen worden.

Change: Al het materiaal op Github plaatsen, een ieder kan issues melden en pull requests doen (dus bijdragen).



ID: 3

Component: A2AAllInOne_v.1.7.xsd

Issue: Het element Collection is van het type token100, dat is erg krap voor een beschrijving van een collectie.

Change: Wijzig het type van Collection in token400.



ID: 4

Component: A2AAllInOne_v.1.7.xsd

Issue: Het element PersonNameFirstName is van het type token100, dit is te krap voor uitzonderingen als "Friedrich August Albert Anton Ferdinand Joseph Karl Maria Baptist Nepomuk Wilhelm Xaver Georg Fidelis" (komt voor bij dapperheidsonderscheidingen NIMH).

Change: Wijzig het type van PersonNameFirstName in token400.



ID: 5

Component: A2AAllInOne_v.1.7.xsd

Issue: Een Person bevat optioneel een BirthDate en BirthPlace om de geboortedatum -en plaats van en persoon vast te leggen (behalve bij een geboorteakte, dan worden deze gegevens vastgelegd in het Event). In sommige akten (niet zijnde overlijdensakten, maar bijv. huwelijksakten) worden ook de overlijdensdatum en -plaats van de persoon weergegeven.

Change: Voeg een DeathDate (als BirthDate) en DeathPlace (als BirthPlace) tot aan Person.



ID: 6

Component: A2AAllInOne_v.1.7.xsd

Issue: Het element SourceType heeft als waarde patroon 'DTB Dopen|DTB Trouwen|DTB Begraven|BS Geboorte|BS Huwelijk|BS Overlijden|Bevolkingsregister|Notariële archieven|VOC Opvarenden|Kadaster|Memories van Successie|other:.*'. Alhoewel de other:.* constructie andere waarden mogelijk maakt is het toevoegen van bekende brontypen aan te raden voor eenduidigheid.

Change: Voeg 'BS Echtscheiding' toe aan het waarde patroon van SourceType.



ID: 7

Component: A2AAllInOne_v.1.7.xsd

Issue: Het element RelationType heeft als waarde patroon 'Kind|Dopeling|Bruid| Bruidegom|Overledene|Vader|Moeder|Vader van de bruid|Moeder van de bruid|Vader van de bruidegom|Moeder van de bruidegom|Getuige|Geregistreerde|Partner|other:.*'. Alhoewel de other:.* constructie andere waarden mogelijk maakt is het toevoegen van bekende relatietypen aan te raden voor eenduidigheid.

Change: Voeg 'Weduwe|Weduwnaar|Echtgenoot|Echtgenote' toe aan het waarde patroon van RelationType.



ID: 8

Component: A2AAllInOne_v.1.7.xsd

Issue: Het element EventType heeft als waarde patroon 'Geboorte|Doop|Ondertrouw|Huwelijk|Trouwen|Echtscheiding| Overlijden|Begraven|Registratie|Notariële akte|Memorie van successie|Anders|other:.*'. Een Notariële akte en Memorie van successie zijn brontypen, geen gebeurtenissen.
Issue: De volgende gebeurtenissen ontbreken: Crematie, Verloving, Emigratie, Immigratie, Proces, Aanstelling, Onderscheiding, Naturalisatie.
Issue: Anders is nietszeggend en dubbelop met other:.*.

Change: Het waarde patroon van element EventType wijzigen in 'Geboorte|Doop|Ondertrouw|Huwelijk|Trouwen|Echtscheiding|Overlijden|Begraven|Registratie|Crematie|Verloving|Emigratie|Immigratie|Onderscheiding|Naturalisatieother:.*'.



ID: 9

Component: A2AAllInOne_v.1.7.xsd

Issue: Het complexe type ctTransNumber - gebruikt in PersonAgeDays,PersonAgeHours, PersonAgeMinutes, PersonAgeMonths, PersonAgeWeeks, PersonAgeYears, Day, Hour, Minute, Month, Year - is van het type token500.

Change: Wijzig het type van ctTransNumber in  (het striktere) xsd:unsignedShort (of wijzig waar gebruikt).



ID: 10

Component: A2AAllInOne_v.1.7.xsd

Issue: Types als RegistryNumber en DocumentNumber zijn van het type token100.

Change: Wijzig het type in (het striktere) xsd:unsignedInt.



ID: 11

Component: A2AAllInOne_v.1.7.xsd

Issue: Alle plaatsaanduidingen zijn nu tokens (dus vrije tekst), terwijl archiefinstellingen meer en meer hun topografische elementen in hun collecties standaardiseren met URI's om linked data mogelijkheden te benutten.

Change: Neem bij de plaatsaanduidingen het attribuut URI op, waarin bijvoorbeeld een Geonames, Gemeentegeschiedenis of http://thesaurus.erfgeo.nl/ URI kan worden opgenomen.



ID: 12

Component: A2AAllInOne_v.1.7.xsd

Issue: Veel van de types zijn gebaseerd op xsd:sequence waardoor de volgorde zeer strikt is, terwijl de volgorde semantisch niet van belang is.

Change: Wijzig alle xsd:sequentes naar naar (het lossere) xsd:any.

Also see: http://stackoverflow.com/questions/3325247/xml-validation-with-xsd-how-to-avoid-caring-about-the-sequence-of-the-elements)



ID: 13

Component: A2AAllInOne_v.1.7.xsd

Issue: Het EAD element bevat de verplichte elementen URL en Code, terwijl de documentatie spreekt of een keue uit twee manieren (wat logischer is).

Change: De cardinaliteit van URL en Code wijzigen in {0,1}.



ID: 14

Component: A2AAllInOne_v.1.7.xsd

Issue: Het element Religion is van het type ctTransString (token100), dus vrije tekst.

Change: Voeg een waarde patroon toe om meer uniformiteit te krijgen bij deze waarde (zoals bijv. bij MaritalStatus).





ID: 15

Component: A2AAllInOne_v.1.7.xsd

Issue: De elementen Longitude en Latitude zijn van van het type ctTransString (token100).

Change: Wijzig het type van Longitude en Latitude in (het striktere) xsd:float.



ID: 16

Component: A2AAllInOne_v.1.7.xsd

Issue: Het element Calender is nu een token100 (vrij tekst).

Change: Het type laten voldoen aan het waarde patroon 'Gregorian|Julian|Hebrew|French|Islamic|Maya|Hindu|Saka|other:*'




ID: 17

Component: Documentatie v 1.8

Issue: Typo "nummerieke index".

Change: "numerieke index".



ID: 18

Component: Documentatie v 1.8

Issue: Op pagina 25 en verder werken de Dropbox links naar voorbeeld XMLs en schematrons niet meer (404).

Change: Voorbeelden op Github en daar naartoe linken.



ID: 19

Component: Documentatie v 1.8

Issue: Typo op pagina 14 "dieniet".

Change: "die niet".



ID: 20

Component: Documentatie v 1.8

Issue: Typo op o.a. pagina 20 "definieren".

Change: "definiëren" (door heel het document).



ID: 21

Component: Documentatie v 1.8

Issue: Typo op pagina 21 "dar er".

Change: "dat er".



ID: 22

Component: Documentatie v 1.8

Issue: Er zijn diverse internationale gebruikers, het grootste deel van de documentatie (en waardelijsten) is in het Nederlands gesteld wat de internationale adoptie kan belemmeren.

Change: Over op beschrijving en voertaal in Engels.



ID: 23

Component: A2AAllInOne_v.1.7.xsd

Issue: Het element Scan verwijst naar online scans (Uri, UriPreview, UriViewer). Niet altijd is er een link mogelijk naar één akte, maar wel naar heel het gescande register. Er kan op dit moment niet worden aangegeven of er wordt gelinkt aan één akte of een register.

Change: Breid het element Scan uit het optionele element A2A:ScanType van type token100 met mogelijk waarden "akte" en "register".

See also: http://blogbob.coret.org/2013/09/wijzigingsverzoek-op-a2a-model.html




ID: 24

Component: A2AAllInOne_v.1.7.xsd

Issue: Het element Book is van het type token100, dat is erg krap voor een beschrijving van een boek.

Change: Wijzig het type van Book in token400.

woensdag 2 maart 2016

Eerste blik op #opendata portaal van @geldersarchief / @deree_groningen

Op dinsdag 1 maart 2016 kondigde het Gelders Archief aan dat zij de historische gegevens van de Burgerlijke Stand beschikbaar stelt als open data:

Het Gelders Archief stelt met ingang van vandaag de gegevens van de Gelderse Burgerlijke Stand (BS) (1811-1950) beschikbaar als open data. Daarmee gaat het Gelders Archief, in navolging van het Nationaal Archief, een stap verder dan de Wet hergebruik van overheidsinformatie (Who), die 2015 in werking trad.
U zult zich nu wellicht afvragen, hoe kun je een stap verder gaan dan een wet. Maar OK, ze bedoelen natuurlijk dat ze liever niet re-actief hergebruikverzoeken beantwoorden (op basis van de Who) en dus pro-actief open data bieden.

Uiteraard wordt in het nieuwsbericht nog even toegelicht wat open data is:
Wat zijn open data?
Open data zijn gegevens die vrij beschikbaar zijn met een minimum aan beperkingen. Bij overheden gaat het om overheidsinformatie, die openbaar is, waar geen auteursrecht of andere rechten van derden op berust, die bekostigd is uit publieke middelen en is voortgekomen uit uitvoering van de publieke taak. Open data zijn bij voorkeur computer-leesbaar en voldoen aan open standaarden.

de data wordt beschikbaar gesteld onder een CC0 licentie: goed!

Downloaden van bestanden (hoe moeilijk kan dat zijn)
De open data wordt beschikbaar gesteld via de oplossing van De Ree archiefsystemen. In dit open data portaal worden maar liefst 8.998 data sets aangeboden door het Gelders Archief. De keuze voor het aanbieden van bestanden ter download in plaats van een API volgens het OAI-PMH protocol lijkt een trend. Op zich heb ik met deze keuze geen probleem, bestanden downloaden is simpel, toch?

Echter, de wijze waarop De Ree de bestanden ter download biedt is niet echt handig te noemen, het stimuleert zeg maar niet dat de data wordt hergebruikt. Het open data portaal levert namelijk niet direct een lijst met links naar de bestanden. Handmatig moet er eerst geklikt worden op een regel in de lijst van 8999 items, waarna de download link pas wordt opgehaald en getoond. Met deze hoeveelheden is handwerk überhaupt geen optie (scheelt weer een boel hergebruikers...).

Uiteraard probeer ik de bestanden niet handmatig te downloaden maar geautomatiseerd (waarbij ik dus ook voor elke pagina meerdere requests moet doen om de download links te krijgen) en wat me dan opvalt is dat alle bestandslinks zijn voorzien van een sleutel (key) in de url. Waarom bestanden die bedoeld zijn om her te gebruiken op deze manier beveiligen?
http://files.archieven.nl/php/download.php?adt=37&nummer=0207A_G_2516-03&bestand=%2F37%2Fxml%2Fa2a%2FNL-AhGldA_0207A_G_2516-03_54_A2A.xml&key=1A7MCZCE1C

Als je uiteindelijk de 8998 links hebt naar de bestanden kun je deze niet zo maar downloaden, na ongeveer 100 bestanden lijkt het IP-adres van mijn server op een zwarte lijst te komen. Met een andere server kom ik weer even wat verder tot ook daar een limiet bereikt wordt. Niet dat ik een foutmelding krijg, nee de bestanden die worden geretourneerd zijn gewoonweg leeg (0 bytes). Het is toch de bedoeling dat ik de bestanden download, waarom wordt het downloaden dan tegengewerkt?

In de toekomst zullen de bestanden aangepast worden omdat gegevens gecorrigeerd of aangevuld worden. Er is in het portaal geen manier om "bestanden gewijzigd sinds" te krijgen. Dus een volgende keer moet alles weer gedownload worden.

Bestandsinhoud
Ik heb nu een paar honderd bestanden mogen downloaden en heb dus naar de inhoud kunnen kijken. Het eerste wat opvalt is dat de character-encoding van de bestanden niet klopt. Het zou, volgens de A2A standaard, UTF-8 moeten zijn. Dat zijn de bestanden niet, waardoor diakrieten bijvoorbeeld fout gaan.

Wat me daarna opvalt is dat de A2A records geen links bevatten naar scans. Niet elke akte zal gekoppeld zijn aan scans of gescande registers in het archiefbeheersysteem, maar een deel van de Gelderse akten is dit wel degelijk. Deze informatie ontbreekt echter in de bestanden.

Waarom zit er trouwens zoveel "lucht" in de XML bestanden: lege tags als <a2a:Profession\> en veel overbodige white-space. En waarom zijn bestanden niet gecomprimeerd, via "offline ZIP" of GZIP-on-the-fly? Voorbeeld: het bestand 0207A_G_3074-12.xml is 219.506 bytes groot, als je de "lucht" eruit haalt en comprimeert blijft er een bestand over van 6.542 bytes. Scheelt een factor 34, ook in opslag en bandbreedte!

Conclusie
Ik ben enigszins teleurgesteld over het open data portaal. Het huidige portaal, laten we het versie 0.1 beta noemen, stimuleert hergebruik geenszins. Door de drempels, het niet voldoen aan de standaard en het incompleet zijn van data, wordt er geen open data geboden.

Gelukkig zijn geen van de geconstateerde punten moeilijk op te lossen. Dus met een beetje goede wil leveren het Gelders Archief en de andere klanten van De Ree binnenkort wel open data!


[update 3-3-2016]

Sommige gedownloade bestanden blijken geen A2A te bevatten maar foutmeldingen, dit is een groter probleem voor De Ree!

<!--705133935:{D93A49F7-7614-46B2-BF46-F474F9C676BC}:-4030 = ORA-04030: Onvoldoende procesgeheugen tijdens poging 524352 bytes (lpxHeap subhea,qmxsaxAllocMemInternal) toe te wijzen.:1 -->
<!--705133939:{F4179440-875C-4774-9F32-C843452DFFCD}:-4030 = ORA-04030: Onvoldoende procesgeheugen tijdens poging 524352 bytes (lpxHeap subhea,qmxsaxAllocMemInternal) toe te wijzen.:1  -->
<!--705133943:{9943B1CE-0501-442E-9C67-2B7247C1FAD9}:-4030 = ORA-04030: Onvoldoende procesgeheugen tijdens poging 524352 bytes (lpxHeap subhea,qmxsaxAllocMemInternal) toe te wijzen.:1 -->
<!--705133947:{B478C4AA-363D-4797-8BB9-BF1E7C15A792}:-4030 = ORA-04030: Onvoldoende procesgeheugen tijdens poging 524352 bytes (lpxHeap subhea,qmxsaxAllocMemInternal) toe te wijzen.:1 -->
<!--705133951:fout:ORA-04030: Onvoldoende procesgeheugen tijdens poging 123416 bytes (QERHJ hash-joi,kllcqas:kllsltba) toe te wijzen.:1 -->
<!--705133955:fout:ORA-04030: Onvoldoende procesgeheugen tijdens poging 97264 bytes (QERHJ hash-joi,kllcqc:kllcqslt) toe te wijzen.:1 -->
<!--705133959:fout:ORA-04030: Onvoldoende procesgeheugen tijdens poging 97264 bytes (QERHJ hash-joi,kllcqc:kllcqslt) toe te wijzen.:1 -->
<!--705133963:fout:ORA-04030: Onvoldoende procesgeheugen tijdens poging 97264 bytes (QERHJ hash-joi,kllcqc:kllcqslt) toe te wijzen.:1 -->
<!--705133967:fout:ORA-04030: Onvoldoende procesgeheugen tijdens poging 97264 bytes (QERHJ hash-joi,kllcqc:kllcqslt) toe te wijzen.:1 -->
........

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.