VOSpace URIs

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.
   1. 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.
   2. 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 Received on 2006-05-02Z14:10:30