resuming progress on TAP

[Doug Tody]

On Tue, 10 Feb 2009, Patrick Dowler wrote:

> On Monday 09 February 2009 20:29:16 Douglas Tody wrote:
>> If I understand your suggestion correctly Pat, you are proposing
>> that we drop param query from TAP and just have ADQL, with a separate
>> discussion of parameter-based queries to be added externally, somehow
> 
> I am definitely NOT proposing we drop param-query. I am proposing
> that we write a specification for it and ratify it via the standards
> process. Then it can be used in DAL services, including TAP, just as
> ADQL is a standard and it can be used in services, including TAP. It
> is a pretty simple divide and conquer approach that worked well enough
> for ADQL. It would keep the TAP spec smaller and improve clarity.

It would amount to the same thing, removing the parameter query
functionality from the TAP spec.  Note, even if we did such a thing
the param query operation would still have to be defined in TAP as
it is part of the primary service interface at the same level as the
ADQL query, with the two providing the primary table query operations.
Together these *are* most of the TAP service interface and are required
to understand the basic of what TAP provides.  Both operations and
their parameters, many of which are common, as well as much other
common functionality (uploads, outputs, etc.) would still have to be
described in the TAP spec.  If we continue to cover all this essential
TAP-specific stuff how much is really left, for something as simple
as PQ?  How much is generic or specific to TAP?  ADQL is much more
complex, and is a general syntax-based query language which could be
used in many other contexts. (more on this below).

Now it is probably true that there are many generic details of how
parameters are used in the DAL2 interfaces which are common to all DAL
interfaces and which could be described separately and referenced
by TAP, SSA, SIA etc. (Aurelien also noted this).  The same is
true for the basic service interface, and the details of how common
mechanisms such as UWS, VOSI, STC regions (eg REGION), etc. work and
are used in the DAL interfaces, all of which we want to be uniform
and standardized.  We already have much of this defined separately
from TAP.  In the case of DAL the DAL2 architecture draft introduced in
Baltimore is a start at providing this shared specification of common
interface elements.  I agree that much of the detailed specification
of common functionality is better moved out into separate documents.

The key issue with PQ is how much of this is generic, and how much
is really specific to table queries (i.e., to TAP).  If it is mostly
specific to TAP there is no point in moving the material to a separate
document; a separate section within the TAP spec (such as we have now)
is more appropriate.

In general the DAL interfaces all have much in common, however each has
a custom interface including input parameters, output metadata, data
model, etc., which is specialized to the type of data being accessed
(in object terms they are all subclassed from the generic dataset).

In the case of TAP we are accessing table objects rather than images,
spectra, or whatever.  If we look at TAP/SIA/SSA we will see parameters
such as POS, REGION, FORMAT, MTIME, etc. in all these interfaces.
But - and this is the key point - the detailed semantics of these
parameters are *not* the same in all interfaces.  Some syntax and
semantics are common but others are not, because the interface
is specialized to a certain class of data object.  Each protocol
defines a new interface; much is common but the unique aspects must
be described as part of each object interface.

The interface functionality (what we do when we access the data) will
also differ, often very much so.  What we do when we access table data
is very different than what we do when we access an image or spectrum.
With TAP we are operating directly upon table data, not querying for
virtual data objects as in the other DAL interfaces.  Operations like
cone search, field or region-based table filtering, multi-position
queries (multicone), or any of the above combined with features such
as server-side views (which may provide complex multi-table function
even in PQ), are specific to table access.  In the case of TAP,
PQ also provides a critical capability for querying database/table
metadata via the TAP schema, which NVO at least needs to provide good
support to our research users.

I could say more but this message is getting too long already.
In short, yes we need separate documents describing common interface
elements, but the TAP param query is just as specific to TAP and table
access, as the SSA param query is to spectral access, SIA param query
to images, and so forth.  These are all object-specific mechanisms,
and are not abstract query languages in the sense that ADQL is.

 	- Doug