TAP pas de deux

[Linde, A.E.]

Ah, but will it access Flickr:
  http://www.readwriteweb.com/archives/using_flickr_for_astronomy.php

t.
________________________________________
From: Robert Hanisch [hanisch at stsci.edu]
Sent: 19 February 2009 01:59
To: dal at ivoa.net
Subject: TAP pas de deux

To all involved and interested in TAP,

  Over the past couple of days Ray, Doug, and I have been discussing Pat's
proposal for moving the param query specification to its own document.  Our
initial reaction was skeptical and we have been considering things
carefully.  We are prepared to agree, given a few changes that we hope
others find reasonable and acceptable.

  We like that Pat's proposal aims to put ADQL and param-based queries on an
equal footing.  We agree that ADQL is required and param is optional, and
the way the interface is specified now treats them simply as alternative
ways of expressing a query.  This is good.

  We also like the more clear separation of services and payloads.  Thus,
REQUEST=doQuery (along with the other three) is fine.  LANG is also fine,
though we might like to replace this parameter with something like METHOD,
QUERYMETHOD, or QUERYTYPE.  The reason will become clear in a moment.  But,
this way, we have a parameter that specifies the action, a parameter that
specifies how the query is expressed, and then the actual query (in the
QUERY parameter for ADQL, and in the additional parameters defined for the
param-based query in the new document).

  We do have some reservations, however, about the notion of turning TAP
param-based queries into a generic query language that is supposed to
work across all DAL interfaces.  There are different parameters for
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
dynamically generated image.)  We could quite easily tie ourselves into
semantic knots and contradict the design of the DAL2 interfaces if we go
down this road too far.  This is why LANG, which suggests that the external
query specification is a fully defined language, seems less appropriate than
the alternatives mentioned above.

  Simply put, we are ok moving the specification for param-based queries
into its own document, but not with attempting to generalize this into
"PQL".  The specification of param-based queries should focus on how to
query table data and metadata within the context of TAP, including
capabilities such as multi-position queries and table metadata queries.
There are additional details that need to be added to the param-based query
specification along these lines, and we are happy to contribute to this
work.

   We know that similar ideas were suggested earlier, but those came across
(to us) with an implication that param-based queries should be put aside and
forgotten about.  Pat offered a couple of good insights that helped us come
around to this approach, foremost of which is making the core TAP
specification fully query-language agnostic.   We think this approach will
get us all where we want to go, with the core TAP specification being
separable from the details of how the query is expressed in detail.

  We hope others will agree, and with this approach we can get back to
resolving the outstanding technical details.

Bob, Doug, and Ray