⇐ ⇒

[CF-metadata] non-standard standard_names

From: Schultz, Martin <m.schultz>
Date: Wed, 12 May 2010 14:33:29 +0200

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


------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Received on Wed May 12 2010 - 06:33:29 BST

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:41 BST

⇐ ⇒