On Jul 25, 2006, at 17:36, Rob Seaman wrote:
> On Jul 25, 2006, at 7:56 AM, Nausicaa Delmotte wrote:
>
>> I would say that the more examples we give in the reference UCD
>> document,
>> the easiest it is for a user to be convinced that the correct UCD
>> was assigned.
>
> If the logic behind UCDs may only be correctly grasped by example,
> UCDs might just as well be opaque tokens assigned randomly. It
> seems to me that the whole point of the exercise is to illuminate
> (at least partially) the intrinsic structure that underlies
> astronomical nomenclature. Given a categorized value, what are the
> rules for constructing quantities contingent on that value? Given
> a complex UCD expression, how does one parse it without consulting
> documentation such as a master list?
>
> Users need to understand other people's UCDs - they may also need
> to assign their own. UCD fluency won't be established through
> better documentation (not that this hurts), but rather must be
> built into the linguistic structure of the "language".
I do agree, but ... how to make it happen?
I mean, a pragmatic service provider would want to read (and real fast)
the existing ucd documentation and start using ucds asap.
Kids learn the linguistic structure during their kindergarden phase,
using the trial and error method.
How can we succeed, that is make such service provider happy, and
at the same time reach desired "UCD fluency" without asking the
service providers to go through the kindergarden phase?
I do agree with Nausicaa, we need more examples, and probably more comprehensive UCD descriptions (not just only the couple of words currently listed for each ucd); not too much, but just enough to not have anyone repeating the same errors again and again, and to avoid confusion (e.g. meta.code while one really means meta.id, meta.id while one really means meta.code, ;-) etc.)
Al Received on 2006-07-25Z17:56:46