resource identifiers

[Tom McGlynn]

Hi all,

I've been trying to follow this conversation.  My apologies
if I'm rehashing old ground...

Personally I don't have any problem with the idea that
a ResourceID includes information that's not used by a registry.  Registries
are just one of the many services available for the VO.  It seems perfectly
reasonable for our generic indexing mechanism to be designed for a broader
scope than registries.  However there is an essential difference between
the service identifier and the record identifier (as discussed): the
record identifier is not persistent.  Given the transience
of the proposed record identifiers, it's not clear how they can be used
in any context other than the document in which they are created.

Perhaps what we want is a ResourceID which provides persistent linkages
across the VO and a RecordID which provides transient linkages within
a document.  The example that I've been considering where a record
ID would be useful in the SIA is "How do I associate a GIF image and
a FITS file that derive from the same image?"  If we allow RecordID tags
within documents these could be used to provide an index (or possible
multiple indices) within the document.


Here's an example of the kind of functionality I'd hope
that a general Record ID might provide.

  <SiaDocument>
    <SiaHeader>
      <ResourceID>
        <AuthorityID>heasarc.gsfc.nasa.gov</AuthorityID>
        <ResourceKey>ROSAT/HRI/observations</ResourceKey>
      </ResourceID>
      ...
    </SiaHeader>
    <SiaRecord>
      <RecordID context=OriginatingImage>RH900317N00</RecordID>
      <RecordID context=RecNum> 1 </RecordID>
      <FORMAT>GIF</FORMAT>
      ...  All the other SIA fields for an image ...
    </SiaRecord>
    <SiaRecord>
      <RecordID context=OriginatingImage>RH900317N00</RecordID>
      <RecordID context=RecNum> 2 </RecordID>
      <FORMAT>FITS</FORMAT>
      ... Other SIA fields ...
    <SiaRecord>
  </SiaDocument>

Since the first two entries have the same RecordID in the OriginatingImage
context the user knows they are linked.
If we were to address this document with a URL including the fragement
   '#OriginatingImage=RH900317N000'
then this could be interpreted as asking for these records.

Note the use of context to enable multiple indices of records
to be included in a single document.

I'm not advocating adopting this particular structure, but I think
this illustrates how  a generic concept of recordID's could
be used in very powerful ways.  So while I agree with Tony that it's
not clear that a record ID (at least a non-persistent one)
belongs in the the Resource identifier, I do believe that some general
concept of records and their identifiers is also essential for
successful VO services.   Obviously if we have both resource and
record ids, then one can compose them to get a record within
a resource, but it doesn't seem necessary to make one part of the other.


	Tom

Tony Linde wrote:
> Hi again, Ray,
> 
> I think that at heart I am really uncomfortable with having the ResourceID
> including a component that never gets used in the registry.
> 
> The ResourceID should be used solely to describe a resource registered
> within the VO and this requires only the AuthorityID and the ResourceKey. If
> we want to identify *parts* of a resource which are used only by one or more
> services, it ought to be up to that service to define those schema. So SIA
> could have:
> 
> <SiaImageID>
>   <ResourceID>
>     <AuthorityID>www.ncsa.uiuc.edu</AuthorityID>
>     <ResourceKey>ADIL/SIA/targeted</ResourceKey>
>   </ResourceID>
>   <ImageKey>95.DR.01.01.fits</ImageKey>
> </SiaImageID>
> 
> Other services which require more detailed structure would include that
> detail in their own schema using multiple tags. The ResourceID should be
> used solely to uniquely identify the resource.
> 
> Cheers,
> Tony. 
> 
> 
>>-----Original Message-----
>>From: Ray Plante [mailto:rplante at poplar.ncsa.uiuc.edu] 
>>Sent: 28 May 2003 06:10
>>To: Tony Linde
>>Cc: registry at ivoa.net
>>Subject: RE: resource identifiers
>>
>>...
> 
> 
>