MDTO en aanvullende metagegevens

1 sep
Djoke Dam
5
912
1

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>

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.

Afbeelding met tekst, schermopname, LettertypeAutomatisch gegenereerde beschrijving

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.

Reacties

5 reacties, meest recent: 14 oktober

Omgekeerde volgorde

- Léon Masselink
- 1727939763
Hoi Djoke, goed om te zien dat jullie bezig zijn met het vinden van een oplossing voor het huisvesten van <aanvullendeMetagegevens> en de resultaten delen. Daar zijn nog maar weinig praktijkverhalen over te vinden. Ik ben het met je eens dat je aanvullende metagegevens het liefst vastlegt in een valideerbare, gestandaardiseerde structuur, zoals bijvoorbeeld RGBZ. Je wrapper biedt een eenduidige structuur om die gegevens samen met MDTO in één XML-bestand op te nemen. Nuttige bijdrage!

Wij lopen momenteel helaas tegen een scenario aan waarin aanvullende metagegevens niet in een standaard als RGBZ te vangen zijn, zonder bijzonder veel extra mappingwerk. Wij zijn bezig met het migreren van vijf DMS-systemen, en hebben inmiddels een lijst van zo'n 50 aanvullende metagegevens, verspreid over meerdere domeinen (financiën, raadsvergaderingen, vergunningverlening etc) en ook over meerdere systemen. Deze gegevens zijn in hun bronsystemen niet vastgelegd in een metagegevensstandaard. Waarschijnlijk kiezen we ervoor om deze metagegevens in (een) aparte CSV('s) aan te leveren, die achteraf in het e-depot met een script wordt gerelateerd aan de dossiers en documenten waarop ze betrekking hebben. Kwaliteitscontrole doen we door deze CSV-bestanden vooraf te analyseren in onze digitale quarantaineruimte op o.a. compleetheid en koppelbaarheid. Een minder ideale, maar in ons geval wel pragmatische keuze.

Zijn er meer mensen/organisaties met praktijkervaringen over <aanvullendeMetagegevens>?
- Djoke Dam
- 1728034236
Hoi Léon,

De metadatasituatie die je beschrijft klinkt een stuk ingewikkelder dan die bij de gemeente Nieuwegein.
Nemen jullie dan ook nog een verwijzing naar de CSV-bestanden op in het MDTO-element <aanvullendeMetagegevens>?
Het voordeel van de oplossing die we bij HUA uitgewerkt hebben is denk ik dat alle metadata behorend bij een informatieobject in één XML-bestand met metadata zitten. Als de aanvullende metadata niet aan een standaard voldoet dan kun je daar natuurlijk ook een eigen XML-metadataschema met bijbehorende XSD voor maken en deze als XML-blok naast MDTO opnemen.
Het mooiste is als je dit eigen metadatamodel dan ook beschrijft en publiceert (zoals gemeente Utrecht gedaan heeft).
Dat is natuurlijk een intensief traject en misschien is een mapping naar standaarden dan nog eenvoudiger.
Heel begrijpelijk dat jullie voor de praktische oplossing met de CSV-bestanden gekozen hebben.
Ik ben ook benieuwd hoe andere archieven met aanvullende metagegevens omgaan, ieder e-depot zal misschien weer een eigen beste praktische oplossing hebben …

René Voorburg
1728043605

Aangepast op 4 oktober

Hallo Léon, Djoke,

Op het RAZU baseren we ons interne metadatamodel voor het edepot op MDTO. We gebruiken daarbij RDF. Metadata wordt ook opgeslagen in een triplestore maar de source of truth is de metadata zoals opgeslagen op de storage van edepot zelf. De metadata wordt daar per entiteit (hier per mdto:Bestand of mdto:Informatieobject) opgeslagen als een bestand in formaat json-ld (RDF).

Aanvullende metadata in wordt daarbij eenvoudigweg integraal in de RDF opgenomen. Enige onderscheid met MDTO is dat er andere vocabulaires gebruikt worden. Als voorbeeld hiervan een klein stukje testdata als RDF, hier voor het gemak in het wat leesbaarder turtle-formaat:

@prefix geo: <http://www.opengis.net/ont/geosparql#> .
@prefix mdto: <http://www.nationaalarchief.nl/mdto#> .
@prefix schema: <http://schema.org/> .

<https://data.razu.nl/id/object/NL-WbDRAZU-G321-661-11>
    a mdto:Informatieobject ;
    mdto:aggregatieniveau <https://data.razu.nl/id/aggregatieniveau/96f7399fb1c5d3b7d2acdc48dac3d71e> ;
    mdto:archiefvormer <https://data.razu.nl/id/actor/424280985651f416dfb6a68ee8ee6c6a> ;
    mdto:isOnderdeelVan <https://data.razu.nl/id/object/NL-WbDRAZU-G321-661-2> ;
    schema:height [ a schema1:QuantitativeValue ;
            schema:unitCode "CMT" ;
            schema:value 60 ] ;
    schema:width [ a schema1:QuantitativeValue ;
            schema:unitCode "CMT" ;
            schema:value 60 ] ;
    geo:hasBoundingBox [ a geo:Geometry ;
    geo:asWKT "POLYGON((5.1199335040169665 52.05595646677379, 5.12989999848441 52.05595646677379, 5.12989999848441 52.06214448999096, 5.1199335040169665 52.06214448999096, 5.1199335040169665 52.05595646677379))"^^geo:wktLiteral ;
    geo:crs <http://www.opengis.net/def/crs/OGC/1.3/CRS84> ] ;
    geo:scale "1:1000" ;
etc.

Groet, René

- Léon Masselink
- 1728378438
Hoi Djoke,

We nemen inderdaad een verwijzing naar het CSV-bestand op bij <aanvullendeMetagegevens>. Hoe hebben jullie dit opgelost, gezien de aanvullende metagegevens bij jullie feitelijk in hetzelfde bestand zitten?

Ben het met je eens dat we met z'n allen toe moeten naar een organisatiebreed (of wellicht beter, domeinbreed a la het Gemeentelijk Gegevensmodel) datamodel/metadataschema. Dat zou migraties een stuk makkelijker maken..
- Djoke Dam
- 1728891241
Hoi Léon,

Excuses voor deze wat late reactie.
In het voorbeeld dat we bij het HUA uitgewerkt hebben is geen verwijzing naar aanvullende metagegevens opgenomen. Dan zou je naar hetzelfde bestand gaan verwijzen. Dat is geen probleem denk ik maar misschien wel een beetje verwarrend?

Beter lijkt me om (zoals het in de bibliotheekwereld genoemd wordt) een "toepassingsprofiel" (ofwel "application profile") van de gebruikte metadataschema's te publiceren. Eigenlijk is het metadatamodel van de Gemeente Utrecht zo'n toepassingprofiel: er wordt aangegeven welke metadataschema's gebruikt zijn, welke waardelijsten, welke elementen al dan niet verplicht zijn, etc.
Dit toepassingsprofiel kan meerdere metadataschema's bevatten, liefst standaarden zoals MDTO, RGBZ, ORI, schema.org ... maar eventueel ook specifieke metadataschema's.

Bij HUA kwamen we op de volgende richtlijn uit: neem metadata zoveel mogelijk op in MDTO, is dit niet mogelijk gebruik dan een andere standaard, is dit ook niet mogelijk (en wil je de gegevens toch opnemen) gebruik dan een eigen metadataschema. Vooral in dat laatste geval is het toelichten en beschrijven ervan in een toepassingsprofiel belangrijk.

Ja, ik ben het helemaal met je eens dat dit zoveel mogelijk domeinbreed opgepakt moet worden!

Deel

Help

MDTO en aanvullende metagegevens

Reacties

Trefwoorden

Deel

Help

MDTO en aanvullende metagegevens

Reacties

Trefwoorden

Verken

Nieuwe fase voor het Stelsel van Metadata Standaarden

Metadata10Daagse: geen mooiere data dan metadata!

Yes, Stadsarchief Amsterdam werkt volgens OAIS!