RofR

[Tony Linde]

Hi Matthew,

> I think that what is clear from the discussions that have 
> been happening on this list over the past ten days is that 
> this concept of a hierarchy of full registries with 
> owning/managing publishing registries is one that a lot of us 
> are not happy with. 

It isn't a hierarchy. The original idea was a set of peer-related full
registries, all harvesting from each other. I also don't think it is a model
that can last but while we only have a few full registries around the world,
it at least works.

What is the problem? Why are people not happy with it?

> How can you stop anyone from harvesting a 
> publishing registry unless you make the  harvesting interface 
> usable only by particular individuals?

You might do that. Or you could not allow any harvesting and update the
registry by push methods.

But the way I had in mind was simply that no-one else would know about the
publishing registry - only the full registry to which it was attached. It
would not have a resource record so no-one would know where to go to harvest
it.

> Also a publishing registry holds authority records for the 
> authority records it maintains, e.g. the HEASARC registry, 
> and this is not necessarily a full registry.

Yes, the publishing registry owns those authIDs but they are managed by
another registry, a full registry. That's why you need to harvest resources
from both owned and managed authIDs in a full registry.

Cheers,
Tony. 

> -----Original Message-----
> From: Matthew J. Graham [mailto:mjg at cacr.caltech.edu] 
> Sent: 11 April 2005 18:06
> To: Tony Linde
> Cc: registry at ivoa.net
> Subject: Re: RofR
> 
> Hi,
> 
> >> The options for a registry are really:
> >> - is it a publishing registry (I can harvest the records it 
> >> maintains)
> >
> > 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.
> >
> > If you want to change what was agreed then, fine, but 
> you'll need to 
> > either come up with new terms or make it clear how you are 
> redefining 
> > the terms we have been using so far.
> 
> I think that what is clear from the discussions that have 
> been happening on this list over the past ten days is that 
> this concept of a hierarchy of full registries with 
> owning/managing publishing registries is one that a lot of us 
> are not happy with. How can you stop anyone from harvesting a 
> publishing registry unless you make the  harvesting interface 
> usable only by particular individuals?
> 
> Also a publishing registry holds authority records for the 
> authority records it maintains, e.g. the HEASARC registry, 
> and this is not necessarily a full registry.
> 
> >> I also think we need to drop this idea of a full registry because 
> >> supporting every variant schema that every astronomer comes up is 
> >> unrealistic
> >
> > It has nothing to do with the astronomer. It is the owner of a 
> > registry and the people they authorise to add records who 
> may come up 
> > with new schema. If your only public means of adding a record to a 
> > registry only allows the user to add specific types of data 
> then that 
> > is all you will get.
> >
> >> (and this has nothing to do with
> >> relational/native XML implementation), e.g. is Astrogrid 
> intending to 
> >> support the horrible hack schema that identifies records from the 
> >> Penge Local Astronomy Youth Club?
> >
> > You're mixing up supporting a schema with storing it. You 
> do not have 
> > to support a schema in order to store it. If someone adds a record 
> > with a schema not supported by any software then it won't 
> be used by 
> > anyone.
> > That
> > does not stop the registry from storing it. The registry 
> mandates that 
> > certain information must be included (VOResource) but whatever is 
> > added beyond that - the registry is unaware of it. If 
> someone stores a 
> > record with some schema extension that only one piece of software 
> > knows about then only that piece of software will use the 
> data stored 
> > under that extension.
> 
> I disagree: what is a registry = something that can store records
> (conceptual) but how something is stored is an implementation 
> detail and that necessarily means that the only thing that 
> can be stored is what is supported, i.e. this particular 
> record can be stored because I have implemented a storage 
> model for it.
> 
> 	Cheers,
> 
> 	Matthew
> 
>