Hello all
I agree with you.
We are currently experimenting a solution to that based on semantic language. We have the same need in the frame of a project (MyOcean, actually). I tell you the story:
There is the need for MyOcean Information System (call it 'MIS') entities to share the same standard name table. As some standard name for MyOcean variables are missing, and as the process of updating CF official table is external to MyOcean project, the idea is:
- to make a MyOcean internal copy of CF table to fulfill MIS requirements. Inside this copy MIS will keep up-to-date the list of official CF standard names combined with the list of proposed CF standard names, until each variable within MyOcean has one CF definition.
- write this using standardized formalism. SKOS was identified as a good candidate for that.
Actually some structures like MMI and BODC have already started to represent CF using semantic language. Instead of rewriting all CF and turn it into SKOS, we prefer re-use such existing works.
Existing SKOS vocabularies for CF represent CF official table turned into a semantic way, and are provided on a web server; each of the SKOS resources has one URI.
Actually we propose to manage an internal version of this which contains all existing resources needed for the MIS (maybe only 50 at the most standard names attributes), and, use URIs to map them with external reference.
Once one CF standard name is accepted, I should only have to map my internal CF resource to official new one using "skos:exactMatch" relationship.
That's the idea..
Best wishes
Olivier.
-----Message d'origine-----
De : cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] De la part de John Graybeal
Envoy? : mercredi 12 mai 2010 16:15
? : Schultz, Martin
Cc : cf-metadata at cgd.ucar.edu
Objet : Re: [CF-metadata] non-standard standard_names
Martin et al,
I like this approach. I think this is an important addition to the CF concept, it supports much more scalability and encourages much more adoption.
There may be some concern that is not immediately obvious to me, but I have been thinking about a complementary solution from the semantic web standpoint. I'll send that to the list separately so it goes under a separate thread.
Note your example has a hyphen in it, does 'htap_standard_name' more clearly represents your proposal?
As an alternative approach, we might blend the concept of the alternative standard name with a more explicit project or vocabulary reference. Rather than a plethora of xyz_standard_name forms, and the need to do a regular expression search to find them, we could have one form like 'provisional_standard_name', with the requirement that a provisional vocabulary or project also be specified (e.g., 'provisional_name_project' with a string, or 'provisional_name_vocabulary' with a URL. These approaches avoid overloading the attribute name, which seems like a good practice; but I appreciate we might be asked to discuss them via TRAC.
Thanks for bringing this idea forward.
John
On May 12, 2010, at 05:33, Schultz, Martin wrote:
> Dear all,
>
> we are currently cleaning all files on our TFHTAP multi-model
> experiment server to make them fully CF(1.0) conformant. It has been
> about 3 years since we had drafted the original format description of
> these experiments and also initiated the standard name discussion for
> chemical constituents (thanks again to Christiane Textor who did a lot
> of this initial work). Many standard names which we needed have now been
> defined (thanks to all who contributed and to Allison for maintaining
> the list!). Nevertheless, there are a number of model variables left for
> which no standard name has been agreed upon and where we (or the CF
> mailing list group) also felt that they are too specialized to deserve a
> "standard" name. From the perspective of the CF community this may not
> be an issue, but in the context of interoperability (we now operate a
> WCS server to share these files) the fact that some variables do have a
> standard_name attribute and others don't poses considerable challenges.
> The CF convention states that "either standard_name or long_name" should
> be present. In our view, the long_name attribute is a poor substitute
> for the standard_name, because it has no rules attached. We are now
> planning to substitute "illegal" standard_name attributes by a new
> "htap-_standard_name" attribute, which shall make clear that these names
> are derived according to the CF guidelines, but they are not accepted
> standard_names. Such a concept would enable software tools to easily
> scan additional standard_name tables and make use of the well-defined
> semantics that a standard_name provides without having to push
> additional standard_names through the discussion - in particular if they
> are no so "standard". I can see the danger that certain groups might
> think it no longer necessary to go through the tedious but ultimately
> worthwhile discussion process in this mailing list and the meaning of
> "standard" names could get diluted. However, in my view the advantage of
> having the possibility to extend the convention without breaking
> standard-conformance outweighs this potential disadvantage.
>
> Specifically I would thus propose to add an optional attribute to
> the CF documents such as:
>
> <project>_standard_name: use this attribute to define the meaning of
> variables which have no accepted standard_name defined (yet). The
> project name should be a single string without blanks or underscore
> characters. These project-specific standard_names must follow the
> guidelines for the construction of standard_names, but they will not be
> evaluated by generic tools which test a data file for CF compliance.
> Groups who wish to define such project-specific standard names should
> first consider to submit their proposals to the CF mailing list for
> inclusion in the CF standard name table. A variable can contain either a
> standard_name or <project>_standard_name attribute but not both. A
> long_name attribute is not needed when a <project>_standard_name is
> given.
>
>
> Best regards,
>
> Martin
>
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Cliquez sur l'url suivante
https://www.mailcontrol.com/sr/ABvmYQAiIdPTndxI!oX7UnkyRQ0MRq91WnKfcdbqy7umgMZ!HR+bcGckO!Kq9tCR!BRnKHvkql1LwdQMGDtFKA==
si ce message est ind?sirable (pourriel).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20100512/d1f6ec1e/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 12859 bytes
Desc: image002.jpg
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20100512/d1f6ec1e/attachment-0002.jpe>
Received on Wed May 12 2010 - 09:09:06 BST
