Dear Jon/John,
Let me try and answer John's comment 'But I don't see how either will prevent selection errors' by a simple example.
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.
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.
Cheers, Roy.
>>> John Graybeal <graybeal at mbari.org> 12/29/06 6:23 AM >>>
I agree that some terms are not useful to describe science values, and you may want to distinguish those terms from the others in the vocabulary. How you do that -- with separate vocabularies, or just by characterizing each term in the one vocabulary according to its ontological class -- is a design decision. Either approach could be used to pre-fill drop-down lists, which is useful. But I don't see how either will prevent selection errors.
Note that this question generalizes -- CF is fundamentally about climate and forecast terms so far, but a lot of us are trying to apply it to more concepts and terms, and not just in-situ or scientific ones. To what extent (and how) will CF evolve into a set of vocabularies? While such an evolution may prove valuable or necessary, I agree you should have a guideline or process that describes how to distinguish terms.
John
At 10:50 AM +0000 12/27/06, Roy Lowry wrote:
>Dear All,
>
>I still think having separate vocabularies for separate metadata attributes is the better way to go. I would prefer two vocabularies with overlapping term sets to the the possibility of populating a field with an inappropriate term. If the metadata attributes pertain to clearly different entities then so too will the vocabularies.
>
>Having separate vocabularies permits automated population protection on each attribute - it's amazing how easy it is to select the wrong item from a drop-down list through an unintentional slip of the mouse.
>
>Does anyone agree?
>
>Cheers,Roy.
>
>>>> Jonathan Gregory <j.m.gregory at reading.ac.uk> 12/23/06 9:03 PM >>>
>Dear Steve, Paco et al.
>
>> IMHO the above paragraph cannot really be said to be a requirement :-\
>> . It begins with a proposed implementation ("may have a dimension
>> which serves as an index") and follows up with some of the
>> functionality that can (and cannot) easily be achieved through that
>> implementation.
>
>Yes, I agree, I should have taken a step back from the index dimension. So
>I would rephrase the requirement as follows:
>
>A means is needed (a) to aggregate data variables from the members of an
>ensemble, derived from different models, integrations, institutions supplying
>the data, etc., where the data from each ensemble member is a function of the
>same spatiotemporal coordinates and/or other physical independent variables;
>(b) to provide metadata identifying the ensemble members.
>
>Then the proposed implementation begins:
>
>We propose to introduce a dimension for the data variable to serve as an
>index over the ensemble members.
>
>and continues by proposing auxiliary coordinate variables, etc., as in my
>last posting
>http://www.cgd.ucar.edu/pipermail/cf-metadata/2006/001397.html
>
>The requirement covers the areas you (Steve) have given (in more detail) in
>your points 1-3. Your requirements 4-6, however, are about functionality which
>programs processing the data might need to have. While I agree we should bear
>in mind the convenience of processing the proposed metadata, and hence that is
>a consideration in deciding which implementation to choose, I don't think it
>forms part of the requirement. CF is a metadata convention, not a specification
>for data processing software.
>
>Paco, does the present proposal meet your requirements? If so, I would urge
>that we adopt it. We still have the question about whether the new metadata
>items should be given standard_names, or some other atttribute. I would suggest
>that they should be standard_names unless anyone can propose both a requirement
>for a distinction and a reliable objective test which defines that distinction.
>
>Best wishes
>
>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.
>
>
>_______________________________________________
>CF-metadata mailing list
>CF-metadata at cgd.ucar.edu
>http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
----------
John Graybeal <mailto:graybeal at mbari.org> -- 831-775-1956
Monterey Bay Aquarium Research Institute
Marine Metadata Initiative: http://marinemetadata.org || Shore Side Data System: http://www.mbari.org/ssds
--
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 - 03:11:12 GMT
