VO and ADEC identifiers

Alberto Accomazzi aaccomazzi at cfa.harvard.edu
Wed Sep 17 10:28:42 PDT 2003


Alberto Micol wrote:
 >
 > I forgot to mention the other problem I have with the syntax
 > proposed by Ray. The privateID could contain reserved characters
 > like the '/' in Ray's example:
 >
 >  >>         HC.BIMA/BDA#t421/c110.ori
 >  >>         \_____/ \_/ \___________/
 >  >>            |     |        |
 >  >>  IVOA   authID  ResKey  Dataset name
 >  >>         \-----/ \_________________/
 >  >>            |             |
 >  >>  ADEC   InstID    dataset ID
 >
 >
 > The reserved characters should be escaped, eg:
 >
 > HC.BIMA/BDA#t421%2Fc110.ori
 >                 ***
 >
 > isn't it ?

I think this shows exactly why the syntax that Ray suggested, while a 
little more complex than the original design, may be useful:  by 
adopting a format that clearly marks the private dataset identifier 
part, (i.e. whatever follows the "#" character), there will be no 
ambiguity about what is what.

So for instance, from this identifier:

	HC.BIMA/BDA#t421/c110.ori

I can quickly figure out that in order to resolve it I need to do a 
registry lookup of "HC.BIMA/BDA", find a dataset resolver associated 
with it, and then go to the resolver with the string "t421/c110.ori"
If you do away with the "#" character, then you have a situation in 
which it's not clear which part of the identifier should correspond to a 
key into a resolving service and which is the private identifier.  You 
also make it impossible for private identifiers to contain a "/", which 
would not be a tragedy, but nonetheless.

An analogy that may help: consider the following URL:

	http://adsabs.harvard.edu/cgi-bin/bib_query?2003adass..12..309A

An http server that receives a request for such a URL would know exactly 
what to do: find the CGI script corresponding to /cgi-bin/bib_query for 
the virtual server adsabs.harvard.edu and then pass to it the query 
string 2003adass..12..309A.  While it's true that a similar thing can be 
accomplished using a different URL syntax, I think it would 
unnecessarily add complexity.

In terms of instrument names:

> In one sentence I would simply answer that the instrument names
> do not add anything to the identifiers, hence they should not be used.
> Instrument names are part of the metadata associated with
> the data nothing to do with the identifier.

I neither agree nor disagree ;-)  I think the matter of defining the 
namespace under an authorityID should be left to the curator of the data 
collection(s).  We can, of course, have reccomendations as to what the 
"best practice" should be.


-- Alberto


> 
> Alberto
> 
> -- 
> Alberto.Micol at eso.org                         Tel: +49 89 32006365
> HST Science Archive       ST-ECF              Fax: +49 89 32006480
> ESA/RSSD/SN               c/o ESO             Karl Schwarzschild Str.2,
> http://archive.eso.org/   No ads, thanks.     Garching bei Muenchen,
> http://www.stecf.org/     HTML emails         D-85748 Germany
> 
>  


-- 

****************************************************************************
Alberto Accomazzi
NASA Astrophysics Data System                     http://adswww.harvard.edu
Harvard-Smithsonian Center for Astrophysics      http://cfa-www.harvard.edu
60 Garden Street, MS 31, Cambridge, MA 02138 USA
****************************************************************************



More information about the registry mailing list