VO and ADEC identifiers

[Tony Linde]

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