Ah,
Understanding is starting to dawn. My interpretation of your proposal was that there would be a whole raft of new Standard Names covering the categories you describe, not just names for the categories, which I don't see as a problem.
I also agree with you that there will be an increasing need standardisation of string quantity "possible values", which is what I'm trying to achieve through the NDG Vocabulary Server (
http://vocab.ndg.nerc.ac.uk/client/vocabServer.jsp) for technical governance and the SeaDataNet/IOC MarineXML vocabulary content governance group (SeaVoX) for content governance. I'm pretty sure this is what Bryan was thinking of with the external lists pointer. Incidentally, anyone on the CF list interested in this type of vocabulary who would like to get involved with SeaVoX then let me know.
Cheers, Roy.
>>> Jonathan Gregory <j.m.gregory at reading.ac.uk> 12/29/06 10:35 AM >>>
Dear Roy
> Consider a case where a metadata record has two fields, one for geographic
> coverage and one for parameter. If selection drop-downs for these are
> covered by two separate lists - either vocabs or within an ontology - then
> 'sea_temperature' will not appear in the geographic coverage drop-down and
> 'Atlantic_Ocean' will not appear in the paramer drop-down. Were both
> drop-downs covered by a single ' Standard Name list' then both terms would
> appear. This not only increases the risk of field population with nonsense
> (the type of error I was visualising - admittedly it's still possible to
> call temperature salinity), but also makes the drop-down appear eccentric to
> say the least.
We distinguish between lists for (a) standard names (b) the possible values of
quantities which have a standard name. "atlantic_ocean" is not a standard name;
it is a possible value for a variable whose standard name is "region". A menu
of standard names would includes sea_surface_temperature, rainfall_flux,
latitude, region and land_cover (to list a few from the present table) and
also (if my proposal is agreed, to meet Paco's requirement) source, institution
and experiment_id. These are all names for things which a data variable or a
coordinate variable could contain. The *values* of these variables are dealt
with in other ways. sea_surface_temperature, rainfall_flux and latitude are
numeric, so no list is needed. The others are string-valued. At present only
region has standardised values; the possible values are given by
http://www.cgd.ucar.edu/cms/eaton/cf-metadata/region.html
It's quite likely we might develop a standard list for land_cover. As we have
discussed a lot, it would be useful to make links to other people's controlled
vocabularies if we can, and the proposal also includes a new attribute to point
to external lists of the possible values for a quantity (Bryan's suggestion).
> Jon's comment that we can carry on as we are now and change later worries me a little. So many times in my work with metadata I have found that aggregation is infinitely easier than teasing things apart.
It is right to be cautious, but I think this reasonable concern of yours is
that things should be sufficiently informative. I agree with you. That's why
we spend so much time making sure we know exactly what quantity is being
identified by a standard name, and why quantities with different physical
dimensions (units) have different standard names. In this case, I think we
are talking about a categorisation that can be introduced whenever we need it.
There are only 814 standard names at present, so it would not be a big job to
classify them in future, given a clear criterion for doing it - which is what
we lack, since we don't have a need for it (as far as I can see).
Cheers
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 Fri Dec 29 2006 - 06:46:27 GMT
