IVO ids and Data Sets Identifiers

[Francois Ochsenbein]

Tony,

My only problem is that the usage of the # will forbid the usage
of the same identifier as an IVO identifier AND as an UR[IL] directly
usable to point to a dataset from an electronic article. It therefore 
means that the 2 things have to be disjoined because it is not possible
(in the HTTP sense) to make a distinction between
   //Authority.ID/(resource_key)#(dataset_1) and
   //Authority.ID/(resource_key)#(dataset_2)

I feel it's a pity to introduce this incompatiblity -- and moreover
I agree fully with Arnold, I cannot understand the necessity of a
resource_key. What you need is just a unique identifier, which will
be supplied by the Authority.ID . It's not the role of the registry
to define this, IMHO.

Cheers, francois

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