⇐ ⇒

[CF-metadata] Expanding the standard_name metadata (Jonathan Gregory)

From: Schultz, Martin <m.schultz>
Date: Tue, 11 Sep 2012 08:50:43 +0000

Dear Jonathan,

      thanks for your encouraging mail and the specific questions. Please find my reply below:

* What if there is more than one compound involved in a standard name? This could be the case with the existing construction using expressed_as, and you can probably imagine better than me other situations where standard_names might want to name more than one species.

   According to my understanding, these names will still refer to one particular "compound" (or "species" if you like). "Nitrogen_dioxide_expresses_as_nitrogen" is still the same as "nitrogen_dioxide", only that the mass units are given relative to "N" rather than "NO2". I cannot think of a good example where you will indeed find more than one compound name in the standard_name and where you actually aim at pointing to more than one compound at the same time. An example like "photolysis_frequency_of_nitrogen_trioxide_decomposing_into_nitrogen_dioxide_and_atomic_oxygen" (hypothetical example at present) lists 3 compounds, but it is not the compound that is at the center here, but rather the rate (or "frequency"), so in this case I would argue not to include a "compound_name" tag.

* Is it specifically only compounds that you want to identify, that is, excluding elements, lumped groups of components, ions or other chemical species? In my draft lexicon, I have a category "species". This includes all chemical species, but also biological species and some other things such as aerosol and grapel. That's because they appear in similarly patterened standard_names. Do we need to draw a semantic distinction? That would increase the number of standard_name patterns.

This is indeed a tough decision. Without having thought through this in all detail, my gut feeling tells me that it might be more useful to distinguish between fields or applications here and adopt a rather cautious approach when adding such tags. Otherwise we will soon end up in a similar situation where the tags are so broad that they cannot be parsed automatically, and we will invent yet another level of classification. What I have in mind would be an application that would lexically parse the standard_name table and then can use such information to offer "informed choices" to the user. For example, you create a plot of ozone concentrations (sorry, that is "mole_fraction_of_ozone_in_air"), and the program would then tell you which other variables about ozone are in the dataset (or available from some web service). So far, this should also work if, for example, marine biological species were labeled by the same token. But if you want to make the relations one level bigger and get suggestions for "other rel
evant atmospheric chemical compounds", then the marine bacteriae, algae, fish and mammals would literally flood the system.

     As to "aerosol" and "graupel", this will require some more discussion, because aerosol is seen by some also as a medium, rather than a compound. I am not sure at present which concept would be more meaningful for these.

Best regards,

Martin



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

Kennen Sie schon unsere app? http://www.fz-juelich.de/app
Received on Tue Sep 11 2012 - 02:50:43 BST

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:41 BST

⇐ ⇒