2.2 Collection description schemes

Introduction to collection description schemes

When describing large collections it is anticipated that the same collections can be described using different schemes for different purposes. For instance a museum collection may be described based on “famous named” collections or collectors (e.g., Darwin, Spruce) if an aggregator has the need to “find” lost specimens from previously formed collections. The same collection may be described in whole or part based on taxonomic or geographic properties for the purpose of environmental or taxonomic research or funding.

The CollectionDescriptionScheme class, and the supporting SchemeTerm and SchemeMeasurementOrFact classes are intended to provide some parameters around the purpose and expectations of the descriptions and to indicate if objects within the descriptions are assigned attributes that will cause errors in metrics if not explicitly noted.

Using these three classes enables you to build a 'profile' for your LtC implementation, so that you may:

1. describe the purpose of your collection description scheme (using the CollectionDescriptionScheme.basisOfScheme property)
2. define whether the ObjectGroups within the scheme overlap (i.e., a single object might be represented in more than one ObjectGroup) or are distinct (using the CollectionDescriptionScheme.distinctObjects property`)
3. apply restrictions on which terms within the overall LtC standard can be included, and which are mandatory (using the SchemeTerm class)
4. define the metrics that you want to be included in the scheme via the MeasurementOrFact class (using the SchemeMeasurementOrFact class)

Essentially, LtC is a fairly broad and flexible standard which can be applied in multiple ways. While this allows it to support a broad range of collection description use cases, it also presents a risk that if its use isn't constrained appropriately to fit the use case, data coherency and usability may be compromised. In particular, defining 1. common metrics and 2. controlled vocabularies for appropriate terms are vital steps for making sure that the data are consistent and interoperable. The collection description scheme concept and related LtC terms are intended to help to support this process.

Defining a collection description scheme - an example process

Below is an example of steps that you can take to begin defining a new collection description scheme in Latimer Core, using the CollectionDescriptionScheme, SchemeTerm and SchemeMeasurementOrFact classes and properties.

Step 1: Use CollectionDescriptionScheme for the basic definition of your scheme:

{
    "@context": {
        "ltc": "http://rs.tdwg.org/ltc/terms/"
    },

    "@type": "ltc:CollectionDescriptionScheme",
    "schemeName": "NHM London departmental collections",
    "basisOfScheme": "Collections inventory",
    "distinctObjects": "True"
}

This provides a name for the scheme, allowing it to be distinguished from other schemes that might be in the same dataset, and what the scheme is intended to be for. It also dictates that no single object is expected to be represented in more than one ObjectGroup within the scheme, so it should be safe to aggregate metrics within the scheme without the risk of, for example, counting the same object multiple times.

Step 2: add SchemeTerm to define the terms that are allowed in the dataset:

{
    "@context": {
        "ltc": "http://rs.tdwg.org/ltc/terms/"
    },

    "@type": "ltc:CollectionDescriptionScheme",
    "schemeName": "NHM London departmental collections",
    "basisOfScheme": "Collections inventory",
    "distinctObjects": "True",

    "ltc:SchemeTerm": [
        {
            "@type": "ltc:SchemeTerm",
            "termName": "ObjectGroup.collectionName",
            "mandatoryTerm": "True",
            "repeatableTerm": "False"
        },{
            "@type": "ltc:SchemeTerm",
            "termName": "ObjectGroup.Identifier",
            "mandatoryTerm": "True",
            "repeatableTerm": "False"
        },{
            "@type": "ltc:SchemeTerm",
            "termName": "ObjectGroup.Identifier.identifier",
            "mandatoryTerm": "True",
            "repeatableTerm": "False"
        },{
            "@type": "ltc:SchemeTerm",
            "termName": "OrganisationalUnit",
            "mandatoryTerm": "True",
            "repeatableTerm": "False"
        },{
            "@type": "ltc:SchemeTerm",
            "termName": "OrganisationalUnit.organisationalUnitName",
            "mandatoryTerm": "True",
            "repeatableTerm": "False"
        },{
            "@type": "ltc:SchemeTerm",
            "termName": "OrganisationalUnit.organisationalUnitType",
            "mandatoryTerm": "True",
            "repeatableTerm": "False"
        },{
            "@type": "ltc:SchemeTerm",
            "termName": "StorageLocation",
            "mandatoryTerm": "True",
            "repeatableTerm": "False"
        },{
            "@type": "ltc:SchemeTerm",
            "termName": "StorageLocation.locationName",
            "mandatoryTerm": "True",
            "repeatableTerm": "False"
        },{
            "@type": "ltc:SchemeTerm",
            "termName": "StorageLocation.locationType",
            "mandatoryTerm": "True",
            "repeatableTerm": "False"
        },{
            "@type": "ltc:SchemeTerm",
            "termName": "StorageLocation",
            "mandatoryTerm": "True",
            "repeatableTerm": "False"
        },{
            "@type": "ltc:SchemeTerm",
            "termName": "ObjectGroup.preservationMethod",
            "mandatoryTerm": "False",
            "repeatableTerm": "True"
        },{
            "@type": "ltc:SchemeTerm",
            "termName": "Taxon",
            "mandatoryTerm": "False",
            "repeatableTerm": "True"
        }
    ]
}

In human-readable terms, this says:

We want the collection to be broken down by department and building, so each subcollection must have one, and only one, department (OrganisationalUnit) and building (StorageLocation) attached. We need to have the type and name for each of those things so that we know what they are. Each subcollection should also have a single short name (ObjectGroup.collectionName) and an identifier (ObjectGroup.Identifer) so that humans and machines can tell them apart.

It may be useful, but not critical, to get an idea of the taxa represented and preservation methods used in each of those subcollections. However not everyone will have the time to add that data, so we'll make that option available but not force it at this stage.

This has implications on the structure of the data, as the mandatoryTerm = "True" and repeatableTerm = "False" values for OrganisationalUnit and StorageLocation dictate that there should be one ObjectGroup created for every combination of (in this example) department and building. More information on LtC modelling approaches can be found in the ObjectGroups and relationships section.

Step 3: add SchemeMeasurementOrFact to define the quantitative and qualitative measures that we want to include in the dataset:

{
    "@context": {
        "ltc": "http://rs.tdwg.org/ltc/terms/"
    },

    "@type": "ltc:CollectionDescriptionScheme",
    "schemeName": "NHM London departmental collections",
    "basisOfScheme": "Collections inventory",
    "distinctObjects": "True",

    "ltc:SchemeTerm": [...],

    "ltc:SchemeMeasurementOrFact": [
        {
            "@type": "ltc:SchemeMeasurementOrFact",
            "schemeMeasurementType": "Object count",
            "mandatoryMetrics": "True",
            "repeatableMetric": "False"
        },{
            "@type": "ltc:SchemeMeasurementOrFact",
            "schemeMeasurementType": "Percentage barcoded",
            "mandatoryMetric": "True",
            "repeatableMetric": "False"
        },{
            "@type": "ltc:SchemeMeasurementOrFact",
            "schemeMeasurementType": "Historical narrative",
            "mandatoryMetric": "False",
            "repeatableMetric": "False"
        }
  ],
}

In human-readable terms, this says:

For every subcollection, we expect people to provide one, and only one, estimate or count of the number of objects in that subcollection, and the same for the percentage of those objects that have been barcoded. If people have the time, we'll also provide the facility to add a historical narrative to describe the subcollection, but make that optional.

The implication of this is that we would expect to see two instances of the MeasurementOrFact class, one with measurementType of "Object count" and one of "Percentage barcoded", for every ObjectGroup linked to the CollectionDescriptionScheme, and can validate against that expectation.

This principle is not dissimilar to (although simpler than) constructs such as JSON Schema and RDF Schema, which could also be applied to LtC data if stored in that form to achieve similar ends. However, including this in the standard enables this to be applicable regardless of the data serialisation.

Examples

In the example below an LtC description record for the Insects and Invertebrate Zoology collections at the Field Museum is created and its three-term CollectionDescriptionScheme is included.

Figure 1: An example record structure that might be a useful scheme for an institution's contribution to a global registry of collections like GRSciColl.

Figure 2: Another example record structure of a way to describe all of the "famous" collections within a larger collection. In this instance, the OrganisationalUnit class is omitted, as it's implicit that this is a FMNH collection description scheme and so all collections in the dataset belong to the same institution.

In both of the above examples the distinctObjects term is 'True', because there is no overlap in objects between the two ObjectGroups, and so we can be sure that if the 'Specimen count' metric is being aggregated, nothing would be counted twice. However, if the two examples ("FMNH Collections" and "FMNH recognized Named Collections") were to be combined as a single collection description scheme in the same dataset, the distinctObjects term needs to be 'False' (Figure 3).

Figure 3: An example of a record-structure that combines ObjectGroups from the above examples, and has overlapping "Specimen count" measurements.

The distinctObjects term becomes 'False' because the "Darwin Beetles" and "Strecker Collection" ObjectGroups are actually contained within the "Insect Collections" ObjectGroup, and so if we aggregate the 'Specimen count' metric across all of the ObjectGroups in the collection description scheme, the objects in those two smaller ObjectGroups would end up being counted twice. distinctObjects being set to false provides a warning that this is the case.

For this reason, combining the two schemes into one in this scenario is likely in this example to be detrimental, as it's no longer easy to extract accurate aggregations of metrics from the dataset. It's possible to maintain multiple CollectionDescriptionSchemes within the same Latimer Core dataset, and if queries incorporate the CollectionDescriptionScheme into their logic (e.g., "aggregate 'Specimen count' for all ObjectGroups in the "FMNH Collections" CollectionDescriptionScheme"), then the issues with double-counting can still be avoided.

In addition, as shown in Figure 4, this makes it possible to add semantic relationships between ObjectGroups across the two schemes using the ResourceRelationship class for more detailed reporting - for example, to assert that the "Darwin Beetles" ObjectGroup in the "FMNH recognized Named Collections" CollectionDescriptionScheme 'is part of' the "Insect Collections" ObjectGroup in the "FMNH Collections" CollectionDescriptionScheme. More information on linking ObjectGroups can be found in the Linking ObjectGroups section.

Figure 4: Example of maintaining two collection description schemes in parallel, with ObjectGroup to ObjectGroup relationships across schemes using the ResourceRelationship class.