Good points Steve.
It isn't hard to develop the use cases -- we can just ask the existing users.
And there are a lot of them already, in a lot of different communities. So since the existing user base is starting to approach the possible user base, there will be issues trying to be consistent and complete. This is in the nature of widely used community vocabularies. (Or by 'identified user base' do you mean a target user base, which is deliberately constrained to be smaller than the actual user base?)
Re option 3, I agree. I think the problem we've run into (can't remember how thoroughly it's been discussed on the list) is that in NetCDF, specifying the relevant vocabulary for each term is not straightforward -- or perhaps I should say the approach is not agreed. (Does the term name include the vocabulary preface? If not, how do you know which vocabulary each term belongs to?) Even in cases where a CF standard name applies, it is often useful to supply additional terms from other vocabularies, as they may be more specific. It would be delightful to have a way to add this capability within the file in an agreed way. I don't know where community agreement on this idea should be developed -- CF, NetCDF, ...?
There are best practices and standards being developed for the development and maintenance of vocabularies. Not every vocabulary will want or need to follow every practice. But soon the community vocabularies will be characterized with respect to the best practices, and CF (as a leader, in my humble opinion) should be prepared in future to model those best practices as much as possible.
John
At 12:02 PM -0700 4/10/08, Steve Hankin wrote:
>All,
>
>This thread and the other couple that are going in parallel are getting us to examine important fundamentals of CF "philosophy". In the spirit of reaching a shared understanding of those fundamentals (effectively "voting"), I'm tossing my own viewpoint (a probably idiosyncratic and definitely simplified hat) into the ring here:
>
> ==>Note: We clearly need to develop use cases that clarify when and for what specific purposes standard_names are being used (Balaji's point). The following points presume that valid use cases do exist.
>
>1. The CF standard name list should be self-contained, internally-consistent and as complete as we deem its needs to be for our identified user base.
>It should not attempt to be so extensible that it can address all possible user communities. (Jonathan's point)
>Individual standard names should not attempt to be so complete that they serve as definitions. (Bryan's point)
>(We hope that controlled vocabularies created by other communities will try to achieve similar goals.)
>2. Vocabulary translation services should provide the means for translation between lists generated by different communities. (Roy's point)
>3. CF should define optional attributes that allow a CF file to point to "external" vocabularies, but there should be no aspect of strict CF compliance that requires reference to these external resources. (Benno's point -- see <http://cf-pcmdi.llnl.gov/trac/ticket/27>http://cf-pcmdi.llnl.gov/trac/ticket/27)
>Specialized communities can use these means to "personalize" their CF files, while retaining CF compliance.
> - Steve
>
>P.S. The implication of this approach is that if no CF standard_name for a given parameter exists at the time that files must be created, then no standard_name attribute should be included for that parameter. However, bullet #3 allows the file to include a non-CF, community-specific standardized parameter name and a link to its vocabulary. Vocabulary translation services can hope to provide the link back to a CF standard_name if one is created at a later time.
>
>=================================
>
>John Graybeal wrote:
>
>>Martin,
>>
>>Roy's approach is of course practical and I should have thought to suggest it myself.
>>
>>I may have misstated things in my earlier communication with you. I should have said 'if a term changes on either side, you'd have to relink that term; or if you have pointed to a particular version and wanted to be more current, you would have to repoint to the new version.' While currently our OWL copies of the CF vocabulary are set up with respect to specific versions, it is also entirely possible to create a persisting relationship to a given term, if that needs to be supported. (It's like a link to the nytimes.com site -- whenever you visit the page, you get _today's_ copy of the paper, not the copy from the day the link was made.) You are obviously correct that this is most useful to many users.
>>
>>Roy, could you clarify whether your vocabulary mapping service links to specific versions of a vocabulary, to a 'generic' vocabulary, or is it the user's choice?
>>
>>As a general observation, I agree with Jonathan's architectural summary. It is possible to provide good and widely used mapping facilities from a central mapping service. It is much less likely that every community vocabulary provider (and there are many) can provide a wide variety of services that are needed by the vocabulary users.
>>
>>John
>>
>>At 8:37 AM +0100 4/10/08, Jonathan Gregory wrote:
>>
>>
>>>Dear Martin
>>>
>>>I believe there used to be an xsd file for the standard_name xml file. Perhaps
>>>Velimir (copied) knows where it is?
>>>
>>>I sympathise with the need for equivalences to CF metadata and that is of
>>>course why the PCMDI and GRIB equivalences were set up in the first place.
>>>However, I would say there are two reasons why putting equivalences in the
>>>standard_name xml file is not the best approach:
>>>
>>>* There is probably not a one-to-one correspondence between your variables
>>>and standard names. I expect some of your variables might imply other CF
>>>metadata as well, as is the case with some of the PCMDI and GRIB codes. This
>>>is not recorded in the standard_name xml file, but it is noted in the separate
>>>tables for GRIB codes and PCMDI names at
>>><http://cf-pcmdi.llnl.gov/documents/cf-standard-names/>http://cf-pcmdi.llnl.gov/documents/cf-standard-names/
>>>e.g. tas means not just air_temperature, but implies a vertical coordinate.
>>>
>>>* The equivalence between your variables and CF metadata is not really part
>>>of the CF convention, although it facilitates the use of CF, and it seems a
>>>arbitrary to include equivalences to a selection of other conventions.
>>>
>>>As I mentioned, for these reasons I think we should remove the AMIP and PCMDI
>>>equivalences from the table. In any case, they are not being maintained and
>>>are out of date, and probably wrong for some GRIB codes.
>>>
>>>I feel that a better approach is to have a separate xml/html table for the
>>>equivalence between CF metadata (not just standard names, but standard name
>>>+ other metadata, more like common concepts) and other metadata, one for each
>>>standard (GRIB, AMIP, HTAP, aerocom, etc.). These tables could be linked to
>>>the CF site and would not be upset by updates to the standard name table,
>>>because we never *delete* standard names, so the equivalences would always
>>>remain valid. Do you think that would work?
>>>
>>>I am sure that others have good ideas about this, having thought about mappings
>>>and ontologies and how they should be maintained.
>>>
>>>Best wishes
>>>
>>>Jonathan
>>>_______________________________________________
>>>CF-metadata mailing list
>>><mailto:CF-metadata at cgd.ucar.edu>CF-metadata at cgd.ucar.edu
>>><http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>>
>>>
>>
>>
>>
>>
>
>--
>Steve Hankin, NOAA/PMEL -- <mailto:Steven.C.Hankin at noaa.gov>Steven.C.Hankin at noaa.gov
>7600 Sand Point Way NE, Seattle, WA 98115-0070
>ph. (206) 526-6080, FAX (206) 526-6744
>
>"The only thing necessary for the triumph of evil is for good men
>to do nothing." -- Edmund Burke
--
----------
John Graybeal <mailto:graybeal at mbari.org> -- 831-775-1956
Monterey Bay Aquarium Research Institute
Marine Metadata Initiative: http://marinemetadata.org || Shore Side Data System: http://www.mbari.org/ssds
Received on Thu Apr 10 2008 - 14:47:19 BST
