[TAP] data type for column metadata
dave at ast.cam.ac.uk
Sat Mar 28 06:24:02 PDT 2009
Markus Demleitner wrote:
>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.
I must admit I'm kind of lost .. this thread is so long I'm not exactly
sure what is actually where any more.
However, I just want to make sure that we keep in mind the reverse
transcription, from VOTable back to database table. One of the eventual
use cases of a VOSpace/TAP combination is that the user can upload a
VOTable and the server creates a new database table (with metadata)
reconstructed from the users VOTable.
The TAP and VOTable metadata don't have to match exactly, but there
needs to be enough overlap between the two to enable the server to
reconstruct the TAP metadata for the new database table from the
information supplied in the uploaded VOTable.
More information about the dal