ADEC and VO data registration

[Ray Plante]

Hi Alberto, Arnold,

Thanks much for your comments on regarding my strawman to establish 
interoperability between VO Registries and ADEC data resolvers.  

To boil it down: if we all basically like this idea, here's a roadmap
of what would result:

   1. The ADEC proposal would adjust the identifier syntax to match 
      the IVOA ID syntax
        o  the ADEC instrumentID would be .-delimited 
        o  the instrumentID and datasetID would be delimited by a /
        o  a # would be allowed (but not required) in the datasetID.

   2. IVOA would work out a standard for persistent, location-idependent
      IDs based on the IVOA Identifier standard.  

   3. NVO would issue a recommendation to data providers for choosing 
        identifiers that will work for both the ADS Data Resolver 
        and VO Registries.

   4. Data Centers can (but don't have to) register their data collections
        and the resolver services in a VO Registry so that VO users could 
        use it.  

And this doesn't need to happen all at once.  

A few more clarifications...

Just to be clear, I'm not suggesting that ADS explicitly use any VO
services (e.g. the registry) to implement its data resolver.  ADS can
continue with its architecture as currently planned.  In particular,
having it maintain its own list of data centers allows it to address
the "nutter" issue.  

> The identifier to be used in journals to refer to a dataset will be in 
> the form:
> 
> 	authorityID/datacollection#PrivateID
> 
> where both "authorityID" and "authorityID/datacollection" have entries 
> in the registry.  PrivateID can be anything the authorityID has chosen 
> it to be, and represents a unique identifier that has been assigned to a 
> dataset within the particular data collection.

You can still recommend that data providers choose from your list of 
instrument IDs to use as an authorityID.  Also, the 
datacollection-privateID split can be optional. 

> Also, while we're at it, I would suggest specifying an explicit scheme 
> prefix to indicate what domain these identifiers belong to.  I'm 
> thinking of simply prepending vo: or vo:// to it, like Ray has specified 
> in the VO identifier WD:
> 
> 	vo://NASA.HST/STIS#O4LT010E0

I agree that schemes are a good idea.  (BTW, the IVOA ID WD proposes "ivo"  
as the scheme.)  You can choose to adopt the same schema as the IVOA;  
however, that would mean that the authorityID and the data collection
would have to be registered in an IVOA registry.  If you chose a different
scheme, you could drop that requirement--registration is optional.  It
would still be trivial to swap the scheme before sending to a VORegistry
(if that would even be necessary).

> I still have some questions about how the deployment of resolvers should 
> take place both in the short and in the long run, but I don't see a 
> reason why this should stop us from adopting this syntax right away.

Agreed--there are still details to work out, but I think we have a 
workable roadmap.

On Tue, 16 Sep 2003, Arnold Rots wrote:
> I'm not partiucualrly fond of the # and, frankly, I don't see the
> advantage.

To ADS, it means nothing.  It's just another character in the datasetID.  
It's use is for when using it with VO Registries.  It marks where a legal 
IVOA Identifier of a registered resource ends.  

> Also,  instead of going through the system of type and status
> attributes, woudl it not be preferable to just have an expiration
> date?  That would automatically indicate whether the Id is persistent
> (please note spelling), expired, or whatever.

We could do that, assuming that one knows that expiration date.  

Response to the persistent tag has been luke-warm.  I'm thinking the 
simpler solution is just to say, identifiers should be persistent--i.e. 
avoid recycling them.  

cheers,
Ray