TAP1.0 Comments

[Douglas Tody]

Hi Francois -

I wouldn't rule out the multiple tables option yet, but you need to
make a better case and we would need to think a lot more carefully
about how to provide such a feature.  Is the GDS query option not
enough? (I honestly can't tell yet from your responses).  Also I think
this really is getting to be a data model query, and not a classical
table query.  I probably requires some sort of POS,SIZE like query,
or maybe an expanded (as in GDS) query to fully address the problem.
We should understand this better before deciding on the best approach,
but I am sure a way can be found to provide this capability if it
has already been found to be popular with Vizier.

 	- Doug


On Wed, 15 Jul 2009, Francois Ochsenbein wrote:

>
> 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??is 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??is 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
> =======================================================================
>