TAP information schema

[Keith Noddle]

UK and European project commitments have prevented me from engaging with 
this debate as closely as I would have wished, for which my apologies. 
Although I was a willing party to the Information Schema work currently 
under way, I am concerned that we are heading towards a compromise that 
satisfies no one. We've all heard the old joke: "What is a camel? It is 
a horse designed by committee". We need a horse not a camel as a result 
of what we are doing now.

I am further concerned that we are developing sophisticated solutions to 
problems we have not properly defined and which are not part of the 
remit for TAP V1.0. In case I didn't make it clear in my opening remarks 
at the DAL TAP session in Cambridge, I believe we are not making 
progress with TAP because we do not share a common understanding of the 
problems we are trying to address or the pressures each project faces. 
Therefore we MUST agree Use Cases before we attempt to deliver complex 
solutions to ill formed requirements. However, I do believe enough basic 
requirements for TAP V1.0 are known (see below) and that we have a duty 
to the IVOA to get TAP V1.0 agreed ASAP.

Going back to the "camel" above, I do not see why we are trying to fit 
an IS into a VOTable when it seems clear to me that we need a mechanism 
to obtain basic metadata (both for service and content) AND a device for 
accessing the detailed metadata that an IS (for example) would provide. 
The only question is one of timing. Although this has at various times 
been discussed within the context of VOSI, it is perfectly acceptable 
for TAP to specify both an IS (or similar) approach and a simple 
metadata approach to the question of metadata provision _if_ the Use 
Cases so dictate. Finally, it was made abundantly clear to us in Beijing 
- and it remains the case - that the priority for TAP V1.0 is to define 
how we handle ADQL querying. Period. No arguments.

I therefore propose that we approach TAP in incremental steps starting 
with the most basic requirements and working upwards from there. I will 
publish a roadmap for TAP as soon as I can, but the starting point in 
TAP V1.0 has to be:

1. Support for processing ADQL queries (both synchronous and asynchronous)

2. Delivery of basic metadata via a getSimpleMetadata (or whatever name 
we dream up) call, the metadata themselves returned in VOTable or 
VODataService format, again, TBD quickly.

This is the level of detail we need to be examining for TAP V1.0. I plan 
to quickly follow TAP V1.0 with a V1.1 which includes capabilities that 
match the Use Cases that we *must* define. I am NOT willing to preside 
over another 18 months of circular debate whilst the rest of the IVOA 
looks on bemused.

Keith.

-- 
Keith Noddle                    Phone:  +44 (0)116 223 1894
AstroGrid Project manager       Fax:    +44 (0)116 252 3311
Dept of Physics & Astronomy     Mobile: +44 (0)7721 926 461
University of Leicester         Email:  ktn at star.le.ac.uk
Leicester, UK   LE1 7RH         Web:    http://www.astrogrid.org