temporal coverage tags, alternativeTimeScale

[Matt Jones]

Hi Margaret,

AlternativeTimeScale was written (originally by me for the BDP, and 
modified in the EML2 process) to accomodate various stratigraphic and 
geologic time scales.

The documentation stating to put "ongoing" in those fields (or anywhere) 
is a hack, and a bad one at that, that incorrectly uses 
alternativeTimeScale.

The problem is this: a data set that is ongoing isn't really ongoing 
from the data user's perspective, because at any given point in time the 
temporal coverage of the data returned is a fixed interval.  Many data 
managers don't want to deal with the fact that when their data sets 
change the metadata describing those data should also be updated.  One 
way to get around updating is to say that data colleciton is "ongoing", 
but this is meaningless to a search engine.  Let me illustrate with an 
example.

Lets say I collect data in 1985, 86, 87, and 88.  I create a metadata 
document that says my temporal coverage is 1985-1988.  Someone queries 
the metadata to find all data collected in 1988, and my data set is 
returned in the list of matching results.  Perfect. Now, lets say I 
really intend to collect annually, so instead I change my metadata to 
say the temporal coverage is 1985-ongoing.  Someone does a search for 
data in collected in 1988 -- should the metadata search engine return 
the data set as a match?  What if I search for 2004, should it return a 
match even though the only data are actually collected up to 1988?

This comes down to an issue of metadata maintenance.  Putting ongoing 
into any field is a horrible practice because 1) it reduces the 
information about the actual temporal coverage of the data that is 
currently available, and 2) it is highly prone to error because people 
WILL forget to update their metadata record when their data collection 
actually stops.  So from a best practices perspective, its a horrible 
practice in my opinion.  If you want to indicate to someone that you 
intend to collect more data, by all means indicate that in the 
samplingDesign and other methods sections.  But not in temporalCoverage, 
which describes the data you have already collected, not what you plan 
to collect.

We've had this discussion in the EML group before.  I lost this battle 
before, and thus the hack was placed in the EML documentation.  Some 
people probably still support this practice.  I don't.

Hope this has been helpful.
Matt

Margaret O'Brien wrote:
> Hi -
> I'd like someone to clear up some confusion about the temporal coverage 
> module, specifically, the alternativeTimeScale.  This has an inpact on a 
> recommendation which will be made by the lter EML best practices group.
> Since sites conduct time series, many data sets can be considered 
> 'ongoing' ie, their data tables will be appended at some interval - 
> perhaps regularly, but not necessarily.
> 
> In the introduction to the module documentation for eml-coverage, you 
> state:
> " In order to express an "ongoing" time frame, the end date in the range 
> would likely use the alternate time scale fields with a value of 
> "ongoing", whereas the begin date would use the specific calendar date 
> fields. "
> 
> Should we extend this statement to mean that for our time-series 
> datasets, an eml creator can populate the <timeScaleName> tag with a 
> value of "ongoing" and a <timeScaleAgeEstimate> tag with a description 
> of the update frequency for the data?
> 
> When we investigate the element defintions later in the document, it 
> seems that these tags are intended for stratigraphic data and geologic 
> time scales, which makes them inappropriate for an ongoing time series 
> dataset.
> 
> Can you clarify 1) how you intended the alternativeTimeScale tree to be 
> used, and 2) how you recommend we alert a reader that a dataset is a 
> time series and will most definitely be updated.
> Thanks-
> Margaret O'Brien

-- 
-------------------------------------------------------------------
Matt Jones                                     jones at nceas.ucsb.edu
http://www.nceas.ucsb.edu/    Fax: 425-920-2439    Ph: 907-789-0496
National Center for Ecological Analysis and Synthesis (NCEAS)
University of California Santa Barbara
Interested in ecological informatics? http://www.ecoinformatics.org
-------------------------------------------------------------------