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 <cf-metadata-bounces at cgd.ucar.edu> on behalf of Jonathan Gregory <j.m.gregory at reading.ac.uk>
> Sent: 24 July 2019 16:58
> To: cf-metadata at cgd.ucar.edu
> 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 <daniel.neumann at dkrz.de> -----
>
>> Date: Wed, 24 Jul 2019 14:45:33 +0200
>> From: Daniel Neumann <daniel.neumann at dkrz.de>
>> To: cf-metadata at cgd.ucar.edu
>> 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: daniel.neumann at dkrz.de
>> 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
>> 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
--
Kenneth E. Kehoe
Research Associate - University of Oklahoma
Cooperative Institute for Mesoscale Meteorological Studies
ARM Climate Research Facility - Data Quality Office
e-mail: kkehoe at ou.edu | Office: 303-497-4754
Received on Mon Jul 29 2019 - 13:28:28 BST
