Related Objects and relationships

In the ANDS Collections Registry relationships between real world entities are described by linking registry objects together using different kinds of relations. Relationships between activities, collections, parties and services are used to provide navigational links and contextual information. These relations create a rich mesh of information about Australia's research data and the parties, activities and services that support it.

The four classes of registry objects are related. Relations are described using:

Relation type—the category of relationship linking two registry objects.
Relation description—a plain text description further refining or describing a relation.
Relation URL—a URI expressing or implementing the relationship between registry objects.

Relation type

The kind of relation (relation type) is described by choosing from the following values. Local values can also be used, for example, if a data source has described different relationships according to a standard schema. Ad hoc local values should be avoided.

Available relation types differ according to the classes of registry object being linked.

Relation types: Activity

Activity-activity relation:

isPartOf: is contained in the related activity
hasPart: contains the related activity
isFundedBy: receives monetary or in-kind aid from the related party or activity (program only)

Activity-collection relation:

hasOutput: delivers materials in the related collection

Activity-party relation:

isFundedBy: receives monetary or in-kind aid from the related party or program
isManagedBy: is organised and/or delivered by the related party (includes custodian role)
isOwnedBy: legally belongs to the related part
hasParticipant: is undertaken by the related party

Activity-any relation:

hasAssociationWith: has an unspecified relationship with the related registry object

Relation types: Collection

Collection-collection relation:

describes: is a catalogue for, or index of, items in a related collection
hasPart: contains the related collection
hasAssociationWith: has an undefined relationship with the related collection
isDescribedBy: is catalogued or indexed by the related collection
isLocatedIn: is held in the related repository
isLocationFor: is the repository where the related collection is held
isPartOf: is contained within the related collection
isDerivedFrom: collection is derived from the related collection e.g. through analysis
hasDerivedCollection: the related collection is derived from the collection e.g. through analysis

Collection-party relation:

hasCollector: has been aggregated by the related part
isManagedBy: is maintained and made accessible by the related party (includes custodian role)
isOwnedBy: legally belongs to the related party
isEnrichedBy: (parties only) additional value provided to a collection by a party

Collection-activity relation:

isOutputOf: is a product of the related activity

Collection-service relation:

supports: can be contributed to, accessed or used through the related service (in technical terms, the collection supports the service)
isAvailableThrough: (services only) Discovery Services (Harvest, Search, Syndicate)
isProducedBy: (services only) Creation Services (Create, Generate, Assemble, Transform output)
isPresentedBy: (services only) Creation Services (Report)
isOperatedOnBy: (services only) Creation Services (Transform input)
hasValueAddedBy: (services only) Metadata Services (Annotate, Classify)

Collection-any relation:

hasAssociationWith: has an unspecified relationship with the related registry object

Relation types: Party

Party-party relation:

hasMember: (group only) has enrolled the related party in the group
hasPart: (group only) contains the related group
isPartOf: (group only) is contained in the related group
isMemberOf: is enrolled in the related group
isFundedBy: receives monetary or in-kind aid from the related party or activity (program only)
isFunderOf: provides monetary or in-kind aid to the related party or activity

Party-collection relation:

enriches: (collections only) provides additional value to a collection
isCollectorOf: has aggregated the related collection

Party-activity relation:

isParticipantIn: is enrolled in the related activity
isFundedBy: receives monetary or in-kind aid from the related party or program
isFunderOf: provides monetary or in-kind aid to the related party or activity

Party-any relation:

hasAssociationWith: has an unspecified relationship with the related registry object
isManagedBy: is overseen by the related party (includes custodian role)
isManagerOf: oversees the related party or service or administers the related collection (includes custodian role)
isOwnedBy: legally belongs to the related party
isOwnerOf: legally possesses the related activity, collection, service or party (group only)

Relation types: Service

Service-service relation:

hasPart: contains the related service
isPartOf: is contained within the related service

Service-collection relation:

isSupportedBy: enables contribution and access to and use of the related collection (all services) (in technical terms, the collection supports the service)
makesAvailable: Discovery Services (Harvest, Search, Syndicate)
produces: Creation Services (Create, Generate, Assemble, Transform output)
presents: Creation Services (Report)
operatesOn: Creation Services (Transform input)
addsValueTo: Metadata Services (Annotate, Classify)

Service-party relation:

isManagedBy: is overseen by the related party (includes custodian role)
isOwnedBy: legally belongs to the related party

Service-any relation:

hasAssociationWith: has an unspecified relationship with the related registry object

Research domain example

(illustrative only)
Professor Smith was funded by the Australian Research Council to undertake a research project called Urban Renewal and Drought. Outputs of the project were a publication and a dataset containing data about open space and block size in housing developments.

The following objects could be described and linked together in the ANDS Collections Registry;

Professor Smith (party / person)
Australian Research Council (party /group)
Urban Renewal and Drought Project (activity)
Housing development open space and block size 2008 dataset (collection)

These entities are related to each other in reality in the research domain, and the metadata objects describing them in the registry should be linked together to describe these real world relationships. The nature of the relationship is described using the <relation> element.

Additional information

The language in which the relation description is written can be recorded using <xml:lang>. This information answers the question: What language is the relation description recorded in?

Use in Research Data Australia

Relationships are used to link records together to create a rich mesh for discovery. All relations are displayed as URLs and can be used to navigate to other information within Research Data Australia.

Primary relationships (with effect from RIF-CS v1.3.0, 7 Dec 2011)

Data Source Administrators can nominate two primary records that all other records within their data source are automatically linked to. This functionality makes it easier to manage a large number of links to a single object.

How it works:

This capability is under the control of the content provider and is controlled by configuring the Data Source Account. The administrator can specify up to two primary record keys together with relations. The chosen primary records must be published and from the same data source. All records within the data source will then be linked to those primary (keystone) records and will display as related objects in Research Data Australia.

This is an opt-in capability.

Bi-directional links between related objects

In the past the only way a content provider was able to achieve reciprocal two-way links was if the relationship was created within both objects (e.g. collection to party and party back to collection). For this reason, many of the links within the ANDS Registry were created in only one direction. However, from July 2011, Research Data Australia will display links in both directions between related objects where the content providers have only provided one half of the relationship and have opted into this facility.

This capability is under the control of the content provider and is controlled by configuring the Data Source Account. See Release Notes PDF (1.7MB) for details. In brief:

A content provider can opt for two-way links to be displayed for all related objects within their data source. The default setting is to allow two-way links within a data source.

Example: Budawang Uni creates links from all their collection records to related party records they have also created. Because they have left the opt-in setting to its default of allowing reverse inferred links, Research Data Australia displays both the collection-to-party links they have created, and also the inferred reverse links from
party-to-collection.

Opt-in for internal links

A content provider can opt to allow links to be shown from their records to records from a different data source if that other data source has created a relation to one of the content provider's records. The default setting is not to allow two-way links to external data sources.

Opt-in example: Morton Uni creates relations with some of Budawang Uni's records. Because Budawang Uni has opted to allow the creation of inferred reverse links to external parties, Research Data Australia shows both the links Morton Uni has created, and also the inferred reverse links back from Budawang Uni records to Morton Uni records.

Opt-out example: Morton Uni creates links to some of Budawang Uni's records. If Budawang Uni has not opted in to the creation of inferred reverse links, then no backwards links are shown in Research Data Australia. The portal user will see links from Morton Uni records pointing to Budawang Uni records, but if they look at the Budawang Uni record, no link back to Morton Uni will be shown.

Opt-out of external links

The inferred reverse links are created only for display purposes and cannot be edited. You can see them in Research Data Australia, and in the Registry view from Research Data Australia, but not in XML data or manual data entry screens.

Labels

Labels for relationships are simplified for display. Research Data Australia display labels for RIF-CS 1.0.1 are:

"describes" displays as Describes
"enriches"displays as Enriches
"isEnrichedBy" displays as Enriched by
"hasAssociationWith" displays as Associated with
"hasCollector" displays as Aggregated by
"hasMember" displays as Has member
"hasOutput" displays as Produces
"hasPart" displays as Includes
"hasParticipant" displays as Undertaken by
"isCollectorOf" displays as Collector of
"isDescribedBy" displays as Described by
"isFundedBy" displays as Funded by
"isFunderOf" displays as Funds
"isLocatedIn" displays as Located in
"isLocationFor" displays as Location for
"isManagedBy" displays as Managed by
"isManagerOf" displays as Manages
"isMemberOf" displays as Member of
"isOutputOf" displays as Output of
"isOwnedBy" displays as Owned by
"isOwnerOf" displays as Owner of
"isParticipantIn" displays as Participant in
"isPartOf" displays as Part of
"isSupportedBy" displays as Supported by
"supports" displays as Supports

RIF-CS best practice guidelines

To create a link to a related object:

Enter the ANDS Collections Registry <key> of the object being linked to
Select the appropriate kind of relationship (relation type) from the controlled vocabulary or use a local value if none of the vocabulary items is appropriate
Optionally add additional information about the relationship into the <description> element, add language information <xml:lang> if desired, add a <url> if desired.

Related object

Two registry objects are related using their unique keys, together with a relation type to describe the nature of the relationship. The key of the related object needs to be already uploaded or uploaded in the same batch, otherwise the relation has nothing to attach to.

Relation

Content providers should consider how important a relation is to discovery, and not create relations that will not improve access. In particular, although the ANDS Collections Registry allows parties to be related, this should be used only to improve discovery. A relation between a person (researcher) and a group (funding organisation) may add value, while hierarchical relations between organisational parts may not.

Relation is not the same thing as related information. Related information connects to information located outside the registry. This contrasts with connections within the registry to other registry objects, which are handled using the Related object and Relation functionality of the registry. These internal links are constrained by the Registry relation types.

Relation type

For activities, relations of type hasPart and isPartOf should only be established between activities of the same type, that is, between two programs, or between two projects.

Relations between different types of activities need a more specific relation. For example, a program may fund a project, and this should be described using a Funds/isFundedBy relation.

Enriches/isEnrichedBy

This relation type is expected to be useful for aggregators, particularly in relation to 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 within the collection or to relevant external sources
digitising hardcopy resources
changing the format of digital collections to allow greater search capability or capacity to maintain the data
indexing or providing additional search terms
providing additional metadata to the collection to enhance administration, preservation, discovery and re-use.

Relation description

If the generic relation "hasAssocationWith" is used, include a description of the details or nature of the association.

Relation URL

If describing a collection's relation to a service, the URL which implements the related service in the collection's context can be recorded in this element.

Services

Complex relations may apply between services and other registry objects. Detailed information is available from the Services page.

RIF-CS examples

Illustrative example showing the relations between a party and a collection owned by that party.

Part of a party record, showing the key of the related collection and the party's relation to that collection (isOwnerOf). In the narrative form, this reads as: The party this record describes is the owner of the collection (related object) that has the key "hdl:102.100.100/999999".

<relatedObject> <key>hdl:102.100.100/999999</key> <relation type="isOwnerOf" /> </relatedObject>

Part of a collection record showing the key of a related party and the collection's relation to that party (isOwnedBy). In the narrative form, this reads as: The collection this record describes is owned by the party (related object) that has the key "http://nla.gov.au/nla.party-549576".

<relatedObject> <key>http://nla.gov.au/nla.party-549576</key> <relation type="isOwnedBy" /> </relatedObject>

Date	Change history
April 2010	Consultation draft
26 October 2010	First web publication
25 January 2011	Relation information for services added
18 July 2011	Information about inferred bi-directional links added
21 Nov 2011	Information about creating primary relationships
5 Dec 2011	Minor clarifications to descriptions of relation types
4 May 2012	Correction, added collection-to-any relation isAssociatedWith, previously omitted in error

Please send any feedback on this page to guides@ands.org.au