RofR documentation, status

[Ray Plante]

Hey Kevin,

Thanks!  I was hoping someone could read it over before I posted it ;-)

On Wed, 6 Jun 2007, KevinBenson wrote:
> a.)
> In section 3 does OAI have a 'since' typically always used 'from' or 'until'?

You are correct--thanks.

> b.) Section 3 step 1.  Wondering do you really care to harvest with the 'set' 
> parameter?  The primary purpose of RofR is for other Registries (such as Full 
> Registries) to discover publishing Registries to do harvests but a Full 
> Registry will contain all Resources, as stated in section 4.1 there might be 
> other 'standard' type Resources.  Why not just do a ListRecords with no 'set' 
> parameter and get everything (then as you say in your steps after the first 
> time use the 'from' with no set parameter)?

First off, you are welcome to do the harvest however you like; there is 
certainly more than one way to achieve the same end.  However, the recipe 
described in the Note ensures that you get everything without having to 
sort through the results, particularly for duplicates.

If you do not use set=, then you might subsequently, for example, ingest 
all of these records into your registry.  Then you select from your 
registry all of the harvestable registries and proceed. This has three 
problems:

1)  The RofR does not manage those Registry records.  You should get
     these from the registry they describe if you want to guarantee
     that you have the latest version.  The RofR will harvest these
     records at some interval, but it could be out of date.  This is
     why you harvest CDS records from CDS and not the NVO.

2)  When you harvest from each publishing registry, you will get its
     Registry record again.  You will need to manage this somehow
     (presumably by just overwriting the one you ingested from the
     RofR).

3)  Unless you encode as a special case to skip the RofR when you
     harvest from all of the publishing registries, then you will get
     the RofR records twice.

Getting around these issues means by either sorting through results to
avoid duplicates or ingesting records multiple times.  If you find
this easier to do (while avoiding errors) then that is fine.

> c.)
> Section 4.3  Prefer to setup smaller publishing registries that just contains 
> Resources it manages and that will certainly go into the RofR, and had hoped 
> the Full Registries that does have an OAI interface but not really manage any 
> Resources would not necessarily need the 'vg:Harvest' interface would also 
> find it's way into the RofR. From this section I will need to make sure it 
> has a 'vg:Harvest' interface to place it into the RofR.  Correct?

The point of the RofR is to only register publishing registries.
Thus, if you have a full registry that does *not* manage any of its own
resources, then it does *not* need to be in the RofR and it does not
*need* an OAI interface.  (Note that the validater does not check the
search interface.)  You can throw on an vg:Harvest interface for kicks, if
you like, but you shouldn't register it with the RofR as that would be
a waste of other harvesters' time.

Note however, that if the full registry is not a publishing registry,
then you will need to register it with a publishing registry (one of
your small ones) if you want its record to appear in other registries ;-).

> You have a sentence: "Second, any full registry can serve this same role, 
> since it knows about all other searchable registries."
> How does a full Registry know about these other searchable Registries if they 
> never made it into the RofR?

As noted above, your full registry will need to be registered with a
publishing registry.  (Just place the record into one of your little
registries.)  The RofR was not intended as a way to find searchable
registries.

> I am for your counter-argument, my thoughts were a client application that 
> can find all the searchable Registries (such as via RofR) might ask/tell the 
> user 'Found a closer Registry. Would you like this to be your main Registry?' 
> But maybe we can tackle this at a later date and time.

Assuming that you have done the above, then you can set the AstroGrid
full registry as the client's default.  The client uses that one to
find other searchable registries.

thanks again,
Ray