There is another reason:
mapping CF variable names directly to programming language variable names
is pretty handy -- so it's nice if those are legal.
I'm sure not all programming languages have the same restrictions on names,
but there is surely a subset that's pretty common (i.e. none of the usual
math characters).
-Chris
On Mon, Jan 13, 2014 at 12:57 PM, Steve Hankin <steven.c.hankin at noaa.gov>wrote:
> 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 <bryan.lawrence at ncas.ac.uk>
> 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, <john.graybeal at marinexplore.com> wrote:
>
>> As netCDF is growing to allow _at_, +, 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
>> skype: graybealski
>> Marinexplore
>> 920 Stewart Drive
>> Sunnyvale 94085
>> California, USA
>> www.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
>
>
> ------------------------------------
> *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 listCF-metadata at cgd.ucar.eduhttp://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20140114/9cfce9a7/attachment.html>
Received on Tue Jan 14 2014 - 10:08:14 GMT
