pharriso at eso.org
Tue May 2 05:10:17 PDT 2006
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
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://
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
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
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.
More information about the vospace