This is not really a registry issue

Dear all,

Let me summarise our position more clearly before this turns into another registry debate, which is not really the point.

There exists a VOResource specification to describe tabular data. We have VO client tooling that can use such VOResource descriptions to perform useful VO tasks, such as providing assisted Query Builder tools.

It is *useful* for data services to return descriptions of their data in VOResource format because the VO client tooling can then use these descriptions in the normal way, *regardless of whether the descriptions came from a registry or from the service itself*.

This is *not* a fine-grained/coarse-grained registry issue. There are use cases where the VOResource entries describing the data might not *be* in a registry in the first place. For example, a service that provides writeable table "scratch space" might never formally register the data tables it manages, because they are presumed to be transient and user-specific.

Making sure that all TAP-compliant data services are able to expose their tabular metadata in VOResource format means that VO tooling can always work with those services, whether "fully" registered or not (so in the scratch table case above, users can still use VO tooling to build queries against their transient, unregistered scratch tables). If the TAP protocol supplies VOResource metadata, then even those TAP services that *don't* put fine-grained tabular descriptions in the registry (e.g. all NVO services presumably) can still be utilised by VO tooling that understands VOResource metadata.

I don't believe that the getCapabilities() method adequately covers this case, because (a) I'm not sure that the VOResource tabular data descriptions fit under "capabilities" (but I am happy to be corrected if I am wrong), and (b) even if they do, the getCapabilities() route presumably does not *mandate* that the VOResource description of the tabular data is present.

In other words, for the small price of supporting an IVOA-standard XML format for describing tabular data, interoperability is enhanced, as is the standardisation of client tooling for TAP services.

Cheers,
Kona

-- 
Kona Andrews        kea-at-roe.ac.uk
AstroGrid Project   http://www.astrogrid.org
IfA, Royal Observatory, Blackford Hill, Edinburgh EH9 3HJ