S*AP and DAL v2

[Paul Harrison]

Hi,

I thought that I would add my "vision" of how things should/could be...

The "Simple" access protocols have been a success for the VO - They  
are simple to use and relatively simple to implement. They are perfect  
for the "what is available at that position on the sky" types of query.

So how to progress, to accommodate the more sophisticated query that  
people now want to make.

Keep the S*AP simple
* keep as a synchronous service
* have parameter based model that can easily be driven by filing in a  
web form - this means easy for the user to understand, and unambiguous  
for the service writer.

DAL v2 should concern itself with advanced usage;
  * query language driven vs. parameter based.
  * asynchrony
  * interaction with VOSpace
  * interaction with other DAL services to provide "cross matching"

There should be no blurring of the distinction - don't try to make  
S*AP advanced by making them complex to use and complex to implement -  
keep the "simple" characteristic that made them successful. DAL v2 is  
there for more advanced queries than the "what is available at that  
position on the sky" type of query - this will necessarily need a more  
complex interaction with the client software.

Onto the specifics of the  TAP-Param vs. TAP-QL debate. By my criteria  
above,  if we are saying that TAP (note - no simple in the name) is a  
DAL v2,  I would characterise the TAP-Param as Simple Cone Search v2,  
and drop all of the asynchrony, direct access to the table model, etc,  
but retain  the extra defined parameters and ways of putting  
constraints on individual parameters. This distinction between  
parameter based and query language based is fundamental in my opinion.  
The parameter based method for specifying the query breaks down (or  
becomes more complex than a query language approach) as soon as you  
want to express a constraint that involves a logical combination of  
two parameters e.g. do I mean "magnitude < 18 and redshift > 0.5" or  
do I mean "magnitude < 18 or redshift > 0.5" - This is concise and  
unambiguous in the query language approach, whereas in the parameter  
based approach the best you can reasonably do is specify that you mean  
"or" or "and" for all the individual parameter constraints which  
obviously does not allow you to express the full range of  
possibilities when there are 3 or more parameters involved.

There is nothing to stop a service writer providing both a SCSv2 and a  
TAP interface, but they would be separate interfaces with their  
separate usage characteristics - a user who wants simple usage (param  
driven) just looks at the SCSv2 document to work out how to drive the  
service, and a user who knows that they need a query language approach  
looks at the TAP document to find out how to use the service.

Paul.

Dr. Paul Harrison
JBCA, Manchester University
http://www.manchester.ac.uk/jodrellbank