Edepot: verschil tussen versies

Uit JOIN wiki
Naar navigatie springen Naar zoeken springen
 
Regel 48: Regel 48:
 
Juist vanwege deze inhoudelijke discussie is het van belang dat er ervaring wordt opgedaan met digitale overbrenging, waardoor er 'best-practices' kunnen worden toegepast.
 
Juist vanwege deze inhoudelijke discussie is het van belang dat er ervaring wordt opgedaan met digitale overbrenging, waardoor er 'best-practices' kunnen worden toegepast.
  
De ondersteuning van JOIN voor de verschillende elementen uit TMLO staan hier gedocumenteerd: [[TMLO_elementen|TMLO elementen]].
+
De ondersteuning van JOIN Zaak & Document voor de verschillende elementen uit TMLO staat hier gedocumenteerd: [[TMLO_elementen|TMLO elementen]].

Huidige versie van 17 jan 2020 om 11:59

Export naar e-Depot

Sinds versie 6.027 van JOIN Zaak & Document is het mogelijk om een verwijderlijst te exporteren naar een specifiek formaat, waarmee digitale overbrenging kan worden gerealiseerd. Op dit moment wordt alleen nog het RIP-formaat ondersteund en vinden pilots plaats met gemeenten om ervaringen op te doen met deze export.

De export bestaat uit twee delen: de metadata in XML en de bestanden (naar keuze) in PDF of in het oorspronkelijke formaat.

Om deze export te kunnen gebruiken, is het volgende nodig:

  • een licentie voor de e-depot koppeling
  • een keuze voor de te exporteren velden (zie onder over TMLO)
  • toegang tot de JOIN server om de bestanden te kunnen ophalen

XML format: ToPX

JOIN Zaak & Document exporteert de metadata naar XML. De structuur en inhoud van die XML is een eigen structuur, gebaseerd op de databasevelden. Deze XML kan automatisch worden vertaald naar een andere XML structuur of naar een CSV-bestand. Het ontvangende systeem (het e-Depot) zal eisen stellen aan de structuur van de aangeleverde XML. Bijvoorbeeld de eis dat de metadata wordt aangeleverd in ToPX, een standaard van het Nationaal Archief.

Als het e-Depot eisen aan de XML stelt, heeft u dus ook nodig:

  • een stylesheet (een XSLT) waarmee uw inrichting wordt vertaald naar het gewenste formaat.

Decos beschikt over een stylesheet voor ToPX. Deze stylesheet moet wel worden aangepast aan uw specifieke inrichting: deze aanpassing kan door een functioneel consultant worden uitgevoerd. Als u een andere stylesheet nodig heeft, kunt u hiervoor contact opnemen met Decos.

Export: RIP-structuur

Als de metadata aangeleverd wordt in het juiste formaat (zoals ToPX), is daarmee nog niets gezegd over de mappenstructuur waarmee de bestanden aangeleverd moeten worden. In deze sector bestaan daarvoor twee structuren: RIP en Sidecar.

Bij RIP worden alle bestanden in dezelfde map geplaatst, met daarbij een enkel bestand dat alle metadata bevat. Dit metadata-bestand is een XML-bestand dat bestaat uit een RIP-structuur waarin per archiefregistratie een ToPX-structuur is opgenomen. Ook RIP is een standaard van het Nationaal Archief en kan het beste worden beschouwd als een enveloppe waarin de verschillende metadata-bestanden per registratie worden samengevoegd tot één XML-bestand. Het voordeel van deze aanpak is dat alle metadata voor de hele export in samenhang kan worden verwerkt. Daar staat tegenover dat dit bestand behoorlijk groot kan worden.

Alle bestanden in de export worden dus in dezelfde map geplaatst op de JOIN server. Dit betekent dat ieder bestand een unieke naam heeft (dat is een sleutel, een GUID, geworden) en dat het e-depot op basis van de metadata kan achterhalen welk bestand welk archiefstuk is.

De volledige export kan vervolgens opgehaald worden door de map te kopieren naar een externe schijf of via SFTP te versturen. Dit is een handeling die uiteraard alleen uitgevoerd kan worden door personen die toegang hebben tot de JOIN Zaak & Document server. In de meeste gevallen zal dat door uw applicatiebeheerder worden gedaan; voor cloud-omgevingen kan Customer Support van Decos daar een rol in spelen.

Export: Sidecar-structuur

In de Sidecar-structuur wordt per archiefstuk een XML-bestand aangemaakt dat dezelfde naam heeft als het archiefstuk. Waar RIP werkt met één metadata-bestand, werkt Sidecar dus met aparte metadata-bestanden. Bovendien worden de bestanden in de export niet in dezelfde map geplaatst, maar in een mappenstructuur.

In onze pilots heeft Decos gemerkt dat er meerdere variaties mogelijk zijn in de Sidecar-structuur. De extensie van de metadata-bestanden (.sidecar, .xml of .metadata) en de opbouw van de mappenstructuur komt in verschillende varianten voor.

Op dit moment ondersteunt JOIN Zaak & Document alleen nog de RIP-structuur.

Veldkeuze: TMLO en de elementen

Dat het technisch mogelijk is om een export naar het e-depot te verzorgen, betekent uiteraard niet dat de export ook inhoudelijk alle informatie bevat die het e-depot nodig heeft of wil hebben.

De basis voor de metadata bij archieven van lokale overheden is het Toepassingsprofiel metadatering Lokale Overheden, of TMLO. Dit model beschrijft de velden die voor archivering moeten worden vastgelegd en daarmee ook de velden die bij overbrenging vanuit de RMA beschikbaar moeten worden gesteld aan het e-Depot. Bij de eerste evaluatieronde in 2015 hebben meerdere leveranciers, waaronder Decos, aangegeven dat het TMLO onvoldoende technische specificatie biedt voor een export. Zo kunnen verschillende systemen een andere invulling geven aan "geografische locatie" (9.2) of aan "eventgeschiedenis" (12). Het informatiemodel TMLO is het vervolg van die discussie, maar nog niet vastgesteld.

Daarnaast bevat TMLO elementen die meestal niet in de RMA worden vastgelegd. Het gaat dan bijvoorbeeld om de gebruiksrechten (16), de creatieapplicatie(21.6) of het event plan (13). Ook de openbaarheid en de vertrouwelijkheid worden niet altijd in de RMA vastgelegd. Met name komt het bij oudere archiefbescheiden (en dus net degenen die overgebracht gaan worden) voor dat de metatdata te beperkt is.

Tenslotte is het ook mogelijk dat JOIN informatie bevat die te gedetailleerd is voor het e-depot. Dat komt voor bij de workflow-data, waarin alle behandelstappen zijn vastgelegd inclusief de persoonsnamen van de medewerkers. Hoewel deze data veel informatie bevat over de behandeling van de archiefstukken, is het archiveren van deze workflow-data een discussie apart. Een discussie over persoonsgegevens, maar ook een discussie over de noodzaak van deze gedetailleerde informatie voor toekomstige raadplegers. Hetzelfde geldt voor de audit-trail, die ook (te) veel gedetailleerde informatie bevat.

In de praktijk blijkt dus dat er een discussie plaats moet vinden tussen de beheerder van de RMA en de beheerder van het e-Depot over welke informatie beschikbaar is en welke informatie vereist is. Daarbij moeten ook keuzes gemaakt worden over wat er gedaan moet worden als er informatie ontbreekt. Als bijvoorbeeld de openbaarheid niet wordt vastgelegd in de RMA, kan in de exporttechniek de openbaarheid een vaste waarde krijgen. Deze discussie is van groot belang, omdat de uitkomsten bepalend zijn voor de exportselectie, maar vooral ook omdat na de overbrenging de archiefbescheiden zullen worden verwijderd - er is dus geen mogelijkheid voor het e-depot om achteraf aanvullende informatie op te vragen.

Juist vanwege deze inhoudelijke discussie is het van belang dat er ervaring wordt opgedaan met digitale overbrenging, waardoor er 'best-practices' kunnen worden toegepast.

De ondersteuning van JOIN Zaak & Document voor de verschillende elementen uit TMLO staat hier gedocumenteerd: TMLO elementen.