Rob Seaman said...
> I'll say it again - users are not going to understand how to use
> UCDs. This may or may not be acceptable - it depends on whether
> our users will ever need to either parse other people's UCDs or
> create their own.
>
> More generally, the question isn't whether UCDs make *any* sense -
> there appears to be a defensible logic behind every individual
> distinction that is raised. The question is whether the same logic
> lies behind all choices - and further, whether the logic is stable
> over time.
> It isn't that I don't understand the logic behind the choice - it's
> that many other choices are just as logical. Why make *this* choice?
I think there is reason to worry if the official list of UCDs can only be justified a posteriori. If nobody else feels the same way, by all means continue with the adoption of the new batch. In addition to versioning and a verification tool, I would then reiterate my support for retaining the ability to namespace UCDs.
> Ok. So *both* meta.code.class and meta.class.code are to be
> supported? And is our software supposed to be able to understand
> these razor thin distinctions and do something usefully different?
>
Hear, hear! Yes, the list grew in a historical process somewhat organically, and yes we're all very glad that those who worked in the initial development who had other things on their minds than the long- term evolution, but THIS is the time - not later - to put the UCDs on a firm symantic foundation and to clearly define how to create words and how to clearly avoid naming a concept for which no one can find a meaning.
Thus, I concur that we need a very explicit and robust set of guidelines, e.g.
> I recommend:
0) UCD constructions DO NOT constitute a formal ontology and are
intended to be clearly understood, chosen, and interpreted within the
context they are used. Thus, long _generic_ hierarchies should be
avoided (e.g. meta.code.class.enum).
> 1) UCD versioning be explicit
> 2) a UCD verification web service be assigned high priority (that
> is, beyond checking syntax and atoms)
3) UCD words can be contracted if the uncontracted form is cumbersome or if the contracted form constitutes a commonly recognized abbreviation, but uncontracted forms are to be preferred and length is per se no constraint.
4) UCD words should not be contracted if the meaning of the contraction is not clearly understood outside of it's immediate context
...
Rick
Dr. Frederic V. Hessman Hessman-at-Astro.physik.Uni-Goettingen.DE Institut für Astrophysik Tel. +49-551-39-5052 Friedrich-Hund-Platz 1 Fax +49-551-39-5043 37077 Goettingen Room F04-133http://www.Astro.physik.Uni-Goettingen.de/~hessman
http://monet.Uni-Goettingen.de ------------------------------------------------------------------------ -------------------------Received on 2006-07-27Z19:05:29