Hi Jonathan,
Jonathan Gregory wrote:
>Dear Ethan
>
>Thanks for this document. It might be useful to advertise it to GO-ESSP,
>perhaps, for their comments? I am not experienced with what kind of metadata is
>needed in the file for discovery purposes but that is a concern of GO-ESSP.
>
>
Good thinking. I will send a note to GO-ESSP as well.
>* CF defines some global attributes already (section 2.6.2). title and history
>are in common with your list. What about institution, source, references and
>comment? All these seem useful to me. Possibly institution and source could
>serve the purpose of your summary and project attributes. Maybe the
>naming_authority is the same as institution. Many datasets come from an
>institution rather than from a named author and contributors. I think such
>overlaps should be resolved if we are going to add more recommendations for
>global attrs to CF. I see that you have a note at the end which is relevant
>to this.
>
>
We will be pushing this proposed attribute convention (once more fully
developed) beyond the CF arena. So, we haven't been thinking of this
proposal as an addition to CF but rather as a seperate convention that
would work well with CF as well as other conventions.
Our target has been to feed into the THREDDS defined discovery metadata.
So, there is a lot of overlap with existing CF attributes but it isn't a
perfect match. This is part of what I would like to work out: renaming
some of our proposed attributes to better fit with CF and/or deciding
how CF attributes would map into the proposed attributes.
I'll put together another table trying to map the proposed attributes to
existing CF attributes and we can use that to talk about this issue.
>* The THREDDS data types appear to be characterising individual variables, not
>files. Perhaps thredds_data_type should be a variable attribute therefore.
>
>
The proposed convention is aimed more at dataset rather than variable
discovery. So most of it is aimed at a fairly hight level.
We have generally used it to characterize files. For instance, a file
might contain a collection of trajectories, each trajectory contains N
variables each with a value at every point on the trajectory. We haven't
dealt with many/any files that combine grid, image, point, trajectory
and such yet. Do you guys see combining of data types in the same file much?
>* I'm not clear what you mean by date_valid. Is it really helpful to
>distinguish so many dates? What would you use them for?
>
>
Good question. A lot of the date stuff kind of migrated into THREDDS
from digital library metadata standards (e.g., Dublin Core) which don't
really define the differences all that well either. If anyone has any
ideas about the various types of dates, I'd like to hear it. Unless I
hear arguments for all of those date variations, I'd like to reduce the
number of them.
>* processing_level seems rather vague. Couldn't that kind of information be
>included in the source/summary attributes?
>
>
Yes, rather vague and could be included in summary. I'll have to take a
look at what we are doing with this.
>* The spatial and temporal coverage of the data can be deduced from the
>coordinate variables. The data variables might have many different such
>ranges. This information is redundant and would have to be rewritten if a
>subselection is made, so could easily go wrong. Including such attributes
>therefore worries me. The same applies to the suggested geospatial_
>attributes. This very specific information has more to do with individual
>variables than with files.
>
>
Again, we are looking at dataset discovery rather than variable
discovery. And we are hoping to make harvesting the discovery level
information easier. So that applications harvesting this information
won't have to understand all the coordinate variables and geolocation
information, the geospatial_ attributes would allow for that information
to be bubbled up to a higher level. I agree that containing this
information in the dataset may not always be the best idea. There need
to be ways of bubbling this information up that are outside of the
datasets. THREDDS is working on some ways of doing that.
Thanks for your comments,
Ethan
>best wishes
>
>Jonathan
>_______________________________________________
>CF-metadata mailing list
>CF-metadata at cgd.ucar.edu
>http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
--
Ethan R. Davis Telephone: (303) 497-8155
Software Engineer Fax: (303) 497-8690
UCAR Unidata Program Center E-mail: edavis at ucar.edu
P.O. Box 3000
Boulder, CO 80307-3000 http://www.unidata.ucar.edu/
---------------------------------------------------------------------------
Received on Tue Jun 14 2005 - 13:42:22 BST
