[Esip-documentation] topics and schedule for ACDD

[John Graybeal via Esip-documentation]

Hi everyone! Here's where I think we are with ACDD topics and schedule.

*** NEXT ACDD SPECIAL MEETING ***

We intended to hold the ACDD side meeting yesterday, but due to preparation oversight missed the chance (sorry!). I've proposed a Doodle poll for a make-up meeting next week; can you please fill it out if you'd like to attend this next meeting? The intent is to resolve everything if we can, so as to allow final adoption at the ESIP Winter meeting.

The Doodle poll is at http://doodle.com/t385cv5k7acm57ad. Given everyone can contribute off-line, or at the final approval meeting, I think we should hold the meeting at the best available time, unless we can't get more than 3 or so.

*** TOPICS ***

1) Standard_name_vocabulary attribute
2) Product_version and software_version
3) Status of cdm_data_type
4) Final comments and wrap-up

Details of these topics are below.

The current version is at http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_1-3; soon I will edit it to incorporate the markups already visible.

John


*** TOPIC 1: STANDARD_NAME_VOCABULARY ATTRIBUTE

Thank you for voting in the Doodle poll (see poll, or its summary at end of this email). We have no consensus or strong favorite; eliminating the lowest vote-getter (Remove it) the remaining options are close (No change, Clarifying the definition, Generalizing the definition, or Adding new attributes). 

No option got 70% YES votes; only one option had less than 30% NO votes (Generalize it (beyond CF) by adding CF compliance warning to the description), but it had only one YES vote.

SO: I will leave the poll open for additional votes (or for people to change their votes; just click on the pencil by your name). This poll is strictly informational of course. When we have the meeting, if someone wants a vote on one of these options, they can ask for it. Otherwise, we leave things the way they are (2nd favorite choice out of 5).

*** TOPIC 2: PRODUCT_VERSION and SOFTWARE_VERSION ATTRIBUTES

Proposals are:
* product_version: The version identifier of the product based on the algorithm or methodology applied.
* software_version: The version identifier of the software that generated the data. 

Discussion has taken place on the list (and now has a few more days to take place); let's try to finalize decisions on these attributes at the meeting, ideally resolving any issues beforehand.


*** TOPIC 3: CDM_DATA_TYPE ATTRIBUTE

I overlooked this topic in Bob Simons' email of 10/16/2014, and as a result we have not explicitly addressed his concern in the meeting after that (though there was long ago considerable discussion in the list). I will send a separate email summarizing the status of that attribute.


*** APPENDIX: SUMMARY OF RESULTS ON TOPIC 1 POLL 

Proposal
Description
Yes
If Need Be
No
1) Remove it.
Remove attribute.
2
0
6
2) Make it specific to versions
Make it more specific to versions, e.g., change its definition to "The version of the CF standard names from which variable standard names are taken. Example: v27"
4
1
3
3) Leave it as is.
No change.
2
3
3
4) Generalize it
Change its definition to add the text above: "Using standard_name values that are not from the CF Standard Name Table will make the file non-compliant with CF."
2
4
2
5) Add unique_name and unique_name_vocabulary attributes
Add a variable attribute called unique_name, definition "A unique descriptive name for the variable taken from a controlled vocabulary of variable names."  And add a name for its vocabulary. 
2
2
4

Comments:

> CF Standard Names are backwards compatible, so the version of the S.N. table isn't needed - nothing is removed or redefined (substantively). If the aim is to allow/encourage other sets of variable names, let's call it something other than standard_name_vocabulary.
 
> The standard_name_vocabulary attribute points up an oversight in CF. CF does not, within itself, provide a way to indicate which standard name vocabulary was used when selecting standard names for a file. This attribute is rectifying the oversight. And I agree that we shouldn't override CF's use of an attribute, as John G said.
 
> As much as I'd like to extend CF's focus on a single vocabulary, I don't think we should override CF's use of an attribute.





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