RofR

[Tony Linde]

Hi Aurelien,

> Moreover, the type of agregation invisible to the VO should 
> not be a problem.
> If it's invisible, it doesn't need any specifications from 
> the VO point of view.

Exactly - let's forget about aggregation - the only registries which we in
the VObs need to worry about are publishing ones. They'll all be listed in
the RofR, they'll all be harvestable and some will be searchable.

> There will always be new extensions that are not supported by 
> all registries, so advertising which ones are supported could 
> be useful.

Exactly. If a registry cannot store, query on and return all current and
future extensions then it should list the ones it can do so with.

Cheers,
Tony. 

> -----Original Message-----
> From: owner-registry at eso.org [mailto:owner-registry at eso.org] 
> On Behalf Of Aurelien Stebe
> Sent: 12 April 2005 16:57
> To: registry at ivoa.net
> Subject: Re: RofR
> 
> The problem concerning the agregation of registries is that 
> nobody seems to agree on how many registries will exist in 
> the future (publishing and searchable).
> I would guess that there wouldn't be more than half a 
> thousand publishing ones and tens of searchables.
> Anyway, even in the worst case scenario, lets say more or 
> less 500 publishing registries to be harvested every day.
> The harvesting of the VO community would then represent half 
> an hour of work for full searchable registries per day.
> This does not seem a lot to me, but agregation could be put 
> back on the table if this happens to be a problem.
> Compared to this, the load for the publishing registries is 
> minimal (they don't even have the load of the search interface).
> So, from my point of view, the agregation is not technically needed.
> 
> Moreover, the type of agregation invisible to the VO should 
> not be a problem.
> If it's invisible, it doesn't need any specifications from 
> the VO point of view.
> These relations don't even need to use the OAI for 
> harvesting, they could use any method both parties agree upon.
> 
> Concerning the support of extensions, our registry (still in
> developement) at ESAC
> deals with unknown extensions the same way as the STScI one does.
> There will always be new extensions that are not supported by 
> all registries, so advertising which ones are supported could 
> be useful.
> I think that using the OAI sets the way it is described in 
> the RI doc might be enough.
> Applications would simply have to search for a registry that 
> supports their needs.
> 
> cheers,
> Aurelien
> 
> KevinBenson wrote:
> 
> > Yes I agree, I think that both concepts would be good.  As 
> you say no 
> > anointing of full registries, you might have Heasarc managed by 
> > Carnivore and NCSA managed by STSCI or neither.  I do think there 
> > should be some encouragement though to do this, otherwise a lot of 
> > publishing registries will never let a Full Registry manage their 
> > authority id's.  As you say Tony maybe it is just a 
> recommendation on 
> > smaller publishing registries that do not have a lot of resources.
> >
> > On another note we keep talking about this centralized registry at 
> > www.ivoa.net this seems fine, but if nobody minds having a 
> lot of the 
> > same duplicate entries coming back from a OAI harvest (or 
> putting back 
> > the GetRegistries interface method), then you could 
> potentially just 
> > let the Full Registries return back any new/updated 
> Registry Types.  
> > Then a publishing registry just needs to register with any Full 
> > Registry.
> >
> > There was talk of a local/special registry or "private publishing 
> > registry"
> > and have a Full Registry be able to manage these as well; is that 
> > correct?
> > Why bother, my notion of a local registry is one that much 
> like a full 
> > registry it will contain a search interface and be able to harvest 
> > external registries if it desired (some or all external 
> registries).  
> > It might even have all the Resources like a Full Registry.  
> The only 
> > difference is that it is hidden from the world, so there 
> should be no 
> > tracking at all and I don't see why any Full Registry needs to keep 
> > track of it.  The only one who should know its existence is 
> the person 
> > who setup the registry and people who setup apps to point at that 
> > registry.  Does a Full Registry really need to know about 
> these local 
> > special registries? (is there a thought that they will not have a 
> > search interface?)
> >
> > Cheers,
> > Kevin
> >
> > -----Original Message-----
> > From: owner-registry at eso.org 
> [mailto:owner-registry at eso.org]On Behalf 
> > Of Tony Linde
> > Sent: 11 April 2005 19:50
> > To: registry at ivoa.net
> > Subject: RE: RofR
> >
> >
> > My take was that there will be lots of full registries, not 
> just one 
> > or two per country but probably at least one per portal 
> installation 
> > and app centre to make searching faster. So probably 
> hundreds around 
> > the world. Then, for those just publishing a few datasets 
> who didn't 
> > want to be bothered with being harvested by all these 
> registries every 
> > night, they could upload their records to a nearby full 
> registry: and 
> > the easiest way of doing that was simply to run a cut down registry 
> > app which is harvested by only one other registry. Made life easier.
> >
> > But as I said in my previous email - we can have both concepts 
> > implemented.
> >
> >  
> >
> >> hierarchical model will depend on the practice of the 
> annointed full 
> >> registry of a region.
> >>   
> >
> >
> > Again, I don't think there will be any annointed full 
> registries but 
> > hundreds of them.
> >
> > 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 19:20
> >> To: registry at ivoa.net
> >> Subject: RE: RofR
> >>
> >> Hi Tony,
> >>
> >> On Mon, 11 Apr 2005, Tony Linde wrote:
> >>   
> >>
> >>> No, you cannot. Only one full registry can harvest the 
> records of a 
> >>> publishing registry. And it is that full registry that 
> manages the 
> >>> authIDs owned by the publishing registry.
> >>>
> >>> That is the definition of full and publishing registry 
> that we were 
> >>> working with at the Harvard interop meeting from which we
> >>>     
> >>
> >> came up with
> >>   
> >>
> >>> the owned and managed authIDs concept.
> >>>     
> >>
> >> I think this is a little circular.  We never said that 
> only one full 
> >> registry can harvest from a publishing registry.  As I 
> remember it, 
> >> owned/managed was motivated as a way of trading records across VO 
> >> projects.  That is, there was a desire to reduce, for example, the 
> >> number of US registries that AstroGrid would have to harvest from.
> >> This was desirable because it was pressumed to be simpler and have 
> >> less overhead from a performance stand-point.  Our 
> discussions have 
> >> illustrated that the former is not all that correct.  RofR posits 
> >> that the latter is not that big a deal.
> >>
> >> I think the important thing to realize is that in the US, we 
> >> currently have 2 "full" registries based on different technologies 
> >> and feature different interactive user interfaces and excell in 
> >> different ways.  This is a Good Thing in my book.  Under the 
> >> aggregation system, one has to be annointed the "US Full 
> Registry".  
> >> If you say that a publishing registry can only harvest 
> from one full 
> >> registry, then one is complete subserviant to the other.  
> It's really 
> >> not necessary.
> >>
> >>   
> >>
> >>> extensions
> >>>     
> >>
> >> This issue of supporting/storing non-standard extensions 
> is mostly a 
> >> red-herring.  We'll have to deal with it separately.
> >> It's only an issue in that when we do deal with it, how far 
> >> non-standard extension records propogate through the hierarchical 
> >> model will depend on the practice of the annointed full 
> registry of a 
> >> region.
> >>
> >> cheers,
> >> Ray
> >>
> >>
> >>   
> >
> >
> >
> >
> >  
> >
> 
>