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
>
Received on Fri Apr 11 2003 - 06:53:13 BST
