Re: hash in WebID - cachability problem

On 7 December 2012 14:51, Henry Story <henry.story@bblfish.net> wrote:

>
> On 7 Dec 2012, at 14:03, Nathan <nathan@webr3.org> wrote:
>
> > Henry Story wrote:
> >> People who do real implementations of Linked Data in javascript on the
> browser are telling us this is problematic for them: speed
> >> matters in user interface, and the 303 is creating real usability
> >> issues.
> >
> > To keep this simple:
> >
> > 303 responses by RFC 2616 are not cache'd
> > httpbis doesn't speak of caching in regard to 303 any more
>
> Ah, that is a pity. Because cached 303s + SPDY would have I think gotten a
> long way
> to resolving the efficiency issues it seems to me. ( With SPDY you could
> very efficiently
> make a large number of entity URI requests that would very efficiently
> return 303s )
>
> >
> > Pretty much all HTTP tooling everywhere for the last decade has used
> 2616 and will continue to for quite some time, 303's you may as well assume
> are not cache'd by clients (*clients = HTTP CLIENTS*).
> >
> > The web of linked data utilizes 303 redirects frequently, they are an
> every day part of what we do and encounter, any tooling which doesn't cater
> for them is missing half of the data out there.
> >
> > Every HTTP URI, with or without a fragment, can send back any status
> code, including 303, and could easily result in a huge chain of redirects.
> >
> > That is to say, WebID cannot preclude 303 responses, it's none of it's
> concern. WebID is layered on to HTTP, and the dereferencing process never
> has a fragment in it, so you're never dealing with a fragment at HTTP level.
>
> Agree.
>
> >
> > #frag URIs are great in linked data, very efficient and they keep things
> clean and simple. Slash-303 URIs exist and can be (and are) used. WebID
> Protocol requires no extra steps to enable their usage, in-fact it requires
> many many extra steps to try and preclude them.
> >
> > Ultimately we either say that a webid is an HTTP URI, or an HTTP URI
> with a Fragment - the latter restriction is virtually impossible to impose,
> but very easy to promote as a KISS approach to WebID w/ Linked Data.
>
> My guess is that there is large agreement with this position.
>
> Now given that #uris are easier for people to work with, and work better
> with the web,
> it still seems to me that one can promote them with a SHOULD in our spec.
>
> But my feeling is that even if we do, we should link it to the ISSUE-70
> and develop the
> best arguments we have on our wiki for each side, so that this can then be
> resolved
> when this is a WG and we have the full W3C process to help us come to a
> tricky conclusion
> like this one.
>
> In any case a lot of arguments are in flux:
>   - the OSX Keychain could be fixed tomorrow
>   - the HTTPBis caching of 303s could be re-introduced
>   - LDP is evolving
>   - we might find other arguments that we have not thought of yet
>     for one side or the other
>
> So it does not look like we can close this completely either. But we can
> move
> on to do the rest of the SPEC. Because I think everybody here agrees that
> #uris
> in the examples should be used, and the descriptions should be done in
> terms
> of them.
>

+1

At the end of the day, there will always be some people that do not wish to
use # URIs (no matter what the spec says), there are legitimate reasons for
doing so, but the main reasons from what I can tell for people NOT using #
URIs are human and psychological, rather than, technical e.g. some people
like vanity urls.

We should try and swing the pendulum towards the use of hash URIs by
explaining the advantages, one of which that you can logically order
multiple data points relatively to a root document while performing a
single HTTP GET.


>
>    Henry
>
>
> Social Web Architect
> http://bblfish.net/
>
>