Metadata

ERM Community Wiki

From MoReq 2 (Model Requirements for the Management of Electronic Records). This specification has been prepared for the European Commission by Serco Consulting with funding from the IDABC programme. MoReq 2 is available in electronic form at the following urls:

* http://dlm-network.org/moreq2
* http://ec.europa.eu/transparency/archival_policy

This chapter presents functional requirements for managing metadata. The MoReq2 metadata “model” is presented in appendix 9. Section 12.1 covers the principles of metadata and section 12.2 lists the general metadata requirements.
Metadata includes, in the context of this specification, indexing information and other data needed for effective records management, such as access restriction information. A formal definition is given in the glossary. A more detailed explanation of the role of metadata in records management is found in ISO 23081 (see appendix 7).

12.1 Principles
Scope
It is not possible to define here all the metadata requirements for all possible kinds of ERMS implementation. Different kinds of organisations and applications have particular needs and traditions which vary enormously. For example, some organisations will need indexing focused on account names and transaction dates, while others will need strict hierarchical numbering; some will need volumes, which relate to financial years, while others will not; some will need access controls for security reasons, others for intellectual property reasons, and so on.

This chapter of MoReq2 therefore suggests minimum requirements which are intended as the starting point for customisation and expansion. These minimum requirements are closely related to lists of specific metadata “elements” which the ERMS must be able to capture and process. These elements make up the MoReq2 metadata model in appendix 9.

12.2 General Metadata Requirements
12.2.1: The ERMS must not present any practical limitation on the number of metadata elements allowed for each entity (e.g. class, file, sub-file, volume, record).
The definition of “practical limitation” will vary according to the application. For example, some organisations with a simple classification scheme may not need as many metadata elements as other organisations with a complex classification scheme.

12.2.2: Where the contents of a metadata element can be related to the functional behaviour of the ERMS, then the ERMS must use the contents of that element to determine the functionality.

For example, where the ERMS stores file opening date metadata, it must populate that metadata automatically whenever a file is opened rather than requiring a user to populate it. Note that this is a general requirement which stretches across many metadata elements. MoReq2 does not attempt to identify all cases in which this is relevant.

12.2.3: The ERMS must allow different sets of metadata elements to be defined for different record types at configuration time.

For example:

• invoices may need account number metadata;
• correspondence needs multi-value recipient metadata elements;
• records which are scanned images will need metadata relating the scanning and indexing processes.
  

12.2.4: The ERMS must allow an administrative role to define at configuration time whether each metadata element is mandatory or optional.

12.2.5: The ERMS must support at least the following metadata element formats:

• alphabetic;
• alphanumeric;
• numeric;
• date;
• logical (i.e. YES/NO, TRUE/FALSE).
  

12.2.6: The ERMS should support metadata element formats, definable by an administrative role, which consist of combinations of the formats in ‎12.2.5.

For example, a case might have a reference number in the format nnnnn/aa-n.

12.2.7: The ERMS must support date formats defined in ISO 8601 for all dates.

12.2.8: At time of configuration, the ERMS should allow definition of the source of data for each metadata element.

Possible sources are described in requirements ‎12.2.9, ‎12.2.10, ‎12.2.11 and ‎12.2.13.

12.2.9: The ERMS must allow an administrative role to specify which metadata element values are to be entered and maintained by manual entry or from selection from a controlled vocabulary.

12.2.10: The ERMS should allow for the values of metadata elements to be inherited automatically by default from the next higher level in the classification scheme hierarchy.

For example, for a volume, the value of some of the metadata elements must be inherited from its parent sub-file; and for a record, the value of some metadata may be inherited from the volume into which it is stored.

12.2.11: The ERMS should allow values of metadata to be obtained from lookup tables or from calls to other software applications.

For example, the ERMS might provide name and post code to an addressing application which then returns a street name to be used as metadata.

12.2.12: Where the metadata element is populated by lookup tables, if the selection of a value excludes other values in subsequent lookup tables, this should be reflected in the values shown to users in those subsequent tables.

12.2.13: The ERMS should be able to acquire metadata values from:

• a document-creating software application (see ‎6.1.12);
• operating system;
• network software;
• the user at the time of capture or declaration;
• rules defined at configuration time for generation of metadata by the ERMS at the time of declaration.
  

12.2.14: The ERMS must be able to validate metadata when it is entered by users, and when it is imported. The validation must use at least the following mechanisms:

• format of the element contents;
• range of values;
• validation against a list of values maintained by an administrative role.
  

An example of format validation is that the contents are all numeric, or are in a date format (consistent with ‎12.2.5). An example of range format validation is that the contents fall in the range between 1 January 1999 and 31 December 2001. An example of validation against a list of values is verifying that an export destination is present on a list.

12.2.15: The ERMS must be capable of validating metadata using calls to another application (for instance to a personnel system to check whether a personnel number has been assigned, or to a post code database system) or using an internal look-up table.

12.2.16: The ERMS must allow an administrator role to configure the validation (as specified in ‎12.2.14 and ‎12.2.15) to be applied to each metadata element.

Different metadata elements will require different validation. So, for example, dates will call for format and range validation while descriptions will not need any validation.

12.2.17: For metadata element values that are entered manually, the ERMS should allow an administrator role to configure the element so that it supports one of the following data entry modes:

• persistent user-definable default values;
• a fixed default value;
• today’s date (for date elements only);
• blank element.
  

Additional modes for data entry, not specified above, may also be supported.

A persistent default appears as the default in the data entry field for each item in succession until it is changed by a user. Once changed, the new value remains, i.e. becomes persistent. It should persist at least until the end of a session and ideally between sessions. This applies to all entities for which users may enter metadata values.

12.2.18: The ERMS should allow configuration such that any metadata element value can be used as a search field in a free text search.

12.2.19: Where a metadata element value is stored in date format, the ERMS should allow searches which recognise the value of the date.

For example, the ERMS should support searches in a date range. It is not sufficient for the date to be stored as a text field.

12.2.20: Where a metadata element value is stored in numeric format, the ERMS should allow searches which recognise the value of the number.

12.2.21:The ERMS must allow administrative roles to restrict the ability to make changes to metadata values as defined in the access control model (section 13.4).

12.2.22: The ERMS must allow reconfiguration of the ERMS metadata model by an administrative role, and must log such in the audit trail.

For example, it may be necessary to add a new data element such as “Department Identifier” to some document types following an organisational change.

12.2.23: The ERMS must allow metadata elements to be configured at configuration time such that values generated from other application packages, the operating system or the ERMS (for example, e-mail transmission data) cannot be modified by users once they have been captured.

12.2.24: The ERMS must allow metadata elements to be configured at configuration time such that their values cannot be modified by users once they have been captured.