[CF-metadata] Encoding Errors on variables in CF

[Stephens, A (Ag)]

Hi,

I think that Russ's suggestion about prefixing "for_variable_" or
"for_variables_" is fine. As long as this becomes a standard it probably
doesn't matter too much what is decided on as long as the link is clear. The
one-to-one and one-to-many mappings will also be potentially useful in
making it clear to the user what variables are related in a file(s?).

Ag

> -----Original Message-----
> From: Russ Rew [mailto:russ at unidata.ucar.edu]
> Sent: 08 April 2003 15:55
> To: Jonathan Gregory
> Cc: cf-metadata at cgd.ucar.edu
> Subject: Re: [CF-metadata] Encoding Errors on variables in CF 
> 
> 
> Hi,
> 
> I haven't followed this discussion very closely, but have a few
> comments on one of Jonathan's suggestions.
> 
> > If we include data quality variables, we are dealing with 
> more than just
> > "errors". I would suggest calling the pointer attribute 
> "ancillary_data"
> > rather than "error_variables". 
> 
> If an attribute contains a list of netCDF variables, I suggest it's
> better to use "variables" in the attribute name, because otherwise
> it's just a string with no indication it is intended to refer to other
> variables.  So I would much prefer "ancillary_variables" to
> "ancillary_data".  Similarly, if an attribute contains a list of other
> attribute or dimension names, using a suffix of "_attributes" or
> "_dimensions" in the attribute name makes the intention clear.  If an
> attribute can only name one variable, dimension, or attribute, then
> you could use "_variable", "_dimension", "_attribute" to indicate
> the intention that only one component is named, as in one-to-one or
> many-to-one mappings.  
> 
> I suspect this meta-convention hasn't been followed in all the
> coordinate variables conventions that have been proposed (although
> "_coordinates" is a good prefix, since it can name variables or
> dimensions), but if followed, it would permit extra checking analogous
> to what declarations in programming languages provide, that a variable
> name in such a list exists.  And it would make clear that such an
> attribute exists for structural purposes, to establish additional
> relations among the components in a dataset.  It could even be used to
> prevent components becoming separated from closely associated
> components when processing splits a file, since it would permit
> automatic determination of closely associated variables.
> 
> > * Give the ancillary variables a standard_name prefix of 
> "ancillary_data_for_".
> > They should also have all the metadata of their parent 
> variables, so they are
> > independently fully self-described.
> 
> Instead of prefixing a variable name with "ancillary_data_for", I
> would instead recommend using an attribute named something like
> "for_variable" or "for_variables" that names the variable or variables
> to which the information applies.
> 
> --Russ
> 
> _____________________________________________________________________
> 
> Russ Rew                                         UCAR Unidata Program
> russ at unidata.ucar.edu                      http://my.unidata.ucar.edu
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
>