separating TAP and query languages

Paul Harrison paul.harrison at manchester.ac.uk
Mon Feb 23 02:09:48 PST 2009


On 2009-02 -23, at 01:55, Roy Williams wrote:

> Pat
> I like your idea of the LANG keyword, it allows creative scope for  
> creating the kind of services that will most benefit the  
> astronomical community. It immediately made me think of  
> LANG=MULTICONE for the kind of "simple inclusive crossmatch" with a  
> small, simple, standard, something that could be running in multiple  
> places by April.
>
> But when I started reading the document below, it says that ADQL is  
> "mandatory", VOSI compliance is "mandatory", metadata queries are  
> "mandatory", RUNID is "mandatory", and so on and so on. Years of  
> time and effort to expend on all these things before even starting  
> with the "optional" parts of TAP, i.e. multicone. You have made TAP  
> a monolith. However I am not seeing the software toolkit to let me  
> build a compliant TAP service from my database, and I am not seeing  
> this being built anywhere(?).


If you put you client hat on though, all of these "mandatory" parts  
mean that  the services are both uniform and capable - this means that  
you can repeatedly issue the same query globally to many services  
without having to check if particular services support some optional  
feature - this is the essential characteristic that makes the VO  
different from what went before, and what makes it possible to do new  
science more quickly. Too many optional features in a specification  
mean that the mandatory core is left so simplistic as to be  
scientifically worthless.

It is a balancing act in ensuring that the specifications are not too  
onerous for service providers to be prepared to implement the  
protocol, but I think that TAP is so central to services that a VO  
will provide that it is better to err on the side of making things  
more powerful for clients. For most large data archive providers the  
TAP specification is not going to be too onerous, and for the smaller  
provider without sufficient resources, there are several toolkits that  
are/will be available.


Paul.

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





More information about the dal mailing list