Meaning & purpose

The Key element identifies a metadata record in the RDA Registry. A key must be unique and persistent in the sense that, once allocated, it does not change.
Keys are created or assigned in the source system. They also form part of the public technical infrastructure of the RDA Registry. They are used as the mechanism for linking related objects to each other, and for update and delete functions as part of the harvesting and Registry ingest process.
Note that the key does not identify the object being described, only the record containing a description of the object.

Use in Research Data Australia

Keys are searchable but are not displayed in Research Data Australia.

Best practice

If a newly harvested record has the same key as an existing record from the same data source, it is treated as an updated record, and overwrites (replaces) the existing record. However, if the newly harvested record has the same key as an existing record from a different data source, the key re-use is considered to be an error, and the new record is rejected. The harvest log will display an error message, and the key of the problem record will need to be changed before it can be ingested. It is therefore good practice to start using properly formed unique keys for records as early as possible.

Principles for creating keys

Options for keys

Do not use the NLA party identifier as the RIF-CS record key by any contributor other than the National Library of Australia (NLA). Use of NLA party identifiers as keys is reserved for the NLA, to enable record exchange between the RDA Registry and the NLA.

The use of other party identifiers, such as ORCIDs, as keys is also not recommended, as these may also be used by other data sources resulting in the records being rejected on harvest into the RDA Registry.

Do not use grant identifiers as keys for activity records: keys of the form are reserved for records from funders.

Contact if you have technical questions about what keys can be accepted by the RDA Registry.

XML encoding examples


Change history

DateChange history
April 2010Consultation draft
26 October 2010Changed recommendations for keys for parties, additional information about minting ANDS persistent identifiers
15 April 2011Corrected to state that keys are searchable
18 July 2011Added information about overwrite prevention function, simplified key information
20 Sept 2011Added information about maximum length permitted for keys
12 Jul 2012Clarified and emphasised that only the NLA can use NLA party IDs as keys for RIF-CS records
9 May 2013Added information about 'Generate Random Key' function enabled with Release 10
13 July 2017Page reviewed and updated