Let's get something to test...

[Anita M. S. Richards]

Hi people, here are some comments from someone who hopes to use TAP.  I 
have read the discussion with great interest so I hope that I have not 
missed the point...


My main interests in TAP are as a current or future data publisher of
both large and medium tables (and a user of existing services for
research).  The requirements of large data providers e.g. ALMA have
been covered by some previous comments e.g. Aurelian.  On the medium
scale, our local Manchester services should eventually provide not
only e-MERLIN observing logs, source lists etc, but also higher level
data products and related collections, such as catalogues of
gravitational lenses or pulsars.

One of the requests which came up time and again at the Euro-VO
workshop last year (and at other events) is to be able to perform
non-RA/Dec queries, e.g. positional but in Healpix, or non-positional
queries, e.g.  (in the above examples) to select all lensed objects
with separations > 5 arcsec, or all pulsars with periods in a certain
range.  Another is to be able to mix existing standards, e.g. select
by position and wavelength range and/or time.

For those of us designing a new data serving system or a major
upgrade, ADQL seems the priority because it is more extensible.  I can
see the point of maintining existing parameter-based queries which are
limited but simple (at least in the sense that anything familiar is
simple), but once you get to the point of wanting a complex language,
ADQL exists...

So, my first plea is to take up Aurelian's suggesting and factorise
TAP so that we can see what everyone has to provide which is common to
ADQL and PARAM, and then separately specify what is required (in the
broad sense - from 'must' to 'may') for ADQL and for PARAM, so that
people with existing installations can see what might need to be
changed easily, as well as for new implimentations.  At the moment,
the document 0.31 seems a bit mixed up and it was not clear to me what
I would need to impliment for ADQL only, for example.  There was also
discussion of how to cope with overflows and similar in more than one
place. This is one of the biggest weaknesses in many present services
so we should make sure that is clear.

Secondly, we need to get something out there to start testing asap,
since that is what shows up inconsistencies fastest.  Hence I am all
for whatever preliminary version can be provided, as long as future
versions are backward-compatible as much as possible.

Thirdly, I'd like to see some comments from the ADQL group and the
Registry group.  On the latter, any table publishing service is only
useful if people can find it, and so the service to provide table
metadata should have this role, as well as in specific queries.  For
example, if I want data at resolutions better than 0.1 arcsec, will
TAP help provide that to the registry or does the astronomer have to
identify tables first?  In any case, we should make sure that the
results of metadata-only queries can be convenient for humans who want
to know what is in a dataset.

Finally, three specific questions (maybe outwith the general discussion):

- I assume that the requirement for case sensitivity refers to the
   need to pass on whatever the user inputs, not to impose extra
   demands on user syntax.

- Why is it an error to specify e.g. the coordsys explicitly but
   positions as column references (Section 2.4.2)?

- It would save less skilled data providers a bit trouble if you gave
   examples of the commonest MIME types likely to be used, in 2.4.5

thanks
a


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Dr. A.M.S. Richards, UK ARC Node/AstroGrid,
Jodrell Bank Centre for Astrophysics, Alan Turing Building, 
University of Manchester, M13 9PL
+44 (0)161 275 4124
and
MERLIN/VLBI National Facility, Jodrell Bank Observatory, 
Cheshire SK11 9DL, U.K. +44 (0)1477 571321 (tel) 571618 (fax)

"Socialism or barbarism?" Rosa Luxemburg (1915)