On 1/11/2011 4:28 AM, Bryan Lawrence wrote:
> Hi Jonathan
>
> Thanks for doing this. I think it's an important step.
>
> Unequiviocally: CF needs an explict data model, independent of netCDF!
> My take on this is that the right way to go forward is to produce an
> abstract description (aka a data model) for CF as is now - which means
> it explicitly includes NetCDF dependencies.
>
> Then we explicity identify those dependencies (and assumptions) and
> identify the underlying data model.
>
> In doing so, I think we want to use *existing* data modelling tools and
> language, rather than inventing our own.
Jonathan -- echoing Brian's thanks for taking on this effort. A high
level description of the CF data model (pinning down concepts
intuitively for readers as well as formal UML) would be a valuable
addition to the document. (Maybe make this a trac ticket?)
Bryan -- I'd like to make sure that the vocabulary is clear in
interpreting your words. "NetCDF" is an ambiguous term in this context,
because it is both a data model and a file format. I see the CF data
model as a specialization of the netCDF data model, rather that a
roll-your-own from scratch. To borrow the terminology from the de jure
world, I see the netCDF-3 data model as a normative standard for CF.
From a standard pov CF is stronger because it builds upon the netCDF
data model. From your UML I infer that you are seeing things the same
way. (It was the words that seemed ambiguous.)
What seems a significant omission in this discussion, though, is the
coupling to the CDM, which has already traversed much of this formal
data modeling terrain. There is much to be gained in merging the two
bodies of work. (And much to be lost by diverging.) This effort seems
like the opportunity to pin down the areas where there is currently
divergence.
> I had a stab at this a few years ago, an image of which is attached.
> I
> know it's wrong in a couple of details, but I never got back to finish
> it. Had I done so, I would have documented (*) it and shared it with the
> CF community. then.
>
> (* by which I mean, explain in more neutral langauge what the UML was
> intended to convey).
>
> With those thoughts in mind, a couple of comments on your web page.
>
> Firsty, and most importantly, most of the important ideas are there, and
> I think it's a great start. however, it's in the nature of these things
> to criticise:
>
> - I don't like the concept of a space construct. It's a new term to me
> which doesn't carry any useful attributes. I much prefer the use of
> object, which *is* a language neutral term (in data modelling). If you
> use object, you can then use existing data modelling tools and
> voabularies.
>
> -I don't like central assumptions that are violated. Either we make it
> or we don't. You can make that assumption property of some attributes of
> space constructs.
>
> - I think text without pictures is just as unhelpful as pictures without
> text (my version :-).
>
Only one very specific technical comment here (raised because it has
been the topic of other discussions recently):
"In CF, there is a formal distinction between scalar coordinate
variables and size-one coordinate variables, but they are logically
the same;"
I think this is a typo intended to say "there is NO formal distinction"
N'est-ce pas? While we offer two syntax options for scalar coordinates,
our recent discussions about bounds attributes and axis attributes
revealed that from a data modeling perspective a coordinate axis of
length N=1 is simply a coordinate axis; AFAIK there is not a distinct
concept of a scalar coordinate axis.
- Steve
> With my last point in mind, and in an effort to be constructive: howabout
> I spend an afternoon with you, and see if we can get my picture and your
> text congruent? We might as well exploit our geographic adjacency :-)
>
> Cheers
> Bryan
>
>
>
>> Dear all
>>
>> Although CF is primarily a file format convention, we often have in
>> mind a logical data model for CF data while we are discussing
>> modifications and extensions to CF. In principle the data model can
>> be separated from the mechanics, restrictions and requirements of
>> netCDF itself, and could apply to other file formats. In
>> http://www.met.rdg.ac.uk/~jonathan/CF_metadata/cfdm.html I have
>> outlined my perception of the CF data model. I know this is not the
>> only such description. For example, libcf implicitly has a CF data
>> model, but it is generally more low-level, it seems to me. I may
>> well be completely unaware of other relevant documents, and I'd be
>> grateful to hear of them, and in any case for comments on my version
>> of the data model. Would it be useful to write down a data model as
>> part of the CF standard document, I wonder?
>>
>> Cheers
>>
>> Jonathan
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> --
> Bryan Lawrence
> Director of Environmental Archival and Associated Research
> (NCAS/British Atmospheric Data Centre and NCEO/NERC NEODC)
> STFC, Rutherford Appleton Laboratory
> Phone +44 1235 445012; Fax ... 5848;
> Web: home.badc.rl.ac.uk/lawrence
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20110111/9428d6f7/attachment.html>
Received on Tue Jan 11 2011 - 10:07:16 GMT
