Hi Philip and list,
(I've started a new thread as this is probably a new topic for discussion.)
> And I could read this file today using, say, ncdump and ncview. Which
> clearly doesn't tell us much.
This is a really important point. It would be very difficult, in the
general case, to ascertain whether a certain piece of software
actually interprets a certain CF attribute correctly. Conversely it
is perhaps unreasonable to expect a piece of software to implement
correctly every feature of a certain CF version.
What a tool user really wants to know (I think) is, for a given NetCDF
file, which attributes in the file are correctly interpreted by the
tool. I can't think of a neat way to do this - perhaps tool
developers could publish a list of attributes that they claim to be
able to interpret for each version of the tool they produce? A given
tool might then implement 100% of CF1.0 but 50% of CF1.2 for example.
Then the CF community could maintain a list of tools that users could
go to to find out which tools might be most suited to their purpose.
An add-on to the CF compliance checker could be created that, having
scanned a file for CF attributes, produces a list that says "Tool X
understands all of the attributes in this file, but Tool Y only
understands 7 out of 9".
All this requires effort of course, but I think it's useful to
consider what we really mean when we call for "CF compliance". How
can we help users to judge which tools they should use and how can we
help data providers to ensure that their data can be interpreted by a
wide community?
Jon
On Thu, May 8, 2008 at 11:53 AM, Philip Bentley
<philip.bentley at metoffice.gov.uk> wrote:
>
> Hi Jonathan, Ethan,
>
>
> Dear Ethan
>
> I think that the current rules are a good compromise between the needs of
> people who write and analyse data, and the needs of developers of analysis
> and other software. The former group of people would like CF to be modified
> fairly rapidly, when they are about to start producing data from a project,
> and they want that data to have proper metadata. As you will have seen from
> previous discussions, our discussions are too slow as it is sometimes. Hence
> we decided the rules so that changes could be made, but marked as
> provisional.
>
> Indeed. I think the 4-plus years between CF 1.0 and CF 1.1 - according to
> the date stamps on the documents - says it all. Perhaps the recent flurry of
> CF proposal activity in part reflects a general desire to 'play catch-up'.
>
> For provisional changes to become permanent depends on at least two
> applications supporting them. That requires some development effort to be
> invested. CF doesn't have staff resources of its own to commit to it. I
> think
> the most likely applications to make changes first are the cf-checker and
> libcf. It will be interesting to see how long it takes for the changes so
> far
> agreed to be implemented in these or other applications.
>
> I fear that if we followed this approach:
>
> > 2) Don't add changes to the upcoming version of the specification
> > document "until at least two applications have successfully interpreted
> > the test data".
>
> development of CF would effectively be halted altogether. It would be
> impossible for writers of data to agree changes to the CF standard on a
> short enough timescale. Consequently they would bypass CF, and write and
> analyse data with their own metadata conventions, and the usefulness of CF
> in providing a common standard would be undermined.
>
> I agree 100% with this. If, as a community, we set the barrier to progress
> [of the CF conventions] too high then people will necessarily devise local,
> incompatible solutions - not out of willfulness, but simply to meet project
> deadlines.
>
> Applications don't have to keep entirely up to date, do they? I think the
> value of the Conventions attribute should be that it is easy to be clear
> about what conventions are being implemented in data and metadata.
>
> I agree about the test data. We should construct a file which contains
> some test data for the changes of CF 1.2. (The changes of CF 1.1 did not
> introduce any new attribute.) We'll need a place to deposit such files.
> As moderator of that ticket, I'll discuss it with Phil and Velimir.
>
> I can produce some simple test files for the changes at CF 1.2. But the
> question of what constitutes application conformance is, I suggest, not
> easily defined. For instance, I could create a noddy netcdf file with two
> new grid mapping attributes, as follows:
>
> float temperature(t,z,lat,lon);
> :grid_mapping = "crs";
> char crs;
> :grid_mapping_name = "latitude_longitude";
> :semi_major_axis = "92389234"; // new at CF 1.2
> :semi_minor_axis = "78682347"; // new at CF 1.2
>
> And I could read this file today using, say, ncdump and ncview. Which
> clearly doesn't tell us much. Yet a proposer of a given CF change cannot
> force the hands of software developers to produce compliant software within
> a particular time frame, if at all. In some (many?) circumstances I think we
> have to take it as an act of faith that a particular update to the CF
> convention will be advantageous. Plus I believe that the robustness of the
> CF peer review and challenge mechanisms is sufficient to ensure that those
> updates will be advantageous.
>
> Regards,
> Phil
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
--
--------------------------------------------------------------
Dr Jon Blower Tel: +44 118 378 5213 (direct line)
Technical Director Tel: +44 118 378 8741 (ESSC)
Reading e-Science Centre Fax: +44 118 378 6413
ESSC Email: jdb at mail.nerc-essc.ac.uk
University of Reading
3 Earley Gate
Reading RG6 6AL, UK
--------------------------------------------------------------
Received on Thu May 08 2008 - 06:23:02 BST
