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
Received on 2007-05-08Z11:16:34