« [Linking-open-data] Semantic Crawling sitemap extension: pleasereview   [Linking-open-data] Linked Data and FOAF: bNodes are out :-) »

[Linking-open-data] Fwd: 203,400, 406 as alternative to 303 ?

Giovanni Tummarello writes on 2007-07-11 :

Browse this thread Giovanni Tummarello »
Hi all
I sent this on the semweb ML but no replies yet,
so i am wondering, what do you guys think?

Giovanni


---------- Forwarded message ----------
From: Giovanni Tummarello <>
Date: Jul 10, 2007 2:29 AM
Subject: 203,400, 406 as alternative to 303 ? :-)
To: 


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


Responses