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
Received on 2007-05-09Z09:38:50