ToPX: meerdere typen eventgeschiedenis per record vastleggen
Beste collega's, event.txtVoor een gemeente ben ik bezig om het aangeleverde archief uit Corsa klaar t...
Aanleveren aan een e-depot: Hoe ga je om met de metagegevens van een bestand?
- apr 2019
- Vincent Hoolt
- ·
- Aangepast 27 jun
- 5
- 91
In de redactiegroep koppelvlak TMLO is een discussie ontstaan over de manier van aanleveren van metagegevens voor bestanden. Wij willen deze discussie graag breder trekken en vragen om jullie mening.
TMLO schrijft in het model voor dat de technische metagegevens altijd bij een record horen. Een bestand kent geen los bestaan. Voor het aanleveren aan een e-depot gaat de redactiegroep uit van het gebruik van sidecars. Voor elk record wordt een apart sidecar bestand met de metadata geleverd. Bij het aanleveren aan een e-depot van de metadata voor het bestand hebben we twee keuzes:
Technische metagegevens meeleveren op record niveau, dus in de sidecar van het record.
Technische metagegevens lostrekken van het record en specifiek bij het bestand aanleveren als een aparte sidecar.
Graag horen wij van jullie welke ervaringen jullie mogelijk al hebben bij het aanleveren, welke keuze jullie gemaakt hebben en waarom. Ook als je nog geen ervaring hebt maar wel een duidelijke voorkeur voor een van beide keuzes kun je deze delen.
Verken
Duurzame opslag vóór er een edepot is
Beste collega's, Archief Eemland gaat per het volgend jaar onderzoeken wat de mogelijkheden van een e-...
experimenteren met mogelijkheden
Ik geef het direct toe: ik ben niet zo van het experimenteren. Wel ben ik nieuwsgierig. Zo kwam ik dit...
Reacties
Hoi Vincent, interessante vraag! Bij het BHIC hebben we ervaring met aanlevering uit diverse systemen, waaronder Corsa, eDOCs en Key2Zaken (en fileshares). De huidige voorwaarden export voldoen m.i. prima.
topx.pngIn theorie is de huidige werkwijze ook goed te verdedigen: je legt een checksum vast voor een bestand, niet voor een recordmap. Als je meerdere bestanden onder één record hebt, dan moet je meerdere keren een checksum aanleveren. Hoe ziet de redactiegroep dat dan?
Over het aanleveren heb ik nog wel een opmerking: met de RMTool kan je met één druk op de knop de technische metadata toevoegen (soort voorgeprogrammeerd sjabloon), of als je wilt delen daarvan. Ik ben nu toevallig bezig met het toevoegen van checksums en timestamps aan de oorspronkelijk aangeleverde sidecars. Dus ook als je de metadata niet volledig krijgt aangeleverd, kan je deze eenvoudig verrijken, zeker als het om al die technische metadata gaat. Zie bijlage.
Hallo Vincent,
Goed dat je deze discussie hier breder trekt!
Eerst even ten aanzien van de gebruikte terminologie, die vind ik wat verwarrend. Om de een of andere reden is men de term "record" gaan gebruiken als synoniem voor het aggregativeau archiefstuk. Maar het in het TMLO verwijst de term "record" niet naar een aggregatieniveau, maar naar een entiteit: "Elke entiteit kent verschillende aggregatieniveaus waarop metagegevens worden vastgelegd. Zo zijn archiefstuk, dossier of archief aggregatieniveaus van de entiteit ‘record’. aggregatieniveaus van de entiteit ‘actor’ zijn bijvoorbeeld: organisatie, afdeling en functionaris." (p. 10 TMLO v 1.1)
Je kunt dus eigenlijk niet spreken over "record-niveau", alle niveaus in het TMLO betreffen de entiteit "record".
Ik zou er voor pleiten om technische metagegevens mee te geven op het niveau waar ze ook echt betrekking op hebben, namelijk het digitale bestand. En met bestand bedoel ik dan het niveau van de bitstream met een bestandsnaam en extensie, de "file " in je besturingssysteem dus.
Het lijkt me wel zo consequent om hier de MARA architectectuur ( Model architectuur rijks archiefinstellingen) te volgen, die het heeft over manifestatie afhankelijke en manifestatie onafhankelijke metadata. (MARA thema C, va p 71)
Het digitale bestand is een "manifestatie" van het archiefstuk, en één archiefstuk kan meerdere digitale manifestaties hebben (bijvoorbeeld een orgineel bestandsformaat en een genormaliseerd duurzaam bestandsformaat). Technische metadata zijn manifestatie-afhankelijke metadata, en horen dus bij de manifestatie (digitaal bestand).
Overigens: begrijp ik uit je vraagstelling dat jullie in de redactiegroep al de keuze hebben gemaakt voor de sidecarstructuur als standaard voor het uitwisselformaat? Of houden jullie meerdere opties open?
Hoi Jean-Luc,
Bedankt voor je antwoord.
Bij de aanlevering op record niveau, als element 21, is dit element herhaalbaar en herhaal je deze voor elk bestand met de eigen checksum. Dat past meer bij het model en werkt. Maar praktisch werkt het ook prima om het los te koppelen, zoals we nu bij het NA en dus bij het BHIC doen. Ik neem dit mee in de discussie van de redactiegroep.
De RM tool toepassing op dit gebied lijkt me leuk om ook een keer bij de redactiegroep te bekijken. Ik kom daar nog bij je op terug.
Hoi Anje,
Bedankt voor je antwoord. Heel duidelijk. Wat betreft je vraag over de sidecarstructuur als standaard is het antwoord dat we sidecars willen gebruiken. Voor het uitwisselformaat volgt nog een openbare review, dus er is nog gelegenheid om andere opties voor te stellen.