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

Philip Jones - NOAA Affiliate via Esip-documentation esip-documentation at lists.esipfed.org
Fri Nov 21 09:26:18 EST 2014


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 <http://doodle.com/9erdnp4ma74aa7ew> (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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-documentation/attachments/20141121/c62f641a/attachment.html>


More information about the Esip-documentation mailing list