Meeting notes
Participants: Gao Chen, Sebastien Villaume, Charles Brock, Rebecca Hornbrook, John Nowak, Dagmar Kubistin, Markus Fiebig, Jörg Klausen, Franziska Stürzl
-
Welcome (5')
-
Approval of minutes (5')
-
Syntax of variable names and tags (Review from last meeting)
(JK) informs about possible changes to the WMDR model. See also: Content model of WIGOS metadata
For observations, the model adopts the O&M standard. To define an observation it provides the categories "Feature of interest" and "Observed property", which we interpret as "Domain" and "Observed variable". Additional information can only be included by parameters as name - value pairs. With codelists for parameters such as the size range, relative humidity etc. a name - value pair would consist of a link to the code list (name) and a link to a certain entry (value). Fundamental changes to the O&M standard (OGC) like the inclusion of a third category for matrix are possible but take years.
Conclusion: The group recommends a normalisation of the vocabulary and to wait until the WMDR model is reworked and adapted, before making important changes to the code tables for observed variables.
Links:
Participants: Gao Chen, Charles Brock, Rebecca Hornbrook, John Nowak, Dagmar Kubistin, Markus Fiebig, Judd Welton, Jörg Klausen, Franziska Stürzl
Minutes (Summary)
-
Welcome (5')
-
Approval of minutes (5')
-
Syntax of variable names (presentation)
The approach to split up information on observed properties into different dimensions (Species/state variable - domain - matrix - size cut-off - ...) requires changes to the WMDR model and therefore cannot be implemented immediately. We propose to use the following syntax as an interim solution:
notation name description domain matrix tags Variables for chemical species x [Molecular formula] ([some names]) in [matrix], [optional: size range] IUPAC: [...], PubChem CID: [...], CAS Number: [...] Atmosphere/Ocean/... Gas phase/Particle phase/Total deposition/... matrix, some other categories Other variables related to matrices y [Property/physical quantity], [optional: size range] useful unambiguous definition Atmosphere/Ocean/... Gas phase/Particle phase/Total deposition/... matrix, some other categories Other variables z variable name useful unambiguous definition Atmosphere/Ocean/... - some categories Examples:
- CH3Cl (methylchloride); path: \Atmosphere\ Gas \Reactive Gas\CH3Cl (methylchloride)
- Chloride (Cl-), PM1; path: \Atmosphere\ Aerosol \Composition\Inorganic anions\Chloride (Cl-), PM1
- Light absorption coefficient, PM1; path: \Atmosphere\Aerosol\Optical properties\Light absorption coefficient, PM1
- C14H10 (anthracene), in air and aerosol; path: \Atmosphere\POPs\PAH\C14H10 (anthracene), in air and aerosol
- Atmospheric pressure; path: \Atmosphere\Pressure\Atmospheric pressure
New solution:
notation name description domain matrix tags i. 280 CH3Cl (methylchloride) in gas phase IUPAC: chloromethane, PubChem CID: 6327, CAS Number: 74-87-3 Atmosphere Gas phase Gas phase ii. 614 Chloride (Cl-) in particle phase, PM1 IUPAC: chloride, PubChem CID: 312, CAS Number: 16887-00-6 Atmosphere Particle phase Particle phase, inorganic anions iii. 316 Light absorption coefficient, PM1 A measure of light attenuation due to absorption by aerosol particles expressed as the Beer-Lambert Law exponent at unit path distance. Atmosphere Particle phase Particle phase, Optical properties iv. 337 C14H10 (anthracene) in aerosol ... Atmosphere Aerosol Aerosol, POPs, PAH v. 216 Atmospheric pressure ... Atmosphere - Pressure -
Progress on issues
-
Ready for FT-2021-2?
-
#275 1-01-01 Addition of gas phase variables
final confirmation of branch needed
-
#112 6-02 Sample treatment (new codelist)
final confirmation of branch needed
-
-
Status?
-
#280 1-01-01 Remove particle size range from variable name (JK)
issue postponed until WMDR model is adapted
-
#270 6-01-01 Creation of a new code table ParticleSizeRange (FS)
inclusion of size ranges "110 μm equivalent" etc.?
-
#263 Aerosol variables and WMDR class modifications required to align with OSCAR requirements
-
#289 1-01-01 Addition of new particle phase variables and variable descriptions
-
-
-
Next meeting: 9 June 2021, 13:00 - 14:30 UTC
Participants: Gao Chen, Charles Brock, Rebecca Hornbrook, John Nowak, Dagmar Kubistin, Markus Fiebig, Judd Welton, Jörg Klausen, Franziska Stürzl
Minutes (Summary)
-
Welcome (5')
-
Approval of minutes (5')
-
Progress on issues
-
#182 1-01-01: distinction between primary and secondary physical particle properties (MF)
(MF) distiction does not make sense, can be left out
(CB), (GC) agree
(JK) decision of the team: distinction should be dropped, issue can be closed
-
#270 6-01-01 Creation of a new code table ParticleSizeRange (FS, GC)
(GC), (JW), (MF) agree to include other entries to the table, so that it can be used for both aerosol and cloud particles.
-
#280 1-01-01 Remove particle size range from variable name (MF, JW, GC)
(GC) and (MF) will provide descriptions for existing variables.
-
#263 Aerosol variables and WMDR class modifications required to align with OSCAR requirements (JW)
(JW) states that changes proposed by (GC) are ok
(JW) "Vertical distribution of properties" is used by us in OSCAR/Surface because there was no better alternative. We will support the migration
(GC) proposal to replace "Effective radius" by "Effective size" to describe both radius and diameter.
(JW) for discovery purposes "Size" is more useful.
(JK) If it is needed for search, "size" should be a tag. It is better to have two variables than be ambiguous.
(CB) and (JW) agree, conclusion: add "Aerosol effective diameter".
(JW) proposes to add other variables for Ångström exponents (will leave a comment in the issue)
(GC) Are the characters "Å" and "ö" ok?
(JK) In the name yes! We are only limited in the notations, otherwise all UTF-8 characters can be used.
-
#275 1-01-01 Addition of variables from WDCGG (RH)
(RH) "E/Z" should be revoved from variable name "C2H2Cl2 ((E/Z)-1,2-dichloroethene)".
(DK) and (RH) will review the proposal and add variables if necessary.
-
#284 1-01-01 Add description to gas phase variables (FS)
(GC) will contact Morgan Silverman about a review of this list.
-
#168 Total carbon variables for codetable 1-01-01.csv (FS, MF)
(JK) assigns (MF) to include a specific proposal with definitions
-
Any other open issues according to Kanban
-
-
Next meeting: 26 May, 2021 14:00-15:00 UTC (wrap-up for FT2021-2)
Participants: Sebastien Villaume, Dagmar Kubistin, Markus Fiebig, Judd Welton, Gao Chen, Rebecca Hornbrook, John Nowak, Anna Milan, Jörg Klausen, Franziska Stürzl
Minutes (Summary)
-
Welcome
-
Approval of minutes
-
Review of Wiki page necessary
- Section "Current organization of variables in the atmospheric domain" is outdated
- Consult project board for priorities of WG-ACV
-
Progress on issues
-
#277 1-06-01 New code list "Domain"
(JK) added definitions to the terms, asks team to review the proposal.
(SV) addresses the problem of overlapping domains, e.g. "Sea surface temperature" fits into both "Atmosphere" and "Ocean" domain.
(JK) Origin of the five WIGOS domains is unclear, the intention was to break up the code list for observed variables into smaller parts. Changing the domains or adding new ones is a fundamental change. Action: Research, where the domains came from and if they can be changed.
(GC) Use "spatial extent" instead of "space" in the definitions, (JK) and (RH) agree.
(RH) proposes to include the term "soil" in the definition of "Terrestrial", to better distinguish this domain from the "Earth" domain.
(JK) will discuss this issue with the TT-WIGOSMD
-
#278 1-06-01 New code list "Matrix"
(JK) added definitions to the terms in the proposal. Action: Include an overview in which domains a matrix is meaningful. For definitions of tags the Wiki page Tags for observed variables was created.
(MF) agrees to the contents of the page in general with a minor correction to the definition of "Particle phase" (Particle: liquid or solid). The term "Aerosol" is correctly defined, but maybe we should avoid the term altogether?!
Action: Review proposal and leave comments in the issue; revise definition of "Particle phase".
-
#275 1-01-01 Addition of variables from WDCGG
(DK) and (RH) assign themseves to the issue.
-
#270 6-01-01 Creation of a new code table ParticleSizeRange
(MF) "PM" always refers to the aerodynamic diameter, so sizes smaller than 1 do not make sense.
Action: review proposal
-
#280 1-01-01 Remove particle size range from variable name
(JK) Hygroscopic growth factor needs to be expanded, the migration needs help from data center
-
#261 Discussion on Gas phase variables -> reminder: revision of variable description and list of tags needed, next step: assign tags to variables
(RH) prefers the terms "N species". The tags "C species", "H species", "O species" might be obsolete. It is less likely that a user searches for e.g. all carbon species.
(GC) suggests to include HxOy as a tag.
(RH) will look into this proposal and consider if the community would use this tag.
(MF) suggests using a IUPAC approach. (JK) counters that the IUPAC system is not necessarily user driven, which the tags should be.
(RH) Is "acid" as a tag enough or should we distinguish between "organic acid" and "inorganic acid"? (DK) The tag "acid" is sufficient.
(RH) suggests to add the tag "Isotopologue".
-
#257 1-01-01 Path structure and tags of Aerosol (particle phase) composition variables -> revision of tags needed
(JK) "Major inorganic components" needs a definition because different users have different understandings. The term "major inorganic components" should be dropped as a tag.
-
-
Oganizational
(JW) management of issues is confusing
(AM) suggests to assign responsibility to one person in the team to improve management
-
Next meeting: 19 May, 12-13:30 UTC
Participants: Sebastien Villaume, Dagmar Kubistin, Markus Fiebig, Judd Welton, Gao Chen, Charles Brock, Rebecca Hornbrook, John Nowak, Anna Milan, Jörg Klausen, Franziska Stürzl
Minutes (Summary)
-
Welcome
-
Approval of minutes
-
Review: new structure of atmosphere vocabulary (tagging approach)
- Matrices and tags
- Consequences for code table ObservedVariablesAtmosphere and representation in OSCAR/Surface
- Discussion (for comments use issue #273)
Conclusions:
- A unique observed variable is defined by the following equation Observerd variable = domain x matrix x species and gets a notation (unique id)
- Tags do not affect the identity of a variable, but represent certain "baskets" in which the variables can be sorted.
- Avoid mix of definitions and tags in the description, no combination of json and csv format in the tables on GitHub
- (AM) recommends a new column for tags on GitHub (instead of paths?) or allow multiple tags for one observed variable; no mix between hierarchy and tags
-
Progress report on issues postponed
- #181 1-01-01: Use of term "aerosol" in observed variable table (MF)
- #257 1-01-01 Path structure of Aerosol (particle phase) composition variables (MF)
- #182 1-01-01: distinction between primary and secondary physical particle properties (MF)
- #270 6-01-01 Creation of a new code table ParticleSizeRange (FS, GC)
Participants: Sebastien Villaume, Dagmar Kubistin, Judd Welton, Gao Chen, Charles Brock, Rebecca Hornbrook, Alex Vermeulen, Jörg Klausen, Franziska Stürzl
Minutes (Summary)
-
Welcome (JK)
(JK) introduces Alex Vermeulen as Chair of WMO GAW SAG on Greenhouse Gases
-
Approval of minutes (all)
-
Vocabulary building
- Example: BODC Vocabulary builder
(JK) BODC vocabulary builder is a useful tool to build terms by combining various elements of a term (e.g. chemical substance, matrix, sample preparation), similar to the approach in WIGOS. WIGOS information model: vocabulary consists of meaningful combinations of "domain" + "variable" as observed variables, listed in the codes registry. The subdomains are not visible in the registry, only in OSCAR/Surface or in the csv files on GitHub)
Our intention is to improve the equation observed variable = domain x subdomain(s) x variable with the constraint to the domain "atmosphere".
(AV) refers to mapping effort made by the working group I-ADOPT (InteroperAble Descriptions of Observable Property Terminology, case statement)
-
Progress report on issues
-
Gas phase variables (RH), (DK):
-
#261 Discussion on Gas phase variables
(GC) mentions grouping in Global Change Master Directory (GCMD) Keywords and GCMD Keyword Viewer
Issue: Identification of constituents; flexibility is important, users need to be able to find the same variable using different names. One possible solution is to have CAS numbers as unique identifiers.
(RH) Goals: harmonise and normalise vocabulary to improve the searchability and usability for the end user.
(DK) searchability: focus on the user, who defines how he is looking for a variable
(RH) table is a living document, people continuously need new variables, driven by what is measured
(JK) addition of new terms is possible - with a time lag of approx. 6 months due to the fast track procedure. What we need to resolve today: elements in the path, that have been put in question, namely the subdivision into "Greenhouse Gas", "Reactive Gas", "Ozone" and "Other Gas" with their respective subgroups. (Purpose: improve searchability by breaking down a long list of species into smaller parts)
(AV) The category "Reactive Gases" is arbitrary - reactivty depends on the time scale... Subdividions only represent the SAG groups on an organisational level and support the search for variables.
(JK) Revision of paths is necessary if the distinction between "Greenhouse Gas" and "Reactive Gas" is not meaningful. Alternative approach?
(GC), (CB) in favour of introducing tags instead of a fixed hierarchy
(JK) Consequence is a radical change from a tree structure to a "skos-like" structure, which is significantly more challenging in terms of implementation. We need a decision considering costs and benefits!
(AV) SAG is not against changing the groups. From an architectural point of view, the WMO codes registry should allow the implementation of skos concepts via sparql to enable tagging.
(JK) Even though the tool allows it, changes in the codes registry (hosted by UK Met Office) are not to be expected soon. At the moment, we can only work on name, notation and description.
element purpose/structure notation unique id across all domains name (= label) chemical formula (some names) description (= definition) IUPAC: ..., PubChem CID: ..., CAS Number: ... (not yet included) (AV) proposes to include tags in the description in a fixed structure, e.g. encoded in json for harvesting information.
(JK) Action items: Explore the possibility of adding tags to the description and how to deal with that in OSCAR, establish and review a vocabulary of terms, which can also be growing in the future.
(RH), (DK) are assigened on GitHub to bring the issue forward considering our results from today's discussion.
-
#253 1-01-01 Observed variables (atmosphere), corrections, confirmation needed
(DK) will take a look at it.
-
-
Variables and methods for remote sensing (JW)
-
#258 1-01-01 Inclusion of aerosol typing from remote sensing
(JW) Purpose: Introduce variables for aerosol types into the code list. In the communities there is no consensus regarding names and definitions.
(JK) What is the actual endpoint of the observation, "Aerosol Type" or a specific type e.g. "Aerosol Type Marine"? If you are making an observation of aerosol types resulting in a time series with certain fractions of smoke, dust, marine, then I would only add "Aerosol Type" as an Observed variable.
(JW) Aerosol types are retrieved from remote sensing by considering optical parameters. Adding "Aerosol Type" to the code list could work.
(JK) assigns (JW) to review the updates in the branch.
-
#263 Aerosol variables and WMDR class modifications required to align with OSCAR requirements
OSCAR Requirements variables: https://www.wmo-sat.info/oscar/variables
(JW) Issue is closely related to the issues set up by Markus Fiebig (#173, #181). There are too many information in the variable name (modifiers, layer); as a data provider it is difficult to determine which variable to use.
(GC) Variable "Aerosol Effective Radius" (6.) should be renamed to "Aerosol Effective Size" (less specific)
(JK) agrees that "Vertical Distribution of Properties" (5.) should be removed (or provided with a meaningful definition, if possible). Regarding OSCAR Requirements, there will never be a requirement for all elements in the WIGOS code lists for Observed variables. The OSCAR Requirements variables are a subset of the Observed variables.
(JW) stresses the difficulty for a user to find a suitable variable if they are not defined and do not have an entry in the requirements table.
(JK) Observed layer (new table proposed in #185) has some overlap to the existing table "Geometry" with entries "Point", "Line", "Area", "Volume", "Vertical profile", "Total column". The observed layer could be an additional attribute indicating where the measurement was made.
-
#266 Lidar in Measurement/Observing Method (atmosphere)
(JK) Issue is caused by path structure of method table intended to simplify the search for methods in OSCAR/Surface.
(JW) From a data provider's perspective the grouping makes the choice of a method more difficult.
further discussion postponed to next meeting
-
-
Participants: Sebastien Villaume, Judd Welton, Gao Chen, Charles Brock, John Nowak, Rebecca Hornbrook, Markus Fiebig, Richard Eckman, Jörg Klausen, Franziska Stürzl
Minutes (Summary)
-
Welcome (JK)
-
Progress report on issues
-
1-01-01: Use of term "aerosol" in observed variable table
(MF) Introduction to the purpose of this issue: The term "aerosol" is defined as a system of gas and particle phase. The variables with the path \Atmosphere\Aerosol refer only to the particle phase. Therefore the subdomain should be names "Particle phase" or "Particulate matter" instead.
(JW) proposes to use "Aerosol particle". For remote sensing observations the term "particle phase" is too specific as the particles itself cannot be measured with these observing method.
(JK) To define an observed variable, what matters is the intention of the observation.
(MF) Possible compromise: Rename the paths to "Particle phase", but keep the term "aerosol" in the variable name, where it makes sense. E.g. \Atmosphere\Particle phase\Optical properties\Aerosol optical depth
(JK) Decision to suggest "Particle phase" to the Task Team, (MF) will update the issue.
-
1-01-01 Path structure of Aerosol (particle phase) composition variables
(JK) Discussion about subdomain_3 in the branch \Atmosphere\Particle phase\Composition..., the intention behind the categories such as "Inorganic anions", "Inorganic cations" etc. was to facilitate the search for variables in the OSCAR/Surface application, but also to provide context about the intention behind an observation.
(MF) The separation in subdomain_3 is ambiguous. If the categories are supposed to help with the search, it needs to be unique. Remark, that the ambiguity is already there in subdomain_1, because many variables under \Atmosphere\Particle phase also belong into the \Atmosphere\Precipitation branch.
(GC) stresses the importance of having variable descriptions, because the variable name alone cannot include all information.
(MF) Path structure is the attempt to create an ontology, which is a difficult effort. The problem is the strict hierarchy, because there are many variables, which belong into more than one subdomain. That leads to an overcrowded code list, if a variable is included multiple times with all possible paths. It is better to consider creating separate code lists for subdomains.
(JK) Clarification of terms (subdomain_1): "Gas" and "Aerosol"/"Particle phase" refer to constituents IN the atmosphere,"Total atmospheric deposition" variables describe particles in the atmosphere, which accumulate on a surface. A variable like "Ammonium" can appear in "Particle Phase", "Total atmospheric deposition" and "Precipitation". It is one variable, but it needs to be combined with a specific subdomain to describe an observation properly (variable = biogeochemical species or physical quantity, observed variable = domain x subdomain(s) x variable).
(GC) Approach: Subdomains as attributes coming from a fixed codelist (compare Atmospheric Composition Variable Standard Name Recommendations)
(JK) leads the focus back to the original issue: Are categories like "Inorganic anions" etc. an important concept or can it be dropped (subdomain_3)? Do we need to sort particle phase variables into "Composition", "Optical properties" and "Physical properties" (subdomain_2)?
(MF),(GC) agree, that subdomain_3 is unneccessary.
(JK) Consequences for the practical use in OSCAR/Surface (link to the application): Without subdomain_3, the variable tree will have more than 100 endpoints under Atmosphere -> Particle phase -> Composition.
(RH),(MF) If a cateorisation is ambiguous or too difficult to make, a longer list is preferable.
(JW) The same issue applies to the category "Physical properties", the discussion can be extend to subdomain_3 under "Physical properties - primary".
-
1-01-01: distinction between primary and secondary physical particle properties
(JK) We need specific proposals, (MF) will update the issues #181, #257 and #182.
-
1-01-01 additional variables (mostly originating from EBAS), postponed
-
1-01-01 Inclusion of aerosol typing from remote sensing
(JW) Issue is an approach to add "Aerosol types" such as "Smoke", "Dust", "Sea Salt" etc. to the codelist and find a way to include physical properties retrieved from remote sensing (variables which are inferred from optical properties).
(JK) We need suggestions for a vocabulary and where to place this grouping. (JW) should develop a proposal including a list of variables.
(JW) Related issue: The variable "Aerosol effective radius" is sorted into the subdomain "Physical properties", but it is retrieved from optical properties and should belong to this subdomain.
(CB), (JK) object, because the radius is in fact a physical property.
(MF) The retrieval from optical properties is an information on the observing method and should not be stored in the variable name.
-
Difference between code lists and domains
(JK) Domains and subdomains are firstly a way to organise the code lists (see variable tree in OSCAR/Surface). If we establish code lists of subdomains, we create a new vocabulary, that needs to be agreed on, including definitions how elements of the codelists can be combined (consider CF as a combination of many code lists). Therefore the vocabulary can be interpreted as a multidimensional matrix. If all combinations of subdomains and variables are allowed, every matrix entry can be populated. If only useful combination are made possible, we get a sparse matrix.
-
6-02 Sample treatment (new codelist) postponed
-
Issues for gas variables needed?
(RH) has prepared a list of questions and will open an issue for discussion (see: #261)
-
-
Assign responsible persons to specify the requirements for describing the following aspects of an observation:
- particle size, sizing methodology
- relative humidity
- temperature
- pressure
- wave length/frequency
(JK) We need to advance this as soon as possible... Deadline for proposals: June, 24 (see: Fast Track Schedule)
-
Next meeting in two weeks (31 March, 14 UTC) on MS Teams
Participants: Sebastien Villaume, Dagmar Kubistin, Gao Chen, Charles Brock, Judd Welton, John Nowak, Rebecca Hornbrook, Markus Fiebig, Jörg Klausen, Franziska Stürzl
Agenda:
-
Presentation on C-14 and what attributes are used in BUFR to describe an observation (SV) + discussion (all)
-
Review notes: Observations, observed variables and sampling procedures (JK, FS)
- definitions of elements to describe observations (WIGOS metadata information model)
- proposals for particle size
- Review tree structure of observed variables (overview, state 11/2020) - postponed
-
Definitions of carbon variables (elemental_carbon, equivalent_black_carbon, equivalent_black_carbon_mass, total_carbon) (https://github.com/wmo-im/wmds/issues/168) - postponed
Participants: Sebastien Villaume, Dagmar Kubistin, Gao Chen, John Nowak, Rebecca Hornbrook, Markus Fiebig, Jörg Klausen, Franziska Stürzl
Agenda:
Welcome
Introduction of the participants (10’)
Short explanation of the WIGOS model (jkl 5’)
Goals of this group (stf 5’)
-
Improve vocabulary for atmospheric composition variables (including a review of the path structure, overview, state 11/2020)
-
Acceptance in other communities
-
Ensure interoperability with other vocabularies
Deficiencies in the WIGOS vocabulary for atmospheric variables (stf 5’)
- Combination observed variable + attributes in the variable name
- Variables without descriptions/definitions
WIGOS vocabulary in relation to other vocabularies (stf 5’)
- CF Convention Standard Names, Common Code Table C-14 etc.
Discussion and next steps (30’)
- Standard conditions (RH, T, P,…?) as code lists or by numbers?
- Assign experts to the relevant issues
- Next meeting (17.02.21?)
Minutes TT-WIGOSMD WG-ACV-1
(JK) Welcome to all participants to the first meeting of WG-ACV, an ad-hoc group of experts supposed to advise the TT-WIGOSMD on the vocabulary for atmospheric composition measurements. The objective is to improve the vocabulary used in the WIGOS metadata standard and, where necessary, the standard itself, so that it becomes more useful for the wider community. Note that the proposals by this group should not only work for atmospheric composition, but essentially all observations in the scope of WIGOS.
(FS) Previous discussions with Gao and Markus lead to the conclusion that attributes should be removed from the variable names and stored in a different way. It is our intention to normalise the table, and connect variables with more information to describe an observation by adding attributes from external code lists. The following definitions are suggested to foster a common understanding of terms:
| Term | Definition |
|---|---|
| Observed variable | a biogeochemical species or physical quantity and an endpoint in a path (providing context but not a description of process of observation) |
| Process of observation | procedures involved in making an observation or measurement that may impact the result. Such procedures may include a specific observing methodology, conditions of sampling and processing the measurand etc. that may be viewed as characteristic attributes of an observation. |
| Observation | Observed variable x process of observation x geometry of observation |
Examples:
- CO2 x dry air
- Mg++ x PM2.5, 40% RH, 20°C, 1013 hPa
- Scattering coefficient x PM10, 40% RH, 20°C, 1013 hPa, 525nm
Characteristic attributes identified thus far that are at least relevant for aerosol observations:
- size range,
- pressure, temperature, humidity,
- wave length (range?)
(SV) The Common Code Table C-14 specifies only chemical species. Information on size range, wave length etc. come from other tables. Improving the communication between the team for C-14 and the WIGOS team will be appreciated and a benefit to both.
(MF) A generic approach for attributes (attribute category) is preferable, such as adding attributes as name-value pairs. This would avoid the problem that new attributes need to be added constantly. Idea: (attribute type, attribute value) with a table for attribute types.
(JK) This is a technical issue. First of all, we need to be concerned with which attributes are important. Another important aspect is the realisation in the application. This leads to questions such as: How would you like to see attributes in a station report? What does this mean for the search function? The model has the objective to define a metadata standard, which can document observations for adequate use of observational data now and in the future. A name-value approach is technically possible (in the schema), but contradicts the idea of a standard, if there are no limitations.
(GC) The change from "Aerosol" to "Particle phase" is acceptable. Another important issue is the structure of the variables, which is too detailed.
(JK) The structure of the variable tree is based on the way the GAW program was traditionally organized. The organisation of the variable structure can be changed, if the community thinks it needs to be changed!
(MF) The number of levels in the variable tree should be limited, currently it seems to be overly structured.
Actions
- Presentation on C-14 and what attributes are used in BUFR to describe an observation (SV, the next meeting)
- Review definitions proposed above and improve if needed (all, for approval at next meeting)
- Proposal for distinct attributes needed to meaningfully describe and group observations, e.g. standard conditions (stable or variable) and how to include them in the WIGOS metadata model (FS, JK, for discussion at next meeting)
Next meeting Feb 17, 15 - 16 UTC+1
Participants: Gao Chen, Jörg Klausen, Franziska Stürzl
Observed variable in WIGOS Metadata Standard
Definition: “Variable indended to be measured, observed or derived, including the biogeophysical context” [Guide to the WMO Integrated Global Observing System]
Currently the codelist for for observed vaiables (atmosphere) (table 1-01-01) is a mixture of constituents and constituents + certain conditions. Possible combinations of variables and observing conditions leads to a long list of observed variables.
Example: The variable “\Atmosphere\Aerosol\Composition\Inorganic anions\Chloride (Cl-), PM1” consists of the name of the constituents itself: Chloride (Cl-) and the size cut-off PM1 as an attribute.
Constituent/physical quantity + Size range + reference conditions (humidity, temperature, pressure)
The code list for observed variables should be reduced to contain only the constituents. Size range and reference conditions are stored separately. The proposed approach in the issues (#111, #112) needs to be reviewed. Idea: Create a new code table for size ranges, information on humidity, temperature and pressure should be expressed numerically without a code table.
Approach for aerosol variables in the Atmospheric Composition Variable Standard Name Recommendations
Source: https://www-air.larc.nasa.gov/missions/etc/AtmosphericCompositionVariableStandardNames.pdf
Standard Name = MeasurementCategory_CoreName_MeasurementMode_DescriptiveAttributes
The “CoreName” represents the constituent, while information on the size range and other conditions are provided as “DescriptiveAttributes”. Depending on the “MeasurementCategory” there are five tables for “DescriptiveAttributes”: Relative humidity, sizing technique, size range, wave length and reporting attributes.
- Size ranges (Table 4.3.3)
| SizeRange | Description |
|---|---|
| Nucl | Nucleation-mode aerosols: 0.001-0.1 μm diameter |
| Accu | Accumulation-mode aerosols: 0.1-1 μm diameter |
| Coarse | Coarse-mode aerosols: greater than 1 μm diameter |
| Bulk | No distinction in size of particle being measured |
| PM1 | Submicron aerosols: less than 1 μm diameter |
| PMx | Particles with diameter under X μm diameter |
| XtoY | Size Range from X to Y, e.g., NucltoAccu |
Nucl + Accu = PM1
A similar code table needs to be implemented in WIGOS (concrete proposal required!), including the following entries.
PMx: PM2.5, PM10
XtoY: PM10toPM1, PM10toPM2.5
- Relative humidity (Table 4.3.1)
| MeasurementRH | Description |
|---|---|
| RHd | Reduced relative humidity in the sampling system, typically less than 40 % |
| RHa | Relative humidity at ambient conditions |
| RHsp | Sampling system relative humidity at specified level |
| None | Not applicable to variable |
This is similar to the distiction between “ambient” and “heated” in the proposed table for the sampling procedure (#111). It is preferred to be able to give a numeric value specifying the relative humidity.
- Sizing technique (Table 4.3.2)
It needs to be determined whether these attributes are necessary in WIGOS.
Actions:
- create proposal for a size range table
- determine other critical issues: variables for mixtures, treatment of other modifiers (not in the context of aerosols)
Participants: Markus Fiebig, Jörg Klausen, Franziska Stürzl
Results
Semantic inconsistency in aerosol vocabulary
Definition: Aerosol: gas phase + particle phase (liquid or solid)
Therefore the distinction between \Atmosphere\Gas and \Atmosphere\Aerosol is semantically incorrect. It was proposed to replace the term "Aerosol" by "Particle phase" (see issue #181).
Modifiers currently in use in table 1-01-01 are ambiguous: "total aerosol", meaning “without size cut-off” -> replace by "TSP" ("total suspended particles" "total aerosol", meaning “gas and particle phase” -> replace by "gas + particle phase" (similar to "in air and aerosol") To do: identify how variables are used in OSCAR (establish list of stations, with last update and by whom)
Systematic approach for modifiers
Modifiers connect variable names with information about reference conditions and size fractions.
Issue: The use of modifiers in table 1-01-01 is not ideal as it leads to an unnecessarily long list of variables, if all possible combinations are included.
Proposal: Separate modifiers from variable names (see issue #173). Review elements proposed for new table "Sampling procedure" (Issue #111) that currently combines size cut off + sampling condition. Review elements proposed for new table "Sample treatment" (Issue #112). Establish new elements for reference conditions (referencePressure, referenceTemperature, referenceHumidity) for use in DataTypes ‘Sampling’ and ‘Reporting’. This involves an extension of the WMDR model (!).
Action:
- Review issues #111, #112. Postpone to FT-2021-2
- Create new issue for additional elements to describe reference conditions. Determine if these should be code lists or ‘free text’. For example for referenceTemperature, a code table could include elements ambient, heated, 20°C, 25°C, 0°C.
[A posteriori considerations] Side effects: The search filter of OSCAR/Surface does not include the possibility to select observations/stations based on any particular size-cutoff or reference conditions. Thus, if these are removed from the variable name, any search on the (new) variables would return a mix of specific observations. A challenge is how OSCAR/Surface can convey information on these details to the user even in a station report. An observation is defined in the WMDS as a combination of observing facility + observed variable + geometry of observation. This is also how they are implemented in the application. Details like size-cutoff and reference conditions would be defined on the level of deployment, but these details are not presently shown in the sub-headings. A user-friendly solution for this needs to be found in the application (and related CRs be prioritized …).
Introduction: presentation slides