amendments to Identifier framework

[Tony Linde]

Hi Ray,

Thanks for the summary but I'm afraid I think your amendments to the
identifier proposal are overcomplicating it unnecessarily.

Part A
======

AuthorityIDs are not necessarily owned by organisations. This should be an
optional part of the authority metadata.

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?

What is a 'publishing 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?

What are 'first-class resources'?

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.


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.


Part C
======

What is the point of the attribute 'persistent' when nothing can be done
with it?

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.

'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?


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.

I don't think there was anything in this Part which required changes to the
IVOA identifier spec.


My Summary
==========

The IVOA is not a policing organisation. The more 'rules' we try to
introduce, the more likely that our standards will be ignored. Let's stick
with developing the minimum standards that are needed to ensure our systems
can interoperate and leave the policing to external efforts.

I think the only parts of your proposed amendments which we need to add are:

1. attributes 'Status' and 'LogicalIdentifier'.
2. repeating element 'Relationship' as I've previously defined (point H in
http://ivoa.net/forum/registry/0462.htm).


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 10:28
> To: registry at ivoa.net
> Subject: amendments to Identifier framework
> 
> 
> Hi all,
> 
> Okay, since Clive asked for it....This is not actually a 
> summary/recap of the identifier issues; however, I hope this 
> will provide a bit more clarity to the discussion.  Thanks to 
> everyone who was able to contribute to Friday's discussion 
> about identifiers and related issues.  I know it had a lot of 
> threads and was often difficult to keep up with; 
> nevertheless, it was very valuable (in my mind, anyway) in 
> helping to understand the current issues of identifier 
> control, relationships to registries, persistance, and 
> location-independence.  I mulled over the disussion over the 
> weekend, and I'd like to propose 4, somewhat independent 
> amendments to the Identifier framework.
> 
> I'm posting the four different amemndment ideas on separate 
> twiki pages to save you from having to read them all.  You 
> can focus on the ones that concern you the most.  Here's a summary:
> 
>   Part A.  Establishing AuthorityID Ownership and Resolving
> 	   ResourceIDs 
>            http://www.ivoa.net/twiki/bin/view/IVOA/IdAmendPtA
> 	   
>     A clarification of what's currently in the Identifier (Working
>     Draft), the main differences beeing:
>     o  A request for an AuthorityID is handled through a publishing
>        registry to global registry.  The request is accompanied by the
>        identifier of the publishing registry to be saved in the global
>        registry as the "registry of origin" for that authority ID.
> 
>     o  Registries are registered as first-class resources.  Their
>        descriptions should include the AuthorityIDs that they have
>        resources for.
> 
>   Part B:  Unregistered Resource IDs
>            http://www.ivoa.net/twiki/bin/view/IVOA/IdAmendPtB
> 
>   This amendment allows one to associated identifiers with resources
>   that are not strictly registered.
> 
>   Part C:  Support for Persistance and Location-independence: 
> 	   Persistant Logical Identifiers (PLI).  
>            http://www.ivoa.net/twiki/bin/view/IVOA/IdAmendPtC
> 
>   This proposal for handling location-independent identifiers is much
>   the same as the strawman I presented to this list earlier
>   (http://www.ivoa.net/forum/registry/0454.htm).  It involves use of
>   metadata to describe mirroring relationships, as well as proposing
>   the use of Persistant Logical Identifiers for refering to resources
>   in a location-independent way.
> 
>    Part D: Persistant Dataset Identifiers (PDI) and ADEC
> 	   Compatibility.  
>            http://www.ivoa.net/twiki/bin/view/IVOA/IdAmendPtD
> 
>    This proposes dataset identifiers based on the PLIs discussed in
>    Part C; these can be used as ADEC identifiers for publishing in the
>    journals.  From a PDI, one can use VO registries to discover 
>    data resolvers that resolve it into one or more locations to
>    retrieve it from.  
> 
> Although I'm calling these amendments, not all of it would go 
> into the 
> Identifier WD per say.  Some of this is input to registry services.  
> 
> cheers,
> Ray
> 
>