[CF-metadata] Getting back to ensembles
Dear Bryan
> I think we all understand the distinction between things which are
> measured, and things which are about measurement techniques, or who made
> the measurements (or simulations).
There is a distinction which can be made in most cases, but
(a) it is blurred. Some things are in the middle, such as latitude or
platform_orientation.
(b) even those things which aren't measured, such as experiment_id, might
be contained in data variables.
So although we all understand the distinction in limiting cases, I am not
sure it is so easy to make in practice in all cases. Therefore the right way
to proceed is to establish why we want to make such a distinction in
practice. The distinction to be made would then be more obvious.
> At the moment it is only your voice which is arguing against separating
> these vocabs. Are there any others who have a problem with the proposed
> separation? (Which is simply the creation of an additional table, to be
> called standard_metadata, which we will continue to control in the same
> way as we control standard_names
I am not against it in principle. I am asking for a clearly stated requirement
for the separation, and a rule which we can apply to make it. That is the
problem I have, not the existence of separate categories per se. Anyone who
thinks this separation is a good idea is welcome to say exactly what the
distinction is supposed to be and why it is needed.
> We want to start building smart tools that can assist data users
> understand these distinctions faster
If *we* can't say what this distinction is in the first place, I don't see how
we can build a tool which will help people to understand it ... unless it is
*very* smart. Perhaps you have an AI which could do it? :-)
I am really not arguing on dogmatic grounds. The only rule I am following is
that I am against introducing things which are ill-defined or do not have an
obvious function. I am very willing to accept a clarification.
Best wishes
Jonathan
Received on Fri Dec 29 2006 - 07:03:35 GMT
This archive was generated by hypermail 2.3.0
: Tue Sep 13 2022 - 23:02:40 BST