Harvesting

Robert Hanisch rjhanisch at worldnet.att.net
Sat Sep 6 09:37:19 PDT 2003


Hi Tony et al.  Yes, I think the next major thing is the
harvesting/integration/maintenance of the registries, and we are far
enough
along on the content and structure (a few more tweaks being required) to
start thinking about the next steps.

We need to come to some -- perhaps temporary -- agreement on the
intertwined
issues of identifiers and mirror services.  I would like to ask the CDS
folks who developed GLU (Pierre Fernique, especially) to comment on this
issue, as they have a number of years of experience already in managing
mirror services within the GLU database.  Pierre:  could you remind us
how
mirror or replica services are denoted in GLU, and how your CDS services
that utilize GLU decide which of a number of replica services to
utilize?

We had some discussion about identifiers and the "sameness" issue at
this
past week's NVO team meeting.  I think we agreed on an operating
definition
of "sameness" that avoids worrying about internal implementations and
bit-wise comparisons, but rather is based on the following proposition: 
if
a VO-compliant request is sent to a replica service, and the replica
service
provider asserts that the response is functionally identical to the
response
from the primary service, then the services are the same.  By
functionally
identical, I mean that the response (i.e., VOTable) need not be bitwise
identical, but that any application using it would yield numerically and
semantically identical results.  This statement is a bit more of a
synthesis
of ideas than was stated at our team meeting, and I hope I am not too
far
off the mark.

I am not unhappy with the idea of primarily describing replica or mirror
services through metadata.  If every VO resource ends up having a dozen
mirrors, then this approach would likely get unwieldy.  As our DIS
shows,
multiple registry entries for the same resources can be seen by users as
a)
confusing or b) edifying.  Personally, I find it interesting to see that
I
can get USNO-B from several sites, for example, and by examining the
provenance metadata (publisher) I can select which site to use.  Users
often
develop a sense for which sites provide better response, and might like
to
have the freedom to select among mirrors.  As with our other initial VO
developments, I hope we do not get bogged down searching for an optimal
solution until we fully understand if we have a problem.  Again, the CDS
GLU
has dealt with this for many years already, and their experiences would
be
very informative.

Cheers,
Bob

----- Original Message ----- 
From: "Tony Linde" <ael at star.le.ac.uk>
To: <registry at ivoa.net>
Sent: Friday, September 05, 2003 5:07 AM
Subject: Harvesting


> Ray and I have finished working on the new registry resource schema and
Ray
> is working it up into a set of xsd's that demonstrate its extensibility.
>
> I think the WG should now turn its attention to thre question of how
> resource metadata is distributed throughout the VO. Coming up with a
> workable proposal for this together with the new schema will make it
> possible for the VO projects to work on interop demos for January as
> planned.
>
> Firstly, does everyone agree that harvesting is the next big issue? And,
if
> so, what work has been done so far in Rwp04 (Keith?) and what needs adding
> to create a proposal?
>
> Cheers,
> Tony.
>
> __
> Tony Linde                       Phone:  +44 (0)116 223 1292
> AstroGrid Project Manager        Fax:    +44 (0)116 252 3311
> Dept of Physics & Astronomy      Mobile: +44 (0)7753 603356
> University of Leicester          Email:  ael at star.le.ac.uk
> Leicester, UK   LE1 7RH          Web:    http://www.astrogrid.org
>
>



More information about the registry mailing list