eventDate vs verbatimEventDate : How to record the collection date?

[GoogleCodeExporter]

We need to decide on the best practices for sharing a collection date in Apple 
Core:
http://rs.tdwg.org/dwc/terms/eventDate
http://rs.tdwg.org/dwc/terms/verbatimEventDate

There are 3 approaches:

== Approach 1 ==

verbatimEventDate = the date as close to the original as possible. This means 
that if no verbatim date is recorded in the database, an altered/structured 
date might be provided in this term.
eventDate = the date formatted according to ISO 8601:2004(E). No other date 
formats are accepted.

Advantage: The collection can always provide a date (in verbatimEventDate).
Disadvantage: The data user has no guarantee the date in verbatimEventDate has 
not been altered/structured (if there is a image of the label available, he 
has).

== Approach 2 ==
verbatimEventDate = the original date as on the label. This means that if no 
verbatim date is recorded in the database, an altered/structured date can NOT 
be provided.
eventDate = the date formatted according to ISO 8601:2004(E). No other date 
formats are accepted.

Advantage: The data user has the guarantee that the date in verbatimEventDate 
has not been altered/structured. It depends of course how you interpret 
altered: is something like "Sum... 199. [illisible]" accepted (which is 
something you might find in a verbatim date field in a collection database)?
Disadvantage: The collection might not be able to provide any date at all: when 
they do not record the verbatim date and are not able to transform the date 
they have to ISO.

== Approach 3 ==
verbatimEventDate = the original date as on the label. This means that if no 
verbatim date is recorded in the database, an altered/structured date can NOT 
be provided.
eventDate = the altered/structured date. Preferably in ISO 8601:2004(E), but 
not mandatory.

Advantage: The collection can always provide a date (in eventDate). The data 
user has the guarantee that the date in verbatimEventDate has not been 
altered/structured (but see remark above).
Disadvantage: the eventDate cannot be readily consumed by aggregators.

Original issue reported on code.google.com by peter.de...@gmail.com on 9 Jun 2011 at 8:34

• Blocked on: Idea: Apple Core Gold standard of excellence #30

[GoogleCodeExporter]

I can see the benefits in approach 1 and 3.

I don't like approach 2 because it limits the collections in providing data.

Original comment by peter.de...@gmail.com on 9 Jun 2011 at 8:37

[GoogleCodeExporter]

I will comment from a user's perspective (and I may still be dead wrong a that).

Users will expect an exact verbatim in a verbatimEventDate field. If that is 
not always the case (as in Approach 1), confusion may arise as to the meaning 
of verbatim.

I am uncertain of the importance of the disadvantage you mention in Approach 3, 
however, and it may be major.
Sorry for the rather naive intervention.

Luc

Original comment by luc.brou...@umontreal.ca on 9 Jun 2011 at 9:17

[GoogleCodeExporter]

I'd lean towards approach 3.  

I concur with Luc that a very large portion of the user community will expect 
verbatim to mean verbatim with no added interpretation.   I also concur with 
Peter that approach 2 limits data provider's ability to provide what data they 
do have.  

Software can look at text which might be an ISO 8601 date and decide if it such 
or not.  Aggregators are thus able to consume eventDate with non ISO 8601 
dates, determine that this is the case, and act accordingly.  Making figuring 
out if an eventDate is formatted as expected a concern of the aggregators/data 
consumers seems reasonable to me.  

Original comment by mole@morris.net on 9 Jun 2011 at 9:25

[GoogleCodeExporter]

I also concur with Paul and Luc that verbatim should be just that otherwise it 
leads to confusion. Thus, approach 3 is really the best we can do and I agree 
with Paul that the aggregators should be able to deal with this.

James

Original comment by James.Ma...@gmail.com on 10 Jun 2011 at 3:28

[GoogleCodeExporter]

This discussion gave me an idea, see issue 30. If you agree, we can solve this 
one.

Original comment by peter.de...@gmail.com on 10 Jun 2011 at 4:33

[GoogleCodeExporter]

The guidelines now recommend approach 3, but ISO 8601 is strongly recommended 
for eventDate: 
http://code.google.com/p/applecore/wiki/CollectionDate#Formatted_date

This issue is considered closed, leave a comment if you want to reopen it.

Original comment by peter.de...@gmail.com on 13 Jun 2011 at 8:08

• Changed state: Done