W3C home > Mailing lists > Public > semantic-web@w3.org > July 2007

203,400, 406 as alternative to 303 ? :-)

From: Giovanni Tummarello <g.tummarello@gmail.com>
Date: Tue, 10 Jul 2007 02:29:07 +0100
Message-ID: <4692E0E3.8020508@gmail.com>
To: semantic-web@w3.org

Hi all,

looking at http 1.1 for an alternative to the non cachable 303 one is 
tempted by the 200 series of course.
A 20x wouldnt cause the counterintuitive change in the URL/URI whenever 
one is trying to dereference a semantic web URI/URL
e.g. http://dbpedia.org/resource/Berlin which in the browser location 
bar turns into http://dbpedia.org/page/Berlin

 It seems to be the main reason why this kind of response might sound 
inappropriate is the general definition of 200 in response to a get:
"an entity corresponding to the requested resource is sent in the response".

So it sounds like it would be a bad response in case of a non 
information resource.
But this is not the case.. because going into detail most of the 20x 
responses don't really send "an entity corresponding to" but do 
something else..
lets take 203.. (for example but there are other)  which says "hey it 
might be a subset or a superset.. the real resource is somewhere else, 
this that i am serving is different (subset or superset or annotations 
etc) ":

---
203 Non-Authoritative Information

The returned metainformation in the entity-header is not the definitive 
set as available from the origin server, but is gathered from a local or 
a third-party copy. The set presented MAY be a subset or superset of the 
original version. For example, including local annotation information 
about the resource might result in a superset of the metainformation 
known by the origin server. Use of this response code is not required 
and is only appropriate when the response would otherwise be 200 (OK).
---

Lets forget that its called "non authoritative" (as this would actually 
be pretty authoritative, i mean you mint the URI you have clearly the 
right to be called authority for it)  .. could this in fact be 
appropriate for what we want to do? that is return something but not 
necessarely the "real entity" (which might not be an information 
resource in fact) and in fact return the local annotations about it?.

Lets see how this would work in practice:

For humans.. good. They look at http://dbpedia.org/resource/Berlin , the 
page doesn't change, they see an HTML version of the rdf, and the page 
possibly can say "This is a semantic web resource, you're  looking at 
our authoritative information it" they can copy paste that URL from and 
to a semantic web application to the browser. it works for them.

For a machine, there is as little ambiguity as for a 303. If you  ask 
for an rdf/xml in your content negotiation, you get a description 
anyway. If you try to dereference it as an information resource, you get 
a 200 if it is, a 204 if might be something else.
In this case as a machine you can either either re ask the same URL with 
a content negotiation set to rdf/xml  or look for a specific header we 
could define or look of the content that we receive  has any meta link 
to something that could clarify the issue (e.g. the html description 
page for that resource is returned and embeds a meta link to an rdf 
descriptin of that resource)

Other alternatives sharing the same properties (usually cachable and 
doesn't cause browser url changes) could be a 40x series.. since all in 
all you are asking the wrong thing by asking get on a non information 
resource.. so a 406 (not acceptable) or a simple 400 could be a good 
answer if you're not asking for rdf/xml which enables you to anyway 
generate a human readable version (the user would never now its an error 
code that's being returned! the page would look perfectly nice as you 
can output html after an error code)

As a conclusion, nothing is perfect here and i see that there is a 
proposal for a new version of HTTP where these concepts could and should 
be clarified. In the meanwhile could these alternative tricks  help with 
the current issues?

Giovanni
Received on Tuesday, 10 July 2007 01:29:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:47:25 UTC