MDTO en aanvullende metagegevens

In maart 2024 is een pilot e-depot van Het Utrechts Archief met de gemeente Nieuwegein van start gegaan. In deze pilot wordt de impact van een overbrenging vanuit het zaaksysteem van de gemeente naar het e-depot (van Preservica) van Het Utrechts Archief onderzocht.
Onderdeel van deze impactanalyse is een metadatamapping vanuit het bronsysteem van de gemeente naar MDTO. Inmiddels is een mapping tot stand gekomen die Het Utrechtse Metadatamodel van MDTO volgt (hier op KIA gepubliceerd op 1 mei 2024 door Alice Strating van de gemeente Utrecht).

Iedereen met ervaring met metadatamappings weet dat dit een heel gepuzzel kan zijn en dat er vaak metadata zijn die niet in het model passen maar waarvan het toch zonde zou zijn om het niet op te nemen. Gelukkig biedt MDTO de mogelijkheid om aanvullende metagegevens op te nemen. Deze mogelijkheid hebben we praktisch uitgewerkt aan de hand van een voorbeeld-dossier uit het zaaksysteem van gemeente Nieuwegein. Uitgangspunten daarbij waren:
1 - Indien mogelijk nemen we de aanvullende metagegevens op in een metadatastandaard. In dit geval lag RGBZ voor de hand omdat het zaaksysteem van de gemeente Nieuwegein op deze standaard gebaseerd is.
2 - De aanvullende metagegevens moeten gevalideerd kunnen worden.
3 - De aanvullende metagegevens moeten bij het informatieobject opgenomen kunnen worden, ze zijn immers onderdeel van het over te brengen archief.

Bij de praktische uitwerking liepen we echter tegen het probleem aan dat de aanvullende metagegevens niet op een eenvoudige manier in een sidecarstructuur opgenomen kunnen worden.
Aanvankelijk hebben we de mogelijkheid uitgewerkt om de aanvullende metagegevens in een apart bestand op te nemen. Vanuit de MDTO metadata van een informatieobject kan naar dit bestand verwezen worden via het MDTO attribuut ‘aanvullende metagegevens’. Om de sidecarstructuur van het digitale archief kloppend te houden moet het bestand met aanvullende metadata ook weer een eigen metadata-sidecar krijgen.
Dit vonden we een omslachtige oplossing: voor het opnemen van misschien maar één aanvullend metagegeven bij een informatieobject zouden dan twee bestanden aangemaakt moeten worden. Bovendien worden metadata die hetzelfde object beschrijven dan verspreid over meerdere bestanden.

Daarom hebben we een andere aanpak uitgewerkt waarbij de aanvullende metagegevens in een eigen metadatablok naast de MDTO-metadata opgenomen zijn. In ons dossier-voorbeeld is een RGBZ-metadatablok in het dossier metadatabestand opgenomen. De structuur in dit XML-bestand is als volgt:

<?xml version="1.0" encoding="utf-8" ?>
<ROOT>
<MDTO xmlns="https://www.nationaalarchief.nl/mdto">
…
</MDTO>

<RGBZ xmlns="namespace_voor_rgbz">
…
</RGBZ>
</ROOT>

De metadata in de verschillende blokken beschrijven hetzelfde (informatie)object, in ons voorbeeld dus een dossier in het zaaksysteem, maar in het RGBZ-blok zit metadata die niet in MDTO maar wel in RGBZ opgenomen kon worden. Er is een extra root element aangemaakt dat beide blokken omvat.
Deze opzet heeft als voordelen dat er geen extra metadatabestand met sidecar opgenomen hoeft te worden én dat alle metadata over hetzelfde object bijeen zitten in één metadatabestand.

De vraag is dan wel hoe dit hybride metadatabestand gevalideerd kan worden? Immers, het XSD-bestand dat MDTO-XML-bestanden valideert (ontwikkeld door het Nationaal Archief) accepteert geen andere metadata-elementen.
Voor de metadatavalidatie is een oplossing uitgewerkt waarbij de metadatabestanden gevalideerd worden door een XSD-bestand dat andere XSD-bestanden importeert, waaronder het MDTO XSD-bestand van het Nationaal Archief en een zelfgemaakt RGBZ XSD-bestand. Er is met andere woorden een soort wrapper-XSD met een modulaire opzet ontwikkeld: MDTO is de basis (verplicht) maar de validatie kan uitgebreid worden met willekeurige andere metadataschema’s (bij voorkeur gebaseerd op een standaard). Voorwaarde is dat de metadata van de verschillende schema’s hetzelfde informatieobject beschrijven en een eigen namespace én XSD-bestand hebben.

Hieronder staat een voorbeeld van hoe het wrapper-XSD-bestand eruit kan zien. Dit XSD-bestand valideert XML-bestanden met een element <HUA> als root, maar dit kan net zo goed een andere root zijn: bijvoorbeeld de OPEX-wrapper die om de XML-bestanden geplaatst moet worden bij de ingest van de metadatabestanden in Preservica.

Met deze oplossing kunnen zowel “pure” MDTO-bestanden als hybride metadatabestanden gevalideerd worden.
Op deze manier wordt voldaan aan onze drie bovengenoemde uitgangspunten.
Daarnaast was – niet onbelangrijk – een eerste ingest van het voorbeeld-dossier met aanvullende metagegevens in Preservica succesvol.