Bob et al.,
So I looked more closely at the references you supplied in your first
email and I am left additional questions and confusion. I hope that
one of the recipients of this message can shed some light on what
appears to me to be a conflict in either the intent or the
interpretation in the way that NetCDF and CF-1.4 define use the
attribute Conventions.
In section 2.6.1 of the CF-1.4 conventions page "Identification of
Conventions" ( http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.html#identification-of-conventions
), it says this:
We recommend that netCDF files that follow these conventions indicate
this by setting the NUG defined global attribute Conventions to the
string value "CF-1.4" . The string is interpreted as a directory name
relative to a directory that is a repository of documents describing
sets of discipline-specific conventions. The conventions directory
name is currently interpreted relative to the directory pub/netcdf/
Conventions/on the host machine ftp.unidata.ucar.edu. The web based
versions of this document are linked from the netCDF Conventions web
page.
But the NetCDF Conventions page ( http://www.unidata.ucar.edu/software/netcdf/conventions.html
) which is referenced at the end of that section clearly indicates
that comma or space separated lists of conventions names as a value
for the attribute Conventions is specifically allowed:
It is possible for a netCDF file to adhere to more than one set of
conventions, even when there is no inheritance relationship among the
conventions. In this case, the value of the `Conventions' attribute
may be a single text string containing a list of the convention names
separated by blank space (recommended) or commas (if a convention name
contains blanks), for example
:Conventions = "XXX YYY" ;
So from my reading of this:
- The current use of the Conventions attribute at ERD is correct
according to the NetCDF Conventions page.
- Section 2.6.1 of the CF-1.4. convention does not specifically
address the use of multiple space or comma separated values in the
value of the Conventions attribute. However it does seem that the text
of section 2.6.1 would indicate a very different specific meaning of
the string value of the Conventions attribute (as a directory name in
a file system) than that described in the NetCDF conventions document.
Is it really the intent of the authors of CF-1.4 that the meaning of
the NetCDF Conventions attribute be overridden if the CF-1.4
convention is supported?
Is it the intent that the attribute Metadata_Conventions from the
NetCDF Attribute Convention for Dataset Discovery (http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html
) is to supersede the use of the netCDF Conventions attribute, thus
freeing the Conventions attribute for use as a directory name?
And in the CF-1.4 section 2.6.1 this sentence: "The string is
interpreted as a directory name relative to a directory that is a
repository of documents describing sets of discipline-specific
conventions." Indicates an entirely different meaning/interpretation/
semantics for the value of the Conventions attribute that is in direct
conflict with the one defined on the NetCDF Conventions page. Is that
really allowed? The sentence following: "The conventions directory
name is currently interpreted relative to the directory pub/netcdf/
Conventions/ on the host machine ftp.unidata.ucar.edu." Seems to
restrict the meaning even further to one that is implementation
specific to the UNIDATA data server. That seems even more out of place
on a conventions definition document.
I proclaim myself bewildered. Help and comments would be greatly
appreciated.
Nathan
On Jan 21, 2010, at 10:57 AM, Bob Simons wrote:
Please leave "Metadata_Conventions" as is.
The problem is that the widely used CF convention specifies that the
value of "Conventions" should be just "CF-1.4" and that the value is
sometimes interpreted as a directory name. So it can't be a list of
conventions. See
http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.html#identification-of-conventions
So it is useful to have a separate "Metadata_Conventions" attribute
which can be a comma-separated list of convention names, e.g.,
"COARDS, CF-1.4, Unidata Dataset Discovery v1.0". See
http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html
.
The misuse of "Conventions" at the ERD site was my mistake. I am
working to change it to (for most datasets)
Conventions : CF-1.4
Metadata_Conventions: COARDS, CF-1.4, Unidata Dataset Discovery v1.0
That's my $0.02.
On 1/21/2010 10:36 AM, Nathan Potter wrote:
Greetings,
Any idea how many people are using the UNIDATA's NetCDF Attribute
Convention for Dataset Discovery??
If Roy's site is the primary (only?) example of it in actual use,
and we
accept Benno's point that the name attribute *Metadata_Conventions*
is
redundant, should we not consider amending the draft to change the
attribute name from *Metadata_Conventions* to *Conventions*?
(Assuming that it hasn't been push passed the draft spec: Dataset
Discovery NetCDF Attribute Convention
<http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html
>)
If we don't change it might we amend the draft to explicitly make the
attributes *Metadata_Conventions* and *Conventions* synonymous?
Nathan
On Jan 14, 2010, at 9:44 AM, Roy Mendelssohn wrote:
There are metadata in our files that follows all of those
conventions.
In trying to relay that act, we felt this was the best way to relay
that fact. So you will find the metadata required for CF, the
Coastwatch conventions, and the Unidata Data Discovery Conventions.
-Roy
On Jan 14, 2010, at 9:40 AM, Benno Blumenthal wrote:
OK, again trying desperately to understand your cryptic e-mails,
http://thredds1.pfeg.noaa.gov/thredds/dodsC/satellite/SW/chla/1day.das
has many of those attributes. You did, however, say
String Conventions "COARDS, CF-1.0, Unidata Dataset Discovery v1.0,
CWHDF";
whereas the document suggested looking for
String Metadata_Conventions = "Unidata Dataset Discovery v1.0";
What you are doing, of course, makes sense. Did the original
document
get corrected over time?
Benno
On Thu, Jan 14, 2010 at 12:31 PM, Roy Mendelssohn
<Roy.Mendelssohn@xxxxxxxx <mailto:Roy.Mendelssohn@xxxxxxxx>> wrote:
No we use it extensively. Look at any of he satellite data at our
TDS (http://oceanwatch.pfeg.noaa.gov/thredds/catalog.html). It is
just since this is not automatically produced by the TDS that we
have a program of our own that generates our catalogs.
-Roy
On Jan 14, 2010, at 9:18 AM, Benno Blumenthal wrote:
So, to be really concrete, despite this convention of using
netcdf
attributes to insert metadata which you just pointed us to, you
don't use it at all, you just scan your netcdf files yourself and
generate the TDS XML directly.
Benno
On Thu, Jan 14, 2010 at 12:14 PM, Roy Mendelssohn
<Roy.Mendelssohn@xxxxxxxx <mailto:Roy.Mendelssohn@xxxxxxxx>>
wrote:
We did this "by hand" (well actually we have a program that does
it) in generating our catalogs not certain ow others do it.
-Roy
On Jan 14, 2010, at 8:56 AM, Nathan Potter wrote:
Roy,
Briefly scanning that page it looks like this gist of it is that
one could use NcML to add/complete a "Unidata Dataset Discovery
v1.0" set of metadata to a data set. THis could then be
harvested
by the TDS, or by other software that understood the "Unidata
Dataset Discovery v1.0" convention.
Is that the general idea?
N
On Jan 14, 2010, at 8:41 AM, Roy Mendelssohn wrote:
Hi Nathan:
Look at:
http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html
-Roy
On Jan 14, 2010, at 8:33 AM, Nathan Potter wrote:
Greetings,
I have some questions about the origin of the
thredds:geospaptialCoverage element that is commonly found in
THREDDS catalogs. It is my understanding that:
- The TDS can generate this metadata element by interrogating
certain types of source data files.
- People that write their own THREDDS catalog files to be
served
by the TDS can add the thredds:geospaptialCoverage metadata
directly to their catalogs (using whatever process they wish).
Is the thredds:geospaptialCoverage also something that can be
added through normal channels in NcML augmented data sets?
= = =
Nathan Potter ndp at opendap.org
OPeNDAP, Inc. +1.541.231.3317
_______________________________________________
thredds mailing list
thredds@xxxxxxxxxxxxxxxx <mailto:thredds@xxxxxxxxxxxxxxxx>
For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/
**********************
"The contents of this message do not reflect any position of
the
U.S. Government or NOAA."
**********************
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
1352 Lighthouse Avenue
Pacific Grove, CA 93950-2097
e-mail: Roy.Mendelssohn@xxxxxxxx
<mailto:Roy.Mendelssohn@xxxxxxxx> (Note new e-mail address)
voice: (831)-648-9029
fax: (831)-648-8440
www: http://www.pfeg.noaa.gov/
"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected"
= = =
Nathan Potter ndp at opendap.org
OPeNDAP, Inc. +1.541.231.3317
**********************
"The contents of this message do not reflect any position of the
U.S. Government or NOAA."
**********************
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
1352 Lighthouse Avenue
Pacific Grove, CA 93950-2097
e-mail: Roy.Mendelssohn@xxxxxxxx
<mailto:Roy.Mendelssohn@xxxxxxxx>
(Note new e-mail address)
voice: (831)-648-9029
fax: (831)-648-8440
www: http://www.pfeg.noaa.gov/
"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected"
--
Dr. M. Benno Blumenthal benno@xxxxxxxxxxxxxxxx
<mailto:benno@xxxxxxxxxxxxxxxx>
International Research Institute for climate and society
The Earth Institute at Columbia University
Lamont Campus, Palisades NY 10964-8000 (845) 680-4450
**********************
"The contents of this message do not reflect any position of the
U.S. Government or NOAA."
**********************
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
1352 Lighthouse Avenue
Pacific Grove, CA 93950-2097
e-mail: Roy.Mendelssohn@xxxxxxxx <mailto:Roy.Mendelssohn@xxxxxxxx>
(Note new e-mail address)
voice: (831)-648-9029
fax: (831)-648-8440
www: http://www.pfeg.noaa.gov/
"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected"
--
Dr. M. Benno Blumenthal benno@xxxxxxxxxxxxxxxx
<mailto:benno@xxxxxxxxxxxxxxxx>
International Research Institute for climate and society
The Earth Institute at Columbia University
Lamont Campus, Palisades NY 10964-8000 (845) 680-4450
**********************
"The contents of this message do not reflect any position of the
U.S.
Government or NOAA."
**********************
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
1352 Lighthouse Avenue
Pacific Grove, CA 93950-2097
e-mail: Roy.Mendelssohn@xxxxxxxx <mailto:Roy.Mendelssohn@xxxxxxxx>
(Note new e-mail address)
voice: (831)-648-9029
fax: (831)-648-8440
www: http://www.pfeg.noaa.gov/
"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected"
= = =
Nathan Potter ndp at opendap.org
OPeNDAP, Inc. +1.541.231.3317
_______________________________________________
thredds mailing list
thredds@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/
--
Sincerely,
Bob Simons
IT Specialist
Environmental Research Division
NOAA Southwest Fisheries Science Center
1352 Lighthouse Ave
Pacific Grove, CA 93950-2079
Phone: (831)658-3205
Fax: (831)648-8440
Email: bob.simons@xxxxxxxx
The contents of this message are mine personally and
do not necessarily reflect any position of the
Government or the National Oceanic and Atmospheric
Administration.
<>< <>< <>< <>< <>< <>< <>< <>< <><
_______________________________________________
thredds mailing list
thredds@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/
= = =
Nathan Potter ndp at opendap.org
OPeNDAP, Inc. +1.541.231.3317
