RofR

[Tony Linde]

Thanks, Ray. That's fine - we can have it both ways. Registries which want
to be harvested every night can add their details into the RofR  and those
which don't stay out of it.

So let's bring back the local registry. If a data centre doesn't want to be
bothered by the world knocking on its door every night, it simply sets up a
private arrangement with another registry to be harvested on a regular basis
(or when it asks for harvesting) and the rest of the VObs is none the wiser.

The registry which manages these records for the local one will need some
way of identifying the authIDs it owns and those it manages for other local
registries but, again, this is invisible to the outside world.

So, every registry 'known' to the VObs is a publishing one and supports the
harvest methods. The resource record for that registry includes the authIDs
that it is responsible for and a normal harvest only returns these records
but a full set can also be got (or the other way around).

Some registries also support the standard query methods, so we need some way
to indicate this in the registry record.

Going on to Matthew's point, some registries can only search on specific
extensions, so we'll need to be able to list the schemas supported by those
registries (default is that all searches are enabled).

Sound right?

Cheers,
Tony. 

> -----Original Message-----
> From: owner-registry at eso.org [mailto:owner-registry at eso.org] 
> On Behalf Of Ray Plante
> Sent: 11 April 2005 18:38
> To: registry at ivoa.net
> Subject: Re: RofR
> 
> Hi all,
> 
> > I daresay I've misunderstood the RofR concept so could someone step 
> > through the registration/harvesting scenarios for me.
> 
> (I really like direct questions like this!)
> 
> The problem an RofR is intended to solve is two-fold:
>   1) how does a new publishing registry let the world know it 
> has records 
>        to harvest? 
>   2) how does a registry attempting to be "full" know who to 
> harvest.  
> 
> I'll start with the first.  Using a browser, the 
> administrator of a new publishing registry goes to a web page 
> at www.ivoa.net and enters into a very simple form the OAI 
> base URL for its publishing registry.  When submit is pushed, 
> the server uses the OAI Identify function to pull over the 
> publishing registry's Registry record.  (It could also do a 
> quick OAI compliance check.)  The server adds the Registry to 
> the RofR.
> 
> Now the second.  The RofR features an OAI interface which "Full" 
> registries query regularly.  When a new publishing registry 
> appears, all full ones find out about it and begin harvesting 
> from it.  
> 
> Very simple, eh?
> 
> Now to comment on some of the issues that have come up in response.  
> 
> On Mon, 11 Apr 2005, Tony Linde wrote:
> > Let's distinguish between full and publishing registries. A full 
> > registry is expected to contain all known resources, kept 
> up to date 
> > via some harvesting mechanism; it exposes one or more query 
> > mechanisms. A publishing registry only contains a few local 
> resources, 
> > kept up to date via some local mechanism;
> 
> As I think others have pointed out, in reality, the two 
> different types of registries are really two different roles. 
>  That is, we have full registries that also publish records 
> and, thus, can be harvested.  
> 
> > The original idea behind the owned/managed authIDs was that a 
> > publishing registry would have one or more owned authIDs 
> and resources 
> > with identifiers under those authIDs. A full registry would 
> also have 
> > owned authIDs but would 'manage' the authIDs for one or more 
> > publishing registries. The publishing registries would only have to 
> > support a simple push (update) or pull
> > (harvest) interface with one full registry. Noone else 
> would ever know 
> > about the publishing registry. The full registry would ensure that 
> > noone else registered either the owned or managed authIDs. 
> Other full 
> > registries would only ever harvest from full registries, gathering 
> > resources under both the owned and managed authIDs.
> 
> This original mechanism was at best complicated, more 
> complicated than necessary as the RofR idea would suggest.  
> The details are in the discussion of "ownedRegistry", I might 
> summarize as follows:
>   o  We're keeping track of who we harvest on a 
> per-authorization basis, 
>        but harvesting actually takes place on a per-registry basis. 
>   o  The book-keeping of authority IDs is prone to error.
>   o  It requires a human, "out-of-band" coordination to set up the 
>        publishing-full relationship.
>   o  It depends on a single-parent hierarchy, which has political and 
>        availabiltiy issues associated with it.  
> 
> An RofR gets rid of all these complications.  
> 
> > Now the first problem with the RofR is that it contains access 
> > information about every publishing registry, which previously was 
> > hidden from world view. What is this going to be used for?
> 
> I don't recall a need to keep publishing registries hidden 
> from the world.  
> (The use of OAI is to make this stuff more visible.)  The 
> owned/managed scheme was meant as a way of reducing the 
> number of places a full registry needs to harvest from.  This 
> might be advantageous if it were not simple to figure where 
> all the publishing registries are.  RofR addresses this.  It 
> assumes that the number of places to harvest from is not large.  
> So what other reason is there to aggregate the harvesting?  
> 
> > Are all the full registries expected to harvest from *all* the 
> > publishing registries?  This may be a problem for sites 
> which do not 
> > want wide-open access to their registry.
> 
> Because of the overhead of supporting the world?  Again, the 
> argument behind RofR is that this is not a big deal today.  I 
> would suggest that if/when it becomes a problem, let's adapt 
> then.  I think it would be a lot easier to add aggregation of 
> harvesting once we have the basics in place.  
> 
> On Mon, 11 Apr 2005, Roy Williams wrote:
> > The problem then is that the owner of the RofR is perceived 
> as being 
> > the center of the IVO, which is politically unattractive, 
> unless you 
> > are part of the project that runs the central registry, in 
> which case 
> > it is very attractive.
> 
> As a fan of de-centralization, the simplicity of this 
> solution overrides any misgivings I might have.  (There 
> really is very little to this RofR.  And note, end users 
> won't see it.)  Again, I think we can add a decentralizing 
> mechanism later.  
> 
> cheers,
> Ray
> 
> 
>