Hi Roy, I can see how that might work. However, I still think it would still be useful to have a clearly structured list as an intermediate step.
After posting the email it occurred to me that it may be better to have such a list either as part of the conformance document or as an additional list posted in the CF Standard Name page (http://cfconventions.org/standard-names.html) rather than adding it to the convention document itself, regards, Martin ________________________________ From: Lowry, Roy K. [r...@bodc.ac.uk] Sent: 13 July 2016 19:25 To: Juckes, Martin (STFC,RAL,RALSP); cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] Recording requirements expressed in standard name definitions Hi Martin, NVS delivers in RDF, so the knowledge would have to be served in the form of triples describing required relationships between Standard Names, such as: area_fraction requires area_type or between Standard Names and other CF controlled vocabularies in NVS like cell methods. I'll suggest spinning up a project to investigate what is possible and serve some examples. Cheers, Roy. Please note that I partially retired on 01/11/2015. I am now only working 7.5 hours a week and can only guarantee e-mail response on Wednesdays, my day in the office. All vocabulary queries should be sent to enquir...@bodc.ac.uk. Please also use this e-mail if your requirement is urgent. ________________________________ From: martin.juc...@stfc.ac.uk <martin.juc...@stfc.ac.uk> Sent: 13 July 2016 16:36 To: Lowry, Roy K.; cf-metadata@cgd.ucar.edu Subject: RE: [CF-metadata] Recording requirements expressed in standard name definitions Dear Roy, Having the constraints expressed in a machine readable way in the NVS sounds good in principle, but do you have a clear idea about how to make it work in practise? The constraints described in ticket 151 are quite complex, so I'm not sure how they would be expressed. e.g. Either: var.type == string AND var.values in standard_region_list Or: flag_values, flag_meanings in var.attributes AND flag_meanings.values in standard_region_list AND var.type == flag_values.type But as the above text is just something I made up now, it would take quite a lot of work, I expect, to get a reliable parsing algorithm. regards, Martin ________________________________________ From: Lowry, Roy K. [r...@bodc.ac.uk] Sent: 13 July 2016 09:38 To: Juckes, Martin (STFC,RAL,RALSP); cf-metadata@cgd.ucar.edu Subject: RE: [CF-metadata] Recording requirements expressed in standard name definitions Dear Martin, This sounds an excellent idea. What do you thinks of the idea of building the knowledge into NVS to make it accessible in machine-readable form and so the requirements could be enforced by the CF checker? Cheers, Roy. -----Original Message----- From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of martin.juc...@stfc.ac.uk Sent: 07 July 2016 12:01 To: cf-metadata@cgd.ucar.edu Subject: [CF-metadata] Recording requirements expressed in standard name definitions Dear All, in connection with ticket 151 (http://cf-trac.llnl.gov/trac/ticket/151) I had proposed a section in appendix B listing standard names whose definitions impose additional constraints on variable attributes etc. Jonathan convinced me that ticket 151 was not the right place for this. The proposal for this new section was motivated by the fact that standard name descriptions cannot include examples or markup, and the specification of the rules is not as clear as in the convention text. It also appears that the rules are not checked by the CF checker (at least not the few that I have looked at in detail) and I think the best way to get consistent checking would be to first create a well structured summary of these rules in the conventions document. The constraint related to ticket 151 is that variables with standard name "region" or "area_type" must be consistent with the standard region and area type lists. I have reviewed the first half of the standard name list (a to m) and found the following coordinate constraints expressed: (1) area_fraction: requires an area_type coordinate; (2) atmosphere_lifting_condensation_level + 2 others: requires an original_air_pressure_of_lifted_parcel coordinate. (3) Many "layer" quantities (e.g. dry_static_energy_content_of_atmosphere_layer): require vertical coordinate with bounds. (4) change_in_energy_content_of_atmosphere_layer_due_to_change_in_sigma_coordinate_wrt_surface_pressure: must have a vertical coordinate variable (axis=Z) (5) change_over_time_... and .._displacement: require bounds on time coordinate (6) downwelling_photosynthetic_photon_radiance_in_sea_water and other radiance variables: direction must be specified, e.g. with coordinate of "zenith_angle". (7) mass_concentration_of_pm..._ambient_aerosol_in_air (and mass_fraction_of_pm..): require air_temperature and relative_humidity (8) isotropic_radiance_per_unit_wavelength_in_air (and other per_unit_wavelength varables): the definition is slightly ambiguous with the sentence "A coordinate variable for radiation wavelength should be given the standard name radiation_wavelength" which, taken literally, means the use of a wavelength coordinate is optional: should it be "A coordinate variable for radiation wavelength should be given with the standard name radiation_wavelength", making the wavelength coordinate required? Is it worth completing the review of the standard name desriptions and creating an appendix section to list these constraints, giving examples (or pointing to examples which may be better positioned in relevant portions of the main text)? regards, Martin _______________________________________________ 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. ________________________________ ________________________________ 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
