VOStore interface

Mark Taylor m.b.taylor at bristol.ac.uk
Tue Aug 23 02:09:20 PDT 2005

Paul Harrison wrote:

> Matthew Graham wrote: 
> > Identifiers:
> > --------------
> >
> > The protocol identifier ivo:// identifies a resource that exists in the
> > VO. It does not promise that you can completely resolve a URI beginning
> > ivo:// in a registry, merely that some component of the URI will relate
> > to a resource that has a registry entry, i.e. the bit before the first #
> > can be resolved in a registry. So I can go to a registry and find out
> > where ivo://nvo.caltech/vostores/vostore1 is
> > but I need to go to VOStore interface for this store to resolve
> > ivo://nvo.caltech/vostores/vostore1#halibut3. I do not see why we need
> > to introduce a second protocol just for VOStore contents.
> Introducing a new URI for vostore is not absolutely necessary,
> as you demonstrate above, you can invent any interpretation of
> the ivo: URI that you want, however, a separate URI scheme does
> have the benefits of
>     * reducing complexity of client software that has to interpret
>       VO URIs/URLs - they can make simple decisions based on string
>       syntax rather than having to constantly query registries,
>       which could become a performance issue.
>     * adhereing more closely to established URI/URL manipulation
>       conventions - the # character normally denotes a "fragment"
>       of the referenced resource - it is arguable whether this
>       useage is a fragment. 

I'd like to make a late addition to this debate by agreeing 
with Paul here on both his points.  With regard to the second one,
RFC 2396 (the URI generic syntax definition) says in section 4.1:

   When a URI reference is used to perform a retrieval action on the
   identified resource, the optional fragment identifier, separated from
   the URI by a crosshatch ("#") character, consists of additional
   reference information to be interpreted by the user agent after the
   retrieval action has been successfully completed.  As such, it is not
   part of a URI, but is often used in conjunction with a URI.


   The semantics of a fragment identifier is a property of the data
   resulting from a retrieval action, regardless of the type of URI used
   in the reference. 


   A fragment identifier is only meaningful when a URI reference is
   intended for retrieval and the result of that retrieval is a document
   for which the identified fragment is consistently defined.

this makes clear that a string like
"ivo://nvo.caltech/vostores/vostore1#halibut3" cannot be interpreted
as a URI referencing a file on a remote store except in relation to
the retrieved content of a document called 
"ivo://nvo.caltech/vostores/vostore1".  Of course we're not obliged 
to interpret it as a URI, we can just call it an opaque string 
in the context of VOStore semantics, but (a) it seems unnecessarily 
confusing to have something which looks like a URI but is not and 
(b) since the string can effectively be used by client software 
as a locator for a persistent object, it will probably be useful 
in some contexts if it can be treated as a URI. 

Simply using some other character to separate the VOStore ID and
the resource location within that store ("?" would seem a good 
choice, as it has a somewhat similar function in http URLs)
would clear this problem up.

> Another argument for a new scheme is that it has been suggested
> that it would be nice to be able to reference fragments of the
> stored entity - e.g. parts of a VOTable - the ivo: scheme is
> already rather overburdened to allow this extra level of specification.

The URI fragment mechanism would seem to be appropriate for this,
but it can only correctly be used if the '#' is not used already within
the basic URI.  If the '#' is switched for something else as I've
suggested above, this facility would not require a new protocol
identifier.  In fact a new protocol ID is not required for the 
other point either, as long as there is some syntactic way of
determining whether the string refences a file on a VOStore or not.


Mark Taylor    Starlink Programmer     Physics,  Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/

More information about the vospace mailing list