UCD in the VO registry

[Tony Linde]

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

Yes we do need Tables in order to construct queries.

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

And this is why.

> (1.3) The VOResource is not expected to hold all metadata...

Yes it is. At least in definition. If an implementation of the Registry
decides *not* to store all the metadata and make calls out to the services
for their metadata then that is okay. The key point is that a Registry
service has to answer all the metadata quesitons about any resource. For
AstrGrid, we will store this in the Registry so that quesitons can always be
answered without worrying about contacting all services.

> (1.4) ...but the UCDs are 
> not there, you need to go back to Vizier itself.

No. We don't want to have to make loads of calls to services just to answer
a query on the registry.

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

The schema should be inclusive otherwise we cannot build standard queries. A
registry or other service may offer facilities outside the IVOA standards
but if we cannot construct a simple registry query because each registry has
a different way of referring to tables (for example) then we'll never get
anything to work without lots of human interpretation of metadata.

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

Again, I think the schema must be fine grained but any particular
implementation of the registry can decide its own granularity and simply not
replicate or harvest the finer details.

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

I agree that standardization is difficult but we should look at what we want
to do in the VO. We will want tools to be able to act on metadata so the
metadata must be standardized to a reasonable level.

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

Which is why the metadata must include both UCDs and column names so that
where the UCD is not unique, the query constructor can ask the user to pick
the ones they are interested in.

Cheers,
Tony. 



> -----Original Message-----
> From: owner-registry at eso.org [mailto:owner-registry at eso.org] 
> On Behalf Of Roy Williams
> Sent: 26 September 2003 12:23
> To: registry at ivoa.net
> Subject: 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
>