Hi Bryan,
Responses interleaved.
Best,
cz
Le 18/09/2013 05:57, Bryan Lawrence a ?crit :
> Hi Charlie
>
> (Before I disagree with you, like most on the list, I'm glad we're
> having the conversation on this topic, it needs to be had, so thanks!)
>
> I find this particular example completely unhelpful, not least because I
> don't see the utility for doing so. However, I can see that others might
> see the utility of doing it ... (your suitcase analogy). But at some
> point, we all use netcdf as such a suitcase, so the question is why use
> CF in particular? Why have a *CF* convention for this?
One reason is to improve suitcase interoperability.
CF could have a standard way of aggregating into suitcases items
which are intended later to be pulled out of suitcases.
Another is that certain research problems CF users are interested
in may become less onerous if datasets are handled with groups.
Refer to "ensemble" use-case just posted on new thread.
> Well, one might use CF because software can handle it. That might not be
> as true as we would like, but finding new ways of organising our
> material (in suitcases) wont make it any easier to build conformant
> software, but heh, we'd do that if we had another compelling reason ...
> so moving on.
>
> We might do it because we have complicated "features" in the real world
> for which groups will help. I imagine we will eventually get there ....
See new post:
Are ensembles a compelling use case for "group-aware" metadata?
> We might do it because it's the "natural" way to ship or store the data.
> I think we can all agree that we are likely to disagree on the natural
> way to do things, but we can all agree that we will all have a natural
> way :-). So, it does make sense to have a convention for allowing folks
> to do this. It's just not obvious (to me) that it needs to be a CF way
> of doing things. That said, CF probably shouldn't *stop* folks using
> groups in netcdf4 files, so we need (IMHO) to come up with the minimum
> specification that supports that - but tension it against my earlier
> comment "is this a compelling reason to make software more complicated?".
>
> IMHO we could live with groups as a convenience encoding. Nothing more
> until we get to features. I think that's consistent with your example.
> In doing so, group attributes become member attributes when unpacked,
> but group attributes that are not inherited would be a big problem ...
Agreed. While we may disagree on the Earth-shattering importance of
group-metadata inheritance, that's a premature dispute. Let's see
if there's a CF consensus on groups first.
--
Charlie Zender, Earth System Sci. & Computer Sci.
University of California, Irvine 949-891-2429 )'(
Received on Thu Sep 19 2013 - 14:00:36 BST
