Hi Ajay -
If you're asking about the global attribute standard_name_vocabulary, it
isn't
actually part of CF, it's part of the data discovery attributes
convention(ACDD),
so I'm not sure if this list is the best place to ask about this field.
The ACDD project is now being supported by ESIP; the page describing it
is at
http://wiki.esipfed.org/index.php/Category:Attribute_Conventions_Dataset_Discovery
Questions about it can be sent to the esip-documentation email list, at
http://www.lists.esipfed.org/mailman/listinfo/esip-documentation
As far as I know, the only group that has implemented ACDD extensively
is at
NODC; they've published templates and examples that use it. On their
site, at
https://geo-ide.noaa.gov/wiki/index.php?title=NODC_NetCDF_Templates, it
says:
'Since these templates comply with CF conventions, this attribute should
contain "CF-1.6". '
On the ESIP site, there's a 'working version' where proposals are under
discussion for
the next rev of the convention. On that page, there's a different syntax
being proposed
' "CF:NetCDF COARDS Climate and Forecast Standard Names"' - however that
hasn't actually
been discussed yet. Personally I prefer the NODC version, but I think
this field is redundant;
if the 'conventions' attribute contains CF, then the standard names are
from CF, as far as I
can see.
Cheers - Nan
On 6/14/13 8:53 AM, Jim Biard wrote:
> Ajay,
>
> As best as I understand, the standard_name_vocabulary attribute should
> contain the name and version of the actual standard name table - most
> likely the one current to when you designed the file contents. It
> should be something along the lines of
>
> CF Standard Name Table (v16, 11 October 2010)
>
> Grace and peace,
>
> Jim
>
>
> On Jun 14, 2013, at 8:48 AM, Ajay Krishnan - NOAA Affiliate
> <ajay.krishnan at noaa.gov <mailto:ajay.krishnan at noaa.gov>> wrote:
>
>> Hello Roy,
>>
>> Thanks for that bit of information. So is it safe to leave out the
>> version number till the issues with the reference to multiple URI's
>> have been sorted out?
>>
>> Thanks,
>> Ajay
>>
>>
>> Message: 2
>> Date: Thu, 13 Jun 2013 08:44:25 -0400
>> From: Ajay Krishnan - NOAA Affiliate <ajay.krishnan at noaa.gov
>> <mailto:ajay.krishnan at noaa.gov>>
>> To: cf-metadata at cgd.ucar.edu <mailto:cf-metadata at cgd.ucar.edu>
>> Subject: [CF-metadata] standard_name_vocabulary attribute
>> Message-ID:
>>
>> <CAA9eyS49D1bzGpQE5dcxTd9gzEnkX9aUMFjZQbiT_uLmL7EpZA at mail.gmail.com
>> <mailto:CAA9eyS49D1bzGpQE5dcxTd9gzEnkX9aUMFjZQbiT_uLmL7EpZA at mail.gmail.com>>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> Hi,
>>
>> There seems to be some ambiguity about the usage of the
>> standard_name_vocabulary attribute. Based on the link below, the
>> right
>> value would be to use something like CF 1.6
>> http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html#standard_name_vocabulary_Attribute
>>
>> Is that the right usage or should we reference the version of the
>> cf-standard-name-table like v1..v23 etc.?
>>
>> Any info on this would be much appreciated.
>>
>> Thanks,
>> Ajay
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20130613/2313776c/attachment-0001.html>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Thu, 13 Jun 2013 14:50:04 +0100
>> From: "Lowry, Roy K." <rkl at bodc.ac.uk <mailto:rkl at bodc.ac.uk>>
>> To: Ajay Krishnan - NOAA Affiliate <ajay.krishnan at noaa.gov
>> <mailto:ajay.krishnan at noaa.gov>>,
>> "cf-metadata at cgd.ucar.edu
>> <mailto:cf-metadata at cgd.ucar.edu>" <cf-metadata at cgd.ucar.edu
>> <mailto:cf-metadata at cgd.ucar.edu>>
>> Subject: Re: [CF-metadata] standard_name_vocabulary attribute
>> Message-ID:
>>
>> <40829B0E077C1145A6DE44D39B3830A922C46DC0B0 at nerckwmb1.ad.nerc.ac.uk
>> <mailto:40829B0E077C1145A6DE44D39B3830A922C46DC0B0 at nerckwmb1.ad.nerc.ac.uk>>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> Hello Ajay,
>>
>> If I've got it right, your example is a URL for a single standard
>> name. The version numbers refer to versions of the whole list
>> and so including the version number in a reference to a single
>> standard name causes the standard name to inherit the version
>> number of the list of which it is a member. Trouble is that most
>> standard names are members of more than one list version but the
>> standard name is exactly the same in each of these versions.
>> Consequently, a given standard name ends up with multiple URIs.
>> In version 1 of the vocabulary server we run (NERC Vocabulary
>> Server or NVS) we made the mistake of list members inheriting the
>> version numbers of their parent lists and learned the hard way
>> the problems it causes for operational systems. Versioning in
>> the current version of NVS (V2)has been done differently with
>> list member and list versioning totally decoupled and the
>> versioning information explicitly excluded from list member URIs.
>>
>> I am aware of work underway by Mark Hedley at the UK Met Office
>> to provide URLs for Standard Names in a CF namespace that follow
>> linked data principles by resolving into usable XML (SKOS RDF)
>> documents. I'm not sure how far this work has progressed, so
>> I'll leave it Mark to say more on the list if he feels he's ready.
>>
>> Cheers, Roy.
>>
>> ________________________________
>> From: CF-metadata [cf-metadata-bounces at cgd.ucar.edu
>> <mailto:cf-metadata-bounces at cgd.ucar.edu>] On Behalf Of Ajay
>> Krishnan - NOAA Affiliate [ajay.krishnan at noaa.gov
>> <mailto:ajay.krishnan at noaa.gov>]
>> Sent: 13 June 2013 13:44
>> To: cf-metadata at cgd.ucar.edu <mailto:cf-metadata at cgd.ucar.edu>
>> Subject: [CF-metadata] standard_name_vocabulary attribute
>>
>>
>> Hi,
>>
>> There seems to be some ambiguity about the usage of the
>> standard_name_vocabulary attribute. Based on the link below, the
>> right value would be to use something like CF 1.6
>> http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html#standard_name_vocabulary_Attribute
>>
>> Is that the right usage or should we reference the version of the
>> cf-standard-name-table like v1..v23 etc.?
>>
>> Any info on this would be much appreciated.
>>
>> Thanks,
>> Ajay
>>
>> ________________________________
>> ________________________________
>> From: CF-metadata [cf-metadata-bounces at cgd.ucar.edu
>> <mailto:cf-metadata-bounces at cgd.ucar.edu>] on behalf of Lowry,
>> Roy K. [rkl at bodc.ac.uk <mailto:rkl at bodc.ac.uk>]
>> Sent: 13 June 2013 14:50
>> To: Ajay Krishnan - NOAA Affiliate; cf-metadata at cgd.ucar.edu
>> <mailto:cf-metadata at cgd.ucar.edu>
>> Subject: Re: [CF-metadata] standard_name_vocabulary attribute
>>
>> Hello Ajay,
>>
>> If I've got it right, your example is a URL for a single standard
>> name. The version numbers refer to versions of the whole list
>> and so including the version number in a reference to a single
>> standard name causes the standard name to inherit the version
>> number of the list of which it is a member. Trouble is that most
>> standard names are members of more than one list version but the
>> standard name is exactly the same in each of these versions.
>> Consequently, a given standard name ends up with multiple URIs.
>> In version 1 of the vocabulary server we run (NERC Vocabulary
>> Server or NVS) we made the mistake of list members inheriting the
>> version numbers of their parent lists and learned the hard way
>> the problems it causes for operational systems. Versioning in
>> the current version of NVS (V2)has been done differently with
>> list member and list versioning totally decoupled and the
>> versioning information explicitly excluded from list member URIs.
>>
>> I am aware of work underway by Mark Hedley at the UK Met Office
>> to provide URLs for Standard Names in a CF namespace that follow
>> linked data principles by resolving into usable XML (SKOS RDF)
>> documents. I'm not sure how far this work has progressed, so
>> I'll leave it Mark to say more on the list if he feels he's ready.
>>
>> Cheers, Roy.
>>
>>
>>
>> ________________________________
>> From: CF-metadata [cf-metadata-bounces at cgd.ucar.edu
>> <mailto:cf-metadata-bounces at cgd.ucar.edu>] on behalf of Ajay
>> Krishnan - NOAA Affiliate [ajay.krishnan at noaa.gov
>> <mailto:ajay.krishnan at noaa.gov>]
>> Sent: 13 June 2013 13:44
>> To: cf-metadata at cgd.ucar.edu <mailto:cf-metadata at cgd.ucar.edu>
>> Subject: [CF-metadata] standard_name_vocabulary attribute
>>
>>
>> Hi,
>>
>> There seems to be some ambiguity about the usage of the
>> standard_name_vocabulary attribute. Based on the link below, the
>> right value would be to use something like CF 1.6
>> http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html#standard_name_vocabulary_Attribute
>>
>> Is that the right usage or should we reference the version of the
>> cf-standard-name-table like v1..v23 etc.?
>>
>> Any info on this would be much appreciated.
>>
>> Thanks,
>> Ajay
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20130613/443c998e/attachment.html>
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: publishingStandardNames.pdf
>> Type: application/pdf
>> Size: 63930 bytes
>> Desc: publishingStandardNames.pdf
>> URL:
>> <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20130613/443c998e/attachment.pdf>_______________________________________________
>> CF-metadata mailing list CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>
--
*******************************************************
* Nan Galbraith Information Systems Specialist *
* Upper Ocean Processes Group Mail Stop 29 *
* Woods Hole Oceanographic Institution *
* Woods Hole, MA 02543 (508) 289-2444 *
*******************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20130614/45afa703/attachment-0001.html>
Received on Fri Jun 14 2013 - 08:34:06 BST
