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
Received on Thu Dec 28 2006 - 23:23:53 GMT
