Re: VO and ADEC identifiers

From: Alberto Micol <Alberto.Micol-at-eso.org>
Date: Thu, 18 Sep 2003 09:31:26 +0200

Alberto Accomazzi wrote:

> 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.
>

I was referring to the last sentence of the below quoted paragraph

 Berners-Lee, Tim, Fielding, R., Masinter, L. 2003. Universal Resource Identifier (URI): Generic Syntax, IETF Internet-Draft,

       http://www.ietf.org/internet-drafts/draft-fielding-uri-rfc2396bis-03.txt

---
The slash ("/"), question-mark ("?"), and number-sign ("#")
   characters are reserved in all URIs for the purpose of delimiting
   components that are significant to the generic parser's hierarchical
   interpretation of an identifier.  The hierarchical prefix of a URI,
   wherein the slash ("/") character signifies a hierarchy delimiter,
   extends from the scheme (Section 3.1) through to the first
   question-mark ("?"), number-sign ("#"), or the end of the URI string.
   In other words, the slash ("/") character is not treated as a
   hierarchical separator within the query (Section 3.4) and fragment
   (Section 3.5) components of a URI, but is still considered reserved
   within those components for purposes outside the scope of this
   specification.
---

To fully comply to rfc2386, even in the fragment component of the URI the '/'
charachter has to be considered reserved. Hence the need for escaping it.


>


> 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.

>
>

I agree. But I always prefer the simplest recommendations ...




> ****************************************************************************

> 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

> ****************************************************************************


Ciao 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

Received on 2003-09-18Z09:32:42