Re II: Resolving Identifiers

[Tony Linde]

Hi Ray,

I'm answering your email in the registry list to try and move the discussion
there.

> > Certainly.  But one would like to be able to produce and verify 
> > products, e.g., datasets, before publishing them to a registry.

What happens to resources before they are registered is of no relevance to
the VO.

> Okay.  Well, we do have a driver for this in the ADEC 
> identifiers.  They 
> want an identifier that refers to a dataset.  However, we are not 
> currently planning to register individual datasets in IVOA 
> registries.  
> Thus, in the current model, they wouldn't have an IVOA identifier.  

I wish someone would provide a glossary! What do you mean by a dataset and
why is it not being registered? What is being registered?

If you are only going to register services which actually access the data
(which I originally suggested) then why are we bothering to talk about
datasets?

> I feel strongly about the resolvability of identifiers.  That 
> is, an identifier is used as a stand-in for a full 
> description of a resource.  
> So as to not to place any requirements on the context in 
> which a global identifer is used, one should be able to 
> resolve the identifier to *some* relevent information about it.  

You can - just look up the metadata in a registry. You don't need any of the
1, 2 or 3 approaches and they (1 and 2 anyway) would not work since the
ResourceId and its components are meaningless.

Cheers,
Tony. 

> -----Original Message-----
> From: owner-metadata at us-vo.org 
> [mailto:owner-metadata at us-vo.org] On Behalf Of Ray Plante
> Sent: 12 September 2003 16:57
> To: Doug Tody
> Cc: metadata at us-vo.org
> Subject: Re: Re II: Resolving Identifiers
> 
> 
> Hey Doug,
> 
> Okay, I think we're getting somewhere.  Basically, you are 
> saying that 
> once an organization owns a namespace, it is free to 
> associate identifiers 
> with resources (datasets, collections, services), even if 
> those resources 
> are never released to the public.  It takes responsibility 
> for ensuring 
> uniqueness within that namespace.  This sounds fine to me, 
> predicated on 
> the assumption that the namespace has been somehow 
> "registered" so that 
> others know not to use it.  Does this sound cool?
> 
> > Certainly.  But one would like to be able to produce and verify 
> > products, e.g., datasets, before publishing them to a registry.
> 
> I would underscore this point.  I keep running into this issue when I 
> think about the exact process of registering.  
> 
> > > The only way I can see that we can support an IVOA identifier of a
> > > resource that is not registered is if we can extract some 
> component of the 
> > > ID (e.g. the authority ID or something more) and resolve 
> it to a resource 
> > > that is somehow related.  Is this what you have in mind?  
> > 
> > Yes.  I know approaches like this have already been 
> discussed, but I 
> > am not convinced that such a scheme cannot provide a simple 
> mechanism 
> > for constructing unique global identifiers, independently of 
> > subsequent registration and independently of any particular 
> registry.
> 
> Okay.  Well, we do have a driver for this in the ADEC 
> identifiers.  They 
> want an identifier that refers to a dataset.  However, we are not 
> currently planning to register individual datasets in IVOA 
> registries.  
> Thus, in the current model, they wouldn't have an IVOA identifier.  
> 
> I feel strongly about the resolvability of identifiers.  That 
> is, an identifier is used as a stand-in for a full 
> description of a resource.  
> So as to not to place any requirements on the context in 
> which a global identifer is used, one should be able to 
> resolve the identifier to *some* relevent information about it.  
> 
> Two ideas to address this have been floated in the past. 
> 
>   1.  A third optional component is added to the identifier 
> which points 
>       to a unregistered component of a registered resource.  
> In the URI 
>       form, this component is set off by a #.
> 
>   2.  The slashes in the ResourceKey mark places where the 
> identifier can 
>       be chopped and the trailing bit lopped off.  If an 
> identifier does 
>       not resolved as is, one (i.e. the registry) can lop off 
> trailing 
>       parts until the identifier is resolved.  At a minimum, 
> the namespace 
>       should resolve to a description of the organization 
> that owns it.  
>       This requires that a resource with resource key "A/B/C" 
> is logically 
>       related to "A/B".
> 
> A third, simpler alternative:
> 
>   3.  Global identifiers are not guaranteed to resolve at any 
> level except 
>       the namespace level.  
> 
> Do any of these appeal to you?  (Alternate suggestion?)
> 
> I'm partial to 2.  The difficulty this idea ran into was in the last 
> sentence:  this placed a restriction on the structure of the 
> resource key.  
> I think 3. is the minimum of what you described, but it does 
> not address 
> the ADEC problem, per se.  
> 
> cheers,
> Ray
> 
> 
>