
Meaning & purpose
The K 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. 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 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 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.
- Generate random keys: Those contributo 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 . 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 . 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 services@ardc.edu.au if you have technical questions about what keys can be accepted by the RDA Registry.
XML encoding examples
<key>hdl:102.100.100/134</key> |
<key>http://hdl.handle.net/102.100.100/8</key> |
<key>myuni.edu.au/s3799332</key> |
Change history
Date | Change history |
---|
April 2010 | Consultation draft | 26 October 2010 | Changed recommendations for keys for parties, additional information about minting ANDS persistent identifiers | 15 April 2011 | Corrected to state that keys are searchable | 18 July 2011 | Added information about overwrite prevention function, simplified key information | 20 Sept 2011 | Added information about maximum length permitted for keys | 12 Jul 2012 | Clarified and emphasised that only the NLA can use NLA party IDs as keys for RIF-CS records | 9 May 2013 | Added information about 'Generate Random Key' function enabled with Release 10 | 13 July 2017 | Page reviewed and updated |
|