Hi John,
Would it be right to think of the strategy you've outlined as an
elaboration on "Alternative 1":
Should the CF standard_name process, *itself*, include a
"provisional fast-track", that allows names to be added very quickly
with no guarantee that they will have a lasting status, but with an
*iron-clad guarantee that the provisional names will be retained*
(and so-identified) in version-stamped (older) CF vocabularies.
Presumably someone connected to CF would have to commit to maintaining
the RDF store and (one assumes) provide an on-going, well-supported
service that can query it. Is this the vision you are suggesting?
- Steve
================================
John Graybeal wrote:
> OK, now I have to submit my other notion after all, which I think
> addresses some of Steve's concerns. But let me semi-agree with his
> first paragraph -- I'm enthusiastic, but I think there are a lot of
> details to be agreed on. I'll come back to that in a separate post.
>
> I had thought it was important to provide a way to enter proposed CF
> terms in a common way/place, so that they can (a) be used by the
> originators and the community in the meantime, (b) be seen by the CF
> folks, and (c) be dispositioned appropriately when CF either accepts
> them or rejects them. So my proposal was to create a vocabulary, or
> more precisely an RDF store, that lets us:
> 1) declare a name that may be proposed as a CF candidate
> 2) make a statement that the name has been (or even 'is being')
> submitted to CF for consideration
> 3a) make a statement that the name has been accepted as a CF name,
> and therefore is deprecated as a proposed name
> 3b) make a statement that the name has been rejected as a CF name,
> and therefore is deprecated as a proposed name
> In either 3a or 3b,
> 4) make a statement that the replacement representation of the name
> is xyz in some other vocabulary
>
> The relationship of this proposal to the previous thread is that it
> provides an implementation mechanism for the life cycle of the
> provisional terms. It also helps assure some of the things Steve is
> trying to ensure -- some of which only recently became possible with
> CF, and even that manually, not through any automatable utility,
> interface, or URI convention.
>
> Anyway, I don't want to encourage a detailed discussion of the above
> proposal, as it is secondary to Martin's original suggestion, and I
> feel sure it will have to be considered at some length in TRAC if we
> get that far. Just wanted to mention that the semantic technologies
> can enable some very useful views/approaches to some of these problems.
>
> John
>
> On May 12, 2010, at 11:22, Steve Hankin wrote:
>
>> Hi Martin,
>>
>> You've had two enthusiastic "yes" responses, so I guess I have the
>> privilege to be the wet blanket. So it goes. I will give only a
>> very cautious and limited "yes". Not an outright "no" ... but a
>> suggestion for more thought and discussion.
>>
>> The proposal here is effectively the creation of 'private tables' as
>> a means of achieving extensibility. We've had an opportunity to see
>> the hazards embedded in this approach as a long-term evolutionary
>> process in WMO. Over time the "custom" tables evolve to have an
>> quasi-official status -- entire sub-communities rely upon them -- but
>> without necessarily a corresponding methodical control over their
>> creation and distribution. With BUFR and GRIB files the proliferation
>> of distinct tables has lead to serious interoperability problems.
>>
>> To avoid repeating these problems with your proposal, CF clients must
>> be provided with *iron-clad ways to be assured that they are
>> referring to the same vocabulary tables that the data author was
>> referring to at the time that the data were written*. Since we want
>> CF files to ensure interoperability when there are *years separating
>> the writing of data from reading it*, your strategy needs to ensure
>> careful version control over the private tables. This imposes a
>> significant burden on you as the creator of a
>> "<project>_standard_name" table -- essentially a requirement to
>> retain and serve out older table versions "in perpetuity" (we could
>> argue over what that means). The use of semantic web technologies
>> will not alter these considerations for the foreseeable future (tho
>> over the long term sophisticated inference engines might ...). The
>> ontologies still need to be informed by correct information, which
>> implies knowledge of the version-controlled private vocabularies.
>>
>> A "<project>_standard_name" may have one of three life histories: it
>> may never become accepted into the standard_name table; it may be
>> accepted as-is; or it may be accepted with alterations. The
>> following suggested restriction illustrates some of the difficulties:
>> "A variable can contain either a standard_name or
>> <project>_standard_name attribute but not both." What's behind this
>> restriction? Given the uncertain life history of a
>> <project>_standard_name, if it has been in use for (say) a year and
>> is found in thousands of files that are being shared around the
>> community, doesn't that generate a need to continue support for it.
>>
>> Two alternative approaches (both flawed, of course ... the nature of
>> the beast):
>>
>> 1. Should the CF standard_name process, itself, include a
>> "provisional fast-track", that allows names to be added very
>> quickly with no guarantee that they will have a lasting status,
>> but with an *iron-clad guarantee that the provisional names
>> will be retained* (and so-identified) in version-stamped
>> (older) CF vocabularies.
>> or
>> 2. Might you be better off using a *truly private* vocabulary of
>> "<project>_standard_name" strings. I.e. one that has no
>> official status in CF at all? There is no violation to the CF
>> standard through doing this. This approach makes it your
>> private responsibility on behalf of your users to deal with
>> files that are created in the period between proposing a CF
>> standard_name and having it become part of the official table
>>
>>
>> - Steve
>>
>> ====================
>>
>> 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
>>>
>>>
>>> ------------------------------------------------------------------------------------------------
>>> ------------------------------------------------------------------------------------------------
>>> Forschungszentrum Juelich GmbH
>>> 52425 Juelich
>>> Sitz der Gesellschaft: Juelich
>>> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
>>> Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe
>>> Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
>>> Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
>>> Prof. Dr. Sebastian M. Schmidt
>>> ------------------------------------------------------------------------------------------------
>>> ------------------------------------------------------------------------------------------------
>>> _______________________________________________
>>> CF-metadata mailing list
>>> CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>>
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
> --------------
> I have my new work email address: jgraybeal at ucsd.edu
> <mailto:jgraybeal at ucsd.edu>
> --------------
>
> John Graybeal <mailto:jgraybeal at ucsd.edu>
> phone: 858-534-2162
> System Development Manager
> Ocean Observatories Initiative Cyberinfrastructure Project:
> http://ci.oceanobservatories.org
> Marine Metadata Interoperability Project: http://marinemetadata.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20100512/8622558e/attachment-0002.html>
Received on Wed May 12 2010 - 13:23:02 BST
