Class:TemporalCoverage

[mswoodburn]

Parent
Label	Temporal Coverage
Definition	A record of a time range represented by the collection's establishment or change over time. This term is separate from the living or geologic periods represented by the objects in the collection.
Usage
Required	No
Repeatable	Yes
Relationships	Range: CollectionStatusHistory, Event, MeasurementOrFact, OrganisationalUnit, PersonRole, ResourceRelationship | Class-level properties: MeasurementOrFact, Reference
Potential standards/vocabularies/ontologies to adopt
Notes	This class can be used to reflect temporal coverage of the collection within various contexts (defined by the temporalCoverageType property). Examples might include the time range in which objects within the collection were collected or the time period over which the collection was assembled. It should not be used to document the time range within which the objects in the collection were alive, and if the time period you are trying to describe is better described by the CollectionHistory, GeologicalContext or ChronometricAge classes, or period property of the ObjectGroup class, then those classes or properties should be used instead. For example, the period property of the ObjectGroup class and/or GeologicalContext class should be used to record named time periods. TemporalCoverage is a repeatable class, but when present as a property of Event or CollectionStatusHistory, multiple occurences should be avoided and repeated occurences of the parent class should be used instead.

[smrgeoinfo]

Do you really mean to restrict the domain of temporalCoverage to a collection? Seems that given the label, why not define it as a specification of a temporal extent, with domain = Perdurant (event or process instance). Physical objects only have temporal extent indirectly, based on their participation in some event(s); the events have temporal extent.

[rondlg]

As it stands, repeatable classes are repeatable in any context, i.e., regardless of the class to which they are attached. Some classes seem to warrant different repeatability allowances in different situations.

For example, TemporalCoverage is repeatable, but in most use cases only a single attachment is needed. An Event seems like it should only ever have a single TemporalCoverage class attached.

However, there may be use cases in which this makes sense (we just don’t know what they are), and in the interest of not overcomplicating recommended use, we are only defining classes as repeatable in any context or none.