[Esip-documentation] ACDD 1.3 issue: date & time stamps

[Ge Peng - NOAA Affiliate via Esip-documentation]

Trying to look at the date issue from a different perspective:


Static historical datasets and near real-time datasets have different
requirements for creation date. So do that for collection-level metadata
records and file-level metadata attributes. Search and discovery will touch
on both collection- and file-level metadata in some way eventually.


Information about the “original” creation date and modification date can be
useful, especially for data provenance. However, both “original” creation
date and “modification” date imply a need for keeping track of dates.


For the static datasets and collection-level metadata records, decisions to
create and modify them tend to happen less frequently with weak or no
latency requirement and are often occurred subjectively and documented so
they may be more feasible to be implemented. Original creation date may be
relevant and good to have in this case.


On the other hand, for the near real-time datasets that usually have strong
data-latency requirement and file-level metadata such as those global
attributes of a NetCDF file in a near real-time dataset, it may not be
feasible to keep track of original creation date, although a version
number/date could be utilized. The file creation date/time stamp may be
more appropriate in this case.


Following the discussion thread on the date and time stamps and based on my
experience working with both static and near real-time datasets, it has
become apparent to me that having a date type element may offer an option
to allow the flexibility of implementing different types of dates for
different types of data as it may be nearly impossible for us to find an
one-size-fits-all solution.


Coming late to the discussions and not wanting to stir up any additional
discussion, I have withheld my comment until our last meeting when the type
element for creator was suggested. Now with Jim’s suggestion to approach
this issue in a more systematic way, I am putting my suggestion in –
hopefully it will help us to reach a more consistent decision as it will
have long-lasting implication for everyone – providers, stewards,
developers, and users.


Best regards,


--- Peng


P.S: Being thinking about it over the weekend but decided to post my
comment on this morning – maybe overlapping with Ted and John’s comments.

On Fri, Oct 3, 2014 at 3:54 PM, John Graybeal via Esip-documentation <
esip-documentation at lists.esipfed.org> wrote:

> The issue of date/timestamps is by far the most challenging ACDD issue.
>
> A very short version of the very long 1.3 history:
> A) A year-plus ago, several members identified ambiguities in definition,
> understanding, and use of the originals (*date_created*, *date_modified*,
> *date_issued*)
> B) An extensive analysis/discussion took place starting over a year's
> time; the opinion of that group was that new terms should be created in
> place of the old. These terms were *date_content_modified*,
> *date_values_modified*, *date_product_generated*. A fourth was proposed
> but not settled on, a la *date_product_originally_created*. Another
> request relative to this group was for a publication date (which could be
> *date_issued* or something else, depending on definitions.)
> C) The broader group's recent (general) decision was that existing terms
> should be kept, but redefined if necessary.
> D Our 10-minute attempt yesterday helped bring out some of the original
> and ongoing issues.
> E) Jim Biard's email this morning ("ACDD date attributes question) takes a
> back-to-fundamentals approach, laying out some suggested use cases and
> concepts.
>
> For reference (only!), I've provided below definitions of these terms more
> or less as they originated or were improved.
>
> From a process perspective I think we might want to have a separate
> sub-group hash out a recommendation, but I think Jim's idea of gather
> requirements is a necessary first step anyway. So I propose
> (a) you *respond to Jim's email* *with your inputs to his summary*, and
> (b) *reply to this email with any other comments or analysis*, especially
> about process.
>
> I do not have any clever ideas to make this topic more easily resolvable,
> given the constraints in (A) and (C) above. Let's start the discussion and
> see how it goes.
>
> John
>
> ====================
>
> *date_created*
> The date on which the data was created.
> *date_modified*
> The date on which this data was last modified.
> *date_issued*
> The date on which this data was formally issued.
> *date_content_modified*
> The date on which any of the provided content, including data, metadata,
> and presented format, was last changed (including creation)
> *date_values_modified*
> The date on which the provided data values were last changed (including
> creation); excludes metadata and formatting changes
> *date_product_generated*
> The date on which this data file or product was produced/distributed.
> While this date is like a file timestamp, the date_content_modified and
> date_values_modified should be used to assess the age of the contents of
> the file or product.
> *date_product_originally_created*
> The date on which this data file or product first came into existence.
>
> <END>
>
> _______________________________________________
> Esip-documentation mailing list
> Esip-documentation at lists.esipfed.org
> http://www.lists.esipfed.org/mailman/listinfo/esip-documentation
>
>


-- 
*Ge Peng, Ph.D*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA's National Climatic Data Center <http://ncdc.noaa.gov/>
151 Patton Ave, Asheville, NC 28801
ge.peng at noaa.gov
o: +1 828 257 3009
f:  +1 828 257 3002

Following CICS-NC on Facebook <http://www.facebook.com/cicsnc>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-documentation/attachments/20141006/3e11e9d8/attachment-0001.html>