news     faq     contact us     prov

5.1 Requirements on recordkeeping systems

The VERS requirements on recordkeeping systems are to ensure that the records are properly managed within an agency to ensure that they are complete, documented, and retain integrity.

When considering these requirements, it is important to remember that the life of most records will far exceed the life of any individual recordkeeping system that holds them. This means that most records will be transferred several times from one recordkeeping system to its successor. Many of the requirements apply to the complete life of the record. For example, it is necessary to document the history of the record from initial registration. This implies that the history must be transferred with the record from one recordkeeping system to its successor.

The requirements on a recordkeeping system that is required to preserve electronic records for a significant period are listed in PROS 99/007 Specification 1: System Requirements for Preserving Electronic Records. They can be summarised as follows:

• The ability to export records. As discussed in section 4.4, it is essential that a recordkeeping system be capable of exporting the records (both content and metadata). When exporting to PROV, the recordkeeping system must be capable of exporting the records in the VERS format.
• Ensuring the integrity of the record. It must be possible to show that the record has not been modified in an unauthorised fashion (i.e. has retained integrity) since creation. Authorised modifications must be documented in the history associated with each record. This is to prevent the loss of integrity discussed in section 4.2.
• Documenting the history of the record. It must be possible to document the history of the record from the time of its creation. This includes the registration of the record, reclassification or alteration to the context of the record, any preservation actions (e.g. format conversions), transfers between recordkeeping systems, and export to PROV. This is to prevent the loss of context, authenticity, and integrity discussed in section 4.2.
• Documenting the creation of the record (i.e. being able to show that a record is authentic). This includes documenting who registered the record, when it was registered, and the context of the registration. This is to prevent the loss of authenticity discussed in section 4.2.
• Metadata capture. The recordkeeping system must capture and store sufficient information to document the context of the record. This is to prevent the loss of context discussed in section 4.2.
• Conversion to long-term preservation format. At some point the record content must be converted to a long-term preservation format to ensure that access to the record is independent of the application that created it. This issue is discussed extensively in section 4.1. Conversion may occur at any time, but two common points are when the record is registered, or when the record is exported. Late conversion increases the risk of record loss, as it increases the chance that the necessary application will not be available or will produce an inaccurate conversion.
• Reliability. The recordkeeping system must not lose records entrusted to its care, as discussed in section 4.4. Records may be lost by software failures (e.g. inaccurate copying), or by catastrophes (e.g. the system being destroyed). Reliability is partially addressed by the quality of the engineering within the recordkeeping program; including that defensive coding practices have been applied (these check that functions have worked correctly). However, quality software will not, by itself, be sufficient to ensure that records are never lost. All software must be assumed to contain bugs. In addition, software cannot guard against hardware failures or natural disasters. To prevent the loss of records, the agency responsible for the recordkeeping system must institute and test a proper backup and disaster-recovery regime.
• Refreshing. The recordkeeping system must be capable of accurately refreshing the media on which the records are held. This is to cover the mechanical and chemical deterioration of both the media and the hardware that reads the media, as discussed in section 4.3.

The VERS Standard does not specify the mechanisms by which recordkeeping systems should conform to the requirements it imposes. Different products and systems will satisfy the requirements in different ways, and this is seen as both appropriate and necessary in a market with diverse needs.

However, it is envisaged that there will be two main implementation models. These models are referred to as 'native' compliance and 'export' compliance. Both models require that records be exported to PROV as VERS Encapsulated Objects (VEOs). The models differ in when the VEOs are generated.

With export compliance, the VEOs are only generated when the records are to be exported to PROV. Before the records are exported they are held in the internal format of the recordkeeping system. When using this model, the component that creates the VEOs can be viewed as an additional module that converts the records from the internal format to the VEO format required by PROV. The advantage of this implementation approach is that it requires minimal changes to existing recordkeeping systems.

Figure 1. Export implementation model. In this model, records are held within the recordkeeping system and only converted to VEOs upon export.

With native compliance, however, the VEOs are created when the record is initially registered into the recordkeeping system. The recordkeeping system then holds the records as VEOs until they are exported to PROV.

The advantage of native compliance (see Figure 2) is that the record is converted to a long-term format, the necessary metadata is collected, and the record is signed using a digital signature at registration. This means that the record is not dependent on the continued functioning of the recordkeeping system. As discussed in section 4.4, even if the recordkeeping system should catastrophically fail, the VEOs will be sitting on the filesystem and can easily be extracted and transferred to PROV.

Figure 2. Native implementation model. In this model, records are converted to VEOs when first registered. One advantage of this model is that the VEOs can be directly extracted from the source system if necessary.

back to top

printer friendly

VERS Story | Standard | Assessment | Projects | Digital Archive | Training | Toolkit | Publications

Site last reviewed: 20 Jul 2006
© State of Victoria 2008 | Disclaimer | Privacy Statement