New version of VO Support Interfaces: v0.26

[Tony Linde]

That makes sense to me, Doug - thanks.

I'm not sure what proportion of services would be managed in this way but
I'd be surprised if the major ones weren't. That said, I'm sure you'd agree
that other services might not have this separation of concerns.

So, we've got:
a) all metadata maintained via registry UI;
b) resource metadata maintained by registry UI and service metadata sourced
from service (using your terminology);
c) all metadata sourced from service.

Questions (to ALL):
1. can any of the above be knocked out: ie, knowing all the resources in
your registry, can we exclude any of the above options?
2. how do we split up VOResource into resource and service metadata (Doug's
terms)? I posed this in a previous reply to Ray: is it at the Capability
element?
3. if all three options are supported, how does each resource indicate which
option it has taken?
3a. should VOSI include (optional) getResourceMetadata and
getServiceMetadata methods (or cgi urls)?
4. any other questions?

Question to Ray: does this cover your requirements, at least enough to
discuss the above questions at Beijing or have I missed a major part of your
proposal?

T.

> -----Original Message-----
> From: Doug Tody [mailto:dtody at nrao.edu]
> Sent: 08 May 2007 21:41
> To: Tony Linde
> Cc: grid at ivoa.net; dal at ivoa.net
> Subject: RE: New version of VO Support Interfaces: v0.26
> 
> Hi Tony, All -
> 
> As only one example, a while back here at NRAO our Web intrastructure
> changed, having something to do with HTTP vs HTTPS.  Clients trying
> to access our services would fail as a result.  It was necessary to
> go into the registry and edit the resource metadata to change the
> accessURL for all these services.  Later, when the problem was fixed,
> we changed it back.  The services themselves were never touched.
> 
> Another simple example might be the contact information for a
> resource/service.  This is an operations matter, not a service
> function matter.  If we want to change this for all our services,
> it would be simplest to do this by editing the resource metadata for
> all affected services, probably in some registry portal, ideally with
> some sort of global edit.
> 
> If on the other hand, we have to do this at the level of the deployed
> service, the service may be deployed on a protected, configuration
> controlled, operational server (our production services here are as I
> am sure they are at many other sites).  We can't just go edit those
> XML files.  It can be fixed in a test version (which is probably
> not registered) but we may have to wait a week or so for any change
> to propagate to the production version.  If on the other hand the
> resource metadata is curated by a registry, we can login and change
> it immediately.
> 
> If the entire VOResource record comes from the service, what
> happens to our ability to enter/review/edit resource metadata in the
> registry, using the nice GUIs, possibly SQL-based tools, verifiers,
> etc. available?  What *will* happen is that the user will review
> and edit this information in a registry portal, then the next time
> the VOResource is updated from the service, the entire record will
> be blown away.  In effect there is no longer any point to having
> an administrative interface to the registry; to do anything with
> the resource metadata we have to edit the low level XML directly
> at the service level (most VO users should never even see things at
> this level).
> 
> My suggestion is that the Resource Registry should manage and curate
> high level resource metadata; it also should cache and search service
> metadata, and might also cache/search "fine-grained" metadata.
> The getCapabilities operation for a service can return the service
> metadata, i.e., the "capability" element of a VOResource record
> for a service, as defined by the service developers.  When updated,
> this would blow away the previous capability element, but the update
> operation would leave all other elements of the VOResource intact.
> If an independent tool, for example a foot print service, should
> update the Coverage portion of the resource metadata, this would in
> turn leave the service metadata unaffected.  Likewise, updating cached
> column metadata for a table should not affect the resource metadata
> for the parent data collection.
> 
> > What you say makes sense, Doug, but only if the person maintaining
> the
> > resource metadata is different from the one maintaining the service
> > metadata.
> 
> Note that the service metadata itself (stuff like MaxSR, MaxRecords,
> which optional capabilities the service instance implements,
> input parameters, etc.) is all or nearly all simple stuff which
> can be autogenerated by a good service implementation or framework
> from knowledge fundamental to the basic functioning of the service.
> It only needs to change when the service changes, and ideally will be
> automatically updated in the registry when a new version gets deployed.
> 
>  	- Doug
> 
> 
> 
> On Tue, 8 May 2007, Tony Linde wrote:
> 
> > 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