Re: Issues relating to simple data and metadata queries

Dear all,

Following on from Inaki's comments, I don't believe that TAP should expose either direct SQL querying capabilities, or direct access to the underlying database schema, for reasons I have discussed previously. Some *data services* may wish to expose these things, and others may not; I do not think that TAP can or should expose every possible type of functionality for every possible type of data service (and yes, there are different types - the VO is already heterogeneous.)

I believe TAP should provide a lowest-common-denominator standard for simple synchronous and asynchronous ADQL querying, in a service-agnostic and RDBMS-agnostic way. It shouldn't require a very complex service to support it; it should be suitable for implementation by a range of services from (e.g.) a simple perl or python CGI to (e.g.) a very rich Java/C++ webservice application. I don't believe that TAP can or should be the *only* interface provided by richer tabular data services (TAP does not accommodate user-writeable tables functionality, for example); this is not a failing of TAP, just a recognition that maximal interoperability and maximal uptake are best achieved by simple standards.

I think that dataset metadata should be exposed in VOResource format, again for reasons I have already described at some length. I would like TAP to provide a simple method for extracting VOResource records describing this metadata. If such a method exists in TAP, fine-grained registries can harvest the metadata for use by fine-grained-registry clients; coarse-grained registry clients can get it direct from the service. This preserves interoperability across registry-flavour. The dichotomy between registry flavours is unfortunate, but I think it is not going to go away, so TAP needs to accomodate it.

Apart from/in addition to these comments, I essentially agree with the points made by Inaki.

I'm afraid that I don't have more time for extensive email debate this week (I thought we had agreed in Friday's telecon that further debate about TAP would take place in Beijing?). I am employed as a software engineer; I'm happy to participate in the IVOA standardisation effort, but I don't have infinite time to dedicate to it.

All the best,
Kona

-- 
Kona Andrews        kea-at-roe.ac.uk
AstroGrid Project   http://www.astrogrid.org
IfA, Royal Observatory, Blackford Hill, Edinburgh EH9 3HJ