VO and ADEC identifiers

[Alberto Micol]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/registry/attachments/20030918/dcfe720b/attachment-0001.html>