[TAP] data type for column metadata

[Markus Demleitner]

On Fri, Mar 27, 2009 at 09:25:28AM -0600, Doug Tody wrote:
> On Thu, 26 Mar 2009, Patrick Dowler wrote:
>
>> * datatype: the current draft uses VOTable types but we have shown several
>> places where that is not adequate and concluded that we need to use a list of
>> types from ADQL/SQL
[...]
> SQLtype is also possible).  We will have to deal with the VOTable
> type in any case since this is how data is returned.  But it is
> useful to know more about what is actually stored in the database.
Thinking about it, I'm not sure the VOTable data type is necessary in
TAP metadata -- it's irrelevant for writing queries or even inferring
types of intermediate expressions (if the clients will attempt to do
that, which I doubt), and it's also irrelevant to locate
"interesting" columns (which ucds and utype can do).  This would
follow the IMHO good rule of thumb: "Put into TAP metadata what's
necessary for building queries".

When a VOTable is actually being delivered, the client has to examine
the types given there anyway, since it's probably unwise to make
assumptions of how a service will encode the values of SQL
expressions from the client side.

>> * system: I propose that column metadata include a place to specify the
>> coordinate system applicable to values; name TBD depending on what in
>> actually needs to contain
>
> This could be useful provided we don't get carried away and make
> it too complicated.  Perhaps a simple string such as TT-ICRS-TOPO,
> UTC-FK5-GEO, etc., provided mainly for human consumption.  Note VOTable
Again, VOTables have (with the inclusion of STC-type metadata) very
elaborate ways of encoding this.  However, I can see why a client
might want to know about what system coordinates in columns are in.
In that case, I'd either propose an STC-S string (without any values)
or again have the client retrieve an empty VOTable containing the
columns in question to figure that out.

Coordinate metadata is always difficult.  Having to represent it in
many places in various, frequently not terribly well-defined formats,
definitely doesn't help.

[And, to counter this argument up front, yes, this kind of
information will not be available in output formats other that
VOTable.  My feeling is that saying "give me the data in TSV" is like
"strip metadata, I'll process the data in my FORTRAN hack and know
what I'm doing".  I'd respectfully grant that wish...]

Cheers,

        Markus