On 02.05.2006, at 17:31, Roy Williams wrote:
> On May 2, 2006, at 5:10 AM, Paul Harrison wrote:
>> Replace this
>> ivo://org.astrogrid/vospace#my/pathto/mydata
>> with this
>> vos://org.astrogrid!vospace/my/pathto/mydata
>
This makes it look like a simple substitution of a few characters,
but there is a world of difference in semantic meaning. There are
clear generic parsing rules laid out in http://www.ietf.org/rfc/
rfc3986.txt that the vos: scheme obeys as the rules for a
hierarchical locator namespace where the ivo: scheme itself does not,
so for instance relative URLs work in the vos scheme, but do not in
the ivo: scheme
> Paul
>
> If we add new and subtle semantics to the IVORN syntax, then a lot
> of documentation will have to be made over the next years
> explaining vos:// and ivo:// and why there are two and how they are
> parsed and used. Each VO tutorial for the next 5 years will have to
> include 15 minutes on ivo and vos. Future IVOA meetings will need
> extra time for this extra syntax/semantics. People will want their
> own prefix ("can I use voe:// for VOEvent?"). So this is a big time
> commitment and you need *very* good reasons for this. Your reasons
> are good, I am not sure they are good *enough*......
I would contend that because the vos: scheme follows the standards for URIs there is less documentation needed as reference can be made to the standard internet rfc document - Having to specify complex rules for interpretation of the fragment or query parts of ivo: URIs for each protocol that wants to have structure within these parts is thus more burdnesome. In addition conformance with the familiar structure of http: URLs will mean that people will understand more about how a vos: URL works without having to read any documentation...
>
> -- In each case you need to use the registry to get an endpoint
> (from ivo://org.astrogrid/vospace or from vos://org.astrogrid),
> then you make a service request to that endpoint to get the data.
> Is that right?
yes, but you do not need to consult a registry to know that vos: is a reference to a VOSpace location - as we are proposing to allow VOSpace to contain soft links this distinction could be useful in future, as it might be possible to point to the results of an OpenSkyQuery for instance. It would then be possible to do certain types of relative VOSpace reference resolution with purely lexical manipulation of the URL.
The relationship between the vos: URLs VOSpace servers and ivo: URIs and the registry is analogous to the relationship between http: URLs, web servers and hostnames and DNS resolvers. In a http: URL the authority part (the part between the // and the first / needs to be looked up in a DNS server to actually contact the web server to obtain the data pointed to by the path part of the URL - in a vos: URL, a registry needs to be contacted to
>
> -- If you want to put a DNS address in (so you don't need to query
> the registry), then you could use a normal http prefix without the
> effort of making new identifier standards:
> http://astrogrid.org/vospace/my/pathto/mydata
>
> -- You can already assign whatever semantics you wish to the
> fragment part. You can have query!path!tablecolumn if you want
> without need of building a new identifier syntax.
>
> -- I think people already know what these ivorns are supposed to
> be, they don't need a special prefix. If I made a query for
> Conesearches and got some ivorns back, then I know what they should
> be because that come from that query. Hey how about a cos:// prefix
> for cone searches so I can recognize them?
>
I recognise that there is a temptation to want to create new URI
schemes for everything, but I believe that VOSpace is a special case,
as it is supposed to be the place that a data item can be named in a
manner independent of any particular properties of the data - a cone
search for instance identifies data by specifying properties about
the data - and that space has arbitrary structure all of its own -
i.e. hierarchical containers. I believe that these two properties of
VOSpace combined with the likely need for humans to have to exchange
VOSpace URLs mean that it deserves a first class URL system rather
than being a dereferenced ivo: scheme...
Received on 2006-05-03Z13:29:52