[TAP] Summary: data type for column metadata

[Gerard]

Hi Arnold 

> 
> There are catalogs with multiple sets of coordinates; and 
> non-standard (by current standards) equinoxes, as Markus pointed out.
> 
> Pat's string is not going to cut it in those situations.
> But relying on the human behind the query, as (I think) 
> Gerard and Mark are suggesting, is not helpful, either. It 
> would mean that any large-scale automated searching or 
> cross-matching is ruled out from the start.
> 
ADQL/TAP does not aim to support cross-match yet as far as I am aware.

What you mean by "large-scale automated searching" is unclear to me, at
least insofar that 
you think this would not be possible. I can well imagine someone writing a
script that 
1. searches the registry to find TAP services that have tables with columns
with UCD=em.opt.U
2. uses the name of these columns to send a query 
  select * from <the-table> where <that-column> < 10
to all these services.

This seems to qualify, though it does not contain RA and Dec as a
constraint.
I guess you would argue that to do the same with pos.eq.ra columns would not
be acceptable to astrometrists if you do not know the exact STC metadata.
But photometrists might argue the same for not having exact calibration
information for these em.opt.U columns. I would argue that making such
distinctions is not the task of TAP version 1.
And we seem all to agree that a single STC metadata column would not suffice
in the general case anyway.

Note that for the interpretation of the results users would still need to
understand the schemas of the services that were queried. TAP simply can not
hold all the required metadata to do proper automated science with its
results at the current time.

Btw, maybe I am missing something, but will the POINT datatype not allow
full coordinate system
specification: POINT('ICRS GEOCENTER',25.4, -20.0) etc.
And together with the ADQL DISTANCE and CONTAINS syntax would this not allow
spatial queries that in theory fulfill all your requirements?
Assuming ofcourse that TAP services are really going to publish their data
using the POINT datatype and implement efficient ADQL executors that can
handle this.



> ...
> This is messy, but we need to solve it.
> 
Not necessarily in TAP version 1 though, and maybe never in TAP, but in
protocols built on top of it.

Gerard


>   - Arnold
> 
> 
> Mark Taylor wrote:
> > >From a TAP outsider (i.e. feel free to ignore in favour of people
> > with a better idea of what they're talking about):
> > 
> > On Thu, 16 Apr 2009, Gerard wrote:
> > 
> > >
> > > > 2. add single additional optional metadata coordinate 
> system spec, 
> > > > with values coming from tables in STC, FITS, and a few in TAP 
> > > > directly to fill gaps (with intention to deprecate them when a 
> > > > definitive source is written: eg Time WCS paper and/or 
> another rev 
> > > > of STC). Several values could be put together with 
> dashes (as in 
> > > > STC Lib); someone could could plausibly (outside TAP 
> spec) extend 
> > > > STC Lib with more useful constants so there is a nice picklist 
> > > > (and thus also used in the VOTable output, so this approach 
> > > > largely solves result metadata as well).
> > > > 
> > > 
> > > I am not very enthousiastic about this. Can we really not 
> leave it 
> > > out and for the time being leave it up to users to read 
> the details 
> > > of a given TAP service's schema? Imho TAP is too low-level to 
> > > support the kind of automated interoperability  that seems to be 
> > > foreseen in some of the use cases. For
> > 
> > I agree with Gerard's position on this.  I don't expect 
> many cases in 
> > which such metadata could/would be used in an automated 
> fashion, so I 
> > don't believe that the additional complication, both in the TAP 
> > standard and for data providers, would be worth the effort.
> > 
> > Mark
> > 
> > -- 
> > Mark Taylor   Astronomical Programmer   Physics, Bristol 
> University, UK
> > m.b.taylor at bris.ac.uk +44-117-928-8776 
> > http://www.star.bris.ac.uk/~mbt/
> > 
> --------------------------------------------------------------
> ------------
> Arnold H. Rots                                Chandra X-ray 
> Science Center
> Smithsonian Astrophysical Observatory                tel:  +1 
> 617 496 7701
> 60 Garden Street, MS 67                              fax:  +1 
> 617 495 7356
> Cambridge, MA 02138                             
> arots at head.cfa.harvard.edu
> USA                                     
> http://hea-www.harvard.edu/~arots/
> --------------------------------------------------------------
> ------------
>