I've generally stayed out of this thread since it is only peripheral to the
VO Registry issue, as long as the original identifier remains intact. But I
would like to ask a couple of questions.
Re:
<<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" >>
Can I confirm that the resource identifier of "HC.BIMA/BDA" will relate to a SkyService (or whatever we end up calling it) which provides access to some data.
If you want to then send that service the dataset pointer of "t421/c110.ori", will you need an extra standard method built into the SkyServices which can resolve that pointer? At the moment, we're likely to have some sort of doQuery method (in addition to getMetadata, getStatus etc). Do we need to add a getDataset(string DatasetID) method?
Next question is about how you expect to use these datasets. Since they are not registered in the VO as resources, a search of a registry will not find them. I'm not sure you could query a dataset either without yet another special method (eg queryDataset(string DatasetID, document AdqlQuery) in the data access services. It is getting a bit silly if we have to add new methods to all the services in order to handle an entity that the VO does not recognise. How do you see this being handled?
I guess the simple solution is that if you want to do anything with a dataset within the VO then it first needs to be registered as a resource. No?
Cheers,
Tony.
-----Original Message-----
From: owner-registry-at-eso.org [mailto:owner-registry-at-eso.org] On Behalf Of
Alberto Micol
Sent: 18 September 2003 08:31
To: aaccomazzi-at-cfa.harvard.edu
Cc: Arnold Rots; Ray Plante; Guenther Eichhorn; registry-at-ivoa.net;
adec-at-stsci.edu
Subject: Re: VO and ADEC identifiers
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.edu60 Garden Street, MS 31, Cambridge, MA 02138 USA
-- 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 GermanyReceived on 2003-09-18Z17:23:18