[Esip-documentation] ACDD open topic: standard_name_vocabulary (please vote!)

[John Graybeal via Esip-documentation]

Yes, exactly my intent.

John


On Nov 21, 2014, at 06:26, Philip Jones - NOAA Affiliate via Esip-documentation <esip-documentation at lists.esipfed.org> wrote:

> John,
> 
> Thanks for setting up the poll.
> 
> I need help understanding options 2, 4 and 5 before I vote. Can you say if these interpretations are correct?
> 
> #2 Modify the definition of 'standard_name_vocabulary' so that it and 'standard_name' are exclusively for CF standard names (from a specified name table version)?
> 
> #4 Modify the definition of 'standard_name_vocabulary' so that it and 'standard_name' can be used for any standard name (adding the note on CF compliance)?
> 
> #5 Add a new attribute pair, e.g., 'unique_name' and 'unique_name_vocabulary' (and keep 'standard_name' for CF names)?
> 
> Thanks!
> 
> Phil
> 
> On Thu, Nov 20, 2014 at 4:22 PM, John Graybeal via Esip-documentation <esip-documentation at lists.esipfed.org> wrote:
> Hi everyone interested in ACDD,
> 
> On today's call the standard_name_vocabulary attribute's purpose was questioned. The definition reads: 
>> The name and version of the controlled vocabulary from which variable standard names are taken. Example: 'CF Standard Name Table v27'"
> 
> The question was asked,  why is this needed, since CF always uses the same vocabulary? (Answer: To specify the version of the CF Standard Name vocabulary that was used.)
> 
> The suggestion was made that other vocabularies should be allowed in standard names also, for users who want ACDD without being forced to use CF names. (Recognizing that any non-CF standard_name will make the file non-compliant with CF, which requires names from the CF Standard Names vocabulary.) This change could be represented by adding text after the current definition:
>> Using standard_name values that are not from the CF Standard Name Table will make the ACDD file non-compliant with CF.
> 
> The lively but abbreviated discussion revolved around whether ACDD targeted CF compliance, and how badly this addition would impact CF compliance and usability.
> 
> So we have these options for dealing with the standard_name_vocabulary attribute:
> 
> 1) Remove it.
> 2) 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"
> 3) Leave it as is.
> 4) 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."
> 5) 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. 
> 
> I want to see if we can come to resolution without having to talk about it at a meeting, so I'm trying a Doodle poll. Of course you are welcome to comment via this list, but please visit http://doodle.com/9erdnp4ma74aa7ew and show your  preference(s). You can change them if the discussion changes your mind; you can also add comments there at the poll, and I encourage this as a simple way to track the main concerns.
> 
> Please vote now (totally easy) so we can zero in quickly on the main options and issues.  Thanks.
> 
> John
> 
> 
> 
> 
> 
> _______________________________________________
> 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/20141121/70e483ab/attachment.html>