Hi John,
Philosophically I am aligned with Bryan: the purpose of the CF standard
is to constrain (simplify and make predictable) the use of a highly
general file creation toolkit like netCDF. The question of limitations
placed on name strings should be evaluated on this yard stick.
There is a class of problems that are created by embedding special
syntax characters willy-nilly into name strings. Namely, that the use
of such characters can render mathematical expressions ambiguous.
Here's a simple example. Suppose a file contains 3 surface marine
variables -- lets say atmospheric CO2, ocean CO2 and an artfully
computed delta across the surface. Further say that the file creator
chooses to name the delta variable using a "-", as in
atmosCO2
waterCO2
and
// atmosCO2-waterCO2
Then the meaning of the mathematical expression "atmosCO2-waterCO2" has
been rendered ambiguous. Is it a single variable name, or the
difference of two? One is forced to use arbitrary tricks that are
alien to the scientific users we are trying to serve -- say
disambiguating the expression by insisting on surrounding quotes,
"atmosCO2"-"waterCO2", white space, "atmosCO2 - waterCO2". (Would any
scientist read "atmosCO2 - waterCO2" and "atmosCO2-waterCO2" to have
distinct meanings?)
As you say we have already headed down this (slippery) slope. Characters
like "+", "-", "." and case-sensitivity have leaked through into fairly
common practice. For better or worse. :-( (Should the publishers of
science textbooks start using case-sensitive variable names?) So the
question that you've posed is in a sense, /now that the horse is out of
the barn, is there any merit to keeping the other animals penned?/
Like Brian, I would argue that the way to answer this is to insist that
at least there be significant gains from letting them out.
Another unintended negative consequence: the impact on free text
searches when our variable names include special syntax characters.
Are our metadata procedures on an arc so promising that we have no need
to rely on general Google-style tools for discovery?
- Steve
=============================================
On 1/13/2014 12:12 PM, John Graybeal wrote:
Not sure I am following you -- constraints are presumably there for a
reason, I wasn't sure what the reason was for these particular
constraints, but thought they might have simply echoed earlier netCDF
constraints.
To your 'use case' question, we were thinking about alternatives to
mx_ as prefix for our own attributes, to minimize the chance of
collisions (e.g., with some maintenance variables someone might name mx_).
john
On Jan 13, 2014, at 11:27, Bryan Lawrence <[email protected]
<mailto:[email protected]>> wrote:
Hi John
In the spirit of CF being *constrained* netCDF, it seems that we
wouldn't, unless we had a specific use case ... do you?
Cheers
Bryan
On 13 January 2014 18:54, <[email protected]
<mailto:[email protected]>> wrote:
As netCDF is growing to allow @, +, hyphen, and period in
variable/dimension/attribute names, is there any likelihood CF
will grow to allow some or all of those characters?
I seem to recall some tools have conflicts with some of those
characters (aside from them being non-conformant). But
consistency and flexibility would be nice.
john
------------------------------------
John Graybeal
Sr. Data Manager, Metadata & Semantics
M +1 408 675-5445 <tel:%2B1%20408%20675-5445>
skype: graybealski
Marinexplore
920 Stewart Drive
Sunnyvale 94085
California, USA
www.marinexplore.com
<http://www.marinexplore.com/><http://marinexplore.com
<http://marinexplore.com/>>
--
Scanned by iCritical.
--
Bryan Lawrence
University of Reading: Professor of Weather and Climate Computing.
National Centre for Atmospheric Science: Director of Models and Data.
STFC: Director of the Centre for Environmental Data Archival.
Ph: +44 118 3786507 or 1235 445012; Web:home.badc.rl.ac.uk/lawrence
<http://home.badc.rl.ac.uk/lawrence>
------------------------------------
*John Graybeal*
Sr. Data Manager, Metadata & Semantics
M +1 408 675-5445
skype: graybealski
Marinexplore
920 Stewart Drive
Sunnyvale 94085
California, USA
www.marinexplore.com <http://marinexplore.com>
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
