I agree with Johnathan that the individual flag descriptions would be documented in the flag_meanings attribute. If the description of the flag or the process to generate the flags is too long to put in the flag_meanings (which is what I would assume for many cases) then the full description can be linked. I would assume using "references" attribute could point to a DOI, URL or paper citation. That is how I would solve this though experiment.
I don't see the need to link each flag meaning to an external source but if that was needed a new attribute of flag_references could be added to providing a linking method. Ken On 2019-7-25 12:36, Martin Juckes - UKRI STFC wrote: > Dear Daniel, > > > I agree with Jonathan's interpretation: "as self-describing as possible" can > only go so far. I don't see any reason in principle not to include pointers > to external resources. However, the problem is always in the detail. > > > The problem appears to be that you consider the amount of information which > can be put in a valid flag_meanings word is too limited in some cases, which > I find plausible. > > > You can place extra information in the "comment" attribute, but this is not > semantically tied to the flags, so there is a plausible case for having a > specific attribute to provide additional information about the flags. > > There is a precedent for referring to external definitions of terms in the > "land_cover_lccs" standard name, which refers to the UN Land Cover > Classification System. Not a great precedent, as the reference given is a web > page from 2000 explaining the system and motivation behind the terms, but > getting at the terms requires running the database on a computer with windows > 95/98 or NT, apparently. It appears that LCCS has evolved to become a > software tool and the terms the community is now using are in the Land Cover > Meta Language (LCML), which is an ISO standard. This suggests, I think, we > need to be cautious about how external references are introduced. > > regards, > Martin > > > > > > > ________________________________ > From: CF-metadata <[email protected]> on behalf of Jonathan > Gregory <[email protected]> > Sent: 24 July 2019 16:58 > To: [email protected] > Subject: [CF-metadata] PID to external description of Quality and Status > states > > Dear Daniel > > I assume you mean a data variable which has strings describing quality or > status states, probably encoded with flag_values and flag_meanings. Would > the flag_meanings be meaningful to a human reading them? If so, you could > regard the file as self-describing. Self-describing doesn't have to mean > self-documenting, I would say. Standard names are self-explanatory to some > extent, and make the file self-describing, but they also have definitions > which aren't in the file, and papers in the peer-reviewed literature about > the quantities. If the flag_meanings are self-explanatory, I think that's OK, > but I'm not in favour of putting codes in the CF-netCDF file. > > Best wishes > > Jonathan > > ----- Forwarded message from Daniel Neumann <[email protected]> ----- > >> Date: Wed, 24 Jul 2019 14:45:33 +0200 >> From: Daniel Neumann <[email protected]> >> To: [email protected] >> Subject: [CF-metadata] PID to external description of Quality and Status >> states >> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 >> Thunderbird/60.8.0 >> >> Dear list, >> >> A CF-conformal NetCDF file should be as self-describing as possible. >> URIs/PIDs poitining to external data sources are problematic in this >> context. However, IDs pointing to external data sources were already >> discussed for taxa in the CF Trac Ticket #99 "Taxon Names and >> Identifiers" (https://cf-trac.llnl.gov/trac/ticket/99). >> >> Let's assume we have a long description of quality control measures >> performed resulting in N possible quality states for a NetCDF >> variable. The full description could be part of a peer-reviewed >> paper or grey literature (with assigned PID). However, it is too >> long to be included in the attribute "description" of the >> quality/status flag variable. One solution would be to add a brief >> description of the quality states to the quality_flag/status_flag >> variable and point to the external full description via it's PID. >> >> What is your opinion on this? >> >> This is not a request for a feature but rather meant to collect some >> opinions on this topic. It is somehow related to the request of a >> global PID attribute in CF GitHub Issue 160 "Add attribute >> citation_id" >> (https://github.com/cf-convention/cf-conventions/issues/160). >> >> Regards, >> Daniel >> >> >> -- >> Dr. Daniel Neumann >> Abteilung Datenmanagement >> >> Deutsches Klimarechenzentrum GmbH (DKRZ) >> Bundesstraße 45 a • D-20146 Hamburg • Germany >> >> Phone: +49 40 460094-120 >> Email: [email protected] >> URL: www.dkrz.de<http://www.dkrz.de> >> >> Geschäftsführer: Prof. Dr. Thomas Ludwig >> Sitz der Gesellschaft: Hamburg >> Amtsgericht Hamburg HRB 39784 >> >> > > >> _______________________________________________ >> 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 -- Kenneth E. Kehoe Research Associate - University of Oklahoma Cooperative Institute for Mesoscale Meteorological Studies ARM Climate Research Facility - Data Quality Office e-mail: [email protected] | Office: 303-497-4754 _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
