>I don't know if this is supportive or not, but the "sheer number of groups bringing new requirements" is an issue that I don't think CF has realistically addressed.
With regard to the standard names problem, here's a perhaps-mad idea from someone standing on the sidelines. I don't think this idea has been floated before, but I may have missed it.
Where I'm coming from: I'm the data manager for a modeling project (NARCCAP,
http://narccap.ucar.edu) that's using the CF standard. I don't generate or use any of the project's data, I'm just in charge of checking it to make sure it's properly formatted and trying to make things usable for the community that will use the data. From my perspective, the really important thing about standard names is that if two different files have a variable with the same standard name, it means (1) they're talking about the same thing, and (2) a user can go somewhere and look up the definition and the canonical units. The fact that the name has passed through an approval process is entirely incidental.
So... why not just let any group that wants to define a set of standard names for their community do so, as long as they're willing to also take charge of publishing a Standard Name Table for it?
Essentially, it would be creating namespaces. The only mechanism that would need to be added would be some way of noting which namespace the name comes from and the URL of the corresponding Standard Name Table. So, for example, maybe for chemical names, all the standard names would all start with "iupac:" and somewhere in the global attributes for the file you'd have "standard_namespaces = (default: cf-pcmdi.llnl.gov/cf-standard-name-table.xml, chem: www.iupac.org/cf/standard-names-3.0.xml)". Or something like that.
Each community can manage its own namespace. There's already a mechanism in place (aliases) that could be extended to handle cases where there are two different names for one thing. And if you end up with two names for the same thing with different dimensions or slightly different definitions, that's fine, because that situation already exists in the single table. (Rain, for example, can be defined as a mass flux per unit area (precipitation_flux) or as an accumulated depth (lwe_thickness_of_precipitation_amount). They're different ways of talking about the same physical thing. So this is not a new problem for the user.)
Put some bounds on the representational domain that the default standard name table will handle, delegate everything else to whoever in that community wants to deal with it, and no matter how many groups come to CF with new standard names, the system can handle it. Right?
Cheers,
--Seth
----
Seth McGinnis
mcginnis at ucar.edu
NARCCAP Data & User Community Manager
Associate Scientist
ISSE / NCAR
----
Received on Mon Oct 20 2008 - 12:40:05 BST
