[eml-dev] [Bug 1794] - modify temporalCoverage to support ongoing data sources

[bugzilla-daemon at ecoinformatics.org]

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=1794





------- Comment #3 from jones at nceas.ucsb.edu  2008-09-25 14:43 -------
Looks like the links to previous EML-dev discussion threads were wrong in
Comment #1.  The actual discussion occurred here:

http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/2004-October/001030.html
http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/2004-October/001031.html
http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/2004-October/001032.html

The synopsis of the discussion is this: I maintain that temporal coverage
should refer to what data now exist (even in a dynamic database) and can be
retrieved at the time the metadata are queried, not what the sampling protocol
is. This allows queries to use the coverage information to accurately retrieve
relevant data.  Information about future intended sampling that has not yet
occurred should go in sampling design descriptions, which will tell people what
is intended but not make coverage inaccurate if plans change.  In contrast,
others feel that it is ok to have a 'null' field or to hack the field type and
put in 'ongoing' or the like.  My feeling is that doing this makes it
indeterminate as to whether a search engine should return a data set for any
given temporal search, and therefore reduces the search effectiveness of the
metadata.  For example, if someone has a so-called 'dynamic' database and
enters a metadata record in 2002 saying that data span "2000- ", should a
search engine return a 'hit' for a search for data in the range of 2008?  What
if the research project ended and those data weren't collected after 2004? 
Would we forever be obliged to return that data set as a hit, even for a search
for data in 2020?  To me this is an issue more about metadata accuracy and
update frequency than anything else.