This seems like a good idea, but I have to disagree with one part of it.
It looks like you want to change the CF convention so that a variable is not
required to have either a long name or an un-prefixed standard name. This
requirement seems like a very basic part of the standard to me, and one that
isn't especially difficult to implement.
I'd really like to see you require long names. You could use them to
provide short definitions for your new <project>_standard_name terms; so,
each variable would have either a standard_name or a
<project>_standard_name,
but all would have a long_name. This would keep a lot of code from needing
to be re-written ... and leave the standard intact.
Also, I hope anyone using the <project>_standard_name technique will
be 'strongly encouraged' to provide enough information about the term in
the <project> field so that in 10 years we're not all scratching our
heads to
figure out the acronyms. Just what that information should be, and how
the terms allowed in the <project> field would be controlled, should be
discussed. At a bare minimum, you'd want to spell out the project name
& provide a URI for the project and/or for the definitions (assuming
they're
too long to be supplied completely as long_names).
We rely on CF being easily found on the web over the long haul, and that's
just not true for every project. The open discussions on the CF list and the
fact that the definitions can be relied upon to be available in the
future are
the strengths of the standard - this doesn't mean we can't move towards
using other namespaces, but, in this case, it seems like we can easily do
that in a way that doesn't require changes to the standard.
Cheers - Nan
> Dear all,
>
> we are currently cleaning all files on our TFHTAP multi-model
> experiment server to make them fully CF(1.0) conformant. It has been
> about 3 years since we had drafted the original format description of
> these experiments and also initiated the standard name discussion for
> chemical constituents (thanks again to Christiane Textor who did a lot
> of this initial work). Many standard names which we needed have now been
> defined (thanks to all who contributed and to Allison for maintaining
> the list!). Nevertheless, there are a number of model variables left for
> which no standard name has been agreed upon and where we (or the CF
> mailing list group) also felt that they are too specialized to deserve a
> "standard" name. From the perspective of the CF community this may not
> be an issue, but in the context of interoperability (we now operate a
> WCS server to share these files) the fact that some variables do have a
> standard_name attribute and others don't poses considerable challenges.
> The CF convention states that "either standard_name or long_name" should
> be present. In our view, the long_name attribute is a poor substitute
> for the standard_name, because it has no rules attached. We are now
> planning to substitute "illegal" standard_name attributes by a new
> "htap-_standard_name" attribute, which shall make clear that these names
> are derived according to the CF guidelines, but they are not accepted
> standard_names. Such a concept would enable software tools to easily
> scan additional standard_name tables and make use of the well-defined
> semantics that a standard_name provides without having to push
> additional standard_names through the discussion - in particular if they
> are no so "standard". I can see the danger that certain groups might
> think it no longer necessary to go through the tedious but ultimately
> worthwhile discussion process in this mailing list and the meaning of
> "standard" names could get diluted. However, in my view the advantage of
> having the possibility to extend the convention without breaking
> standard-conformance outweighs this potential disadvantage.
>
> Specifically I would thus propose to add an optional attribute to
> the CF documents such as:
>
> <project>_standard_name: use this attribute to define the meaning of
> variables which have no accepted standard_name defined (yet). The
> project name should be a single string without blanks or underscore
> characters. These project-specific standard_names must follow the
> guidelines for the construction of standard_names, but they will not be
> evaluated by generic tools which test a data file for CF compliance.
> Groups who wish to define such project-specific standard names should
> first consider to submit their proposals to the CF mailing list for
> inclusion in the CF standard name table. A variable can contain either a
> standard_name or <project>_standard_name attribute but not both. A
> long_name attribute is not needed when a <project>_standard_name is
> given.
>
>
> Best regards,
>
> Martin
>
>
--
*******************************************************
* Nan Galbraith (508) 289-2444 *
* Upper Ocean Processes Group Mail Stop 29 *
* Woods Hole Oceanographic Institution *
* Woods Hole, MA 02543 *
*******************************************************
Received on Wed May 12 2010 - 12:27:13 BST
