UCD in the VO registry

[Roy Williams]

(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