Exactly. It doesn't matter so much where the client gets the VOResource, just that it only has to understand VOResource for metadata (which is does already for the service metadata) and that TAP implementors only have to produce metadata in VOResource format (no matter what sort of strategy individual or all registries happen to take).
Pat
On Thursday 08 March 2007 03:12, Kona Andrews wrote:
> 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
-- Patrick Dowler Tel/Tél: (250) 363-6914 | fax/télécopieur: (250) 363-0045 Canadian Astronomy Data Centre | Centre canadien de donnees astronomiques National Research Council Canada | Conseil national de recherches Canada Government of Canada | Gouvernement du Canada 5071 West Saanich Road | 5071, chemin West Saanich Victoria, BC | Victoria (C.-B.)Received on 2007-03-08Z19:35:12