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.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 ****************************************************************************Received on 2003-09-17Z20:18:15