resource identifiers

[Tony Linde]

> 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.

Thanks, Tom. As I think I said before, I'm not convinced we need a
*standard* way of identifying records in a resource since each resource will
treat its 'parts' differently but I'm open to persuasion (or bribery, of
course - that always works, especially if measured in litres of Scotch).

Cheers,
Tony. 

> -----Original Message-----
> From: Tom McGlynn [mailto:Thomas.A.McGlynn at nasa.gov] 
> Sent: 29 May 2003 15:40
> To: ael at star.le.ac.uk
> Cc: registry at ivoa.net
> Subject: Re: resource identifiers
> 
> 
> 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
> >>
> >>...
> > 
> > 
> > 
> 
>