Standards for date / time values?

[Richard Pyle]

Hannu wrote:

> In my understanding the "Not interpreted" case would be just a text
> string "DateTimeSourceText", repeating whatever is written in the label
> about the dates and times.  This can be useful if questions arise of the
> interpretation.

I had assumed that the CollectingDatesInterpreted value referred to the
Earliest/Latest values; not the Verbatim value.  I would tend to equate
null/empty values for the Earliest/Latest fields to be equivalent to "Not
Interpreted"; and assume that all non-null values in thes two fields to be,
by definition, interpreted.

Michael Lee  wrote:

> It seems to me that the VerbatimDate/EarliestDate/LatestDate are
> helpful, but combine two separate issues:
>
> 1) duration of the event spanning more than one date/time unit
> 2) error associated with the date.

These are two of several possible meanings of two date values that I tried
to qualify with my "DateRangeQualifier" attribute.

There are actually a number of possible meanings/interpretations for a pair
of date/time values, but in most cases, one could interpret a date range as
either of the following:

- Event spanned entire range
- Event occurred at a single point in time somewhere within this range
(Same as what you said, but stated in a different way.)

However, I prefer to view the Earliest/Latest pair of values to have the
specific meaning of "collection event did not likely begin prior to
[Earliest], and did not likely end after [Latest]". In other words, I view
it as always meaning, with some degree of certainty, "collection event took
place within this window of time", independently of the duration of the
event itself.  If "Duration" of sampling event is imporant (e.g., plankton
tow), I think it might best be documented secondarily, elsewhere.  It could
be handled with something like dateTimeAccuracy; but it seems to me that you
would then have two subjective values (the scale of dateTimeAccuracy seems
like it's subjectively defined?)

Arthur wrote:

> This is an interesting discussion, and I am wondering why we
> treat dates/times differently to localities where we may have
> "between two places", "near a place", "along a path", etc.

I think there are many parallels, and you could manage Date values
analagously to the MaNIS protocol for establishing georef coordinates with
max error.  But  my feeling is that this would be overkill except in very
specific use-cases involving seasonally critical datasets, or organisms with
large-scale temporal cycles.  I think in most use-cases,
verbatim/Earliest/Latest provides most of the information that most of the
people are interested in.  Which leads me to...

Roger wrote:

> Who is using data scored like this - actually searching on and
> analyzing data that was scored to 'summer', 'autumn', 'early 19th century'
>
> This thread seems to be a great deal about how to capture data from
various
> historic sources but what are the use cases for exploitation of it?

Use cases I deal with are things like establishing first/last known
occurences of taxon X at locality Y; tracking down patterns of (long-term)
periodicity in taxon occurance, and establishing patterns of seasonality
(among others).  The reason I feel that the three
Verbatim/InterpretedEarliest/InterpretedLatest set covers me is that the
first one really represents the *actual* [meta]data, whereas the other two
are useful for getting a computer to sort & filter chronomogically.

Aloha,
Rich