RofR

[Tony Linde]

> Standard where the naming authority is said to only be able to create 
> identifiers within the authorityID that it owns.

Yes.

> this list) is that there should only be one publishing registry for a 
> particular authorityID ... This requirement is not 
> mentioned within the standards, but it would seem sensible.

If you define the publishing registry as the one which owns/manages the
authID, then, yes, that is the one which originates those records. Records
should be harvested from that registry for greatest authenticity. This is
part of the standard mentioned above.

> The particular use case that I was thinking about was precisely where 
> you do know exactly the IVO id that you want more information 
> on - often 
> the case where a service needs to look up more information 
> about another 
> service - in that case the agent could use the RofR to find which 
> registry could service the request for a particular authorityID.

Only if that publishing registry supports the query interface. In general,
if you want to look up a resource record, you ought to go to a full
registry. There certainly is no need to go to the publishing registry. 

Cheers,
Tony. 

> -----Original Message-----
> From: Paul Harrison [mailto:pharriso at eso.org] 
> Sent: 13 April 2005 13:56
> To: Tony Linde
> Cc: registry at ivoa.net
> Subject: Re: RofR
> 
> Tony Linde wrote:
> >>OK my language is loose here - what I mean is searching on 
> the records 
> >>that belong to a particular AuthorityID - this is the basic unit of 
> >>ownership of records, and is the smallest unit that we can attach 
> >>diffent management functionalities to within a registry.
> > 
> > 
> > Thanks Paul. But I would still maintain that the authID is 
> meaningless.
> 
> The authorityID is not meaningless, as I said it has been 
> implemented as 
> the basic aggregated storage unit that records can fall into - this 
> happens to be a useful property - this is implicit the Identifiers 
> Standard where the naming authority is said to only be able to create 
> identifiers within the authorityID that it owns.
> 
> > Searching for records that belong to a particular authID 
> only gives you
> > records that belong to a particular authID. Any rationale 
> for grouping
> > records under an authID is purely down to the person/org 
> which owns that
> > authID and cannot be assumed to be the same rationale for 
> any other authID.
> 
> This statement does not reflect current usage. Another essential 
> characteristic of the records within a particular authorityID that is 
> apparent within implementations (and seems to be widely 
> supported within 
> this list) is that there should only be one publishing registry for a 
> particular authorityID - this greatly eases the logic behind tracing 
> provenance through the harvesting process. This requirement is not 
> mentioned within the standards, but it would seem sensible.
> 
> > If you know the rationale for a given authID and want to 
> use that as part of
> > a query then you can do so, but if you already know that 
> much, you probably
> > also know the specific resource you want to use anyway.
> >
> 
> The particular use case that I was thinking about was precisely where 
> you do know exactly the IVO id that you want more information 
> on - often 
> the case where a service needs to look up more information 
> about another 
> service - in that case the agent could use the RofR to find which 
> registry could service the request for a particular authorityID.
> 
> 
> -- 
> Paul Harrison
> ESO Garching
> www.eso.org
>