Re: Important Change to HTTP semantics re. hashless URIs

On Mon 2013-Mar-25, at 09:07, Erik Isaksson <> wrote:

> So Content-Location provides a "more specific identifier", which I
> don't think helps us with avoiding 303. Anyway, personally, I think
> we're along the right track here.

Well, it can do. it depends if you're trying to differentiate two things or three things.

dbpedia and others differentiates two URIs:

- described entity (/resource/foo)

- specific serialisation (/page/foo)

In which case Content-Location is just fine for doing that. You request /resource/foo, you get a Content-Location response header containing /page/foo.

Other implementations seek to differentiate three different URIs (for a variety of reasons):

- described entity (/foo#id)

- conceptual document (/foo)

- specific serialisation of that document (/foo.ttl, /foo.n3, /foo.html, etc)

Without getting into a hash/hashless debate, 303 or C-L *alone* won't differentiate all three of those things, but using them in combination with fragments or each other will (and IMO, the combination of fragments and C-L tends to be easier there).


Mo McRoberts - Analyst - BBC Archive Development,
Zone 1.08, BBC Scotland, 40 Pacific Quay, Glasgow G51 1DA,
MC3 D4, Media Centre, 201 Wood Lane, London W12 7TQ,
0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E

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
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to

Received on Monday, 25 March 2013 09:15:06 UTC