Re: (Dis)Proving that 303s have a performance impact.

On Sun 2013-Feb-17, at 17:35, Kingsley Idehen <kidehen@openlinksw.com> wrote:

> If you need to retrieve the data the describes the entity denoted by the Linked Data URI. Likewise, when you try to retrieve data that describes a specific entity denoted by a hash HTTP URI you end up retrieving the description of the entity and the description its descriptor i.e., the content retrieved is a combination of the document subject and the document itself.
>
> Whenever you move from the theoretical to the practical by making a Linked Data browser (or something like that) you'll see the futility in your argument, until then I leave you to continue deflecting by references to specs etc..

Having implemented these things, I'm still failing to understand what on earth you're talking about, in part because you refuse to take the time to write in comprehensible sentences.

It's really, REALLY, simple:—

1. Best practice (and it does indeed work in practice, as you know) is that one uses different URIs for the document and the thing that is described by that document. From experience, I know that this is not obvious to those who may be very capable programmers but haven't lived and breathed linked data for long.

2. In order to do that, there are two likely mechanisms: 303 redirects or hash URIs.

3. While preferences vary, the fact that a 303 redirect results in an additional HTTP request over an equivalent hash URI is a fundamental facet of the protocol.

4. While it is obvious that anybody when asked "does a redirect introduce an additional request?" would answer in the affirmative, asking somebody who isn't entirely familiar with the httpRange-14 debate “which tends to be simpler and more efficient, hash or hashless URIs?" in this context isn't likely to yield as quick an answer.

5. There is nothing wrong, unusual, strange or otherwise about including best-practice guidance in non-normative parts of a spec. In fact, the opposite.

6. Given that WebID isn't making hash-based URIs a MUST (and nor should it, IMHO), and given that the spec shouldn't really require top-to-bottom knowledge of the entire semweb ecosystem, it is entirely sensible and normal to include guidance which explains the above and provides sufficient information to make a decision without acres of research.

7. I would caution against relying solely on the presence of hash-based URIs in the examples to make the point — as the old saying goes, “a little knowledge is a dangerous thing”, and it's entirely likely that developers unfamiliar with httpRange-14 and its ilk would read them and, lacking any other information about it, draw the conclusion that the fragid is superfluous.

8. Those who are knowledgeable enough not to need the guidance can ignore it.

So really, it boils down to whether the consensus is that having a guidance note (not necessarily with the current wording) explaining 1…3 above is on balance harmful or beneficial.

(My personal view is that if the consensus is 'harmful', there are probably bigger problems here than this specific issue).

M.

--
Mo McRoberts - Technical Lead - The Space
0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E,
Zone 1.08, BBC Scotland, Pacific Quay, Glasgow, G51 1DA
Project Office: Room 7083, BBC Television Centre, London W12 7RJ



-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

Received on Sunday, 17 February 2013 21:44:01 UTC