RofR

[Aurelien Stebe]

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
>>
>>
>>   
>
>
>
>
>  
>