Hi John,
sounds we are converging here. So, perhaps I should re-consider the "compound_name" attribute and generalize it. We all agree that the URL is the definitive reference from where the term should be obtained. Now, there are two cases which we (i.e. eventually some interoperable application) should be able to handle:
case 1: one of the 27 namespace servers from all the different communities involved happens to be down when the application needs to access it in order to find out the compound_name. One can argue that it's the responsibility of the application to provide a fallback solution in this event (which would be some cached version of the vocabulary list retrieved earlier), but we could also say that this fallback solution would be provided within the standard_name table via the "resolved" compound_name tag - or more generally, if X_codelist fails, then X_name will be the "value to the best of our knowledge". Technically, one could for example establish a procedure where all X_names would be automatically resolved upon creating a new standard_name table, i.e. at each release.
case 2: some community re-thinks their controlled vocabulary, and what was always called "hydrocarbonoclastic_bacteria" would now be called something else. In this case we would of course get an inconsistency between a standard_name term and the component that is controlled by the external list. Yes, there is a procedure: we can request a standard_name change and move the old name to the alias section. Should we then allow X_codelist also for aliases (given that the old name is still available)? We can hope that this case doesn't happen very often. If it would then we may need to rethink the way how standard_names are adopted (in the case of change requests). But we could end up with an inconsistency between the standard_name and its component, at least temporarily.
While I can see that the explicit addition of the X_name tag could potentially lead to yet another level of inconsistency, I would argue that it might help identify problems of nature #2, and that the risk of inconsistencies is small if we adopt the approach suggested in #1, i.e. automatic re-harvesting in the event of a standard_name table update.
I can see that this almost conceptual change to the standard_names table could lead to a number of issues we will only find out if we try. Perhaps it would be best to create a test version of the current table (version 20) including a couple of these X_name and X_codelist pairs and see how it can actually be used and what kind of problems we encounter. Then, after some testing we could probably come up with a more robust description of what exactly should be done and how it should be done. If you agree I could make a start and post a modified table somewhere so that you (or someone else) could add some more codelist/name tags from their field.
Best regards,
Martin
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Kennen Sie schon unsere app?
http://www.fz-juelich.de/app
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20120912/2b4bb0e6/attachment.html>
Received on Wed Sep 12 2012 - 05:06:52 BST
