Skip to content
This repository has been archived by the owner on Oct 19, 2023. It is now read-only.

2.7 Linking ObjectGroups

Matt Woodburn edited this page Jun 9, 2022 · 18 revisions

There are several methods by which associations between different ObjectGroups, representing collections and subcollections, may be constructed.

Direct linkage using the ResourceRelationship class

The ResourceRelationship class can be used to make direct links between ObjectGroups, using the relationshipOfResource property to specify the nature of the relationship. For example, a hierarchy of parent-child relationships can be constructed by using ResourceRelationships with a relationshipOfResource of ‘part of’, or more semantic relationships can be reflected, such as between an ObjectGroup of physical collection objects, and an ObjectGroup representing digital multimedia artefacts derived from those objects.

With the application of the relationshipEstablishedDate property, this method of linkage may also be used to represent changes to physical collections over time (for example, collections that are split up or merged together), or track changes to how the data are organised in Latimer Core (for example, a year after the initial creation of an institution’s collection descriptions dataset, it’s decided to split the ObjectGroup representing the whole zoological collection into two ObjectGroups representing the vertebrates and invertebrates separately, in order to store more specific descriptions and metrics against them. Creating this kind of provenance relationship enables some continuity of reporting across the two versions of the dataset, even though the shape of the data has changed.

exampleResourceRelationship

Figure 1: An example of using the ResourceRelationship class to represent ObjectGroups that are part of a larger ObjectGroup in a collections hierarchy.

By a similar method, hierarchical structures may also be constructed in other relevant classes to represent breakdowns of collections in different contexts. For example, OrganisationalUnit instances may be chained together with part of relationships to represent the divisions and subdivisions within an institution. Taxon instances may be linked to form a taxonomic hierarchy, or ObjectClassification instances linked to create a less formal hierarchy of object types. Using these linked classes and attaching them to ObjectGroups enables collections to be arranged in contextual hierarchies instead of (or in addition to) creating explicit relationships between the ObjectGroups themselves. Figure 2 below shows a simple example of creating parallel hierarchies in ObjectGroups and OrganisationalUnits in a Latimer Core dataset.

exampleParallelHierarchies

Figure 2: Example of parallel hierarchies in the OrganisationalUnit and ObjectGroup classes, with some additional semantic relationships between instances of the two classes.

Simple representation of subcollections

A frequent use case of collection descriptions is to have the ability to store a list of notable, historic and important collections that may be part of a larger institutional collection. This scenario can be modelled in Latimer Core using the approach above, by creating an ObjectGroup for the parent collection and an ObjectGroup for each of the child collections, and linking the children to the parent through the ResourceRelationship class.

While this approach provides the ability to attach rich Latimer Core descriptions (including metrics and narratives) to each of these ‘named’ collections, there is also a degree of effort involved in assembling and maintaining this more complex dataset which may not be commensurate with the time and resources available. A more lightweight approach may also be taken in Latimer Core, where use of the ResourceRelationship’s relationshipResourceName and relationshipOfResource properties can be used to generate a simple list of subcollections and attach them to the parent ObjectGroup (see Figure 3 below).

fig3

"ResoureRelationship": [
    {
        "relatedResourceName": "Sloane Herbarium",
        "relationshipOfResource": "contains"
    },{
        "relatedResourceName": "W E Cutler Collections",
        "relationshipOfResource": "contains"
    }
]

Figure 3: Diagram and JSON example of using the ResourceRelationship class for simple representation of subcollections.

This approach also provides a methodology for starting with a fairly simple Latimer Core dataset, and building up the detail over time as and when opportunity and resourcing permits. For example, a dataset might begin with a single ObjectGroup representing the whole institutional collection, and a set of ResourceRelationship records listing the divisional collections within that collection. At later points, those subcollections could then be broken out into their own ObjectGroups in order to describe and quantify them in more detail.

Using common entities and controlled vocabularies

ObjectGroups can also be indirectly related by the use of common entities and controlled vocabularies to allow associations to be made between them (although this method is more general data good practice, rather than anything specific to the Latimer Core standard). For example, if a controlled vocabulary is used for the discipline property of the ObjectGroup class, then queries such as ‘find all the ObjectGroups representing ‘Botany’ objects’ and ‘provide the total number of ‘Botany’ objects held by the institution’ are easy to execute without the need to create explicit relationships between the multiple ObjectGroups involved.

Using a CollectionDescriptionScheme

The CollectionDescriptionScheme class provides a construct for grouping together ObjectGroups as part of the same Latimer Core implementation, for a particular use case, and applying rules about how the data may be constrained, validated and interpreted by software agents. This approach is described in more detail in the Collection Description Schemes section.