Hi Nan,
The mislabelling argument doesn't work in a well-designed system - the user never sees the keys through the use of interface tools like combo boxes. Note that I am not advocating replacing the Standard Name in a CF file - it's how that Standard Name is represented in an ontology that's at issue. Adding the ontological tag to a file is a convenience, but not essential for CF. As I intonated, in the case of CF keys/terms is not a real issue, but with other vocabularies - particularly those dealing with biology where 'terms' can hit 300 bytes long and lack stability - it is. I was advocating keys to CF for the sake of a consistent approach to ontological labelling, but as Luis said offline dealing with the inconsistency isn't that hard.
Becoming CF compliant is a nice idea for SeaDataNet, but impractical. BODC has about 150,000 data objects covering something like 5000 parameters. Around the SeaDataNet community are about 500,000 MEDATLAS format files marked up using a Mediterranean/Black Sea community vocabulary again covering a lot more chemistry and biology than CF. Extending the Standard Name list to cover this lot and then reformatting everything to CF isn't viable. Instead what I am trying to do is identify the overlap with CF and put tools in place that will eventually lead to dynamic extraction of CF-compliant netCDF from the existing databases within whatever parameter space is covered by the Standard Names.
Cheers, Roy.
>>> Nan Galbraith <ngalbraith at whoi.edu> 3/26/2007 10:13 pm >>>
>
>
Hi All -
> Consequently, I represent the phenomenon by a semantically neutral
> key ...
My most extensive experience with "semantically neutral keys," EPIC
parameter codes, is that users routinely mislabel items when using
meaningless codes. This is one of many reasons we've moved to CF
from EPIC NetCDF.
> ... feel at liberty to change the term providing I don't change the
> entity it represents (e.g. correcting a spelling error or changing
> syntax). If the term is considered the entity then a spelling error
> would need to be fixed by leaving the error in place, putting the
> correct spelling up as a new term and mapping the two terms as
> synonyms.
The trade-off between possibly having a few duplicate tags in a
single document on the CF namespace server and requiring people to
adopt meaningless codes for parameters - when we have a carefully
chosen, community-based set of standard names at our disposal - seems
to tip quite clearly in favor of using standard names.
Maybe I've missed something, but I have not seen an argument yet that
explains
how adding one level of abstraction by using a system of human-meaningless
keys buys you a net gain in certainty of what you'll find at a location
to which
that key points.
> This is how I'm planning to bolt SeaDataNet and NERC DataGrid
> together and it would be nice if the result were interoperable with
> CF.
Yes, it would be nice if you decide to be CF compliant, but we certainly
would not try to force you to be.
Cheers - Nan
--
**************************************************************
* Nan Galbraith Upper Ocean Processes Group *
* Woods Hole Oceanographic Institution Woods Hole, MA 02540 *
* http://uop.whoi.edu (508) 289-2444 *
**************************************************************
--
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 Tue Mar 27 2007 - 01:40:53 BST
