resource identifiers

[Ray Plante]

Hi RWGers,

With the concensus reached on the general architecture for registries
at the Interop meeting and the general progress on the RSM metadata,
it's a good time to settle how we will handle identifiers.  Several of
us at the meeting reviewed the discussion we had on the list back in
February to try to restate what we came up with in terms of our latest
architecture.  Below is a summary.  If I managed to get this right,
I can go ahead and write this up as a real IVOA proposal.  

First, some relevant items from the architecture:  
  * everything is a resource (organization, data collection, registry...)
  * We have 3 types of registries: 
      Full -- contains all resource descriptions known to the VO
      Data Centre/Publisher -- contains only those descriptions managed by
  	a data center (for harvesting only)
      Local -- contains a specialized subset of descriptions
    All three types may have the ability to accept registration of new
    resources. 

The primary purpose of a VO resource identifier is to serve as a
unique handle that can be given to a registry to get back a
description of that resource.  You can also use an identifier to refer
to some fine-grained item, such as an image or catalog record--which
is not explicitly registered itself; for example, identifiers can be
used to refer to records in a catalog.  

Here's an example of what the ID for a registered resource (say, an
SIAP service) will look like in an XML context: 

<ResourceID>
  <AuthorityID>ivo://www.ncsa.uiuc.edu/nvo/registry</AuthorityID>
  <ResourceKey>ADIL/SIA/targeted</ResourceKey>
</ResourceID>

As an SIA implementer, I might want to provide an identifier for each 
image matching an image query (even though the image is not itself 
registered anywhere); such an ID could look like this: 

<ResourceID>
  <AuthorityID>ivo://www.ncsa.uiuc.edu/nvo/registry</AuthorityID>
  <ResourceKey>ADIL</ResourceKey>
  <RecordKey>95.DR.01.01.fits</RecordKey>
</ResourceID>

Thus, an ID is composed of up to three components:

  * AuthorityID:  a globally unique URI that identifies a registry.  

      - all such IDs begin with "ivo://".  The "ivo" scheme signals
        that the URI refers to a VO registry.
      - It is recommended that the first field after the scheme be a
	DNS name in a domain controlled by the registry maintainer.
	This reduces the likelihood that two registries would have the
	same ID.  
      - Often the URI will be easily converted to a URL (or base URL)
	that can be used for retrieving descriptions from the
	registry (e.g. substituting "http" for "ivo"); however, this
	is not a requirement.  

  * ResourceKey:  a string identifying the resource that is unique
        within the publishing registry.  

      - This is ultimately the choice of the registry but may be a
        combination of a name provided by the registrant and component
        determined by the registry.

  * RecordKey:  a string identifying a component of a registered
	resource.  It is unique only with respect to the resource's
	ResourceKey and within the context that it is being cited.

      - This name is completely under the control owner of the
        resource. 
      - The key need not be permanent.  It may, for instance, refer to
        an image cutout that does not permanently exist.
        Alternatively, the item it refers to could be permanent (like
        a record in a catalog) but the RecordKey is just a temporary
        name used within a VOTable as part of a set of cone search
        results.  
      - There is no guarantee regarding how long a RecordKey is valid.

There will be many cases when one will want to refer to a ResourceID
as a single URI (such as in an OAI record).  In general, this will be
done using the following syntax:

   <AuthorityID>?resourceKey=<ResourceKey>&recordKey=<RecordKey>

That is, for the above two examples, 

   ivo://www.ncsa.uiuc.edu/nvo/registry?resourceKey=ADIL/SIA/targeted
   ivo://www.ncsa.uiuc.edu/nvo/registry?resourceKey=ADIL&recordKey=95.DR.01.01.fits

Did I get this right?

cheers,
Ray