2.2 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.

Firstly, 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.

Secondly, 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": "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"
        }
  ]
}

{
    "@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",
            "mandatoryMetrics": "True",
            "repeatableMetric": "False"
        },{
            "@type": "ltc:SchemeMeasurementOrFact",
            "schemeMeasurementType": "Historical narrative",
            "mandatoryMetrics": "False",
            "repeatableMetric": "False"
        }
  ],
}

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 GRSciColl records.

Figure 2: Another example record structure of a way to describe all of the "famous" collections within a larger collection.

In both of the above examples the distinctObjects term is 'True', because no metric is associated with a description that could cause objects to be counted twice. However, if the two examples (GRSciColl and Famous collections) are nested in a single record, the distinctObjects term needs to be 'False'.

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 count metric for the OrganisationalUnit contains within it the objects and metrics associated with the ObjectGroup (i.e. specimen count).

Latimer Core is intended to be flexible for use to accommodate as much as possible future use cases, CollectionDescriptionScheme serves as the “definition” of any scheme that is developed.