Re: ADEC and VO data registration

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 Received on 2003-09-17Z19:49:04