VO and ADEC identifiers

[Arnold Rots]

Ray,

I have been mulling this over and I am not sure what the merit is of
introducing a third element into the ADEC identifier.
Can't we just have an authority Id and a dataset identifier, where the
former (everything before the first /) is resolved to a physical URL
with the latter provided as, say a parameter, to that URL?
I'm not partiucualrly fond of the # and, frankly, I don't see the
advantage.

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.

  - Arnold

Ray Plante wrote:
> Hi ADECers,
> 
> After looking over Alberto's page, I feel I have a much clearer idea of 
> how your scheme is meant to work, and I think providing compatibility with 
> VO Registries can be a fairly simple matter.  I shared my ideas about it 
> on the registry list, but I also wanted to try some direct discussion with 
> you guys.
> 
> I like your architecture; I don't see any inherent incompatibilities with 
> what we're doing in the VO (not surprising).  I think the only tweaking on 
> your end that would be necessary would be the syntactic use of dots and 
> slashes that we talked about in Victoria; that is, if ADEC identifiers 
> were valid IVOA identifiers (in URI form), then that should do it.  That 
> is, we both have a 2-component identifier where the first component is a 
> namespace name.  Namespaces based on telescope names are fine.  Also, my 
> suggestion (below) recommends use of a # in the dataset ID portion.  Is 
> that ok?
> 
> The other tweak on your end is to allow (encourage) the data resolvers
> services at the data centers that ADS queries to be registered in VO
> registries.  
> 
> The main tweaking I'm recommending is on the IVOA end, and it depends
> on the defintion of a a logical, location-independent name called a
> "LogicalIdentifier".  This would be a separate ID from the
> organization-dependent ResourceID.  Like the ResourceID, the LogicalID
> has the two components.  Often the ResourceID and LogicalID will be
> the same.  The definite exception would be a mirror of a resource:
> here, the LogicalID would be the same as the LogicalID of the thing it
> mirrors, but its ResourceID would be unique.
> 
> So far, this bit about the LogicalIdentifier is largely independent of
> the ADEC work; we could (should) do this anyway.  The connection to
> the ADEC work comes in the form of a recommendation to data providers
> for choosing ADEC identifiers.  Assuming that the dataset is not itself
> registered in a VO registry, the ADEC identifier would be the
> LogicalIdentifier of the dataset's registered DataCollection, a # sign
> followed by a dataset name.  E.g.
> 
>          HC.BIMA/BDA#t421/c110.ori
>          \_____/ \_/ \___________/
>             |     |        |
>   IVOA   authID  ResKey  Dataset name
>          \-----/ \_________________/
>             |             |
>   ADEC   InstID    dataset ID   
> 
> or 
>          bima.org/BDA#t421/c110.ori
> 
> This would allow users to go to a VO registry and resolve the ADEC
> identifier to a data collection (by chopping off the bit after the
> #).  That data collection description could include a reference to the
> data resolver service that can resolve it to a URL that can be used
> for access.  Thus, VO registries can be used to resolve ADEC
> identifiers.  
> 
> To make this all clean and open and accessible to everyone, I would
> also recommend the following:
> 
>    o  that the interface that ADS uses to query its selection of data
>       centers be the same as the interface UCP uses to query ADS.  
> 
>    o  that the DataResolver service be developed as an IVOA standard.
> 
> This way anyone could implement the DataResolver service.  ADS could
> choose to add a particular implementation to its list of data centers
> or not.  Users could use ADS's data resolver, which may or may not be
> able to resolve the ID; they could also a VO registry if it comes from
> a data center that does not happen to be in ADS's list.  
> 
> how does this sound?
> 
> cheers,
> Ray
> 
--------------------------------------------------------------------------
Arnold H. Rots                                Chandra X-ray Science Center
Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
60 Garden Street, MS 67                              fax:  +1 617 495 7356
Cambridge, MA 02138                             arots at head-cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------