Dear All,
There seems to be a slight misunderstanding about the crux of the debate. The discussion John G and I had last week hinged on the identity of the entity represented by the URI. To him it was the term: to me it was the phenomenon described by the term.
In the vocabularies I manage, the latter is the case. Consequently, I represent the phenomenon by a semantically neutral key and 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.
In the case of the Standard Names, the governance is strong enough for me to be almost convinced that it's OK to consider the term as the entity and hence include it in the URI. However, I have encountered other vocabularies where terms have changed syntactically (usually to clarify semantics) and the previous version has simply vanished. If the previous version has been deployed in URIs then our semantic infrastructure breaks. To my thinking establishing the use of keys fails safe as they are less likely to get tweaked in a moment when discipline weakens.
On the URI=URL/URN debate, I'm a pragmatist. I can make practical use of a URL today: with a URN I need to find some way of describing and implementing business rules to translate URN to URL. This is what I imagine registry technology delivers but I see this as today's development area, but for the next generation operationally.
Finally, I need to make it clear that I would never suggest using a meaningless (to humans) URI in CF in place of any existing field and am not trying to degrade the self-describing nature of CF. I see URIs as extra hooks that open semantics to computers. These hooks link into ontologies to form a basis for semantic interoperability without forcing everybody to rework their legacy data to new standards. 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.
Cheers, Roy.
>>> Jonathan Gregory <j.m.gregory at reading.ac.uk> 03/22/07 5:40 PM >>>
Dear John
The argument appears to be than an unintelligible identifier (i.e. one without
semantic content) is good because it is in itself meaningless, so you have to
look it up to find out what it means, whereas if you use intelligible names,
you might be misled by misunderstand them. Is that right? I appreciate that
this is rational, but I'm not convinced it is the most helpful approach for
humans. That would be an argument against self-describing netCDF files, for
example. It would argue that the metadata in the files should be totally
cryptic to humans, so that you had the use the latest version of an approved
translator to tell you what it means. That has some attraction, but I'm not
sure it really solves the problem. The translator will use its own idioms,
which the human user will get used to, and if a new version of the translator
gives new meanings to the words it uses, you are back in the same problem.
It seems to me better to admit that one always has be careful at some level,
and use names that have some apparent meaning.
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.
Received on Mon Mar 26 2007 - 13:17:55 BST
