Comments on PQL spec

[Doug Tody]

On Wed, 8 Jul 2009, John Good wrote:

> The proposed PQL multi-position query (Section 4.2) supports some
> of this but without the cross-table constraints.  It is also a
> little unclear how the user would upload a table for comparison.
> The inference is that one would use POST syntax to upload a table
> with a user-supplied name (e.g. "mylist") and then use a construct
> like "POS=@TAP_UPLOAD.mylist" to tell the service to use the table
> for cross-comparison.

The multi-position query stuff in PQL relies upon the main TAP service
to handle table uploads - PQL just sees a table already ready for
use as in your example above (POS=@TAP_UPLOAD.mylist).  The details
of inline table uploads with POST or via a URL are spelled out in
the main TAP document.  The main issue we need to deal with in the
PQL spec is how to identify the fields of the input table to be used.

For multi-position queries the primary use-case is that the user
uploads a table of positions which we use to drive the query.
Since the user has prepared this table it is not clear in this case
how useful it would be to define additional constraints to filter
the table.  In the more general case of a simple correlation of two
arbitrary existing tables however it could be useful.  We do have
such a case already in the multi-position query when REGION is used
to define a table of positions from an existing table.

One way this could be done would be to compute the multi-position
table and then perform the correlation as two different steps.
This will eventually be possible once we have VOSpace integration
into TAP (so that the temporary table can be written and then reused).
To support this capability more directly would require adding something
to the interface.

> With a little more support for geometric overlap, I personally would
> prefer to use PQL (and/or TAP) for dealing with image and spectral
> metadata over the custom protocols.

This will be possible with the proposed generic dataset query, since
this would be able to query for any type of data (in a somewhat limited
"generic" way of course).  One could then either just download the
referenced data as a static "archival" file, or follow a data link
to a SIA or SSA service for more sophisticated OO access to the data
object, providing virtual data generation etc.

 	- Doug