Hi Kona -
On Wed, 7 Mar 2007, Kona Andrews wrote:
> Hi Doug,
>
>> Database and Table metadata as see in TAP on the other hand, is not
>> service metadata. It is tabular data and is very similar to data
>> returned from a data table or catalog, the only difference being the
>> logical content of the "table" being queried. It is advantageous
>> to use a similar mechanism to access both table data and metadata,
>> hence use of VOTable is reasonable here.
>>
>> Am I missing something or does the discussion below completely miss
>> this point?
>
> The registry resource specification does *not* only cover "service"
> metadata - it also deals with "table" metadata, if you wish to draw
> a distinction between the two.
>
> Database and table metadata can (and in our opinion should) be expressed
> in the registry entry/ies describing a data service; in other words,
> everything that needs to be known about the service and its data should
> be available in the registry, including table metadata. Appropriate
> VOResource types already exist for this and are undergoing further
> development in the registry group - we should contribute to that process
> if we find the current specification inadequate.
I do think we should distinguish between service metadata and dataset metadata. Also; didn't we already discuss this issue in telecon #1, and agree that querying table metadata is a function of the TAP interface, not the registry?
> My impression from our previous discussions was that the mandatory
> getMetadata method(s) in TAP would return VOTable (only). We believe
> that the mandatory method(s) should return the appropriate VOResource
> type(s) for describing tabular data, with return in VOTable format as
> an optional or mandatory extra.
This is incorrect. The DAL getCapabilities operation is very similar to the getMetadata defined by the registry (again, Ray is involved in working out our initial agreement here). It returns structured XML compatible very similar to a VOResource, not VOTable. There is no VOTable format option for getCapabilities since what is returned is not tabular data.
Table metadata is a completely different matter, since this is specific to the individual dataset, and is tabular data, access to which is very similar to a table data query.
As Alex pointed out in a recent telecon, SQL recognizes this as well, using the same mechanism for database/table metadata queries as for regular table queries.