Hello,
On Mon, 27 Oct 2008, Karl Taylor wrote:
> It seems to me that the issue of possibly wanting to store several different
> chemical species in a single array (with a coordinate variable identifying the
> species) is only one limitation of the current constraints placed by standard
> names. We've also run up against the following difficulties:
> [...]
> I think it is perhaps time to consider devising an alternative way of
> providing the information that is currently in the standard name (instead of
> forcing all the information into a single attribute). As you will see, this
> will eliminate the above limitations, but perhaps more importantly it provides
> a way of more quickly converging on new standard names.
>
> The idea, which I'm sure must have been discussed at length already (but I've
> forgotten by now or I've missed it entirely), is to parse the quantity
> identification information into separate elements (or "categories" or
> "components"). We already do this to a certain extent by providing some
> information in the cell_methods attribute. [...]
> [...]
> These independent bits of information could be automatically assembled
> together to create the "standard name". [...]
>
> The main job of the standard name committee would be to agree on when a new
> *component* should be added and agree on the list of acceptable values for
> each component. This would force everyone to think about whether a new
> variable can be distinguished from others simply by adding a new value to one
> of the components, or if an entirely new category (i.e., component) is needed.
> [...]
I think this would be a fantastic approach, and much more extensible and
manageable than the existing standard names which attempt to encapsulate
(IMHO) much more than just a name. I wholeheartedly second the motion!
Julia
--
Julia Collins
National Snow and Ice Data Center
CIRES, University of Colorado, Boulder
449 UCB
Boulder, CO 80309-0449
Voice: 303-492-6405
E-mail: collinsj at nsidc.org
Received on Tue Oct 28 2008 - 13:46:25 GMT
