MDTO en aanvullende metagegevens

  • sep 2024
  • Djoke Dam
  • 16
  • 1905
  • 1
Djoke Dam
KIA Community
  • Barbara Roozen
  • Lars Mogelin
  • Reem Weda
  • Carla le Poole
  • Olivier Giraud
  • Susanne van den Eijkel
  • Jeroen van Oss
  • Laura M van Noort
  • Eva van den Hurk - van 't Klooster
  • Jasper Slob
  • Eike den Hertog
  • Jeroen Clijsen
  • André Clement
  • Marjan Dik
  • Frederiekje de Jongh
  • Adriaan Mol
  • Corinne Boeijinga
  • Rijnder Wever
  • René Voorburg
  • Léon Masselink

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.

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

16 reacties, meest recent: 31 januari

  • 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>?

    Léon Masselink

  • 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 …

    Djoke Dam

  • Aangepast op 4 oktober 2024

    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é

    René Voorburg

  • 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..

    Léon Masselink

  • 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!

    Djoke Dam

  • Aangepast op 18 december 2024

    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.

    Zoiets klinkt mooi — je wilt immers de betekenis van je aanvullende metagegevens kunnen achterhalen — maar MDTO biedt momenteel geen ruimte om naar toepassingprofielen (of iets dergelijks) te kunnen verwijzen binnen je aanvullende metagegevens.

    Sterker nog, MDTO stelt dat je documentatie over aanvullende metagegevens in het bestand zelf behoort op te nemen:

    Informatie over structuur en betekenis van de aanvullende metagegevens kan in het bestand zelf worden opgenomen. (bron: https://www.nationaalarchief.nl/archiveren/mdto/aanvullendeMetagegevens)

    Dus als je een extra JSON bestandje hebt moet je daar zelf documentatie in proppen. Om meerdere redenen een vrij bizare suggestie, alleen al omdat sommige bestandsformaten — waaronder JSON — geen duidelijke ruimte voor comments bieden.

    Wat je eigenlijk zou willen is iets als dit:

    <aanvullendeMetagegevens>

    <aanvullendeMetagegevensVerwijzing>
        <verwijzingNaam>aanvullende gegevens.json</verwijzingNaam>
    </aanvullendeMetagegevensVerwijzing>

    <aanvullendeMetagegevensDocumentatie>
        <begripLabel>Toepassing profiel #1</begripLabel>
        <begripBegrippenlijst>
            <verwijzingNaam>Toepassing profielen gemeente Utrecht</verwijzingNaam>
        </begripBegrippenlijst>
    </aanvullendeMetagegevensDocumentatie>
    
</aanvullendeMetagegevens>

    Dit zorgt er ook voor dat je aanvullende metagegevens documentatie niet 100x heeft te herkauwen in ieder bestand.

    Ik heb dit probleem gemeld bij het NA, en hoop dat ik gehoor krijg 🙂

    Rijnder Wever

  • Als je in RDF werkt, wordt het al wat makkelijker om beschrijving toe te voegen. Je zou bijvoorbeeld naar je eigen shacl shapes kunnen verwijzen. Je kan ook eigen subproperties of subclasses gebruiken.

    René Voorburg

  • Aangepast op 19 december 2024

    Ik geloof meteen dat RDF superieur is aan XML (kan ook bijna niet anders), maar helaas zitten wij — net als veel andere archiefdiensten — in een op XML-geeikt software ecosysteem. En aangezien het inlezen van XML in ons eDepot eigenlijk al een beetje houtje touwtje is, twijfel ik of RDF er voor ons aan zit te komen.


    Maar goed om te weten dat andere archiefdiensten al bezig zijn met modernere formaten!

    Rijnder Wever

  • Ik heb die shacl in een aantal omgevingen gebruikt (oa. met https://www.itb.ec.europa.eu/shacl/any/upload en https://github.com/ULB-Darmstadt/shacl-form) maar nu ik 'm binnen Python wil gebruiken (met pyshacl) loop ik tegen een probleem op. Volgens Python is de shacl niet valide:

    ShapeLoadError: A shape defined as a NodeShape cannot be the subject of a 'sh:path' predicate.
    For reference, see https://www.w3.org/TR/shacl/#node-shapes

    Dat lijkt me juist. Jammer dat NA github niet lijkt te gebruiken (NationaalArchief/MDTO is leeg).

    René Voorburg

  • Aangepast op 19 december 2024

    @Rene er is genoeg mis met de MDTO XSD en XML voorbeeldbestanden, dus ik ben niet al te verbaasd dat de shacl niet klopt (ik heb laatst al een lange mail over MDTO problemen gestuurd naar het NA). Bijv: tot redelijk recent waren sommige XML voorbeeld bestanden niet-valide volgens de MDTO XSD van het NA. Dat vertelt mij: dingen zijn of worden nauwelijks getest (fout of niet, die indruk geeft het wel).

    Ook jammer dat er geen openbare issue tracker is voor dit soort problemen. Op zich kunnen we de MDTO github gaan misbruiken/gebruiken, maar die lijkt vrij dood.

    > (NationaalArchief/MDTO is leeg).

    https://github.com/NationaalArchief/MDTO mag dan wel leeg zijn, maar gelukkig is daar https://github.com/Regionaal-Archief-Rivierenland/mdto.py 🙂 Een project dat bijna helemaal klaar is, maar nog wel in beta. Output in andere formaten dan XML staat al op de planning! (contributions welcome)

    Rijnder Wever

  • Ik het de MDTO shacl van het Nationaal Archief aangepast zodat er op correcte wijze onderscheid gemaakt wordt tussen entiteiten van type sh:NodeShape en sh:PropertyShape. Deze gecorrigeerde shacl is nu ook te gebruiken onder python met pyshacl.

    Ik dacht de lege MDTO-repository van het NA te forken, daar mijn verbeterde shacl in te zetten en dan een pull-request te doen, maar helaas blijkt een lege github-repo niet te forken. Ik heb daarom maar zelf een nieuwe repository aangemaakt. Zie Regionaal-Archief-Zuid-Utrecht/MDTO-RDF

    Ik hoop dat het NA werken in GitHub & aan MDTO weer gaat oppakken.

    Groet, René

    René Voorburg

  • Ik hoop dat het NA werken in GitHub & aan MDTO weer gaat oppakken.

    Ik ook, en goed dat je een gecorrigeerde versie publiceert, maar het is denk ik ook wel goed het NA hier nog een keer apart over in te lichten. Hoe meer mensen aan de deur kloppen, hoe eerder ze iets doen (hoop ik tenminste).

    Also, we hebben het thread nu wel goed ge-derailed 🙂

    Rijnder Wever

  • Omdat ons MDTO-toepassingsprofiel net wat meer is dan een toepassingsprofiel definiëren wij het als een nieuwe ontologie, gebaseerd op / afgeleid van MDTO. We noemen het LDTO waarbij de L (ipv de M) de L is van Linked data.

    Zie hiervoor op Github Regionaal-Archief-Zuid-Utrecht/ldto , met daar o.a. voorbeelden, shacl's en validatiescripts en een owl-definitie.

    Het is uiteraard werk in uitvoering en laat zien waar nu staan qua informatiemodel bij de bouw en doorontwikkeling van ons e-depot.

    René Voorburg

  • Jullie hebben een indrukwekkende hoeveelheid werk verzet René!

    Als ik het goed begrijp kan RAZU altijd nog MDTO als een uitwisselingsformaat gebruiken. Deze MDTO wordt dan afgeleid van jullie LDTO toch?

    Djoke Dam

  • We krijgen graag MDTO aangeleverd, dat we dan zullen omzetten naar LDTO, maar LDTO kunnen we ook weer omzetten naar MDTO (in theorie in ieder geval, in praktijk heb ik hier alleen nog op beperkte schaal mee geëxperimenteerd, vooral om LDTO te valideren).

    René Voorburg

Trefwoorden

Verken