New version of VO Support Interfaces: v0.26

[Tony Linde]

What you say makes sense, Doug, but only if the person maintaining the
resource metadata is different from the one maintaining the service
metadata. I'd always assumed that the service is the resource (ie, the
resource entry points to the service) and vice versa (ie, the service is
known about only through the resource entry), a one-to-one relationship so
to speak. 

In what way are they not the same and how do you have it that different
people maintain the sets of metadata?

[BTW - I don't think this affects the registry discussion as we've accepted
for a long time that you might have the metadata accessible from the
service, even that you could have only a minimal entry in the registry with
detailed metadata only available from the service.]

Cheers,
Tony. 

> -----Original Message-----
> From: owner-dal at eso.org [mailto:owner-dal at eso.org] On Behalf Of Doug
> Tody
> Sent: 08 May 2007 19:51
> To: Paul Harrison
> Cc: grid at ivoa.net; dal at ivoa.net
> Subject: Re: New version of VO Support Interfaces: v0.26
> 
> 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