UCD in the VO registry

(1.1) In the current VO resource, everyting has Curation metadata, and there
is additional support for describing Services beyond their Curation metadata. This is because we have assumed that Services are the interesting things people will put in the registry. If people really want to put Tables
(or any other kind of data object) in the global registry, then now is the
time to speak.

(1.2) In Vizier, there is a "catalog" object which generally comes from a
published paper (curation metadata = Title, Author, Abstract etc),and this points to one or more "table" objects that have the same sort of metadata as VOTable (including UCD).

(1.3) The VOResource is not expected to hold all metadata. It is well suited
to the curation (catalog) data of the Vizier. But it is not built (as currently stated) to hold VOTable headers, and therefore does not indicate UCDs.

(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.

(1.5) It is quite possible to build a registry that concentrates on a
specific resource type (eg Tables), and uses a schema which includes VOResource. It would interoperate with standard VO registry at the curation level only. However, it would offer additional interfaces and queries for its specific metadata (eg tables, UCD, elephants etc).

(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.

(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.

(2.2) A UCD is a semantic type, not an instance. It is semantically
different from a Name. In a table, I *must* have different names for the columns, and thus the query is unambiguous. But a table can easily repeat its UCD -- perhaps a table of double stars where there are four columns RA, Dec, RA, Dec to show the positions. So the idea of writing a query with UCD as "select RA, Dec from Table" is just plain wrong -- no matter how specific the UCDs are. The point of the UCD is show what is interesting, not to carry us with certainty to the end.

Now I go back to sleep!
Roy

---
Caltech Center for Advanced Computing Research
roy-at-cacr.caltech.edu
626 395 3670