resuming progress on TAP

Doug Tody dtody at nrao.edu
Tue Feb 10 11:28:15 PST 2009


On Tue, 10 Feb 2009, Aurelien Stebe wrote:

> Dear all,
>
> please find below the collective view of the ESAVO Team on the recent 
> discussions on TAP.
>
> First, the AQ and PQ, as they have been nicknamed, are not interfaces, but 
> Query Languages. They have been called both, hence part of the confusion. The

AdqlQuery (AQ) and ParamQuery (PQ) are *service operations*, not query
languages, each of which accepts certain parameters and returns certain
outputs, provides status returns in a certain way, etc.  Altogether
this defines the service interface (an abstraction which is not at
all specific to HTTP by the way, except for a mapping onto HTTP).

AQ and PQ are a fundamental part of the TAP service interface.
AQ provides a mechanism to convey ADQL or other syntax-based content
to the service, to specify a query, hence it is a true query language,
with a syntax etc.  PQ does not define an abstract query language in
this sense at all.  It defines certain parameters which are part of
the TAP service interface, including many of which are common with AQ.
The semantics of these parameters and of PQ are specific to TAP (as
I go into in more detail in my previous posting).  Yes, parameter
values have syntax and need to be processed, but this is true of any
parameter-based interface.

The closest thing to a query language in PQ is the range list used
in WHERE, however this is not complex enough to warrant removal to
a separate document, and the semantics are specific to table access.
The range-list syntax itself is indeed a general abstraction like ADQL,
which could be used for anything, and is already described elsewhere -
but one still needs to specify in a TAP, or SSA, etc. spec how the
syntax is used for a specific parameter.

> Second, the "Simple" DAL protocols have a common QL. We have been advancing 
> this idea ever since I tried to write a service that would implement both 
> SIAP and SSAP (the DALToolKit). That document should be written separately 
> and the next versions of SIAP and SSAP should make reference to it, just like 
> TAP makes reference to ADQL. The question is 
> :  could this be unified with the Param-Query document talked about 
> above, maybe. The authors and contributors of SIAP, SSAP and the PQ part of 
> TAP could certainly enlighten us on this.

I agree with this Aurelien, and we understand this point very well
from implementing our DALServer toolkit.  There is much in the DAL
interfaces which is common from one interface to the next.  We need
to preserve this uniformity, and exploit it when we implement service
frameworks and client software.  A start at defining all this is provided
in the DAL2 architecture draft which is available online at

     http://www.ivoa.net/internal/IVOA/SiaInterface/DAL2_Architecture.pdf

(although not specific to SIAV2 that is where we put it).

This "common QL" is basically the query interface for the generic
dataset, the base class for all the DAL interfaces.  Much is common,
but it is nonetheless distinct for each interface in order to provide
what is needed for the specific type of data being accessed (otherwise
one can just do a generic dataset query).  The document goes into
much more detail on all this.  This is not at all the same thing as
the PQ in TAP, which is a table data (and metadata) access interface.

 	- Doug



More information about the dal mailing list