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:
- duration of the event spanning more than one date/time unit
- 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