TAP1.0 Comments

[Francois Ochsenbein]

Hi Doug,

I'll first discuss a bit with Francois Bonnarel -- 
but a priori our current solution works pretty well
without having to wait for another 2 or 5 years ;-)
and Aladin is a example which can perfectly deal with
multiple tables -- and savot can do it too...

I would like to have Pat's point of view too.

Other news in the near future...

Cheers, francois

>
>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.
>>
>>
=======================================================================
Francois Ochsenbein    ------   Observatoire Astronomique de Strasbourg
   11, rue de l'Universite 67000 STRASBOURG  Phone: +33-(0)390 24 24 29
Email: francois at astro.u-strasbg.fr (France)    Fax: +33-(0)390 24 24 17
=======================================================================