[Esip-documentation] status/open issues for ACDD approval

Thu Aug 21 16:16:38 EDT 2014

Hi Philip, thanks for your input. Here are my thoughts, looking for feedback from you and the list.

> date_product_generated:  Is this attribute intended to hold the initial create date of the file?

No, it was meant to be when it was distributed (the separation you wanted). This corresponds originally to the ISO 19115-2 code /gmd:dateType/gmd:CI_DateTypeCode="publication", which says here "date identifies when the resource was issued". To me this means 'visibly released' to the external users, but some say 'issued' means 'produced' in the system). 

As I understand it, the ACDD attribute targets the use case "if I went to the site on date X, was it there yet?" This being helpful for people or computers who grab information from a site at every so often, to know what they don't have to grab. 

So I agree the word 'generated' is confusing here; I can't find a discussion where it changed from _issued to _generated, but I think it was an attempt to avoid the ambiguity of the ISO term 'issued'. 

Perhaps this is better:

date_product_distributed: The date on which this individual data file or other product was distributed (ISO 8601 format). This may be after the product was created (but not before); therefore the date_content_modified and date_values_modified should be used to assess the age of the content. 

(I wanted to add "If the identical data file or product is distributed multiple times, this should be the first date of distribution." But it is pretty wordy already.)

> date_content_modified, date_values_modified

> Both definitions mention changes to the "data", which I presume means changes to variables in the file. Can the definitions and maybe the attribute names be clarified so that the differences between them are clear? Suggest using terminology from the netCDF data model. 

Well, that might be more precise, if we can agree. I'm a little nervous proposing a change, but let's see what people say about just changing 'data' to 'variables' and 'metadata' to 'attributes':

date_content_modified:  The date on which any of the provided content, including variables, attributes, and presented format, was last created or changed (ISO 8601 format) 

date_values_modified: The date on which the provided variables' data values were last created or changed; excludes attributes and formatting changes (ISO 8601 format) 

> can you add the original version 1 from 2005 to the wiki

Good suggestion. As discussed on the call, we'll add this.

John

On Aug 21, 2014, at 10:58, Philip Jones - NOAA Affiliate via Esip-documentation <esip-documentation at lists.esipfed.org> wrote:

> John, all,
> 
> I have a few late comments/questions on the date attributes.
> 
> Attribute: 
> date_product_generated 
>     The date on which this data file or product was produced/distributed (ISO 8601 format). 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. 
> 
> Comment: 
> The date-time a file was "produced" (generated) is not the same as when it was "distributed", because not all datasets are distributed in real-time. Many datasets are produced/generated weeks prior to their distribution. I recommend separating produced from distributed, which suggests that date_issued is still relevant. Is this attribute intended to hold the initial create date of the file?
> 
> Attributes: 
> date_content_modified 
>     The date on which any of the provided content, including data, metadata, and presented format, was last created or changed (ISO 8601 format) 
> date_values_modified
>     The date on which the provided data values were last created or changed; excludes metadata and formatting changes (ISO 8601 format) 
> 
> Comment: 
> Both definitions mention changes to the "data", which I presume means changes to variables in the file. Can the definitions and maybe the attribute names be clarified so that the differences between them are clear? Suggest using terminology from the netCDF data model. 
> 
> Also, if this group is maitaining a history of all ACDD versions, can you add the original version 1 from 2005 to the wiki? It is no longer hosted at Unidata. Archive link from April 2014: https://web.archive.org/web/20140424133239/http://www.unidata.ucar.edu/software/thredds/current/netcdf-java/formats/DataDiscoveryAttConvention.html
> 
> Phil
> 
> 
> On Tue, Aug 19, 2014 at 7:57 PM, John Graybeal via Esip-documentation <esip-documentation at lists.esipfed.org> wrote:
> Hi all,
> 
> In case we get time to consider ACDD Thursday, here are the issues I've seen on the discussion thread and their current status. The page at http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_1-2_Working contains the recommended changes. 
> 
> If there are no further concerns raised, I'd like to do preliminary approval/consent at this call, and schedule the final approval for next call. (If there are still concerns, we can discuss them on-list or on the call.) The approved document can become Version 2, since several people have started calling it that; then everyone is free to work on a groups-aware revision, as they see fit.
> 
> A brief reminder: With respect to issues (1) and (2), because ACDD attributes are all recommendations -- there are no 'shall' statements in the document -- people are still within the specification while not using whatever attributes they don't like. So it isn't dysfunctional if there are attributes that some choose to omit, or deprecated terms that some choose to use.
> 
> === Open Topics ===-
> 
> 1) Deprecation of date_* attributes
> 
> This related to the deprecation of
>     date_created, date_issued, data_modified 
> attributes, while adding (not 1 for 1) 
>     date_content_modified, date_values_modified, date_product_generated.
> 
> This topic was previously summarized in email; review that summary on the talk page[1]. If there continue to be concerns, we can vote on the best answer..
> 
> 2) Adoption of summary metadata for geospatiotemporal ranges (good, tolerable, or bad?)
>     
> Extensive discussion led to an explicit section addressing key software principles[2], and some warning text.  I have not received any critical comments since the last round of changes. (I think one critic is satisfied, another perhaps just silent. :->)  If concerns remain, we can discuss and vote.
> 
> 3) Organization of ACDD pages 
> 
> There is a bit of confusion still with the current organization. I hesitated to go wild with fixes myself, but now that I'm co-chair with Anna, I think we can just fix issues as they are identified. If you have an issue with the ACDD organization, can you please send it to the list or us, as you prefer?  With approval a lot will become more transparent.
> 
> John
> 
> 
> 
> 
> 
> 
> [1] Summary of date_* attribute concerns: http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_1-2_Working#Attributes_Discussed_and_Resolved
> 
> [2] Spatial and Temporal bounds summary recommendations: 
> http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_1-2_Working#Spatial_and_Temporal_Bounds
> 
> 
> 
> 
> _______________________________________________
> Esip-documentation mailing list
> Esip-documentation at lists.esipfed.org
> http://www.lists.esipfed.org/mailman/listinfo/esip-documentation
> 
> 
> 
> 
> -- 
> Philip R. Jones
> Team ERT/STG
> Government Contractor
> National Climatic Data Center, NOAA NESDIS
> Veach-Baley Federal Building
> 151 Patton Ave.
> Asheville, NC 28801-5001 USA
> Voice: +1 828-271-4472  FAX: +1 828-271-4328
> _______________________________________________
> Esip-documentation mailing list
> Esip-documentation at lists.esipfed.org
> http://www.lists.esipfed.org/mailman/listinfo/esip-documentation

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-documentation/attachments/20140821/3252e140/attachment-0001.html>