4. Extending the standard

Latimer Core is intended to be a standard that can be expanded to include any genre of collection, physical or digital. As such an attempt has been made to ensure that the classes and properties contained within it do not preclude such extensions.

Flexibility

• The modular design of the standard allows a high degree of flexibility in terms of schema definition: composition and architecture can be designed around the requirements of the designers system/environment, but class and term definitions, data types and vocabularies are controlled in order to support and encourage schema and LtC re-use. (flexibility is in configuration, not customisation)
• Mandatory fields are rarely specified in the LtC standard. They are intended to be defined at the schema level, according to the requirements of the specific use-case or implementation.
• Generic classes are used where possible to provide the opportunity to add non-standard or unqualified metrics and identifiers to a LtC record, but class properties should hold enough information to enable definition of logical rules to support automated parsing, ingestion and data quality measures.

Extensibility

• Extensibility was a priority during design: requirements change, most of the collections that we are seeking to describe using the standard haven’t been digitised before, so novel use cases are likely to emerge.
• Generic classes support extensibility: if new concrete classes are required, they can be added without affecting the standard definition or breaking functionality of existing implementations/schema (state/behaviour will not diverge significantly from the parent class/other implementations of the same parent class).
• Smaller, single-responsibility classes favoured: easier to understand + communicate to users, fewer dependencies, can be extended without impacting other classes.

Version 1

The classes and properties in the first draft/version of the Latimer Core standard were primarily intended to allow for the description of natural history collections, as such they reflect the categories of specimens, objects and items most usually associated with them.

Future components/discussions

• Activity and PersonActivity

  Class Name	Range (i.e., other classes to which this class can be attached)
  Activity	Event, ObjectGroup
  PersonActivity	Activity, Event, MeasurementOrFact, ObjectGroup, OrganisationalUnit, RecordLevel

  Class Name	Class-level Properties
  Activity	Identifier, PersonActivity
  PersonActivity	Address, ContactDetail, Identifier, Person, Reference, TemporalCoverage

• Connection between Latimer Core and Audubon Core

  See issue 369