4. Classes
For quick reference, Table 5 below lists all of the classes included in the current version of the standard, plus some additional classes proposed but not yet incorporated.
| Class Name | Description | Issue # | In LtC v1 |
| Activity | An activity is something that occurs over a period of time and acts upon or with entities; it may include consuming, processing, transforming, modifying, relocating, using, or generating entities. | https://github.com/tdwg/cd/issues/310 | No |
| Address | A physical address for an organisational unit or person. | https://github.com/tdwg/cd/issues/208 | Yes |
| ChronometricAge | The age of a specimen or related materials that is generated from a dating assay. | https://github.com/tdwg/cd/issues/268 | Yes |
| CollectionStatusHistory | A record of current and past statuses of the object group and the reason for status changes. | https://github.com/tdwg/cd/issues/120 | Yes |
| ContactDetail | Details of a method by which an entity such as a Person or OrganisationalUnit may be contacted. | https://github.com/tdwg/cd/issues/329 | Yes |
| EcologicalContext | The ecological and/or biogeographic classification of the region from which objects associated with the ObjectGroup were collected, or where an Event took place. | Yes | |
| Event | An action that occurs at some location during some time. | https://github.com/tdwg/cd/issues/362 | Yes |
| GeographicContext | The geographic location from which objects associated with the ObjectGroup were collected, or where an Event took place. | https://github.com/tdwg/cd/issues/131 | Yes |
| GeologicalContext | Geological information, such as stratigraphy, that qualifies a region or place. | https://github.com/tdwg/cd/issues/178 | Yes |
| Identifier | A numeric, textual value, or reference such as an IRI, that can be used to uniquely identify the object to which it is attached. | https://github.com/tdwg/cd/issues/126 | Yes |
| LatimerCoreScheme | A grouping of multiple ObjectGroups for a particular use case, purpose or implementation. | https://github.com/tdwg/cd/issues/109 | Yes |
| MeasurementOrFact | A measurement of or fact about a class within the standard, or a relationship between the ObjectGroup and an associated class. | https://github.com/tdwg/cd/issues/289 | Yes |
| ObjectClassification | An informal classification of the type of objects within the ObjectGroup, using a hierarchical structure. | https://github.com/tdwg/cd/issues/214 | Yes |
| ObjectGroup | An intentionally grouped set of objects with one or more common characteristics. | https://github.com/tdwg/cd/issues/55 | Yes |
| OrganisationalUnit | A unit within an organisational hierarchy which may be at, above or below the institutional level. | https://github.com/tdwg/cd/issues/197 | Yes |
| Person | A person (alive or dead). | https://github.com/tdwg/cd/issues/219 | Yes |
| PersonActivity | A link between a Person and an Activity to enable the role that the Person played in the Activity to be specified. | https://github.com/tdwg/cd/issues/314 | No |
| PersonRole | A qualified association between a Person or OrganisationalUnit and an entity such as an ObjectGroup or MeasurementOrFact that enables the relationship to be contextualised with a specific role and time period. | https://github.com/tdwg/cd/issues/316 | Yes |
| RecordLevel | The machine-actionable information profile for the collection description digital object. | https://github.com/tdwg/cd/issues/43 | Yes |
| Reference | A reference to external resources and information related to the class. | https://github.com/tdwg/cd/issues/231 | Yes |
| ResourceRelationship | A relationship between an instance of a class in the collection description standard to another instance of the same class, or an instance of a different class in the standard. | https://github.com/tdwg/cd/issues/279 | Yes |
| Role | The function of a Person with respect to an activity or entity. | Yes | |
| SchemeMeasurementOrFact | A type of measurement or fact used by the LatimerCoreScheme, and the rules relating to its application. | https://github.com/tdwg/cd/issues/117 | Yes |
| SchemeTerm | A Latimer Core term used by the LatimerCoreScheme and the rules relating to its application. | https://github.com/tdwg/cd/issues/113 | Yes |
| StorageLocation | A physical location (such as a building, room, cabinet or drawer) within the holding institution where objects associated with the collection description are stored or exhibited. | https://github.com/tdwg/cd/issues/164 | Yes |
| Taxon | A group of organisms (sensu http://purl.obolibrary.org/obo/OBI_0100026) considered by taxonomists to form a homogeneous unit. | https://github.com/tdwg/cd/issues/269 | Yes |
| TemporalCoverage | The time period during which the related event, activity or status was occurring. | https://github.com/tdwg/cd/issues/333 | Yes |
Table 5: A summary of the classes in the LtC standard, with links to the normative definitions and Github issues used to build the definitions.
As described in the Summary of LtC classes section, the LtC standard (version 1) is made up of 23 classes, each with two or more properties. The central concept of the standard is the ObjectGroup class, which represents ‘an intentionally grouped set of objects with one or more common characteristics’. Arranged around the ObjectGroup are a set of classes, such as GeographicContext, Taxon and GeologicalContext, which are commonly used to describe and classify the objects within the ObjectGroup. There are a set of classes (OrganisationalUnit, CollectionStatusHistory and StorageLocation) intended to reflect aspects of the custodianship, management and tracking of the collections, and a generic class (MeasurementOrFact) for storing metrics, narratives and other qualitative or quantitative measures within the standard. A further set of generic, reusable classes are included that enable common concepts (such as people, identifiers and references) to be attached to multiple classes within the standard. Finally, there’s a set of classes that are used to describe the structure of and metadata about the LtC records and contents themselves.
These are illustrated in Figure 6 below, and the concepts are described in more detail later in this section.
Figure 6: An overview and informal categorisation of LtC classes for describing the ObjectGroup’s characteristics (green), collections custody (purple), generic reusable information types (dark blue), metrics (red), and data structure and links (light blue).
The ObjectGroup is the core class and concept of the LtC standard. It represents any set of physical or digital objects that we want to describe together as a group, as opposed to representing and describing each individual separately. This will generally be for one or both of the following reasons:
- There aren’t yet, or may never be, individual digital records for all of the separate objects, but we still want to capture, use and share data about them at a higher level, or
- There is information that applies to the group as a whole (e.g. a narrative or history, a registration number or a contact person), so we want to store this information at the group level rather than duplicating it across multiple object-level records.
In cases where collections are completely digitized much of the ObjectGroup data could be generated by aggregating individual records, but, there are still likely to be use cases for managing some information at the group level which can’t be obtained from the specimen records.
The Latimer Core definition of an ObjectGroup is
"An intentionally grouped set of objects with one or more common characteristics."
This is a purposefully broad definition that allows the standard to encompass a wide range of use cases for describing collections or their parts for different reasons. Although the most common and familiar use of collection descriptions has been to describe the collection of a particular institution, conceptually an ObjectGroup can represent any set and number of objects that need to be grouped for any purpose. This can scale from a few objects in a drawer to the sum total of all the collections of global natural science institutions: both of these can be represented by an ObjectGroup, as can any level of grouping in between.
Some more practical examples of what may be represented by an ObjectGroup include:
- The collections of a single institution
- The herbarium collection of a single institution
- A specific collection of a single institution, e.g. a herbarium collection, wet invertebrates collection, or Mesozoic mammal collection.
- A named collection provided by a specific donor, or collected by a significant collector
- The unincorporated objects of a particular department within an institution
- The objects in a single drawer, cabinet or room for inventory purposes
- A set of objects brought into an institution together, e.g. from a field trip, several field trips, or a donation from another institution.
- A database of images taken from collection specimens
- A dataset of butterfly observations taken as a monitoring time series
- An ex situ tree plantation rescuing remaining genotypes of European ash
- A virtual collection representing all penguin individuals and populations in zoos and aquaria worldwide
- Collections of sightings of animals as part of environmental impact/mitigation projects (e.g., Toads on Roads)
Each of these represent a number of objects that are grouped for a certain purpose, with one or more common characteristics (for example, belonging to the same institution, being from the same stratigraphic time period, or being collected by the same person). Those characteristics are described by the ObjectGroup's properties and the other associated classes in LtC, as summarised in Figure 7.
Figure 7: A summary of the ObjectGroup's properties and other associated classes that describe the characteristics of the objects within the group.
Collections are held by caregivers. Some collections start out as privately held assemblages, associated generally with a single person. Over the longer term, most surviving collections become preserved and managed by institutions, including for example public or private institutions, organisations, and corporations. Institutions are the administrative entities that are stewards or owners of collections, provide administrative services, maintain and preserve collections, and often employ or dedicate responsible staff to actively manage collections.
For the purpose of integration into a globally applicable collections registry scheme, private collections can be considered to be held by a person of a corresponding role (e.g. “steward”) and be part of a theoretical organisation (e.g. “independent operation”, “private residence”). For a more general discussion of organisations, persons and groups as agents see the FOAF Vocabulary Specification (http://xmlns.com/foaf/spec/).
An important element to stress is the distinction between the organisational unit that holds a collection, and the collection itself. An institution is represented by the class OrganisationalUnit and its properties. A collection within that institution is represented by an ObjectGroup. The two can be linked together (Figure 8) to represent the custodianship of the OrganisationalUnit for the ObjectGroup. This means that the properties describing the institution are restricted to the OrganisationalUnit and associated classes, while any data describing the collection and the objects within it are represented either by ObjectGroup properties, or instances of other LtC classes linked to the ObjectGroup.
Figure 8: An example of representing and linking organisational units and collections using the LtC standard.
In the LtC standard, the institution concept is inspired by the more generic framework provided by the W3C Organization Ontology (ORG, https://www.w3.org/TR/vocab-org/). Institutions can be represented by the OrganisationalUnit class, which is more broadly defined than the corresponding term in the ORG standard. In the LtC standard, its definition combines characteristics of both the org:Organization and org:OrganizationalUnit classes, providing more flexibility. Plans for the future include further development of the intersection between ORG and LtC, to improve alignment and thus enable seamless extension and integration of both standards by each other.
The LtC class OrganisationalUnit provides a simplified approach to representing institutional information and institutional structure, for example, for a local collection management catalogue maintained by a collection-holding institution or a local research group managing their research collections and groups of specimens on loan from a variety of scientific collections. In these cases, it can be sufficient to provide the ltc:OrganisationalUnits directly responsible for the collections or groups of objects. It might not be necessary to represent complete, sometimes byzantine institutional hierarchies.
For larger-scale, e.g. national to regional and global, registry projects, as for example GRSciColl (https://www.gbif.org/grscicoll) and GGBN (https://www.ggbn.org/ggbn_portal/), as well as longer-term LtC-based implementations that are expected to grow and develop, we recommend to take advantage of the full functionality and power of the Organization Ontology standard for representing institutions, their legal status, structure, employees, addresses, etc. (Figure 9). The seamless linking to and extension of LtC by the Organization Ontology W3C standard, and the other way around, is made possible by the Darwin Core dwc:ResourceRelationship class (see below). Thereby, the integration of collection and institution registries, e.g. the GBIF Registry of Scientific Collections (https://www.gbif.org/grscicoll) and the Research Organization Registry (https://ror.org/) is enabled (see e.g. Politze 2021, https://easychair.org/publications/open/r8Dv). In general, this option provides implementers of LtC to choose whether to use the LtC OrganisationalUnit and associated generic classes to represent organisations and related structures, or to instead link in ORG for more complex structures. It should also prove relatively straightforward to start with the former, and transition to the latter at a later point in time.
Figure 9: With reference to the example in Figure 8, an example of using ORG with LtC to represent organisations and organisational units, instead of the LtC OrganisationalUnit class.
The ltc:OrganisationalUnit class can represent, in addition to institutions as (legal) entities, subdivisions at different levels within an institution (e.g. departments, divisions, sections, faculties etc), as well as organisations at a higher level of the collection-holding institution (for example, a museum may be a subunit within the organisational structure of a university). Terms to be used in predefined vocabularies identifying the hierarchical position of an organisational unit within an organisational structure can be found in the “Academic Institution Internal Structure Ontology” (AIISO; https://vocab.org/aiiso/).
Within LtC, OrganisationalUnits can be linked together into a hierarchy or structure using the ltc:hasParentOrganisationalUnit class. Similarly, the links between the institutional level (implemented within the LtC or following the ORG standard) and the collection level (LtC standard) are built using the dwc:ResourceRelationship class. The dwc:relationshipOfResource property of the class should be used to describe the nature of the relationship. It is recommended best practice (see https://dwc.tdwg.org/list/#dwc_ResourceRelationship) to use a controlled vocabulary to describe those relationships. Relationship types listed as examples by the Darwin Core webpage are “same as”, “part of”, “contains”. Alternatively, AIISO terms can be used, e.g. part_of, responsibilityOf, responsibleFor.
Within the ObjectGroup-centric LtC model, associated OrganisationalUnits are essentially treated as properties of the ObjectGroup, rather than as a higher level in a rigid hierarchy. The notation for the property organisationalUnitName of the class OrganisationalUnit is correctly ltc:ObjectGroup.OrganisationalUnit.organisationalUnitName or in a short form ltc:OrganisationalUnit.organisationalUnitName, since in LtC the ObjectGroup class is per default the core element.
In a general graph context (Figure 8 and Figure 9), both classes, ObjectGroup and OrganisationalUnit, can be considered to be at the same level and can be directly associated (they are within each other’s range, see the section on Class ranges and relationships). This link can be looked at and approached from both directions, the point of view taken thereby varies between concrete use cases and serialisations. The collection-centric LtC perspective is to approach the association from the side of the ObjectGroup, therefore, in LtC OrganisationalUnit is a class-level property of ObjectGroup, accordingly in Table 1 of the Class ranges and relationships section, only OrganisationalUnit can be attached to ObjectGroup and not the other way around. However, in a context outside of LtC, e.g. with a focus on describing organisations (cp. the W3C org ontology), ObjectGroup will be a class-level property of Organization or OrganizationalUnit.
Some classes can be used in multiple contexts within the LtC standard. These classes, listed in Table 6, are referred to here as ‘generic’ classes.
Generic classes represent a type of entity or concept that can be a property of, or associated with, several LtC classes. An OrganisationalUnit, Taxon, and Person all might require an Identifier of some sort, for instance. Rather than explicitly repeating the same set of fields within each class, each class includes a hasIdentifier term which may contain one or more instances of the generic Identifier class.
| Generic Class | Range |
| Address | OrganisationalUnit, Person, PersonRole, StorageLocation |
| ContactDetail | OrganisationalUnit, Person, PersonRole |
| Identifier | Address, ChronometricAge, CollectionStatusHistory, ContactDetail, EcologicalContext, Event, GeographicContext, GeologicalContext, LatimerCoreScheme, MeasurementOrFact, ObjectClassification, ObjectGroup, OrganisationalUnit, Person, PersonRole, RecordLevel, Reference, ResourceRelationship, Role, SchemeMeasurementOrFact, SchemeTerm, StorageLocation, Taxon |
| MeasurementorFact | ChronometricAge, CollectionStatusHistory, EcologicalContext, Event, GeographicContext, GeologicalContext, ObjectClassification, ObjectGroup, OrganisationalUnit, Person, PersonRole, StorageLocation, Taxon, TemporalCoverage |
| Person | PersonRole |
| PersonRole | Event, ObjectGroup, OrganisationalUnit, RecordLevel |
| Reference | ChronometricAge, CollectionStatusHistory, EcologicalContext, Event, GeographicContext, GeologicalContext, Identifier, LatimerCoreScheme, MeasurementOrFact, ObjectClassification, ObjectGroup, OrganisationalUnit, Person, PersonRole, RecordLevel, ResourceRelationship, SchemeMeasurementOrFact, SchemeTerm, StorageLocation, Taxon, TemporalCoverage |
| ResourceRelationship | ObjectGroup, RecordLevel |
| Role | PersonRole |
| TemporalCoverage | CollectionStatusHistory, Event, PersonRole |
Table 6: List of Latimer Core generic classes and ranges
Figures 10, 11, and 12 illustrate how instances of the generic Identifier class can be used to represent Person, institutional (OrganisationalUnit) and Taxon identifiers.
{
"@context":
{
"ltc": "http://rs.tdwg.org/ltc/"
},
"@type": "ltc:OrganisationalUnit",
"ltc:hasIdentifier":
[
{
"@type": "ltc:Identifier",
"ltc:identifierType": "Acronym",
"ltc:identifierValue": "EMNH"
},
{
"@type": "ltc:Identifier",
"ltc:identifierType": "Acronym",
"ltc:identifierValue": "EM(NH)"
},
{
"@type": "ltc:Identifier",
"ltc:identifierType": "URI",
"ltc:identifierSource": "https://ror.org/",
"ltc:identifierValue": "099zvsn29"
}
],
"ltc:organisationalUnitName": "Erehwon Museum of Natural History",
"ltc:organisationalUnitType": "Institution",
"ltc:organisationalUnitAlternativeName": "Museum of Natural History, Erehwon"
}
Figure 10: Using the Identifier class to represent an institutional identifier. (JSON file in LtC repo)
{
"@context":
{
"schema": "https://schema.org/",
"abcd": "http://rs.tdwg.org/abcd/",
"ltc": "http://rs.tdwg.org/ltc/"
},
"@type": "ltc:Person",
"ltc:hasIdentifier":
[
{
"@type": "ltc:Identifier",
"ltc:identifierType": "URI",
"ltc:identifierSource": "https://www.worldcat.org/identities/",
"ltc:identifierValue": "lccn-n85816396"
},
{
"@type": "ltc:Identifier",
"ltc:identifierType": "URI",
"ltc:identifierSource": "https://www.wikidata.org/wiki/",
"ltc:identifierValue": "Q371568"
},
{
"@type": "ltc:Identifier",
"ltc:identifierType": "URI",
"ltc:identifierSource": "https://viaf.org/viaf/",
"ltc:identifierValue": "38383989"
}
],
"schema:additionalName": "Eileen Doris",
"schema:familyName": "Courtenay-Latimer",
"schema:givenName": "Marjorie",
"abcd:fullName": "Marjorie Eileen Doris Courtenay-Latimer"
}
Figure 11: Using the Identifier class to represent a person identifier. (JSON file in Latimer Core repo)
{
"@context":
{
"dwc": "http://rs.tdwg.org/dwc/",
"ltc": "http://rs.tdwg.org/ltc/"
},
"@type": "ltc:Taxon",
"ltc:hasIdentifier":
[
{
"@type": "ltc:Identifier",
"ltc:identifierType": "URI",
"ltc:identifierSource": "https://www.checklistbank.org/dataset/9812/taxon/",
"ltc:identifierValue": "84SNJ"
},
{
"@type": "ltc:Identifier",
"ltc:identifierType": "URI",
"ltc:identifierSource": "https://marinespecies.org/authority/metadata.php?lsid=",
"ltc:identifierValue": "urn:lsid:marinespecies.org:taxname:116116"
},
{
"@type": "ltc:Identifier",
"ltc:identifierType": "URI",
"ltc:identifierSource": "https://www.wikidata.org/wiki/",
"ltc:identifierValue": "Q2391885"
}
],
"dwc:order": "Priapulimorphida",
"dwc:family": "Priapulidae",
"dwc:genus": "Priapulus"
}
Figure 12: Using the Identifier class to represent a taxon identifier. (JSON file in the Latimer Core repo)
The overall purpose of any given instance of a generic class can be inferred from its context in the record: a ContactDetail that is associated with or nested within an OrganisationalUnit is an organisational contact point, but a ContactDetail associated or nested within a Person should be interpreted as that Person's preferred method of contact (illustrated in Figure 13).
{
"@context": {
"ltc": "http://rs.tdwg.org/ltc/",
"schema": "https://schema.org/",
"abcd": "http://rs.tdwg.org/abcd/"
},
"@type": "ltc:OrganisationalUnit",
"ltc:hasContactDetail": [
{
"@type": "ltc:ContactDetail",
"contactDetailCategory": "email",
"contactDetailType": "General enquiries",
"contactDetailValue": "enquiries@emnh.org"
}
],
"ltc:hasPersonRole": [
{
"@type": "PersonRole",
"role": "Registrar",
"ltc:hasPerson": [
{
"@type": "ltc:Person",
"schema:additionalName": "Virginia",
"schema:familyName": "Mountweazel",
"schema:givenName": "Lillian",
"abcd:fullName": "Lillian Virginia Mountweazel",
"ltc:hasContactDetail": [
{
"@type": "ltc:ContactDetail",
"contactDetailCategory": "email",
"contactDetailType": "Collection enquiries",
"contactDetailValue": "v.mountweazel@emnh.org"
}
]
}
]
}
],
"ltc:organisationalUnitAlternativeName": "Museum of Natural History, Erehwon",
"ltc:organisationalUnitName": "Erehwon Museum of Natural History",
"ltc:organisationalUnitType": "Institution"
}
Figure 13: Using the ContactDetail class to represent an institutional email address and a named individual’s email address. (JSON file in the Latimer Core repo)
There are several benefits to taking this approach, using the Identifier class as an example:
- Flexibility: a generic
Identifierclass can be used to represent any identifier relevant to classes within its range, so the standard needn’t attempt to anticipate all potential current or future use cases. - Extensibility: The concept can have additional properties that describe it further: e.g.
Identifieris further described byidentifierSource,identifierTypeetc. - It reduces the number of properties in the standard by reusing generic classes.
- It supports the association of multiple identifiers (as shown in Figures 4, 5 and 6) with an entity: see the Repeatability section.
To handle people and roles, LtC uses a simplified version of the RDA/TDWG Attribution metadata recommendations (https://datascience.codata.org/articles/10.5334/dsj-2019-054/), which is largely based on the PROV ontology for presenting provenance (https://www.w3.org/TR/prov-o/). Using this approach avoids both the hardcoding of all potential roles people might play in relation to the different classes in the standard, and the proliferation of similar properties that would be required to support them.
To this end, there are three classes within the standard that are used to represent people and roles: Person, PersonRole and Role. The Person class is used to describe the relevant person, and the PersonRole to attach that person to another class and, with an associated Role class, to define the role that they played in the context of that class (and, optionally, the time frame during which they fulfilled that role). PersonRole is a generic class (see previous section) which can be attached to a range of other classes within the standard, as demonstrated in Figures 14, 15 and 16 below. The separation of Role into a separate class is largely to help to support the use of shared role vocabularies such as the Contributor Roles Taxonomy (CRediT) with machine-readable persistent identifiers, and to potentially attribute more than one of these roles to a single PersonRole association between a Person and an OrganisationalUnit, Event, ObjectGroup etc.
Figure 14: Summary of the classes that can be used to define the relationships between people and (in this example) organisational units.
Figure 15: Linking people to other classes using the PersonRole and Role classes.
Figure 16: An example of using the Person and PersonRole classes to link people to collections, organisations and digital records in the relevant contexts.
The LtC standard implementation differs from the RDA/TDWG recommendations in a couple of key respects: - Rather than use the PROV Agent entity, which has subclasses of Person, Organization and SoftwareAgent, LtC currently only uses the ‘Person’ subtype within this model, and OrganisationalUnit is represented by a separate class. - The PROV model connects the Agent to an Entity using an Activity class, with the role represented by a qualified association between the Agent and the Activity. In the current version of LtC, the activity concept has been removed from the model to simplify the association. These modifications are largely to reduce the level of abstraction in the initial version of LtC, and make the classes more familiar and model simpler for users of the standard. There may be potential to use the full Agent scope and introduce the Activity concept in future iterations of LtC to more fully align with PROV and possible developments within other TDWG standards.