separating TAP and query languages

[Patrick Dowler]

On Monday 23 February 2009 07:37:23 Roy Williams wrote:
> The point of the Multicone service is that you*don't* need to do ADQL!  
> The point is that it gets 90% of what the astronomer wants for 10% of
> the effort! And it can be made robust as well.

That may or may not be true, but even if it is true it is not what people mean 
by TAP. TAP is general and intended to access general (relational) databases 
where we have no data model for the content. It is a step forward, not the 
ultimate solution. In many ways TAP (and specifically using ADQL) provide a 
lower-level access to heterogeneous content (the real content that people are 
making right now).

Other DAL services and your idea for "multicone" on the other hand imply a 
data model for the content, or at least I surmise that from the various 
postings on the topic. It is not general purpose, but rather aimed at a 
specific (albeit currently not specified) "source" data model. These services 
provide a simpler nigh level, more abstract interface to content. The service 
provider makes more decisions and the client has less controll/access to 
details. That is also valuable, but in a different way. 

What I am saying is that there is plenty of room in the VO ecosystem for TAP 
and Multicone, but when I think about Multicone I think it is ConeSearch 2.0 
and not some variant of TAP. TAP is low level, hands on. Multicone is more 
abstract and hides many details. Both are good.

my 2c,


-- 

Patrick Dowler
Tel/Tél: (250) 363-0044
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9E 2M7

Centre canadien de donnees astronomiques
Conseil national de recherches Canada
5071, chemin West Saanich
Victoria (C.-B.) V9E 2M7