New version of VO Support Interfaces: v0.26

[Doug Tody]

Hi Paul -

I agree with most of what you say.  The service provider (not
necessarily implementer or operations team) is the ultimate source
of all information describing the service.  The key issue is
that *resource* metadata, describing the service at a high level,
has nothing to do with the basic functioning of the service; the
service should describe only what it knows about, that is, itself
(the service metadata) and any data it manages.  The key problem with
putting an entire VOResource at the level of the service, is that we
are then requiring the service to curate resource metadata.  I think
the Resource Registry is much better suited to curating Resource
Metadata, describing the relationships between related resources,
ensuring resource metadata completeness and integrity, and so forth.

	- Doug


On Tue, 8 May 2007, Paul Harrison wrote:

> 
> 
> 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