[PQL] scope

[Doug Tody]

Hi -

On Mon, 23 Mar 2009, Roy Williams wrote:
> I suggest that the first part of PQL to be accepted and ratified should be a 
> Multicone service. Upload a table of positions to a catalog, run cone search 
> on each of them, return the result as a single table, delete the upload. Can 
> be synchronous or asynchronous, should run without authentication.

Of course if we have a multicone capability, then having done the
hard part one would want to provide a simple cone search as well
(e.g., POS,SIZE with no upload table).  Furthermore for any type of
spatial query it is extremely useful to support at least simple range
constraints on table fields, as this can greatly reduce the amount of
data to be returned to the client in a simple query of a large catalog.
There are also use cases where a simple range constraint filter of
a catalog without a spatial constraint is what is desired.

Hence in the terminology of parameter queries in recent TAP specs, we
require at least POS,SIZE (with or without an upload table reference)
as well as at least a simple range-type WHERE constraint.  To avoid
having to write a separate service for every table we need FROM
as well.  To support narrow/wide views of astronomical catalogs
(which can have hundreds of fields in some cases) we also need SELECT.

This is basically what we already have specified for the TAP parameter
query: POS,SIZE, SELECT,FROM,WHERE (plus the common parameters UPLOAD,
FORMAT, etc.).  These are the most important parameters required.

REGION and MTIME should be provided as well, but could be considered
optional advanced capabilities.

I posted a more detailed discussion of the requried TAP parameter
query functionality a while back.  This can be found here:

     http://www.ivoa.net/forum/dal/0902/1016.htm

- Doug