432 lines
17 KiB
Plaintext
432 lines
17 KiB
Plaintext
head 1.10;
|
||
access;
|
||
symbols;
|
||
locks; strict;
|
||
comment @# @;
|
||
|
||
|
||
1.10
|
||
date 2008.03.16.14.49.29; author JohnWieczorek; state Exp;
|
||
branches;
|
||
next 1.9;
|
||
|
||
1.9
|
||
date 2007.02.14.13.55.05; author JohnWieczorek; state Exp;
|
||
branches;
|
||
next 1.8;
|
||
|
||
1.8
|
||
date 2007.01.10.21.21.57; author JohnWieczorek; state Exp;
|
||
branches;
|
||
next 1.7;
|
||
|
||
1.7
|
||
date 2006.10.10.21.05.25; author StephenLong; state Exp;
|
||
branches;
|
||
next 1.6;
|
||
|
||
1.6
|
||
date 2006.10.10.18.54.32; author StephenLong; state Exp;
|
||
branches;
|
||
next 1.5;
|
||
|
||
1.5
|
||
date 2006.10.06.20.33.04; author StephenLong; state Exp;
|
||
branches;
|
||
next 1.4;
|
||
|
||
1.4
|
||
date 2006.10.06.18.44.19; author StephenLong; state Exp;
|
||
branches;
|
||
next 1.3;
|
||
|
||
1.3
|
||
date 2006.09.19.23.30.41; author StephenLong; state Exp;
|
||
branches;
|
||
next 1.2;
|
||
|
||
1.2
|
||
date 2006.09.19.18.13.29; author StephenLong; state Exp;
|
||
branches;
|
||
next 1.1;
|
||
|
||
1.1
|
||
date 2006.09.14.19.38.09; author StephenLong; state Exp;
|
||
branches;
|
||
next ;
|
||
|
||
|
||
desc
|
||
@none
|
||
@
|
||
|
||
|
||
1.10
|
||
log
|
||
@none
|
||
@
|
||
text
|
||
@%META:TOPICINFO{author="JohnWieczorek" date="1205678969" format="1.1" version="1.10"}%
|
||
%META:TOPICPARENT{name="DarwinCoreDraftStandard"}%
|
||
---++Element Description: Earliest Date Collected
|
||
The earliest date-time (Common Era calendar) in a date-time period during which an organism or group of organisms was collected or observed. If the event is recorded as occurring at a single date-time, populate both !EarliestDateCollected and LatestDateCollected with the same value.
|
||
|
||
---++++ Open Questions:
|
||
|
||
• 3 Oct 2004, 15 Jun 2005 - Elements requested for Date Range expression. (Blum, Giovanni, GBIF Circa; Date-Time Elements).
|
||
|
||
• 3 Sep 2005 - Recommendation that Month, Day, Year, and Time concept combinations be collapsed into single ISO 8601 date and time concepts. !YearCollected, !MonthCollected, !DayCollected, !TimeCollected would become !DateCollected, while !YearIdentified, !MonthIdentified, !DayIdentified would become !DateIdentified. This change would simplify representation of date ranges on events (_e.g._, !BeginDateCollected, !EndDateCollected. ( -- Main.JohnWieczorek).
|
||
|
||
---++++ Change Log:
|
||
|
||
• 04 Aug 2005 - changed data type from nonNegativeInteger to positiveInteger for !MonthCollected and !DayCollected. Changed wording in the descriptions of !MonthCollected and !DayCollected to avoid the conception that two digits are required. (Wieczorek, per Ginzbarg).
|
||
|
||
• 11 Sep 2005 - replaced !YearCollected, !MonthCollected, !DayCollected, and !TimeCollected with !EarliestDateCollected and !LatestDateCollected (Wieczorek & Blum).
|
||
|
||
• 18 May 2006 - modified description of !EarliestDateCollected and !LatestDateCollected to express suggested best practices. (De Giovanni, Blum, & Wieczorek).
|
||
|
||
• 10 Jan 2007 - change data type from xsd:dateTime to simpleType DateTimeISO developed for ABCD. This new data type allows greater flwxibility in the use of the ISO 8601 standard than the xsd:dateTime does. xsd::dateTime requires a fully specified date and time, which is too restrictive for use as a Collecting Event Date element ( -- Main.JohnWieczorek).
|
||
|
||
---+++ Comments
|
||
Use the space below to make comments about this page. -- Main.StephenLong - 24 Aug 2006
|
||
|
||
------
|
||
|
||
%ICON{bubble}% *Multiple collecting dates*
|
||
Posted by: Micka<6B>l Graf [mailto:mickael.graf@@nrm.se] Date: Fri, 12 Dec 2003, 14:03:34
|
||
|
||
Dear all (Stan alone?)
|
||
|
||
I am currently working to fit databases with !DarwinCore, as currently used by GBIF, and I am often confronted to a problem where two dates (in various formats) are registered for the same record, in the same "date" field. So far, this is only in botany I saw that, where scientists are collecting specimens in different times of the year (spring, summer etc.).
|
||
|
||
There is currently no way to express that in !DarwinCore 2. Could it be possible to implement it in !DwC ?
|
||
|
||
Regards
|
||
Micka<EFBFBD>l Graf
|
||
------
|
||
|
||
%ICON{bubble}%The primary representation of "CollectingDate" now in the Darwin Core consists of !YearCollected, !MonthCollected, and !DayCollected expressed as integers, and !TimeCollected expressed in decimal hours. A secondary representation, !JulianDay (= day of year, expressed as an integer), supports queries on season regardless of year.
|
||
These elements represent just one of several possible compromises among competing criteria, such as fidelity to the data as they are given, simplicity of representation, ease of query formulation, and precision of query expression.
|
||
The requirements or goals for our representations should be:
|
||
|
||
* to accommodate a wide variety of vague date expressions that exist in our data;
|
||
|
||
* to enable record retrieval by simple queries against the time-line; simple queries are typically expressed as:
|
||
|
||
* after T1,
|
||
|
||
* before T2,
|
||
|
||
* or both after T1 and before T2.
|
||
|
||
Such simple queries are commonly understood to be operate against records where date-time is represented as a "point" rather than an interval, with distinct begin and end points.
|
||
Representatives from several disciplines have asked for separate begin and end points (date-time elements). Begin and end points are commonly recorded in disciplines where mechanical devices are used to collect over some duration.
|
||
|
||
[To be continued...]
|
||
Created by sblum
|
||
Last modified 2004-08-26 08:08 PM
|
||
------
|
||
%ICON{bubble}% *CollectionNumber and Date Ranges*
|
||
Posted by: Stan Blum [mailto:sblum@@calacademy.org] Date: Sun, 03 Oct 2004, 21:48:48
|
||
|
||
The contents of the earlier garbled (encoded) message are re-sent below.
|
||
|
||
Dear Rich,
|
||
|
||
Thanks for your comments.
|
||
|
||
<verbatim><snip></verbatim>
|
||
|
||
The suite of elements used for dates is a pretty hot topic. I gather from your comments that you would like to see a suite of elements, either in the core or in the curatorial extension, that accommodates date ranges for a specimen record. Can you tell me (us) more specifically what functions you want to support with these more complex date fields? Do you want to query against data ranges? (Note that a single data field is already typically queried using a range -- _e.g._, !CollectionDate is greater-than X and/or less-than Y-- so querying a date range becomes
|
||
significantly more complicated. It adds the notion of my query range either overlapping or completely containing the collecting range of the specimen. Even if you want all specimens collected after 1979, you would need to specify the equivalent of "might have been collected after
|
||
1979" (!EndDate >= Jan 1, 1980), or definitely collected after 1979 (!BeginDate >= Jan 1, 1980). Do you want users to be confronted with that degree of complexity? I can also understand that you might want to use !DarwinCore (and appropriate extensions) as a structure for exchanging records between databases (not just for creating data sets to analyze) and you feel it's important not to lose these details. Is that the kind of usage you were thinking about? We're interested in what's motivating people to ask for particular additions; more than just "our records have these fields".
|
||
|
||
Looking forward to your response. Cheers, -Stan
|
||
------
|
||
%ICON{bubble}% *Date range*
|
||
Posted by Korbinus at 2004-10-11 03:38 PM
|
||
|
||
I think it would be good to have the possiblity to enter an interval of dates, since it is very common to find records with date information such as "March 1978 - June 1978".
|
||
|
||
Data providers need today to pick up one date out of the range (or calculate an average date) and present it in !YearCollected & _al_. By doing so, we are losing here some critical information.
|
||
|
||
It would be very helpful to integrate this concept in the coming version of !DwC.
|
||
|
||
------
|
||
<DL>
|
||
<DD>%ICON{bubble}% *Replies to this comment*
|
||
Posted by regiov at 2005-06-15 09:24 AM
|
||
|
||
I also agree that !DarwinCore should support date ranges. If it happens, people would still be able to use simple queries based on either the initial or end point of the collecting event. By using date ranges:
|
||
|
||
1) Providers that store information in that way would not lose information when exposing their data (as mentioned in the previous comment);
|
||
|
||
2) Complex queries considering the range would be possible, even if not frequently used;
|
||
|
||
3) !DarwinCore would better serve as a basis for further extensions. Some of the existing extensions, like the one used by OBIS (http://iobis.org/obis/obis.xsd) decided to include the date range, which makes the composition !DarwinCore + Extension require three date mappings related to the collecting event.
|
||
</DL>
|
||
------
|
||
|
||
%ICON{bubble}% *Date Recommendation*
|
||
Posted by gkamp at 2005-09-28 08:44 PM
|
||
|
||
"3 Sep 2005 - Recommendation that Month, Day, Year, and Time concept combinations be collapsed into single ISO 8601 date and time concepts. !YearCollected, !MonthCollected, !DayCollected, !TimeCollected would become !DateCollected, while !YearIdentified, !MonthIdentified, !DayIdentified would become !DateIdentified. This change would simplify representation of date ranges on events (_e.g._, !BeginDateCollected, !EndDateCollected.)"
|
||
|
||
This is problematic when there is missing information for historical records. We have insect labels with only pieces of this information (only a day and month; only a month and year; only a year) that never successfully fit into a true "date" as defined above. This is true not only for collecting dates but even more so for identification (determination) dates, which for insects anyway, are generally only a year. I submit that it is important to keep these fields separated for data entry, but to allow the calculation of a date when all fields are represented.
|
||
|
||
Gail Kampmeier
|
||
------
|
||
<DL>
|
||
<DD>%ICON{bubble}% *Agree*
|
||
Posted by ChuckMiller at 2005-09-29 07:57 AM
|
||
|
||
I agree with Gail. If Darwin Core is to enable the exchange of basic specimen data, one of the most basic elements of that data is the collection date. Collectors of the past were notoriously bad about taking shortcuts in their field notes and their labels. Specific dates are often missing. Sometimes even months are missing. To my mind, collapsing date components into a single date representation is a computer-world notion. It seems efficient, but it can result in loss of validly useful information - that some detail is missing. Forcing a label annotation like January 1801 to be arbitrarily changed to January 1, January 15, or January 31 seems unnecessarily problematic to me. Certainly the computers have no problem with the date element separations. They can easily either map the values from database date format to Month, Day, Year or map from Month, Day, Year fields if they exist. So, why consolidate during data exchange? I think if any change in this date area were needed, it would the addition of three more elements, for Ending Date, Month and Year, and thus enabling a date range, say from January 1801 to March 1801. But, not to an artificially constructed date value.
|
||
|
||
Chuck Miller, Missouri Botanical Garden
|
||
</DL>
|
||
------
|
||
<DL>
|
||
<DD>%ICON{bubble}% *Re: date recommendation*
|
||
Posted by lapham at 2005-10-01 07:01 AM
|
||
|
||
Accees, at least, will accepet dates without the day in a DateTime field, if the data is so fragmenteded it only has a year portion it won't go into a DateTime field and a verbatrim date field woud be requied for that. It takes a whole lot less code to extract a range for DateTime field that it does for the atomized fields and fragmented dates are relatively rare.
|
||
|
||
Charlie Lapham
|
||
------
|
||
<DL>
|
||
<DD>%ICON{bubble}% *Re: Agree*
|
||
Posted by fini at 2005-12-19 02:38 AM
|
||
|
||
"They can easily either map the values from database date format to Month, Day, Year or map from Month, Day, Year fields if they exist."
|
||
|
||
Even this should be done with great caution (especially if the data was ever to be exported from the db), since using database date fields will also tend to disallow incomplete dates, this could unintentionally result in converting dates like 00-12-2005 into 01-12-2005 or simply result in a database error, blank dates etc.
|
||
</DL>
|
||
</DL>
|
||
------
|
||
|
||
%ICON{bubble}% *Earliest and !LatestCollectionDate*
|
||
Posted by lapham at 2005-09-30 03:07 PM
|
||
|
||
Legacy data in herbaria typically contains one collection date. Should it be used to populate one or both these elements? If one, which one?
|
||
------
|
||
<DL>
|
||
<DD>%ICON{bubble}% *Re: Agree*
|
||
Posted by lapham at 2005-10-01 07:33 AM
|
||
|
||
The problem with this pair of elements may be similar to our earlier bounding box problem. These two elements are charactersisitcs of a group of collecting/observation events and are inappropriate for single collecting/observation event records. We need to revert back to a single CollectionDate DateTime element with a verbatim field for fragmentary dates.
|
||
|
||
Charlie Lapham
|
||
|
||
------
|
||
<DL>
|
||
<DD>%ICON{bubble}% *Re: Agree*
|
||
Posted by fini at 2005-12-19 02:53 AM
|
||
|
||
"We need to revert back to a single !CollectionDate DateTime element with a verbatim field for fragmentary dates. "
|
||
|
||
I agree with Charlie Lapham, it is basically impossible to decide dates to fill out if there is only one, this would lead to people filling both fields with the same values, or even worse people would just fill out one of them, but not always the same.
|
||
|
||
My suggestion along Charlie's idea is to have fields similar to these:
|
||
|
||
!YearCollected, !YearCollectedRangeEnd.
|
||
!MonthCollected, !MonthCollectedRangeEnd.
|
||
!DayCollected, !DayCollectedRangeEnd.
|
||
!TimeCollected, !TimeCollectedRangeEnd.
|
||
</DL>
|
||
------
|
||
<DL>
|
||
<DD>%ICON{bubble}% *Re: Agree*
|
||
Posted by lapham at 2006-01-15 07:59 PM
|
||
|
||
if we susstitute !DateCollected-date/time data type and Additional !dateCollected- date/time data type, the second field can be used to establish a range,if needed. The addtional fild should not be comfused with with the primary date field. Both of them at date/time data types so one can use greater than, or less than criteria and sort them easily. Having a clear primary field is also essetial for setting the !DayOfYear Julian date field unambiguously.
|
||
</DL>
|
||
</DL>
|
||
------
|
||
|
||
%ICON{bubble}% *Suggestion*
|
||
Posted by fini at 2005-12-19 03:32 AM
|
||
|
||
Earlier today I posted a possible solution at this location:
|
||
http://darwincore.calacademy.org/Documentation/DarwinCore2Draft_v1-4_HTML/talkback/1134989637/discussionitem_view
|
||
|
||
I will post it here since it seems to fit better in this location.
|
||
|
||
Charlie Lapham: "We need to revert back to a single !CollectionDate !DateTime element with a verbatim field for fragmentary dates."
|
||
|
||
I agree with Charlie Lapham, it is basically impossible to decide dates to fill out if there is only one, this would lead to people filling both fields with the same values, or even worse people would just fill out one of them, but not always the same.
|
||
|
||
My suggestion along Charlie's idea is to have fields similar to these:
|
||
|
||
<noautolink>YearCollected, YearCollectedRangeEnd.
|
||
MonthCollected, MonthCollectedRangeEnd.
|
||
DayCollected, DayCollectedRangeEnd.
|
||
TimeCollected, TimeCollectedRangeEnd.</noautolink>
|
||
|
||
All the *RangeEnd* fields are optional.
|
||
|
||
Issues: This might not be perfect for situations where you know *only* the end of a range, but in the case of ever getting start and end date, the complete date range could fairly easy be modified on the record by copying !MonthCollected to !MonthCollectedRangeEnd, and updating the !MonthCollected with the start month.
|
||
|
||
%ICON{bubble}%
|
||
|
||
------@
|
||
|
||
|
||
1.9
|
||
log
|
||
@none
|
||
@
|
||
text
|
||
@d1 1
|
||
a1 1
|
||
%META:TOPICINFO{author="JohnWieczorek" date="1171461305" format="1.1" reprev="1.9" version="1.9"}%
|
||
d4 1
|
||
a4 1
|
||
The earliest date-time (Common Era calendar) in a date-time period during which an organism or group of organisms was collected or observed. If the event is recorded as occurring at a single date-time, populate both !EarliestDateCollected and !LatestDateCollected with the same value.
|
||
d203 1
|
||
a203 1
|
||
------
|
||
@
|
||
|
||
|
||
1.8
|
||
log
|
||
@none
|
||
@
|
||
text
|
||
@d1 1
|
||
a1 1
|
||
%META:TOPICINFO{author="JohnWieczorek" date="1168464117" format="1.1" version="1.8"}%
|
||
d3 1
|
||
a3 7
|
||
This is a test documentation page for an <noautolink> *EarliestDateCollected* </noautolink> concept.
|
||
|
||
|
||
|
||
-- Main.StephenLong - 14 Sep 2006
|
||
|
||
---++Element Description
|
||
@
|
||
|
||
|
||
1.7
|
||
log
|
||
@none
|
||
@
|
||
text
|
||
@d1 1
|
||
a1 1
|
||
%META:TOPICINFO{author="StephenLong" date="1160514325" format="1.1" version="1.7"}%
|
||
a21 1
|
||
|
||
d24 1
|
||
d26 1
|
||
a26 3
|
||
|
||
|
||
• 18 May 2006 - modified description of !EarliestDateCollected and !LatestDateCollected to express suggested best practices. (De Giovanni, Blum, & Wieczorek).
|
||
d209 1
|
||
a209 1
|
||
------@
|
||
|
||
|
||
1.6
|
||
log
|
||
@none
|
||
@
|
||
text
|
||
@d1 1
|
||
a1 1
|
||
%META:TOPICINFO{author="StephenLong" date="1160506472" format="1.1" version="1.6"}%
|
||
d144 40
|
||
d187 1
|
||
a187 1
|
||
Posted by fini at 2005-12-19 03:32 AM
|
||
d211 1
|
||
a211 1
|
||
------
|
||
@
|
||
|
||
|
||
1.5
|
||
log
|
||
@none
|
||
@
|
||
text
|
||
@d1 1
|
||
a1 1
|
||
%META:TOPICINFO{author="StephenLong" date="1160166784" format="1.1" version="1.5"}%
|
||
d110 36
|
||
d171 1
|
||
a171 1
|
||
------@
|
||
|
||
|
||
1.4
|
||
log
|
||
@none
|
||
@
|
||
text
|
||
@d1 1
|
||
a1 1
|
||
%META:TOPICINFO{author="StephenLong" date="1160160259" format="1.1" version="1.4"}%
|
||
d35 13
|
||
d135 1
|
||
a135 1
|
||
------
|
||
@
|
||
|
||
|
||
1.3
|
||
log
|
||
@none
|
||
@
|
||
text
|
||
@d1 1
|
||
a1 1
|
||
%META:TOPICINFO{author="StephenLong" date="1158708641" format="1.1" version="1.3"}%
|
||
d55 9
|
||
d65 9
|
||
a73 1
|
||
------%ICON{bubble}% *Date range*
|
||
d82 3
|
||
a84 1
|
||
%ICON{bubble}% *Replies to this comment*
|
||
d94 1
|
||
a94 1
|
||
|
||
d120 2
|
||
a122 2
|
||
|
||
%ICON{bubble}%
|
||
@
|
||
|
||
|
||
1.2
|
||
log
|
||
@none
|
||
@
|
||
text
|
||
@d1 1
|
||
a1 1
|
||
%META:TOPICINFO{author="StephenLong" date="1158689609" format="1.1" version="1.2"}%
|
||
d16 1
|
||
a16 1
|
||
• 3 Sep 2005 - Recommendation that Month, Day, Year, and Time concept combinations be collapsed into single ISO 8601 date and time concepts. !YearCollected, !MonthCollected, !DayCollected, !TimeCollected would become !DateCollected, while !YearIdentified, !MonthIdentified, !DayIdentified would become !DateIdentified. This change would simplify representation of date ranges on events (_e.g._, !BeginDateCollected, !EndDateCollected. (Wieczorek).
|
||
a103 1
|
||
|
||
@
|
||
|
||
|
||
1.1
|
||
log
|
||
@none
|
||
@
|
||
text
|
||
@d1 1
|
||
a1 1
|
||
%META:TOPICINFO{author="StephenLong" date="1158262689" format="1.1" version="1.1"}%
|
||
d12 5
|
||
d27 1
|
||
d33 71
|
||
@
|