resource identifiers

[Tony Linde]

Hi Ray,

I think what I'm trying to get at is that only the resource will ever
interpret the <query> component, so it shouldn't matter that no-one else can
do anything with the contents. Having a keyword/value structure just makes
the interpretation easier. It also makes comparison easier - if the resource
is the same, you just need to compare the values associated with each
keyword.


I think we should get back to basics. A resource is a resource and is
identified simply by the authorityID and the resourceID where the resourceID
is unique within the authority. This will cater for most resources and if we
mandate that the authorityID can only contain {alphanum, '-' and '.'}, and
the resourceKey can only contain {alphanum, '-' and '/'} characters.

IF some resource allows subsidiary item identification, it can include this
in the resourceKey by using the ':' character followed by {alphanum, '-',
'.' and '/'} characters (and then another ':' followed etc...). In this way,
the resourceKey is always unique within the authority. (It could use some
other method  - '/' delimiters, say - as long as they were conformant.)

The resource can parse the item info out of the resourceKey when the
resource is invoked by whoever or whatever has retrieved the resourceID
(using the URL in the rest of the resource metadata).

So, for 90%+ of resources:

  <ResourceID>
    <AuthorityID>www.ncsa.uiuc.edu</AuthorityID>
    <ResourceKey>ADIL/SIA/targeted</ResourceKey>
  </ResourceID>

And for the rest:

  <ResourceID>
    <AuthorityID>www.ncsa.uiuc.edu</AuthorityID>
    <ResourceKey>ADIL/SIA/targeted:95.DR.01.01.fits:wibble</ResourceKey>
  </ResourceID>

This also solves Roy's OAI problem. The worst string you'll get is:
  ivo://www.ncsa.uiuc.edu/ADIL/SIA/targeted:95.DR.01.01.fits:wibble

Cheers,
Tony. 

> -----Original Message-----
> From: Ray Plante [mailto:rplante at poplar.ncsa.uiuc.edu] 
> Sent: 23 May 2003 22:03
> To: Tony Linde
> Cc: registry at ivoa.net
> Subject: RE: resource identifiers
> 
> 
> Hey Tony,
> 
> On Fri, 23 May 2003, Tony Linde wrote:
> > But order need not be significant if you allow different keys:
> > 
> >   <ResourceID>
> >     <AuthorityID>www.ncsa.uiuc.edu</AuthorityID>
> >     <ResourceKey>ADIL/SIA/targeted</ResourceKey>
> >     <Record>
> >       <Key1>95.DR.01.01.fits</Key1>
> >       <KeyX>wibble</KeyX>
> >     </Record>
> >   </ResourceID>
> > 
> > 
> ivo://www.ncsa.uiuc.edu/ADIL/SIA/targeted?Key1=95.DR.01.01.fits&KeyX=w
> > ibble
> 
> Sorry, I wasn't making myself clear.  The most common way 
> people compare 
> URIs is by simple string comparison.  If order does not matter, this 
> method will not work; instead, applications are required to parse the 
> components of a URI.  This makes it harder to use Identifiers as a 
> look-up key.  Obviously, this is not a problem for databases 
> that have 
> these bits all pre-parsed, but that is not the only instance 
> such look-ups 
> are done.  (In fact, record keys, since they are not 
> persistant, are not 
> likely to be used outside a formal database--e.g. a VOTable.)
> 
> As for the <Key1> etc. bit, are you suggesting that the resource that 
> creates the record defines element tags that goes inside 
> <Record>?  This 
> would make things very difficult from an interoperability 
> standpoint.  It 
> would be better to say:
> 
>      <Record>
>        <Key name="Key1">95.DR.01.01.fits</Key>
>        <Key name="KeyX">wibble</KeyX>
>      </Record>
> 
> This seems more than necessary to me as it requires that 
> everyone use the 
> key=value format for the arguments.  I think it would be better if a 
> resource wants to use this format it be included in the key value 
> explicitly:
> 
>      <Record>
>        <Key>95.DR.01.01.fits</Key> 
>        <Key>KeyX=wibble</KeyX>
>      </Record>
> 
> The only one that will want to parse the second key further is the 
> resource itself, because it is the only one that knows what 
> "KeyX" means.  
> 
> cheers,
> Ray
> 
>