TAP1.0 Comments

[Gerard]

Dear Francois and others

On Mon, 13 Jul 2009, Francois Ochsenbein wrote:

> First, the question of TAP result in a single *table* : Alberto's
> question is quite right, and I'm afraid the reduction of the
> result to a single table will generate problems for us (vizier)
> and likely for other services. Yes the relational model implies
> that the result of any query is a single table -- but sticking
> to this means that queries like "give me all objects from any
> table this region of the sky" is not possible. Such questions
> however are quite frequent... How to deal with those ? I see
> only the following alternatives if TAP sticks to a single
> output table:
> a. the client asks for tables existing in the service;
> upon the answer (7896 tables), the client generates
> 7896 queries. Not really realistic :-(
> b. the server creates some kind of minimal common schema
> between all these tables -- in practice this can only be
> the position and the table name (i.e. a 3 column table).
> But then you have to get more details about each result,
> details concerning data and as well as metadata.
> Therefore you still have to generate many 'children' queries.
>
> Or should services like vizier give up with TAP ?

About Francois' request for supporting multiple tables in a TAP query
result.
First, I have read 2.7.1 as implying that a TAP service is supposed to
return a single TABLE, wrapped in a single VOTable for a given query.

It seems to me that whether one requires support for multiple TABLEs depends
on the query language that is used.
If the language allows queries that return multiple tables, then TAP should
support multiple TABLEs to be returned, but in a single VOTable.
Currently, if I am not mistaken, ADQL does not support such queries, and
neither does PQL (correct?).
Many databases allow concatentaion of queries separated by a semi-colon and
produce multiple result sets.
ADQL might well be extended to allow this as well (in a future version!).
With that in mind, and possible similar behaviour of other query languages,
there seems no reason to prescribe in the TAP standard that
a single TABLE must be returned in the VOTable result.

Francois' use case for "select * from any table where ..." is a requirement
on the query languages, not on TAP.
ADQL does not (and hopefully will never) allow such queries, unless "any
table" is in reality a single table that somehow represents all tables in
VizieR, for example through some common data model. Note, in that case a
single tabular result will be returned ofcourse.
Whether PQL, or some future language for querying GDS should support this is
up to those languages.

I don't see why these aspects of the proposed standard would make TAP
irrelevant for VizieR.
Finally there will be a standardised way to write queries joining different
tables in VizieR to each other and to do so using an agreed upon language.
And it is now up to the VizieR team to possibly add new tables that add
value to their data set, for example the master table proposed by Tom.

Cheers

Gerard