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
-- Mark Taylor Starlink Programmer Physics, Bristol University, UK m.b.taylor@bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/Received on 2005-08-23Z11:09:51