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)
* 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/
>> 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
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>
>
>
>
--
Steve Hankin, NOAA/PMEL -- 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20080410/76ccf9c0/attachment-0002.html>
Received on Thu Apr 10 2008 - 13:02:53 BST
