[TAP] Summary: data type for column metadata

[Arnold Rots]

I don't think I agree, but I'm not sure, either, that we are at a
point where we can say how it should be done.

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.

TAP does not have to have great intelligence, but it does need to be
able to tell the client what it is that (s)he is getting or,
conversely, what to ask for.

I am not very enthusiastic about Ray's grouping, either. I don't feel
this level of detail needs to be in the registries and even if it is,
it should be possible to get it from the database directly.

I guess where I am going is that this kind of information needs to be
exchangeable in the metadata queries; and that it needs to be pretty
specific as to what pertains to which column.
And my traditional mantra: clients and servers may support whatever
they like, but should advertize their limitations, so humans can judge
whether they (the clients as well as the servers) are of any use to
them.

This is messy, but we need to solve it.

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