Hi.
I don't think we should use ease of mapping variable names to a programming language as a reason for allowing (or not allowing) any particular character in variable names. CF has, as I understood it, considered variable names as completely up to the producer, relying on attributes to provide meaning. So, I can name a temperature variable "fluffy_bunny" if I want to, and it is completely valid. Section 1.3 of the Conventions states, "No variable or dimension names are standardized by this convention." Section 2.3 states: Variable, dimension and attribute names should begin with a letter and be composed of letters, digits, and underscores. Note that this is in conformance with the COARDS conventions, but is more restrictive than the netCDF interface which allows use of the hyphen character. The netCDF interface also allows leading underscores in names, but the NUG states that this is reserved for system use. Case is significant in netCDF names, but it is recommended that names should not be distinguished purely by case, i.e., if case is disregarded, no two names should be the same. It is also recommended that names should be obviously meaningful, if possible, as this renders the file more effectively self-describing. This convention does not standardize any variable or dimension names. While the Conventions makes recommendations about variable names, NO STANDARDS are set by the Conventions. So, why were non-alphanumeric characters other than '_' excluded by practice back in the day? Are these reasons still valid? In fact, given the statements in the Conventions, is there actually anything other than opinion constraining people from using any characters they like in variable (and dimension) names (as long as they are OK with netCDF and maybe NUG)? Grace and peace, Jim On 2014-01-14 12:08, Chris Barker wrote: > 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.han...@noaa.gov [9]> 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.lawre...@ncas.ac.uk [5]> 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.grayb...@marinexplore.com [3]> 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 >>>>> skype: graybealski >>>>> Marinexplore >>>>> 920 Stewart Drive >>>>> Sunnyvale 94085 >>>>> California, USA >>>>> www.marinexplore.com [1]<http://marinexplore.com [2]> >>>>> >>>>> -- >>>>> 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 [4] >>> >>> ------------------------------------ >>> 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 [6] >>> >>> _______________________________________________ >>> CF-metadata mailing list >>> CF-metadata@cgd.ucar.edu >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata@cgd.ucar.edu [7] >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata [8] > > -- > > 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.bar...@noaa.gov [10] Links: ------ [1] http://www.marinexplore.com/ [2] http://marinexplore.com/ [3] mailto:john.grayb...@marinexplore.com [4] http://home.badc.rl.ac.uk/lawrence [5] mailto:bryan.lawre...@ncas.ac.uk [6] http://marinexplore.com [7] mailto:CF-metadata@cgd.ucar.edu [8] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata [9] mailto:steven.c.han...@noaa.gov [10] mailto:chris.bar...@noaa.gov
_______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata