I am currently working on the occurrence database (arthropod, mainly for bees) in DwC format publishing in GBIF and have encountered some problems. The question is how to properly handle the dating of records collected from the traps, i.e., Malaise trap, Pan trap, and Blue vane trap?
Asides from typical “time-point event” such as using a sweep net or hand collecting, the occurrence from these traps typically have “set up date” and “collected date”, for an example, set the trap on 29 Dec 2020, waiting for a week, and collect it on 4 Jan 2021, so the arthropods can be fell for the trap whenever in this “time-range”.
So, how can I give them the time which sampling event occurs in specific Darwin Core terms? I currently use 4 of these without any problem as most of the records is the time-point event
1: verbatimeEventDate — no problem for this, just fill out all the information in range here
Next, these three fields might be trickier, I wonder what should I do?
2: day — filling the first or last date? yes I can just fill out in range as 13/20 (13 to 20), but what should I do if the time is across the month or year as in an example?
3: month — practically no problem except the case above
4: year — practically no problem except the case above
Or should I just give more DwC terms like
5: startDayOfYear
6: endDayOfYear
This must resolve the time-range occurrence problem that occurs for (2) to (4), but what is the most proper way to handle those? Just leave them blank? Also what to do in the case of time-point capture like sweep net? Just give this two fields the same date?
I’m interested to see how GBIF data people answer your question.
Darwin Core eventDate allows interval dates, like 2020-12-29/2021-01-04, which would solve your problem, but GBIF processing says interval dates in eventDate are invalid, and strips away one of the dates. This was noted by GBIF as something to be worked on, at least as far back as 2018.
startDayOfYear and endDayOfYear can be used in place of an interval date, but they’re a nuisance because for further processing you need to convert from ordinal day to date, and this is year-dependent, so sDOY and eDOY can’t be used without a “year” entry. But which year in your 2020>2021 case?
The general problem has bothered collection databasers for years. For a collecting interval in a database which only allows one date, do you enter the start date, the end date or the a date in the middle? I’ve seen all three “solutions” in museum databases. A widespread solution is to have a start-date field and an end-date field in the database. Darwin Core doesn’t have this option.
As a workaround, I suggest putting the end date of an interval in eventDate, and the full interval date in eventRemarks. I recommend the end date because that’s the date on which the specimens were actually retrieved.
Please also note that Darwin Core allows for ISO 8601 date-time in eventDate, so you could have several-hour intervals as an eventDate, but I don’t think GBIF can process those.
Good question. Speaking strictly from the Darwin Core perspective, you should fill in everything you are able to fill in unambiguously while following the recommendations given by the standard. Specifically, using your numbered items:
yes, no problem, and this will back up the rest of what you do in case anyone has a question
this field is ordinal, do not fill it if the event includes more than one day
this field is ordinal, do not fill it if the event includes more than one month
this field is ordinal, do not fill it if the event includes more than one year
5, 6) you can use these, but they will be ambiguous without providing the year for both the start and end dayOfYear
The standard specifically recommends ISO 8601-1:2019 and gives examples that cover your case, such as 2007-03-01T13:00:00Z/2008-05-11T15:30:00Z, or more simply, such as 2007-03-01/2007-03-08 to just include the days if that is all you have.
You should not be swayed into providing less meaningful data by GBIFs current capacity to interpret it correctly.
Cheers,
John Wieczorek
Convener, Darwin Core Maintenance Group