⇐ ⇒

[CF-metadata] Getting back to ensembles

From: CJ Beegle-Krause <Cj.Beegle-Krause>
Date: Fri, 29 Dec 2006 14:52:51 -0800

hello everyone,

A splash to add a bit of momentum for Jonathan's arguments, from someone
that works in modeling for decision support. There is a strong division
between "what is happening" and "where it is happening". The experts in
the "what is happening" have to be able to talk to and overlay their
information to the local resource (human and environmental) experts for
the "where it is happening" context. There is a little known
publication "Recommendations for Probabilistic Seismic Hazard Analysis:
Guidance on Uncertainty and the Use of Experts" sponsored by the Senior
Seismic Hazard Analysis Committee that states this most clearly.
Generalizing from this report, one needs to understand the phenomena,
and then combine that expertise with a "resource expert" that will have
"site-specific experience that will be of use". So when I do an oil or
chemical spill trajectory, someone else is going to be combining it with
the local resources at risk. This combined information needs to be
useful to those who want to understand the situation. Though we aren't
at the point where we can easily do this in a single file in 3D, that
day is coming.

Hope this helps.

Cheers,
CJ

Roy Lowry wrote:

>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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20061229/f341164d/attachment-0002.html>
Received on Fri Dec 29 2006 - 15:52:51 GMT

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:40 BST

⇐ ⇒