-
Notifications
You must be signed in to change notification settings - Fork 10
2.7 Linking ObjectGroups
There are several methods by which associations between different ObjectGroups
, representing collections and subcollections, may be constructed.
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.
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.
Figure 2: Example of parallel hierarchies in the OrganisationalUnit
and ObjectGroup
classes, with some additional semantic relationships between instances of the two classes.
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).
"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.
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.
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.
Version | Date | Contributors | Status |
---|---|---|---|
1.x | TBD | Matt Woodburn, Jutta Buschbom, Sarah Vincent, Kate Webbink, Maarten Trekels, Janeen Jones, Sharon Grant | Expert Review - In progress |
1.0 | 2022-06-10 | Matt Woodburn, Jutta Buschbom, Sarah Vincent, Kate Webbink, Maarten Trekels, Janeen Jones, Sharon Grant | v1 - Archived |
0.1 | 2022-02-10 | Matt Woodburn, Jutta Buschbom, Sarah Vincent, Kate Webbink, Maarten Trekels, Janeen Jones, Sharon Grant | Draft |