Hugh Campbell, Public Records Office of Northern Ireland (PRONI)


The Northern Ireland Civil Service (NICS) selected TRIM as the software platform for its corporate Electronic Document and Records Management (EDRM) system following a procurement exercise in the early 2000s. TRIM has subsequently evolved through a number of manifestations and is now (Micro Focus) Content Manager. The NICS currently uses CM 9.4.


A number of Public Record Office of Northern Ireland (PRONI) staff were involved in the initial procurement project and PRONI was one of three lead implementers of the system. This proved to be very beneficial as we had a member of staff who was interested in records management and was an obvious selection for the role of system administrator for the PRONI implementation. This afforded us a great opportunity to learn about the product particularly as we had someone with higher privileges than regular users.


We were very aware that, although Retention and Disposal hadn’t been implemented at that point, PRONI would receive records from the corporate EDRM system at some point in the future. The two obvious areas for research and investigation therefore were:


  • Metadata; and
  • Export


We spent some time researching metadata standards before a very simple realisation dawned on us – the only metadata we could get was what was in the system. It didn’t matter what was being recommended, if it wasn’t in the source system then we weren’t going to get it. This led to a more focussed look at the actual metadata within the EDRM system. We did this by:


  • Going through all the screens and recording the metadata; and
  • Using the out of the box export and examining the output.


The next stage involved lots of meetings and discussion as we examined each piece of metadata and tried to make an objective decision as to the value of keeping it (in a digital repository for ever). In making our decision, we took into account what we understood the metadata to mean and considered how useful (or confusing) it may be for future generations. For example, one item within the EDRM system which generated considerable discussion was ‘Creator’. On the surface, ‘Creator’ sounds like an important piece of metadata to retain. Investigation, however, revealed that ‘Creator’ did not necessarily guarantee a meaningful association with a digital object. It simply recorded who saved the record into the EDRM. In the case of senior civil servants, who may be creating a substantial percentage of the content in which future generations may be interested, records were often being saved by secretaries or personal assistants (who had no other association with the record). In this case, we decided that it could be a very confusing piece of metadata and so we decided not to take it. The various date fields stored in the EDRM system also generated considerable discussion. It should be noted, however, that not every piece of metadata warranted the same level of consideration, particularly those items that were obviously required.


One of the benefits of the EDRM system was expected to be the reduction in duplication which would arise from the use of ‘links’. Undoubtedly this has been the case, particularly when a ‘link’ rather than an attachment is emailed to multiple recipients. These ‘links’, however, were also the subject of considerable discussion in an attempt to reach a decision on what we would do with them. The final decision here was to generate a text ‘stub’ based on the content of the link.


After lengthy research and discussion, we eventually settled on the metadata fields we would take from the EDRM system – this is shown below.


The EDRM system was supported by a Managed Service Provider when we were developing the means to export records and metadata. We worked with the Managed Service Provider to specify and develop an export that:


  • Copied each container selected for transfer out into a Windows folder on the file system, and;
  • Created a metadata csv file within each folder, with one row of metadata for every object within the folder.


We also used this metadata layout as a standard template for the metadata associated with all digital records transferring to PRONI. As part of our processing, we will supplement this with more metadata, for example the metadata generated by DROID, and we will populate the ‘PRONI use’ fields.


Like most great plans, however, it has not all been plain sailing. We have sought to tweak the metadata slightly over the last few years and we know that there will be occasions when we will have to develop some scripts to manipulate metadata before it is presented to our digital preservation system for processing. To date, two Public Inquiries have transferred over 51,000 records from the EDRM system to PRONI - proof that the process works.

To find out more about PRONI, please visit our website and follow us on Facebook  and Twitter.


PRONI - EDRM system metadata template




Name of originating System


Originating System version


Local System Name


Date exported from EDRM System


The titles, separated by space | (pipe) space, of the classification levels excluding container holding records


The title of the container or folder containing records


The number of original digital objects in a container


The container record type description


The ID of the EDRM container level classification


The full ID of the EDRM container level classification


The level of the container within the classification


From the Notes tab of the container


Path of interim location of data files on the export server prior to transfer to PRONI


This is the relative data path following structure defined by PRONI (Accession Number\"data"\transfer identifier\ContainerID\)


Date that the container was closed


FOR PRONI USE (Digital Preservation Unique Identifier)


Name of the Record Type


The original textual description of the record


The filename and extension of the digital object


The unique identifier within an EDRM System


The unique identifier within an EDRM System


From the object's 'Notes' tab record metadata


Language of the intellectual content of the resource


Date of creation of the digital object


The date on which the digital object was last modified


Person who composed the digital object


Exact size of the object in bytes


Details of related objects


Description of relationship eg attachment to email or document embedded within another document


Determines whether or not the Access decision permits the digital object to be viewed by the public


If record is Closed for FOI/DPA/or other reasons


Free text field describing reasons for decisions to close


Next Action for record


The date on which the next action on the record will occur


If the filename is more than 200 characters, the filename should be recorded here prior to being truncated - see Filename


Business area to which the record relates


Information Asset Owner as determined by the business


Name of person who reviewed file


Date file was reviewed


Name of Departmental Information Manager approving decision


Date approved by Departmental Information Manager


This will be either Crown Copyright (Government Records) or other details agreed at submission with depositor


The person identified as having management powers over the digital object with regards to access


Free text field containing additional information on the copyright/licensing of the digital object


Is an access copy required for access systems


Free text field containing any comments relating to entries on the file format registry




MD5 checksum if EDRMS stores checksum










End of standard metadata




Scroll to top