resource identifiers

[Tony Linde]

Hi Roy,

Except that if you want to make use of the components of the isbn without
always having to decode it, you'd have:

<ISBN>
  <GroupID>...</GroupID>
  <PublisherID>...</PublisherID>
  <TitleID>...</TitleID>
  <CheckDigit>...</CheckDigit>
<ISBN>

Or whatever the system is.

Cheers,
Tony. 

> -----Original Message-----
> From: Roy Williams [mailto:roy at cacr.caltech.edu] 
> Sent: 29 May 2003 16:02
> To: Tom McGlynn; ael at star.le.ac.uk
> Cc: registry at ivoa.net
> Subject: Re: resource identifiers
> 
> 
> Everyone seems to be packing all this other stuff into 
> something that is just an ID. To me, an ID is just a simple, 
> short string.
> 
> The ID for the book is 0521-56098-5
> 
> The metadata for the book is all these <title> and <author> 
> and <number of
> Pages> fields.
> 
> The ID is not a place to shove all this metadata.
> Can't we just Keep It Simple?
> 
> My $0.02.
> Rot
> 
> 
> --------
> Caltech Center for Advanced Computing Research 
> roy at cacr.caltech.edu 626 395 3670
> ----- Original Message -----
> From: "Tom McGlynn" <Thomas.A.McGlynn at nasa.gov>
> To: <ael at star.le.ac.uk>
> Cc: <registry at ivoa.net>
> Sent: Thursday, May 29, 2003 7:39 AM
> 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
> > >>
> > >>...
> > >
> > >
> > >
> >
> >
>