New version of VO Support Interfaces: v0.26

[Doug Tody]

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