Blog Bob https://blogbob.coret.org/ the more technology related stuff Thu, 27 Jul 2023 16:45:56 +0000 nl-NL hourly 1 https://blogbob.coret.org/wp-content/uploads/sites/2/2017/10/gele-boom.png Blog Bob https://blogbob.coret.org/ 32 32 Spelen met ChatGPT vanuit SPARQL (GraphDB) https://blogbob.coret.org/2023/07/spelen-met-chatgpt-vanuit-sparql-graphdb.html https://blogbob.coret.org/2023/07/spelen-met-chatgpt-vanuit-sparql-graphdb.html#comments Thu, 27 Jul 2023 16:45:56 +0000 https://blogbob.coret.org/?p=923 De nieuwste versie van triplestore GraphDB (10.3) heeft nu ook een integratie met ChatGPT. Na installatie van deze nieuwe versie, met een (betaalde) API key van OpenAI en de documentatie kon ik snel aan de slag om te kijken wat “harnass the power of ChatGTP” betekent. NB: Bijna alle tests hebben betrekking op de Gouda...

Het bericht Spelen met ChatGPT vanuit SPARQL (GraphDB) verscheen eerst op Blog Bob.

]]>
De nieuwste versie van triplestore GraphDB (10.3) heeft nu ook een integratie met ChatGPT. Na installatie van deze nieuwe versie, met een (betaalde) API key van OpenAI en de documentatie kon ik snel aan de slag om te kijken wat “harnass the power of ChatGTP” betekent. NB: Bijna alle tests hebben betrekking op de Gouda Tijdmachine Knowledge Graph.

SPARQL query uitleg

Wanneer je een SPARQL query uitvoert in GraphDB door op de Run knop én de Alt toets te drukken, dan zal in de resultaten een _gpt kolom verschijnen met de uitleg van de query:

ChatGTP inzetten voor reconcilitatie?

Naar aanleiding van een gesprek eerder op de dag, in hoeverre AI erfgoedinstellingen kan helpen bij het reconciliëren van termen (dus termen zoals plaatsnamen, kunstenaars, schrijvers, ed. koppelen aan URI’s in terminologiebronnen) een test waarop ik al wist dat het antwoord niet goed zou zijn (maar toont wel een manier aan waarop je ChatGPT aangesproken kan worden in GraphDB’s SPARQL):

Maak iets van mijn data (1)

De SPARQL functie DESCRIBE geeft alle triples van een bepaald subject, in dit voorbeeld van een pen en perceeltekening getiteld “Gezicht op de Gouwe”. In dit voorbeeld geef ik de instructie via een tweetal “commentaar-commando’s” om een kort gedicht te maken over het werk (mijn verzoek is in het Nederlands, dus is het antwoord ook in het Nederlands).

Stel vragen aan mijn data in natuurlijke taal, sort-of

Je kan ook via helper functies triples verzamelen (in dit geval de sem:hasEarliestBeginTimeStamp waarden van de Goudse straten) om daar dan een een vraag over te stellen. Helaas, de verzamelde triples waren te veel “tokens” voor het gebruikte model. (een LIMIT 20 in de query had enige uitkomst geboden, maar toont nog wel de zwakte, liever had je, in plaats dat je alle RDF-kennis in je ChatGTP query moet stoppen, dat de vraag werd omgeschreven in SPARQL)

Data van ChatGTP in tabel vorm

Je kunt ook een vraag stellen aan ChatGPT waarbij de antwoorden in “tabel vorm” beschikbaar komen binnen je SPARQL query. In dit voorbeeld wordt er niets met het resultaat gedaan, alleen getoond. En de kenners zullen glimlachen van het antwoord (lees: hallucinaties).

Maak iets van mijn data (2)

OK, mijn bijdrage om archieven populairder te krijgen bij de jeugd (of: hoe krijg je archivarissen op de kast 😉

Conclusie

Het speelkwartier is weer voorbij. Nuttige toepassingen heb ik nog niet zo 1,2,3 gevonden voor deze integratie, het is meer in de categorie “leuk” zoals we van een Large Language Model mogen verwachten.

Ik denk dat ik had gehoopt dat ik een vraag in natuurlijke taal kon stellen die dan op basis van de Gouda Tijdmachine Ontologie werd omgeschreven in SPARQL en uitgevoerd en resulteert in een antwoord in natuurlijke taal zou opleveren. Benieuwd wat de vorderingen van Kadaster & Friends zijn naar aanleiding van hun publieksprijswinnende Hackalod 2022 project

Het bericht Spelen met ChatGPT vanuit SPARQL (GraphDB) verscheen eerst op Blog Bob.

]]>
https://blogbob.coret.org/2023/07/spelen-met-chatgpt-vanuit-sparql-graphdb.html/feed 1
IIIF stroomlijnt crowdsourcingsprojecten https://blogbob.coret.org/2023/07/iiif-stroomlijnt-crowdsourcingsprojecten.html https://blogbob.coret.org/2023/07/iiif-stroomlijnt-crowdsourcingsprojecten.html#comments Wed, 12 Jul 2023 15:41:55 +0000 https://blogbob.coret.org/?p=903 Bij het door de crowd laten indexeren van archiefbronnen, geo-positioneren van afbeeldingen of het geo-refereren van kaartmateriaal wordt er veelal binnen een crowdsource platform een project ingericht. Hiervoor is enerzijds informatie nodig over de bron(nen), zoals naam, plaats, jaartal/periode en toegangsnummer/inventarisnummer(s). Anderzijds moeten de scans vanuit de bron geselecteerd worden en gekopieerd naar het crowdsource...

Het bericht IIIF stroomlijnt crowdsourcingsprojecten verscheen eerst op Blog Bob.

]]>
Bij het door de crowd laten indexeren van archiefbronnen, geo-positioneren van afbeeldingen of het geo-refereren van kaartmateriaal wordt er veelal binnen een crowdsource platform een project ingericht. Hiervoor is enerzijds informatie nodig over de bron(nen), zoals naam, plaats, jaartal/periode en toegangsnummer/inventarisnummer(s). Anderzijds moeten de scans vanuit de bron geselecteerd worden en gekopieerd naar het crowdsource platform. Veel werk, waar ook een prijskaartje aan hangt. Kan dit niet efficiënter? Was het digitaal efgoed mantra niet “data bij de bron”?

Als we het hebben over metadata van beeldmateriaal en het presenteren van beeldmateriaal, dan hebben we het over IIIF.

IIIF, een afkorting van de International Image Interoperability Framework, is een verzameling standaarden die zijn ontworpen om afbeeldingen en andere visuele materialen gemakkelijker toegankelijk te maken op het internet. Deze standaarden zijn vooral nuttig voor bibliotheken, musea en andere instellingen die grote collecties digitale afbeeldingen beheren. Ze helpen bij het samenstellen, delen en inzoomen op hoge-resolutie afbeeldingen, en het aanmaken van annotaties.

Eén deel van IIIF is gericht op de interactie met de afbeeldingen zelf (IIIF Image API). Deze functionaliteit stelt gebruikers in staat om afbeeldingen op verschillende manieren te bekijken. Je kunt bijvoorbeeld inzoomen op een klein deel van een hoge-resolutie afbeelding zonder de hele afbeelding te moeten laden, wat nuttig kan zijn als je bijvoorbeeld een gedetailleerd kunstwerk of historisch document bekijkt. Je kunt ook afbeeldingen draaien, de kleur aanpassen, of een specifiek deel van een afbeelding selecteren.

Het andere deel van IIIF gaat over hoe deze afbeeldingen worden gepresenteerd (IIIF Presentation API), dit wordt vastgelegd in een manifest. Dit geeft onder andere een beschrijving van een collectie van afbeeldingen, de organisatie hiervan qua volgorde en een indicatie waar de afbeeldingen te vinden zijn. Het kan ook gaan om het combineren van afbeeldingen met andere soorten media, zoals tekst, audio of video, om een complexer verhaal of uitleg te creëren.

Stel, je wilt een crowdsourcingsplatform opzetten specifiek voor één type archiefbron: doodsbriefjes (overlijdensverklaringen waarop ook de doodsoorzaak staat vermeld). Als een archiefinstelling deze doodsoorzaakbronnen heeft gescand en als ‘registers met scans’ beschikbaar heeft gesteld dan kan de beschrijving (=metadata) uit het IIIF Manifest worden gehaald. In dit manifest staan ook de links naar de afbeeldingen, natuurlijk via een IIIF Image server. Doordat de archiefinstelling deze informatie over het beeldmateriaal op een standaard wijze toegankelijk maakt, kan het crowdsourcingsplatform deze doodsoorzaakbronnen zo als projecten aanbieden, waarbij de scans dus ‘geserveerd’ worden door de archiefinstelling, vanuit de bron (lees: het crowdsourcingsplatform heeft geen grote hoeveelheden storage nodig voor opslag van beeldmateriaal)!

En dan nu de praktijk. Bij welke systemen van archiefinstellingen die gescande doodsoorzakenbronnen hebben kan er een IIIF Manifest opgevraagd worden? Op dit moment komt Picturae’s Memorix als enige dicht in de buurt. Dit systeem biedt diverse API’s om data te ontsluiten. Helaas heb ik nog geen API documentatie gevonden, maar doordat de website van archiefinstellingen van Picturae klanten de API’s gebruiken, valt er snel te achterhalen welke API bevraagd moet worden om bijvoorbeeld informatie te krijgen over een register met scans. Dit komt in de buurt komt van een IIIF Manifest.

PS: onlangs is er in een Pica Verbonden Erfgoed project voor de beeldbank van de Atheneum Collecties door Picturae een mogelijk ingebouwd om een IIIF Manifest op te vragen, klik bijv. op het IIIF ikoontje in de linker balk bij de Hieronymusbrieven.

Zo levert een aanroep naar https://webservices.picturae.com/genealogy/register/d0e05ef2-bd60-86a9-0284-1ef349bed01d?apiKey=b80c5aec-ef5e-11e5-9ce9-5e5517507c66 (van het West-Brabants Archief) onder andere de volgende machine leesbare informatie (JSON):

register: [
  {
	id: "d0e05ef2-bd60-86a9-0284-1ef349bed01d",
	tenant: "wba",
	....
	metadata: {
		modified_time: "2022-11-23T11:06:38.566707",
		type_title: "overlijdensoorzaken",
		naam: "Gemeentebestuur Klundert 1811-1940 3096. (Medische) Verklaringen van overlijden, 1911.",
		archiefnummer: "raw - 0451",
		inventarisnummer: "3096",
		brontype: "origineel",
		gemeente: "Klundert",
		periode: [ 1911 ],
		has_assets: "register"
	},
	....
  }
]

En daarna kan Memorix bevraagd worden naar de scans binnen dit register, de zog. assets, via bijvoorbeeld het request https://webservices.picturae.com/genealogy/asset?apiKey=b80c5aec-ef5e-11e5-9ce9-5e5517507c66&page=1&q=register_id:%22d0e05ef2-bd60-86a9-0284-1ef349bed01d%22

asset: [
  {
	id: "9fa41342-159c-53f2-80e3-00376050b5c1",
	file_id: "6eb5a89b-b76c-5039-3999-aabfd7a0c7c9",
	....
	title: "RAW04513096_00000",
	metadata: {
		....
	},
	thumb.small: "https://images.memorix.nl/wba/thumb/100x100/6eb5a89b-b76c-5039-3999-aabfd7a0c7c9.jpg",
	thumb.medium: "https://images.memorix.nl/wba/thumb/250x250/6eb5a89b-b76c-5039-3999-aabfd7a0c7c9.jpg",
	thumb.large: "https://images.memorix.nl/wba/thumb/640x480/6eb5a89b-b76c-5039-3999-aabfd7a0c7c9.jpg",
	topview: "https://images.memorix.nl/wba/topviewjson/memorix/6eb5a89b-b76c-5039-3999-aabfd7a0c7c9",
	download: "https://images.memorix.nl/wba/download/large/6eb5a89b-b76c-5039-3999-aabfd7a0c7c9.jpg",
	deepzoom: "https://images.memorix.nl/wba/deepzoom/6eb5a89b-b76c-5039-3999-aabfd7a0c7c9.dzi"
},

Via de assets krijgen we informatie over de directe links naar de plaatjes zodat deze als thumbnail of via een viewer die TopView of DeepZoom ‘spreekt’ kunnen laten zien, vanuit de bron. Liever nog had ik een link naar de IIIF info.json (IIIF Image API) geizen. Hoewel dit niet geadverteerd wordt, wordt de IIIF Image API wel ondersteund door Memorix. Je moet even weten hoe de URL wordt opgebouwd… Voor de hierboven genoemde asset is de (basis) URL voor de IIIF Image API https://images.memorix.nl/wba/iiif/6eb5a89b-b76c-5039-3999-aabfd7a0c7c9

Voor het in oprichting zijnde crowdsourcingsplatform doodsoorzaken.nl is de informatie over de registers met ‘doodsbriefjes’ opgehaald bij het West-Brabants Archief via de API en worden er binnen dit platform scans getoond vanuit de bron (via de IIIF Image server). Een archiefinstelling die haar data en scans zo toegankelijk maakt kan je als platform toch geen kosten meer in rekening brengen?

Het bericht IIIF stroomlijnt crowdsourcingsprojecten verscheen eerst op Blog Bob.

]]>
https://blogbob.coret.org/2023/07/iiif-stroomlijnt-crowdsourcingsprojecten.html/feed 1
Open Archieven als plugin voor ChatGPT https://blogbob.coret.org/2023/06/open-archieven-als-plugin-voor-chatgpt.html https://blogbob.coret.org/2023/06/open-archieven-als-plugin-voor-chatgpt.html#comments Sat, 17 Jun 2023 14:18:31 +0000 https://blogbob.coret.org/?p=856 Diegenen die de OpenAI’s ChatGPT tool gebruiken cq. aan het uit proberen zijn én een abonnement hebben kunnen gebruik maken van plug-ins van derden. Als dienstaanbieder is het natuurlijk interessant om te kijken of je voor jou dienst een plugin kunt realiseren zodat ChatGPT deze kan gebruiken. Als experiment heb ik Open Archieven gekoppeld. Als...

Het bericht Open Archieven als plugin voor ChatGPT verscheen eerst op Blog Bob.

]]>
Diegenen die de OpenAI’s ChatGPT tool gebruiken cq. aan het uit proberen zijn én een abonnement hebben kunnen gebruik maken van plug-ins van derden. Als dienstaanbieder is het natuurlijk interessant om te kijken of je voor jou dienst een plugin kunt realiseren zodat ChatGPT deze kan gebruiken. Als experiment heb ik Open Archieven gekoppeld.

Als je platform open is en gebruik maakt van standaarden dan is de realisatie van de plugin zeer eenvoudig. Open Archieven, biedt diverse API‘s. Deze zijn beschreven op basis van de Open API specificatie in een online YAML bestand. Een ai-plugin.json bestand op je domein bevat de configuratie van je plugin, waarin het meest belangrijke de url van de Open API url is. Dit JSON bestand moet onder die naam geplaatst worden in de .well-known directory op je website zodat je aan ChatGPT alleen het domeinnaam hoeft op te geven (hier dus www.openarch.nl) en je kunt aan de slag (nu nog als developer, ik heb de plugin nog niet aangeboden om in de plugin-store te komen).

Door de YAML beschrijving van je API ‘weet’ de AI wanneer het welke vraag moet stellen. Hieronder enkele voorbeelden met hier en daar wat observaties.

Bij de eerste vraag heeft ChatGPT op de achtergrond het volgende request gedaan: https://api.openarch.nl/1.1/records/getBirths.json?name=Wilhelmus%20Coret De gestuctureerde JSON resultaten zijn dus in mooi Nederlands (want ik stelde de vraag in het Nederlands) omzet mét links naar de akten. Onverwacht werden er ook afbeeldingen en titels getoond van de aktes. Hiervoor zorgt een andere door Open Archieven gehanteerde standaard: Open Graph.

Het is een chat, dus je kunt doorvragen, bijvoorbeeld naar de bronnen. Alle akten uit de vorige vraag komen inderdaad van het Streekarchief Midden-Holland. Maar de uitleg over dit archief komt niet van de Open Archieven plugin, dat verzint ChatGPT er zelf aardig bij. Hetzelfde zie je gebeuren bij de vraag naar het brontype.

De weergave varieert, hieronder zijn de namen niet gelinkt maar bevat elke regel een “Link naar de akte”. Doordat ik in de prompt ook vroeg naar het archief, zie je dit netjes in het antwoord terug.

Bij Open Archieven (en dus ook via de API) kun je zoeken met wildcards. ChatGPT snapt dit en geeft aan de API “Hendr* Coret” mee via de name-parameter!

In de volgende vraag heeft ChatGPT goed gezien dat ik de getMarriages methode van de API wil aanroepen en dus twee namen als losse parameters (name1 en name2) meegegeven moeten worden in de API aanroep.

In de volgende vraag hebben de resultaten allemaal betrekking op Hendricus Wilhelmus Coret en is het dus logisch om de brontype (en archiefinstelling) op te sommen. Toch knap van ChatGPT.

Dat ChatGPT de volgende vraag heeft beantwoord vind ik erg knap. ChatGPT weet dat het geboorteakten kan opvragen en overlijdensakten. ChatGPT heeft begrepen dat het de leeftijd van de persoon moest berekenen (om de “hoe oud” vraag te beantwoorden) en daarvoor de (metadata van de) geboorteakte en de (metadata van de) overlijdensaktes moet ophalen (je ziet in de GUI dat er 2 requests naar Open Archieven zijn gedaan!!!) van de persoon en dan de twee datums van elkaar moet halen. ChatGPT is niet helemaal zeker van de zaak, het verwacht een hogere leeftijd. Het gaat hier echter om een jong overleden kind, dat inderdaad maar enkele maanden oud is geworden.

De resultaten van de API worden standaard gesorteerd op naam (en ik heb ChatGPT nog niet via de Open API YAML vertelt dat hier een parameter voor is). Maar in je prompt kun je natuurlijk iets over de volgorde opnemen. Ook kun je vragen de gegevens te “verrijken”, in dit geval met de weekdag (op basis van de datum). Van de 10 weekdagen is er (door handmatige controle via de Kalender omzetter) één incorrecte weekdag: 14 juni 1834 was een zaterdag (niet een vrijdag). Ook de sortering is niet perfect, 7. en 8. hadden omgekeerd moeten worden.

Bij de volgende vraag gaat ChatGPT de mist in. Ik vraag om de leeftijden van Goudse Coretten, dus ChatGPT gaat voor alle Coretten geboren in Gouda ook de overlijdensakten opvragen, maar zoals elke genealoog weet is puur ‘matchen’ echt niet genoeg. Vandaar in de tabel enkele personen ouder dan 100 jaar (en dat vindt ChatGPT niet raar?). De gevraagde gemiddelde leeftijd wordt niet geleverd.

Sommige van de API methodes vereisen dat er een specifieke GUID (en archive_code) van wordt opgegeven, normaliter uit een eerdere vraag. Ook dit lijkt ChatGPT te snappen, waardoor de vervolgvraag naar kinderen van een echtpaar ook (de goede request en) goede antwoord geeft.

Zou het ook in een diagram getoond kunnen worden?

Weer een vrij eenvoudige vraag, maar net weergegeven antwoord.

De resultaten kunnen ook in de genealogische defacto standaard GEDCOM gepresenteerd worden (niet geheel valide door ontbrekende header, 1 SOUR zou beter 2 SOUR moeten zijn):

De Open Archives plugin is zaterdagmiddag (17-6-2023) aangeboden aan ChatGPT. Op maandagmiddag is de plugin goedgekeurd en beschikbaar in de ChatGPT plugin store!

Het bericht Open Archieven als plugin voor ChatGPT verscheen eerst op Blog Bob.

]]>
https://blogbob.coret.org/2023/06/open-archieven-als-plugin-voor-chatgpt.html/feed 1
Real-world Face Restoration with GFPGAN, some examples https://blogbob.coret.org/2021/12/real-world-face-restoration-with-gfpgan-some-examples.html Tue, 14 Dec 2021 20:19:56 +0000 https://blogbob.coret.org/?p=835 GFPGAN aims at developing a Practical Algorithm for Real-world Face Restoration. It leverages rich and diverse priors encapsulated in a pretrained face GAN (e.g., StyleGAN2) for blind face restoration. I ran some photo’s from my personal collection thru this GFPGAN (CVPR 2021) algorithm. Below are the inputs and outputs can be compared.

Het bericht Real-world Face Restoration with GFPGAN, some examples verscheen eerst op Blog Bob.

]]>
GFPGAN aims at developing a Practical Algorithm for Real-world Face Restoration. It leverages rich and diverse priors encapsulated in a pretrained face GAN (e.g., StyleGAN2) for blind face restoration.

I ran some photo’s from my personal collection thru this GFPGAN (CVPR 2021) algorithm. Below are the inputs and outputs can be compared.

Het bericht Real-world Face Restoration with GFPGAN, some examples verscheen eerst op Blog Bob.

]]>
MAIS-MDWS probleem: links naar niet gekoppelde scans https://blogbob.coret.org/2020/12/mais-mdws-probleem-links-naar-niet-gekoppelde-scans.html Wed, 16 Dec 2020 00:21:43 +0000 https://blogbob.coret.org/?p=787 Onderstaand bericht is op 10 december 2020 aan Regionaal Archief Rivierenland en haar leverancier DE REE gestuurd: Ik constateer als gebruiker van de open data (A2A) bestanden van het RAR dat sommige records aan de verkeerde scan zijn gekoppeld. Het gaat dan om records die nog niet aan een scan zijn gekoppeld maar aan een gescand...

Het bericht MAIS-MDWS probleem: links naar niet gekoppelde scans verscheen eerst op Blog Bob.

]]>
Onderstaand bericht is op 10 december 2020 aan Regionaal Archief Rivierenland en haar leverancier DE REE gestuurd:

Ik constateer als gebruiker van de open data (A2A) bestanden van het RAR dat sommige records aan de verkeerde scan zijn gekoppeld. Het gaat dan om records die nog niet aan een scan zijn gekoppeld maar aan een gescand register, zoals bijvoorbeeld https://hdl.handle.net/21.12108/CA6781621885418C847F81645ED7831C

In het voor dit record gegenereerde A2A (zie hieronder) wordt er in <a2a:SourceAvailableScans> blok een link gelegd naar de eerste scan in het register, in dit geval de kaft van het register… Dit is niet goed. Gebruikers van deze data, waaronder Open Archieven, sturen hun bezoekers nu dus naar de verkeerde scan!

Bij records die niet zijn gekoppeld aan specifieke scans, maar een geheel register van scans is het beter om geen link naar https://proxy.archieven.nl/embed/102/.. te maken maar naar de “viewer met strip” (in dit voorbeeld https://regionaalarchiefrivierenland.nl/maisi_ajax_proxy.php?…).

Ook kunnen de <a2a:Uri> (de link om de scan te downloaden) en <a2a:UriPreview> (een kleine weergave van de scan) denk ik beter achterwege blijven (zijn geen verplicht op te namen waarden!).

Uit NL-TlRAR:0010-1851:54:A2A.xml : 
[...]
 <a2a:SourceAvailableScans>
  <a2a:Scan>
   <a2a:OrderSequenceNumber>1</a2a:OrderSequenceNumber>
<a2a:Uri>https://proxy.archieven.nl/download/102/41662F0A1A98430AA6D75B300D175FEC</a2a:Uri>
<a2a:UriViewer>https://proxy.archieven.nl/embed/102/41662F0A1A98430AA6D75B300D175FEC</a2a:UriViewer>
<a2a:UriPreview>https://proxy.archieven.nl/thumb/102/41662F0A1A98430AA6D75B300D175FEC</a2a:UriPreview>

   </a2a:Scan>
  </a2a:SourceAvailableScans>
<a2a:SourceDigitalOriginal>https://hdl.handle.net/21.12108/CA6781621885418C847F81645ED7831C</a2a:SourceDigitalOriginal>
  <a2a:RecordIdentifier>1982461304</a2a:RecordIdentifier>
  <a2a:RecordGUID>{CA678162-1885-418C-847F-81645ED7831C}</a2a:RecordGUID>
 </a2a:Source>
</a2a:A2A>

Het antwoord van de leverancier:

Archieven.nl is een verzameling van verschillende archiefdiensten en collectiebeherende instellingen. Wij hosten de database en zorgen ervoor dat de aangeboden informatie beschikbaar is en gevonden kan worden door u.

De inhoud van de database wordt gevuld en beheerd door de archiefdiensten en collectiebeherende instellingen.

Vragen met betrekking tot bepaalde collecties kunnen daarom alleen beantwoord worden door de organisatie welke de informatie aanbiedt.

Het Regionaal Archief Rivierenland (http://www.regionaalarchiefrivierenland.nl/ ) kan u waarschijnlijk verder helpen.

Jammer!

Niet alleen hoe DE REE de website archieven.nl presenteert (als verzameling van organisaties?) maar vooral hun beperkte rol hierin. Niet alleen wordt het probleem niet begrepen, ze verwijzen doodleuk door naar hun klant.

Onterecht. Ik hoop dat deze blogpost de leverancier aanzet om meer hun verantwoordelijkheid te nemen. Ik hoop dat DE REE het probleem gaat begrijpen (hieronder nog extra voorbeelden) en hun product zal verbeteren.

Want het issue ligt toch echt meer bij MAIS-MDWS dan bij hun klanten: wanneer een record niet aan scan van een akte is gekoppeld maar aan een gescand register, dan moet de data in A2A XML niet koppelen aan de eerste scan uit het gescande register! Hooguit koppel je aan de viewer die het gehele gescande register toont (en dus niet de viewer die alleen één scan toont zoals in de voorbeelden, want dat is onjuist).

De A2A XML is een weerslag van de data van archiefinstellingen. Er is een mapping van data in het gesloten, niet-standaard MAIS formaat naar de open standaard A2A. Of de leverancier of de archiefinstelling deze mapping maakt is niet belangrijk, een systeem moet niet de mogelijkheid bieden om een mapping te definiëren er koppelingen naar scans worden opgeleverd die niet bestaan (omdat er (nog) geen koppeling is).

Nog wat voorbeelden bij andere archieforganisaties…

Een doopinschrijving (op Open Archieven) waarbij in het open data bestand van Regionaal Archief Dordrecht in het <a2a_SourceAvailableScans> blok staat:

<a2a:Scan>
<a2a:Uri>https://proxy.archieven.nl/46/6C38CD4707394F469F4BFED8349E5D81</a2a:Uri> <a2a:UriViewer>https://proxy.archieven.nl/46/6C38CD4707394F469F4BFED8349E5D81</a2a:UriViewer> <a2a:UriPreview>https://proxy.archieven.nl/thumb/46/6C38CD4707394F469F4BFED8349E5D81</a2a:UriPreview>
</a2a:Scan>

Bekijk je deze doopinschrijving (op de website van de archiefinstelling) dan zie je dat deze akte niet is gekoppeld aan een scan, maar een gescand register. Je kunt dan dus niet de doopinschrijving aan de eerste scan uit de reeks koppelen!

Op bovenstaande scan moet een doopinschrijving (op Open Archieven) staan volgens de A2A afkomstig van het Stadsarchief Rotterdam:

<a2a:Scan>
<a2a:Uri>https://hdl.handle.net/21.12133/B54B52BFAFA747099AF03A5FEA17744E</a2a:Uri><a2a:UriViewer>https://hdl.handle.net/21.12133/B54B52BFAFA747099AF03A5FEA17744E</a2a:UriViewer><a2a:UriPreview>https://proxy.archieven.nl/thumb/184/B54B52BFAFA747099AF03A5FEA17744E</a2a:UriPreview>
</a2a:Scan>

Op de website van Stadsarchief Rotterdam wordt er bij deze doopinschrijving een reeks scans getoond. Niet omdat de doopinschrijving meerdere pagina’s beslaat, maar omdat de scan is gekoppeld aan de gehele reeks scans van het betreffende doopboek.

Valt er op bovenstaande scan een huwelijksakte (op Open Archieven) te ontdekken? De XML in A2A formaat, ontvangen van Streekarchief Voorne-Putten, suggereert dit:

<a2a:Scan>
<a2a:Uri>https://proxy.archieven.nl/126/6B4EA98A5D6AE3C8E053600410AC5B3E</a2a:Uri><a2a:UriViewer>https://proxy.archieven.nl/126/6B4EA98A5D6AE3C8E053600410AC5B3E</a2a:UriViewer><a2a:UriPreview>https://proxy.archieven.nl/thumb/126/6B4EA98A5D6AE3C8E053600410AC5B3E</a2a:UriPreview>
</a2a:Scan>

Helaas, ook deze huwelijksakte (op website archiefinstelling) is door het Streekarchief (nog) niet gekoppeld aan een scan maar een register. Toch geeft het XML record een link naar een scan, inderdaad de eerste pagina…

Hierboven een mooie scan (als lezer begint u wellicht een patroon te zien) van een doopinschrijving (op Open Archieven) uit het Doop-, trouw- en begraafboek van Mierlo. In de door Regionaal Historisch Centrum Eindhoven beschikbare open data bestanden lezen we:

<a2a:Scan>
<a2a:Uri>http://www.archieven.nl/mi/48/?mivast=48&miadt=48&miaet=54&micode=DTB_Mierlo_10225_65.1&minr=17591801&miview=ldt</a2a:Uri><a2a:UriViewer>http://www.archieven.nl/mi/48/?mivast=48&miadt=48&miaet=54&micode=DTB_Mierlo_10225_65.1&minr=17591801&miview=ldt</a2a:UriViewer><a2a:UriPreview>http://files.archieven.nl/php/get_thumb.php?adt_id=48&toegang=10225&file=65.1\00000_D_Mierlo_65.1_00t1.jpg</a2a:UriPreview>
</a2a:Scan>

Inderdaad, de doopinschrijving (op website archiefinstelling) is ook hier gekoppeld aan de eerste scan uit een reeks scans van het doopboek.

Bonus

Een voorbeeld waar het ook andersom mis kan gaan (NB: dit betreft dus ander MDWS probleem!). Hieronder een scan uit de bevolkingsregistratie Waverveen en Waveren, archief 1202, inventaris­num­mer 408.

De door Regionaal Historisch Centrum Vecht en Venen geleverde A2A van de registratie (op Open Archieven) ziet er als volgt uit:

<a2a:Scan>
<a2a:Uri>http://www.rhcvechtenvenen.nl/collectie?mivast=386&miadt=386&miaet=54&micode=1202-408&minr=970705&miview=ldt</a2a:Uri><a2a:UriViewer>http://www.rhcvechtenvenen.nl/collectie?mivast=386&miadt=386&miaet=54&micode=1202-408&minr=970705&miview=ldt</a2a:UriViewer><a2a:UriPreview>http://files.archieven.nl/php/get_thumb.php?adt_id=386&toegang=1202&file=408\1202_0408_0012.jpg</a2a:UriPreview>
</a2a:Scan>

Wordt de registratie bekeken op de website van de archiefinstelling dan zien we een strip van scans, maar is niet zichtbaar welke scan de juiste is (blijkt nummer 14 te zijn)?!

Dit is dus een voorbeeld van een “record” dat wel is gekoppeld aan een scan, de juiste scan, en dit ook in A2A XML correct wordt weergegeven, maar op de eigen website (en dus ook archieven.nl) wordt de gekoppelde scan niet getoond…

Ik kan aankloppen bij het RHC, maar ook hier lijkt mij DE REE aan zet.

Het bericht MAIS-MDWS probleem: links naar niet gekoppelde scans verscheen eerst op Blog Bob.

]]>
Koppelen en gebruiken van thesaurustermen bij de Rotterdamse arrestantenkaarten https://blogbob.coret.org/2020/06/koppelen-en-gebruiken-van-thesaurustermen-bij-de-rotterdamse-arrestantenkaarten.html Wed, 03 Jun 2020 22:46:37 +0000 https://blogbob.coret.org/?p=746 Erfgoedinstellingen complementeren de meta-data over objecten en collecties meer en meer met termen uit gemeenschappelijke termenlijsten. Voorbeelden hiervan zijn RKD Artists, de Gemeenschappelijke Thesaurus voor Audiovisuele Archieven (GTAA), de Erfgoedthesaurus, Iconclass en Geonames. Bij het verwerken van de open data van Stadsarchief Rotterdam (een export vanuit MAIS-Flexis) liep Open Archieven aan tegen een nieuw data-element...

Het bericht Koppelen en gebruiken van thesaurustermen bij de Rotterdamse arrestantenkaarten verscheen eerst op Blog Bob.

]]>
Erfgoedinstellingen complementeren de meta-data over objecten en collecties meer en meer met termen uit gemeenschappelijke termenlijsten. Voorbeelden hiervan zijn RKD Artists, de Gemeenschappelijke Thesaurus voor Audiovisuele Archieven (GTAA), de Erfgoedthesaurus, Iconclass en Geonames.

Bij het verwerken van de open data van Stadsarchief Rotterdam (een export vanuit MAIS-Flexis) liep Open Archieven aan tegen een nieuw data-element aan dat Open Archieven nog niet eerder verwerkte: thesaurusterm.

De bron waar Open Archieven dit data-element tegen kwam betrof arrestantenkaarten uit de periode 1940-1944 (Stadsarchief Rotterdam, archief 63 Archief van de Gemeentepolitie Rotterdam, inventarisnummer 3470). Deze nadere toegang is tot stand gekomen in samenwerking met de crowd en Netwerk Oorlogsbronnen. De laatste heeft hier onder andere de verrijking met thesaurustermen uit de WO2-thesaurus voor haar rekening genomen.

Martin Kapfer, Gearresteerd op: 13-11-1940

In deze blogpost wil ik kijken naar het resultaat van het termen koppelen en de presentatie van termen. Het is een weerslag van het gedachtenproces om te bepalen wat Open Archieven als hergebruiker met deze termen doet.


De records met meta-data over de arrestantenkaarten bevatten in 13 van de 139 gevallen (=9%) een veld ‘Thesaurusterm’ met daarin een URI als waarde. De URI’s verwijzen naar termen uit de – door het NIOD beheerde – WO2-thesaurus:

De WO2-thesaurus is een gevalideerde, hiërarchisch georganiseerde trefwoordenlijst voor de thematische ontsluiting van (digitale) bronnen uit en over de Tweede Wereldoorlog. De thesaurus bevat bijna 2300 termen over gebeurtenissen, plaatsen, begrippen en objecten.

Als je het XML bestand bekijkt, dan lijkt het er sterk op dat de matching heeft plaatsgevonden op waardes in het veld ‘In bewaring voor’. Dat de thesaurusterm op dit veld slaat, wordt overigens verder nergens gedocumenteerd (jammer, is een belangrijk stukje provenance informatie).

Andere velden die voorzien zouden kunnen worden van termen – uit de WO2-thesaurus of andere thesauri – omvatten de plaatsnamen (in velden ‘Geboorteplaats’, ‘Overlijdensplaats’, ‘Adres’ en ‘Getransporteerd naar’) en beroep (in veld ‘Beroep’). Daar is klaarblijkelijk niet voor gekozen, ben benieuwd naar de overwegingen in deze.

De XML laat wel zien, dat elke arrestantenkaart ook trefwoorden heeft: voor plaatsnaam en straatnaam (en de WO2-thesaurus term in tekstvorm). Deze trefwoorden zijn vermoedelijk geëxtraheerd uit specifieke velden, ze komen niet uit een gemeenschappelijk termenlijsten en hebben geen URI. Dit zijn strings, geen links. Voor het verbinden van data, over instellingen heen, is dit een drempel.

Wat opvalt bij het plaatsnaam trefwoord is dat hier een keuze gemaakt is: niet de geboorteplaats of plaats waarheen getransporteerd (waar af en toe een kampnaam voorkomt), maar (alleen) de woonplaats wordt als plaats trefwoord gezien. Ook hier ben ik benieuwd naar de overwegingen.

<record type=”Arrestantenkaart”>
    <recorditems>
      <item label=””>Rients Kamstra, Gearresteerd op: 16-05-1940</item>
      <item label=”beginjaar”>1940</item>
      <item label=”eindjaar”>1940</item>
      <item label=”GUID”>{B27A24E2-5242-4F38-9D35-21802CC9DF4C}</item>
      <item label=”Inventarisnummer”>3470</item>
      <item label=”Toegangsnummer”>63</item>
      <item label=”Voornaam”>Rients</item>
      <item label=”Achternaam”>Kamstra</item>
      <item label=”Geboortedatum”>24-9-1882</item>
      <item label=”Geboorteplaats”>Franeker</item>
      <item label=”Beroep”>koopman</item>
      <item label=”Nationaliteit”>Nederlandse</item>
      <item label=”Datum in bewaring”>16-05-1940</item>
      <item label=”In bewaring voor”>Duitse militairen</item>
      <item label=”Datum getransporteerd”>16-05-1940</item>
      <item label=”Getransporteerd naar”>Münster, Duitsland</item>
      <item label=”Reden in bewaring”>Spionnage</item>
      <item label=”Registratienummer”>1</item>
      <item label=”Thesaurusterm”>https://data.niod.nl/WO2_Thesaurus/1880</item>
      <item label=”Adres”>Rotterdam, Prinses Julianalaan 96</item>
      <trefwoord label=”Trefwoorden”>Militairen</trefwoord>
      <trefwoord label=”PLAATSNAAM”>Rotterdam</trefwoord>
      <trefwoord label=”STRAATNAAM”>Prinses Julianalaan</trefwoord>
      <bron label=””>https://stadsarchief.rotterdam.nl/zoek-en-ontdek/archieven/zoekrestultaat-archieven/?mivast=184&miadt=184&miaet=54&micode=63.3470&minr=45122298&miview=ldt</bron>
    </recorditems>
</record>

Wat bovenstaand stuk XML wel mooi laat zien is, dat de ingevoerde (of geïmporteerde) thesaurusterm URI ook in de export aanwezig is. Het ‘label’ van de thesaurusterm lijkt opgenomen als trefwoord (als string). De aanwezigheid van de thesaurusterm URI betekent dat hergebruikers deze waarde ook kunnen gebruiken als ze willen. Een keuze waar dus ook Open Archieven voor staat.

Hieronder staan de 13 voorkomens van ‘In bewaring voor’ in het bekeken XML bestand en de toegevoegde match in de vorm van URI en thesaurusterm:

‘In bewaring voor’ waardeAantal voorkomensThesaurusterm URITerm
1.Justitie Dienst I2https://data.niod.nl/WO2_Thesaurus/2601Justitie
2.Geheim Feld Politie3https://data.niod.nl/WO2_Thesaurus/2715Politie
3.Marine Havenabteilung6https://data.niod.nl/WO2_Thesaurus/3509Havens
4.Wehrmacht1https://data.niod.nl/WO2_Thesaurus/3585Wehrmacht
5.Duitse militairen1https://data.niod.nl/WO2_Thesaurus/1880Militairen

De matches zijn “zijn geautomatiseerde matches dmv linkstrategie met concepten uit de WO2-thesaurus“. Als je naar de 5 matches kijkt in bovenstaande tabel kijkt, dan lijkt alleen nummer 4 te gaan over exact hetzelfde begrip. Bij de 4 anderen is er een match, puur omdat de karakters waar de term (waarschijnlijk het prefLabel) uit is opgebouwd, voorkomen in het ‘In bewaring voor’ veld. Een substring match, als een proxy voor een semantische match? Bij nummers 2 en 5 zou je kunnen zeggen dat het een algemenere term is. Maar bij nummer 1 wordt een organisatorische eenheid gelijk gesteld met het concept justitie (als rechterlijke macht). En bij nummer 3 wordt een organisatorisch eenheid gekoppeld aan het concept havens.

Als je kijkt naar andere ‘In bewaring voor’ waarden dan zijn er 2 die wel nuttig gekoppeld hadden kunnen worden (maar: ik ben geen specialist op dit terrein), maar door de gebruikte strategie niet zijn gevonden:

Dit leidt bij mij tot vragen als:

  • is substring matching de juiste strategie om overeenkomsten te vinden van begrippen?
  • kan de matching niet beter plaatsvinden op een specifieke ’tak’ uit de hiërarchische termenlijst die beter aansluit bij het veld waarop wordt gematched (in dit geval bijvoorbeeld corporaties)?
  • worden ook alternatieve labels betrokken in de matching?
  • kan het matchen van thesaurustermen wel volledig geautomatiseerd worden, oftewel is de kwaliteit en kwantiteit hoog genoeg?

We zien hier overigens een voorbeeld waar een erfgoedinstelling de eigen meta-data verrijkt met behulp van derden. Goed! Of dit nu een overheidsorganisatie is, de crowd of een ZZP-er die met data kan toveren, de erfgoedinstelling moet wel altijd alert blijven op de kwaliteit. Deels door zicht te hebben op het proces waarmee de verrijking tot stand is gekomen (bijvoorbeeld dubbele invoer bij crowdsourcing, informatie over wijze van matching, opschoning van data, gemaakte keuzes) en deels door steeksproefsgewijs de kwaliteit te controleren.

Voor Open Archieven heeft bovenstaande beschouwing geleid tot de beslissing om de thesaurustermen in deze bron nog even niet te gebruiken of te tonen.

In het algemeen gesproken kunnen thesaurustermen die zijn toegevoegd aan de objecten ook van waarde zijn voor eindgebruikers. Op de website van het Stadsarchief Rotterdam wordt nu echter alleen de URI van de thesaurusterm getoond:

Gebruikers die weten wat een ‘Thesaurusterm’ inhoudt (zal maar een klein deel zijn) en de link volgen, komen terecht in de WO2-thesaurus. Deze is opgezet met behulp van PoolParty. Een goede tool voor thesauri beheerders, maar niet echt gericht op eindgebruikers…

Bovenstaande afbeelding toont ook dat de trefwoorden op de website getoond worden. Wanneer er op het trefwoord geklikt wordt, dan wordt de gehele archiefcollectie doorzocht op objecten die ook zijn voorzien van het betreffende trefwoord. Een functie die, als het kwalitatieve trefwoorden zijn, zeker nut heeft.

Om nog even terug te komen bij de Thesaurusterm. Stel je eens voor dat de ‘In bewaring voor’ waarde (waar de thesaurusterm immers op slaat in dit record) wordt voorzien van een (i) symbool, die, wanneer je deze aanklikt, de beschrijving van de term (uit de thesaurus) toont:

Daar help je de eindgebruiker mee! Dan zet je de gebruiker centraal.

NB: bovenstaande presentatie gaat er wel vanuit dat er een definitie is van de term. Helaas hebben niet alle termen in de WO2-thesaurus een definitie of scopeNote. Van de 5 termen in bovenstaande tabel hebben er maar 2 een scopeNote.

Tenslotte, bovenstaande moet niet gelezen worden als kritiek op het gebruik van thesauri. Ik zie bovenstaande als een experiment dat het Stadsarchief Rotterdam heeft uitgevoerd waar lessen uit getrokken kunnen worden. Het gebruik van thesaurustermen en URI’s kunnen van grote waarde zijn voor eindgebruikers en om objecten en collecties te koppelen in het tijdperk van linked open data.

Het bericht Koppelen en gebruiken van thesaurustermen bij de Rotterdamse arrestantenkaarten verscheen eerst op Blog Bob.

]]>
Open data (portals), de stand van zaken in de archiefsector (1) https://blogbob.coret.org/2020/05/open-data-portals-de-stand-van-zaken-in-de-archiefsector-1.html Tue, 05 May 2020 18:03:16 +0000 https://blogbob.coret.org/?p=688 In een reeks blogposts wordt er gekeken naar de stand van zaken van open data in de archiefsector. De open data wordt op verschillende wijzen aangeboden, dit is in grote mate afhankelijk van de software (en dus leverancier) die de archiefinstelling gebruikt. In deze blogpost staat de open data centraal die wordt geboden door archiefinstellingen...

Het bericht Open data (portals), de stand van zaken in de archiefsector (1) verscheen eerst op Blog Bob.

]]>
In een reeks blogposts wordt er gekeken naar de stand van zaken van open data in de archiefsector. De open data wordt op verschillende wijzen aangeboden, dit is in grote mate afhankelijk van de software (en dus leverancier) die de archiefinstelling gebruikt. In deze blogpost staat de open data centraal die wordt geboden door archiefinstellingen die de “open data portal” van De Ree gebruiken.

Aggregator

Open Archieven maakt de historische persoonsvermeldingen in akten van Nederlandse en Belgische archiefinstellingen doorzoekbaar. Met 219 miljoen historische persoonsvermeldingen is Open Archieven de grootste doorzoekbare database.

Open Archieven draait op de door archiefinstellingen (of vrijwilligers) beschikbaar gestelde open data. Open Archieven is hiermee ook een van de grotere (particuliere) aggregatoren.

Er is voor het “open data portaal” van De Ree een specifieke crawler en processor gemaakt. Dit was nodig omdat De Ree geen API biedt en er dus HTML gescraped moet worden en custom AJAX requests moeten worden gedaan. De crawler identificeert zich (qua user agent) als OA-ANL-Harvester en kent twee fasen. Allereerst wordt alle metadata van de open data bestanden opgehaald. Er wordt hiermee een lokale data catalogus opgebouwd per archiefinstelling. In een tweede fase worden – op basis van de data catalogus – nieuwe en bijgewerkte bestanden daadwerkelijk gedownload zodat deze verwerkt kunnen worden door Open Archieven.

Door de opzet van het “open data portaal” van De Ree moeten er een groot aantal requests worden gedaan om de gewenste metadata (zoals datum laatste wijziging van het bestand) te verkrijgen. Eén request per 20 bestanden en één request voor elke bestand. Om de infrastructuur van De Ree niet te veel te belasten, wordt er na elke request een halve seconde gewacht. Het opbouwen van de complete datacatalogus voor de ruim 127 duizend bestanden van 22 archiefinstellingen (wat dus nodig is om te controleren of er nieuwe of bijgewerkte bestanden zijn) duurt ruim 17 uur!

Kwantiteit

ArchiefinstellingAantalMegabytesDeel
Gelders Archief10.37225.40620,5%
Stadsarchief Rotterdam6.80823.71719,1%
Het Utrechts Archief33.40019.12515,4%
Zeeuws Archief42.60613.13010,6%
RHC Eindhoven5.1548.9197,2%
Haags Gemeentetarchief2.9757.7876,3%
Noord-Hollands Archief6.0054.4783,6%
Regionaal Archief Dordrecht2.5744.1103,3%
Regionaal Archief Rivierenland4.0483.6422,9%
Erfgoedcentrum Achterhoek Liemers2.4273.5252,8%
Westfries Archief2.8032.6992,2%
Streefarchief Voorne-Putten9181.8581,5%
Gemeentearchief Zaanstad1.7041.4001,1%
Regionaal Historisch Centrum Vecht en Venen1.0721.3691,1%
Groninger Archieven2.5605610,5%
Rijckheyt4095220,4%
Gemeentearchief Roermond1815170,4%
Gemeente Steenwijkerland2593640,3%
Het Flevolands Archief6383360,3%
Gemeentearchief Alphen aan den Rijn1962160,2%
Gemeente Kerkrade1351860,2%
Archief De Domijnen Sittard-Geleen 21180,0%
127.265 123.885
Aantallen en totale bestandsgrootte open data bestanden per archiefinstelling

Het achterhalen welke van de 87 op archieven.nl publicerende archiefinstellingen ook open data bieden is niet eenvoudig op te vragen. Ook hier geen auto-discovery maar hand- en giswerk.

Van deze 87 archiefinstellingen zijn er 22 die open data bieden, dat is krap een kwart. Als je naar genealogische data kijkt dan zijn er nog 15 archiefinstellingen die wel historische persoonsgegevens via archieven.nl bieden maar dit niet als open data beschikbaar stellen. Hiervan bieden 4 archieforganisaties hun data aan via de oplossing van Picturae. De overige 11 gebruiken geen open data portal:Gemeentearchief Hardenberg, Gemeentearchief Hulst, Gemeentearchief Zeist, Historisch Centrum Leeuwarden, Regionaal Historisch Centrum Limburg, Stadsarchief Deventer, Stadsarchief Kampen, Streekarchief Noordwest-Veluwe, het Nederlands Instituut voor Militaire Historie en Historisch Centrum Overijssel.

Als je ook naar de andere datasoorten kijkt, zoals inventarissen en beeldbanken dan is er een nog groter aantal archiefinstellingen die wel data heeft maar dit niet via het “open data portal” van De Ree beschikbaar stelt voor hergebruik.

In totaal is er 123,9 GB aan open data bestanden gedownload. Helaas wordt er door De Ree geen compressie toegepast. Vreemd, want als er compressie wordt toegepast – bijvoorbeeld Gzip of Brotli – hetgeen een zeer eenvoudige configuratie in een webserver betreft, dan zou er slechts 4,42 GB aan open data bestanden hoeven worden gedownload. Een besparing (en snelheidsverbetering) die voor alle gebruikers van archieven.nl zou gelden.

De 22 archiefinstellingen bieden samen 127.265 open data bestanden aan. Helaas is de toegang hierop vooral op mensen gericht (veel klikken…). Hopelijk komt ook de machine in beeld als gebruiker. Wanneer de bestanden en metadata (datasets en dataset beschrijvingen) een meer gestandaardiseerde toegang krijgen verlaagd dit de drempel tot hergebruik.

BeschikbaarheidAantalDeel
Bestand beschikbaar126.407 99,3%
Nog niet beschikbaar8580,7%
Beschikbaarheid van bestanden zoals gerapporeerd door het open data portal

Een klein deel van de bestanden in de open data portals van de archiefinstellingen hebben als status “nog niet beschikbaar”. Veelal worden de open data bestanden door De Ree in het weekend gegenereerd. Er kan dus wat tijd zitten tussen het aanwijzen van een open data bestand door de archiefmedewerker en het daadwerkelijk beschikbaar komen van het bestand. De vraag dringt zich op het er genoeg tijd in het weekend is om bestanden te genereren (nieuw of update). Ook doordeweeks is er genoeg tijd dat het gebruik van de website gepaard kan gaan met de verwerking van de bestanden. Archiefinstellingen wordt aangeraden om deze “nog niet beschikbaar” bestanden geregeld te controleren. Het kan ook een teken zijn dat er iets mis is gegaan bij het genereren van het open data bestand.

Kwaliteit

LicentieAantalDeel
CC0 1.0107.58184,5%
CC BY-SA 4.017.55713,8%
CC BY 4.02.1231,7%
PDM 1.040,0%
Aan de beschikbaar gestelde bestanden toegekende licenties

We hebben het hier over open data. Dit betekent dat de data voor hergebruik beschikbaar wordt gesteld onder een vrij licentie. Het overgrote deel van de bestanden is door archiefinstellingen beschikbaar gesteld onder een CC0 publiek domein verklaring. Ook worden CC BY-SA en CC BY gebruikt, hieraan worden wat meer voorwaarden gesteld bij hergebruik (waaronder naamsvermelding en gelijk delen).

FormaatAantalDeel
A2A101.98880,7%
MI12.78910,1%
EAD11.5599,1%
DC690,1%
Aantallen bestanden per gebruikt dataformaat

Binnen de beschikbaar gestelde bestanden worden verschillende dataformaten gebruikt. Opmerkelijk is dat bij 1 op de 10 bestanden niet gebruik is gemaakt van een open standaard (als A2A en EAD) maar een proprietary formaat. Het ‘MI’ formaat, gemaakt door De Ree, is niet beschreven en open. Hergebruik van deze bestanden vereist reverse-engineering en een boel giswerk wat niet veel hergebruikers zullen opbrengen.

SoortAantalDeel
genealogie113.31189,0%
inventaris12.2409,6%
archief9900,8%
sys_ovr7030,6%
beeldmateriaal130,0%
museum40,0%
bibliotheek20,0%
diversen10,0%
bouwdossiers10,0%

Er worden verschillende soorten data ter beschikking gesteld. Het grootste gedeelte betreft nadere toegangen op akten, oftewel genealogie, gevolgd door inventarissen. Ik verwacht dat de groei de komende jaren vooral in de andere data soorten zal zitten.

StatusAantalDeel
Valide inhoud125.82399,5%
Invalide A2A inhoud5220,4%
Bestand niet gevonden630,0%
Genealogie bestand aangeboden in verkeerd formaat (EAD i.p.v. A2A)50,0%
Status van de beschikbaar gestelde open data bestanden

Als aggregator is Open Archieven gebaat bij beschikbare én valide bestanden. De validiteit van bestanden wordt in twee stappen gecontroleerd. Een eerste controle vindt plaats direct na download: hier wordt gecontroleerd of het bestand daadwerkelijk beschikbaar is en (bij A2A bestanden) of er überhaupt A2A in voorkomt of dat het bestand alleen waarschuwingen bevat. Dit laatste gebeurd als er voor een brontype geen mapping is gedefinieerd naar A2A.

Gevonden problemen – bestand niet gevonden / nog niet beschikbaar / ongeldige A2A – worden via het openbare dashboard op Open Archieven getoond. Elke archiefinstelling krijgt hier een een overzicht van bestanden met problemen waarmee ze aan de slag kunnen. Zo nu en dan worden archiefinstellingen hier via e-mail nog eens op gewezen.

Bij het inlezen van de data door Open Archieven vindt de tweede controle plaats, dan wordt de syntax van elk A2A record gecontroleerd (op basis van de A2A XSD). Dit geldt ook voor de MI-bestanden, die door Open Archieven worden omgezet in A2A formaat.

JaarAantalDeel
201612.5559,9%
201727.18921,5%
201851.63940,8%
201920.16415,9%
202014.86111,8%
Jaar waarin het bestand voor het laatst is bijgewerkt.

De actualiteit van de bestanden valt moeilijk te beoordelen. Zo’n 31% van de bestanden is voor het laatst bijgewerkt in vóór 2018. Gezien het aantal foutmeldingen dat via Open Archieven aan de archiefinstellingen wordt gestuurd lijkt het toch wel aannemelijk dat er vaker bijgewerkte bestanden beschikbaar moeten komen. In hoeverre de software van De Ree hiervoor zorgt of dat er een handeling van een archiefmedewerker nodig is, is onbekend.

Conclusie

Het “open data portaal” van De Ree is een softwarecomponent dat niet is gericht op hergebruikers en machines (=de doelgroep van open data). Doordat open data portalen per archiefinstelling en daarbinnen de metadata per bestand niet volgens semantische standaarden zijn opgezet, blijft het harvesten van de (ongecomprimeerde) open data een grote, tijdrovende uitdaging. Dit vormt een zeer hoge drempel, waardoor de open data van de archiefinstellingen veel minder hergebruikt zullen worden.

Via het “open data portaal” bieden 22 archiefinstellingen samen 127.265 open data bestanden aan, mooi! Het overgrote deel hiervan is volgens een open standaard, beschikbaar en zonder problemen. Aandacht blijft nodig om de laatste 10% aan gesloten MI formaat data om te zetten in een open standaard. Archiefinstellingen worden aangemoedigd om de problemen met hun open data bestanden op te lossen.

Het “open data portaal” is nog niet bij alle archiefinstellingen die De Ree als haar klant mag rekenen in gebruik. Een deel van de archiefinstellingen stelt haar data op andere wijze beschikbaar, zoals het open data portaal van Picturae of door het exporteren vanuit MAIS-Flexis en e-mail van de data. Blijft toch een groot aantal archiefinstellingen over die nog niet open zijn.

Het bericht Open data (portals), de stand van zaken in de archiefsector (1) verscheen eerst op Blog Bob.

]]>
Nederlandse GEDCOM afspraken – doop https://blogbob.coret.org/2020/02/nederlandse-gedcom-afspraken-doop.html Fri, 07 Feb 2020 11:13:30 +0000 https://blogbob.coret.org/?p=683 Dit artikel is onderdeel van de blogpost Nederlandse GEDCOM afspraken en heeft als focus de gebeurtenis doop. Ik hoor graag wat de diverse stamboomprogramma’s en genealogische diensten hier mee doen qua invoer (en GUI) en GEDCOM export (en import). Het “probleem” wordt beschreven en er wordt een suggestie gedaan voor een “oplossing” om de discussie...

Het bericht Nederlandse GEDCOM afspraken – doop verscheen eerst op Blog Bob.

]]>
Dit artikel is onderdeel van de blogpost Nederlandse GEDCOM afspraken en heeft als focus de gebeurtenis doop. Ik hoor graag wat de diverse stamboomprogramma’s en genealogische diensten hier mee doen qua invoer (en GUI) en GEDCOM export (en import). Het “probleem” wordt beschreven en er wordt een suggestie gedaan voor een “oplossing” om de discussie aan te zwengelen. Ik hoop dat er een gedragen Nederlandse GEDCOM afspraken set uit voortvloeit.

Doop

In de GEDCOM specificatie zijn twee INDIVIDUAL_EVENT_STRUCTUREs gedefinieerd voor een doop: CHR en BAPM. Het CHR subrecord beschrijft “the religious event of baptizing and/or naming a child”. Het BAPM subrecord beschrijft “the event of baptism”.

Een christening (of: “infant baptism”) vindt plaats bij een kind. Een baptism kan gedurende het leven plaatsvinden. De dopen die voorkomen in de DTB zijn voornamelijk dopen ter naamgeving en vinden plaats kort na de geboorte. Het gebruik van CHR lijkt dus meer voor de hand te liggen.

Het probleem ligt in het feit dat diverse internationale stamboomprogramma’s beide gebeurtenissen (CHR en BAPM) vertalen als doop waardoor gebruikers een “verkeerde” doop kiezen. Hierdoor komen dopen in de GEDCOM’s als CHR en BAPM terecht.

Nederlandse programma’s lijken met name CHR te gebruiken.

Het bericht Nederlandse GEDCOM afspraken – doop verscheen eerst op Blog Bob.

]]>
Nederlandse GEDCOM afspraken – roepnaam https://blogbob.coret.org/2020/01/nederlandse-gedcom-afspraken-roepnaam.html https://blogbob.coret.org/2020/01/nederlandse-gedcom-afspraken-roepnaam.html#comments Mon, 13 Jan 2020 10:08:40 +0000 https://blogbob.coret.org/?p=650 Dit artikel is onderdeel van de blogpost Nederlandse GEDCOM afspraken en heeft als focus de roepnaam. Ik hoor graag wat de diverse stamboomprogramma’s en genealogische diensten hier mee doen qua invoer (en GUI) en GEDCOM export (en import). Het “probleem” wordt beschreven en er wordt een suggestie gedaan voor een “oplossing” om de discussie aan...

Het bericht Nederlandse GEDCOM afspraken – roepnaam verscheen eerst op Blog Bob.

]]>
Dit artikel is onderdeel van de blogpost Nederlandse GEDCOM afspraken en heeft als focus de roepnaam. Ik hoor graag wat de diverse stamboomprogramma’s en genealogische diensten hier mee doen qua invoer (en GUI) en GEDCOM export (en import). Het “probleem” wordt beschreven en er wordt een suggestie gedaan voor een “oplossing” om de discussie aan te zwengelen. Ik hoop dat er een gedragen Nederlandse GEDCOM afspraken set uit voortvloeit.

Roepnaam

Johan Cruijf heeft van z’n ouders de naam Hendrik Johannes gekregen, hij is vernoemd naar de opa van moeders kant: Hendrik Johannes Draaijer. Zijn moeder noemde hem Jopie en de rest van de wereld kende hem als Johan. Echte voetbalfans noemen hem ook wel “Het orakel” of “Nummer 14”.

Qua naamdelen hebben we dus:

  • de geboortenaam (of doopnaam?) Hendrik Johannes > belangrijk om vast te leggen omdat deze naam in officiële documenten voorkomt;
  • de roepnamen Jopie en Johan > belangrijk omdat dit soort namen vaak in kranten en literatuur wordt gehanteerd, dit blijkt typisch Nederlands (en Duits);
  • de bijnamen “Het orakel” en “Nummer 14” > belangrijk om verwijzingen via een bijnaam naar de persoon te herkennen.

In GEDCOM wordt de naam (of namen) van een persoon vastgelegd volgens de definitie van de PERSONAL_NAME_STRUCTURE. Dit is een NAME in de structuur “Given name/surname/suffix” en – optioneel – als losse PERSONAL_NAME_PIECES, waar je dan een NAME_PIECE_PREFIX (NPFX), NAME_PIECE_GIVEN (GIVN), NAME_PIECE_NICKNAME (NICK), NAME_PIECE_SURNAME_PREFIX (SPFX), NAME_PIECE_SURNAME (SURN) en NAME_PIECE_SUFFIX (NSFX) vindt.

Een nickname is een bijnaam, wat iets anders is dan een roepnaam, toch? Dus, waar laten we de roepnaam? Is dit een custom tag waard, bijvoorbeeld _RUFNAME (zoals de Duitse GEDCOM-L groep beschrijft in hun GEDCOM-L Addendum). Of, wordt de geboortenaam in de NAME geplaatst en de roepnaam in GIVN (in plaats van de geboortenaam)? Of worden er voor de roepnamen aparte PERSONAL_NAME_STRUCTURE’s opgenomen waarbij we als NAME_TYPE roepnaam specificeren? Deze laatste optie lijkt het meest te passen binnen de GEDCOM specificatie en ziet er als volgt uit:

0 INDI @I1@ 
1 NAME Hendrik Johannes /Cruijf/ 
1 NAME Jopie /Cruijf/ 
2 TYPE roepnaam 
1 NAME Johan /Cruijf/ 
2 TYPE roepnaam 
2 NICK Het orakel 
1 NAME Johan /Cruijf/ 
2 TYPE roepnaam 
2 NICK Nummer 14 

Binnen een INDI_RECORD kunnen meerdere PERSONAL_NAME_STRUCTUREs opgenomen worden. Omdat de bijnamen horen bij de persoon die we kennen als Johan Cruijf horen, is er hierboven voor gekozen om twee maal de roepnaam Johan Cruijf op te nemen, elk met een bijnaam (er mag maar één NICK in een PERSONAL_NAME_STRUCTURE).

Het bericht Nederlandse GEDCOM afspraken – roepnaam verscheen eerst op Blog Bob.

]]>
https://blogbob.coret.org/2020/01/nederlandse-gedcom-afspraken-roepnaam.html/feed 6
Nederlandse GEDCOM afspraken – patroniem https://blogbob.coret.org/2020/01/nederlandse-gedcom-afspraken-patroniem.html https://blogbob.coret.org/2020/01/nederlandse-gedcom-afspraken-patroniem.html#comments Mon, 13 Jan 2020 10:08:21 +0000 https://blogbob.coret.org/?p=653 Dit artikel is onderdeel van de blogpost Nederlandse GEDCOM afspraken en heeft als focus de patroniem. Ik hoor graag wat de diverse stamboomprogramma’s en genealogische diensten hier mee doen qua invoer (en GUI) en GEDCOM export (en import). Het “probleem” wordt beschreven en er wordt een suggestie gedaan voor een “oplossing” om de discussie aan...

Het bericht Nederlandse GEDCOM afspraken – patroniem verscheen eerst op Blog Bob.

]]>
Dit artikel is onderdeel van de blogpost Nederlandse GEDCOM afspraken en heeft als focus de patroniem. Ik hoor graag wat de diverse stamboomprogramma’s en genealogische diensten hier mee doen qua invoer (en GUI) en GEDCOM export (en import). Het “probleem” wordt beschreven en er wordt een suggestie gedaan voor een “oplossing” om de discussie aan te zwengelen. Ik hoop dat er een gedragen Nederlandse GEDCOM afspraken set uit voortvloeit.

Patroniem

Een patroniem of vadersnaam is een naam, al dan niet officieel, die aangeeft hoe de vader van de naamdrager heet. De patroniem is niet specifiek Nederlands, maar toch lijkt er niet echt een evenknie in GEDCOM te zijn. Sommige patroniemen zijn “versteend” en toch achternaam “gepromoveerd”, zoals Jans(s)en, Willems(en), Hendriks, Jacobs en Hermans. Voor sommige voorouders hebben we alleen een patroniem en geen achternaam, voor sommige hebben we wel beide.

Als we kijken naar Jannetje Hendriksdr. Schroef dan hebben we dus:

  • de voornaam Jannetje
  • het patroniem Hendriksdr
  • de achternaam Schroef

De bij de roepnaam voorgestelde oplossing, om een aparte naam op te nemen met type, lijkt voor het patroniem minder geschikt. Een aparte custom tag (in het PERSONAL_NAME_PIECES construct) voor patroniem lijkt hier meer op z’n plaats, dus zoiets als:

0 INDI @I3@ 
1 NAME Jannetje /Schroef/ 
2 _PATR Hendriksdr.

Het bericht Nederlandse GEDCOM afspraken – patroniem verscheen eerst op Blog Bob.

]]>
https://blogbob.coret.org/2020/01/nederlandse-gedcom-afspraken-patroniem.html/feed 6