Re: [CF-metadata] standard_name modifiers

[Robert Muetzelfeldt]

Dear all,

Jonathan suggested having a web-based tool which can be used to check 
possible standard names, prior to submitting them for human approval. 
This could use the grammar he developed for CF-metadata names, and which 
he has written up at 
http://www.met.reading.ac.uk/~jonathan/CF_metadata/14.1/ 
. (This 
grammar apparently handled all the Standard Names around when it was 
developed - a very impressive achievement.)


I thought it might help the discussion to implement this idea. This 
involved two steps:
1. Converting his grammar (as presented on Jonathan's web page) into 
Prolog's grammar notation.

2. Making a parser for this grammar available on the web.

The implementation of Jonathan's grammar in Prolog follows the approach 
which I have described previously on this mailing list, and which is 
written up at 
http://envarml.pbworks.com/w/page/8988921/Prototype+grammar+for+CF-metadata+%22standard+names%22+(Prolog+version) 
 
- the only difference being that I have now used his grammar rules 
rather than ones based on the CF-metadata guidelines.


I have checked the list of standard names which Jonathan used in his 
work against the Prolog version of his grammar, and currently 1958 out 
of the total of 2072 names parse correctly. The remaining 100 or so are 
probably down to slight differences in the way that filler words, such 
as prepositions, are handled - this is just a question of checking all 
the rules for consistency in how the filler words are included.


My colleague Mark Muetzelfeldt has produced a web app which gives access 
to this Prolog grammar, providing browser-based access to a simple query 
system for checking that a proposed standard name conforms to the 
grammar. This is available at 
http://www.eco-epistemics.org/cf_metadata_grammar/. It includes the text 
for the complete Prolog version of Jonathan's grammar. It goes without 
saying that I would welcome any feedback (or, better, that we decide to 
set up some sort of working group to take this forward). Please note 
that this is a highly-experimental and early-stage exercise, designed 
primarily to explore what a grammar-based online CF-metadata checker 
might look like. It has been tested only in Firefox and Chrome.


A number of issues have arisen during this exercise:

1. I feel strongly that it is highly desirable to use a standard grammar 
notation (such as Prolog's) for representing the grammar. Apart from the 
benefits of using a standard approach, this makes it straightforward to 
handle arbitrary nesting of grammar rules (as in, say, a grammar for 
English), rather than Jonathan's flat set of rules.


2. In my opinion, it is far better for the name itself to contain all 
the information about a particular variable, rather than use a separate 
mechanism (modifiers). Consider a variable such as 
"monthly_mean_of_log_of ratio_of_leaf_carbon_to_root_nitrogen". This is 
straightforward to capture in a grammar (provided it can handle the 
recursive aspect of the nesting of mathematical functions, which most 
could), and almost impossible to capture by the use of modifiers on some 
base Standard Name.


3. Prolog is a particularly useful platform to use for this task. It has 
long had a specific notation for grammar rules which is very readable 
and supported natively by the Prolog interpreter. Using Prolog offers 
several substantial benefits over other approaches, including the 
ability to handle more advanced grammar requirements, the ability to 
query the grammar and/or a collection of Standard Names directly in the 
Prolog interpreter, and the ease with which it can made available as a 
web app.


4. One feature of Prolog which deserves special mention is that it can 
easily be used to automatically generate names which are valid according 
to the grammar - this can be done with a one-line query. This may seem 
useless, but in fact is a very effective way of picking up weaknesses in 
the grammar: if a generated name is (to the expert human) nonsense, then 
that can help us to refine the grammar.


5. Jonathan's grammar includes base (atomic) terms which could be 
further broken down, for example:

phenomenon -->
due_to_condensation_and_evaporation_from_boundary_layer_mixing
due_to_condensation_and_evaporation_from_convection
due_to_condensation_and_evaporation_from_longwave_heating
due_to_condensation_and_evaporation_from_pressure_change
due_to_condensation_and_evaporation_from_shortwave_heating
due_to_condensation_and_evaporation_from_turbulence
There is clearly scope here for some more rationalisation.

6. The current policy is (as I understand it) that each new Standard 
Name has to be approved individually, but that anyone can add whatever 
modifiers they like. If, as I suggest, the role of modifiers is 
incorporated into the grammar

Re: [CF-metadata] standard_name modifiers

[Jonathan Gregory]

Dear Philip and John

I agree with what Philip says here:

> We could then tweak our current practice on this mailing list so that when a
> person proposes a std_name they should state (or perhaps there is a little
> bit of code to check) that the proposed std_name conforms to the existing
> grammar and vocabulary rules.  I think most of us would then provide only
> cursory scrutiny.  Perhaps there could even be an automatic timer so that if
> nobody objects within some time period (perhaps 1 month) then the name is
> automatically accepted.  Essentially the default decision for conforming
> names would be 'acceptance'.  I think this would also make the generation of
> the text descriptions either automatic, or perhaps obsolete, in many cases
> because they could be inferred from the grammar and vocabulary tables.

I could bring the grammar up to date as a starting point. I agree that it
would be possible to work out text corresponding to each phrase and thus
construct definitions, or at least a first draft of them. Units could also
be deduced automatically. I don't myself have the expertise or the time to
write scripts in support of this, to make it easy for proposers to use these
procedures e.g. on the web.


John writes:
> But where we are talking about adding generic modifiers, it seems to me a 
> more automated approach is possible.  If the meaning of the modifier is 
> clear, then no matter what name it is applied to, the meaning of the 
> resulting compound should be clear.  If that is the case, then adding that 
> modifier to an existing name should be verifiable mechanically.

If this refers to the standard_name modifiers, which are separate words
appended to standard names, then in fact no approval is needed. It is fine
to add these to the standard_name attribute. That is not regarded as creating
a new standard_name. In fact the modifiers were introduced to avoid having to
add such names to the table.

Best wishes

Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] standard_name modifiers

[John Graybeal]

There are a number of quite attractive suggestions here.  The idea that someone 
could enter a name to a tool that says "no, we would not build the name that 
way because..." is quite attractive, though perhaps only viable for simple 
denials.  I hope some of the other ideas can move forward.

There is a rich review process of the details of each term which others will 
convey, and that will take place thoroughly for every suggested name, I am sure.

That said there are two kinds of names that could be subject to routine 
conformance.  Jonathan focused (I think) on constructions involving the body of 
the name, and I agree those will not be automatable for another 3-4 years 
(;->),  if only because the definition has to be reality-checked.

But where we are talking about adding generic modifiers, it seems to me a more 
automated approach is possible.  If the meaning of the modifier is clear, then 
no matter what name it is applied to, the meaning of the resulting compound 
should be clear.  If that is the case, then adding that modifier to an existing 
name should be verifiable mechanically.  No?

john

On Mar 2, 2011, at 19:51, Cameron-smith, Philip wrote:

> Hi All,
> 
> The last time we discussed formalizing grammar and vocabulary, or an 
> ontology, it was clearly hard to get agreement.  It would also be a lot of 
> hard work and could be a lot of work to amend and modify if it is done too 
> narrowly.
> 
> I suggest we consider a weaker option, which I think would give us much of 
> the benefit at moderately cost, and could be a step on the road to a more 
> rigorous system. 
> 
> I suspect it would be fairly easy to take Jonathan's inferred grammar and 
> vocabulary system and attach meanings to each phrase and piece of grammar by 
> cutting and pasting from the existing std_name descriptions.
> 
> We could then tweak our current practice on this mailing list so that when a 
> person proposes a std_name they should state (or perhaps there is a little 
> bit of code to check) that the proposed std_name conforms to the existing 
> grammar and vocabulary rules.  I think most of us would then provide only 
> cursory scrutiny.  Perhaps there could even be an automatic timer so that if 
> nobody objects within some time period (perhaps 1 month) then the name is 
> automatically accepted.Essentially the default decision for conforming 
> names would be 'acceptance'.   I think this would also make the generation of 
> the text descriptions either automatic, or perhaps obsolete, in many cases 
> because they could be inferred from the grammar and vocabulary tables.
> 
> This would provide faster acceptance for proposers, and allow this mailing 
> group to focus on the harder issues, primarily ones which want to modify or 
> extend the grammar and/or vocabulary.
> 
> I think this is what have been doing in practice for a while, and I think 
> formalizing it a little would make it better for all.
> 
> Best wishes,
> 
>   Philip
> 
> ---
> Dr Philip Cameron-Smith, p...@llnl.gov, Lawrence Livermore National Lab.
> ---
> 
> 
> 
>> -Original Message-
>> From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-
>> boun...@cgd.ucar.edu] On Behalf Of Jonathan Gregory
>> Sent: Wednesday, March 02, 2011 5:37 AM
>> To: Seth McGinnis
>> Cc: cf-metadata@cgd.ucar.edu
>> Subject: Re: [CF-metadata] standard_name modifiers
>> 
>> Dear Seth
>> 
>> I think we can devise systems which will develop *proposed* standard
>> names
>> that conform to existing patterns and lexicon. If they do, they are
>> often
>> uncontroversial and usually accepted. However we still need a manual
>> approval
>> process because there are sometimes choices about how a quantity might
>> be
>> described i.e. there's more than one possible conformant proposal, and
>> there
>> are special cases when there is a commonly used term we might want to
>> employ.
>> Apart from those reasons, there are also a quite often proposals which
>> require
>> new lexicon, new interpretations or new patterns.
>> 
>> Best wishes
>> 
>> Jonathan
>> ___
>> 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
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata



John Graybeal   <mailto:jgrayb...@ucsd.edu> 
phone: 858-534-2162
Product Manager
Ocean Observatories Initiative Cyberinfrastructure Project: 
http://ci.oceanobservatories.org
Marine Metadata Interoperability Project: http://marinemetadata.org   

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] standard_name modifiers

[Cameron-smith, Philip]

Hi All,

The last time we discussed formalizing grammar and vocabulary, or an ontology, 
it was clearly hard to get agreement.  It would also be a lot of hard work and 
could be a lot of work to amend and modify if it is done too narrowly.

I suggest we consider a weaker option, which I think would give us much of the 
benefit at moderately cost, and could be a step on the road to a more rigorous 
system. 

I suspect it would be fairly easy to take Jonathan's inferred grammar and 
vocabulary system and attach meanings to each phrase and piece of grammar by 
cutting and pasting from the existing std_name descriptions.

We could then tweak our current practice on this mailing list so that when a 
person proposes a std_name they should state (or perhaps there is a little bit 
of code to check) that the proposed std_name conforms to the existing grammar 
and vocabulary rules.  I think most of us would then provide only cursory 
scrutiny.  Perhaps there could even be an automatic timer so that if nobody 
objects within some time period (perhaps 1 month) then the name is 
automatically accepted.Essentially the default decision for conforming 
names would be 'acceptance'.   I think this would also make the generation of 
the text descriptions either automatic, or perhaps obsolete, in many cases 
because they could be inferred from the grammar and vocabulary tables.

This would provide faster acceptance for proposers, and allow this mailing 
group to focus on the harder issues, primarily ones which want to modify or 
extend the grammar and/or vocabulary.

I think this is what have been doing in practice for a while, and I think 
formalizing it a little would make it better for all.

Best wishes,

   Philip

---
Dr Philip Cameron-Smith, p...@llnl.gov, Lawrence Livermore National Lab.
---



> -Original Message-
> From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-
> boun...@cgd.ucar.edu] On Behalf Of Jonathan Gregory
> Sent: Wednesday, March 02, 2011 5:37 AM
> To: Seth McGinnis
> Cc: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] standard_name modifiers
> 
> Dear Seth
> 
> I think we can devise systems which will develop *proposed* standard
> names
> that conform to existing patterns and lexicon. If they do, they are
> often
> uncontroversial and usually accepted. However we still need a manual
> approval
> process because there are sometimes choices about how a quantity might
> be
> described i.e. there's more than one possible conformant proposal, and
> there
> are special cases when there is a commonly used term we might want to
> employ.
> Apart from those reasons, there are also a quite often proposals which
> require
> new lexicon, new interpretations or new patterns.
> 
> Best wishes
> 
> Jonathan
> ___
> 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
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] standard_name modifiers

[Jonathan Gregory]

Dear Seth

I think we can devise systems which will develop *proposed* standard names
that conform to existing patterns and lexicon. If they do, they are often
uncontroversial and usually accepted. However we still need a manual approval
process because there are sometimes choices about how a quantity might be
described i.e. there's more than one possible conformant proposal, and there
are special cases when there is a commonly used term we might want to employ.
Apart from those reasons, there are also a quite often proposals which require
new lexicon, new interpretations or new patterns.

Best wishes

Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] standard_name modifiers

[Jonathan Gregory]

Dear Robert

As you probably remember, I have quite a thorough and mostly automatic method
for parsing/constructing standard names using a lexicon and sentence patterns.
I haven't updated this to the most recent standard name table but I would offer
it as something that could help with proposing new names, especially if some
web-based tools were written to support it. The last version is
http://www.met.reading.ac.uk/~jonathan/CF_metadata/14.1/

Best wishes

Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] standard_name modifiers

[Robert Muetzelfeldt]

Can we please resurrect the topic of a grammar for standard names, which 
Jonathan and I have raised in the past? - see 
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2010/007093.html for 
an entry point.This discussion illustrates as clearly as can be that 
the time has come to really get to grips with this - ultimately there 
really is no alternative.   If this forum is not the right place to 
develop this in detail, then I'm very happy to be contacted off-list.


Cheers,
Robert



On 01/03/11 21:07, Seth McGinnis wrote:

I'm in favor of a generalized system for automatically constructing new
standard names by applying quantifiers to established ones.  In fact, when I
first encountered the Guidelines for Construction of CF Standard Names, I
thought that's what it *was*, and it took me a while to understand that you
still had to actually propose the standard name and have it accepted.
  Obviously there are potential complications if chaining together multiple
quantifiers is allowed, but for simple derived names, I think it sounds like a
great idea.

Case in point: I've been meaning to propose two new standard names myself, and
hadn't gotten around to writing the email about it yet:

histogram_of_spell_length_of_days_with_lwe_thickness_of_precipitation_amount_above_threshold
histogram_of_spell_length_of_days_with_lwe_thickness_of_precipitation_amount_below_threshold

(I've simply applied the "histogram_of" modifier to two existing names here, so
that we can record the climatological distributions of wet and dry spells.)

This seems like exactly the kind of thing that could be automated away with
some general rules, no?  Or is my proposal more controversial than I think it
is?

Cheers,

--Seth



On Mon, 28 Feb 2011 17:15:13 +
  Jonathan Gregory  wrote:

Dear Martin

Even 24 such cases wouldn't be really a problem. However, I don't feel
strongly
about this myself. This is not quite the original use of standard_name
modifiers, which is to describe variables containing ancillary quantities.
However, it seems to be a reasonable use of the mechanism, since it's a
derived quantity. (A combination of quantities would be more difficult to
deal with, as we have discussed.) I feel that opinions from others on whether
we should make this change would be helpful.

Best wishes

Jonathan

On Mon, Feb 28, 2011 at 09:14:18AM +0100, Schultz, Martin wrote:


 maybe I am fighting a lost battle here, but let me try to argue once

more for a generalized solution, i.e. the addition of "anomaly" as a standard
name modifier. I don't like the idea of adding a new standard name for each
new anomaly: i) this seems illogical and new users will ask "why is there an
anomaly defined for temperature, but nor for precipitation?", ii) past
experience has shown that it takes time to get new standard names adopted, and
if new use cases come up (as they are bound to be for something as essential
as anomalies) it may discourage people to even go for standard names for these
variables. Why not try to make the system as systematic as possible? I don't
want to argue against a pragmatic approach, but if you decide to change the
anomalies from individual standard names to a modifier in three years, the
effort might be much larger, the confusion will be greater and other
"operators" with similar problems will come along. So, my suggestion would be
to
deprecate the use of air_pressure_anomaly, air_temperature_anomaly,
geopotential_height_anomaly and surface_temperature_anomaly now and introduce
"anomaly" as a modifier. It's only replacing an underescore by a blank anyhow
;-)

 As we just developed some tools to compute multi-model means and model

anomalies for the TFHTAP data sets, I would otherwise have to come up with a
list of ~20 new "_anomaly" standard names. So, besides what I see a rational
argument (above), I have a personal reason for arguing so vehemently.
___
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
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata




--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] standard_name modifiers

[Seth McGinnis]

I'm in favor of a generalized system for automatically constructing new
standard names by applying quantifiers to established ones.  In fact, when I
first encountered the Guidelines for Construction of CF Standard Names, I
thought that's what it *was*, and it took me a while to understand that you
still had to actually propose the standard name and have it accepted.
 Obviously there are potential complications if chaining together multiple
quantifiers is allowed, but for simple derived names, I think it sounds like a
great idea.

Case in point: I've been meaning to propose two new standard names myself, and
hadn't gotten around to writing the email about it yet:

histogram_of_spell_length_of_days_with_lwe_thickness_of_precipitation_amount_above_threshold
histogram_of_spell_length_of_days_with_lwe_thickness_of_precipitation_amount_below_threshold

(I've simply applied the "histogram_of" modifier to two existing names here, so
that we can record the climatological distributions of wet and dry spells.)  

This seems like exactly the kind of thing that could be automated away with
some general rules, no?  Or is my proposal more controversial than I think it
is?

Cheers,

--Seth



On Mon, 28 Feb 2011 17:15:13 +
 Jonathan Gregory  wrote:
>Dear Martin
>
>Even 24 such cases wouldn't be really a problem. However, I don't feel
>strongly
>about this myself. This is not quite the original use of standard_name
>modifiers, which is to describe variables containing ancillary quantities.
>However, it seems to be a reasonable use of the mechanism, since it's a
>derived quantity. (A combination of quantities would be more difficult to
>deal with, as we have discussed.) I feel that opinions from others on whether
>we should make this change would be helpful.
>
>Best wishes
>
>Jonathan
>
>On Mon, Feb 28, 2011 at 09:14:18AM +0100, Schultz, Martin wrote:
>
>> maybe I am fighting a lost battle here, but let me try to argue once
>more for a generalized solution, i.e. the addition of "anomaly" as a standard
>name modifier. I don't like the idea of adding a new standard name for each
>new anomaly: i) this seems illogical and new users will ask "why is there an
>anomaly defined for temperature, but nor for precipitation?", ii) past
>experience has shown that it takes time to get new standard names adopted, and
>if new use cases come up (as they are bound to be for something as essential
>as anomalies) it may discourage people to even go for standard names for these
>variables. Why not try to make the system as systematic as possible? I don't
>want to argue against a pragmatic approach, but if you decide to change the
>anomalies from individual standard names to a modifier in three years, the
>effort might be much larger, the confusion will be greater and other
>"operators" with similar problems will come along. So, my suggestion would be
>to 
> deprecate the use of air_pressure_anomaly, air_temperature_anomaly,
>geopotential_height_anomaly and surface_temperature_anomaly now and introduce
>"anomaly" as a modifier. It's only replacing an underescore by a blank anyhow
>;-)
>> 
>> As we just developed some tools to compute multi-model means and model
>anomalies for the TFHTAP data sets, I would otherwise have to come up with a
>list of ~20 new "_anomaly" standard names. So, besides what I see a rational
>argument (above), I have a personal reason for arguing so vehemently.
>___
>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
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] standard_name modifiers -- units problem

[cristina . tronconi]

Dear Steven..ups.yes.it was a typing mistaken! sorry for  
this error!

Best regards

cristina


Citando Steven Emmerson :


Christina,

I assume you meant "1" for the unit specification rather than "!".

--Steve

On 2/28/2011 5:25 AM, cristina.tronc...@artov.isac.cnr.it wrote:

Dear Steve,
thanks for your recommandation. It is important to me to be sure I can
use "!" as unit, as my data are produced within MYOCEAN (european)
project and thay are going to test my data! so it is important my data
does not failed the CF checker test.

Best regards

cristina




Citando Steven Emmerson :


Cristina,

I recommend the unit "1" for that use.

If the CF checker doesn't like that unit, then it should be fixed, IMO,
because that unit is supported by both the US NIST and the BIPM.

Regards,
Steve Emmerson
UDUNITS developer

On 2/26/2011 12:30 PM, cristina.tronc...@artov.isac.cnr.it wrote:

Dear Roy,
Our variable "chlorophyll count" as is understandable by CF is the
number of individual measurements used to determine a chlorophyll value.

I do need to know what to put at "units" attribute for that variable.
I undestood by the CF convention 1.4 (appendix C) that I have to put
"units="1" as the chlorophyll count is a dimensionless variable...but
the CF checker found it as an error.

I try not to put the Unit attribute ...but again i get an error by che
cf chcker...so.

my question is: what unit shoudl I set for my chlorophyll count
variable?

thanks for your help.

cristina

---
Cristina Tronconi
Istituto di Scienze dell'Atmosfera e del Clima - sezione di Roma
Consiglio Nazionale delle Ricerche
Via Fosso del Cavaliere 100
00133 Roma, Italy
Tel: +39 06 49934342
cell: '39 349 1242954
Fax: +39 06 20660291
e-mail: cristina.tronc...@artov.isac.cnr.it


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata




---
Cristina Tronconi
Istituto di Scienze dell'Atmosfera e del Clima - sezione di Roma
Consiglio Nazionale delle Ricerche
Via Fosso del Cavaliere 100
00133 Roma, Italy
Tel: +39 06 49934342
cell: '39 349 1242954
Fax: +39 06 20660291
e-mail: cristina.tronc...@artov.isac.cnr.it





---
Cristina Tronconi
Istituto di Scienze dell'Atmosfera e del Clima - sezione di Roma
Consiglio Nazionale delle Ricerche
Via Fosso del Cavaliere 100
00133 Roma, Italy
Tel:  +39  06  49934342
cell: '39 349 1242954
Fax:  +39  06  20660291
e-mail:   cristina.tronc...@artov.isac.cnr.it


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] standard_name modifiers -- units problem

[Karl Taylor]

Dear all,

Here's what the CF conventions say about dimensionless quantities:

"Units are not required for dimensionless quantities. A variable with no 
units attribute is assumed to be dimensionless. However, a units 
attribute specifying a dimensionless unit may optionally be included. 
The Udunits package defines a few dimensionless units, such as 
|percent|, but is lacking commonly used units such as ppm (parts per 
million). This convention does not support the addition of new 
dimensionless units that are not udunits compatible. The conforming unit 
for quantities that represent fractions, or parts of a whole, is "1". 
The conforming unit for parts per million is "1e-6". Descriptive 
information about dimensionless quantities, such as sea-ice 
concentration, cloud fraction, probability, etc., should be given in the 
|long_name| or |standard_name| attributes (see below) rather than the 
|units|. "


It does not indicate whether or not it is o.k. to set units to the empty 
string, but by *not* mentioning this, I think we should assume that this 
would not be CF compatible.  I also think that a human interpreting 
units = "" might think that the user had made mistake, whereas if the 
units attribute were missing altogether, they would think it was simply 
unitless.  A strict interpretation of the conventions seems to imply:


1.  a number (like "1" or "1e-6") should be used if the quantity 
represents fractions or parts of a whole, whereas
2.  the units attribute should be omitted in other dimensionless cases 
(e.g., involving ratios such as calcium/boron ratio, or involving 
"counts" such as the number of cars crossing a bridge each day)  In 
these cases the standard name indicates what the quantity is (but I 
wonder what standard name applies in the second example above, and 
should it have units of inverse time?)


If a quantity is dimensionless and the units attribute is present, I 
think the CF checker currently only allows "1" as the units attribute.  
Perhaps this should be generalized since apparently a conforming unit is 
also a number (such as "1e-6" for ppm).  I don't think it should allow 
units = "".


Best regards,
Karl

On 3/1/11 9:26 AM, Steven Emmerson wrote:

Everyone,

The UDUNITS packages (both UDUNITS and UDUNITS-2) interpret the empty
string (i.e., "") as the dimensionless unit 1 -- so if you can't use
"1", then use "" (assuming you pass that string to the UDUNITS library).

The udunits(1) and udunits2(1) programs, however, interpret the empty
string as a user input error and ask for the input unit again.

Regards,
Steve Emmerson
UDUNITS developer

On 2/28/2011 10:18 AM, Rosalyn Hatcher wrote:

Dear Karl,

That is correct. If the variable is deemed unitless, then the checker
will not flag an error if either units=1 or the units attribute is omitted.
If the units attribute is missing, it will, however, produce an
information message suggesting that the units attribute is added for
completeness.

Eg.

--
Checking variable: CHL_count
--
INFO (3.1): No units attribute set.Please consider adding a units attribute 
for completeness.


I introduced the INFO category of message a while ago, for instances
where the checker couldn't be sure of an error (E.g. where an attribute
is being used in a non-standard way), to prompt the user to double check
that what they've put is actually what they meant.

I'll hopefully have a fixed version of the checker available tomorrow
for testing.

Regards,
Ros.




On 28/02/11 16:44, Karl Taylor wrote:

Dear Rosalyn,

I assume the checker will also not complain if the units attribute is
simply omitted when the variable is unitless (i.e., either units="1"
or the attribute is omitted result in the same behavior by the checker).

best regards,
Karl

On 2/28/11 4:28 AM, cristina.tronc...@artov.isac.cnr.it wrote:

Dear Rosalyn,
thanks so much for your reply and your works that is so important for
me. Infact "my" data are produced within MYOCEAN (european) project
and thay are going to test them! so it is important they do not failed
the CF checker test.

Best regards.

cristina

p.s.
Sorry if sometime I miss some e-mails and I didin't answer to them.
This is a very caotic working timeand I'm receiving so many e-mails.

Thanks to all the cf-metadata group to their help!

Citando Rosalyn Hatcher:


I agree units should be set to "1" and I am currently in the process of
fixing the error in the CF Checker.

Regards,
Ros.


On 27/02/11 17:27, Steven Emmerson wrote:

Cristina,

I recommend the unit "1" for that use.

If the CF checker doesn't like that unit, then it should be fixed,
IMO, because that unit is supported by both the US NIST and the BIPM.

Regards,
Steve Emmerson
UDUNITS developer

On 2/26/2011 12:30 PM,cristina.tronc...@artov.isac.cnr.it  wrote:

Dear Roy,
Our variable "chlorophyll count" as is understandable by CF is the
number of individual measurements used to determine a chlorophyll value.

I do need to know w

Re: [CF-metadata] standard_name modifiers -- units problem

[Steven Emmerson]

Everyone,

The UDUNITS packages (both UDUNITS and UDUNITS-2) interpret the empty 
string (i.e., "") as the dimensionless unit 1 -- so if you can't use 
"1", then use "" (assuming you pass that string to the UDUNITS library).


The udunits(1) and udunits2(1) programs, however, interpret the empty 
string as a user input error and ask for the input unit again.


Regards,
Steve Emmerson
UDUNITS developer

On 2/28/2011 10:18 AM, Rosalyn Hatcher wrote:

Dear Karl,

That is correct. If the variable is deemed unitless, then the checker
will not flag an error if either units=1 or the units attribute is omitted.
If the units attribute is missing, it will, however, produce an
information message suggesting that the units attribute is added for
completeness.

Eg.

--
Checking variable: CHL_count
--
INFO (3.1): No units attribute set.Please consider adding a units attribute 
for completeness.


I introduced the INFO category of message a while ago, for instances
where the checker couldn't be sure of an error (E.g. where an attribute
is being used in a non-standard way), to prompt the user to double check
that what they've put is actually what they meant.

I'll hopefully have a fixed version of the checker available tomorrow
for testing.

Regards,
Ros.




On 28/02/11 16:44, Karl Taylor wrote:

Dear Rosalyn,

I assume the checker will also not complain if the units attribute is
simply omitted when the variable is unitless (i.e., either units="1"
or the attribute is omitted result in the same behavior by the checker).

best regards,
Karl

On 2/28/11 4:28 AM, cristina.tronc...@artov.isac.cnr.it wrote:

Dear Rosalyn,
thanks so much for your reply and your works that is so important for
me. Infact "my" data are produced within MYOCEAN (european) project
and thay are going to test them! so it is important they do not failed
the CF checker test.

Best regards.

cristina

p.s.
Sorry if sometime I miss some e-mails and I didin't answer to them.
This is a very caotic working timeand I'm receiving so many e-mails.

Thanks to all the cf-metadata group to their help!

Citando Rosalyn Hatcher:


I agree units should be set to "1" and I am currently in the process of
fixing the error in the CF Checker.

Regards,
Ros.


On 27/02/11 17:27, Steven Emmerson wrote:

Cristina,

I recommend the unit "1" for that use.

If the CF checker doesn't like that unit, then it should be fixed,
IMO, because that unit is supported by both the US NIST and the BIPM.

Regards,
Steve Emmerson
UDUNITS developer

On 2/26/2011 12:30 PM,cristina.tronc...@artov.isac.cnr.it  wrote:

Dear Roy,
Our variable "chlorophyll count" as is understandable by CF is the
number of individual measurements used to determine a chlorophyll value.

I do need to know what to put at "units" attribute for that variable.
I undestood by the CF convention 1.4 (appendix C) that I have to put
"units="1" as the chlorophyll count is a dimensionless variable...but
the CF checker found it as an error.

I try not to put the Unit attribute ...but again i get an error by che
cf chcker...so.

my question is: what unit shoudl I set for my chlorophyll count variable?

thanks for your help.

cristina

---
Cristina Tronconi
Istituto di Scienze dell'Atmosfera e del Clima - sezione di Roma
Consiglio Nazionale delle Ricerche
Via Fosso del Cavaliere 100
00133 Roma, Italy
Tel: +39 06 49934342
cell: '39 349 1242954
Fax: +39 06 20660291
e-mail:cristina.tronc...@artov.isac.cnr.it


___
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
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

--
Rosalyn Hatcher
NCAS Computational Modelling Services
Dept. of Meteorology, University of Reading,
Earley Gate, Reading. RG6 6BB
Email:r.s.hatc...@reading.ac.uk  Tel: +44 (0) 118 378 6016


---
Cristina Tronconi
Istituto di Scienze dell'Atmosfera e del Clima - sezione di Roma
Consiglio Nazionale delle Ricerche
Via Fosso del Cavaliere 100
00133 Roma, Italy
Tel:  +39  06  49934342
cell: '39 349 1242954
Fax:  +39  06  20660291
e-mail:cristina.tronc...@artov.isac.cnr.it


___
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
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata



--
Rosalyn Hatcher
NCAS Computational Modelling Services
Dept. of Meteorology, University of Reading,
Earley Gate, Reading. RG6 6BB
Email:r.s.hatc...@reading.ac.uk  Tel: +44 (0) 118 378 6016



___
CF-metadata

Re: [CF-metadata] standard_name modifiers -- units problem

[Rosalyn Hatcher]

Dear All,

I've made a couple of fixes to the CF checker:

1) If the variable is deemed unitless, then the checker will not flag an 
error if either units=1 or the units attribute is omitted.


2) Fix bug where the checker was incorrectly complaining about a missing 
units attribute on some dimensionless variables.


It's available for testing at:

http://puma.nerc.ac.uk/cgi-bin/cf-checker-2.0.3.pl

Let me know if you find any issues.  If all's well I'll copy it to the 
'live' location on Friday.


Regards,
Ros.

On 28/02/11 17:18, Rosalyn Hatcher wrote:

Dear Karl,

That is correct.  If the variable is deemed unitless, then the checker 
will not flag an error if either units=1 or the units attribute is 
omitted.
If the units attribute is missing, it will, however, produce an 
information message suggesting that the units attribute is added for 
completeness.


Eg.
--
Checking variable: CHL_count
--
INFO (3.1): No units attribute set.  Please consider adding a units attribute 
for completeness.

I introduced the INFO category of message a while ago, for instances 
where the checker couldn't be sure of an error (E.g. where an 
attribute is being used in a non-standard way), to prompt the user to 
double check that what they've put is actually what they meant.


I'll hopefully have a fixed version of the checker available tomorrow 
for testing.


Regards,
Ros.




On 28/02/11 16:44, Karl Taylor wrote:

Dear Rosalyn,

I assume the checker will also not complain if the units attribute is 
simply omitted when the variable is unitless (i.e., either units="1" 
or the attribute is omitted result in the same behavior by the checker).


best regards,
Karl

On 2/28/11 4:28 AM, cristina.tronc...@artov.isac.cnr.it wrote:

Dear Rosalyn,
thanks so much for your reply and your works that is so important for
me. Infact "my" data are produced within MYOCEAN (european) project
and thay are going to test them! so it is important they do not failed
the CF checker test.

Best regards.

cristina

p.s.
Sorry if sometime I miss some e-mails and I didin't answer to them.
This is a very caotic working timeand I'm receiving so many e-mails.

Thanks to all the cf-metadata group to their help!

Citando Rosalyn Hatcher:


I agree units should be set to "1" and I am currently in the process of
fixing the error in the CF Checker.

Regards,
Ros.


On 27/02/11 17:27, Steven Emmerson wrote:

Cristina,

I recommend the unit "1" for that use.

If the CF checker doesn't like that unit, then it should be fixed,
IMO, because that unit is supported by both the US NIST and the BIPM.

Regards,
Steve Emmerson
UDUNITS developer

On 2/26/2011 12:30 PM,cristina.tronc...@artov.isac.cnr.it  wrote:

Dear Roy,
Our variable "chlorophyll count" as is understandable by CF is the
number of individual measurements used to determine a chlorophyll value.

I do need to know what to put at "units" attribute for that variable.
I undestood by the CF convention 1.4 (appendix C) that I have to put
"units="1" as the chlorophyll count is a dimensionless variable...but
the CF checker found it as an error.

I try not to put the Unit attribute ...but again i get an error by che
cf chcker...so.

my question is: what unit shoudl I set for my chlorophyll count variable?

thanks for your help.

cristina

---
Cristina Tronconi
Istituto di Scienze dell'Atmosfera e del Clima - sezione di Roma
Consiglio Nazionale delle Ricerche
Via Fosso del Cavaliere 100
00133 Roma, Italy
Tel: +39 06 49934342
cell: '39 349 1242954
Fax: +39 06 20660291
e-mail:cristina.tronc...@artov.isac.cnr.it


___
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
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

--
Rosalyn Hatcher
NCAS Computational Modelling Services
Dept. of Meteorology, University of Reading,
Earley Gate, Reading. RG6 6BB
Email:r.s.hatc...@reading.ac.uk  Tel: +44 (0) 118 378 6016

---
Cristina Tronconi
Istituto di Scienze dell'Atmosfera e del Clima - sezione di Roma
Consiglio Nazionale delle Ricerche
Via Fosso del Cavaliere 100
00133 Roma, Italy
Tel:  +39  06  49934342
cell: '39 349 1242954
Fax:  +39  06  20660291
e-mail:cristina.tronc...@artov.isac.cnr.it


___
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
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata



--
Rosalyn Hatcher
NCAS Computational Modelling Services
Dept. of Meteorology, University of Reading,
Earley Gate, Reading. RG6 6BB
Email:

Re: [CF-metadata] standard_name modifiers -- units problem

[Rosalyn Hatcher]

Dear Karl,

That is correct.  If the variable is deemed unitless, then the checker 
will not flag an error if either units=1 or the units attribute is omitted.
If the units attribute is missing, it will, however, produce an 
information message suggesting that the units attribute is added for 
completeness.


Eg.

--
Checking variable: CHL_count
--
INFO (3.1): No units attribute set.  Please consider adding a units attribute 
for completeness.


I introduced the INFO category of message a while ago, for instances 
where the checker couldn't be sure of an error (E.g. where an attribute 
is being used in a non-standard way), to prompt the user to double check 
that what they've put is actually what they meant.


I'll hopefully have a fixed version of the checker available tomorrow 
for testing.


Regards,
Ros.




On 28/02/11 16:44, Karl Taylor wrote:

Dear Rosalyn,

I assume the checker will also not complain if the units attribute is 
simply omitted when the variable is unitless (i.e., either units="1" 
or the attribute is omitted result in the same behavior by the checker).


best regards,
Karl

On 2/28/11 4:28 AM, cristina.tronc...@artov.isac.cnr.it wrote:

Dear Rosalyn,
thanks so much for your reply and your works that is so important for
me. Infact "my" data are produced within MYOCEAN (european) project
and thay are going to test them! so it is important they do not failed
the CF checker test.

Best regards.

cristina

p.s.
Sorry if sometime I miss some e-mails and I didin't answer to them.
This is a very caotic working timeand I'm receiving so many e-mails.

Thanks to all the cf-metadata group to their help!

Citando Rosalyn Hatcher:


I agree units should be set to "1" and I am currently in the process of
fixing the error in the CF Checker.

Regards,
Ros.


On 27/02/11 17:27, Steven Emmerson wrote:

Cristina,

I recommend the unit "1" for that use.

If the CF checker doesn't like that unit, then it should be fixed,
IMO, because that unit is supported by both the US NIST and the BIPM.

Regards,
Steve Emmerson
UDUNITS developer

On 2/26/2011 12:30 PM,cristina.tronc...@artov.isac.cnr.it  wrote:

Dear Roy,
Our variable "chlorophyll count" as is understandable by CF is the
number of individual measurements used to determine a chlorophyll value.

I do need to know what to put at "units" attribute for that variable.
I undestood by the CF convention 1.4 (appendix C) that I have to put
"units="1" as the chlorophyll count is a dimensionless variable...but
the CF checker found it as an error.

I try not to put the Unit attribute ...but again i get an error by che
cf chcker...so.

my question is: what unit shoudl I set for my chlorophyll count variable?

thanks for your help.

cristina

---
Cristina Tronconi
Istituto di Scienze dell'Atmosfera e del Clima - sezione di Roma
Consiglio Nazionale delle Ricerche
Via Fosso del Cavaliere 100
00133 Roma, Italy
Tel: +39 06 49934342
cell: '39 349 1242954
Fax: +39 06 20660291
e-mail:cristina.tronc...@artov.isac.cnr.it


___
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
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

--
Rosalyn Hatcher
NCAS Computational Modelling Services
Dept. of Meteorology, University of Reading,
Earley Gate, Reading. RG6 6BB
Email:r.s.hatc...@reading.ac.uk  Tel: +44 (0) 118 378 6016


---
Cristina Tronconi
Istituto di Scienze dell'Atmosfera e del Clima - sezione di Roma
Consiglio Nazionale delle Ricerche
Via Fosso del Cavaliere 100
00133 Roma, Italy
Tel:  +39  06  49934342
cell: '39 349 1242954
Fax:  +39  06  20660291
e-mail:cristina.tronc...@artov.isac.cnr.it


___
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
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata



--
Rosalyn Hatcher
NCAS Computational Modelling Services
Dept. of Meteorology, University of Reading,
Earley Gate, Reading. RG6 6BB
Email: r.s.hatc...@reading.ac.uk Tel: +44 (0) 118 378 6016

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] standard_name modifiers

[Jonathan Gregory]

Dear Martin

Even 24 such cases wouldn't be really a problem. However, I don't feel strongly
about this myself. This is not quite the original use of standard_name
modifiers, which is to describe variables containing ancillary quantities.
However, it seems to be a reasonable use of the mechanism, since it's a
derived quantity. (A combination of quantities would be more difficult to
deal with, as we have discussed.) I feel that opinions from others on whether
we should make this change would be helpful.

Best wishes

Jonathan

On Mon, Feb 28, 2011 at 09:14:18AM +0100, Schultz, Martin wrote:

> maybe I am fighting a lost battle here, but let me try to argue once more 
> for a generalized solution, i.e. the addition of "anomaly" as a standard name 
> modifier. I don't like the idea of adding a new standard name for each new 
> anomaly: i) this seems illogical and new users will ask "why is there an 
> anomaly defined for temperature, but nor for precipitation?", ii) past 
> experience has shown that it takes time to get new standard names adopted, 
> and if new use cases come up (as they are bound to be for something as 
> essential as anomalies) it may discourage people to even go for standard 
> names for these variables. Why not try to make the system as systematic as 
> possible? I don't want to argue against a pragmatic approach, but if you 
> decide to change the anomalies from individual standard names to a modifier 
> in three years, the effort might be much larger, the confusion will be 
> greater and other "operators" with similar problems will come along. So, my 
> suggestion would be to 
 deprecate the use of air_pressure_anomaly, air_temperature_anomaly, 
geopotential_height_anomaly and surface_temperature_anomaly now and introduce 
"anomaly" as a modifier. It's only replacing an underescore by a blank anyhow 
;-)
> 
> As we just developed some tools to compute multi-model means and model 
> anomalies for the TFHTAP data sets, I would otherwise have to come up with a 
> list of ~20 new "_anomaly" standard names. So, besides what I see a rational 
> argument (above), I have a personal reason for arguing so vehemently.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] standard_name modifiers -- units problem

[Karl Taylor]

Dear Rosalyn,

I assume the checker will also not complain if the units attribute is 
simply omitted when the variable is unitless (i.e., either units="1" or 
the attribute is omitted result in the same behavior by the checker).


best regards,
Karl

On 2/28/11 4:28 AM, cristina.tronc...@artov.isac.cnr.it wrote:

Dear Rosalyn,
thanks so much for your reply and your works that is so important for
me. Infact "my" data are produced within MYOCEAN (european) project
and thay are going to test them! so it is important they do not failed
the CF checker test.

Best regards.

cristina

p.s.
Sorry if sometime I miss some e-mails and I didin't answer to them.
This is a very caotic working timeand I'm receiving so many e-mails.

Thanks to all the cf-metadata group to their help!

Citando Rosalyn Hatcher:


I agree units should be set to "1" and I am currently in the process of
fixing the error in the CF Checker.

Regards,
Ros.


On 27/02/11 17:27, Steven Emmerson wrote:

Cristina,

I recommend the unit "1" for that use.

If the CF checker doesn't like that unit, then it should be fixed,
IMO, because that unit is supported by both the US NIST and the BIPM.

Regards,
Steve Emmerson
UDUNITS developer

On 2/26/2011 12:30 PM, cristina.tronc...@artov.isac.cnr.it wrote:

Dear Roy,
Our variable "chlorophyll count" as is understandable by CF is the
number of individual measurements used to determine a chlorophyll value.

I do need to know what to put at "units" attribute for that variable.
I undestood by the CF convention 1.4 (appendix C) that I have to put
"units="1" as the chlorophyll count is a dimensionless variable...but
the CF checker found it as an error.

I try not to put the Unit attribute ...but again i get an error by che
cf chcker...so.

my question is: what unit shoudl I set for my chlorophyll count variable?

thanks for your help.

cristina

---
Cristina Tronconi
Istituto di Scienze dell'Atmosfera e del Clima - sezione di Roma
Consiglio Nazionale delle Ricerche
Via Fosso del Cavaliere 100
00133 Roma, Italy
Tel: +39 06 49934342
cell: '39 349 1242954
Fax: +39 06 20660291
e-mail: cristina.tronc...@artov.isac.cnr.it


___
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
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


--
Rosalyn Hatcher
NCAS Computational Modelling Services
Dept. of Meteorology, University of Reading,
Earley Gate, Reading. RG6 6BB
Email: r.s.hatc...@reading.ac.uk Tel: +44 (0) 118 378 6016



---
Cristina Tronconi
Istituto di Scienze dell'Atmosfera e del Clima - sezione di Roma
Consiglio Nazionale delle Ricerche
Via Fosso del Cavaliere 100
00133 Roma, Italy
Tel:  +39  06  49934342
cell: '39 349 1242954
Fax:  +39  06  20660291
e-mail:   cristina.tronc...@artov.isac.cnr.it


___
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
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] standard_name modifiers

[John Graybeal]

+1

This is a case where clearly the pragmatic approach is to do the systematic 
approach.

Probably can't formally deprecate the terms as Roy points out, but one could 
put in all of their definitions a pointer to the currently recommended 
practice.  

John

On Feb 28, 2011, at 00:14, Schultz, Martin wrote:

> Dear Jonathan et al.,
> 
>maybe I am fighting a lost battle here, but let me try to argue once more 
> for a generalized solution, i.e. the addition of "anomaly" as a standard name 
> modifier. I don't like the idea of adding a new standard name for each new 
> anomaly: i) this seems illogical and new users will ask "why is there an 
> anomaly defined for temperature, but nor for precipitation?", ii) past 
> experience has shown that it takes time to get new standard names adopted, 
> and if new use cases come up (as they are bound to be for something as 
> essential as anomalies) it may discourage people to even go for standard 
> names for these variables. Why not try to make the system as systematic as 
> possible? I don't want to argue against a pragmatic approach, but if you 
> decide to change the anomalies from individual standard names to a modifier 
> in three years, the effort might be much larger, the confusion will be 
> greater and other "operators" with similar problems will come along. So, my 
> suggestion would be to d
 e
> precate the use of air_pressure_anomaly, air_temperature_anomaly, 
> geopotential_height_anomaly and surface_temperature_anomaly now and introduce 
> "anomaly" as a modifier. It's only replacing an underescore by a blank anyhow 
> ;-)
> 
>As we just developed some tools to compute multi-model means and model 
> anomalies for the TFHTAP data sets, I would otherwise have to come up with a 
> list of ~20 new "_anomaly" standard names. So, besides what I see a rational 
> argument (above), I have a personal reason for arguing so vehemently.
> 
> Cheers,
> 
> Martin
> 
> 
> 
> 
> Forschungszentrum Juelich GmbH
> 52425 Juelich
> Sitz der Gesellschaft: Juelich
> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
> Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
> Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
> Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
> Prof. Dr. Sebastian M. Schmidt
> 
> 
> ___
> CF-metadata mailing list
> CF-metadata@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata



John Graybeal    
phone: 858-534-2162
Product Manager
Ocean Observatories Initiative Cyberinfrastructure Project: 
http://ci.oceanobservatories.org
Marine Metadata Interoperability Project: http://marinemetadata.org   

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] standard_name modifiers -- units problem

[cristina . tronconi]

Dear Rosalyn,
thanks so much for your reply and your works that is so important for  
me. Infact "my" data are produced within MYOCEAN (european) project  
and thay are going to test them! so it is important they do not failed  
the CF checker test.


Best regards.

cristina

p.s.
Sorry if sometime I miss some e-mails and I didin't answer to them.  
This is a very caotic working timeand I'm receiving so many e-mails.


Thanks to all the cf-metadata group to their help!

Citando Rosalyn Hatcher :


I agree units should be set to "1" and I am currently in the process of
fixing the error in the CF Checker.

Regards,
Ros.


On 27/02/11 17:27, Steven Emmerson wrote:

Cristina,

I recommend the unit "1" for that use.

If the CF checker doesn't like that unit, then it should be fixed,   
IMO, because that unit is supported by both the US NIST and the BIPM.


Regards,
Steve Emmerson
UDUNITS developer

On 2/26/2011 12:30 PM, cristina.tronc...@artov.isac.cnr.it wrote:

Dear Roy,
Our variable "chlorophyll count" as is understandable by CF is the
number of individual measurements used to determine a chlorophyll value.

I do need to know what to put at "units" attribute for that variable.
I undestood by the CF convention 1.4 (appendix C) that I have to put
"units="1" as the chlorophyll count is a dimensionless variable...but
the CF checker found it as an error.

I try not to put the Unit attribute ...but again i get an error by che
cf chcker...so.

my question is: what unit shoudl I set for my chlorophyll count variable?

thanks for your help.

cristina

---
Cristina Tronconi
Istituto di Scienze dell'Atmosfera e del Clima - sezione di Roma
Consiglio Nazionale delle Ricerche
Via Fosso del Cavaliere 100
00133 Roma, Italy
Tel: +39 06 49934342
cell: '39 349 1242954
Fax: +39 06 20660291
e-mail: cristina.tronc...@artov.isac.cnr.it


___
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
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata



--
Rosalyn Hatcher
NCAS Computational Modelling Services
Dept. of Meteorology, University of Reading,
Earley Gate, Reading. RG6 6BB
Email: r.s.hatc...@reading.ac.uk Tel: +44 (0) 118 378 6016




---
Cristina Tronconi
Istituto di Scienze dell'Atmosfera e del Clima - sezione di Roma
Consiglio Nazionale delle Ricerche
Via Fosso del Cavaliere 100
00133 Roma, Italy
Tel:  +39  06  49934342
cell: '39 349 1242954
Fax:  +39  06  20660291
e-mail:   cristina.tronc...@artov.isac.cnr.it


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] standard_name modifiers -- units problem

[Rosalyn Hatcher]

I agree units should be set to "1" and I am currently in the process of 
fixing the error in the CF Checker.


Regards,
Ros.


On 27/02/11 17:27, Steven Emmerson wrote:

Cristina,

I recommend the unit "1" for that use.

If the CF checker doesn't like that unit, then it should be fixed, 
IMO, because that unit is supported by both the US NIST and the BIPM.


Regards,
Steve Emmerson
UDUNITS developer

On 2/26/2011 12:30 PM, cristina.tronc...@artov.isac.cnr.it wrote:

Dear Roy,
Our variable "chlorophyll count" as is understandable by CF is the
number of individual measurements used to determine a chlorophyll value.

I do need to know what to put at "units" attribute for that variable.
I undestood by the CF convention 1.4 (appendix C) that I have to put
"units="1" as the chlorophyll count is a dimensionless variable...but
the CF checker found it as an error.

I try not to put the Unit attribute ...but again i get an error by che
cf chcker...so.

my question is: what unit shoudl I set for my chlorophyll count 
variable?


thanks for your help.

cristina

---
Cristina Tronconi
Istituto di Scienze dell'Atmosfera e del Clima - sezione di Roma
Consiglio Nazionale delle Ricerche
Via Fosso del Cavaliere 100
00133 Roma, Italy
Tel: +39 06 49934342
cell: '39 349 1242954
Fax: +39 06 20660291
e-mail: cristina.tronc...@artov.isac.cnr.it


___
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
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata



--
Rosalyn Hatcher
NCAS Computational Modelling Services
Dept. of Meteorology, University of Reading,
Earley Gate, Reading. RG6 6BB
Email: r.s.hatc...@reading.ac.uk Tel: +44 (0) 118 378 6016

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] standard_name modifiers -- units problem

[cristina . tronconi]

Dear Steve,
thanks for your recommandation. It is important to me to be sure I can  
use "!" as unit, as my data are produced within MYOCEAN (european)  
project and thay are going to test my data! so it is important my data  
does not failed the CF checker test.


Best regards

cristina




Citando Steven Emmerson :


Cristina,

I recommend the unit "1" for that use.

If the CF checker doesn't like that unit, then it should be fixed, IMO,
because that unit is supported by both the US NIST and the BIPM.

Regards,
Steve Emmerson
UDUNITS developer

On 2/26/2011 12:30 PM, cristina.tronc...@artov.isac.cnr.it wrote:

Dear Roy,
Our variable "chlorophyll count" as is understandable by CF is the
number of individual measurements used to determine a chlorophyll value.

I do need to know what to put at "units" attribute for that variable.
I undestood by the CF convention 1.4 (appendix C) that I have to put
"units="1" as the chlorophyll count is a dimensionless variable...but
the CF checker found it as an error.

I try not to put the Unit attribute ...but again i get an error by che
cf chcker...so.

my question is: what unit shoudl I set for my chlorophyll count variable?

thanks for your help.

cristina

---
Cristina Tronconi
Istituto di Scienze dell'Atmosfera e del Clima - sezione di Roma
Consiglio Nazionale delle Ricerche
Via Fosso del Cavaliere 100
00133 Roma, Italy
Tel: +39 06 49934342
cell: '39 349 1242954
Fax: +39 06 20660291
e-mail: cristina.tronc...@artov.isac.cnr.it


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata




---
Cristina Tronconi
Istituto di Scienze dell'Atmosfera e del Clima - sezione di Roma
Consiglio Nazionale delle Ricerche
Via Fosso del Cavaliere 100
00133 Roma, Italy
Tel:  +39  06  49934342
cell: '39 349 1242954
Fax:  +39  06  20660291
e-mail:   cristina.tronc...@artov.isac.cnr.it


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] standard_name modifiers

[Lowry, Roy K.]

Hi Martin,

' It's only replacing an underescore by a blank anyhow ;-)'

This isn't strictly true.  As the semantics infrastructure stands at the moment 
the deprecation procedure is to label the deprecated Standard Name as an 
'alias' with another Standard Name specified as its replacement. 

I don't know about you, but I would feel a little uneasy about a Standard Names 
list that has 'surface_temperature_anomaly' aliased to 'surface_temperature'.

Cheers, Roy. 


-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu 
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Schultz, Martin
Sent: 28 February 2011 08:14
To: Jonathan Gregory
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] standard_name modifiers

Dear Jonathan et al.,

maybe I am fighting a lost battle here, but let me try to argue once more 
for a generalized solution, i.e. the addition of "anomaly" as a standard name 
modifier. I don't like the idea of adding a new standard name for each new 
anomaly: i) this seems illogical and new users will ask "why is there an 
anomaly defined for temperature, but nor for precipitation?", ii) past 
experience has shown that it takes time to get new standard names adopted, and 
if new use cases come up (as they are bound to be for something as essential as 
anomalies) it may discourage people to even go for standard names for these 
variables. Why not try to make the system as systematic as possible? I don't 
want to argue against a pragmatic approach, but if you decide to change the 
anomalies from individual standard names to a modifier in three years, the 
effort might be much larger, the confusion will be greater and other 
"operators" with similar problems will come along. So, my suggestion would be 
to de
 precate the use of air_pressure_anomaly, air_temperature_anomaly, 
geopotential_height_anomaly and surface_temperature_anomaly now and introduce 
"anomaly" as a modifier. It's only replacing an underescore by a blank anyhow 
;-)

As we just developed some tools to compute multi-model means and model 
anomalies for the TFHTAP data sets, I would otherwise have to come up with a 
list of ~20 new "_anomaly" standard names. So, besides what I see a rational 
argument (above), I have a personal reason for arguing so vehemently.

Cheers,

Martin




Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
-- 
This message (and any attachments) is for the recipient only NERC
is subject to the Freedom of Information Act 2000 and the contents
of this email and any reply you make may be disclosed by NERC unless
it is exempt from release under the Act. Any material supplied to
NERC may be stored in an electronic records management system.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] standard_name modifiers

[Schultz, Martin]

Dear Jonathan et al.,

maybe I am fighting a lost battle here, but let me try to argue once more 
for a generalized solution, i.e. the addition of "anomaly" as a standard name 
modifier. I don't like the idea of adding a new standard name for each new 
anomaly: i) this seems illogical and new users will ask "why is there an 
anomaly defined for temperature, but nor for precipitation?", ii) past 
experience has shown that it takes time to get new standard names adopted, and 
if new use cases come up (as they are bound to be for something as essential as 
anomalies) it may discourage people to even go for standard names for these 
variables. Why not try to make the system as systematic as possible? I don't 
want to argue against a pragmatic approach, but if you decide to change the 
anomalies from individual standard names to a modifier in three years, the 
effort might be much larger, the confusion will be greater and other 
"operators" with similar problems will come along. So, my suggestion would be 
to de
 precate the use of air_pressure_anomaly, air_temperature_anomaly, 
geopotential_height_anomaly and surface_temperature_anomaly now and introduce 
"anomaly" as a modifier. It's only replacing an underescore by a blank anyhow 
;-)

As we just developed some tools to compute multi-model means and model 
anomalies for the TFHTAP data sets, I would otherwise have to come up with a 
list of ~20 new "_anomaly" standard names. So, besides what I see a rational 
argument (above), I have a personal reason for arguing so vehemently.

Cheers,

Martin




Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] standard_name modifiers -- units problem

[Steven Emmerson]

Cristina,

I recommend the unit "1" for that use.

If the CF checker doesn't like that unit, then it should be fixed, IMO, 
because that unit is supported by both the US NIST and the BIPM.


Regards,
Steve Emmerson
UDUNITS developer

On 2/26/2011 12:30 PM, cristina.tronc...@artov.isac.cnr.it wrote:

Dear Roy,
Our variable "chlorophyll count" as is understandable by CF is the
number of individual measurements used to determine a chlorophyll value.

I do need to know what to put at "units" attribute for that variable.
I undestood by the CF convention 1.4 (appendix C) that I have to put
"units="1" as the chlorophyll count is a dimensionless variable...but
the CF checker found it as an error.

I try not to put the Unit attribute ...but again i get an error by che
cf chcker...so.

my question is: what unit shoudl I set for my chlorophyll count variable?

thanks for your help.

cristina

---
Cristina Tronconi
Istituto di Scienze dell'Atmosfera e del Clima - sezione di Roma
Consiglio Nazionale delle Ricerche
Via Fosso del Cavaliere 100
00133 Roma, Italy
Tel: +39 06 49934342
cell: '39 349 1242954
Fax: +39 06 20660291
e-mail: cristina.tronc...@artov.isac.cnr.it


___
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
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] standard_name modifiers -- units problem

[Karl Taylor]

I agree with Roy.

Karl

On 2/26/11 12:19 PM, Lowry, Roy K. wrote:

Hi Cristina,

Looks like my worries were unfounded concerning the meaning of 'count'.  From 
the discussion thread my understanding is that the units you have are OK and 
that the issue is with the CF checker.

Cheers, Roy.

From: cristina.tronc...@artov.isac.cnr.it [cristina.tronc...@artov.isac.cnr.it]
Sent: 26 February 2011 19:30
To: Lowry, Roy K.
Cc: cf-metadata@cgd.ucar.edu
Subject: standard_name modifiers -- units problem

Dear Roy,
Our variable "chlorophyll count" as is understandable by CF is the
number of individual measurements used to determine a chlorophyll value.

I do need to know what to put at "units" attribute for that variable.
I undestood by the CF convention 1.4 (appendix C) that I have to put
"units="1" as the chlorophyll count is a dimensionless variable...but
the CF checker found it as an error.

I try not to put the Unit attribute ...but again i get an error by che
cf chcker...so.

my question is: what unit shoudl I set for my chlorophyll count variable?

thanks for your help.

cristina

---
Cristina Tronconi
Istituto di Scienze dell'Atmosfera e del Clima - sezione di Roma
Consiglio Nazionale delle Ricerche
Via Fosso del Cavaliere 100
00133 Roma, Italy
Tel:  +39  06  49934342
cell: '39 349 1242954
Fax:  +39  06  20660291
e-mail:   cristina.tronc...@artov.isac.cnr.it--
This message (and any attachments) is for the recipient only NERC
is subject to the Freedom of Information Act 2000 and the contents
of this email and any reply you make may be disclosed by NERC unless
it is exempt from release under the Act. Any material supplied to
NERC may be stored in an electronic records management system.
___
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
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] standard_name modifiers -- units problem

[Lowry, Roy K.]

Hi Cristina,

Looks like my worries were unfounded concerning the meaning of 'count'.  From 
the discussion thread my understanding is that the units you have are OK and 
that the issue is with the CF checker.

Cheers, Roy.

From: cristina.tronc...@artov.isac.cnr.it [cristina.tronc...@artov.isac.cnr.it]
Sent: 26 February 2011 19:30
To: Lowry, Roy K.
Cc: cf-metadata@cgd.ucar.edu
Subject: standard_name modifiers -- units problem

Dear Roy,
Our variable "chlorophyll count" as is understandable by CF is the
number of individual measurements used to determine a chlorophyll value.

I do need to know what to put at "units" attribute for that variable.
I undestood by the CF convention 1.4 (appendix C) that I have to put
"units="1" as the chlorophyll count is a dimensionless variable...but
the CF checker found it as an error.

I try not to put the Unit attribute ...but again i get an error by che
cf chcker...so.

my question is: what unit shoudl I set for my chlorophyll count variable?

thanks for your help.

cristina

---
Cristina Tronconi
Istituto di Scienze dell'Atmosfera e del Clima - sezione di Roma
Consiglio Nazionale delle Ricerche
Via Fosso del Cavaliere 100
00133 Roma, Italy
Tel:  +39  06  49934342
cell: '39 349 1242954
Fax:  +39  06  20660291
e-mail:   cristina.tronc...@artov.isac.cnr.it-- 
This message (and any attachments) is for the recipient only NERC
is subject to the Freedom of Information Act 2000 and the contents
of this email and any reply you make may be disclosed by NERC unless
it is exempt from release under the Act. Any material supplied to
NERC may be stored in an electronic records management system.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] standard_name modifiers -- units problem

[cristina . tronconi]

Dear Roy,
Our variable "chlorophyll count" as is understandable by CF is the  
number of individual measurements used to determine a chlorophyll value.


I do need to know what to put at "units" attribute for that variable.
I undestood by the CF convention 1.4 (appendix C) that I have to put  
"units="1" as the chlorophyll count is a dimensionless variable...but  
the CF checker found it as an error.


I try not to put the Unit attribute ...but again i get an error by che  
cf chcker...so.


my question is: what unit shoudl I set for my chlorophyll count variable?

thanks for your help.

cristina

---
Cristina Tronconi
Istituto di Scienze dell'Atmosfera e del Clima - sezione di Roma
Consiglio Nazionale delle Ricerche
Via Fosso del Cavaliere 100
00133 Roma, Italy
Tel:  +39  06  49934342
cell: '39 349 1242954
Fax:  +39  06  20660291
e-mail:   cristina.tronc...@artov.isac.cnr.it


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] standard_name modifiers

[Jonathan Gregory]

Dear Martin

The case of anomaly is a good use case. It could be indicated by a standard
name modifier, as you say, but I agree with Nan that it should be a specific
one i.e. "anomaly" rather than generic. However in that case we have so far
been adding new standard_names instead of using a modifier, viz

air_pressure_anomaly
air_temperature_anomaly
geopotential_height_anomaly
surface_temperature_anomaly

As you see, we have not so far been flooded with requests for these, even
though in principle it could be relevant for any quantity. Following the
usual pragmatic approach, I would argue that we don't yet need a general
solution for this particular case; we can just add more standard names if
you need some.

Best wishes and happy weekend

Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] standard_name modifiers

[Nan Galbraith]

I agree that it's misleading (even to humans, who might not
be as thorough as some software) to use a common standard
name for a quantity that's not actually the measurement of that
observable, as in your example of a temperature anomaly.

The term "derived_quantity" doesn't seem especially helpful as
a standard name modifier, though; many observed phenomena
(salinity, longwave radiation) are, technically, derived quantities.

In our data sets, for "secondary" variables like temperature differences,
we wouldn't usually supply a standard name at all. That's perfectly legit
in CF, and would prevent users from mistakenly using the data as a
"primary" variable, but it doesn't help make the data discoverable.
For that reason, it could be worthwhile to introduce more standard
name modifiers, e.g. anomaly, even if more attributes are needed to
describe the "meaning" of the data.

Regards -
Nan

On 2/25/11 8:56 AM, Schultz, Martin wrote:

Dear Jonathan,

 I don't quite agree with the implication you derive from : "In general, CF metadata describes what a quantity *is* and not how it was calculated from other quantities."  -- a temperature difference is a temperature, but you don't want to confuse it with a temperature (pun intended). Suppose you have this wonderful search engine that finds out that NOAA, UK Met Office, JMA, ECMWF and many others provide daily fields of sea surface temperatures. Then you load them all and compute a mean value. What happens if the NOAA values are SST anomalies rather than actual temperatures? As far as I can tell, the software would have no way of telling. OK: you can argue this is why we still need humans, but in my view it defeats the GEOSS concept of interoperability. In particular, because it should be avoidable. But perhaps a simple solution yould be to add a standard_name modifier called "derived_quantity" which would mean that it has similar properties (grid, units, etc.) like the 

ori

  ginal, but values should not be compared with the original.

Best,

Martin


It would probably help if we focussed on some real use-cases
where it is essential to provide *systematic* metadata i.e.
which can be processed by programs. It is always possible to
provide descriptive metadata, useful to humans, in
non-standardised attributes such as long_name and history,
and this can explain how the quantity is obtained.

Best wishes

Jonathan





--
***
* Nan Galbraith(508) 289-2444 *
* Upper Ocean Processes GroupMail Stop 29 *
* Woods Hole Oceanographic Institution*
* Woods Hole, MA 02543*
***




___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] standard_name modifiers

[Schultz, Martin]

Dear Jonathan,

I don't quite agree with the implication you derive from : "In general, CF 
metadata describes what a quantity *is* and not how it was calculated from 
other quantities."  -- a temperature difference is a temperature, but you don't 
want to confuse it with a temperature (pun intended). Suppose you have this 
wonderful search engine that finds out that NOAA, UK Met Office, JMA, ECMWF and 
many others provide daily fields of sea surface temperatures. Then you load 
them all and compute a mean value. What happens if the NOAA values are SST 
anomalies rather than actual temperatures? As far as I can tell, the software 
would have no way of telling. OK: you can argue this is why we still need 
humans, but in my view it defeats the GEOSS concept of interoperability. In 
particular, because it should be avoidable. But perhaps a simple solution yould 
be to add a standard_name modifier called "derived_quantity" which would mean 
that it has similar properties (grid, units, etc.) like the ori
 ginal, but values should not be compared with the original.

Best,

Martin


>
> It would probably help if we focussed on some real use-cases
> where it is essential to provide *systematic* metadata i.e.
> which can be processed by programs. It is always possible to
> provide descriptive metadata, useful to humans, in
> non-standardised attributes such as long_name and history,
> and this can explain how the quantity is obtained.
>
> Best wishes
>
> Jonathan
>



Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] standard_name modifiers

[Jonathan Gregory]

Dear Martin

> Take a global model output of temperature, for example. How do you 
> describe temperature differences between this model and another one? The 
> resulting quantity is still an "air_temperature" (OK, actually 
> "air_temperature_difference") with units of "K". Yet, it would be nice to 
> know that this field is a result of differencing two models. "Difference" 
> could be accomodated relatively easily with the standard_name modifier (but 
> how do you describe what has been differenced?). More complicated operations, 
> such as normalized mean bias (X-Y/(X+Y)) will at some point be impossible to 
> maintain through standard_name modifiers, I believe.

Yes, I agree, generalised description like this is a tricky issue. Standard
name modifiers really only work for describing things done with a single
quantity. Cell methods are more powerful because they describe operations on
coordinates too. Although there are cases where it seems like a small step to
extend this to operations which combine variables, I think that could get very
complicated in the end. In general, CF metadata describes what a quantity *is*
and not how it was calculated from other quantities.

It would probably help if we focussed on some real use-cases where it is
essential to provide *systematic* metadata i.e. which can be processed by
programs. It is always possible to provide descriptive metadata, useful to
humans, in non-standardised attributes such as long_name and history, and this
can explain how the quantity is obtained.

Best wishes

Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] standard_name modifiers

[Schultz, Martin]

Dear John,

there is a distinct difference between cell_methods and the kind of 
operators I am talking about (or I misunderstand the cell_methods description): 
cell_methods describe operations that are done with respect to variable 
dimensions (averaging over time and/or lon or lat, etc.). From the CF1.5 
document:
"Each "name: method" pair indicates that for an axis identified by name, the 
cell values representing the field have been determined or derived by the 
specified method."
The "modifier" or "operator" describes operations that are done to the variable 
values themselves without changing the dimensions. Let me clarify:

Take a global model output of temperature, for example. How do you describe 
temperature differences between this model and another one? The resulting 
quantity is still an "air_temperature" (OK, actually 
"air_temperature_difference") with units of "K". Yet, it would be nice to know 
that this field is a result of differencing two models. "Difference" could be 
accomodated relatively easily with the standard_name modifier (but how do you 
describe what has been differenced?). More complicated operations, such as 
normalized mean bias (X-Y/(X+Y)) will at some point be impossible to maintain 
through standard_name modifiers, I believe.

Reading through the CF1.5 description of cell_methods again, I see that 
this is probably the way to go, but one would need to define a way of 
expressing such methods that are not associated with a dimension.  For example, 
this could be done with ":difference", but this might be rather 
clumsy (think of 
"atmosphere_absorption_optical_thickness_due_to_particulate_organic_matter_ambient_aerosol:difference").
 "self:difference" could be another option, with additional information in 
paranthesis (e.g. "self:difference (ERA-interim, CRU)"). Writing only 
"difference" is a third option - however this complicates the syntax again, 
because you parse for colon in some cases but not always.

Cheers,

Martin


> -Original Message-
> From: Jonathan Gregory [mailto:j.m.greg...@reading.ac.uk]
> Sent: Thursday, February 24, 2011 7:08 PM
> To: Schultz, Martin
> Cc: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] standard_name modifiers
>
> Dear Martin
>
> The idea of the modifiers was to provide standard names for
> ancillary data, such as count of obs, standard error, and so
> on. The other kinds of thing you mention, such as means over
> periods and other statistics, can often be described by
> cell_methods, which is more flexible because it refers to the
> dimensions of the data.
>
> Best wishes
>
> Jonathan
>



Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] standard_name modifiers

[Lowry, Roy K.]

Dear Christina,

As this debate unfolds I am coming to the realisation that there might be a 
significant difference between what you mean by 'chlorophyll count' (the 
unmodified reading from a fluorometer analogue-to-digital converter that is a 
function of chlorophyll concentration) and what CF understands by 'chlorophyll 
count' (the number of individual measurements used to determine a chlorophyll 
value).  Am I correct?  If so, apologies for not having realised this sooner.

Cheers, Roy. 

-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu 
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Jonathan Gregory
Sent: 24 February 2011 18:08
To: Schultz, Martin
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] standard_name modifiers

Dear Martin

The idea of the modifiers was to provide standard names for ancillary data,
such as count of obs, standard error, and so on. The other kinds of thing you
mention, such as means over periods and other statistics, can often be
described by cell_methods, which is more flexible because it refers to the
dimensions of the data.

Best wishes

Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
-- 
This message (and any attachments) is for the recipient only NERC
is subject to the Freedom of Information Act 2000 and the contents
of this email and any reply you make may be disclosed by NERC unless
it is exempt from release under the Act. Any material supplied to
NERC may be stored in an electronic records management system.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] standard_name modifiers

[Jonathan Gregory]

Dear Martin

The idea of the modifiers was to provide standard names for ancillary data,
such as count of obs, standard error, and so on. The other kinds of thing you
mention, such as means over periods and other statistics, can often be
described by cell_methods, which is more flexible because it refers to the
dimensions of the data.

Best wishes

Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] standard_name modifiers

[Schultz, Martin]

Dear all,

   perhaps I am not aware of the previous discussions on this issue, but 
reading through the comments about the "count" modifier, I am wondering whether 
the concept of standard_name modifiers is a good solution. Once again, I am 
presently biased towards observational data (ozone time series from stations), 
and I can think of a couple of use cases here. A typical thing to do with obs. 
data is to create a monthly means file from hourly observations. Then we would 
be interested in the mean value, the standard deviation, the number of valid(!) 
data points and potentially other parameters (percentiles, mean of daytime 
values, mean of nighttime values, etc.). Is it practical to include all this in 
pre-defined standard_name modifiers? Or wouldn't it make more sense to define 
some sort of "operator" attribute which describes what has been done to the 
data? In order to be traceable, one would of course have to define the allowed 
operations, but ultimately it may become possible to even define more complex 
formulae which could then describe operations such as differences between a 
model realisation and an ensemble, a normalized mean bias between model and 
observations, a root mean square error, etc.

   For "CF checking" I do see a point though that actually advocates the 
present approach: if I am not mistaken, the the standard_name attribute is the 
only attribute that defines which units a variable should have, so the CF 
checker needs to parse only standard_name to find out if the given units are 
allowed. With a new "operator" attribute one would need to parse another 
attribute (and first check if it exists).

Best regards,

Martin

= Dr. Martin G. Schultz, IEK-8, Forschungszentrum Jülich  =
= D-52425 Jülich, Germany =
= ph: +49 (0)2461 61 2831, fax: +49 (0)2461 61 8131   =
= email: m.schu...@fz-juelich.de  =
= web: http://www.fz-juelich.de/icg/icg-2/m_schultz   =



Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata