amendments to Identifier framework

[Tony Linde]

Hi again, Ray,

> If not, can you suggest 
> an alternate statement regarding who/what controls the use of 
> authority IDs?

I personally don't think we need one, nor do I think it necessary to trace
names, but if people want to link an authority to an organisation, I can
live with it. But if I want to register an authority of tonylinde.com, I
don't see that it should be traceable back to anyone but me, and if I'm the
named curator of that authority, why do we need more? But it doesn't overly
bother me as long as it is all optional so people can ignore it if they
want.

> I'm essentially suggesting a component of the interface (perhaps
> optional) of a global registry that is capable of granting 
> AuthorityID requests because that registry is capable of 
> determining whether the ID is already in use.  That means 

Gotcha! You mean that a global registry is any 'full' registry?

> My apologies: this is equivalent to what we've called a 
> "local registry".  We've migrated to this name here in the 

It'd be useful if we could all stick to the same names.

> These are not meant to be rules for policing, but a recipe 
> for ensuring unique ownership and control.  

That's fine but I'm always wary of stating a rule that you cannot enforce.

> The main requirement proposed here is having the global 
> registry associate AuthorityIDs with the registry that 
> originates them.

We'll get that by replicating the Registry resource which includes a list of
ManagedAuthority pointers. Yes?

> Perhaps persistent="false" is not needed.  Should we just say 
> the all IVOA identifiers are persistent (thus, disallowing 
> recycling of identifiers)?  I'm cool with this, too.

Sounds okay as a 'best practice' note.

> We plan to add relationships that include a reference to 
> other resources.  Those other resources may disappear.  If 
> their metadata descriptions are completely deleted from the 
> VO environment, then we will have dangling references.  

Good point. Solves the persistence issue as well.

> this interoperation, I'm suggesting one minor change to the 
> Identifier WD specification of the URI form: the use of # to 
> set off a component that is to be ignored by registries.  

Hmm. Sounds okay though, again, I don't think it belongs as part of the
identifier WD. Let'd keep it simple. Any extension of the use of the
identifier *outside* of resource identity should be handled by a Note, I
think.

> Would it help to go through what I've written and segregate 
> the components a bit?
>   *  changes for the Identifier WD
>   *  changes to the RM and extended schema
>   *  requirements for registry service interfaces
>   *  recipes for handling identifiers (that might appear in a Note).  

Sounds good but let's see if anyone else has comments to make (if they can
keep up :) ).

Cheers,
Tony. 

> -----Original Message-----
> From: owner-registry at eso.org [mailto:owner-registry at eso.org] 
> On Behalf Of Ray Plante
> Sent: 15 September 2003 18:08
> To: registry at ivoa.net
> Subject: RE: amendments to Identifier framework
> 
> 
> Hi Tony, 
> 
> Thanks for your comments.  I'm happy to hear more from others.
> 
> One general comment:  The suggests I called "amendments" are 
> all intended to be specific amendments to the Identifier WD.  
> I tried to look at the overall Identifier and Registry 
> framework to understand how we might address the issues that 
> have been under discussion.  Much of whatever comes out of 
> this discussion may appear only as an appendix to illustrate 
> how identifiers are intended to fit into the overall 
> framework (and thus are not a binding part of the spec).  
> 
> On Mon, 15 Sep 2003, Tony Linde wrote:
> > Part A
> > ======
> > 
> > AuthorityIDs are not necessarily owned by organisations. 
> This should 
> > be an optional part of the authority metadata.
> 
> I think we need to be able to trace an AuthorityID to a 
> naming authority, which ultimately has people behind it.  
> Perhaps you are thinking that a registry might "own" an 
> authority ID.  I am assuming that an organization runs the 
> registry, and thus is ultimately in control of its use.  Is 
> this consistant with your thinking?  If not, can you suggest 
> an alternate statement regarding who/what controls the use of 
> authority IDs?
> 
> > Where does the 'global IVOA Name-granting registry' live? 
> Who is going 
> > to maintain this and ensure it is always available? Can we 
> not leave 
> > it up to the replication process to ensure non-duplication of 
> > AuthorityIDs?
> 
> I'm essentially suggesting a component of the interface (perhaps
> optional) of a global registry that is capable of granting 
> AuthorityID requests because that registry is capable of 
> determining whether the ID is already in use.  That means 
> anyone who runs a global registry can grant such names; there 
> does not need to be a single one.  Thus, it does depend on 
> the replication process employed by global registries.
> 
> The important point is, a local registry should not have to 
> replicate the world to ensure uniqueness of AuthorityIDs; it 
> just needs to go to a global resource.
> 
> (Sorry if my explanation was more complicated than necessary.)
> 
> > What is a 'publishing registry'?
> 
> My apologies: this is equivalent to what we've called a 
> "local registry".  We've migrated to this name here in the 
> NVO, I think, because it is more indicative of what it does: 
> it is for publishing, not necessarily searching.  At the 
> global end, we've slipped into the terminology of 
> "searchable" registry.  
> 
> > The rules for adding an AuthorityID to a registry should be 
> left up to 
> > that registry. Why should IVOA set rules about this that it cannot 
> > police?
> 
> These are not meant to be rules for policing, but a recipe 
> for ensuring unique ownership and control.  
> 
> > What are 'first-class resources'?
> 
> Sorry, poor choice of words.  I just mean we should define a 
> class of resource called "Registry".
> 
> > Surely the only steps needed to resolve an identifer are:
> > 
> > 1. Registry looks within itself for a matching identifier. 
> If none is 
> > found and registry is *not* a 'full' (see 
> > http://ivoa.net/forum/registry/0193.htm)
> > registry then the query is sent to a full registry.
> > 
> > 2. If a full registry cannot find the identifier then 
> 'resource is not 
> > found' message is returned.
> > 
> > If an application (or, more likely, user) wants to try to 
> dig further 
> > then they can do so by searching on AuthorityID, organisation 
> > ResourceID etc.
> 
> The recipe I spelled out is simply an extension of this (that 
> is, our 1 and 2 are the same).  By using a "full" registry to 
> trace an AuthorityID to the local registry where it 
> originated means that that registry need not really be 
> "full"--that is, be a strict, comprehensive registry for the 
> entire VO.  There may be local registries that are locally 
> targeted and don't want to be harvested necessarily, but yet 
> wants to request unique AuthorityIDs.  This just helps keep 
> things distributed.  
> 
> The main requirement proposed here is having the global 
> registry associate AuthorityIDs with the registry that 
> originates them.
> 
> > Part B
> > ======
> > 
> > Surely unregistered ResourceIDs are nothing to do with the 
> registry. 
> > If the owner of an AuthorityID wants to create unregistered 
> > identifiers for their own purposes then it is up to them to 
> maintain 
> > them and ensure that they are not reused.
> 
> I think this is essentially what I'm saying in this proposed 
> amendment.  Previously, the WD said that IVOA ResourceIDs are 
> guaranteed to be registered somewhere.  This amendment simply 
> loosens this requirement by saying that it can be given to a 
> registry for resolution which may or may not be successful.
> 
> > Part C
> > ======
> > 
> > What is the point of the attribute 'persistent' when nothing can be 
> > done with it?
> 
> Currently, in the WD, identifiers are not necessarily 
> persistent. Resources may come and go, either deliberately or 
> through neglect. The persistent="false" would be a way for a 
> resource to indicate explicitly that the resource is 
> transitory (and, for example, should not be mirrored).  
> 
> Perhaps persistent="false" is not needed.  Should we just say 
> the all IVOA identifiers are persistent (thus, disallowing 
> recycling of identifiers)?  I'm cool with this, too.
> 
> > The 'status' attribute makes sense as I can see people 
> wanting to not 
> > search "inactive" resources. I'm not sure I agree about "deleted" 
> > status. I can see your reasoning but the registry is primarily a 
> > device for discovering resources; listing dead ones does not make 
> > sense unless we say that "deleted" resources are normally excluded 
> > from a search unless specifically included.
> 
> We plan to add relationships that include a reference to 
> other resources.  Those other resources may disappear.  If 
> their metadata descriptions are completely deleted from the 
> VO environment, then we will have dangling references.  
> 
> In practice, the global registry may choose to remove a 
> deleted resource description from its database; however, the 
> registry of origin could continue to hold the deleted record. 
>  With the recipe I outlined in part A, one still has the 
> ability to track it down.  My example of a moved resource 
> makes use of status="deleted"; it retains its status as a 
> separate copy from the original which has been deleted.
> 
> Note that this practice of marking resources as "deleted" is 
> not new to digital library practice.  This functionality is 
> also supported by OAI.  Such records can be hidden from the 
> view of users while still maintaining unambiguous 
> bookkeeping.  We'll still end up with some dangling 
> references, I'm sure, and we'll have to live with that; 
> nevertheless, this provides a mechanism to avoid it.  
> 
> > 'LogicalIdentifier' also sounds okay although I think the issue of 
> > mirrors is more complex than this can cope with.
> > 
> > I don't think we need add more elements to the schema for a 
> resource 
> > for mirrors etc. A repeating 'Relationship' element using 
> namespaced 
> > values would be more efficient and extendable?
> 
> I think this would do the trick.  
> 
> > Part D
> > ======
> > 
> > Changing the standard to ensure compliance with one other service 
> > could open the floodgates to other services. If we want to 
> specify how 
> > ADEC can interoperate with VO Registries then it should be 
> a separate 
> > document, a Note probably.
> 
> This part is mainly a recommendation to data providers in 
> choosing ADEC identifiers that interoperate well.  To assist 
> this interoperation, I'm suggesting one minor change to the 
> Identifier WD specification of the URI form: the use of # to 
> set off a component that is to be ignored by registries.  
> 
> Dataset resolution is going to be pretty important; 
> referencing datasets in journals is only one example likely 
> to be common.  The use of the # in the URI form provides a 
> means to refer to datasets that are known not to be 
> registered individually.  
> 
> I also suggest to the ADEC that they develop the DataResolver 
> service as an open IVOA standard service.  This would be a 
> great asset to all.  
> 
> > The IVOA is not a policing organisation.
> 
> This is certainly not the intention.  
> 
> > 1. attributes 'Status' and 'LogicalIdentifier'.
> > 2. repeating element 'Relationship' as I've previously 
> defined (point 
> > H in http://ivoa.net/forum/registry/0462.htm).
> 
> Would it help to go through what I've written and segregate 
> the components a bit?
>   *  changes for the Identifier WD
>   *  changes to the RM and extended schema
>   *  requirements for registry service interfaces
>   *  recipes for handling identifiers (that might appear in a Note).  
> 
> cheers,
> Ray
> 
> 
>