Op 1 maart 2024 is MDTO versie 1.0 aangemeld voor opname op de ’pas toe of leg uit’-lijst van het Forum Standaardisatie. Het Forum Standaardisatie heeft op 2 oktober 2024 ingestemd met het intakeadvies MDTO om de standaard in procedure te nemen voor plaatsing op deze 'pas toe of leg uit'-lijst. Een volledig expertonderzoek is aangewezen om de standaard te toetsen aan de criteria voor opname op de lijst. Het onderzoek hiervoor loopt momenteel.
Deze versie omvat alle modules die op dat moment samen het normerende deel van MDTO vormen.
Het is mogelijk dat modules van dit normerende deel van MDTO worden doorontwikkeld en dat die doorontwikkeling in nieuwe versies van die modules resulteert. Deze eventuele nieuwe versies maken dus geen deel uit van de versie die bij het Forum Standaardisatie is ingediend. Net zomin als de niet-normerende onderdelen van MDTO. Die doorontwikkelde en volledige versie van MDTO is ook gepubliceerd op de website van het Nationaal Archief.
Versie 1.0 van MDTO bestaat uit de statische versies van de volgende documenten die verder op deze pagina zijn opgenomen:
- Metagegevensschema: Beschrijving van de structuur, de relaties en betekenis van de metagegevens, en de waarden die zijn toegestaan.
- Begrippenlijsten: Specificatie van de begrippenlijsten die binnen het metagegevensschema gebruikt worden om de mogelijke waarden van bepaalde metagegevens aan te geven.
- XML-schema: Beschrijving van de XML-syntax waarin de metagegevens conform het metagegevensschema uitgewisseld worden. In de vorm van een XML Schema Definition (XSD), als tekst en als HTML, met daarbij een toelichting en voorbeelden.
- Specificatie Submission Information Package: Een Submission Information Package (SIP) is een verzameling informatieobjecten met bijbehorende representaties en metagegevens. Een SIP is bedoeld om informatieobjecten uit te wisselen tussen informatiesystemen.
- Definitie van MDTO-conform: Uitleg wanneer een informatiesysteem aan MDTO voldoet.
Bovenstaande documenten vormen samen de normatieve specificatie van versie 1.0 van de MDTO-standaard. De MDTO-standaard wordt beheerd zoals beschreven in het (MDTO-addendum bij het) niet-normatieve beheerplan.
---
#Metagegevensschema
Wat is een metagegevensschema?
Een metagegevensschema beschrijft de structuur, betekenis en regels waar bepaalde metagegevens aan moeten voldoen. Of zoals geformuleerd in NEN-ISO 23081 een “logische structuur die het verband aangeeft tussen elementen van metagegevens, doorgaans door regels vast te stellen voor het gebruik en beheer van metagegevens, vooral met betrekking tot de semantiek, de syntaxis en de keuzevrijheid (mate van verplichting) van waarden."
Een metagegevensschema kan voor verschillende doeleinden gebruikt worden, zoals:
- Het ontwerpen of inrichten van de metagegevensfuncties van een informatiesysteem. Een metagegevensschema beschrijft de structuur van de metagegevens. Op basis daarvan kunnen de functies voor opslag, invoeren, wijzigen en tonen van de metagegevens ontworpen worden.
- De uitleg van de betekenis van metagegevens. Bijvoorbeeld in een handleiding of als verklarende tekst in een gebruikersinterface.
- De validatie van metagegevens. Het metagegevensschema beschrijft de regels waaraan de metagegevens moeten voldoen. Op basis daarvan kunnen de metagegevens gecontroleerd worden.
MDTO beschrijft in de basis de metagegevens die behoren bij informatieobjecten en bestanden. Daarnaast beschrijft MDTO een aantal objecten die binnen de context van informatieobjecten van belang zijn.
Objecten
Alles uitklappenMDTO maakt onderscheid tussen verschillende soorten objecten waaraan metagegevens verbonden zijn:
- Informatieobject: Een op zichzelf staand geheel van gegevens met een eigen identiteit. Zoals een tekstdocument of een foto. Zie de definitie van Informatieobject voor een nadere toelichting.
- Bestand: Een geordende verzameling van gegevens in elektronische vorm, die door een elektronisch apparaat onder één naam kan worden behandeld en aangesproken. Zoals een Word-bestand of MPEG-bestand. Zie ook de definitie van Bestand.
- Bedrijfsactiviteit: een taak die wordt uitgevoerd door een organisatie (Bron: NEN-ISO 30300:2020). Zie ook de specificatie van Bedrijfsactiviteit.
- Actor: Persoon, groep, organisatie of functionaris. Zie ook de specificatie van Actor.
- Locatie: Fysieke plaats in de ruimte. Zie ook de specificatie van Locatie.
Bedrijfsactiviteit, Actor en Locatie worden gezamenlijk aangeduid als contextobjecten.
In het onderstaande diagram zijn de in MDTO gespecificeerde relaties tussen de verschillende objecten weergegeven:
* deze relaties zijn onderdeel van een gegevensgroep.
Een informatieobject kan samengesteld zijn uit andere informatieobjecten. Dit wordt een aggregatie genoemd. Een archief omvat bijvoorbeeld alle informatieobjecten van één organisatie of persoon. Een dossier bevat alle informatieobjecten die op een bepaald onderwerp betrekking hebben. Een website bevat meerdere webpagina’s en een e-mail kan bijlagen bevatten. MDTO gaat ervan uit dat metagegevens bij elk aggregatieniveau zijn vastgelegd.
Het is niet eenduidig wanneer een informatieobject als aggregatie beschouwd wordt. Bijvoorbeeld:
- Is een e-mail met een bijlage een ongedeeld informatieobject? Of is het een aggregatie met als onderdelen de tekst van de mail en de bijlage?
- Is een database met persoonsbeschrijvingen een ongedeeld informatieobject? Of is het een aggregatie met als onderdelen de beschrijvingen van alle individuele personen?
- Is een wet een ongedeeld informatieobject? Of is het een aggregatie met als onderdelen de artikelen in de wet?
- Is een verzameling van versies van een tekstdocument een ongedeeld informatieobject? Of is het een aggregatie met als onderdelen de losse versies?
Of een informatieobject wordt beschouwd als ongedeeld of als een aggregatie is een keuze waar MDTO geen regels voor geeft. Maar deze keuze heeft wel consequenties voor de metagegevens. Als een informatieobject als ondeelbaar wordt beschouwd, dan is het niet mogelijk om in MDTO-metagegevens onderscheid te maken tussen onderdelen van het informatieobject. Bijvoorbeeld als de versies van een tekstdocument geen afzonderlijke informatieobjecten zijn, dan hebben ze ook geen eigen creatiedatum. En als een wet of besluit ondeelbaar is, dan kunnen de artikelen geen eigen geldigheidsduur hebben. Als een mail ondeelbaar is, dan kunnen er voor de bijlage geen afzonderlijke beperkingen op de openbaarheid gelden.
MDTO kent geen overerving van metagegevens (attribuutwaarden) tussen aggregatieniveaus. Dit betekent dat bij de uitwisseling van MDTO-metagegevens attribuutwaarden op elk aggregatieniveau opgenomen moeten zijn.
Wanneer overerving van metagegevens wordt toegepast is het door de tijd heen moeilijker te waarborgen dat individuele informatieobjecten alle gegevens bevatten. Dit wordt met name een probleem als de informatieobjecten buiten de grenzen van het systeem komen waarin zij zijn aangemaakt.
Omdat MDTO geen eisen stelt aan de manier waarop metagegevens worden vastgelegd, is het wel toegestaan om bij het vastleggen van de metagegevens overerving toe te passen. Mits zij bij de uitwisseling van deze metagegevens wel op elk aggregatieniveau worden genoemd. Een archiefvormer kan in een informatiesysteem bijvoorbeeld alleen op het hoogste aggregatieniveau worden vastgelegd. Bij een uitwisseling dient de archiefvormer dan wel op elk aggregatieniveau vermeld te worden.
MDTO maakt onderscheid tussen een informatieobject als eenheid van informatie ongeacht de vorm, en de specifieke vorm waarin deze informatie wordt gerepresenteerd. Bestanden zijn één vorm van representatie (ook wel manifestatie genoemd). Maar een representatie kan bijvoorbeeld ook een papieren stuk of een videotape zijn. Andere vormen dan bestanden worden in MDTO verder niet behandeld.
De metagegevens die MDTO specificeert voor een informatieobject zijn onafhankelijk van haar representaties. Zoals de titel of auteur. De metagegevens die MDTO specificeert voor een bestand hebben specifiek betrekking op die representatie. Zoals het aantal bytes en het bestandsformaat. Door de metagegevens van informatieobject en representatie van elkaar te scheiden hoeven de representatieonafhankelijke metagegevens slechts één keer vastgelegd te worden. En kunnen in een later stadium gemakkelijk representaties toegevoegd worden aan een informatieobject.
Een informatieobject kan meerdere representaties hebben. Bijvoorbeeld een tekst kan gerepresenteerd worden door een Word-bestand én een PDF-bestand. Of een afbeelding door een bestand met hoge resolutie én een bestand met lage resolutie. De bestanden zijn verschillend, maar de informatie is dan hetzelfde. Om een informatieobject duurzaam toegankelijk te maken en houden, kan het nodig zijn om deze verschillende representaties te onderscheiden. Bijvoorbeeld omdat in de loop van de tijd een bestandsformaat niet meer ondersteund wordt. Of een PDF-bestand voor menselijke lezing en een XML-bestand voor machinale verwerking.
Het is ook mogelijk dat een informatieobject opgedeeld is in meerdere representaties. Bijvoorbeeld losse bestanden voor elke pagina van een gescand tekstdocument. Of een notitie als los bestand voor elke versie. Of een webpagina als een HTML-bestand en bestanden voor de afbeeldingen op de pagina. De representaties bevatten dan niet dezelfde inhoud.
Meestal is het zo dat representaties gekoppeld zijn aan een ongedeeld informatieobject. Maar ook aggregaties kunnen representaties hebben. Bijvoorbeeld een mailbox die beschouwd wordt als een aggregatie van mappen en daarbinnen mailberichten, kan als geheel gerepresenteerd worden door een Outlook-gegevensbestand (.pst-bestand). Of een website die beschouwd wordt als een aggregatie van webpagina’s, kan als geheel gerepresenteerd worden door een Web ARChive-bestand (WARC).
MDTO specificeert alleen metagegevens voor informatieobjecten en bestanden. Maar onderscheidt daarbij wel verschillende soorten contextobjecten: bedrijfsactiviteit, actor en locatie. Omdat daar, vanuit de metagegevens van informatieobjecten, naar verwezen kan worden. Zoals naar de auteur van een tekstdocument of de locatie waar een informatieobject betrekking op heeft. Van deze contextobjecten worden, anders dan naam en identificatie, geen gegevens gespecificeerd in MDTO.
De structuur van metagegevens
Alles uitklappenIn MDTO is een enkel metagegeven bij een object gestructureerd als een attribuut-waardepaar. Bijvoorbeeld:
- naam: ‘Rapport NL Digitaal - Data Agenda Overheid’ (bij een tekstdocument)
- omvang: 324534 (aantal bytes van een bestand)
Het attribuut in het paar is een eigenschap die een object kan hebben. Bijvoorbeeld “naam, ”omschrijving”, of “omvang”. In MDTO wordt een attribuut aangeduid met een tekenreeks zonder spaties.
De waarde in het paar is de waarde van het attribuut voor een specifiek object. Bijvoorbeeld “Jan de Boer” of “1802-06-17”. In MDTO kan de waarde van een attribuut bestaan uit:
- Een enkelvoudig gegeven.
- Een gegevensgroep (waaronder ook een begrip of een verwijzing).
In de attribuutspecificaties van MDTO wordt beschreven welke attribuut-waardeparen binnen MDTO voorkomen.
Een enkelvoudig gegeven is een gegeven dat binnen MDTO niet verder gestructureerd is. De enkelvoudig gegevens vormen de basis van de metagegevens. De enkelvoudige gegevens in MDTO hebben de vorm van een XML built-in datatype (zie XML Schema Part 2: Datatypes). Bijvoorbeeld:
- ‘Jan de Boer’ (een string)
- 125000 (een integer)
- 2021-01-18 (een datum)
Een gegevensgroep is een samengesteld gegeven dat bestaat uit een opsomming van attribuut-waardeparen. Een waarde kan zelf ook een gegevensgroep zijn, in dat geval is er sprake van nesting). Gegevensgroepen worden gebruikt als er meerdere enkelvoudige gegevens nodig zijn om de waarde van een attribuut weer te geven. Bijvoorbeeld:
- identificatie:
kenmerk: ‘9789047706205’
bron: ‘ISBN’
- checksum:
waarde: ‘2C2D00B7ADC331709202290B7626D42759447800306307F452CE150E42CFB762’
algoritme: ‘SHA-256’
datum: ‘2011-04-13T21:11:18’
- betrokkene:
type relatie: ‘rechthebbende’
naam: ‘Architectenbureau Janssen’
identificatie:
kenmerk: ‘99999988’
bron: ‘KVK’
Een verwijzing is een speciale gegevensgroep die gebruikt wordt om te verwijzen naar een ander object. Bijvoorbeeld een informatieobject die een verwijzing naar een representatie (een bestand) of naar een auteur (een actor) heeft. Een attribuut waarvan de waarde een verwijzing is wordt ook wel een relatie genoemd.
Een verwijzing heeft de volgende attributen:
- Naam: Een naam waarmee het object aangeduid wordt. Bedoeld voor menselijke lezing. Bijvoorbeeld “Jan de Boer” voor een actor, “Behandelen bouwvergunningen” voor een activiteit of “Binnenhof 1, 2513 AA Den Haag” voor een locatie. Omdat een naam niet uniek hoeft te zijn, kan het dubbelzinnig zijn welke object aangeduid wordt.
- Identiteit: Een of meerdere unieke identiteitskenmerken waarmee het object aangeduid wordt. Bedoeld voor menselijke of machinale lezing. Omdat de identificatie uniek is, wordt hiermee eenduidig het object aangeduid. Bij voorkeur is de identiteit zodanig dat op grond hiervan de metagegevens over het object gelokaliseerd kunnen worden. Maar MDTO stelt dat niet als eis.
Zie de specificatie van de gegevensgroepklasse verwijzingGegevens en de bijbehorende attributen voor de volledige beschrijving.
Een begrip is een speciale gegevensgroep die gebruikt wordt voor waarden waarvan de betekenis is vastgelegd in een zogenaamde begrippenlijst. Een begrip wordt gedefinieerd als een eenheid van denken (‘concept’ in NEN-ISO 25964-1:2011). Begrippen hebben een betekenis en onderlinge semantische relaties die zijn vastgelegd in een begrippenlijst. Een begrip kan over elk concreet of abstract ding gaan waar we woorden aan geven en over communiceren. Begrippen worden in MDTO gebruikt als attribuutwaarde als het gewenst is de betekenis van die waarde vast te leggen. Zodat voor iedereen duidelijk is hoe die waarde geïnterpreteerd moet worden. Zoals de aanduidingen van informatietypes, categorieën in een classificatieschema of de categorieën in een selectielijst. Een begrippenlijst wordt ook wel een gecontroleerde woordenlijst genoemd.
Een begrip heeft de volgende attributen:
- label: De tekstweergave van het begrip dat is toegekend in de begrippenlijst.
- code: De code die aan het begrip is toegekend in de begrippenlijst.
- begrippenlijst: Verwijzing naar het informatieobject (de begrippenlijst) waarin de betekenis van het begrip is vastgelegd.
Zie de specificatie van de gegevensgroepklasse begripGegevens en de bijbehorende attributen voor de volledige beschrijving.
Een klasse is een verzameling objecten (een objecttype), enkelvoudige gegevens (een datatype) of gegevensgroepen (een gegevensgroeptype). MDTO gebruikt klassen om vanuit de attribuutspecificaties te kunnen verwijzen naar een verzameling. Verder hebben klassen geen speciale betekenis binnen MDTO.
Een klassespecificatie van objecten binnen MDTO bestaat uit de volgende onderdelen:
| Onderdelen | Beschrijving |
|---|---|
| Naam | De naam van de klasse. Deze wordt gebruikt om naar de klasse te verwijzen. De naam is een tekenreeks zonder spaties. Voor objectklassen wordt de naamgevingsconventie UpperCamelCase gebruikt. |
| Definitie | Beschrijving van de betekenis van de klasse. |
| Regels | Nadere eisen waaraan moet worden voldaan. |
| Overerft van | Vermelding van de bovenliggende klasse waarvan de attributen worden overerft. (Merk op dat MDTO geen overerving van attribuutwaarden van bovenliggende aggregatieniveaus kent.). |
| Attributen | Opsomming van de attributen die in MDTO voor deze klasse zijn gespecificeerd. |
| Toelichting | Nadere toelichting op de definitie. De toelichting is alleen bedoeld ter verduidelijking en bevat geen extra eisen aan het object. |
| Voorbeelden | Voorbeelden van elementen van de klasse. |
Een attribuutspecificatie beschrijft de betekenis en de toegestane waarden van een attribuut dat in MDTO-metagegevens voor kan komen.
Een attribuutspecificatie bestaat uit de volgende onderdelen:
| Onderdelen | Beschrijving |
|---|---|
| Naam | De naam van het attribuut. Deze wordt gebruikt om naar het attribuut te verwijzen. De naam is een tekenreeks zonder spaties. Voor attributen wordt de naamgevingsconventie lowerCamelCase gebruikt. |
| Label | De naam van het attribuut voor menselijke lezing. |
| Domein | De klasse van objecten of gegevensgroepen waar dit attribuut een waarde voor kan hebben. |
| Bereik | De klasse(n) van waarden die toegestaan zijn voor het attribuut. Dit kan een datatype of een gegevensgroepklasse zijn. In een aantal gevallen zijn meerdere datatypen toegestaan. Als het bereik “Verwijzing” is, dan is daarbij ook aangegeven naar welke klasse objecten verwezen wordt door dit attribuut. Bijvoorbeeld “Verwijzing (Bestand)” is een verwijzing naar een bestand”. |
| Doel | Waarom het van belang is om dit attribuut op te nemen in metagegevens. Vanuit het perspectief van duurzame toegankelijkheid. Bij de attributen van een gegevensgroep wordt geen doel vermeld. |
| Definitie | De betekenis van het attribuut. |
| Begrippenlijst | Als het bereik “begripGegevens” is, dan is hier aangegeven welke begrippenlijsten zijn toegestaan voor dit attribuut. Mogelijk zijn:
|
| Verplichting | Of het attribuut een waarde moet hebben. Mogelijk zijn:
|
| Herhaalbaar | Of het attribuut voor een object meerdere waarden mag hebben. Mogelijke waarden “ja” of “nee”. |
| Regels | Nadere eisen waar de waarden van dit attribuut aan moeten voldoen. Hierin kan verwezen worden naar waarden van andere attributen. |
| Toelichting | Waar nodig, een toelichting ter verduidelijking van de specificatie. Een toelichting is alleen ter verduidelijking en bevat geen extra eisen. |
| Voorbeelden | Voorbeelden van mogelijke waarden. De voorbeelden zijn alleen ter verduidelijking en bevatten geen extra eisen. Als het bereik een gegevensgroepklasse is, dan bevat de specificatie meestal geen voorbeelden. Die zijn dan opgenomen bij de attributen van de gegevensgroep. |
De volgende datatypen worden gebruikt in de attribuutspecificaties van MDTO.
Alle datatypen zijn ingebouwde (built-in) datatypen gedefinieerd in XML Schema.
| Naam | Toelichting |
|---|---|
| #date | Datum uitgedrukt als YYYY-MM-DD conform ISO 8601. Voorbeeld: 1976-06-13 (13 juni 1976) |
| #gYear | Periode van één kalenderjaar conform ISO 8601. Voorbeeld: 1993 |
| #gYearMonth | Periode van één kalendermaand in een specifiek jaar conform ISO 8601. Voorbeeld: 2001-11 (November 2001) |
| #dateTime | Datum- en tijd uitgedrukt in YYYY-MM-DDThh:mm:ss conform ISO 8601. Voorbeeld: 2014-07-24T08:03:01 (24 juli 2014 8 uur, 3 minuten en 1 seconde) |
| #duration | Periode in tijd uitgedrukt conform ISO 8601. Voorbeeld: P70Y (70 jaar), Of P0Y0M14D (14 dagen) |
| #anyURI | URI conform RFC 3987. URI staat voor Unique Resource Identifier. Het is een gestandaardiseerde manier om te verwijzen naar een stuk data (zoals webpagina’s met informatie, objecten en datasets) en hier direct toegang toe te geven. Een URL is een voorbeeld van een URI. Voorbeeld: https://www.example.com |
| #language | Identificatiekenmerk van een natuurlijk taal conform RFC 3066. Voorbeeld: nl (Nederland) |
| #string | Een reeks tekens of karakters. Een lege string wordt opgevat als een ontbrekende waarde. In MDTO zijn lege strings daarom niet toegestaan. Voorbeeld: “abc 123” |
| #integer | Geheel getal, lengte is minimaal 1 en maximale lengte is onbepaald, zonder voorloopnullen. Subtype van ISO Number (ISO 11404). Voorbeeld: 23042 |
---
#Begrippenlijst metagegevensschema
Type begrippenlijst: Open
Deze begrippenlijst wordt gebruikt binnen het attribuut aggregatieniveau
| Label | Definitie |
|---|---|
| Archief | Geheel van informatieobjecten, ontvangen of opgemaakt door een archiefvormer. |
| Serie | Verzameling van dossiers, fysieke archiefbestanddelen en/of stukken, numeriek, alfabetisch, chronologische of logisch geordend, ontstaan vanuit een identieke "handeling", dan wel een identieke vorm hebbend dan wel verwante inhoud bevattend. |
| Dossier | Geheel van fysieke of virtueel gekoppelde informatieobjecten die op één onderwerp betrekking hebben. |
| Archiefstuk | Enkelvoudig informatieobject of informatie-eenheid. Enkelvoudig wil zeggen dat het stuk niet meer dan één component bevat. |
Type begrippenlijst: Open
Deze begrippenlijst wordt gebruikt binnen het attribuut eventType
| Label | Definitie |
|---|---|
| Creatie | Creatie van een informatieobject door een auteur. |
| Ontvangst | Ontvangst van een informatieobject door de archiefvormer. |
| Verzending | Verzending van een informatieobject door de archiefvormer. |
| Opname | Opname van een informatieobject in een applicatie met de bijbehorende metagegevens. De opname vindt bijvoorbeeld plaats na creatie of ontvangst en wordt gerealiseerd door registratie en opslaan. |
| Digitalisering | Het scannen van een fysiek informatieobject, waardoor een digitaal informatieobject ontstaat. |
| Vervanging | Formele vervanging van een informatieobject door een ander informatieobject, waarbij het vervangende informatieobject de plaats en archiefwettelijke status overneemt en het originele informatieobject die plaats en status verliest. |
| Bevriezing | ’Bevriezen’ van het Informatieobject, waarna geen wijzigingen meer zijn toegestaan. Voorbeelden zijn afsluiten van dossier of afronden van een tekstdocument. |
| Conversie | Omzetting van het Informatieobject van het ene naar het andere formaat. |
| Export | Exporteren van een informatieobject en de metagegevens uit de applicatie. |
| Import | Importeren van een informatieobject met de metagegevens uit de applicatie. |
| Kopie | Kopiëren van een informatieobject met de metagegevens binnen de applicatie zodat een nieuw informatieobject bestaat. NB. Unieke metagegevens worden bij een kopie wel gewijzigd. |
| Migratie | Verplaatsen van het Informatieobject van de ene hard- en/of softwareconfiguratie naar een andere, zonder het formaat te wijzigen. |
| Vernietigen | Vernietigen van informatie is het blijvend ontoegankelijk maken van die informatie, waardoor deze niet meer vindbaar, beschikbaar, leesbaar, interpreteerbaar en betrouwbaar is. |
| Overbrenging | Formeel overbrengen van het Informatieobject en bijbehorende metagegevens naar een archiefbewaarplaats, waarbij het zorgdragerschap ook wordt overgedragen. |
| Uitplaatsing | Uitplaatsen van een informatieobject en bijbehorende metagegevens naar een beheeromgeving buiten de eigen organisatie, zonder daarbij het zorgdragerschap over te dragen. |
| Wijziging | Wijzigen van het Informatieobject of de bijbehorende metagegevens. |
| Publicatie | Publiceren van het Informatieobject en bijbehorende metagegevens, bijvoorbeeld op een openbare webpagina. |
| Accordering | Het accorderen van een informatieobject. Dit kan bijvoorbeeld door een digitale handtekening. |
| Validatie Handtekening | Controle of de digitale handtekening daadwerkelijk door de desbetreffende Actor is gezet. |
Type begrippenlijst: Gesloten
Deze begrippenlijst wordt gebruikt binnen het attribuut waardering.
| Code | Label | Definitie |
|---|---|---|
| B | Blijvend te bewaren | Het Informatieobject dient blijvend bewaard te worden. |
| V | Tijdelijk te bewaren | Het Informatieobject dient tijdelijk bewaard te worden en na afloop van de bewaartermijn vernietigd te worden. |
| N | Nader te bepalen | Er is mogelijk een waardering. Maar de aard daarvan is niet vastgelegd als type waardering en niet vastgelegd in de metagegevens. |
Type begrippenlijst: Open
Deze begrippenlijst wordt gebruikt binnen het attribuut betrokkeneTypeRelatie.
| Label | Definitie |
|---|---|
| Belanghebbende | De persoon of organisatie die een belang heeft bij de inhoud van het Informatieobject. Bijvoorbeeld als iemand het onderwerp is van een Informatieobject. Of wanneer het Informatieobject een besluit betreft die het belang van een persoon of organisatie direct of indirect treft. |
| Indiener | Indiener van een verzoek of aanvraag waar het Informatieobject betrekking op heeft. |
| Rechthebbende | Degene die een wettelijk recht op het Informatieobject kan laten gelden. Zoals auteurs- of portretrecht. |
Type begrippenlijst: Open
Deze begrippenlijst wordt gebruikt binnen het attribuut gerelateerdInformatieobjectTypeRelatie.
| Label | Betekenis | Overeenkomstig Dublin Core label |
|---|---|---|
| Heeft Versie | Een gerelateerd object dat een versie, editie of een aanpassing is van het beschreven object. | dcterms:hasVersion |
| Wordt aangehaald door | Een gerelateerd object dat refereert aan, citeert of op een andere wijze verwijst naar het beschreven object. | dcterms:isReferencedBy |
| Is vervangen door | Een gerelateerd object dat het beschreven object vervangt, verdringt of opvolgt. | dcterms:isReplacedBy |
| Is vereist door | Een gerelateerd object dat het beschreven object nodig heeft ter ondersteuning van de functie, levering of coherentie. | dcterms:isRequiredBy |
| Is een versie van | Een gerelateerd object waarvan het beschreven object een versie, editie of een aanpassing is. | dcterms:isVersionOf |
| Refereert aan | Een gerelateerd object waarnaar wordt gerefereerd, uit wordt geciteerd of op een andere wijze naar wordt verwezen door het beschreven object. | dcterms:references |
| Vervangt | Een gerelateerd object dat wordt vervangen, verdrongen of opgevolgd door het beschreven object. | dcterms:replaces |
| Heeft nodig | Een gerelateerd object wat het beschreven object nodig heeft ter ondersteuning van de functie, levering of coherentie. | dcterms:requires |
Type begrippenlijst: Open
Deze begrippenlijst wordt gebruikt binnen het attribuut beperkingGebruikType.
| Label | Definitie |
|---|---|
| Geen beperking | Er rust geen beperking op het gebruik van het informatieobject. |
| Nader te bepalen | Er is mogelijk een beperking. Maar de aard daarvan is niet vastgelegd als type beperking en niet vastgelegd in de metagegevens. |
| Overig | Niet nader gespecificeerde beperking. Deze waarde wordt gebruikt als er geen andere geschikt type gedefinieerd is en er in de documentatie wel een beperking is omschreven. |
Type begrippenlijst: Open
Deze begrippenlijst wordt gebruikt binnen het attribuut checksumAlgoritme.
| Label | Definitie |
|---|---|
| SHA-224 | Cryptografisch hashalgoritme ten behoeve van authenticatie en integriteitscontrole. Zie https://www.forumstandaardisatie.nl/open-standaarden/sha-2 |
| SHA-256 | Cryptografisch hashalgoritme ten behoeve van authenticatie en integriteitscontrole. Zie https://www.forumstandaardisatie.nl/open-standaarden/sha-2 |
| SHA-384 | Cryptografisch hashalgoritme ten behoeve van authenticatie en integriteitscontrole. Zie https://www.forumstandaardisatie.nl/open-standaarden/sha-2 |
| SHA-512 | Cryptografisch hashalgoritme ten behoeve van authenticatie en integriteitscontrole. Zie https://www.forumstandaardisatie.nl/open-standaarden/sha-2 |
---
#XML-Schema
Dit gedeelte beschrijft welke documenten de documentatieset bevat en hoe het XML-schema is afgeleid van het MDTO metagegevensschema.
Inhoud documentatieset
De documentatieset bestaat uit de volgende links en mappen in een .zip bestand.
- MDTO-XML 1.0.1.xsd: Het XML-schema. (Eerdere versie MDTO-XML 1.0.xsd)
- MDTO-XML 1.0.1.html: Weergave van het schema als HTML-pagina. Bedoeld voor lezers die geen speciale viewer voor XML-schema’s hebben. (Eerdere versie MDTO-XML 1.0.html)
- MDTO-XML 1.0.1 Voorbeelden: Map met voorbeelden van XML-bestanden conform het XML-schema.
Aanwijzing voor gebruik:
- Sla het .zip bestand op op uw computer
- Pak het .zip bestand uit en sla daarbij het bestand op op uw computer
- Open het bestand met de juiste applicatie vanuit de bestandenmap op uw computer
Documentatieset MDTO-XML
Toelichting op de voorbeelden
De voorbeeldbestanden zijn ter informatie en maken geen onderdeel uit van de definitie van het XML-schema en zijn dus ook geen onderdeel van de norm. Het doel van de voorbeelden is dat de lezer zich een voorstelling kan maken hoe een XML-bestand conform het XML-schema er uit kan zien. De voorbeelden zijn zo realistisch mogelijk. Maar om alle mogelijkheden te demonstreren zijn er soms waarden en combinaties van waarden gekozen die in de praktijk niet zo snel voor zullen komen.
De volgende voorbeelden zijn opgenomen:
- MDTO-XML 1.0.1 Voorbeeld Serie Informatieobject.xml:
Metagegevens voor de serie “Vergunningen van de gemeente 's-Gravenhage vanaf 1980”. - MDTO-XML 1.0.1 Voorbeeld Dossier Informatieobject.xml:
Metagegevens voor het dossier “Kapvergunning Hooigracht 21 Den Haag”. - MDTO-XML 1.0.1 Voorbeeld Archiefstuk Informatieobject.xml:
Metagegevens voor het informatieobject “Verlenen kapvergunning Hooigracht 21 Den Haag” in het dossier “Kapvergunning Hooigracht 21 Den Haag”. - MDTO-XML 1.0.1 Voorbeeld Bestand.xml:
Metagegevens voor het bestand “20090101KapvergunningHooigracht.pdf” dat de representatie is van “Verlenen kapvergunning Hooigracht 21 Den Haag”.
De hiërarchische relaties tussen de voorbeelden staan weergegeven in het volgende schema:
Relatie tussen het MDTO metagegevensschema en het MDTO-XML schema
Het XML-schema is op de volgende manier afgeleid van het metagegevensschema:
Op het hoogste niveau bevat het schema één element “MDTO” van het type “mdtoType”. Dit element is bedoeld om te markeren dat het XML-bestand MDTO-metagegevens bevat.
Een waarde van het type “mdtoType” is ofwel een element “informatieobject” of een element “bestand”. Dit zijn de twee mogelijkheden die voor mogen komen in een XML-bestand met MDTO-metagegevens.
Voor elk object of gegevensgroep uit het metagegevensschema bevat het XML-schema een corresponderend <complexType> waarvan de naam eindigt op “Type”.
Elk object in MDTO bevat in ieder geval een identificatie en een naam. Deze attributen zijn bij objectType opgenomen en wordt als basis gebruikt van informatieobjectType en bestandType d.m.v. <xsd:extension base=”objectType”>.
Elke complextype bevat een <sequence> met daarin voor elk bijbehorend attribuut uit het metagegevensschema een <element>-definitie. Dat wil zeggen voor elk attribuut met het betreffende object of gegevensgroep als domein.
Voor elk attribuut bevat de <element>-definitie:
name = naam van het attribuut.
type = het bereik van het attribuut.
minOccurs = ondergrens van de kardinaliteit van het attribuut .
maxOccurs = bovengrens van de kardinaliteit van het attribuut.
<annotation><documentation> = definitie van het attribuut.
---
#Specificatie Submission Information Package
Deze module is in combinatie te gebruiken met de specificatie aanlevering aan een e-depot. Het biedt een standaard werkwijze voor de aanlevering van informatie van een bronsysteem naar een doelsysteem.
Deze module beschrijft de structuur van het Submission Information Package (SIP) dat nodig is voor de uitwisseling van informatieobjecten en bestanden tussen een bronsysteem en doelsysteem.
Het aanleveren van digitaal archief van een archiefvormer van een DMS naar een E-depot van een archiefinstelling is een voorbeeld van een dergelijke uitwisseling. Een ander voorbeeld is het uitwisselen van informatie tussen ketenpartners, bijvoorbeeld van DMS naar DMS.
Structuur van een Submission Information Package (SIP)
In de afbeelding is een voorbeeld van de structuur weergegeven van de informatieobjecten en bestanden in een SIP. Elk informatieobject kan een aggregatie zijn.
De export uit het bronsysteem moet een sidecar-structuur hebben.
In deze structuur zit de inhoud in een directory-structuur: elk aggregatieniveau van de informatieobjecten is een map. Een bestand kan op elk aggregatieniveau in de map zitten. Ook als daar ook nog een aggregatie van informatieobject beschikbaar is. Denk aan een e-mail met bijlagen of een website met de webpagina’s.
Elk informatieobject en elk bestand heeft zijn eigen MDTO metagegevensbestand. In de sidecar moet het versienummer van de betreffende MDTO-versie zijn opgenomen (zie MDTO.xml).
De plaats van het metagegevensbestand dat bij een aggregatie (map in de SIP) hoort, is in deze aggregatie. De plaats van het metagegevensbestand dat bij een bestand hoort, is naast het bestand.
Een informatieobject is uniek en kan maar één keer in de SIP voorkomen. Er is altijd maar één hiërarchische relatie. De hiërarchische relatie met de bovenliggende aggregatie moet ook meegeleverd worden in de MDTO-metagegevens.
De aggregaties zijn de informatieobjecten die een hiërarchische relatie kennen. Dit is niet de 1 op 1 ordening zoals die in het bronsysteem bestaat. Als een dossier in de ordening in het bronsysteem onder meerdere informatieobjecten valt dan wordt deze maar 1 keer als record in de structuur opgenomen. De originele ordening is te vinden in de relaties.
Elke aanlevering kent in ieder geval één aggregatieniveau. Er is altijd sprake van een informatieobject, met meestal nog een bestand. Er kunnen meer aggregaties geleverd worden, met boven en onderliggende aggregaties.
Elke aanlevering kent een bovenliggende aggregatieniveau in het doelsysteem. Naar dit informatieobject moet in de informatieobjecten die hier direct onder geplaatst worden in de MDTO-metadata een verwijzing zijn opgenomen.
Neem in de pakbon op in welke collectie, bijv. archief, deze aanlevering moet worden geplaatst.
De sidecar met MDTO-metadata bestaat uit een voorgeschreven formaat (XML) en een bestandsnaam. Dit ziet er zo uit: <naam>.MDTO.xml of bij een bestand: <bestandsnaam>.bestand.MDTO.xml.
Elk informatieobject of bestand moet een naam hebben. Deze naam moet in de aanlevering uniek zijn en hoeft niet met de titel overeen te komen. Voor de <informatieobjectnaam>. MDTO.xml of <bestandnaam.extensie>. MDTO.xml geldt in de aanlevering een limiet op het aantal karakters van 255.
De namen van het informatieobject, bestand en de sidecars mogen niet de volgende karakters bevatten: < > : “ / \ | ? * # &.of spatie. Schoon, indien nodig, de informatieobject- en bestandsnamen in de SIP van deze karakters voor aanlevering.
Let op: De titel van een informatieobject staat altijd in de metagegevens. Deze kan wel leestekens bevatten of langer zijn dan 255 karakters. Verwar dit niet met de naam van het informatieobject zoals meegegeven voor de aanlevering.
MDTO metagegevens moeten in een MDTO metagegevensbestand worden aangeleverd. De aanleverende organisatie zorgt ervoor dat waar mogelijk na redelijke inspanning metagegevensvelden een waarde hebben. Dit kan in voorkomende gevallen extra inspanning vragen van de aanleverende organisatie, bijvoorbeeld door het combineren van metagegevens. Verplichte metagegevens moeten altijd worden aangeleverd.
Voor het vullen kan gebruik worden gemaakt van het XML-schema of van de RDF-ontologie.
Met behulp van de .xsd controleert een doelsysteem de aangeleverde MDTO.xml bestanden.
Als naast MDTO ook een set met andere metagegevens meegeleverd wordt bij een informatieobject doet u dat door het toevoegen van een eigen bestand voor elke set van metadata. Zoals voor elk bestand kent dit bestand een sidecar met de MDTO-metadata voor bestand.
Voor elk metadatabestand gelden de volgende eisen:
- Elk bestand maakt gebruik van een gedefinieerde standaard en wordt conform deze standaard opgeleverd. (De standaard mag ook een eigen schema zijn.)
- Elk bestand maakt gebruik van een standaardformaat uit de lijst van voorkeursformaten. Denk hierbij aan: XML, JSON, CSV, RDF.
- Metagegevens die in meerdere sets voorkomen worden in elke metagegevens set meegeleverd. Dus als het veld naam in MDTO en in RGBZ of OWMS voorkomt wordt dit veld in beide standaarden gevuld met de metagegevens.
- Additionele metagegevens voor bestanden zijn enkel technisch van aard (bijv. PREMIS).
- De naamgeving is overeenkomstig de naamgeving van de MDTO.xml bestanden.
De documentatie, zoals een definitiebestand, van een niet-erkende (eigen) standaard of metagegevensschema, levert u als informatieobject mee.
Pakbon
Bij de aanlevering van een export in een SIP levert de aanleverende organisatie een pakbon mee.
De ontvangende partij moet van elke aangeleverde SIP kunnen vaststellen:
- van wie deze afkomstig is
- wat de inhoud is.
Bij de aanlevering van de export in een SIP levert de aanleverende organisatie daarom een zogenaamde pakbon mee. De inhoud en het formaat van aanlevering van de pakbon spreekt u af met uw contactpersoon bij de ontvangende partij. Het formaat varieert van een op .xml gebaseerd bericht tot een e-mail. Hierin staat in ieder geval:
- Uniek identificatienummer.
- Naam/Titel aanlevering.
- Locatie doelsysteem, zoals gecommuniceerd door de ontvangende partij.
- Hashcode SIP, specificatie hashcode wordt geleverd door de ontvangende partij.
- Time stamp creatie SIP.
- Organisatie/Archiefvormer.
- Contactpersoon/ e-mail.
- Aantal informatieobjecten en aantal bestanden.
- Aantal bestanden in de export met extensie ongelijk aan .mdto.xml.
- Omvang van de content in de export in bytes (ofwel de optelsom van de grootte van de bestanden met extensie ongelijk aan .mdto.xml).
- Bijzonderheden materiaal: hier vermelding bijzondere formaten e.d.
NB. De voorkeur gaat uit naar een xml bestand.
Begrippen
Tot slot bevat deze module een begrippenlijst, waarin de belangrijkste begrippen geduid worden.
Bronsysteem: Systeem waar de informatieobjecten voor uitwisseling bewaard worden. Dit omvat alle applicaties tot aan de verzending van de SIP. Bijv. een DMS met een exporttool.
Doelsysteem: Systeem waar de informatie naar verplaatst wordt om bewaard te worden. Dit omvat alle applicaties die gebruikt worden om de SIP te ontvangen en op te nemen. Bijv. een QZ met een E-depot.
Sidecar: xml bestand met bijbehorende metagegevens per informatieobject of bestand
Submission Information Package (SIP): Een set informatieobjecten en bestanden met bijbehorende inhoudelijke en technische metadata, bedoeld voor opname in een doelsysteem.
---
#Definitie van MDTO-conform
Er zijn twee niveaus van MDTO-conform. Minimaal MDTO-conform betekent dat de MDTO-metagegevens zijn vastgelegd en beschikbaar zijn. Maar het zegt niks over de vorm waarin deze metagegevens beschikbaar zijn. Volledig MDTO-conform voegt daaraan toe eisen over de vorm waarin de MDTO-metagegevens beschikbaar zijn en geïmporteerd worden.
Het onderscheid tussen twee niveaus biedt de mogelijkheid om bij regels voor het toepassen van MDTO onderscheid te maken. Bijvoorbeeld door een langere termijn toe te staan waarbinnen een informatiesysteem volledig MDTO-conform moet zijn.
Hieronder wordt met ‘een informatiesysteem voor bepaalde informatieobjecten’ bedoeld een specifiek informatiesysteem en daarbinnen nader beschreven informatieobjecten waarvoor ergens aangegeven is dat deze MDTO-conform (moeten) zijn. Zoals bijvoorbeeld in “DMS-X is voor alle daarin beheerde bestanden, mappen en zaakgegevens volledig MDTO-conform”.
Minimaal MDTO-conform
Een informatiesysteem is voor bepaalde informatieobjecten ‘minimaal MDTO-conform’ als geldt:
- MDTO-metagegevens vastgelegd: Gedurende de gehele levenscyclus worden bij de informatieobjecten de metagegevens vastgelegd die in het MDTO-metagegevensschema verplicht zijn.
- Vertaling naar metagegevensschema: De vastgelegde MDTO-metagegevens kunnen eenduidig en zonder verlies van informatie vertaald worden naar de structuur, betekenis en regels zoals beschreven in het MDTO-metagevensschema (ook wel mapping genoemd).
- Weergave metagegevens: Er is een functie waarmee alle gebruikers van het informatiesysteem bij de informatieobjecten een weergave van de vastgelegde MDTO-metagegevens kunnen opvragen.
- Export metagegevens: Er is een functie waarmee alle gebruikers van het informatiesysteem bij de informatieobjecten een export van de vastgelegde MDTO-metagegevens kunnen opvragen, in een automatisch verwerkbaar formaat.
Volledig MDTO-conform
Een informatiesysteem is voor bepaalde informatieobjecten ‘volledig MDTO-conform’ als het minimaal MDTO-conform is, en de vastgelegde metagegevens op de volgende manieren uitgewisseld kunnen worden:
- Weergave metagegevens: Er is een functie waarmee alle gebruikers van het informatiesysteem bij de informatieobjecten een weergave van de vastgelegde MDTO-metagegevens kunnen opvragen. In deze weergave zijn de metagegevens volgens het metagegevensschema gestructureerd en worden de labels gebruikt zoals aangegeven in het metagegevensschema.
- Export metagegevens: Er is een functie waarmee alle gebruikers van het informatiesysteem bij de informatieobjecten een export van de vastgelegde MDTO-metagegevens kunnen opvragen, in een een XML-bestand conform het XML-schema van MDTO.
- Import metagegevens: Als er een importfunctie is voor de metagegevens bij een informatieobject, dan kunnen deze metagegevens in een XML-bestand conform het XML-schema van MDTO geïmporteerd worden. Waarbij de metagegevens zonder verlies van informatie vastgelegd worden.
- Export of import Submission Information Package: Als er een export- en/of importfunctie is voor SIP’s, dan ondersteunen deze het MDTO SIP-formaat.
Het is toegestaan dat een volledig MDTO-conform informatiesysteem in aanvulling hierop ook op andere manieren metagegevens uitwisselt. Bijvoorbeeld door ook een andere weergavefunctie aan te bieden of bij de export of import van een SIP ook een ander XML-formaat te ondersteunen.
Verplicht indien bekend
Een klein aantal metagegevens is verplicht binnen MDTO (dit is aangegeven in het metagegevensschema). Deze moeten altijd vastgelegd zijn. Voor de rest van de metagegevens geldt ‘verplicht, indien bekend’. Dat betekent dat deze gegevens vastgelegd moeten zijn als ze bekend zijn binnen de verantwoordelijke organisatie of afgeleid kunnen worden van andere bekende gegevens. Tenzij de verantwoordelijke organisatie hiervoor kosten moet maken die niet in verhouding staan tot het doel van het vastleggen van de metagegevens.
Met ‘bekend zijn’ wordt bedoeld dat een gegeven al ergens binnen de organisatie bekend is omdat dat voor het uitvoeren van het werk- en beheerproces noodzakelijk is. Bijvoorbeeld het onderwerp of de datum van ontvangst moet vaak bekend zijn om een ontvangen stuk te kunnen verwerken. Met ‘afgeleid worden’ wordt bedoeld dat het gegeven bepaald kan worden door andere bekende gegevens te combineren. Bijvoorbeeld de activiteit waar een document uit voortkomt kan vaak afgeleid worden van het dossier waarin het is opgenomen.
De conditie ‘indien bekend’ is opgenomen om te voorkomen dat medewerkers metagegevens moeten vastleggen alleen om aan MDTO te voldoen, maar die voor hun werk- of beheerproces niet noodzakelijk zijn. Dit zou een onredelijke administratieve belasting vormen. En leidt bovendien vaak tot een slechte kwaliteit metagegevens.
Aanvullende metagegevens
Het is mogelijk om vanuit MDTO-metagegevens te verwijzen naar aanvullende metagegevens die niet binnen het metagegevensschema vallen. Mits deze aanvullende metagegevens gedocumenteerd zijn zoals in het metagegevensschema voorgeschreven. Dit gaat om het attribuut ‘aanvullendeMetagegevens’.
Aanvullende waarden
Bij een aantal MDTO-metagegevens is het toegestaan om waarden te gebruiken die niet binnen MDTO zijn gespecificeerd (bij de attributen met een zogenaamde vrije of open begrippenlijst). Mits deze aanvullende waarden gedocumenteerd zijn zoals in het metagegevensschema voorgeschreven.
Dit betekent dat een importfunctie er rekening mee moet houden dat er bij deze attributen waarden aangeboden kunnen worden die niet in MDTO zijn gespecificeerd. Ook deze waarden moeten dan vastgelegd worden.