[CF-metadata] Invalid alias IDs in CF Standard Name Table v47
Lowry, Roy K.
rkl at bodc.ac.uk
Tue Nov 21 02:33:17 MST 2017
The duplicate you mention is a case where the original Standard Name was unfit for purpose due to the direction of the flux being implicit (assumed downwards) rather than explicit. We tackled this in our serving by using narrowMatch as the mapping predicate to both possibilities, with the implicit assumption reported by through the replacedBy mechanism. I appreciate that this isn't totally watertight if the semantic handler ignores the mappings and fails to report the inconsistency.
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 enquiries at bodc.ac.uk. Please also use this e-mail if your requirement is urgent.
From: CF-metadata <cf-metadata-bounces at cgd.ucar.edu> on behalf of Murray Altheim <Murray.Altheim at metservice.com>
Sent: 21 November 2017 02:08
To: cf-metadata at cgd.ucar.edu
Subject: Re: [CF-metadata] Invalid alias IDs in CF Standard Name Table v47
My apologies, I spoke too soon. Upon realising that XML parsers always exit on validation
errors I should have waited until I'd fixed all of the errors. There were more to be found.
Upon making the aforementioned whitespace fixes I noted that the aliases were all
essentially meaningless, i.e., aliases to the same ID. These included the following IDs:
<alias id="mole_fraction_of_chlorine monoxide_in_air">
<alias id="mole_fraction_of_chlorine dioxide_in_air">
<alias id="rate_of_ hydroxyl_radical_destruction_due_to_reaction_with_nmvoc">
Following these changes I rigged up the XSD and tried validating the document. This
pointed out a duplicate of the alias:
which unless I'm mistaken is an attempt to alias an entry to two other different entries. This
would suggest that aliases are many-to-many. Is this intended? It seems odd, as then there
is no single resolution to an alias. [In my local file I've commented out the second element.]
What the above does suggest is that updates to the CF Standard Name Table XML document
are being posted without going through a validation process. Since I assume this document is
to be used in production environments (or at least it's our intention) I'm wondering who I
might discuss this issue with. And yes, I can offer assistance and/or forward a notated copy
of my fixed XML document if requested.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the CF-metadata