IVO ids and Data Sets Identifiers

[Tony Linde]

This is in reply to both Francois and Arnold.

An AuthorityID is not a service and so will not have an invocation URL
associated with it. The AuthorityID is simply a way of grouping resources
and allowing a registry to know that when it assigns a ResourceKey, it is
globally unique (since no other registry can assign a ResourceKey to that
AuthorityID).

So a service *must* have a ResourceKey as part of its unique identifier, as
well as the AuthorityID.

On the issue of the dataset identifier, there is no problem with:
  ivo://Authority.ID/(resource_key)#(dataset_identification)
since this is not being sent to an http server. It will be interpreted by
some piece of software (which can interpret the ivo:// protocol) which will
understand that everything before the '#' sign is a resource identifier and
everything after it a dataset identifier. The software will use the resource
identifier to look up the service metadata, get the service invocation
method (web service or cgi or whatever) and then call that service using the
dataset identifier (as a parameter to the web service or as the value part
of a cgi '?name=value' pair).

The ivo:// protocol is for the use of *VO software* only and not http
servers. They may use the same URI convention but they are completely
separate and different naming conventions.

Cheers,
Tony. 

> -----Original Message-----
> From: owner-registry at eso.org [mailto:owner-registry at eso.org] 
> On Behalf Of Francois Ochsenbein
> Sent: 23 September 2003 22:34
> To: registry at ivoa.net
> Subject: IVO ids and Data Sets Identifiers
> 
> 
> If I may intervene on this subject of the IVO identifiers, I 
> would strongly suggest not to use the hash symbol as a 
> delimiter, because it has a special meaning in the HTTP 
> protocol: it indicates a marker in the document, and what 
> comes after the # symbol is quite generally ignored by the 
> HTTP servers.  For instance the output of an HTTP GET to
>   http://www.stsci.edu/ftp/science/hdfsouth/warnings.html#NICMOS
> is exactly identical to the output of
>   http://www.stsci.edu/ftp/science/hdfsouth/warnings.html
> (the browser simply scrolls the document to position it at 
> the "NICMOS" marker)
> 
> Therefore in the general scheme of the IVO identification
>    ivo://Authority.ID/(resource_key)(dataset/subset_identification)
> the # sign could maybe appear in the 3rd part 
> (dataset/subset_identification) but certainly not a separator 
> between the parts 2 and 3 (and moreover not between the parts 
> 1 and 2) if it is wished that a resource can be reached using 
> the http conventions.
> 
> In fact, for datasets I would more agree with Guenther's 
> arguments: one Authority.ID, and what follows it is defined 
> under the responsability of the Authority.ID who "publishes" 
> the way to access to the data. The dataset can effectively be 
> a simple document like
>    ivo://Authority.ID/Resource-Service/Repository/Intrument/datasetID
> 
> but could also be something like
>    
> ivo://Authority.ID/RepositoryQuery?instrument=Intrument&ID=datasetID
> 
> As long as there is no ambiguity (the Authority.ID may 
> "delegate" the "naming space" to different missions or 
> instruments or whatever) the role of the identifiers is 
> fulfilled. The problem with the links from the journals is, 
> as pointed out by Bob, the requirement for long-term 
> persistence which can only be achieved if any change in the 
> curator is 
> propagated to the Registry who has to make this mapping between the 
> 'permanent' and the 'actual' identifiers (the GLU was not bad 
> in this role!) 
> ==============================================================
> ==================
> Francois Ochsenbein       ------       Observatoire 
> Astronomique de Strasbourg
>    11, rue de l'Universite F-67000 STRASBOURG       Phone: 
> +33-(0)390 24 24 29
> Email: francois at astro.u-strasbg.fr   (France)         Fax: 
> +33-(0)390 24 24 17
> ==============================================================
> ==================
>