TAP pas de deux

[Doug Tody]

On Tue, 24 Feb 2009, Patrick Dowler wrote:

> Naming that document PQL (expanded) and using LANG=PQL was a convenient way to
> make the intention of the proposal clear (which I think was successful) with
> a minimal change to the structure of the services being described. I agree
> that P?? is not a fully formed query language in the same sense as ADQL, but
> I also feel we can standardise P?? if we define what it is clearly enough.

I think so too (that we can standardize the TAP param query).  What it
is, is the parameter-based query method for TAP, used to access table
data and metadata.

>> different purposes depending on whether one is accessing images, spectra,
>> or tables.  The same parameter can have different semantics depending on
>> the type of data.  (Example:  SIZE, which in TAP defines a circle in which
>> to search and in SIAP defines a box that can be the requested size of a
>
> This is, to be blunt, a terrible idea and we really must stop doing it. If we
> want two shapes (circle and box) we must have two parameters. Having a
> parameter mean different things in different places is a bad idea(tm). The
> alternative is to specify the shape on the right-hand side (as is done with
> the REGION param)... Yes, this may well make SIA 2 incompatible with SIA 1,
> but that is what the VERSION parameter is for.

The POS issue is not the main point here, so lets not get side
tracked by that (REGION will provide the generalized search region
capability you refer to).  The key point is that the DAL interfaces
are specialized to the type of data being accessed.  They have to be,
to be able to do actual data access, not mere data discovery queries
(the typed interfaces actually do both with one interface by posing
queries against virtual data).  The details of how we access table
data, or images, or spectra, have to differ somewhat for each type
of data.

Now of course there is much which is common to all these interfaces as
well.  Some of the same parameters may appear in multiple interfaces.
But the semantics of how these parameters are used will in general
vary depending upon the type of data being accessed.  If that were not
true then astronomy could have only one interface today for accessing
all astronomy data.  There would be no difference between accessing
a relational DBMS or an image.  This is simply not the case.

DAL *does* already have a unifying concept relating all the typed data
interfaces - the generic dataset.  This concept defines a standard
query interface applicable to any type of data (any primary dataset),
and a standard query response based upon the generic dataset metadata.
But this is subclassed for each of the typed interfaces, in a standard
OO fashion, to provide the specialized support required for each type
of data.

Development of these concepts goes back 5-6 years or more.  If we
must have this discussion all over again I suggest that those who
are interested first read the DAL2 architecture draft.  This is
available at

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

(or on both the SIAV2 and TAP discussion pages).  Lets try to pose
any analysis in terms of the existing DAL concepts, and the years
of effort and hundreds of service implementations based upon these
concepts, rather than begin to reinvent all of DAL from scratch.

 	- Doug