<div>Patricia, and all,</div>
<div> </div>
<div>The ISO 8601 standard specifies the format explicitly. The W3C implementation of it is explained at <a href="http://www.w3.org/TR/NOTE-datetime">http://www.w3.org/TR/NOTE-datetime</a>. Your point is well taken though, some interpretation of original data (
e.g., expanding two-digit years to four digits) will often have to be done to express dates as xsd:dateTime.<br> </div>
<div>Can you justify the separation (or addition) of the time fields? It may ease the expression of queries on time independent of date. It may also allow one to express a discrete across a date range (e.g., 17:00 every day in June 2005). This seems like an exceptional case. Is that worth adding two more concepts to accomodate this?
</div>
<div> </div>
<div>John</div>
<div> </div>
<div><span class="gmail_quote">On 2/24/06, <b class="gmail_sendername">Patricia Koleff Osorio</b> <<a href="mailto:pkoleff@xolo.conabio.gob.mx">pkoleff@xolo.conabio.gob.mx</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">We should be clear on format for Early and Latest CollectionDate, meaning<br>to store data as DDMMYYYY<br>
There are some old specimens missing the day or even the month (and only<br>have years, and even not the complete year, only the like 79)<br>I think that time hour should be another field, noting that must be refered<br>to the locality
<br>Regards<br>Patricia Koleff<br><br><br>At 12:00 a.m. 24/02/2006 -1000, Richard Pyle wrote:<br>>RE: CollectingDatesInterpreted<br>>When would this field *not* be set to true? In other words, what is the<br>>threshold for "interpreted", in terms of populating EarliestCollectingDate
<br>>and LatestCollectingDate?<br>><br>>At one extreme, we have a VerbatimDateTime of "12 January 2005, 13:34:15<br>>local time". Not a lot of interpretation needed there (other than<br>>conversion of original documentation format to ASCII/Unicode, and
<br>>interpretation of the time zone from the locality data). But conversion of<br>>"12 January 2005" to<br>><br>>EarliestCollectingDate: "2005-01-12 00:00:00"<br>>LatestCollectingDate: "2005-01-12 23:59:59"
<br>><br>>...requires a bit of interpretation. Maybe the time portion could simply be<br>>omitted; but even still, there is technically *some* interpretation when<br>>converting "January" to "01".
<br>><br>>And the spectrum continues on from there up until, well, stuff that would be<br>>unambiguously flagged as "interpreted".<br>><br>>My point is, there should be some sort of guideline as to when to set
<br>>CollectingDatesInterpreted true; i.e., what threshold of interpretation<br>>triggers that field. If such a guideline already exists, then I apologize<br>>for missing it.<br>><br>>Personally, I don't think CollectingDatesInterpreted is necessary, really,
<br>>because I have always regarded my equivalents of EarliestCollectingDate and<br>>LatestCollectingDate as interpreted.<br>><br>>RE: Lynn's examples below.<br>>I wrestled with these issues (and more) a number of years ago. Other
<br>>examples include "Summer; year unknown" (important for seasonal species),<br>>and multiple (non-contiguous) date ranges: "May or August, 2004" -- among<br>>others.<br>><br>>In addition to the equivalents of VerbatimDateTime, EarliestCollectingDate,
<br>>LatestCollectingDate; I had a controlled-vocabulary field called<br>>"DateRangeQualifier", which had an enumerated list of options tied to<br>>interpretation logic (e.g., "continuous range", "discontinuous range",
<br>>"unknown point", "either/or", etc.; as well as sub-range qualifiers like<br>>"Summer"). I modelled it after an analogous field I use for interpreting<br>>paired or multiple georef coordinates (
e.g., "transect" vs. "bounding box";<br>>"polygon" vs. "linear"). This DateRangeQualifier approach ended up being too<br>>cumbersome to implement -- only because I was too lazy, and the number of
<br>>cases that benefited from it (i.e., allowed computer logic to be applied,<br>>independent of a human reading of the VerbatimDateTime value) was low.<br>><br>>The three fields<br>>VerbatimDateTime/EarliestCollectingDate/LatestCollectingDate will give you
<br>>90% of the value 90% of the time (at least for the specimen/observation data<br>>that I deal with). I wonder if DWC really needs more precision capability<br>>than that....<br>><br>>Rich<br>><br>>Richard L. Pyle, PhD
<br>>Database Coordinator for Natural Sciences<br>>Department of Natural Sciences, Bishop Museum<br>>1525 Bernice St., Honolulu, HI 96817<br>>Ph: (808)848-4115, Fax: (808)847-8252<br>>email: <a href="mailto:deepreef@bishopmuseum.org">
deepreef@bishopmuseum.org</a><br>><a href="http://hbs.bishopmuseum.org/staff/pylerichard.html">http://hbs.bishopmuseum.org/staff/pylerichard.html</a><br>><br>><br>><br>>-----Original Message-----<br>>From: Taxonomic Databases Working Group List
<br>>[mailto:<a href="mailto:TDWG@LISTSERV.NHM.KU.EDU">TDWG@LISTSERV.NHM.KU.EDU</a>]On Behalf Of Lynn Kutner<br>>Sent: Thursday, February 23, 2006 5:26 PM<br>>To: <a href="mailto:TDWG@LISTSERV.NHM.KU.EDU">TDWG@LISTSERV.NHM.KU.EDU
</a><br>>Subject: Re: Standards for date / time values?<br>><br>><br>>Hi Stan and all -<br>><br>>Yes, I am thinking about dates in the context of the observation /<br>>monitoring schema.<br>><br>>Here are some of the types of dates that I've seen in just the data from the
<br>>NatureServe member programs based on either lack of available information or<br>>interesting data collection situations.<br>><br>>1) partial dates (only have the year or year-month) - definitely<br>>accommodated by the ISO 8601 format
<br>><br>>2) vague dates - for these I suppose you'd use ISO 8601 in<br>>EarliestCollectingDate / LatestCollectingDate, VerbatimDateTime, and the<br>>CollectingDatesInterpreted flag ?<br>><br>>PRE-1975<br>
>post-1992<br>>summer 2001<br>>Mid-1990s<br>>late 1950's<br>>Circa 1941<br>>Early 1990s<br>><br>>3) a range of dates indicating that collection occurred on a specific date<br>>sometime between those two limits and you're not sure when (example:
<br>>Observations / collections from pitfall traps may have date ranges<br>>associated with them rather than a single date. For instance, you can have<br>>dates of collection of 19Dec 2004 to 23Jan 2005 and the specimen was from
<br>>some unknown specific date in that rage),<br>><br>>4) continuous data collection over a period of time (some sort of sensor)<br>><br>>5) information collected on one of two possible dates (one or the other is
<br>>correct, it's not a range) (example: aerial surveys flown on either May 27<br>>or June 04, 1999).<br>><br>>It seems that EarliestCollectingDate / LatestCollectingDate could be used<br>>for #3, #4, and #5 - but is there a way to differentiate between these as
<br>>actually being very different types of dates? Would those distinctions just<br>>be communicated using the VerbatimDateTime?<br>><br>>Of course for all of these examples the fallback would be to use the<br>
>VerbatimDateTime, but it would be ideal to have as much as possible of the<br>>date information in field(s) that can be queried and analyzed<br>><br>>Thank you for your thoughts and help.<br>><br>>Lynn<br>
><br>><br>><br>>Lynn Kutner<br>>NatureServe<br>><a href="http://www.natureserve.org">www.natureserve.org</a><br>>(303) 541-0360<br>><a href="mailto:lynn_kutner@natureserve.org">lynn_kutner@natureserve.org
</a><br>><br>><br>><br>>From: Blum, Stan [mailto:<a href="mailto:sblum@calacademy.org">sblum@calacademy.org</a>]<br>>Sent: Thu 2/23/2006 6:41 PM<br>>To: Lynn Kutner; <a href="mailto:TDWG@LISTSERV.NHM.KU.EDU">
TDWG@LISTSERV.NHM.KU.EDU</a><br>>Subject: RE: Standards for date / time values?<br>><br>><br>>Hi Lynn,<br>><br>>Context is everything, so I'm going to assume you are talking about<br>>date/time representations in the observation and monitoring schema(s) that
<br>>you are developing. The thinking in the collections community has gone<br>>something along the lines of this:<br>><br>>Concept: the date-time of a collecting event [= recording-event,<br>>gathering-event] --
i.e., when one or more organisms were collected or<br>>observed -- expressed in the common Gregorian calendar, in local time.<br>><br>>Requirements:<br>><br>>1 - express the data/time exactly as it was recorded
<br>>2 - retreive records by date/time ranges (date-time greater than X and/or<br>>less than Y)<br>>3 - accommodate date-times of varying precision, including explicit<br>>date-time ranges (specifying a duration)
<br>>4 - support seasonal (time of year) queries<br>><br>>These requirements can be met by the following fields:<br>><br>>VerbatimDateTime<br>>EarliestDateCollected<br>>LatestDateCollected<br>>CollectingDatesInterpreted
<br>>DayOfYear<br>><br>>As John Wieczorek noted, the ISO 8601 format accommodates varying degrees of<br>>precision. Using a "verbatim date-time" [text string] is as good as you can<br>>do to satisfy the first requirement, short of scanning field notes or voice
<br>>recordings. The earliest and latest dates support the recording of explicit<br>>ranges as well as interpreted ranges, which could be used to make "Summer of<br>>1952" retrievable. The CollectingDatesInterpreted field would be a boolean
<br>>field, set as true when the earliest and latest dates represent<br>>interpretations rather than an explicit range. The "DayOfYear" field is a<br>>compromise that we've offered as a simple way to support queries involving
<br>>seasonal (annual) cycles; e.g., collected in the northern summer, regardless<br>>of year. But it can be argued that day of year is derivable from the other<br>>fields (unless year is unknown), and that it doesn't accommodate explicit
<br>>ranges.<br>><br>>A bit more documentation is needed to address the odd cases (What do I do<br>>when ...?), but these five fields will support a lot of the data exchange<br>>needed for this concept. These fields are not intended to handle the dating
<br>>of localities in paleontology, nor are they intended to handle named periods<br>>that are used in cultural collections (e.g., Iron Age, Victorian).<br>><br>>ABCD uses a few more fields to handle the concept,
<br>><a href="http://ww3.bgbm.org/abcddocs/AbcdConcepts">http://ww3.bgbm.org/abcddocs/AbcdConcepts</a> but some of these (date, time,<br>>and time zone) are handled by the ISO format, except when the larger units<br>
>are unkown; .e.g., the year is unknown, but the day is [ June 16 ]; or the<br>>date is unknown, but the time is [ 14:00-15:30 ].<br>><br>>AbcdConcept0860 /DataSets/DataSet/Units/Unit/Gathering/DateTime<br>>AbcdConcept0861 /DataSets/DataSet/Units/Unit/Gathering/DateTime/DateText
<br>>AbcdConcept0862 /DataSets/DataSet/Units/Unit/Gathering/DateTime/TimeZone<br>>AbcdConcept0863<br>>/DataSets/DataSet/Units/Unit/Gathering/DateTime/ISODateTimeBegin<br>>AbcdConcept0864<br>>/DataSets/DataSet/Units/Unit/Gathering/DateTime/DayNumberBegin
<br>>AbcdConcept0865<br>>/DataSets/DataSet/Units/Unit/Gathering/DateTime/TimeOfDayBegin<br>>AbcdConcept0866<br>>/DataSets/DataSet/Units/Unit/Gathering/DateTime/ISODateTimeEnd<br>>AbcdConcept0867<br>>/DataSets/DataSet/Units/Unit/Gathering/DateTime/DayNumberEnd
<br>>AbcdConcept0868<br>>/DataSets/DataSet/Units/Unit/Gathering/DateTime/TimeOfDayEnd<br>>AbcdConcept0869<br>>/DataSets/DataSet/Units/Unit/Gathering/DateTime/PeriodExplicit<br>>The ABCD fields pretty much cover the entire concept space. One could argue
<br>>whether time-zone is relevant to the description of biological phenomena,<br>>but we do know that ship trawls do cross time-zones (including the<br>>date-line), and that daylight savings time could stretch or compress some
<br>>nocturnal collecting events if their durations were calculated too simply.<br>><br>>To some extent these arguments are still going on, so analyze your<br>>requirements and your data, then state your position. ;-)
<br>><br>>Cheers,<br>><br>>-Stan<br>>Stanley D. Blum, Ph.D.<br>>Research Information Manager<br>>California Academy of Sciences<br>>875 Howard St.<br>>San Francisco, CA<br>>+1 (415) 321-8183
<br>><br>><br>>-----Original Message-----<br>>From: Taxonomic Databases Working Group List<br>>[mailto:<a href="mailto:TDWG@LISTSERV.NHM.KU.EDU">TDWG@LISTSERV.NHM.KU.EDU</a>] On Behalf Of Lynn Kutner<br>>Sent: Thursday, February 23, 2006 9:12 AM
<br>>To: <a href="mailto:TDWG@LISTSERV.NHM.KU.EDU">TDWG@LISTSERV.NHM.KU.EDU</a><br>>Subject: Standards for date / time values?<br>><br>><br>>Hi -<br>>I'm working with a suite of date attributes that can include a combination
<br>>of precise dates, imprecise dates, and ranges of dates (and the same types<br>>of time values). We'd like to follow existing standards. If this sort of<br>>date / time standard exists, I'd appreciate leads to the appropriate
<br>>resources.<br>>Thank you for your help -<br>>Lynn<br>><br>><br>>Lynn Kutner<br>>Data Management Coordinator<br>>NatureServe<br>>Email: <a href="mailto:lynn_kutner@natureserve.org">lynn_kutner@natureserve.org
</a><br>>Phone: (303) 541-0360<br>><a href="http://www.natureserve.org">www.natureserve.org</a><br><br>Dra. Patricia Koleff<br>Directora de An�lisis y Prioridades<br>CONABIO<br>Comisi�n Nacional para el Conocimiento y Uso de la Biodiversidad
<br>Av. Liga Periferico - Insurgentes Sur 4903<br>Col. Parques del Pedregal<br>Delegacion Tlalpan<br>14010 Mexico, D.F.<br>MEXICO<br>Tel. +52 (55) 5528 9105<br>Fax +52 (55) 5528 9194<br><a href="http://www.conabio.gob.mx">
www.conabio.gob.mx</a><br>e-mail: <a href="mailto:pkoleff@xolo.conabio.gob.mx">pkoleff@xolo.conabio.gob.mx</a><br></blockquote></div><br>