>
>
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 *
**************************************************************
Received on Mon Mar 26 2007 - 15:13:44 BST
