On Fri, 12 Jan 2007, Patrick Dowler wrote:
>> +VOQL-TEG-1/AI#7 on FO (plus DT/KA): to propose a mechanism for getting
>> table metadata within the TAP and possible output format
>> open
>
> Given the format=metadata usage in other DAL services (well, SIA 1.0 anyway)
> and returned VOTable, it would seem we should follow that same style. Given
> that you need name, datatype, units, and ucd for each column of a table it
> would basically be the same.
I agree with this, but the main reason is that database/table metadata is inherently tabular hence it makes sense to return it via a table-oriented interface. Since we will already support VOTable as the main output format for table data queries, it makes sense to use the same basic interface for table metadata queries as well. Client application software for example, will already support VOTable for data queries and it will be almost trivial to use the same code for metadata.
The actual query should not however use the literal "format=metadata"; this confuses the type of query with the format in which data is returned (we are moving away from format=metadata for the newer DAL interfaces and going to a separate getCapabilities operation for service metadata instead).
It could be done either with the same query as is used for data, using a parameter to specify what to query, or it could be done with a separate service operation. I suggest we avoid having 10 separate operations for metadata queries as I have seen in some interfaces, especially if the data returned is in VOTable format in each case.
> But, this works for single tables only, eg
> format=metadata&table=foo... we would still need a way to get a list of
> tables and a descriptor (ucd) saying what a row in that table IS or means.
> Maybe format=metadata returns a list of tables with names and descriptors, and
> format=metadata&table=$name returns the details for that table.
>
> The details for a table may also include indications about (i) which columns
> are indexed, (ii) which columns are unique, (iii) which columns are keys for
> joining other tables (if/when we decide to support join, which may not be in
> TAP at all).
Yes, one probably wants to be able to query both for the tables which are available from a service, and the fields of each table.
If a data table is a form of dataset, perhaps a query for a list of tables is a form of data discovery query, like the queryData operation for SIA/SSA? If we look at it that way, then the "getData" is what we use to access data (table rows) from a particular dataset (data table). It just happens to return table data in the case of TAP. If a "queryData" operation is useful for tables, does it want to be able to query based on table attributes as we do for other datasets?