⇐ ⇒

[CF-metadata] Getting back to ensembles

From: Roy Lowry <rkl>
Date: Wed, 27 Dec 2006 10:50:57 +0000

Dear All,

I still think having separate vocabularies for separate metadata attributes is the better way to go. I would prefer two vocabularies with overlapping term sets to the the possibility of populating a field with an inappropriate term. If the metadata attributes pertain to clearly different entities then so too will the vocabularies.

Having separate vocabularies permits automated population protection on each attribute - it's amazing how easy it is to select the wrong item from a drop-down list through an unintentional slip of the mouse.

Does anyone agree?

Cheers,Roy.

>>> Jonathan Gregory <j.m.gregory at reading.ac.uk> 12/23/06 9:03 PM >>>
Dear Steve, Paco et al.

> IMHO the above paragraph cannot really be said to be a requirement :-\
> . It begins with a proposed implementation ("may have a dimension
> which serves as an index") and follows up with some of the
> functionality that can (and cannot) easily be achieved through that
> implementation.

Yes, I agree, I should have taken a step back from the index dimension. So
I would rephrase the requirement as follows:

A means is needed (a) to aggregate data variables from the members of an
ensemble, derived from different models, integrations, institutions supplying
the data, etc., where the data from each ensemble member is a function of the
same spatiotemporal coordinates and/or other physical independent variables;
(b) to provide metadata identifying the ensemble members.

Then the proposed implementation begins:

We propose to introduce a dimension for the data variable to serve as an
index over the ensemble members.

and continues by proposing auxiliary coordinate variables, etc., as in my
last posting
http://www.cgd.ucar.edu/pipermail/cf-metadata/2006/001397.html

The requirement covers the areas you (Steve) have given (in more detail) in
your points 1-3. Your requirements 4-6, however, are about functionality which
programs processing the data might need to have. While I agree we should bear
in mind the convenience of processing the proposed metadata, and hence that is
a consideration in deciding which implementation to choose, I don't think it
forms part of the requirement. CF is a metadata convention, not a specification
for data processing software.

Paco, does the present proposal meet your requirements? If so, I would urge
that we adopt it. We still have the question about whether the new metadata
items should be given standard_names, or some other atttribute. I would suggest
that they should be standard_names unless anyone can propose both a requirement
for a distinction and a reliable objective test which defines that distinction.

Best wishes

Jonathan
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata


-- 
This message (and any attachments) is for the recipient only. NERC
is subject to the Freedom of Information Act 2000 and the contents
of this email and any reply you make may be disclosed by NERC unless
it is exempt from release under the Act. Any material supplied to
NERC may be stored in an electronic records management system.
Received on Wed Dec 27 2006 - 03:50:57 GMT

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:40 BST

⇐ ⇒