towards an ID spec

[Tony Linde]

Hi Ray,

Back to the interesting stuff...

> compatability with other contexts.  As a single string, there 
> are places where it could be inserted where an XML fragment 
> (i.e. a <serviceID> node) could not, e.g. a VOTable cell, as 

If we state that the authorityID must be a URI and neither it nor
serviceKey can contain the characters '?' nor '&', then, to get a single
string, we could join the two parts with the string '?serviceKey=',
giving:
 
http://www.star.le.ac.uk/ledas/registry?serviceKey=xmm/catalogABC/datase
tXYZ

Which even Outlook thinks is a URL but we would have to educate people
is just a simple way of representing IDs.

And for the registry entry for another Registry, where the serviceKey is
null, it simply has the string,
'http://www.star.le.ac.uk/ledas/registry' as its ID.

>   *  In general, applications do not discern anything about a service
>      based directly on the character content of its ID.

Agreed.

>   *  The only thing that one can definitively learn from an ID is
>      where one can go to retrieve the metadata for the service.

But only in the sense that you look up the authorityID (with null
serviceKey) in the Registry to find the location for the registry
containing the metadata (unless the registry you're sitting in has
chosen to replicate *all* metadata that it has harvested from other
registries.

>   *  The network name refers to the authority that issued the ID.
>      Anyone can be their own authority.

But only if they create and maintain a VO standards compliant Registry
service, thus allowing other registries access to the metadata
associated with the unique serviceKeys that they've issued.

Only if a registry 'owns' an authorityID can it guarantee that the
serviceKey values that it assigns to registered services are unique.

>  <serviceID>
>    <authorityID>http://www.star.le.ac.uk/ledas/registry</authorityID>
>    <serviceKey>xmm/catalogABC/datasetXYZ</serviceKey>
>    <recordKey>1244+29.0_v100s.fits<recordKey>
>  </serviceID>
> 
> where the serviceKey points to a metadata description but 
> recordKey does not.  Nothing else is implied except that 

That sounds good. Continuing the 'single string' discussion above, we
could plug the recordKey value in with a '&recordKey=' separator,
giving:

 
http://www.star.le.ac.uk/ledas/registry?serviceKey=xmm/catalogABC/datase
tXYZ&recordKey=1244+29.0_v100s.fits

> via the metadata.  The use case I'm exploring here is one 
> brought to us by journals, who would like a location 
> independent identifier for data cited in an article.  They 

We could certainly use the same structure. Assuming some VO-wide
implementation of the AstroGrid MySpace idea, a community which
maintains a MySpace service would provide a 'directory' of items (files,
tables, images etc) which would work in a similar manner to a registry,
so those items could be identified in the same way, eg:

<itemID>
  <authorityID>http://www.star.le.ac.uk/ledas/myspace</authorityID>
  <itemKey>TonyLinde/papers/2003/0222-Eureka.xml</itemKey>
</itemID>

And, as before, all the authorityIDs and itemKeys are
location-independent namespace-like pointers to appropriate metadata
structures (which, internally, could skip one step of indirection by
using something like the above as real directory structures).

Cheers,
Tony. 

> -----Original Message-----
> From: Ray Plante [mailto:rplante at poplar.ncsa.uiuc.edu] 
> Sent: 20 February 2003 12:27
> To: Tony Linde
> Cc: registry at ivoa.net
> Subject: RE: towards an ID spec
> 
> 
> ...