Dear Steve,
This sounds like an excellent suggestion. As you say, the CF-convention is
doing sterling work and is certainly the most comprehensive of the NetCDF
metadata conventions. It can also be applied beyond NetCDF which is very
useful. However, the growth of the standard name list is relatively slow and
is unlikely to catch up with the 10s of 1000s of chemistry and other
domain-specific parameters. Rather than trying to manage all standard names
and understand them it would be better to allow each community to build
their own convention lists that can plug in to CF.
I also support your second suggestion that supplies an audit trail for
modifications that are made to the standard name table as this is bound to
happen (and already has!).
There is, of course, still the issue that there will be overlap between
standard name tables within different communities. We still need
thesauri/ontologies (or whatever we want to call them) to cross this bridge.
Hopefully, similar communities will talk to eachother to converge on this.
You are probably aware of Roy Lowry's (British Oceanographic Data Centre)
current work with the EnParDis (Enabling Parameter Discovery) project which
is establishing a list (or semantic model) of thousands of variables, most
of which are marine or chemical in origin. OTS may want to plug into this
work.
Kind regards,
Ag Stephens (BADC)
a.stephens at rl.ac.uk
===========================================================
Hello CF-ers,
Background:
The topic of this message is the the CF Standard Names table. But the
context is considerably broader than CF users, alone. The value of the CF
conventions already extends well beyond the climate and forecast modeling
communities. CF represents one of the most mature and thoughtful profiles
of netCDF that exists today. As such it has great deal of value to other
communities. As an example, I have encouraged the international group
working on developing an OTS standard (Ocean Time Series -- for moored ocean
measurements) to adopt as much of CF as they can. A time series series is
after all just a degenerate 4D grid, right? Much of CF applies very nicely.
Importantly it is an achievable goal that an OTS data set can *be* a CF
dataset simply by defining some new attributes and conventions that are
mandatory for OTS, only. So any CF application will be able to read OTS
files -- even if some of the specialized semantics are not understood.
One notable flaw in this is the CF standard_name table. The "standard_name"
attribute is highly applicable to the OTS (or any other) community. But the
CF standard_name table contents are not. The ocean measurement community
needs to grow its own rapidly evolving and distinct list of specialized
names -- some may be as arcane and specialized as
"tendency_of_air_temperature_due_to_diabatic_processes". I assert (in order
to hear if there is dissent) that CF does not want to become a naming
authority for all physical parameters. CF is already having to juggle
compatibility with many other organizations involved in this game.
Proposal:
I propose the following new tag, "standardNameConventions":
// global attributes:
:Conventions = "CF-1.0" ;
:standardNameConventions =
"
http://www.cgd.ucar.edu/cms/eaton/cf-metadata/standard_name.xml"
The goal is to make CF into a broader standard at little effort -- so that
OTS and other communities can create true CF files with differing parameter
name standards. Other communities could insert their own standard_name.xml
file. The new attribute will also liberate the CF standard, so that the
name table can evolve separately from the CF version, itself (and much more
rapidly.)
- steve
====
Post Scriptum:
Standard name tables will be evolving documents for some time to come (for
ever). Mistakes will be made in official versions of the table (make no
mistake about it!) There should be a mechanism to correct mistakes without
"breaking" files that have previously been created. For discussion I
propose that an easy means to achieve this might be to expand the XML schema
of the standard name table with just a few new tags, so that it can become
an audit trail. In other words add new XML tags (in bold below) such as
<standardNameTableVersion>
<versionNumber>1.2</versionNumber>
<date>22Jun2004</date>
</standardNameTableVersion>
and
<renamed id="air_pressure_at_convective_cloud_base" version=1.2>
xlink to new and old <entry> tags
</renamed>
and
<entry id="new_air_pressure_at_convective_cloud_base">
<version>1.2</version>
<canonical_units>Pa</canonical_units>
<description>cloud_base refers to the base of the lowest
cloud.</description>
</entry>
and even
<deleted id="some_misbegotten_variable" version=1.2>
xlink to old <entry> tag
</renamed>
ATT847655.txtATT847655.txt
Received on Wed Jun 23 2004 - 02:06:25 BST
