Sorry for the relayed reply.
Replacing the one "in" by "as" doesn't sound correct. Doesn't need the
medium "in_air" be located in the end of the standard name?
Maybe the suggestion
mass_concentration_of_particulate_ammonium_in_air
isn't that bad at all. We can extend it by pm10 as follows:
mass_concentration_of_particulate_ammonium_in_pm10_in_air
In this extension we have, again, the ambiguity -- but at least not in
the non-extended version.
Or it would be resolved via
mass_concentration_of_pm10_ammonium_in_air
What do you think?
Cheers, Daniel
On 08.01.2018 17:57, Jonathan Gregory wrote:
Dear Daniel and Markus
I agree that "aerosol" and "in air" is tautological, but I think it helps
recognition of the name to include "aerosol". We use that in many names. The
problem is the ambiguity arising from the two "in"s! We could rearrange these
names to follow a new pattern
mass_concentration_in_air_of_ammonium_in_dry_aerosol_particles
The second "in" could perhaps be "as" in this constriction. What do you think?
Cheer
Jonathan
----- Forwarded message from Daniel Neumann <[email protected]>
-----
Date: Mon, 8 Jan 2018 09:41:44 +0100
From: Daniel Neumann <[email protected]>
To: [email protected]
Subject: Re: [CF-metadata] Fwd: Re: Clarifying standard names for
'mass_concentration_of_*_dry_aerosol_particles'
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Thunderbird/52.5.0
Dear Markus and Jonathan,
I fully agree with Markus with respect to having a structure that is
expandable by "pm10" or similar size descriptors.
I would rather drop "aerosol" and keep "in_air". The reason is that
we define the concentration of "ammonium in dry particles" (mass) in
"air" (per volume). This is also suggested by
http://cfconventions.org/Data/cf-standard-names/docs/guidelines.html#medium
Using "mass_concentration_of_ammonium_in_dry_aerosol_particles"
might be miss-interpreted as the concentration of "ammonium" in "dry
aerosol_particles" (per volume or per mass) - and not in air.
I also see that
mass_concentration_of_ammonium_in_dry_particles_in_air
is not ambiguous because it might mean
concentration of "ammonium in dry particles" in "air".
or
concentration of "ammonium" in "dry particles in per".
However,
mass_concentration_of_particulate_ammonium_in_air
is lacking the expandability by "pm10" (or whatever).
Regards,
Daniel
On 05.01.2018 09:53, Markus Fiebig wrote:
Dear Jonathan and Daniel,
just to make an attempt to throw in my 5 cents here:
By definition, the term "aerosol" already means the system of the particles
together with their carrier gas which, in this context of the atmosphere, is
air. Thus, "aerosol_particles_in_air" includes the air twice. We may consider
simply to omit the "in_air", and would end up with:
mass_concentration_of_ammonium_in_dry_aerosol_particles
That way, we'd make clear that only the particle phase is meant, but leave the
option open for further additions such as "pm10", e.g.
mass_concentration_of_ammonium_in_pm10_dry_aerosol_particles.
Best regards,
Markus
Am 04.01.2018 um 17:44 schrieb Jonathan Gregory:
Dear Daniel
I see. So the new names would be of the form
mass_concentration_of_ammonium_in_dry_aerosol_particles_in_air
I think that might be liable to misunderstanding. It could mean the mass
concentration of the ammonium within the aerosol particles, rather than
within the air. Your earlier suggestion
mass_concentration_of_particulate_ammonium_in_air
does not have that drawback.
Best wishes
Jonathan
----- Forwarded message from Daniel Neumann <[email protected]>
-----
Date: Wed, 3 Jan 2018 22:46:55 +0100
From: Daniel Neumann <[email protected]>
To: [email protected]
Subject: Re: [CF-metadata] Fwd: Re: Clarifying standard names for
'mass_concentration_of_*_dry_aerosol_particles'
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Thunderbird/52.5.0
Dear Jonathan,
OK. If experts are unanimous in their conviction that the existing names will
never be needed for the meaning that they appear to have, I agree that they
should become aliases of the new names, which convey the correct meaning.
I'm sure this change could be made.
Great.
Alison Pamment is in charge of the updates
as you know and I expect she will consider as it soon as she has time. I think
that a complete list of the new and old names would be useful - that may
already be in one of your emails, perhaps.
I didn't include a full list yet. I will create one and send it
around the next days.
After reading one of the past mailing list posts again and talking
to a former colleague: it might be better to just include an "_in_"
between "X" and "dry_aerosol_particles" in the new names (and maybe
remove aerosol) instead of creating names like
"...particulate_X_in_air". This first version with "_in_" is better
expandable, when particle size fractions like PM10 should be
considered in future (like
"..._X_in_PM10_dry_aerosol_particles_in_air").
Thank you very much.
Best,
Daniel
Best wishes and thanks
Jonathan
----- Forwarded message from Daniel Neumann <[email protected]>
-----
Date: Wed, 3 Jan 2018 17:07:45 +0100
From: Daniel Neumann <[email protected]>
To: [email protected]
Subject: Re: [CF-metadata] Clarifying standard names for
'mass_concentration_of_*_dry_aerosol_particles'
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Thunderbird/52.5.0
Dear Jonathan,
I understand. That's tricky, [...]
Yes :-) .
We could define apple to mean orange in
future, for the sake of the existing datasets,
but only if we are certain that no-one will
ever want to talk about apples.
I am not aware of any situation in which someone actually meant to
talk about apples. Markus Fiebig from the World Data Centre for
Aerosols wrote the same
(http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2017/059588.html).
I talked to two former colleagues, who confirmed it as well.
Therefore, it is quite save to assume that nobody talks about
apples.
We could just define and start using the new names,
and be aware that the CMIP5 datasets used the
wrong names (because the CF process somehow
made a mistake), without defining aliases. Would
that be acceptable?
With respect to my personal usage of the respective standard names I
am fine with just defining new standard names. I also see that it is
the simplest solution for the moment considering the work effort
needed to additionally define aliases.
But, we might run into trouble (and cause confusion), if both
standard names - apple and orange - are used to describe oranges.
People, who used "apple" in the past, probably keep using "apple" to
describe oranges because they are not aware of the changes. People
who look up standard names for their new data sets might also end up
with "apple" for describing an orange if "apple" is not marked as
deprecated. Also people comparing data sets following the old and
the new conventions (e.g. CMIP5 and CMIP6) might not be aware of
this discussion. Hence, I would prefer to define aliases.
Would it be feasible with respect to the required work, to define
aliases for all the ambiguous standard names? How could I support
this process? There seem to be 100 to 110 standard names involved:
- atmosphere_mass_content_of_X_dry_aerosol_particles (15)
- tendency_of_atmosphere_mass_content_of_X_dry_aerosol_particles*
(78, maybe less)
- mass_concentration_of_X_dry_aerosol_particles_in_air (15)
- tendency_of_mass_concentration_of_X_dry_aerosol_particles_in_air (1)
Best,
Daniel
On 03.01.2018 14:40, Jonathan Gregory wrote:
Dear Daniel
Is it feasible to rename all affected standard names?
It would be feasible (using aliases) but is it necessary? It seems to me that
your question has identified that there should be a distinction between e.g.
mass_concentration_of_particulate_X_in_air
and
mass_concentration_of_X_dry_aerosol_particles_in_air
for X=ammonium etc. These are different quantities: the former refers to the
mass of ammonium only, the latter to the dry mass of the aerosol of that type.
That is, we need new names for CMIP6, not aliases.
Yes, there should be a distinction between both standard names.
However, the latter name has been used as synonym for the first name
up till now (e.g. in CMIP5 or in a data set I published recently).
Additionally, the latter name has no real application - at least I
am not aware of an application (neither for model nor for
measurement data). Therefore, it might be reasonable for backward
compatibility to use aliases.
I understand. That's tricky, because we've established that the second name
is a valid concept but not correct. When we use aliases, it's because we've
decided on a clearer, more consistent or more precise formulation of the
name, but in this case, it seemed that we called something an apple when
it ought to have been called an orange. We could define apple to mean orange
in future, for the sake of the existing datasets, but only if we are certain
that no-one will ever want to talk about apples.
We could just define and start using the new names, and be aware that the
CMIP5 datasets used the wrong names (because the CF process somehow made a
mistake), without defining aliases. Would that be acceptable?
Best wishes
Jonathan
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
----- End forwarded message -----
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
----- End forwarded message -----
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
Dr. Markus Fiebig
Senior Scientist
Dept. Atmospheric and Climate Research (ATMOS)
Norwegian Institute for Air Research (NILU)
P.O. Box 100
N-2027 Kjeller
Norway
Tel.: +47 6389-8235
Fax : +47 6389-8050
e-mail: [email protected]
skype: markus.fiebig
P Please consider the environment before printing this email and attachments
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
Daniel Neumann
Leibniz Institute for Baltic Sea Research Warnemuende
Physical Oceanography and Instrumentation
Seestrasse 15
18119 Rostock
Germany
phone: +49-381-5197-287
fax: +49-381-5197-114 or 440
e-mail: [email protected]
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
----- End forwarded message -----
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
Daniel Neumann
Leibniz Institute for Baltic Sea Research Warnemuende
Physical Oceanography and Instrumentation
Seestrasse 15
18119 Rostock
Germany
phone: +49-381-5197-287
fax: +49-381-5197-114 or 440
e-mail: [email protected]
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
