ADEC and VO data registration

[Ray Plante]

On Thu, 18 Sep 2003, Arnold Rots wrote:
> In the interest of simplicity for authors, can anyone explain what the
> advantage is of this three-element Identifier definition:
> 
>         <AuthorityId>/<ResourceKey>#<DatasetId>
> 
> Over the two-element identifier:
> 
>         <AuthorityId>/<DatasetId>
> 
> In both cases the same number of resources have to be registered,
> though in the first case they are all different authority Ids, while
> in the first case some of them are resource keys.

> In either case Sa.HST.STIS and Sa.HST/STIS need to be resolved to a
> physical location.  What's the difference?

(First, just to be clear: Sa.HST.STIS as an authority ID is compatible 
with the IVOA ID WD.)  

A major goal of the ID WD is to maximize the freedom of providers to 
choose their IDs.  This is done by giving them a sandbox--their 
namespace--to do what they want.  This allows them to reuse the 
identifiers or names they already use internally.  

I think the difference is that we (IVOA) shouldn't *force* providers to 
put different collections into different authority IDs.  Nor should we 
say that the authority ID should include certain information.  This is a 
fundemental principle of the WD: IDs carry no parsable semantic 
information about the resource.

I get the sense that you feel it is important that the first field of an
ID that ADEC uses to resolve datasets should contain parsable semantic
information.  Is this true?  If so, why?  If it's just a matter of
avoiding collisions, then it shouldn't matter where the / goes.

The point of the # is that what comes after it refers to something 
that is *not* registered in a VO registry.  The ADEC Data Resolver service 
resolves to datasets--this is too fine-grained for VO registries (as we 
are planning to use them at the moment).  But what I'm trying to do is 
provide a way that we can use a VO registry to take an ADEC identifier, 
find the corresponding data collection, follow the reference to a 
local data resolver service, and resolve it to a dataset.  

If the ADEC scheme recommends, or even insists, that participating centers
have the first field conform strictly to a telescope-instrument syntax
that can be compatible with the IVOA ID standard.  However, I might
suggest that if the ADEC system is very strict about what goes on each
side of the /, then I think we are going to wind up with are for all
practical purposes, two independent and non-interoperable identifier
systems.

cheers,
Ray