RWP04: Registry Replication

[Keith Noddle]

Ah, poorly explained, I'll try again...

> > 
> >       * A registry is viewed just another a resource
> 
> Correct.
> 
> >       * By definition, resource entries in a registry include a
> >         description of themselves (note: fine grained vs 
> > coarse grained
> >         resource metadata? This proposal requires fine grained)
> 
> We should not dictate the content or structure of registries. I'm not sure
> why 'requires fine grained'.
Agreed but we can define the structure of the metadata which describes
the registry. The more information in that metadata, the better the
searching will be.

> 
> >       * The description of the content of a registry grows as other
> >         resources are added to it, BUT:
> > 
> >       * It is only necessary to add the "new" metadata from the added
> >         resource to the registry description (the goal being that the
> >         registry description contains the scope of the resources it
> >         holds but not the detail, that is in the individual resource
> >         descriptions)
> 
> I'm lost. What is 'scope of the resources'?
An example (forgive me if this is astronomically challenged, it's the
principle): say a registry has entries for 3 resources an X-Ray all sky
survey, a radio all sky survey and a radio northern hemisphere survey.
The metadata for the *registry* needs to reflect that it has resources
which include X-Ray, Radio, All-sky and Northern Hemisphere. Then if the
query calls for say, optical data, this registry can be omitted from
"scope={"all}" type queries. I realise the more resources there are in a
registry the less selective this becomes, but there are other options
for making this type of information useful.
 
> 
> >       * All registries mirror all other registries
> 
> In content? Or just mirrors the list of registries?
I should have said "All registries contain the metadata descriptions of
all other registries." i.e. a registry has all the other registries
entered as a resource. I was alluding to mirroring as the mechanism
whereby the metadata would be shared. My apologies.

> 
> >       * A registry only actions queries against resources for which it
> >         is authoritative (i.e. not resources for which it is 
> > a mirror),
> 
> If it mirrors the resource metadata, why shouldn't it answer the queries?
Because it only contains the metadata describing the registries,
"mirror" was the wrong term to use. See above.

> 
> >         BUT:
> > 
> >       * A registry can initiate a query requesting it be actioned
> >         against mirrored resources (to manage "registry unavailable"
> >         problems - this needs further work)
> 
> ??
> 
> 'fraid I'm lost here.
One of the concerns about "multicast queries" was the amount of
redundant responses that would be generated when a resource is known to
more than one registry (i.e. mirrored). There was a suggestion that a
resource be marked as local or mirrored. Assuming this to be the case,
I'm proposing that when a suitable resource is located, only the
registry which owns that resource (i.e. the registry for which the
resource is local) answer the query, thus removing redundant responses.
In the event that registry is unavailable, we need a mechanism to get
one of the mirrors to respond instead.

Hope this clarifies a little...

Keith.

-- 

Keith Noddle			Phone:  +44 (0)116 223 1894
AstroGrid Technical Lead	Fax:    +44 (0)116 252 3311
Dept of Physics & Astronomy	Mobile: +44 (0)7721 926 461
University of Leicester		Email:  ktn at star.le.ac.uk
Leicester, UK   LE1 7RH		Web:    http://www.astrogrid.org