VOEvent 20110215 notes

[Norman Gray]

Rob, hello.

On 2011 Mar 18, at 20:34, Rob Seaman wrote:

>> URL design: you mention the IVORN <ivo://nvo.caltech/voeventnet/catot#1004071150784109051>.  The semantics of URIs mention that fragments are intended to be interpreted/resolved client-side:
>> 
>>>  As such, the fragment identifier is not used in the scheme-specific
>>>  processing of a URI; instead, the fragment identifier is separated
>>>  from the rest of the URI prior to a dereference, and thus the
>>>  identifying information within the fragment itself is dereferenced
>>>  solely by the user agent, regardless of the URI scheme.
>>> <http://www.ietf.org/rfc/rfc3986.txt>
>> 
>> I can't help feeling that using the fragment in this way is rather going against the URI grain, in a way I could elaborate if given any encouragement.
> 
> You are encouraged.  Don't know what to do here unless you elaborate. I suspect the implications will be broader than VOEvent.

I think the problem is that the URI RFC, as quoted above, states that the fragment is removed from the URI before any dereference.  That is, the spec appears to require that any application ('user agent') which dereferences <ivo://nvo.caltech/voeventnet/catot#1004071150784109051> must do so by removing the fragment, retrieving <ivo://nvo.caltech/voeventnet/catot>, and then looking for the <#1004071150784109051> within it, in some way.  Since this fragmentless URI is designed to be a completely different resource, and since 'retrieving the stream' is potentially a big operation, what the VOEvent spec appears to want (namely being able to retrieve <ivo://nvo.caltech/voeventnet/catot#1004071150784109051> in isolation) appears to be frustrated by the URI spec.

Now, there's not _necessarily_ a problem.  There's nothing to stop someone saying "please give me information about the thing named <ivo://nvo.caltech/voeventnet/catot#1004071150784109051>", or some more formal version of that.  That would work, but naming VOEvents in this way

(a) seems to violate a principle of least surprise (namely the general, warranted, expectation that 'fragments are resolved client-side'); and

(b) means you can never 'dereference' a VOEvent's URI, in any way which is compatible with the URI RFC.

Perhaps the implications are indeed broader than VOEvent, but the two possibilities that occur to me are the following 

(a) Replace the '#' with a '?'.  This is a bit of a cop-out, but is the smallest possible change.

(b) Don't require the VOEventStream URI to be a prefix of the VOEvent URI.  The draft here is very deliberate, saying "The Event identifier also expresses the Stream identifier" in bold letters, but it doesn't say why this is important.

If the point is simply to ensure that there's a link from the VOEvent back to its parent VOEventStream (which seems like a good thing), then that could be managed by simply requiring a suitable reference to appear in the VOEvent packet.  This is more compatible with Linked Data practice.

That way, a service has complete freedom to mint stream and event URIs as it wishes.  It could have <ivo://nvo.caltech/voeventnet/catot?1004071150784109051> or <ivo://nvo.caltech/voeventnet/catot/1004071150784109051> or <ivo://nvo.caltech/voeventnet/catot;subrsrc=1004071150784109051>, whatever was most convenient.

I can imagine there are existing implementations which have the '#' assumptions built in to them.  That may be storing up problems for the future.

All the best,

Norman


-- 
Norman Gray  :  http://nxg.me.uk