UCD in the VO registry

[martin hill]

> (1.4) When you search for a restaurant in the Yellow Pages, you can query on
> where it is, and whether it is a Chinese or an Italian restaurant. You
> cannot see the menu unless you go directly to the resource, so it is not
> easy to query for a "restaurant that serves Birds Nest Soup" -- you will
> need to make several phone calls. Similarly with the VOregistry, you can
> query on Author and Title and Abstract, but the UCDs are not there, you need
> to go back to Vizier itself.

I'm probably a bit out of touch here, but in fact we (Astrogrid) *are* intending 
to hold table column descriptions (menu details) in registries, so that you can 
carry out exactly this kind of query.  But whether you look in the Yellow Pages 
or ring around, the business of seeing who's got Birds Nest Soup/Blue Near Stars 
is done using common words.  When it's *not* done with common words (many 
different languages!) it becomes impossible to do in practice. 

> (1.6) I do not believe that anyone should be attempting to "add a UCD
> element" to the registry. This would be much too fine grained, it is the
> table, or group of tables, that would be in a registry. Therefore I believe
> VOTable would be the best vehicle. In building VOTable we tried (against the
> objections of the XML junkies) to keep all metadata in a small, detachable,
> "head" piece, and all data as a subsequent stream of numbers that has no
> metadata, just tr and td elements. This head piece was always meant to be
> detached and stored separate from the data stream.

Hang on, so you *do* want to put column information in the registry??  While I 
(as an XML junkie obviously!) have problems trying to use VOTable with standard 
XML tools (eg try extracting data with XPath or XQuery!), VOTable headers seems 
reasonably comprehensive.

> (2.1) The UCD system is not meant to have the specificity of a data model,
> as Martin would like. My personal opinion is that it will be impossible to
> build a DM that is both widely accepted and sufficiently specific, and that
> a choice must always be made between standardization and specificity. In UCD
> we have chosen the former.

Ho hum so we have to do the impossible again!  What we are after is a theasaurus 
or dictionary with often-used common terms.  The fact that we can't even be 
*sure* of extracting which columns describe an object's RA and DEC from the 
registry is not good!  Similarly a common way of describing mag/flux, and 
possibly two or three other terms would probably be sufficient for 90% of 
queries...



-- 
Martin Hill
07901 55 24 66
www.mchill.net