TAP 1.0: Substantive comments.

[Douglas Tody]

On Wed, 15 Jul 2009, Tom McGlynn wrote:

> 5. Returning a single result.
>
> I'm sympathetic to Francois' comments here, but opening up the possibility of 
> multi-resource VOTables may substantially increase the complexity of TAP 
> clients.  Would we allow resources within resources as well?  It's a little 
> hard to know where to end.
>
> A middle path might be possible though...
>
> I believe that internally Vizier queries a master 'table' [in quotes since 
> I'm not sure this it is at all relational] where it finds tables with 
> potential matches and then queries only those tables with matches.
>
> E.g., a URL like:
>
> http://vizier.u-strasbg.fr/viz-bin/votable?-meta&-c=287.5%2b2.05&-c.r=5
>
> returns a VOTable listing only the the tables which have data within some 
> radius (5" I think) of 287.5,2.05.  This query does not actually query these 
> tables, but just gave metadata about the query.  It's not organized as a TAP 
> result might be -- it puts each
> table in a separate RESOURCE, but it would seem pretty easy to expose 
> something similar as a TAP service which returned a VOTable with a single 
> resource and table.  Clients could either present the intermediate results to 
> users so they could select tables of interest, or go ahead and query Vizier 
> for the matching tables, recapitulating what Vizier does internally.

This is pretty much the same as the proposed GDS query.  This would
query a master table ("index" table describing all Vizier tables),
and find tables which are thought (based probably on coarser coverage
information) to have data in the indicated region.  The main difference
is that a single table would be returned describing each candidate
table as one row.  This summary table of candidate data tables could
be presented to the user or analyzed by the application.  A subsequent
query of each individual table would be required to more precisely
find the data in the indicated region for that table.

 	- Doug