[Esip-documentation] ACDD 1.3 issue: date & time stamps /Bob proposes...

Sat Oct 4 11:24:54 EDT 2014

Keeping in mind the need to deal with individual files (granules) and 
larger aggregations (virtual datasets in THREDDS or ERDDAP, created from 
many files, to which data may be periodically added)...  How about:

Keep these attributes with their current definitions (in black) plus 
additions (in green) that are just intended to be clarifications:
* date_created - The date on which the data was originally created. Note 
that this applies just to the data, not the metadata. The ISO 8601:2004 
extended date format is recommended (see above).
* date_modified - The date on which the data was last modified. Note 
that this applies just to the data, not the metadata. The ISO 8601:2004 
extended date format is recommended (see above).
* date_issued - The date on which this data (including all 
modifications) was formally issued (i.e., made available to a wider 
audience). Note that these apply just to the data, not the metadata. The 
ISO 8601:2004 extended date format is recommended (see above).

Add this attribute:
* date_metadata_modified - The date on which the metadata was last 
modified. The ISO 8601:2004 extended date format is recommended (see above).

-----
My reasoning:

* We must keep the original attribute names and definitions as much as 
possible.

* The original attributes specifically refer to data, not metadata. From 
a programming and structure standpoint, in NetCDF files and OPeNDAP 
datasets, it is clear:
   * Data is the data which in is the primary data structure of the 
variables.
   * Metadata is the collection of global attribute names and values, 
and the data variables' attribute names and values.
I understand that the issue blurs when you realize that a given piece of 
information can be stored in the file (or dataset) as metadata or as 
data. But when someone made that decision, that piece of information 
became either metadata or data. So let's stick to the very clean 
definition that comes from the structure of the files (and datasets).
I know some people like other terms which mean something specific to 
them (e.g., product), but perhaps not others. Let's stick to data and 
metadata because they have specific clear meanings.

* Attributes which deal with data plus metadata are very useful/handy, 
but some people still need the specific information about when the data 
was last modified, or when the metadata was last modified. So we still 
need the separate attributes for data and for metadata. If you need to 
know when either the data or the metadata was last modified, use the 
later of date_modified and date_metadata_modified.

* Like a file in Linux, Mac OS X, and Windows, initially date_created 
and date_modified are equal. But if the data is changed in any way 
(e.g., a value is changed, or when data for additional time points is 
added), date_modified is changed.

* If there is a real need (not just for a sense of symmetry), we can add 
another attribute:
   * date_metadata_created - The date on which the metadata was 
originally created. The ISO 8601:2004 extended date format is 
recommended (see above).

On 2014-10-03 12:54 PM, John Graybeal via Esip-documentation 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

-- 
Sincerely,

Bob Simons
IT Specialist
Environmental Research Division
NOAA Southwest Fisheries Science Center
99 Pacific St, Suite 255A
Monterey, CA 93940
Phone: (831)333-9878 (Changed 2014-08-20)
Fax: (831)648-8440
Email: bob.simons at noaa.gov

The contents of this message are mine personally and
do not necessarily reflect any position of the
Government or the National Oceanic and Atmospheric
Administration.
<>< <>< <>< <>< <>< <>< <>< <>< <>< <><

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-documentation/attachments/20141004/1bcf68cd/attachment.html>