Multiple date ranges in temporalCoverage
If an information holding being described covers 2 or more widely separated time periods, e.g. 1980-1990 and 1995 to present, but is identical in all other respects, there appears to be no way allowed for describing this, without describing this information as two separate information holdings. I had hoped this problem with the FGDC and NBII might be corrected in EML. The related issue in this bug is the issue of indicating that end date is "present", although I see that this is an issue that has been reported in one or more other bug reports.
#1 Updated by Matt Jones over 13 years ago
In EML you can specify multiple, dicontiguous time periods by repeating the coverage element. No need to have two separate holdings for this.
With respect to ongoing data collection, this issue has been raised before. EML documents the data that you already have for the purposes of more accurate search and interpretation. At any given point in time when you distribute a dataset with an EML document, the data will be from a finite temporal coverage, and that is what should be indicated in the documentation. If in the future you incude new records, simply modify the EML to reflect the new coverage at that time.
If you plan on collecting additional data in the future, the best place to indicate this is in your methods and sampling design descriptions. Unfortunately, adding an end date of 'present' doesn't really tell us much from a search or interpretation perspective. For example, if someone says their data covers 1990-present, and the metadata was produced in 2001, should I expect to find data from 2006 in that data set when I search? Should it be returned as a hit in a search for data in 2006? Probably not, as the best laid plans often go awry. The only reliable thing to document over the long term is the data you actually have in hand.
I htink there are no new issues in this bug report, so unless further comments reflect something that should be changed in EML I will close the bug report shortly.