resource identifiers

[Ray Plante]

Hi (again) Tony,

I think this is probably a good time to explicitly clarify the 
requirements that described thus far only informally.  I believe our  
working set to be the following:

 1. A VO identifier can be used to obtain a unique description of a 
    resource from a registry.  A VO ID is, thus, necessarily globally 
    unique.  
 2. The spec defines a uniform framework for encoding all VO identifiers
 3. Identifier encoding should be compatible with the URI specification 
    and integrate well into XML documents.  The latter includes making it 
    easy to extract an ID from an XML document.
 4. The identifier framework should provide a way to refer to components 
    of a resource (e.g. a catalog record) that is not necessarily 
    described in a registry (though its resource would be).  The component 
    identifier need not be permanent and may only be applicable within a 
    limited context.

All four of these are informally stated in the message that started this
thread.  Req. 4 is the point we are discussing now.  I also note that we
have approached 3 by specifying two formats for an ID that are
inter-convertable: an XML-tagged version and a URI version.

On Tue, 27 May 2003, Tony Linde wrote:
> If you mean that resources with a RecordKey are not stored in the registry
> then that's okay. In which case, RecordKey should not be part of the
> ResourceID. Maybe you need to wrap Resource ID in another structure, eg:
> 
> <RaysBitsID>
>   <ResourceID>
>     <AuthorityID>www.ncsa.uiuc.edu</AuthorityID>
>     <ResourceKey>ADIL/SIA/targeted</ResourceKey>
>   </ResourceID>
>   <RecordKey>95.DR.01.01.fits:wibble</RecordKey>
> </RaysBitsID>

I gather that <RayBitsID> is part of some specific schema intended for a
limited use and not part of a VO standard schema.  The fact that
<RecordKey> is a part of <RaysBitsID> and not part of <ResourceID>
suggests that we no longer have a uniform way to refer to records or other
components of a resource.  Each specialized schema is free to handle this 
reference in its own way.  

If that is the intent, then we should consider dropping Req. 4.  

Before we do, though, I would suggest that the RecordKey is not so scary
an item as it seems.  I think it fits very nicely into a simple framework
based on two interchangable encodings:

      XML ResourceID Node  <==>  URI

That is, the contents of the <ResourceID> can be convert to a URI and back 
again independent of any other metadata.  Adding the RecordKey does not 
break this model; rather, it provides further consistancy with URIs with 
the use of # to mark the resource component.  Furthermore, including it 
within <ResourceID> incurs no further cost to consumers of the XML form.  
For example, if a registry wants resolve it to a description, it grabs the 
<ResourceKey> and (when needed) the <AuthorityID>, just as it would 
otherwise.  

Since I was the originator of Req. 4, I should say that I have some 
specific use cases in mind.  SIA V1.0 has a preliminary (and as yet 
unimplemented) specification for a staging request which includes a 
reference to one of the images refered to in a prior image query.  An ID 
containing a <RecordKey> would allow one to refer to the particular image 
to stage.  Another is one generated by Roy where in his response to an 
SIA image query (which is in VOTable format) he might include an extra 
table that describes where to access mirrors of the images; IDs for the 
images would link to two tables.  While he would not necessarily need a 
globally unique ID to accomplish this, we can consider generalizing this 
scheme to any case where identical data is located at multiple places and 
in which the "mirror table" is passed in a separate message; then a 
globally unique ID is useful.  

So, do we drop Req. 4?  If so, what are the specific objections (e.g. cost
of processing, inconsistant model)?  Or, do we address it in a different
way?  

cheers,
Ray