TAP1.0 Comments

[Francois Ochsenbein]

>
>On Thu, Jul 16, 2009 at 10:22:16AM +0200, Francois Bonnarel wrote:
>> I was also wondering about this single table output issue because I
>> had use  cases in mind where it could be a great constraint
>> (Observation metadata in the larger extent) What would be the price
>> to pay to remove this limitation?
>
>Well, at least the nice symmetry that the output of a TAP service can
>be used as the upload for another would be sacrificed, unless one
>lifted the requirement on single-table uploads.

===> But hopefully you can upload several tables to be used in a query
     (section 2.5.1 of TAP document) -- and anyway apart from 
     cosmetic aspects, there is no reason for a symetry here.

>Allowing multi-table uploads, however, is IMHO a relatively high
>price to pay (without having thought too much about it, it seems
>there a tricky points defining the semantics of such an operation),
>too high indeed in the late stage of an RFC.
>
>Because of that -- and of Gerard's observation that TAP currently
>defines no query language that would allow you to generate
>multi-table responses -- I'd suggest we leave the single-table
>requirement and postpone multi-table responses until we have more
>experience with TAP.

===> Here I think it's a mixture between TAP and the query language;
     if neither AQDL not PQL currently can return more than one table,
     the conclusion should not be, imho, a requirement that TAP returns
     a single table. 
     
There are really many cases where getting as a result more than
one table is useful and brings a lot more efficiency: the example
of generic searches among a collection of tables is an example,
but you also have the examples of complex databases. For instance
with Simbad, a comprehensive result can hardly be made of a single
table if you expect to get what is known about a single object
which combines queries from several tables (with designations,
bibliography, photometry, etc etc). With the one table output
limitation, getting what's known in Simbad for one object would 
mean:
-- either giving the result in a single call as a large table
   which combines everything -- meaning a lot of repetitions,
   a lot of empty columns;
-- or provide just a key to every bit of data, meaning a lot of
   correlated queries
In both cases, the method is totally inefficient -- either a
lot of useless descriptions and  empty columns or repetitions
transiting over the wire, or a lot of requests to get everything.
In the second case moreover, the information supplied may be 
incomplete if the correlated queries are not properly understood
and executed by the application. 

Maybe the conclusion for us should be, in the case of a single-table
output, that TAP is not the solution for these two services 
(Simbad and Vizier) ? 

--Francois
=======================================================================
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
=======================================================================