TAP1.0 Comments

[Douglas Tody]

Hi Paul -

If we need this kind of integrator capability I am sure we can find
a way to provide it; it is just that it may be that TAP is not the
right interface for this.  It is fairly fundamental for a table query
interface to return a table result.

I thought the main point here was that it was hopeless to query all
8000 tables looking for data in a small region.  If we first find all
tables with data in the small region then probably the 8000 goes to a
much smaller number which can be queried individually without breaking
the relational model and complicating the TAP interface even further.
Personally if I had a client application that needed to do this I think
it would be easier to get the contents of each individual table with
a separate small query, rather than have to use additional software
to extract the tables from a VOTable container (most VOTable clients
cannot deal directly with multiple tables).

Francois - can you please clarify?  Would one of the solutions I
proposed provide what you want, or is something more required?
Perhaps it would help to stop talking about TAP and instead back up
and describe the use-case more directly.

 	- Doug


On Wed, 15 Jul 2009, Paul Harrison wrote:

>
> On 2009-07 -15, at 12:38, Douglas Tody wrote:
>
>> Basically what this would allow you to do is build an index table for
>> all the 8000 or so Vizier tables.  It could be queried with a GDS query
>> (in TAP probably) to find the tables of interest.  These would then
>> be queried individually with TAP.  Aside from being simpler, I think
>> this is more convenient and flexible for the client than getting all
>> the query responses in one big file from which they would then have
>> to be extracted.  If we really wanted that it could be done with an
>> integrator service of some sort.
>
>
> Doug,
>
> I think that you have missed the point here - Vizier *is* such an integrator 
> service. This was precisely what François was saying, and pointing out that 
> the client does not want the inefficiency of doing 1+N queries where N is a 
> large number when in fact they could do just one when querying Vizier. I 
> think that the additional point that was made was that in an all catalogue 
> search Vizier can return different columns for each table (catalogue) that 
> matches, which is why François wants to be able to issue multiple tables 
> within a single VOTable document. It seems rather a shame to disallow this in 
> TAP in many ways as VOTable is supposed to be self describing, so that the 
> client should be able to "understand" the multi table result just as easily 
> as they can a single table result.
>
> Cheers,
> 	Paul.
>
>
>
>
>
>