Create glossary of terms

[davidhassell]

Th current terms (such as fragment, aggregated data, etc.) are not the only choices, and some other choices are probably better.

The glossary should be considered a starting point for debate, rather than a statement of fact.

Things to consider: Not to use a term that is for a similar, but fundamentally different thing elsewhere. E,g, "chunk" is not a good substitute for "fragment", as chunks in other domains (like HDF, dask, ...) are much less self aware - i.e. they do not contain self-describing metadata, unlike our fragments (or whatever we call end up calling them)

[JonathanGregory]

Dear David

I think "fragment" is a pretty OK term. Its drawback is that it doesn't obviously relate to "variable" or "aggregated". Since you use "aggregated variable" for the assembly, you could call the fragments "subvariables", maybe. Or if you wish to evoke the cfdm, you could call them aggregated fields and subfields. That's just a thought - I'm not sure it's better.

Best wishes

Jonathan

[davidhassell]

Dear Jonathan - a quick thought: subfield is interesting, as one of the (uniques?) features of all this is that the each "bit" is fully self-describing, i.e. each "bit" does indeed map exactly to a CF data model Field construct.

[davidhassell]

Now that the glossary of existing terms is in place, I'll open a new issue for the discussion on what those term should actually be.