Parties in the RDA Registry
A party record describes a person, group or role related to an activity; to the creation, update, or maintenance of a collection; or to the provision of a service. Parties are included in the RDA Registry because they aid discoverability of collections and add valuable contextual information, including assisting with determination of value for a collection.
Parties may be linked to collections, activities and services in one of two ways:
- By creating a RegistryObject for the party (i.e. a party record), and linking it via its key in the RelatedObject element of the collection, activity or service; or
- By linking to it via a globally unique persistent identifier (e.g. an ORCID) in the RelatedInfo element of the collection, activity or service.
See Do I need to create a party record? below for guidance.
Do I need to create a Party record?
Linking parties to collections, activities and service aids discovery, provides context and gives recognition to people and organisations associated with collections. However, consider whether you need to create a RegistryObject for parties (i.e. a party record). Research Data Australia treats parties linked via RelatedObject or RelatedInfo in almost exactly the same way: the indexing and display of names are equivalent; however, an advantage of using RelatedObject is that reverse links are generated from the Party Object, allowing all collections related to that Party to be displayed when a Party name is clicked on (this functionality will hopefully be available with RelatedInfo links in a future release). The advantage of using RelatedInfo is that it is the simplest (and most sustainable) way to link parties to collections, activities and services with a globally unique persistent identifier. Whichever option is chosen, contributors are strongly encouraged to provide a globally unique identifier such as an ORCID or NLA Party identifier in their records. Identifiers support a linked data approach that enables relationships between resources to be identified and displayed in Research Data Australia regardless of the source of the record.
You do not need to create a party record if:
- A suitable party record already exists in Research Data Australia. In this case, link your collection, service or activity record to the existing party record using the key in RelatedObject.
- A suitable party record, with a unique identifier, exists elsewhere, e.g. the person has an ORCID. In this case, provide the identifier in the RelatedInfo element of your collection, service or activity record.
Consider creating a party record if:
- There is no suitable party record already in Research Data Australia and no record exists elsewhere with a unique identifier; e.g. a party record for a researcher was created by their past institution, and their current institution wishes to highlight their current affiliation, so creates a new record.
Often, multiple parties will be related to a collection. The description should aim to link the collection to any party that will substantially improve discovery. That means all active known collaborators on the project:
- who made a substantial contribution to the collection (so that it makes sense to discover the collection via the collaborator), and
- who can reasonably be given credit for bringing about the collection.
As a default, that would include all named researchers on the research grant application, but not support staff or research assistants.
Party (group) records, institutional hierarchies and Contributor pages
Research Data Australia is not intended to represent organisational hierarchies. The default approach for party (group) records should be to represent the lowest-level group, with the most direct engagement with the collection. That means that the research centre, research lab/group, or individual researchers are the parties of interest that need to be described and linked to a collection, in preference to departments or faculties. The name of a research lab, for example, may include its superior body's name as part of its name, e.g. Budawang University Frontiers of Chemistry Research Laboratory.
Collection records do not need to be linked to an institutional party record (however, contributors may make such connections if they wish); because Research Data Australia aggregates an institution's information for display using the group attribute (which is not the same as, and has no relationship to the party of type "group").
Each contributor to Research Data Australia has a Contributor Page, which is automatically linked to all the collections, parties, activities, and services contributed by the organisation, and is accessed by clicking on the organisation's logo at the top of all records. Contributor pages include basic text about the organisation’s content in Research Data Australia, which is automatically generated by the system (based on the "group" attribute); this basic information can be enhanced by the organisation’s Data Source Administrators (via MyRDA) with richer text, a logo and images if desired.
Metadata for Party records in the RDA Registry
The table below specifies the mandatory and optional elements for creating a party record for the RDA Registry. Click on the label name to see how the element should be encoded.
Provide as many optional elements as you can to create a party record that is richly described and well connected.
Label in the RDA Registry
Schema element or attribute name
A wrapper element for metadata records (registry objects). It has no relationship to objects being described, but exists solely as part of the interchange infrastructure.
The entity holding the managed version of the registry object metadata, as represented by a URI. The primary source of truth for the metadata record.
The organisation that is contributing the metadata record (registryObject), that is, the metadata publisher.
A unique string that persistently identifies a metadata record within the RDA Registry.
“Party” is one of four classes of things that may be described in a metadata record.
The type of party selected from a predefined list.
The name or title given to a party.
A plain text description of a party.
For a party, relevant locations may include a physical address or an electronic address (e.g. a web page URL or email address). Do not use spatial location in party records if you have a better form of location.
A related party linked to the party using an object key or an identifier.
A related collection linked to the party using an object key or an identifier.
A related activity linked to the party using an object key or an identifier.
A related service linked to the party using an object key or an identifier.
|related info||<relatedInfo>||Optional||Y||Additional information related to the party, including a website.|
The start and end dates of the existence of the party being described, e.g. birth and death dates for persons, or dates of establishment, incorporation, dissolution or other start and end dates for organisations.
A sequence of characters or words that uniquely identify an party within a particular context or the domain of a specified authority.
A term, keyword, classification code or phrase representing the primary topic or topics covered by a party.
The date the party record metadata was last changed in the source system.
A Party Type must be specified, preferably from the Party Type vocabulary below.
one or more persons acting as a family, group, association, partnership, corporation, institution or agency.
"The Australian National University"
a human being; or an identity assumed by one or more human beings.
"Professor Julie Smith"
a kind of party where the position name and contact information are present but the identity of the party filling the role is not specified.
Date Modified (metadata) attribute
A date that indicates the currency of a metadata record may be provided as an party attribute in a RIF-CS record, but is not displayed or searchable in Research Data Australia. The DateModified attribute indicates the date when metadata describing a party was last changed in the source system (not the RDA Registry). DateModified has no relation to the date of the last harvest of metadata from a data source. This date will usually be system-generated by the source system and should be UTC and of one of the forms described in section 3.2.7 of the W3C Schema Data Types document.
The RDA Registry infers and displays bi-directional links between related objects in Research Data Australia. If a collection links to a party within the same data source, the party record does not need to link back to the collection; the RDA Registry will display the inferred reverse link in Research Data Australia. If the party and collection are from different data sources, the inferred reverse link will only be displayed if the receiving partner has opted in to allow bi-directional links. See relationships between registry objects for information on how the RDA Registry can automatically create relationships between objects, and bi-directional links between related objects.
Expand the links below to view an explanation of the relationships:
Parties must be linked to a collection, through one of the following relations: "isManagerOf", "isCollectorOf", "isOwnerOf", "isPrincipalInvestigatorOf" or "enriches". The most important relations of these are: "isCollectorOf" (the party that takes credit for the collection), and "isManagerOf" (the party that is curating the collection, and can be contacted for further information). The relation type "enriches", may be useful for aggregators, particularly of cultural collections. Use this relation type when a party's role goes beyond managing a collection to adding value to the collection, by, for example: creating linkages to relevant external sources, digitising hard-copy resources, changing the format of digital collections, indexing or providing additional search terms, or providing additional metadata to the collection.
If none of these adequately describe the relation then use the generic "hasAssociationWith" together with a description to refine the relation.
Parties may link to an activity through either the "isParticipantIn", "isPrincipalInvestigatorOf", "isOwnerOf" or "isManagerOf" relationships, or if a funder, through the "isFunderOf" relationship.
Research Data Australia is a collections registry; accordingly, relations between parties are not required or expected.
If party to party relations are considered important (such as "isPartOf", "hasPart" (group only) or "isManagedBy, IsManagerOf"), they are only relevant in Research Data Australia if they improve collections discovery.
Certain relations apply to person only, or group only. For example, "isMember of" applies to party (person) records only and "hasMember" applies to party (group) records only. Parties can fund a related party ("isFunderOf") or can be funded by ("isFundedBy") a related party.
A party can own ("isOwnerOf") or manage ("isManagerOf") a service.
What makes a good Party record?
Ideally, party records will include accurate, concise and authoritative descriptive content that facilitates discovery, appraisal and reuse of collections associated with the party.
If there is a globally unique identifier for a party, it is strongly recommended to provide that identifier in your Party record. Include all relevant identifiers (e.g. for persons: ORCID, NLA Party Identifier, Scopus Author Identifier, ResearcherID, or a local username or staff ID; for organisations: GRID, ISNI, or Crossref funder registry ID), as this helps in the disambiguation of similar names. It also facilitates the identification and merged display of all records in the RDA Registry associated with a particular party.
In practice, the actual content of individual party records will depend on the source of the metadata for the description (system-generated or human-created) and the goals and resources of the institution providing the party records. While there is no 'one size fits all' for party descriptions, a ‘good’ party record might:
include name variations where appropriate
- include contact details for a person or organisation - electronic addresses are preferred, e.g. a web page URL and/or an email address
include a description of the party to provide users with context for collections: information about the researcher's experience and reputation is useful for evaluating collections
include subject terms that describe the research focus of the party
- include links to related information which provides research context around the researcher.
See the individual elements and attributes for best practice information, and find out how to create RIF-CS metadata for impact.
14 October 2011
First web publication
21 November 2011
RIF-CS v1.3.0 change information added: Party Type (administrativePosition), NameType (superior and subordinate), using primary relationships to link all collections to a party, existence dates, using termIdentifier in collections to describe parties as subjects.
6 December 2011
Added links to search for NLA party ID, Scopus author ID, & ThomsonReuters ResearcherID
8 June 2012
Added administrativePosition Party Type examples
6 March 2013
Added link and example for ORCID
26 November 2013
Updated Related Info to include information about the element introduced in RIF-CS 1.5
28 March 2014
Updated with information about multiple parties
17 May 2017
New Party page created replacing the "Best practice for creating party records" and "RIF-CS in Practice: Describing a Party" pages. Content completely revised and updated.
New table providing an overview of schema requirements for parties added to replace the Metadata Content Requirements page on the ANDS website. Providing a name/title now mandatory in the RDA Registry.
|21 February 2018|
Updated advice in "Do I need to create a Party record?" around Party (group) records, institutional hierarchies and Contributor pages to clarify that linking to schools/faculties/departments is not desired.
Updated Best Practice section to include reference to identifiers for Organisations.
|20 June 2018||Updated RelatedInfo vs RelatedObject advice in "Do I need to create a Party record?".|