Hi John,
The back end supports versioned mappings, through maintenance of an audit trail. However, this isn't accessible through the current version of the API, which will only serve mappings to terms present in the current version of the vocabulary. Rectifying this is on the API development plan but putting times to this is tricky at the moment as Geoff is emigrating to Australia at the end of June.
Cheers, Roy.
>>> John Graybeal <graybeal at mbari.org> 4/10/2008 2:56 pm >>>
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
--
----------
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
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
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.
Received on Thu Apr 10 2008 - 09:12:52 BST
