RofR

[Gretchen Greene]

Okay fair enough,  YET what we've opted to do in the land of 
freedom is to publish a field "harvestedFrom",  not in the 
OAI or VOResource form,  but as part of our internal field 
such that one could see where the resource originated from.  
This field has proven to be VERY helpful for curation of 
resources and tracking.  There is no other standard mechanism 
currently in place for doing this.  

If the managed or searchable AuthorityIDs are available, then 
this COULD go away but what happens in the case where 
something about a resource or needs to be changed?  I can see 
with the evolvement here how the resources are propagating 
OUT but not easily traceable back to the provider or curator.

-Gretchen


Hi Gretchen,

> Why would you need to hide a publishing registry record in 
a 
> full registry? 

You wouldn't. It is strictly a private link between the full 
registry and
another piece of software whereby the full registry sources 
some resource
records from that other piece of software. To the VObs, the 
full registry
owns and maintains those records and that is all.

Cheers,
Tony. 

> -----Original Message-----
> From: Gretchen Greene [mailto:greene at stsci.edu] 
> Sent: 12 April 2005 16:32
> To: 'Tony Linde'; registry at ivoa.net
> Subject: RE: RofR
> 
> It sure seems like these discussions are going in all 
> directions and there seems to be cross-over between how 
> registries are required to interoperate and standardize 
> versus preferences in implementations.
> 
> Why would you need to hide a publishing registry record in 
a 
> full registry?  I don't understand why this is necessary in 
> servicing the community.  We have in our registry contents 
> all the entries and types that are harvested.  Isn't that 
> something that registries can choose to implement?  
> 
> -Gretchen
> 
> 
> 
> -----Original Message-----
> From: owner-registry at eso.org [mailto:owner-
registry at eso.org] 
> On Behalf Of Tony Linde
> Sent: Monday, April 11, 2005 3:41 PM
> To: registry at ivoa.net
> Subject: RE: RofR
> 
> 
> > Would there be a Registry record for this "local" 
registry that 
> > propogates to the full registries, or would that be 
hidden as well?
> 
> Nope - all hidden - it doesn't exist to the world.
> 
> >   1) To know which registry a record originated from so 
> that problems 
> > with
> >        it can be tracked down.  
> 
> The trail will end at the managing registry - you'll have 
to 
> take it from there on foot.
> 
> > Does anyone outside of the managing registry need to 
> understand this 
> > distinction?
> 
> Nope - all internal - invisible to the VObs.
>  
> Cheers,
> Tony. 
> 
> > -----Original Message-----
> > From: Ray Plante [mailto:rplante at ncsa.uiuc.edu]
> > Sent: 11 April 2005 20:10
> > To: Tony Linde
> > Cc: registry at ivoa.net
> > Subject: RE: RofR
> > 
> > On Mon, 11 Apr 2005, Tony Linde wrote:
> > > Thanks, Ray. That's fine - we can have it both ways.
> > Registries which
> > > want to be harvested every night can add their details 
into
> > the RofR
> > > and those which don't stay out of it.
> > 
> > Okay, I can see this working.  We put down a path forward 
for 
> > aggregating the harvesting, but we have something simpler 
in place 
> > that will work in the near term.
> > 
> > > So let's bring back the local registry. If a data centre
> > doesn't want
> > > to be bothered by the world knocking on its door every 
night, it 
> > > simply sets up a private arrangement with another 
registry to be 
> > > harvested on a regular basis (or when it asks for
> > harvesting) and the rest of the VObs is none the wiser.
> > 
> > Would there be a Registry record for this "local" 
registry that 
> > propogates to the full registries, or would that be 
hidden as well?
> > 
> > The reason I ask is that there is actually two purposes 
we've 
> > discussed for listing authority IDs in the Registry 
record.
> >   1) To know which registry a record originated from so 
> that problems 
> > with
> >        it can be tracked down.  
> >   2) To aid in harvesting aggregation.  
> > 
> > > The registry which manages these records for the local 
one
> > will need
> > > some way of identifying the authIDs it owns and those it
> > manages for
> > > other local registries but, again, this is invisible to 
the
> > outside world.
> > 
> > Does anyone outside of the managing registry need to 
> understand this 
> > distinction?  (How would they use this
> > information?)  If not, then you might consider 
this "internal data" 
> > and thus need not be incorporated into the standard 
metadata.  The 
> > exception might be if a Registry record for the local 
registry does 
> > not propagate to the world; if so, there would be no 
record 
> of where 
> > its authority IDs come from.  In any case, it's not clear 
that the 
> > distinction between owned and managed is all that 
important.
> > 
> > As for (2) above, I rather think that it's not the 
> authority ID that 
> > you should be tracking, but rather a registry handle of 
some sort 
> > (IVOA ID or OAI base URL, whatever's appropriate).  
Again, if the 
> > local registry is to be hidden, then this would be 
> "internal data" not 
> > exported.
> > 
> > cheers,
> > Ray
> > 
> > 
> 
>