Community feedback re TAP metadata

[Doug Tody]

Hi All -

I sent a query to Ray for a clarification of the official Registry
WG position on this, plus invited comments from NVO.  Some responses
have been received, but I will wait a while longer and then forward
all such comments received.

Another use-case to think about in the meanwhile, is a tabular service
which returns virtual data.  In the case of a service which returns
virtual data, the table is constructed on the fly in response to the
client request.  This has proven to be a quite useful feature with
other forms of astronomical data within DAL.  In the case of dynamic
generation of a virtual table, the table fields generated may well
depend upon the actual query received.

We can think up any number of examples of this, but one which came up
recently in another project I am working on, is a catalog service which
computes thousands of image cutouts from survey data, then computes
some morphological quantities via image analysis of each cutout,
returning a table containing the results.  This "dynamic table"
could then be combined with data from conventional source catalogs
to provide a powerful, user extensible object detection technique.

A simpler example might be a service which can return data from
multiple catalogs, e.g., by specifying the collection name as a
query parameter.  For example, if a survey data collection includes
several catalog data products, it might be reasonable to serve these
up with the same service.  This leads to the concept of a "table set",
which the ability to query the metadata of each such table.

Service metadata, and getCapabilities/VOResource would seem to be
intended to describe the more static capabilities of a service.  In the
case of virtual data however, or table sets, metadata describing the
dataset to be accessed can be more dynamic.  Even in the case of static
tables, metadata such as a list of table fields can be very large;
some of these tables can have hundreds of fields.  This suggests that
table metadata is more closely tied to the data than to the service,
and perhaps should be handled with a more data-oriented mechanism.

 	- Doug