Stappenplan voor het mappen van een DMS naar MDTO
Samenvatting: Het RAR heeft een stappenplan opgesteld voor het mappen van een DMS naar MDTO in het kader van digitale migratie.
Eerste indrukken MDTO?
- apr 2020
- Erik Saaman
- ·
- Aangepast 28 jun
- 21
- 41
Een week geleden is de openbare review van MDTO gestart (zie aankondiging). Wij zijn heel benieuwd wat de eerste indrukken zijn. Zijn er misschien al vragen of discussiepunten? Natuurlijk ontvangen we die graag in de review zelf. Maar voel je ook vrij om hier een discussie te starten. Misschien kunnen we dan al heel snel onduidelijkheden verhelpen.
Verken
Informatieverzoek inzake projectplan opstellen metadataschema binnen uw organisatie of gemeente
Als trainee informatiebeheer, nu bijna een jaar werkzaam voor de drie Limburgse gemeenten Maasgouw, Ec...
Metadatamodel e-Depot Nationaal Archief
Onlangs heeft binnen het Nationaal Archief een evaluatie van Medusa plaatsgevonden. Medusa is het XML ...
Reacties
Hallo Erik,
In principe positief gestemd over de richting naar een meer relationeel model maar het is nog steeds niet bepaald laagdrempelig geschreven en daardoor lastig te volgen door iemand die niet helemaal met de materie bekend is. In mijn reviewgroep werd het visuele model ook erg gemist. Ook jammer dat de nadruk lijkt te liggen op permanent te bewaren informatie. Ook voor te vernietigen informatie zou je een model willen hebben. Daarvoor is de oude TMLO en nu de MDTO toch iets te zwaar opgetuigd. Zou mooi zijn als er in een volgende versie een meer schaalbaar model komt, met duidelijk aangegeven welke elementen er relevant zijn voor te vernietigen informatie en welke voor te bewaren informatie.
Hallo Erik,
wat ik vooral lastig vind is dat een verantwoording voor wijzigingen ontbreekt. MDTO is begonnen als een doorontwikkeling van het TMLO, maar gaandeweg zijn er beslissingen genomen om een en ander anders in te steken. Prima, alleen waarom er vervolgens andere keuzes zijn gemaakt, is nu niet duidelijk. Worden bijvoorbeeld vormelementen niet meer noodzakelijk geacht of moet dit op een andere manier worden opgelost binnen het model?
Ook ik mis - net als Gerard - een visueel model, zeker als het gaat om de relatie tussen objecten en subobjecten en eventuele overervingen. Daarin waren de aggregatieniveaus in het TMLO mijns inziens toch een stuk duidelijker, hoewel daar ook wel het een en ander op aan te merken viel. Het valt me dan vooral op dat het document met de aanleverspecificaties nog wel vasthoudt aan dit oude model.
In gebruik lijkt MDTO me niet moeilijker - maar ook niet echt makkelijker - dan het TMLO. Mijn eerste indruk is dat er goed mee te werken valt.
Verder moet ik zeggen dat ik in deze drukke tijd een maand erg kort vind voor een review.
Groet,
Wouter
Gerard, Het zou inderdaad jammer zijn als de mensen waarvoor MDTO bedoeld is het lastig vinden om deze te lezen. We hebben ons best gedaan. Maar het is lastig inschatten wanneer een tekst duidelijk genoeg is voor een breed publiek en tegelijk niet te langdradig. Het zou fijn zijn als jullie in de review kunnen aangeven welke onderdelen onduidelijk zijn. Welke doelgroep heb je daarbij trouwens in gedachten? MDTO is alleen bedoeld voor de mensen die informatiesystemen en koppelingen daartussen ontwerpen of daarbij adviseren. Het is niet bedoeld voor de mensen die metagegevens invoeren of gebruiken.
Wat betreft het gebruik voor tijdelijk te bewaren informatie, daar heb je een punt. MDTO is daarvoor wel bedoeld. Maar we hebben het uitwisselen met e-depots wel als de belangrijkste use case gebruikt. En dan gaat het meestal om blijvend te bewaren informatie (behalve bij uitplaatsen). Bijna alle attributen zijn niet-verplicht, maar 'verplicht indien beschikbaar'. Dus dat biedt al ruimte. Misschien is het een idee om aan te geven welke attributen minder belangrijk zijn voor tijdelijk te bewaren informatie. Aan welke elementen denk je dan? Aan de andere kant, als die attributen wel beschikbaar zijn, waarom zou je ze dan niet uitwisselen?
Wouter, De verantwoording van de keuzes is inderdaad belangrijk om nog toe te voegen. Dat willen we juist doen op basis van het ontvangen commentaar. Die maken voor ons duidelijk waar die verantwoording het meeste nodig is.
De keuze welke attributen wel of niet op te nemen is bepaald door de volgende criteria:
1) Het attribuut draagt bij aan de duurzame toegankelijkheid van het record. Zoals vindbaarheid.
2) Standaardisatie van het attribuut heeft meerwaarde. Zoals het kunnen maken van een zoekformulier)
3) Het attribuut is generiek. D.w.z. dat het bij de meeste soorten werkprocessen en informatie kan voorkomen in de gestandaardiseerde vorm. Daarom nemen we bijvoorbeeld zaakgegevens en gedetailleerde geogegevens niet in MDTO op.
Voor bijvoorbeeld de vorm kwamen we er niet uit hoe die te standaardiseren. Bovendien kan het attribuut 'Classificatie' ook gebruikt worden om te classificeren naar de vorm. Alhoewel het dan als ontvangende partij niet te herkennen is als zodanig.
De hiërarchische is in de koppelvlakspecificatie inderdaad opgenomen, maar niet verplicht. We hebben het opgenomen omdat sommige e-depots ze wel gebruiken. Maar andere niet. De niveaus lijken misschien verplicht vanwege te plaatjes. Maar dat is dus niet zo.
Eens met de opmerking van Gerard: ook mij valt op dat de nadruk ligt op overbrenging/uitplaatsing. Terwijl maar een zeer beperkt deel van alle overheidsdata daarvoor in aanmerking komt.
Mijn suggestie zou zijn om binnen de MDTO verschillende profielen uit te werken. Sommige attributen zou ik bijvoorbeeld wel verplicht stellen bij B-informatie, maar niet bij V1-informatie. Dan zou je de kardinaliteit per profiel kunnen vaststellen. In een aanbesteding kun je dan aangeven welk profiel van toepassing is, zodat voor leveranciers duidelijk is wat je precies verwacht.
Als ik een of ander klein fluttooltje ga aanschaffen/inrichten voor een proces met een lage informatiewaarde, dan wil ik alleen maar een hele beperkte set metadata hebben op basis waarvan ik vernietiging kan uitvoeren zodat ik voldoe aan de AVG/Archiefwet. Dan heb ik dus een absolute minimumset compliancy-metadata nodig. Ga ik meer vragen, dan voegt dat functioneel niet per se iets toe, (al is het mooi meegenomen natuurlijk) maar loop ik wel het risico dat er minder/geen marktpartijen inschrijven omdat ze niet aan de eisen kunnen voldoen. Dat signaal krijgen we ook van leveranciers: dat we als overheid vaak overvragen en eigenlijk niet goed de toegevoegde waarde van specifieke eisen kunnen uitleggen. Daar moeten we dus wat mee.
In mijn werkpraktijk vallen veruit de meeste informatiesystemen/apps onder de categorie die ik hierboven beschrijf. Dat de use case over uitwisseling met een e-depot zo centraal stond zoals Erik aangeeft, dat verrast me daarom een beetje. Natuurlijk is dat een belangrijk aspect, maar volgens mij is het verhoudingsgewijs maar een heel klein onderdeel van de totale scope.
De reden dat de use case uitwisselen met een e-depot centraal stond komt omdat de eerste aanleiding voor de update van TMLO was dat TMLO onvoldoende basis was voor het maken van koppelingen voor het uitwisselen van metagegevens.
MDTO is gericht op het uitwisselen en beschikbaar stellen van metagegevens (ze 'Waarop is MDTO van toepassing' in de inleiding). Niet op het inrichten van informatiesystemen zelf. Rens, ik krijg de indruk dat jij MDTO ook wilt gebruiken om te bepalen welke metagegevens er in een systeem bijgehouden moeten worden. Klopt dat? Daarvoor is het nu dus niet bedoeld.
Wat zou volgens jou de absolute minimale set metagegevens zijn dat elk systeem moet bijhouden?
De concrete eisen die in de wetgeving (Archiefbesluit) staan over metagegevens zijn overigens alleen op blijvend te bewaren informatie van toepassing. Dus dat helpt ons niet verder als minimale set.
Klopt Erik, zo bedoelde ik het inderdaad. Zo gebruiken we TMLO nu ook.
Wat we niet moeten willen, is dat we een aparte standaard naast de MDTO gaan ontwikkelen voor het inrichten van informatiesystemen. Dan zouden we straks namelijk twee standaarden hebben met veel overlap, in de kern allebei opgesteld om bij te dragen aan duurzame toegankelijkheid. Zou toch mooi zijn als we dat in één standaard zouden integreren?
Je vraag wat dan die minimumset zou moeten zijn: dat is een punt om uit te werken, heb ik niet direct een pasklaar antwoord op. Misschien zou je daar ook nog twee of drie varianten in kunnen bedenken, afhankelijk van de informatiewaarde.
Hallo Erik,
Ik kan me vinden in de reactie van Gerard en Rens. Het zou ons denk ik helpen als we met de MDTO een een instrument hebben die wij ook kunnen toepassen bij het inrichten van systemen met informatie die een korte bewaartermijn hebben, een situatie die in onze situatie nu eenmaal vaker voorkomt dan te preserveren informatie. Het zou mooi zijn als we één standaard hebben voor alle smaken en dat is misschien vooral een kwestie van vorm.
Als we de MDTO nu zouden willen toepassen bij AbD in een bedrijfsapplicatie zouden we hem eerst moeten 'afpellen' en dat maakt de communicatie met leveranciers gecompliceerder. Een vorm waarin het duidelijk is wat de minimale comliancy-set is, die stapsgewijs kan worden uitgebouwd tot de set die er nu in het informatiemodel staat zou ons denk ik erg helpen.
Ik begrijp jullie wens om MDTO ook te kunnen gebruiken voor het inrichten van informatiesystemen. Maar daar is het huidige concept dus niet voor bedoeld. We zullen dit als wijzigingsvoorstel meenemen.
Blijft wel de vraag wat dan die minimale set voor alle informatiesystemen moet bevatten. Wie heeft een idee?
En, is het nodig om die minimale set als een standaard vast te leggen? Of kan dat ook niet-normerend. Dwz zonder dat er consensus over hoeft te zijn. Dat maakt het gemakkelijker om de set vast te stellen.
Volgens mij ontkom je er meestal niet aan dat je meerdere standaarden moet hanteren. Ik denk niet dat het mogelijk is om een standaard te ontwerpen die alle doelen dient. Neem bijvoorbeeld een gemeente die een zaaksysteem wil aanschaffen en inrichten. Dat zaaksysteem moet de procesuitvoering ondersteunen, maar ook alle informatie die uit een proces voortkomt duurzaam toegankelijk houden. MDTO volstaat alleen voor het tweede doel. Voor het eerste doel is er RGBZ .
Dus zelfs als je MDTO ook geschikt zou maken voor kort te bewaren informatie, ben je er niet met alleen deze standaard, omdat procesondersteuning geen doel is van MDTO. Of je moet RGBZ erin opnemen. En wat doe je dan met de ondersteuning van niet-zaakgericht werken?
De metadata die minimaal noodzakelijk zijn om een zaak te kunnen behandelen, of de metadata die tijdens de behandeling van de zaak gegenereerd worden, kunnen ook per domein heel erg verschillen. Daarom zijn er voor sommige domeinen ook nog domeinstandaarden. Ik kan me niet voorstellen dat je dat allemaal in één standaard kunt vangen. En als het al zou kunnen, dan krijg je een standaard die zo veelomvattend en gedetailleerd is, dat je in de meeste gevallen veel meer vraagt dan nodig is. Een standaard met heel veel velden die alleen in bepaalde domeinen of bij bepaalde bewaartermijnen verplicht zijn. Dan moet je bij de aanschaf van een applicatie voor één domein of één proces alsnog tegen je leverancier zeggen welk deel van de standaard noodzakelijk is.
Ook zou een standaard die alle denkbare metadata bevat archiefvormers heel erg beperken in hun vrijheid om hun processen en zaaktypen naar eigen wens en behoefte in te richten.
Als het MDTO wordt gezien als opvolger en vervanger van het TMR/TMLO en de Richtlijn Metagegevens Rijksoverheid dan kan het niet zo zijn dat MDTO niet van toepassing is op het inrichten van informatiesystemen bij overheidsorganisaties.
De Richtlijn is toepasbaar op alle systemen waarin of waarmee overheidsinformatie wordt beheerd. De minimum set aan gegevens die de richtlijn geeft zijn in alle gevallen essentieel om informatie terug te vinden en te duiden/interpreteren. Hier heb je een minimale set ;-) Deze hoeft zich overigens niet in één systeem te bevinden als ze maar gekoppeld kunnen worden aan de informatie/het informatieobject.
Het Toepassingsprofiel Metagegevens Rijk (TMR) beschrijft de afspraken over welke metagegevens minimaal nodig zijn en over de manier waarop deze gegevens binnen de rijksoverheid worden vastgelegd. Deze metagegevens zijn dan ook een belangrijke stap voor duurzame toegankelijkheid en een betrouwbare informatiehuishouding. Door deze afspraken wordt de interpretatie en uitwisseling van informatie tussen organisaties en systemen bevorderd, maar het doel van TMR/TMLO is niet het uitwisselen of beschikbaarstellen van metagegevens an sich.
Door je met MDTO enkel te richten op het uitwisselen en het beschikbaarstellen van metagegevens verlies je de doelstellingen en het nut van de vorige standaarden uit het oog. Prima als dit de keuze is, maar realiseer je dan dat MDTO op deze manier een uitwisselingsstandaard is en niet een metagegevensschema zoals bedoeld in de Archiefregeling.
Ik ben het met Frederiekje eens dat een set metagegevens voor duurzame toegankelijkheid niet genoeg is voor het inrichten van een informatiesysteem. Dit is afhankelijk van verschillende factoren, zoals het proces, de functie, het doel, wet- en regelgeving enz.
Eens met Frederiekje en Mette, er zijn voor verschillende doelen verschillende standaarden en dat is oké. Laten we alleen oppassen dat we niet verschillende standaarden voor min of meer hetzelfde doel gaan ontwikkelen.
@Erik: wat betreft die minimumset; in de conceptarchitectuur (onderdeel van GEMMA) voor informatiebeheer bij gemeenten wordt al een voorzet gedaan voor de minimale compiancy-metadata, zie: https://www.gemmaonline.nl/images/gemmaonline/2/2b/GEMMAArchitectuurDUTO16122018V6.pdf
Is nog een concept en ik weet niet wat de huidige status is, maar lijkt me goed om op dit punt de samenwerking met de VNG op te zoeken.
Ik begrijp niet zo goed waarom een standaard minimale set wenselijk is. Wat win je daar mee?
En waar leg je dan de grens. Wanneer is de ene minimale set van toepassing en wanneer de andere. Simpelweg grenzen leggen bij bepaalde bewaartermijnen lijkt me te simplistisch. Ook de aard van het bronproces en de informatie zal daar een rol bij spelen.
Is het niet handiger om MDTO te zien als de lijst van metagegevens die je altijd wilt hebben, als de kosten daarvoor opwegen tegen de meerwaarde. Dat laatste is een afweging die je per geval moet maken. Voor vergelijkbare processen en informatie zal dat misschien hetzelfde uitpakken. Maar het is lastig daar een algemene uitspraak over te doen.
Om te helpen bij het maken van de keuze welke metagegevens wel of niet noodzakelijk zijn, hebben we in het informatiemodel het kopje 'doel' opgenomen. Dan kun je zelf afwegen of je dat doel belangrijk genoeg vindt.
Ik zou het omdraaien Erik: ik snap niet waarom de nadruk ligt op metadatering van langdurig te bewaren informatie die ooit naar een e-depot gaat. Verhoudingsgewijs komt dat bijna niet voor. Voor het gros van de systemen die je op basis van een standaard wil inrichten, ligt er met deze standaard een veel te zwaar en uitgebreid pakket. Ik zou zo'n standaard niet op de uitzondering baseren, maar op de regel.
Je wil niet bij elke aanbesteding een superlange maatwerkeis formuleren: u moet voldoen aan de MDTO-standaard, met uitzondering van [enorme waslijst van in dat geval niet-relevante items], zoals jij suggereert. Dat is geen doen en voor leveranciers ook niet te behappen als elke overheidsorganisatie voor zichzelf een standaard op die manier gaat interpreteren, dat merken we nu met de TMLO ook al. Je wil kunnen zeggen: u moet voldoen aan de MDTO-standaard en daarbinnen specifiek Profiel A, B of C.
Je hebt gelijk dat het te kort door de bocht is om dat enkel op bewaartermijn te baseren, daar zouden we dus criteria voor moeten formuleren. En verder is het ook aan de adviseur van dienst om daar met gezond verstand de juiste keuze in te maken.
Daarom: maak een standaard die recht doet aan de verschillende belangen en staar je niet blind op alleen maar het erfgoeddeel. Natuurlijk is dat belangrijk, maar het is maar het topje van de ijsberg.
Ik denk dat als we er zo naar kijken, dat we dan een waanzinnig mooi instrument maken waar echt breed behoefte aan is die bovendien bijdraagt aan standaardisatie in de markt.
Eens met vorige sprekers: ik ben ook voor één landelijke metadatastandaard, die zowel gebruikt kan worden voor het inrichten van informatiesystemen en voor het uitwisselen en beschikbaar stellen van informatie.
Het lijkt me dat je dan een volledige set hebt voor e-depots (profiel A?) en een minimale set die voor elk informatiesysteem geldt (profiel C?). Of je ook allerlei andere sets voor andere systemen gaat definiëren of dat je dat oplost met de minimale set + een mapping van de metadatavelden die toch al aanwezig zijn vanwege het proces, is dan voer voor discussie.
Overigens is dat in mijn ogen ook niet heel erg anders dan hoe het TMLO al gebruikt kan worden (en misschien MDTO ook wel, al is het niet als zodanig bedoeld).
Het formuleren van expliciete profielen is een interessant idee om te onderzoeken. Hebben jullie ideeën hoe die verschillende profielen te onderscheiden. Want alleen blijvend vs tijdelijk bewaren lijkt me te grofmazig. En een minimale set voor echt alle informatiesystemen lijkt me ambitieus. Ik kan me voorstellen dat er systemen zijn waar je helemaal geen mategegevenseisen aan stelt. Ik zou de profielen liever aan de aard van de informatie dan aan termijnen willen ophangen. Bijvoorbeeld één profiel voor informatie die een rol kan spelen bij publieke verantwoording en juridische procedures.
Zou je die profielen dan ook breder willen inzetten dan alleen voor metagegevens. Dus ook de andere eisen t.a.v. duurzame toegankelijkheid er aan koppelen? Zoals voor vernietigen, bestandsformaten, etc. We zouden zo dezelfde profielen bij meerdere lijstjes kunnen gebruiken.
Rens en Wouter, is het een idee om in de KIA-werkgroep archiveren by design de profielen te definiëren?
Ik zie eigenlijk twee dingen die door elkaar lopen: de koppelvlakspecificatie, die uitgaat van de use case 'uitwisselen met een e-depot'. En het informatiemodel, dat los daarvan gebruikt kan worden voor de inrichting van informatiesystemen. Daar is het mijns inziens juist wel voor bedoeld (een instrument dat gebruikt kan worden voor archivering by design).
En voor zowel te vernietigen als te bewaren informatie, want duurzame toegankelijkheid gaat om de toegankelijkheid van informatie zolang dat nodig is. En dat kan kort of lang zijn.
En toegankelijkheid komt natuurlijk ook ten goede aan alle gebruikers, niet alleen de bezoekers van een digitale studiezaal.
Het informatiemodel staat niet in dienst van het koppelvlak.
Door het domein van MDTO nadrukkelijker te benoemen, is er ook een beter onderscheid te maken met andere standaarden die voor andere doeleinden zijn gemaakt. Die kunnen best naast elkaar bestaan. Standaarden worden naast elkaar gebruikt en zullen ook deels overlappen.
Om daarnaast nog aparte profielen te formuleren lijkt me dan weer een brug te ver.
Nu wij werken aan een review-reactie, wil ik namens RA Tilburg graag de vraag voorleggen aan het Nationaal Archief waarvoor de wijziging nodig is. Wij begrijpen de intentie Rijk, provinciaal en gemeentelijk niveau samen te brengen, maar is dat op basis van een verzoek of wens uit een van die geledingen gekomen?
Specifieker willen wij hier graag de vraag voorleggen: welk probleem zal met MDTO opgelost worden? Want als wij nu reageren, denken wij graag mee in die oplossingsrichting.
Kunnen te behalen voordelen genoemd worden, welke wij nu - eerlijk gezegd - niet direct zien, vanuit TMLO bekeken.
Onze inhoudelijke reactie en die van de archiefvormers uit ons werkgebied volgt nog.
@ Mathé,
Ik verwijs je hiervoor naar eerdere blogs op KIA:
- Uit juli 2019, over de aangepaste en ook nu nog gevolgde strategie voor de doorontwikkeling van (toen nog) TMLO ;
- Uit december 2018, met een uiteenzetting over de (nu achterhaalde) strategie voor de doorontwikkeling
De laatste van die twee blogs bevat een link naar een document met daarin een opsomming van knelpunten in het gebruik van TMLO/TMR en mogelijke oplossingsrichtingen voor die knelpunten.
Ook wordt daar een consultatieronde genoemd om de knelpunten en oplossingsrichtingen te verifiëren. Als onderdeel van de consultatie is in februari 2019 ook een toelichting op de strategie en de knelpunten en oplossingsrichtingen gegeven tijdens een ADI bijeenkomst, nota bene bij het RA Tilburg. Knelpunten en oplossingsrichtingen werden daar door de aanwezigen onderschreven.
Mvg,
Wout
Dag Erik,
Reviewformulier MDTO_AC 24apri20 KIA.xlsxIn de bijlage vind je de reactie van de Architectuurcommmissie van NA-RHC's. We hebben in Architectuurcommissie opmerkingen verzameld voor de openbare review MDTO, en via deze weg willen we de reactie ook openbaar delen.
Als ik een paar generieke reacties eruit licht:
1. MDTO komt vrij snel naar de invoering van TopX/TMLO. De archiefvormers zijn nauwelijks gewend aan TopX/TMLO en moeten nu al weer over naar een nieuwe standaard?
- En in het verlengde hiervan: Het introduceren van een nieuwe standaard zal er voor zorgen dat archiefvormers een afwachtende houding gaan aannemen
2. Is dit het goede moment om een nieuwe nationale standaard te introduceren terwijl er internationaal een standaard ontwikkeld wordt met min of meer dezelfde scope (RiC-O)?
- En in het verlengde hiervan: een specifiek Nederlandse standaard is niet aantrekkelijk voor leveranciers en maakt de gebruikers afhankelijk van een hele kleine specifiek Nederlandse markt. Veroorzaakt sneller een vendor-lock-in.
- En: is MDTO compatible met ISAD-G en de andere ICA standaarden en hun uitwisselingsformatien (met name EAD, en EAC-CPF)?
3. De relatie tussen MDTO en de archiefwet- en regeling is niet expliciet aangegeven. TMLO was 1 op 1 te relateren aan de archiefwet- en regeling
Vriendelijke groet,
Hans Laagland
(voorzitter Architectuurcommmissie van NA-RHC's)
Hans, Bedankt voor jullie reactie. We zullen bij het verwerken van het commentaar aangeven hoe we de reacties van de architectuurcommissie verwerken. Hier alvast een snelle reactie op de genoemde punten.
1) De meningen verschillen of MDTO snel komt. Er zijn ook mensen die vinden dat het al veel te lang duurt. TMR 1.0 komt uit 2009 en TMLO 1.1 uit 2014. Dus heel erg snel is dat ook weer niet. Maar maatgevend hier is of er inhoudelijke redenen zijn voor aanpassingen. We hebben vooraf een consultatieronde gedaan om vast te stellen dat de wens voor een nieuwe versie breed leeft. Ik kan me overigens voorstellen dat die redenen meer bij de archiefvormers liggen dan bij de RHC's.
2) RiC-O is nog niet af. Dus daar kunnen we nog niet op bouwen. Daarnaast lijkt RiC-O (en de andere internationale archiefstandaarden) inhoudelijk vooral op archiefinstellingen gericht, niet op archiefvormers. En archiefvormers zitten nadrukkelijk wel in de scope van MDTO (want daar komen de metagegevens immers vandaan). We hebben overigens in de redactiegroep besproken of RiC-O een goed alternatief zou zijn. Daar waren de leden niet enthousiast over. We kijken wel naar een mogelijke mapping tussen MDTO-RDF en RiC-O. Dat maakt het dan mogelijk voor archiefsinstellingen beide standaarden naast elkaar te gebruiken.
3) Goed punt. Zullen we naar kijken.