New version of VO Support Interfaces: v0.26

[Paul Harrison]

On 07.05.2007, at 21:48, Doug Tody wrote:

> The problem is that a full VOResource can contain considerable
> information which has nothing to do with the basic functioning of the
> service, e.g., general resource metadata describing curation, content,
> coverage, etc., and it is a burden to ask service implementors to
> provide and maintain this information at the level of each service
> instance, particularly when much better tools for entering and
> verifying this high level information may already exist in registry
> portals.  Information which really is specific to the service however,
> such as the service metadata defined in the service specification,
> fundamental limitations, which optional capabilities are implemented,
> the service interface including input parameters etc. (basically
> what is in the Capability element of the VOResource for a service),
> should clearly come from the service since the service is the ultimate
> source of information about its capabilities.

I just do not buy this argument - the service implementer is the  
*only* authoritative source of *any* metadata that goes into the  
registry,
so in practical terms, it is more effort to create some split in the  
metadata and manage the data in two places, with two different  
mechanisms.
It is much simpler for the service implementer to just implement the  
VOSI getMetadata (or capabilities or registration - whatever the  
flavour of the month name is), which is simply returning the XML  
VOResource document. The registries then just need to provide a  
"register a service" form that simply allows the user to enter the  
url of the VOSI endpoint and the service is registered, and any  
updates can simply be carried out with service local edits of the  
metadata, and the registry can automatically update - the overall  
curation problem is simplified by this approach.

This approach has other advantages of course - If you can find out  
exactly the same metadata from the registry or from the service  
itself then the the registry can be viewed as simply a "cache" of  
service metadata, which allows the client searching for services to  
more efficiently search for the services that are suitable with a  
single call. Indeed, at the other end of the spectrum, if the  
metadata discovery is the same from either source, clients can be  
programmed more easily to be able to not be dependent on the registry  
at all, and interact directly with a well known service end-point -  
having the VOSI interfaces *decreases* coupling between various  
components.


Paul Harrison
ESO Garching
www.eso.org