New version of VO Support Interfaces: v0.26

[Paul Harrison]

On 09.05.2007, at 00:02, Ray Plante wrote:

> Hi,
>
> On Tue, 8 May 2007, Aurelien Stebe wrote:
>> We consider 3 different types of Metadata :
>> - Resource Metadata : the "curation" and "content" elements of
>> VOResource (creator, contact, description, subjects, ...)
>> - Service Metadata : the "capability" element of VOResource (URL
>> endpoint, service type, max records, ...)
>> - Table / IO Metadata : the "catalog" and "param" elements of
>> VOResource (table/column name, UCD, uType, input parameters, output
>> fields, ...)
>
> I appreciated this summary and essentially agree with Aurelien's  
> assessment.  In particular, he argues that table metadata should be  
> gotten from the service, which supports my call (on the other  
> thread ;-) for a common method for retrieve table metadata direct  
> from the service.
>

What it does not address it the terrible inefficiency of a client  
having to query every table service even to be able to select the  
services to enable an end user query of the style "I want to run a  
query over all tables that have a redshift column", which, as far as  
I am concerned, is the main motivation for "fine-grained" registries.

You could invent a specific service that does cache all table  
metadata and allow easy selection of services - sort of what Vizier  
does, only slightly less functional as the service needs only to  
return the service ivoa ids and table metadata, rather than be able  
to return the actual data.

Certainly the TAP group should not deprecate the placing of table  
metadata in the registry without simultaneously defining a Table  
Metadata registry service - otherwise they will severely decrease the  
efficiency/speed of the VO as a grid.

In my opinion it would be less effort (design,  implementation,  
deployment) to just allow this feature to be present in the current  
registry records rather than defining another service.

Paul Harrison
ESO Garching
www.eso.org