The minimum metadata set is a simplified application of the Australian Government Recordkeeping Metadata Standard 2.2 (AGRkMS), which:

• is focused only on the Record entity of the AGRkMS
• identifies metadata properties essential for agency management of business information or transfer to the Archives and other agencies
• facilitates metadata implementation and information use in agencies
• supports interoperability and information sharing across government via standardised metadata.

Using the minimum metadata set

The minimum metadata set can be used:

• to identify the metadata your systems need to allow easy and accountable capture, retrieval and disposal of records
• to describe records at the item or aggregate level in systems
• with the Archives' Business System Assessment Framework to assess information management functionality requirements for business systems
• when it is impractical to meet the full requirements of the AGRkMS
• with other metadata standards, including the AGRkMS, when additional metadata is required to suit your business needs.

The minimum metadata set can be implemented through system configuration or governance measures, or a combination of the two. For example, if all of the information in a business system can have the same disposal class, format, or rights metadata applied at aggregate level, this could be recorded in system governance documentation or information asset register, rather than being recorded against individual records within the system.

Using the minimum metadata set can help meet requirements of the Building trust in the public record policy by:

• ensuring business systems meet functional and minimum metadata requirements for information management (action 10)
• assessing interoperability maturity, identifying gaps and planning to address them (action 11).

Structure

The minimum metadata set is cumulative and arranged in three levels: Core, Additional and Transfer. Each level has corresponding metadata properties. The value and expected longevity of information determines the amount of metadata that must be kept about it. You must use at least the properties of the Core level to meet minimum requirements to manage all your information, and then use other levels for information of higher value.

However, you should also use Additional or Transfer properties for lower value information if there is a business need or other requirement. For example, it is a requirement of the Protective Security Policy Framework that agencies apply protective markings for sensitive or security-classified information, regardless of its value or length of use. For high-volume, low value information that could otherwise be managed with the Core properties alone, meeting this other requirement can be done using the Protective Marking property from the Additional level properties.

Property reference tables

Below are the reference tables for each level. These include essential information to help you understand each property and how they can be used. 

Core properties

Identifier

Getting the most out of the Identifier property

While recording a single Identifier value satisfies the requirements of the minimum metadata set, it is important to note that a record may have more than one Identifier. For example, records that have been migrated between systems. Recording all Identifiers assigned to a record over time is preferred, particularly for long-term or high-value records. This can help preserve the relationships between records where past identifiers have been used for cross-referencing purposes. In a table format you can record additional identifiers by adding extra columns with different names, for example:

• Identifier 1
• Identifier 1 Scheme
• Identifier 2
• Identifier 2 Scheme

The Identifier property can also be used to capture relationships between records. In a table format this can be achieved by including additional columns with different names to record the identifier of an aggregate of which the individual record belongs, such as:

• Parent Identifier
• Parent Identifier Scheme

Creator

Getting the most out of the Creator property

While recording a single Creator value satisfies the requirements of the minimum metadata set, it is preferable to record all relevant Creators. Recognising contributors other than the Creator, such as authorising officers in a workflow process, can also provide valuable contextual information, particularly if you also record their role or position. It will not only enrich the record, it will also streamline searching, sentencing, and identifying authorisers for destruction or transfer. You can add other contributors in a table format by adding extra columns with different names, for example:

• Creator Agency
• Creator Agency Name Scheme
• Creator Individual
• Creator Individual Name Scheme
• Creator Individual Role
• Approver Individual
• Approver Individual Role.

Use of the Agent and Relationship entities from the AGRkMS would enable the capture of more robust hierarchical and approval metadata if required.

Date Created

Getting the most out of the Date Created property

It is also helpful to record the date of migration if a record is moved between systems or agencies, or the date last modified. Care must be taken not to overwrite the original creation date when a record is closed, migrated or modified. Audit metadata captured by a system may also include important dates related to recordkeeping events.

Sensitive information

It is a requirement of the Protective Security Policy Framework that agencies protectively mark information on systems that store, process or communicate sensitive or classified information. This can be achieved by using the Protective Marking property from the Additional set for all such records regardless of their value.

Additional properties

Title

Getting the most out of the Title property

While a single Title value is all that is required to comply with the minimum metadata set, adding separate Description fields is sometimes beneficial. In a table format this can be achieved by adding extra columns with different names, for example:

• Title
• Title Naming Scheme
• Description.

Another way of improving the discoverability of records is by adding tags or keywords (as per AGRkMS properties 17.1, Keyword Term and 17.3 Keyword Scheme).

Care should be taken to ensure the Title is not overwritten when a record is modified or migrated.

For guidance on managing the quality of titles and descriptions, see Describing Information and What's in a Name?

Protective Marking

Getting the most out of the Protective Marking property

A record should only have one Protective Marking property assigned to it (or a combination of one security classification/marker, one information management marker, and one caveat text). It is acceptable to record more than one property if the current/valid property is clearly marked. This could be achieved in a table format by renaming any columns to show which are valid and which are not, e.g. 'Current Protective Marking', 'Superseded Protective Marking'.

Disposal Class

Getting the most out of the Disposal Class property

While a single Disposal Class value is all that is required to comply with the minimum metadata set, recording the name of the relevant records authority (AGRkMS property 18.1, Records Authority) and disposal action (AGRkMS property 18.3, Disposal Action) can assist with sentencing. This will ensure your agency makes accountable retention and destruction decisions. In a table format this can be achieved by adding extra columns with different names, for example:

• Disposal Class
• Disposal Records Authority
• Disposal Action.

Format

Getting the most out of the Format property

Providing additional information about the format is recommended for unusual, complex, or very large records where that information will assist with its ongoing management. This might include the version of the format or the creating application, but can include other more specialised properties from sources other than the AGRkMS, such as the PREMIS Data Dictionary for Preservation Metadata. Recording the size and quantity of the record(s) (as per AGRkMS 20, Extent) is also advisable. In a table format this can be achieved by adding extra columns with different names. For example, it may be useful to record the following information about an RNA digital audio file using additional properties adapted from the AudioMD schema, and the AGRkMS Extent property:

• Format (e.g. WAV)
• Sampling Frequency (e.g. 48 kHz)
• Bits per Sample (the bit depth, e.g. 24 bits)
• Channels (e.g. 2, stereo).
• File Size (e.g. 1036800)
• File Size Units (e.g. KB)
• Duration (e.g. 01:00:00).

If your system describes records stored on portable carriers such as external drives or DVDs, please also refer to the AGRkMS property 21, Medium. While the minimum metadata set was designed primarily for electronic records management, the Extent, Medium and Document Form properties from the AGRkMS can be used to describe paper and mixed media records as required.

Contact the Agency Service Centre for advice on the format metadata best suited to unusual or high value records.

Transfer properties

Rights

Getting the most out of the Rights property

The Rights property may be repeated if more than one restriction or policy applies to a record. In a table format, this can be achieved by adding extra columns with different names, for example:

• Rights Type 1
• Rights Type 2.

Integrity Check

Getting the most out of the Integrity Check property

It is important that the message digest value is generated and recorded before a record is migrated or transferred to another agency, including the National Archives of Australia. It can then be regenerated after the record is moved or copied to assess its integrity.

In a table format, 'Message Digest' and 'Message Digest Algorithm' (Hash Function Name) can be entered in separate columns. Alternatively, the values can be concatenated, as in the example above, which is the SHA512 message digest for the PDF copy of AGRkMS version 2.2 available on the National Archives’ website. As per the National Archives’ transfer advice, message digests should be generated using an ASD (Australian Signals Directorate) approved hash algorithm.

Recording the file path of the record is advisable, so that you know where to run the integrity check. The date that the message digest was generated can also be very helpful, as recommended in preservation metadata schemes such as the PREMIS Data Dictionary. In table format, this can be achieved by adding a columns with names like:

• Message Digest Date Generated
• File Path.

Adding more properties

The minimum metadata set is extensible. Properties from other metadata schemas can and should be added to meet any additional business needs of your agency.

The property descriptions above provide some examples of how the minimum metadata set can be extended to meet specific information management needs, mostly with reference to the AGRkMS. You should also look to any industry-specific standards that may be relevant to your agency’s business beyond those issued by the National Archives.