for 'totally different functionally' read 'totally different semantically' at the end of the 1st paragraph. Too early in the morning.....
>>> "Roy Lowry" <rkl at bodc.ac.uk> 12/15/2006 8:41 am >>>
Dear All,
Reading through this I am now starting to grasp the issue and have to say that I am definitely with Steve in the 'this needs to be in a separate vocabulary'. A vocabulary needs to describe an entity that is clearly defined. I found it difficult to come up with a definition better than 'a collection of labels' for a list covering both the current Standard Names and the ensemble labels, which whilst similar syntactically and functionally are totally different functionally.
As to whether that vocabulary should be internal or external comes down to what is available. If there is a list out there somewhere being maintained with adequate (maintains quality to CF standard and able to respond to CF's needs on a reasonable timescale) content governance then it could be adopted. If not, we need to manage it through the CF mechanism. I would be happy to provide technical governance through the NDG Vocabulary Server if required.
Cheers, Roy.
>>> Steve Hankin <Steven.C.Hankin at noaa.gov> 12/14/2006 5:57 pm >>>
Hi All,
Alison, thanks for that detailed summary and plowing through past email
threads to summarize. Your efforts have made it possible for new comers
to join this discussion. (And your success points up again the work
that remains for us to do to better organize our discussion threads -- a
subject for another discussion.)
I'd like to add my vote to those who agree *yes, there is a need for a
new and separate "external (*)" vocabulary* -- a.k.a. a
"standard_metadata" attribute. The reasoning behind this conclusion
for me is brought into focus in the gridspec proposal, where you'll see:
standard_name = "link_base_path";
standard_name = "link_path";
standard_name = "grid_mosaic_spec";
standard_name = "grid_tile_spec";
standard_name = "grid_cell_area";
standard_name = "grid_edge_x_distance";
standard_name = "grid_edge_distance";
standard_name = "grid_edge_angle_WRT_geographic_east";
standard_name = "neighbor_cell_index";
standard_name = "vertex_index";
standard_name = "grid_x_coordinate";
standard_name ="anchor_point_shared_between_tiles";
standard_name ="orientation_of_shared_boundary";
etc. etc.
Jonathan makes the point that "we need a way of deciding whether new
metadata added within CF should be standard names or standard
metadata". I'd argue that it is our *process* for discussion that is
making questions like this challenging to answer. Namely, we have not
started from a clear statement of our requirement. Just below is a
straw man for the requirement statement. _Please hack it to bits!_
*Requirement: "A general mechanism is needed in the CF conventions
to identify variables (netCDF variables, that is), that function as
parts of CF data structures (grids, axes, coordinates, etc.)" *
If this is our requirement then this is _not _a requirement for a new
"external" vocabulary (see "*" from paragraph 2 above). It is an
internal vocabulary that should be fully documented in the body of the
CF standard. And it is under the sole control of those who are
developing the CF structure conventions.
Arriving at a clear statement of our requirement will often be lengthy
process of iteration. And in the present context there will be specific
names of variables that remain ambiguous cases. The term "ensembles"
may be one of those ambiguous cases. I lean towards the argument that
says "ensembles" has been proposed as a way to identify a new dimension
of the CF grid data structure (now 6-dimensional). Therefore it belongs
in the CF conventions -- not in the external list of standard_names.
But I'd agree this is an ambiguous case, when one compares to, say, a
dimension identified by 'standard_name="longitude";'.
Personally I do not like the attribute name "standard_metadata". The
use of the word "standard" seems to imply that there is an external
"standard" as there is with "standard_name". This is not the case, if
you accept the above. I'd lobby for something more like
"structure_element"?
structure_element = "grid_mosaic_spec";
structure_element = "grid_tile_spec";
structure_element = "grid_cell_area";
structure_element = "ensemble_axis"; <=== !!!!
- Steve
===============================================
Pamment, JA (Alison) wrote:
> Hello Jamie, Paco, Jonathan and Roy,
>
> Thank you all for your recent comments. Firstly I would like to make a
> general point about the purpose of the standard name status reports. They
> are intended to achieve two things: (1) to keep everyone up to date with the
> state of play on the various standard names threads without having to
> follow every discussion in detail; (2) to identify the unresolved issues
> and prompt further discussion. Writing the summaries helps me to keep things
> straight in my own mind and I hope they are useful to others, if only to
> reassure people that their proposals have not been forgotten, especially when
> progress is slow. Preparing the summaries is, of course, a subjective process
> and sometimes I will get things wrong - I am always happy for people to point
> out when I have made a mistake or misrepresented something.
>
> My summary of the ensembles discussion concluded with:
>
>> Given the direction that the discussion has taken since the initial
>> proposals were made on 15th October 2006 I will now close "ensembles" as a
>> standard names issue. The names will _not_ be added to the table.
>> However, ensembles will most definitely remain open as a CF1.0 conventions
>> issue.
>>
> This seems to be causing some concern. Before writing this I reread the whole
> of the ensembles discussion and I believed this to be the point that had been
> reached in the conversation. Since Bryan's posting of 27th October there has
> been no further discussion of the specific standard name proposals. Rather,
> the question has been whether or not standard names is the correct mechanism
> for labelling metadata.
>
> My overall impression was that people felt that being able to specify an
> external vocabulary or standard metadata would be a useful addition to the CF
> standard. There seemed to be general agreement that it could
> accommodate ensemble metadata and also other types of metadata that may be
> needed in the future. Rereading again today I realise that there are a couple
> of points raised by Jonathan that should have been included in my summary but
> weren't. They are:
> (1) if we adopt Bryan's proposal then we need a way of deciding whether new
> metadata added within CF should be standard names or standard metadata;
> (2) when using external vocabularies we would need to be sure of the format and
> content - these may need to be agreed with the vocabulary owner.
> Regarding (1), Bryan has suggested that standard names should be used to
> describe the content of variables that relate to the physical world while
> standard_metadata would describe how the data were produced (i.e., details of a
> model or observing system). Jonathan (23rd October) has suggested that it is
> not always straightforward to decide whether something should be a standard name
> or standard metadata, so it would be better not introduce the standard_metadata
> vocabulary.
>
> The upshot of this is that there are actually three alternative approaches on
> the table, rather than the two detailed in my summary:
> (1) use standard names for ensemble metadata;
> (2) use standard names to describe physical variables, for metadata use
> external vocabularies where possible and introduce a new CF vocabulary called
> standard_metadata for situations where a suitable external vocabulary does not
> exist;
> (3) use external vocabularies for metadata where possible and add new standard
> names where a suitable external vocabulary does not exist.
>
> Clearly there needs to be a decision on which approach to take before any
> specific proposals can be taken forward. On balance, it seems I was premature
> in declaring the issue completely closed as far as standard names are
> concerned. However, I would certainly say that the standard name proposals are
> "on hold" pending a decision on strategy.
>
> It remains my impression that external vocabularies are generally agreed to be
> a useful tool, albeit one that should be used with care. For ensembles in
> particular, my understanding is that no suitable external vocabulary exists, so
> in this instance we will need to add the metadata within CF. All
> of which leaves one question: do we want to introduce a new attribute called
> standard_metadata, with an associated vocabulary, or do we want to add metadata
> names as standard names? I would still argue that this is really a conventions
> issue at the moment, rather than a standard names issue, and that it deserves
> as wide a discussion as possible.
>
> Best wishes,
> Alison
>
> ------
> Alison Pamment Tel: +44 1235 778065
> NCAS/British Atmospheric Data Centre Fax: +44 1235 445858
> Rutherford Appleton Laboratory Email: J.A.Pamment at rl.ac.uk
> Chilton, Didcot, OX11 0QX, U.K.
>
>
>
>
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
--
--
Steve Hankin, NOAA/PMEL -- Steven.C.Hankin at noaa.gov
7600 Sand Point Way NE, Seattle, WA 98115-0070
ph. (206) 526-6080, FAX (206) 526-6744
--
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.
_______________________________________________
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 15 2006 - 01:51:32 GMT
