All,
Things are very time-pressed today and I will be largely out of touch
for the next two weeks. I regret this, since I was one of the people
who started poking this hornets nest. Given these time constraints I'm
prevented from weighing in on all of the details of the dialog. So I'll
confine myself to the high points (I think that is where our discussion
belongs for now, anyway.) And in advance, a brief bowing and scraping
here to say that (as you doubtlessly know) I am prone to hyperbole in my
rhetorical style. Every one of the issues we face is nuanced. Finding
the right level of simplification is a challenge. I am bound to fail in
some cases ...
My belief: our challenge is *interoperability*. That and only that is
the reason that we are working as a community instead of working
individually. (Completeness of metadata content is one important aspect
of interoperability.) If we end up devising a CF format that allows a
small group of researchers in a narrowly connected field to write their
files, but no one knows how to read them, then we will have failed
utterly. Obviously, the format is still useful for those researchers,
since it allows them to press forward with their work, but we will have
failed in the sense that we have not taken an adequate step beyond the
dysfunctional practices of the past. Those dysfunctional practices
continue to limit the scientific methodology (e.g. models need to be
testable through model-data and model-model comparisons),
interdisciplinary research, and applications of the research
The question of timeliness -- how long does it take for a desperately
needed new idea to become a part of the standard -- is perhaps the key
point. We need to address it at both ends: 1) make the process faster;
2) set our expectations lower so we ensure that we develop a quality
standard. (A year is _not _a long time for a major new concept to make
its way into the official CF release.) The central problem is this: it
is easy, fast and fun to explore new ideas. It can be done in a few
email messages. It is slow, expensive and often thankless work to
implement the ideas, improve them and sometimes reject them. The first
part is illusion in my opinion unless the second is done, too. And
frankly, it seems shallow, too, in the sense that we all respect the
process of testing, exploring and rejecting ideas through
experimentation, don't we? That's what makes science, science.
The clear answer is that we (the CF community) have to be much more
successful in engaging the software development process. Two ways to do
this: 1) insist that *we* (the participants in the conversation) do
development at the same rate (on average) that we generate new ideas;
and 2) bring in more outside developers (e.g. Unidata) to help us
along. Again, we need to do both.
Two rules for standard development that seem to have been commonly
accepted "in the literature" today:
1. "at least two independent implementations"
2. "in systems of realistic complexity"
These are tall orders. In full honesty I don't think we can move fast
enough if we hold to them rigidly. But we need figure out a process and
a set of attitudes that gets us close to them. They are the star that
we ought to steer by, in my opinion.
I'm going to make a proposal at how we ought to apply these philosophies
in the case in hand -- encodings for ensemble models:
1. "two independent implementations" -- we have the GDS group at COLA
with a system in operation already. And we have (I think) Jamie's
group champing at the bit. So we ought to agree that the proposal
is provisional until these two groups (or others) have 1) created
datasets (not necessarily "files" per se -- can be aggregations
through OPeNDAP) and created 2) client applications to read those
datasets that adhere totally to the proposed encodings.
2. Make sure we test them on large, fully 4D, multi-variable,
curvilinear models and use them for a month or two actually doing
a broad range of activities. One hopes this will happen
naturally. It merely challenges us to be patient and a little
more focussed on testing -- not to declare prematurely that the
standard is "official".
Agree? Disagree? Gotta run. Not sure if next week I will even have
dial-up access ... but will stay in touch the best that I can.
-- Steve
====================================
Rich Signell wrote:
> Bryan & Jonathan,
>
> I agree with you both. ;-)
>
> I think there *is* some use to having standards even if computer
> applications have not been written to process them. The English
> language is one such useful standard, but there are not too many
> applications that work effectively on every aspect of it.
>
> On the other hand, it sure would be nice to see an application that
> demonstrates (a) why the new addition to the standard is necessary,
> and (b) that the proposed solution actually works. But even if there
> is a demonstrated app, that doesn't mean it's a good addition to the
> standard. Just more grist for the mill of the Conventions Committee
> to produce a good decision on inclusion. So I don't think we should
> require it.
>
> -Rich
>
>
>
> On 11/17/06, Bryan Lawrence <b.n.lawrence at rl.ac.uk> wrote:
>>
>> > ... However, conventions were devised so the metadata could be
>> written,
>> > because people thought it worthwhile to record it.
>>
>> :-) but this is my last point about a one hundred paragraph document. By
>> all means record metadata, and document how you've done so, but until a
>> number of folk have done so, and seen the utility of it, it's not a
>> convention ... (let alone a standard) ... although the utility of
>> discussing best practise it in the CF context is undoubted, and will
>> help one do it, but nothing has been lost in this case if the CF
>> community moves on and decides it is better done another way!
>>
>> Maybe we should wait until the other hemisphere wakes up and see if
>> we're alone in this argument :-) :-) :-)
>>
>> Cheers
>> B
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://www.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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20061117/215ef8d8/attachment-0002.html>
Received on Fri Nov 17 2006 - 10:59:32 GMT
