[TAP] data type for column metadata

[Markus Demleitner]

On Wed, Apr 01, 2009 at 09:20:46AM -0700, Patrick Dowler wrote:
> On 2009-03-31 23:08:05 Markus Demleitner wrote:
> > Again: What would be so bad with having clients request an empty VOTable
> > for the columns they are interested in to retrieve STC metadata?
> 
> We already came to the conclusion that VOTable datatypes do not fully capture 
> what is needed to write queries, not to mention metadata aside from column 
> descriptions. That is why we came up with the list of SQL types and once 
> users have to get some metadata from VOSI or TAP_SCHEMA I don't think it is 
> plausible to impose that they get the rest of it from the header of an empty 
> VOTable.
Well, I guess the topic can become deep, but I'd like to draw the line
between what's in (simple relational) TAP_SCHEMA and what's in
(tree-structured) VOTable metadata at what separates the
technicalities of ADQL (what comparisions can you make?  what
operators are available? what columns are valid for what function
arguments?) from physics (which is at least an order of magnitude
more complex and contentious). 

*If* STC-type information should go into TAP_SCHEMA, I think it
should be in some way closely equivalent to the (relatively elegant)
group mechanism of the VOTable -- you'd need to be able to
reconstruct which pairs of coordinates belong together.  I wouldn't
want to come up with a specification for that.

> Secondly, in the first example of  Section 5.1 in the doc you referred to
> (http://www.ivoa.net/Documents/Notes/VOTableSTC/VOTableSTC-20081018.html) they 
> use one of the standard reference systems specified in STC-Lib: 
> UTC-ICRS-TOPO. That is exactly what would be done here if we adopt the 
> simpler compact form and a single metadata attribute (to specify something 
> like UTC-ICRS-TOPO, for example). 
...which would limit what we could express in that metadata to what's
in STCLib.  This might not be bad, because it would give a baseline
that clients could strive to implement.  But then we should, at least
informally, recommend some way to say "this STC metadata cannot be
expressed with STC/TAP, see VOTable STC metadata for real
definition".  I'd feel it's clumsy.

Agreed, having to split metadata into "technical" (TAP) and "physics"
(VOTable) isn't great either, but at least it saves us from having to
represent the same thing in two places with different expressive
powers...

Cheers,

         Markus