IVOA Identifiers Working Draft

[Ray Plante]

On Fri, 12 Sep 2003, Tony Linde wrote:
> > I think it is intended (Doug?) that non-registered 
> > ResourceIDs would be 
> > used in VO systems.  That is what led to the discussion of resolution 
> > schemes that allow you to learn something about the unregistered 
> > ResourceID (e.g. those 3 ideas for resolving some component of it).  
> 
> In which case it would make more sense to use the ResourceID to identify the
> resource and some other element to identify the lower level part, say:
> 
> <DataItem>
>   <ResourceID>
>     <AuthorityID>...</AuthorityID>
>     <ResourceKey>...</ResourceKey>
>   </ResourceID>
>   <ItemID>...</ItemID>
> </DataItem>
> 
> But we should maintain the ResourceID as a unique identifer for registered
> resources. Especially since the subsidiary element (ItemID) would not apply
> to services.

Okay, this is similar to choice 1, in which the unregistered component is 
separately marked.  (I think we will need a URI counterpart).

The disadvantage to this approach, as Doug has pointed out, is that the 
identifier for the dataset will essentially change if and when it is 
registered.

Furthermore, I believe Doug was thinking of something more general, not
just the case of a dataset from a registered collection.  The idea is that
the ID for any resource is defined prior to registration.  For example,
one might have a data collection or a service that exists and is
accessible via VO applications but is not registered initially.  Maybe a
year later, when it is more public, it is registered.  That is why he was
partial to choice 2.  

(By the way, Doug is not the lone voice on this issue.  Several people in 
the NVO project have expressed some variation on the idea of identifiers 
existing somewhat independently of registries.)

cheers,
Ray