[TAP] Summary: data type for column metadata

[Patrick Dowler]

On Friday 17 April 2009 08:15:14 Gerard wrote:
> The second seems to say that VOTable could also be used to express the
> structure of the database itself.
> This should then be done using empty VOTable-s for example.
> The attractive feature of this seems to be that VOTable metadata is richer
> than a simple listing of columns with some attributes.
> PARAM elements can assign extra features to TABLEs and possibly nested
> GROUP elements can link columns together, potentiall adding
> coordinate systems etc. This may be useful indeed, though I would rather
> have this implemented in TAP as a separate servcice request,
> something like a
>         REQUEST=getEmptyVOTables
> and NOT as a natural outcome of a "select top 0 * from sometable" ADQL
> query.

Doing this is one of the reasons that MAXREC can be used with an ADQL query, 
even though TOP appears to do the same thing. If a client wants to get clean 
and complete metadata via VOTable, this seems the most direct way:

LANG=ADQL&QUERY=SELECT * FROM someTable&MAXREC=0

or (e.g., PQL not really discussed much yet, but) might be:

LANG=PQL&FROM=someTable&MAXREC=0

Further,  MAXREC is already needed to negotiate max query result size with the 
service, so MAXREC=0 is already an available mechanism and applies to any 
query language used.

> I read (maybe mistakenly) from some comments the idea that such GROUP
> structure could be carried over to the result of general ADQL queries.
> I would argue that for the general case (in a mathematical sense) this is
> NOT the case.
> It is hard enough I think to deal with UCDs, UTYPEs, descriptions etc that
> apply to single columns.
> GROUPs are much harder I would argue.
> It is very easy to think of queries that will make it extremely difficult
> to translate GROUPs defined on tables to query results.
> For example the concept of a single coordinate system for (GROUPs of)
> position columns is easily broken by a union.
> Groups themselves are easily broken up by SELECT-s other than *, etc etc
> etc.

Oh yes - in practice the VOTable metadata for a real query will be less 
complete than that of the simple approach above, and it is easy to make it 
more or less impossible for the service by writing the query in certain ways.

In our prototype, we found that the ResultSet->VOTable code had to navigate 
the parsed ADQL query for even simple cases and it was pretty easy to write a 
query where complex code would be needed to figure out the metadata for a 
single FIELD - even without any expressions in the select clause. Just having 
the ResultSet and ResultSetMetadata (from JDBC) was not enough.

-- 

Patrick Dowler
Tel/Tél: (250) 363-0044
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9E 2M7

Centre canadien de donnees astronomiques
Conseil national de recherches Canada
5071, chemin West Saanich
Victoria (C.-B.) V9E 2M7