[TAP] Summary: data type for column metadata
patrick.dowler at nrc-cnrc.gc.ca
Fri Apr 17 10:04:22 PDT 2009
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
> and NOT as a natural outcome of a "select top 0 * from sometable" ADQL
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:
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
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.
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
More information about the dal