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

bugzilla-daemon at ecoinformatics.org bugzilla-daemon at ecoinformatics.org
Wed Oct 1 11:19:56 PDT 2008


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





------- Comment #4 from mob at icess.ucsb.edu  2008-10-01 11:19 -------
Summary of 2008-09-30 discussion (Matt Jones, Margaret O'Brien, James Brunt,
Mark Servilla, Inigo San Gil, Chris Jones, Corinna Gries, Ken Ramsey)

Consensus:
1. a resource-level endDate element with date content is necessary if accurate
searches are to be returned
2. it is important that EML is able to accurately describe datasets in which
values are expected to be added beyond the resource-level endDate (e.g., sensor
data or time series)
3. authors wish to encode this "ongoing" nature in resource-level metadata, not
just at the methods/sampling level

Comments and observations:
1. most sensor metadata will be autogenerated, and so keeping metadata up to
date should not be a hardship.  The frequency of update can be specified in the
optional tag: /eml/dataset/maintenance/maintenanceUpdateFrequency (from
appinfo/description: "Frequency with which changes and additions are made to
the dataset").
2. Generally, it has been expected that searches of EML documents would be for
quality-controlled products rather for unexamined real-time data. The
high-frequency metadata updates that would be required to keep a description of
real-time data accurate may demand a different model for metadata storage
applications (i.e, metacat), since repeated additions of metadata documents may
overburden a system where the entire revised document is stored rather than
just "diffs".

Possible changes to EML:
1. endDate element could have a optional attribute to indicate that data are
expected be updated, e.g., <endDate updateFrequency="daily">
2. an element <metadataCreationDate> could be added. This need is also
highlighted in bug #1991, which outlines other metadata maintenance issues.
3. add a new data type to described sensor data,  e.g., "dataStream", which
would be analogous to dataTable
4. adapt the methods/sampling tree to accommodate an empty (or nillable)
endDate (any changes to methods trees are related to bug #3504)

A subset of eml-dev members will consider these issues: 
Ken Ramsey, Corinna Gries, Chris Jones, Matt Jones


More information about the Eml-dev mailing list