Thank you all very much! -Ajay On Fri, Jun 14, 2013 at 10:54 AM, <[email protected]> wrote:
> Send CF-metadata mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of CF-metadata digest..." > > > Today's Topics: > > 1. Re: standard_name_vocabulary attribute (Jim Biard) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 14 Jun 2013 10:53:59 -0400 > From: Jim Biard <[email protected]> > To: "[email protected] List" <[email protected]> > Subject: Re: [CF-metadata] standard_name_vocabulary attribute > Message-ID: <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > We are making use of the ACDD here at NCDC. We are referencing the > standard name table that was current at the time the standard name > attribute values were specified for the file. I agree that referencing a > version of CF is both incomplete and redundant. > > Jim Biard > Research Scholar > Cooperative Institute for Climate and Satellites > Remote Sensing and Applications Division > National Climatic Data Center > 151 Patton Ave, Asheville, NC 28801-5001 > > [email protected] > 828-271-4900 > > > > Follow us on Facebook! > > On Jun 14, 2013, at 10:34 AM, Nan Galbraith <[email protected]> wrote: > > > 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 < > [email protected]> 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 <[email protected]> > >>> To: [email protected] > >>> Subject: [CF-metadata] standard_name_vocabulary attribute > >>> Message-ID: > >>> < > caa9eys49d1bzgpqe5dcxtd9gzenkx9aumfjzqbit_ulml7e...@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." <[email protected]> > >>> To: Ajay Krishnan - NOAA Affiliate <[email protected]>, > >>> "[email protected]" <[email protected]> > >>> Subject: Re: [CF-metadata] standard_name_vocabulary attribute > >>> Message-ID: > >>> < > 40829b0e077c1145a6de44d39b3830a922c46dc...@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 [[email protected]] On Behalf Of > Ajay Krishnan - NOAA Affiliate [[email protected]] > >>> Sent: 13 June 2013 13:44 > >>> To: [email protected] > >>> 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 [[email protected]] on behalf of > Lowry, Roy K. [[email protected]] > >>> Sent: 13 June 2013 14:50 > >>> To: Ajay Krishnan - NOAA Affiliate; [email protected] > >>> 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 [[email protected]] on behalf of > Ajay Krishnan - NOAA Affiliate [[email protected]] > >>> Sent: 13 June 2013 13:44 > >>> To: [email protected] > >>> 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 [email protected] > 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 * > > ******************************************************* > > > > > > _______________________________________________ > > CF-metadata mailing list > > [email protected] > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20130614/bbd08426/attachment.html > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: CicsLogoTiny.png > Type: image/png > Size: 15784 bytes > Desc: not available > URL: < > http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20130614/bbd08426/attachment.png > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > CF-metadata mailing list > [email protected] > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > ------------------------------ > > End of CF-metadata Digest, Vol 122, Issue 36 > ******************************************** >
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
