Hello Jonathan,
I would be more than happy to drop the idea of a standard name modifier
in this case and just introduce the standard name 'realization_weight'.
I had thought that if you were using ancillary_variables this meant you
had to use a standard name modifier - but I think I misread CF1.0 sec
3.4.
This is clearly a special handling of a fifth dimension: how do we
expect applications that are CF1.0 compliant to support the addition of
the standard names 'realization' and 'realization_weight'? Should they
treat them as special standard names (as latitude, longitude and
vertical coordinate types are in spatially referencing the data)? In
this case this dimension is special in that it allows you to calculate
statistics across the realizations. (In that sense 'realization_weight'
is a little bit like a cell measure - though I'm not sure we'd want to
go this way 'realization' doesn't really have a scale/units).
You pointed out that I had not standardised the way in which you might
distinguish different realization_weights present in the same file. I
think there are two parts to this problem.
1) identifying which realization_weights can be used with which
variables (temperature, pressure, or both) - this is dealt with through
the ancillary_variable references of 'temperature', 'pressure' etc.
2) provenance information on how the realization_weights have been
derived.
The two are not entirely independent - you may take the philosophical
position that to form a pdf of forecast temperature (point 1) you need
to base this on realization_weights derived on a uniform prior in
forecast temperature (point 2). But for purpose of representation I
think you can treat them as being separate. I think I'd not try and
standardise point 2 yet - but use 'source' to describe the provenance in
the level of detail needed to make sense to a human user (this is all
reminiscent of the problems representing ensemble provenance).
I think given this change has larger implications than just the addition
of a couple of standard names it is probably a candidate for
'provisional' status? And a period of testing?
Jamie
On Sun, 2007-01-21 at 11:55 +0000, Jonathan Gregory wrote:
> Dear Jamie
>
> Thank you for resurrecting this. Although they are linked, I think we should
> keep this as separate from the ensemble metadata, for ease of discussion.
>
> I presume that this proposal is agreed in principle from the last discussion
> of it, but we have to draft exactly what it means in the standard before
> deciding.
>
> > The thing I missed in the original posting is that the pdfs can be
> > multivariate involving two (or more) quantities with different standard
> > names. This means we may have to support standard names of the form
> >
> > weight:standard_name="air_temperature precipitation_amount
> > realization_weight";
>
> This is a new syntax and I would suggest it implies that things are getting a
> bit too complicated. You already admit the need for alternative sets of weights
> but don't provide any standardised way of describing them.
>
> What would you think of simplifying the proposal to introduce a standard_name
> of realization_weight instead of a standard_name modifier? You can still use
> the ancillary_variables attribute to point to the appropriate weights, which
> will help in cases where there's more than one set. In many cases there is only
> one set for all quantities, if the ensemble members have been weighted by some
> overall metric, and then it doesn't seem appropriate to name the weights as a
> modifier of a particular standard name.
>
> For more complicated cases, one could either devise a project-specific
> convention, or we could do something more general, but I'd say we should do
> that when we have a real use case to consider.
>
> Cheers
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Wed Feb 07 2007 - 03:48:41 GMT
