On Authorities...

[Tony Linde]

Hi Tom,

(message copied to registry list - can we continue there?)

> registries.  I feel that's a confusion of functionality that 
> makes any semantically meaningful naming scheme difficult to 
> implement properly.  If names are opaque tokens then I have 

That is the key to the argument. An ID should *not* have any semantic
meaning. All meaning should be in the rest of the metadata. I know we have
put the AuthorityID into the ResourceID but that is simply to ensure
uniqueness when we have no central registration authority. But basically,
the ID must be meaningless. It is only a pointer. 

>From long experience, embedding any meaning into an ID is fatal for the
future expansion of systems.

Cheers,
Tony. 

> -----Original Message-----
> From: Tom McGlynn [mailto:Thomas.A.McGlynn at nasa.gov] 
> Sent: 29 May 2003 19:39
> To: ael at star.le.ac.uk
> Cc: metadata at us-vo.org
> Subject: Re: On Authorities...
> 
> 
> 
> 
> Tony Linde wrote:
> > Hi Tom,
> > 
> > Just to butt in here, the AuthorityID in the Resource ID is the 
> > identifier of the registry. If you choose to register a 
> resource, you 
> > register with a valid registry and the AuthorityID you get 
> is that of 
> > the registry. It is then up to the registry how it allocates the 
> > ResourceKey: it can allow the user to specify one which it 
> then checks 
> > for uniqueness within its own domain or it can simply 
> assign a random 
> > number.
> > 
> 
> That was in fact the crux of the discussion at this week's 
> MWG telecon: Should the authority ID be associated with the 
> identity of the registry? There was some considerable debate 
> on that point. Doubtless this has come up in earlier 
> discussions, but I had not picked up on the idea that naming 
> authorities were tied one-to-one with actual realized 
> registries.  I feel that's a confusion of functionality that 
> makes any semantically meaningful naming scheme difficult to 
> implement properly.  If names are opaque tokens then I have 
> fewer problems, but then there is no real need for distinct 
> Authorities and Keys.
> 
> My feeling is that names need to be under the control of
> the service publisher not the registries.  We should not 
> require users to build a registry solely to be able to 
> control their own namespace.
> 
> Were we to continue down
> this path, I would expect someone (quite possibly me) to 
> build 'virtual' registry services which emulate a registry on 
> behalf of a user who doesn't want to build an explicit 
> registry, but does want to control their name space.
> 
> Analogously my personal e-mail address is tom at mcglynns.org -- 
> a name that I control. That used to point to a real mail 
> account at mcglynn at home.net.  Alas @Home went bankrupt and 
> any mail sent to that real address -- the address associated 
> with a physical mail server -- is now lost to me.  Mail sent 
> to the address at the name that I control, is properly 
> forwarded to my current account mcglynn at comcast.net.
> 
> We should not tie persistent names to potentially transient services.
> 
> 	Regards,
> 	Tom
>