Jim/Ajay,
There may be misunderstanding here. If Ajay wants to cite the source of the standard name, then as Jim says he should follow standard library practice and include both the version number and the publication date.
However, I understood that Ajay wanted to provide a URI in the form of a URL for a particular standard name, which is something completely different. What our experience has taught us is that version numbers of lists have no place in the URIs (whether URNs or URLs) for members of that list. This is the advice that I was trying to pass on to Ajay.
Does that clarify?
Cheers, Roy.
________________________________
From: CF-metadata [cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Jim Biard [jim.biard at noaa.gov]
Sent: 14 June 2013 13:53
To: cf-metadata at cgd.ucar.edu List
Cc: Ajay Krishnan - NOAA Affiliate
Subject: Re: [CF-metadata] standard_name_vocabulary attribute
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
Jim Biard
Research Scholar
Cooperative Institute for Climate and Satellites<
http://www.cicsnc.org/>
Remote Sensing and Applications Division
National Climatic Data Center<
http://www.ncdc.noaa.gov/>
151 Patton Ave, Asheville, NC 28801-5001
jim.biard at noaa.gov<mailto:jim.biard at noaa.gov>
828-271-4900
[cid:560F6B81-8392-410D-844D-E13247D3F791 at cicsnc.org]
Follow us on Facebook<
https://www.facebook.com/cicsnc>!
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>
------------------------------
Subject: Digest Footer
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu<mailto:CF-metadata at cgd.ucar.edu>
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
------------------------------
End of CF-metadata Digest, Vol 122, Issue 28
********************************************
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu<mailto:CF-metadata at cgd.ucar.edu>
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
________________________________
This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20130614/726e0aa5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CicsLogoTiny.png
Type: image/png
Size: 15784 bytes
Desc: CicsLogoTiny.png
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20130614/726e0aa5/attachment-0001.png>
Received on Fri Jun 14 2013 - 08:20:09 BST
