Dave,
I admire your proposal and think it's much better than the current 303,
thus kudos++.
However, it doesn't solve the *core* problem which is that different
things need different names, and names that can never be thought to name
something else. </slash> uri's have this problem (they can be considered
as naming a document - think HTTP status code ignored as the correct
approach), as do <mailto:f...@example.com> it names a mailbox, nothing else.
The only two ways to address the issue, is to either use <tdb:> which
will provide semantic indirection, or to use #fragment uris.
As for the existing slash uris out there, they've just got the age old
problem. Best advice imho would be to support them for legacy reasons
(or migrate them, perhaps "uncool uris do change"), but get everybody
moved on to <tdb:> or #frahs from here forth.
One good reason why not?
Best,
Nathan
David Wood wrote:
Hi all,
This message is an attempt to summarize my position in relation to the points made by
others. I hope it is useful to the discussion. A new approach to the problem is
discussed at the end of this message that proposes deprecating the 303 for use in Linked
Data (only) in favor of a new HTTP response code. The new response code would state
"The URI you just dereferenced refers to a description of a resource that may be
informational, physical or conceptual. The information you are being returned in this
response contains an RDF description of the resource you dereferenced."
1) Kudos to Ian for starting the most engaging discussion on this list in many
moons.
2) I think we all agree that the SemWeb/Linked Data usage of the 303 is a
hack, non-optimal and is worthy of reconsideration *presuming* that we can
change the way a lot of people use the Web. I'm an optimist, so I'm willing to
have a go.
3) Nathan (correctly, IMO) summarized the core problems with the 303 when he
said:
On Nov 4, 2010, at 16:23, Nathan wrote:
</thing> -> 303 -> </doc>
(1) Many automated clients that make assertions about URIs treat HTTP as a blackbox,
thus are still saying </thing> a :Document . (original problem not solved)
(2) Many Humans are clicking on </thing> getting the </doc> URI in their address bar
then using that instead, saying that </doc> a :Thing . (new problem)
(3) Network effect of 303 (2 requests) vs 200 (single request), as well as
deployment considerations.
Completely leaving frag ids out of the equation, it appears (to me at least)
that new insight is that 303 isn't addressing the problem (1) and rather
introducing more (2) and (3).
David Booth's comments are similar in scope and, though he puts it differently, agrees
that the main issue is that "that many applications *will* wish to distinguish
between the toucan and its web page (or between the toucan's age and the age of it's web
page)". Indeed, the need for different URIs between a physical (or conceptual)
resource and its (informational) description is the central issue.
4) Leigh Dodds is right to call me on the distinction between deprecating 303
and their use in Linked Data. I do not think 303 should be deprecated, but do
not think they are the best solution for Linked Data.
5) I totally agree with Michael Hausenblas when he says:
On Nov 5, 2010, at 05:29, Michael Hausenblas wrote:
It occurs to me that one of the main features of the Linked Data community
is that we *do* things rather than having endless conversations what would
be the best for the world out there.
6) We can't really hack at the 303 any more than we have. I explored that in
2007 and came up pretty empty:
http://prototypo.blogspot.com/2007/08/returning-http-303s-for-semantic-web.html
So where does that leave us? I think that the best way out is to return a
single HTTP response for the resolution of a URI describing a physical or
conceptual resource that unambiguously states that the returned response is a
*description* of that resource.
That leaves me in agreement with Phil Archer (http://philarcher.org/diary/303/)
when he proposed a new HTTP response code. Let's just do it! It might work
like this (using Ian's notation from
http://iand.posterous.com/is-303-really-necessary):
# Get an information resource:
GET /doc returns a 200 (OK)
# Get an information resource with an RDF description:
GET /toucan_info responds with a 210 (Description Found)
# Get a physical resource:
GET /toucan_physical responds with a 210 (Description Found)
# Get a conceptual resource:
GET /toucan_definition responds with a 210 (Description Found)
How does that stack up against Ian's objections to the 303? Rather well,
actually.
- It returns the required information in one GET.
- Multiple descriptions can be linked from a resource's URI via the returned
RDF.
- A human using a browser stays at the same URI requested (and content
negotiation would still work).
- It is trivial to configure a Web server to match an HTTP status code to file
extensions.
- It can be implemented using a static Web server setup (one that serves just
RDF).
- It does not mix layers of responsibility.
- It can be used with information resources, as well as physical and conceptual
resources.
- It is easy to explain to the broader community.
Disadvantages are:
- W3C/IETF buy-in, time and effort required to standardize.
- Server operators would have to configure their Web servers to return the
correct status code (until Web servers shipped with reasonable defaults).
All that is left is to prototype it. It doesn't seem to break curl, so that's
a start :)
[[
Macadamia:~ dwood$ curl -I http://localhost:8090/
HTTP/1.1 210 Description Found
Date: Fri, 05 Nov 2010 14:15:31 GMT
Server: Hacked up Web server by prototypo
]]
Regards,
Dave
