-
Notifications
You must be signed in to change notification settings - Fork 1
6. Structural Connections
The range of a LtC class defines the classes to which it can validly be attached. This is intended to provide guidelines for reasonable interconnections between classes that are useful when describing a given aspect of a collection. For example, the TemporalCoverage
class can be validly attached to the CollectionStatusHistory
, Event
, or PersonRole
classes in order to document the time spans for those classes.
Class Name | Range (i.e., other classes to which the class in the first column can be attached) |
Address | OrganisationalUnit, Person, PersonRole, StorageLocation |
ChronometricAge | ObjectGroup |
CollectionStatusHistory | ObjectGroup |
ContactDetail | OrganisationalUnit, Person, PersonRole |
EcologicalContext | Event, ObjectGroup |
Event | Event, ObjectGroup |
GeographicContext | Event, ObjectGroup |
GeologicalContext | ObjectGroup |
Identifier | Address, ChronometricAge, CollectionStatusHistory, ContactDetail, EcologicalContext, Event, GeographicContext, GeologicalContext, LatimerCoreScheme, MeasurementOrFact, ObjectClassification, ObjectGroup, OrganisationalUnit, Person, PersonRole, RecordLevel, Reference, ResourceRelationship, Role, SchemeMeasurementOrFact, SchemeTerm, StorageLocation, Taxon |
LatimerCoreScheme | |
MeasurementOrFact | ChronometricAge, CollectionStatusHistory, EcologicalContext, Event, GeographicContext, GeologicalContext, ObjectClassification, ObjectGroup, OrganisationalUnit, Person, PersonRole, StorageLocation, Taxon, TemporalCoverage |
ObjectClassification | ObjectClassification, ObjectGroup |
ObjectGroup | LatimerCoreScheme, RecordLevel |
OrganisationalUnit | ObjectGroup, OrganisationalUnit |
Person | PersonRole |
PersonRole | Event, ObjectGroup, OrganisationalUnit, RecordLevel |
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 |
SchemeMeasurementOrFact | LatimerCoreScheme |
SchemeTerm | LatimerCoreScheme |
StorageLocation | ObjectGroup, StorageLocation |
Taxon | ObjectGroup |
TemporalCoverage | CollectionStatusHistory, Event, PersonRole |
Table 9: Ranges for each Latimer Core class
Conversely, the class-level properties define which other classes can be attached to a given LtC class:
Class Name | Class-level Properties |
Address | Identifier |
ChronometricAge | Identifier, MeasurementOrFact, Reference |
CollectionStatusHistory | Identifier, MeasurementOrFact, Reference, TemporalCoverage |
ContactDetail | Identifier |
EcologicalContext | Identifier, MeasurementOrFact, Reference |
Event | EcologicalContext, GeographicContext, Identifier, MeasurementOrFact, Event, PersonRole, Reference, TemporalCoverage |
GeographicContext | Identifier, MeasurementOrFact, Reference |
GeologicalContext | Identifier, MeasurementOrFact, Reference |
Identifier | Reference |
LatimerCoreScheme | Identifier, ObjectGroup, Reference, SchemeMeasurementOrFact, SchemeTerm |
MeasurementOrFact | Identifier, Reference |
ObjectClassification | Identifier, MeasurementOrFact, ObjectClassification, Reference |
ObjectGroup | ChronometricAge, CollectionStatusHistory, EcologicalContext, Event, GeographicContext, GeologicalContext, Identifier, MeasurementOrFact, ObjectClassification, OrganisationalUnit, PersonRole, Reference, ResourceRelationship, StorageLocation, Taxon |
OrganisationalUnit | Address, ContactDetail, Identifier, MeasurementOrFact, OrganisationalUnit, PersonRole, Reference |
Person | Address, ContactDetail, Identifier, MeasurementOrFact, Reference |
PersonRole | Address, ContactDetail, Identifier, MeasurementOrFact, Person, Reference, Role, TemporalCoverage |
RecordLevel | Identifier, ObjectGroup, PersonRole, Reference, ResourceRelationship |
Reference | Identifier |
ResourceRelationship | Identifier, Reference |
Role | Identifier |
SchemeMeasurementOrFact | Identifier, Reference |
SchemeTerm | Identifier, Reference |
StorageLocation | Address, Identifier, MeasurementOrFact, StorageLocation, Reference |
Taxon | Identifier, MeasurementOrFact, Reference |
TemporalCoverage | MeasurementOrFact, Reference |
Table 10: Class-level properties for each Latimer Core class
The design decisions for the structure of LtC give rise to the general principle that, with one exception, only classes within the standard can be repeated, not individual properties within classes. For example, if a work phone contact point has two phone numbers, then the ltc:ContactDetail class is repeated for this contact point, resulting in two full sets of phone contact details. Repeating only the ltc:ContactDetail.contactDetailValue property, or changing its stored information from a single string to an array containing several strings, is not allowed. Such an approach would run counter to the spirit of the standard's design, and break its overall structure. In consequence, the contact point, e.g. a ltc:ObjectGroup or ltc:PersonRole that has the two phone contact options will have a "hasContactDetail" term, which represents and collects links to, i.e. stands in for the ltc:ContactDetail class, with a value that is an array storing the two sets of ltc:ContactDetail information as sub-arrays.
One important exception however, exists in the form of the standard's core ltc:ObjectGroup class that rests at the center of the standard's data model. In this class, all properties have as values arrays with zero to many entries. Thus, for an ltc:ObjectGroup that digitally represents a fish collection with objects preserved in alcohol or formaldehyde, ltc:ObjectGroup.preservationMethod validly can be represented as an array of [alcohol, formaldehyde].
Over time different standards have handled repeatability by pipe-delimiting multiple values in a single field, versus nested or related tables or classes. LtC aims to take a pragmatic approach, given the variety of possible relationships among classes.
How repeatability is handled in an LtC implementation depends largely on which data serialisation format is used. Taking the period
property of the ObjectGroup
class as an example, the appropriate methods might be:
-
an array, if using JSON or RDF **
"ltc:period": ["Neolithic Period", "McCarthy Era"]
-
a normalised table, if using a relational database
|
|
|
|
|
|
- a repeated set of numbered columns for the same property, if using a spreadsheet or csv file (e.g. period.1, period.2)
|
|
|
|
- multiple pipe-delimited values, if using a flat text format
|
|
As it stands, repeatable classes are repeatable in any context, i.e., regardless of the class to which they are attached. Some classes may seem to warrant different repeatability allowances in different situations. We leave the choice to the user.
Taking the Identifier
class as an example, the appropriate methods for representing multiple identifiers for an ObjectGroup
might be:
- an array of objects, if using JSON or RDF
"Identifier": [
{
"ltc:identifierSource": "GrSciColl",
"ltc:identifierValue": "urn:uuid:ea4f0640-ef20-40aa-b359-166f07c7492a",
"ltc:identifierType": "UUID"
},
{
"ltc:identifierSource": "GrBio",
"ltc:identifierValue": "http://grbio.org/cool/zdsi-36ka",
"ltc:identifierType": "LSID"
}
]
- a normalised table, if using a relational database
auto_id | ltc:identifierSource | ltc:identifierValue | ltc:identifierType |
1 | GrSciColl | urn:uuid:ea4f0640-ef20-40aa-b359-166f07c7492a | UUID |
2 | GrBio | http://grbio.org/cool/zdsi-36ka | LSID |
- a repeated set of numbered columns for the same property, if using a spreadsheet or csv file
ltc:identifierSource.1 | ltc:identifierValue.1 | ltc:identifierType.1 | ltc:identifierSource.2 | ltc:identifierValue.2 | ltc:identifierType.2 |
GrSciColl | urn:uuid:ea4f0640-ef20-40aa-b359-166f07c7492a | UUID | GrBio | http://grbio.org/cool/zdsi-36ka | LSID |
-
multiple pipe-delimited values, if using a flat text format
- In LtC, it is not recommended to repeat properties within repeatable classes. For example, if an
identifierSource
corresponded to two ltc:identifierValue values, repeat each identifier’s source, value, and type in parallel:
- In LtC, it is not recommended to repeat properties within repeatable classes. For example, if an
ltc:identifierSource | ltc:identifierValue | ltc:identifierType |
GrSciColl | GrBio | urn:uuid:ea4f0640-ef20-40aa-b359-166f07c7492a | http://grbio.org/cool/zdsi-36ka | UUID | LSID |
* Do not nest comma-delimited values within pipe-delimited values:
ltc:identifierSource | ltc:identifierValue | ltc:identifierType |
Ouch | Yikes | urn:uuid:ea4f0640-ef20-40aa-b359-166f07c7492a | http://grbio.org/cool/zdsi-36ka, http://grbio.org/cool/zdsi-36kb | UUID | LSID, LSID |