Since version 6.027 of JOIN Case & Document it is possible to export a removal list to a specific format, with which digital transfer can be realized. At the moment only the RIP format is supported and pilots are taking place with municipalities to gain experience with this export.
The export consists of two parts: the metadata in XML and the files (optional) in PDF or in the original format.
To use this export you need:
JOIN Case & Document exports the metadata to XML. The structure and content of that XML is its own structure, based on the database fields. This XML can be automatically translated to another XML structure or to a CSV file. The receiving system (the e-Depot) will set requirements for the structure of the XML supplied. For example, the requirement that the metadata is supplied in ToPX, a standard of the National Archives.
a style sheet (an XSLT) that translates your design into the desired format.
Decos has a stylesheet for ToPX. This style sheet must be adapted to your specific design: this adjustment can be carried out by a functional consultant. If you require a different style sheet, please contact Decos.
If the metadata is supplied in the correct format (such as ToPX), this does not say anything about the folder structure with which the files must be supplied. There are two structures for this in this sector: RIP and Sidecar.
In RIP, all files are placed in the same folder, with a single file containing all metadata. This metadata file is an XML file consisting of a RIP structure in which a ToPX structure is included for each archive registration. RIP is also a standard of the National Archives and can best be regarded as an envelope in which the various metadata files per registration are combined into one XML file. The advantage of this approach is that all metadata for the entire export can be processed coherently. On the other hand, this file can become quite large.
All files in the export are therefore placed in the same folder on the JOIN server. This means that every file has a unique name (that has become a key, a GUID) and that the e-depot can find out which file is which archive item based on the metadata.
The full export can then be retrieved by copying the folder to an external drive or sending it via SFTP. This is an action that can of course only be performed by persons who have access to the JOIN Case & Document server. In most cases this will be done by your application manager; for cloud environments, Decos Customer Support can play a role in this.
In the Sidecar structure, an XML file is created per archive item that has the same name as the archive item. Where RIP works with one metadata file, Sidecar works with separate metadata files. In addition, the files in the export are not placed in the same folder, but in a folder structure.
In our pilots, Decos has noticed that several variations are possible in the Sidecar structure. The extension of the metadata files (.sidecar, .xml or .metadata) and the structure of the folder structure come in different variants.
At the moment JOIN Case & Document only supports the RIP structure.
The fact that it is technically possible to provide an export to the e-depot does not of course mean that the export also contains all the information that the e-depot needs or wants to have.
The basis for the metadata in the archives of local authorities is the Application Profile Metadating Local Authorities, or TMLO. This model describes the fields that must be recorded for archiving and thus also the fields that must be made available to the e-Depot when transferred from the RMA. During the first evaluation round in 2015, several suppliers, including Decos, indicated that the TMLO offers insufficient technical specifications for an export. For example, different systems can give a different interpretation to “geographic location” (9.2) or to “event history” (12). The information model TMLO is the continuation of that discussion, but has not yet been established.
In addition, TMLO contains elements that are usually not recorded in the RMA. This concerns, for example, the user rights (16), the creation application (21.6) or the event plan (13). Publicity and confidentiality are also not always recorded in the RMA. In particular, with older archive records (and therefore precisely the ones that will be transferred), the metat data is too limited.
Finally, it is also possible that JOIN contains information that is too detailed for the e-depot. This occurs with the workflow data, in which all treatment steps are recorded, including the personal names of the employees. Although this data contains a lot of information about the handling of the archive documents, archiving this workflow data is a separate discussion. A discussion about personal data, but also a discussion about the need for this detailed information for future consulters. The same applies to the audit trail, which also contains (too) much detailed information.
In practice, it therefore appears that a discussion must take place between the manager of the RMA and the manager of the e-Depot about what information is available and what information is required. Choices must also be made about what to do when information is missing. For example, if publicity is not recorded in the RMA, publicity can acquire a fixed value in the export technique. This discussion is of great importance, because the results determine the export selection, but especially because the archive records will be removed after the transfer - so there is no possibility for the e-depot to request additional information afterwards.
It is precisely because of this substantive discussion that it is important that experience is gained with digital transfer, so that ‘best practices’ can be applied.
The support of JOIN Business & Document for the various elements from TMLO is documented here: TMLO elements.
Work in progress…