Harvesting

Tony Linde ael at star.le.ac.uk
Wed Sep 10 00:34:10 PDT 2003


Hi Bob,

> We need to come to some -- perhaps temporary -- agreement on 
> the intertwined issues of identifiers and mirror services.  I 

The approach suggested in the SkyNode doc
(http://skyservice.pha.jhu.edu/develop/vo/adql/) of using the ShortName in
the short term seems a good idea.

> 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 

How does the replica know this if the original has been changed but not yet
replicated.

Cheers,
Tony. 

> -----Original Message-----
> From: Robert Hanisch [mailto:rjhanisch at worldnet.att.net] 
> Sent: 06 September 2003 17:37
> To: Tony Linde; registry at ivoa.net
> Cc: Pierre Fernique
> Subject: Re: Harvesting
> 
> 
> 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