separating TAP and query languages

[Doug Tody]

Hi Pat -

Roy's multicone is the TAP param query - that is multiposition queries,
combined with REGION and possibly a WHERE clause to restrict the query
with simple range expressions for specific table fields.  Simple as
this is, it is sufficient for the first stage of most catalog cross
matches, supports fully distributed queries, and it is scalable to
very large problems, while remaining quite simple and robust.

As you point out, the implied data model and higher level of
abstraction make it much easier to implement and use (for this
specific use case), than to try to do it with primitives within
a general query language.  ADQL is far more general and powerful,
but is not needed for this type of common astronomical use case,
at least not most of the time.

 	- Doug


On Mon, 23 Feb 2009, Patrick Dowler wrote:

> 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,
>
>
>