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