woensdag 17 mei 2017

Nieuw archiefsysteem en bestaande data? Grondige controle vereist!


Archiefinstellingen beheren heel wat data, waaronder nadere toegangen / indexen, die voor genealogen van grote waarde zijn. Als archiefinstellingen overstappen op software van een nieuwe leveranciers is het altijd maar hopen dat alle data goed overkomt. Ook wanneer een archiefinstelling overstapt op een nieuwe versie van hetzelfde systeem is het van groot belang dit grondig te controleren. In dit artikel een voorbeeld van wat er kan misgaan.

Bevolkingsregister Leiden

Onderstaande afbeelding komt uit een presentatie over Open Archieven uit mei 2015. Het toont een registratie uit het bevolkingsregister van Leiden (archiefnummer 516, inventarisnummer 1309). 


Reden dat deze pagina was opgenomen in de presentatie was het feit dat Open Archieven de straat toon op een historische kaart. De kaart was in dit geval beschikbaar gesteld door Erfgoed Leiden, de straat informatie is afkomstig van OpenStreetsMaps. Met één klik op de straatnaam krijgt de Open Archieven gebruiker een beeld waar de straat in Leiden lag (en hoogstwaarschijnlijk nog ligt).


Wie nu, twee jaar later, naar dezelfde pagina uit het bevolkingsregister gaat, ziet de volgende pagina:

De huidige versie heeft geen straatnaam en een andere datum?!?!

Controle van de bron data (het A2A record met GUID f885100e-9c88-f0b2-8c34-9232ee10b2f0), leert dat het niet aan de weergave door Open Archieven ligt. De straatnaam maakt geen onderdeel meer uit van de beschikbaar gestelde data.

<?xml version="1.0" encoding="UTF-8"?>
<OAI-PMH xmlns="http://www.openarchives.org/OAI/2.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd">
  <responseDate>2017-05-16T14:40:13Z</responseDate>
  <request verb="GetRecord" metadataPrefix="oai_a2a" identifier="3f630667-c793-46e9-61d4-45f0970b50ba">http://webservices-a2a.picturae.pro/20a181d4-c896-489f-9d16-20a3b7306b15/</request>
  <GetRecord xmlns:a2a="http://Mindbus.nl/A2A">
    <record xmlns:a2a="http://Mindbus.nl/A2A">
      <header>
        <identifier>3f630667-c793-46e9-61d4-45f0970b50ba</identifier>
        <datestamp>2017-04-12T10:54:15Z</datestamp>
      </header>
      <metadata xmlns:a2a="http://Mindbus.nl/A2A">
        <a2a:A2A xmlns:a2a="http://Mindbus.nl/A2A" Version="1.7">
          <a2a:Person pid="Person:6b269db5-29fd-6fe2-b6ce-1a554ab8cd22">
            <a2a:PersonName>
              <a2a:PersonNameFirstName>Johanna Maria</a2a:PersonNameFirstName>
              <a2a:PersonNameLastName>Coret</a2a:PersonNameLastName>
            </a2a:PersonName>
            <a2a:Gender>Onbekend</a2a:Gender>
            <a2a:BirthDate>
              <a2a:Year>1879</a2a:Year>
              <a2a:Month>3</a2a:Month>
              <a2a:Day>15</a2a:Day>
            </a2a:BirthDate>
            <a2a:BirthPlace>
              <a2a:Place>Leiden</a2a:Place>
            </a2a:BirthPlace>
          </a2a:Person>
          <a2a:Event eid="Event1">
            <a2a:EventType>Registratie</a2a:EventType>
            <a2a:EventDate>
              <a2a:Year>1879</a2a:Year>
              <a2a:Month>3</a2a:Month>
              <a2a:Day>15</a2a:Day>
            </a2a:EventDate>
          </a2a:Event>
          <a2a:RelationEP>
            <a2a:PersonKeyRef>Person:6b269db5-29fd-6fe2-b6ce-1a554ab8cd22</a2a:PersonKeyRef>
            <a2a:EventKeyRef>Event1</a2a:EventKeyRef>
            <a2a:RelationType>other:Persoon</a2a:RelationType>
          </a2a:RelationEP>
          <a2a:Source>
            <a2a:SourcePlace>
              <a2a:Place>Leiden</a2a:Place>
            </a2a:SourcePlace>
            <a2a:SourceIndexDate>
              <a2a:From>1890-01-01</a2a:From>
              <a2a:To>1924-12-31</a2a:To>
            </a2a:SourceIndexDate>
            <a2a:SourceType>Bevolkingsregister</a2a:SourceType>
            <a2a:SourceReference>
              <a2a:Place>Leiden</a2a:Place>
              <a2a:InstitutionName>Erfgoed Leiden</a2a:InstitutionName>
              <a2a:Archive>516</a2a:Archive>
              <a2a:Collection>Archiefnaam: Archief van het algemeen en dagelijks bestuur, (1545) 1816-1929 (1963); Bevolkingsbo...</a2a:Collection>
              <a2a:Book>48. supplement I. (1 - 415)</a2a:Book>
              <a2a:Folio>45</a2a:Folio>
              <a2a:RegistryNumber>1350</a2a:RegistryNumber>
            </a2a:SourceReference>
            <a2a:SourceLastChangeDate>2012-01-06</a2a:SourceLastChangeDate>
            <a2a:SourceDigitalOriginal>https://www.erfgoedleiden.nl/collecties/personen/zoek-op-personen/deeds/3f630667-c793-46e9-61d4-45f0970b50ba</a2a:SourceDigitalOriginal>
            <a2a:RecordGUID>{3f630667-c793-46e9-61d4-45f0970b50ba}</a2a:RecordGUID>
            <a2a:SourceRemark Key="Opmerking">
              <a2a:Value>
<br/><a href="/collecties/archieven/archievenoverzicht/inventaris/index/eadid/0516/inventarisnr/1350">Inventarisnummer 1350 van archiefnummer 516 in Archieven</a></a2a:Value>
            </a2a:SourceRemark>
          </a2a:Source>
        </a2a:A2A>
      </metadata>
    </record>
  </GetRecord>
</OAI-PMH>


Ook op de website van Erfgoed Leiden wordt de straatnaam niet getoond:


Missende data

Is de straatnaam informatie verloren gegaan? Of wordt deze alleen niet gepresenteerd? Ik hoop natuurlijk op het laatste, dan is het een kwestie van presentatie aanpassen en de A2A mapping corrigeren. 

Wat betreft de datum van de registratie, deze wordt op de website van Erfgoed Leiden niet getoond. In het A2A record is er wel een EventDate aanwezig. Maar, laat dit nu steeds de geboortedatum van de persoon zijn... Ook hier weer de vraag: zijn de originele gegevens verloren of worden ze nu niet goed getoond?

Werk aan de winkel voor Erfgoed Leiden en hun leverancier.

zaterdag 8 april 2017

Open data wel en wee #1


Eén van de datasets die op Open Archieven wordt gepresenteerd is de VOC Opvarenden collectie, bij het Nationaal Archief bekend als Nadere Toegang 344 op archief 1.04.02. Toen de dataset in het voorjaar van 2014 werd verwerkt door Open Archieven, waren er nog geen koppelingen tussen de personen en de scans. Bij toeval kwam ik er deze week achter dat er op de GaHetNa website nu wel scans worden getoond!

De nadere toegang, inclusief de namen van de scans, was en is ook downloadbaar. Dat er nu een rijker data bestand beschikbaar was, is naar mijn weten nergens aangekondigd. Ik heb als hergebruiker van de dataset (dat is bekend bij het Nationaal Archief) ook geen persoonlijk bericht ontvangen.

Nergens op de GaHetNa website is er een overzicht van downloadbare indexen met daarbij een laatste wijzigingsdatum. Er is wel een overzicht van indexen die beschikbaar zijn als open data, helaas is er in dit document ook geen datum of versie nummer opgenomen. Niet dat de VOC Opvarenden voorkomt in dit document, dat staat in het overzicht van indexen die niet beschikbaar zijn als open data, ook hier weer geen datum/versienummer. De technische metadata van de PDF documenten geven overigens wel informatie over creatiedatum (19-01-2016) en auteur. Dat het VOC Opvarenden bestand geen open data is maar wel te downloaden is blijf ik vreemd vinden. Voor het presenteren van de data op Open Archieven heb ik overigens toestemming.

De nieuwe VOC Opvarenden dataset is volgens de bijgeleverde metadata gemaakt op 10 februari 2017. Waarschijnlijk een uitvloeisel van de VOC tentoonstelling die nu bij het Nationaal Archief is te bekijken. Wat direct opvalt is dat het bestand niet betrekking heeft op Nadere Toegang 344 is maar 444. Blijkbaar kunnen bestaande nadere toegangen niet aangepast worden en is er een nieuwe nadere toegang gemaakt. De nieuwe beschrijving mist overigens de introductie en melding dat er geen CC0 geldt, zoals wel bij de NT00344 was opgenomen.

Benieuwd naar de inhoudelijke data, heb ik een persoon waarvan ik weet dat deze voorkomt in VOC Opvarenden, opgezocht in het nieuwe (NT00444) en oude bestand (NT00344).

NT00444_OPVARENDEN.csv:"Erris Danglisoe","Erris","","","Danglisoe","Arbeek","Matroos","Sailor","Matrose","waak- en roergang; laden en lossen; reinigen, teren en kalfaten van het schip; af- en aanslaan van de zeilen; helpers van de onderofficieren. Ook wel bootsgezel.","(Dutch: matroos) watch and helmansman duties; loading and unloading; cleaning, taring and caulking the ship; hoisting and pulling in the sails; assisting the NCOs.","(niederländisch: matroos) vgl. Bootsgeselle (niederländisch: bootsgezel)","1761-04-19","1762-03-13","Azie","Asia","Asien","Overleden","Deceased","Gestorben","","","","Schagen","Nee","Ja","","","","","","","0","","","","","","","3076","","NL-HaNA/1.04.02/14471//108//","d110ccf0-c864-11e6-9d8b-00505693001d","NL-HaNA_1.04.02_14471_0122.jpg","http://hdl.handle.net/10648/9337d26a-7e22-5f35-8f58-65546ba8f995","1130647"

NT00344_opvarenden.csv:"1130647","Erris Danglisoe","Erris","","","Danglisoe","Arbeek","Matroos","Sailor","Matrose","waak- en roergang; laden en lossen; reinigen, teren en kalfaten van het schip; af- en aanslaan van de zeilen; helpers van de onderofficieren. Ook wel bootsgezel.","(Dutch: matroos) watch and helmansman duties; loading and unloading; cleaning, taring and caulking the ship; hoisting and pulling in the sails; assisting the NCOs.","(niederländisch: matroos) vgl. Bootsgeselle (niederländisch: bootsgezel)","1761-04-19","1762-03-13","Azie","Asia","Asien","Overleden","Deceased","Gestorben","","","","Schagen","Nee","Ja","","","","","","","","","","","","","","3076","0","NL-HaNA/1.04.02/14471//108//","bd85f0c8-b77c-4ce3-b4b7-d8b30843ce7d"

De verschillen in structuur van beide bestanden is met kleur aangegeven, één verplaatst veld (van begin naar eind) en 2 extra velden achteraan voor de informatie over de scan. Dat het nieuwe bestand verschilt van het oude bestand is overigens ook nergens gedocumenteerd.

Even tussendoor over de scans: via de consoles in de tentoonstellingsruimte van het Nationaal Archief kun je de VOC Opvarenden ook doorzoeken en volgens mij zag ik daar dat er meerdere scans waren gekoppeld aan een persoon, op GaHetNa en in dit bestand staat er maar één scan?

Maar waar ik meer van schrik is dat het "prs_id" veld (identificatie-nummer van de persoon) is gewijzigd. Waar het Internet adres van testsubject Eris Danglisoe voorheen dus http://www.gahetna.nl/collectie/index/nt00344/bd85f0c8-b77c-4ce3-b4b7-d8b30843ce7d was, is dit nu http://www.gahetna.nl/collectie/index/nt00444/d110ccf0-c864-11e6-9d8b-00505693001d. De oude URL levert een lege zoekpagina op, geen foutmelding en al helemaal geen doorverwijzing naar het nieuwe adres. Dit is erg jammer! Een ieder die dus links had gelegd naar personen binnen de VOC Opvarenden collectie op GaHetNa heeft nu dus een boel broken links, zowel particulieren als zoekmachines als Google en websites als Open Archieven!

Voor Open Archieven nu maar aan de slag om de scans weer te geven en om weer werkende links te krijgen naar GaHetNa ...

[update 9-4-2017] De VOC Opvarenden collectie op Open Archieven toont nu ook de scans en linkt naar de gewijzigde adressen op GaHetNa. Bekijk als voorbeeld de inschrijving van testsubject Erris Danglisoe (waarbij de Open Archieven URL's van de VOC Opvarenden pagina ongewijzigd zijn gebleven).

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!