Skip to main content
Skip table of contents


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

  • Each RegistryObject must have a key. 
  • Each key must be unique at least within its context of use (that is, in the RDA Registry).
  • Keys should be persistent, that is, not change once allocated.
  • Contributors are responsible for the uniqueness and persistence of the keys they supply.
  • A key may be any unique string. 
  • A key may be, but is not required to be, a URL.
  • Keys must be 512 characters or less, and only 255 characters can be displayed. Keys cannot include ampersands (the & character).
  • Keys should preferably be globally unique to support discovery in federated global registries.

Options for keys

  • Mint persistent handle identifiers for use as keys: Guaranteed persistent unique keys can be created by minting persistent handle identifiers (using either the Handle Service for handles or an equivalent). This approach implies a commitment to maintaining the currency of the location component of the key into the future.
  • Create local keys: If minting persistent handle identifiers to use as metadata record keys is not a suitable solution for a contributor, local primary keys or identifiers may be used, although these cannot be guaranteed to be globally unique. These keys should not be changed in the local system once created. Local keys can be programmatically enhanced by adding a server or domain name from your own institution, or some other unambiguous and unique identifier, to an existing object identifier.
    • Party keys can use a local unique identifier for the person or group that is maintained internally by the institution or agency, such as a staff number or username, prepended with the contributor's domain name and a trailing slash to make it globally unique. Example:
  • Generate random keys: Those contributors using the RDA Registry to manually create records may choose to use the 'Generate Random Key' function which generates keys that are unique within the Registry. The keys produced are random strings of characters.

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

A persistent handle identifier


An actionable (resolvable) persistent handle identifier


A local key prepended by the domain name of the contributor


Change history

Click here to view...
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
JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.