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 <daniel.neumann at io-warnemuende.de> -----
> Date: Wed, 3 Jan 2018 22:46:55 +0100
> From: Daniel Neumann <daniel.neumann at io-warnemuende.de>
> To: cf-metadata at cgd.ucar.edu
> 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 <daniel.neumann at io-warnemuende.de> -----
> >
> >>Date: Wed, 3 Jan 2018 17:07:45 +0100
> >>From: Daniel Neumann <daniel.neumann at io-warnemuende.de>
> >>To: cf-metadata at cgd.ucar.edu
> >>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
> >>>CF-metadata at cgd.ucar.edu
> >>>http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >>_______________________________________________
> >>CF-metadata mailing list
> >>CF-metadata at cgd.ucar.edu
> >>http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >----- End forwarded message -----
> >_______________________________________________
> >CF-metadata mailing list
> >CF-metadata at cgd.ucar.edu
> >http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
----- End forwarded message -----
Received on Thu Jan 04 2018 - 09:44:05 GMT
