Nieuwe fase voor het Stelsel van Metadata Standaarden
Samenvatting: ICTU heeft de afgelopen jaren belangrijke bijdragen geleverd aan de overheidsbrede werkgroep 'metadata', onderdeel van het Rijksprogramma voor Duurzaam Digitale Informatievoorziening (RDDI). Metadata zijn belangrijk, niet alleen bij archivering maar ook in de dagelijkse informatiehuishouding van de overheid. Doel van de werkgroep was daarom: meer regie op het gebruik van metadata en metadatastandaarden binnen de overheid. Deze regie op het 'stelsel van metadata standaarden' is in september belegd bij BZK/DO. ICTU ondersteunt BZK bij de uitvoering. Projectleider Jaap Haenen blikt in onderstaand interview terug op wat de werkgroep heeft bereikt, en kijkt vooruit naar de situatie waarin BZK/DO regie voert en ICTU ondersteunt. https://www.informatiehuishouding.nl/actueel/nieuws/2024/10/10/jaap-haenen-blikt-terug-leiderschap-en-innovaties-in-metadata-voor-duurzame-overheidsinformatie
Reacties
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>?
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 …
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:
Groet, René
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..
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!
Aangepast op 18 december 2024
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:
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:
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 🙂
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.
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!
Het Nationaal Archief heeft in ieder geval al wel een SHACL validatie voor MDTO, zie:
https://www.nationaalarchief.nl/archiveren/mdto/rdf-ontologie
(heb er verder nog niet naar gekeken)
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).
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)
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é
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 🙂
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.
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?
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).