This section outlines how the recordkeeping metadata schema contained in the Technical Specifications can be used as a checklist for conformance, how to identify and isolate specific metadata elements in an EDRMS and the potential uses of that.

One use for the recordkeeping metadata schema is to determine whether your existing EDRMS system is consistent with the mandatory elements defined in the Technical Specifications accompanying the Electronic Recordkeeping Metadata Standard.

Please note that the use of the term mandatory in relation to the recordkeeping schema in the Technical Specifications does not imply mandatory implementation under the Electronic Recordkeeping Metadata Standard. The implementation of the Technical Specifications is discretionary.

The aim of determining conformance with the schema is to identify the elements within the EDRMS that equate to, map to, or contain the same data as those defined in the recordkeeping metadata schema. Identifying these elements will enable organisations in the future to import and export records appropriately from EDRMS and assist in strategies to capture records maintained in other business systems into the EDRMS.

Metadata equivalence
User defined elements
Data elements combining recordkeeping metadata.

6.1     Metadata equivalence

When implementing recordkeeping metadata, the assumption is that the majority of the metadata elements required by the Technical Specifications are already present in the EDRMS and need to be identified and not added as extra fields. Many of the elements are required to make the EDRMS work, so should almost certainly be present. However, because they are used to drive functionality in an electronic document and records management system (EDRMS), the naming convention used may not correspond to the element names in the Technical Specifications, and they may therefore be hard to isolate. Specific EDRMS may also combine elements and other data in different ways to enable their specific functionality – again this may make the process of identifying the required elements from the Technical Specifications difficult.

Matching elements in a proprietary EDRMS against the standardised metadata in the Technical Specifications does not mean that the EDRMS needs to express the concepts in the same words or use the element names of the recordkeeping metadata schema. It involves assessing whether the relevant elements are present, either under the same or another name and documenting the proprietary name against the name given to the element or sub-element in the Technical Specifications.

Some of the metadata of relevance to records may be hidden from the casual user, but to check conformance it is necessary for a recordkeeping professional to have access to the data models and definitions sitting behind the specific application in order to find the relevant elements. Much of this detailed information may be contained in system design documentation. Sometimes it may be difficult to find the appropriate documentation providing the details of the proprietary system. In cases like this an option is to ask the vendor to provide the mappings, ensuring that the reason for asking for the mapping is clearly articulated.

When making assessments of equivalence, care needs to be taken to ensure that there really is compatibility of meaning between the Technical Specifications' elements and those identified in the EDRMS. The issues of carefully understanding the definitions of the metadata elements to ensure that the elements being equated are really the same, is addressed in the section 6.7 Inter-relationships and Interdependency of the Technical Specifications and also in the section, Extensibility of this Technical Guide.

Even moving from an earlier EDRMS version requires an understanding of how metadata has been used in the implementation. Examples of issues which may cause difficulty in upgrading between EDRMS versions are:

• implementation specific names or captions may have been introduced which change the standard element names to suit local requirements
• particular elements in the software application may have been used as ‘work-arounds’ to achieve specific goals, but resulted in non-standard configuration
• user defined elements may have been used to enable specific actions local to the implementation
• workflows or templates specific to the local environment may have been defined.

Each of these examples will require some thought in terms of how to find equivalence in the newer implementation.

In working through these issues, mapping to the standard recordkeeping schema will enable you to find equivalent elements in any new software. This will be critical in implementing a successful migration between versions or different EDRMS. It is important to question the intent of the elements, rather than rely on their names. What are they doing or documenting?

Mapping is further addressed in the section Mapping Business Systems/Applications to EDRMS.

Two particular areas of concern in determining how mappings between the Technical Specifications and your EDRMS configuration will work are:

• the use of user defined elements
• data elements which combine recordkeeping metadata values.

6.2    User defined elements

Most EDRMS applications enable implementers to add user defined elements - specific fields that are relevant to the particular implementation. These are sometimes known as user defined fields. The addition of these elements is often at point of capture metadata and they often provide additional information retrieval points, such as client number in addition to case number, or geospatial coordinates for a local government property.

The temptation by EDRMS developers and vendors may be to suggest to implementers that requirements for specific elements defined in the Technical Specifications can be met by their system using user-defined elements. This is not satisfactory because such elements, by their very nature, are user defined and are therefore inconsistent in both content and structure. User-defined elements lead to different types of data being assigned resulting in a lack of standardisation.

To this end, elements deemed as mandatory in the recordkeeping metadata schema from the Technical Specifications should not be implemented in EDRMS using user-defined elements. It is advisable that they should be built into the base EDRMS (by the developers) as mandatory elements.

6.3    Data elements combining recordkeeping metadata

EDRMS applications view metadata from the perspective of functionality – what action uses this data or how is this element used in an application? In some instances this results in a pragmatic approach; some data is grouped together (concatenated) within a single field and some is separated out into individual fields. There is potential for things that have been defined as separate metadata elements in the Technical Specifications to be grouped and stored as a single metadata element in an application. This may result in metadata elements defined within the EDRMS relating to multiple recordkeeping metadata elements as determined in the Technical Specifications. The opposite may also apply, where the EDRMS application splits up data that in the Technical Specifications is regarded as a single element. This in turn will cause problems in defining equivalence.

Wherever possible, a single recordkeeping metadata element should be mapped to a single application metadata element. Where this does not occur, it should be documented and a way of working around the constraint devised, for example by constructing a combined value.

To document conformance with the recordkeeping metadata schema use the Template for checking metadata.

Template for checking metadata

This table has been adopted from the Queensland State Archives Queensland Recordkeeping Metadata Standard and Guideline, February 2008 (External link).

In order to assist checking conformance with metadata requirements, a simple template can be developed. An example is provided below.