VOSpace URIs

[Paul Harrison]

Early drafts of the VOSpace (or more accurately VOStore) standard  
proposed defining locators for the space by dereferencing using the  
"fragment" (#) extension of the IVOA standard identifier scheme ivo:  
so for example a reference

ivo://org.astrogrid/vospace#my/pathto/mydata

would point to a particular data holding called mydata in a container  
called "my/pathto/" on a vospace server the location of which could  
be found by looking in the registry entry with identifier "ivo:// 
org.astrogrid/vospace"

  For the particular case of VOSpace I would like to propose that  
this practice is not followed. I believe that the because VOSpace is  
a complete namespace of its own with locator style semantics, it  
deserves its own URI scheme. There are the following advantages;

1. Client software and humans could immediately recognise that they  
had been given a VOSpace URI by trivial inspection of the namespace  
prefix, as opposed to having to do at least one dereferencing  
operation in the registry to check if the URI does indeed refer to  
VOSpace. The example given above could refer to a VOEvent for  
instance if someone had been perverse enough to register a voevent  
server with an identifier that looked more like a vospace. One of the  
aims of VOSpace is to make it easy to share data, and so it should  
also be easy to recognise and manipulate the locators for the data.

2. A VOSpace specific scheme could more closely follow the general  
URI semantics and syntax as laid down in http://www.ietf.org/rfc/ 
rfc3986.txt so that they could be manipulated by generic URI parsing  
software - i.e.
    a) Use the general form that indicates a "/" to be interpreted as  
part of a locator hierarchy - it is unfortunate that the ivo: scheme  
allows the use of "/" in identifiers when there is no implied  
hierarchy in that scheme.
    b) Use the "fragment" and "query" parts of the URI directly in a  
VOSpace scheme rather than these syntactic constructs having to be  
used simply to delimit what belongs to the ivo: scheme and what it  
part VOSpace reference. It was an early design aim of VOSpace that it  
should be possible to reference parts of the the data objects - e.g.  
columns in a VOTable file, and it would be beneficial if the URI  
scheme could support this simply and directly.

With these advantages it remains only to define the VOSpace URL  
scheme following the advice in http://www.ietf.org/rfc/rfc2718.txt ;  
The general idea would be to have a scheme vos: that had similar  
semantics to the http: scheme with general structure

vos://authority/path?query#fragment

The authority part is intended to be the ivoa identifier for a  
VOSpace server so that the registry would play the same name lookup  
service role that DNS typically does with http URLs. The main problem  
here is the fact that the IVOA identifiers already use "/" as part of  
the identifier which make the direct use of the unaltered IVOA  
identifier impossible, as the "/" that was part of the IVOA  
identifier would be interpreted as the start of the path part of the  
vos: scheme. In this case the "/" needs to be replaced by another  
reserved character - preferably without another common meaning (and  
in the "discouraged" set of characters in the IVOA identifiers  
standard - "!" or "$" would be candidates, so that the original  
example above could be represented as

vos://org.astrogrid!vospace/my/pathto/mydata

it might even be a good idea to prefix the authority part with a "!"  
also to make it clear that the authority should not be interpreted as  
an ordinary IP DNS host name representation.

vos://!org.astrogrid!vospace/my/pathto/mydata


Paul Harrison