table metadata and the registry

[Ray Plante]

Hi Tony,

On Tue, 8 May 2007, Tony Linde wrote:
> I'm not sure we do not have a better version of what you suggest already.
> The GWS proposal for getCapabilities will return the full registry record
> for a resource and this is, in effect, a URL for getting the extra metadata.

No doubt by now you have seen my posting to the gws list commenting on 
this standard as an alternative approach to the problem.  The main problem 
with the VOSI solution is that the choice of which method 
(getRegistration() or getMetadata()) to include it in is the service 
provider's.  Since the one of the objections to including fine-grained 
information in the registry is the curation costs incurred by the 
registry, this needs to be the choice of the registry.

Furthermore, with no guideline as to what information should go in either, 
the provider is hardly motivated to make any distinction at all between 
them.  The effect will be that either the information will not be 
included in either method, or it will be included in both.

To resolve this issue, we need allow a way for a registry to get at 
fine-grained information without effectively forcing other registries to 
carry the same burden of this information.  The VOSI standard does do 
enough to prevent registries that do not want this information from having 
to deal with it.  Even if we later specified what information should go 
into getMetadata() (and managed to get providers to follow that 
specification), the registry's choice of pulling in this extra information 
is all or nothing.  Not only does the URL solution allow a registry to 
choose what fine-grained information it collects, but also it does not 
require that that information fit into the VOResource format.

> If we were to implement your suggestion of a url for the fine-grained
> metadata this would require:
> -          that all resources implement these new URLs (effort matched by
> the getCapabilities implementation anyway)

(I think you mean getMetadata().  It's not clear whether the DAL 
getCapabilities() will include table metadata.)

Not so.  First of all, providing this URL is optional.  Second, all of our 
existing standard catalog services have methods that return table 
metadata.  A simple service (provided by a registry) can translate that 
information into a standard format, so off the bat you get good coverage 
with no effort by the providers.

One relevent future catalog protocol, TAP, will also have these methods. 
The conversion of this information into the standard format can be 
accomplished on the fly from these methods.  Again, there is no 
extra per-service instance effort necessary.

> -          future resources which have fine-grained metadata not of a
> table/column nature would have to implement other URL methods which
> registries then have to implement rather than just using getCapabilities on
> those resources (a method which will work on all existing and future
> resource structures)

You are neglecting the effort of incorporating that fine-grained 
information VOResource.  The point is that if we can just point to the 
information, it does not have to be in VOResource format.

> -          the registry interface will need changing to take account of
> getting full resource information rather than the skeleton record

I don't understand this.  Anybody who wants the fine-grained information 
can get it by following the URLs.  Anybody who doesn't want this 
information is not saddled with it anyway.  No change the the registry 
interface is required.

cheers,
Ray