Re: Is 303 really necessary?

Sorry, this thread has been around but the public-lod list 
snuck up on me without my getting on it, so I have missed
some of the fray!

I am happy to look at improvements in the current HTTPRange 14
architecture as I know that 303 is a pain.  But I don't want to break the web.

Looking at http://bnb.bibliographica.org/entry/GB8102507
the tabulator concludes that the thing identified by it
is both a book and an RDF document, and it shows me, by default,  the triples it contains
instead of the information about it, because that is what as a user I want.

It doesn't use this new idea from IanD of using the content-location header as
flag to indicate that the URI you used in the GET request may NOT be used
to refer to the document returned.

Suppose we go along with this new idea.

Then, it will end up with  (ignoring namespaces) in N3 the information
we get from that fetch includes:

<http://bnb.bibliographica.org/entry/GB8102507> a Book;
	contributor [name "Boyd, William"].

<http://bnb.bibliographica.org/entry/GB8102507.rdf> a DataDocument;
	foaf:primaryTopic <http://bnb.bibliographica.org/entry/GB8102507>.

Ok,  I understand the system. 

But if you introduce this as the architecture of the  web, 
then it applies all the time.  You can't chose when it applies and when it doesn't.

Now look at 

	http://www.w3.org/2008/site/images/logo-w3c-mobile-lg

This dereferenced to give you a content-location of

	http://www.w3.org/2008/site/images/logo-w3c-mobile-lg.png

What do we know then?

<http://www.w3.org/2008/site/images/logo-w3c-mobile-lg.png>
	we know we can use to refer to the image in its PNG version.
<http://www.w3.org/2008/site/images/logo-w3c-mobile-lg>
	we know nothing about.

Because the fetch returned a content-location header,
we are now not allowed to use that URI to refer to anything -- it could
after all refer to the Eiffel Tour, or the W3C as an organization
according to the new system.

Does this make sense?

If you look that up in a browser, you will see the image in the 
window and the URI in the title bar.
We in fact really expect that people SHOULD use the generic URI
"http://www.w3.org/2008/site/images/logo-w3c-mobile-lg"
to refer to the logo, not the .png URI, as people may need the
content negotiation, and we may introduce a new version in
a new graphics format some time.

So all across the web, people are, and should use the original URI
to refer to the image.  Tthey 
see something in the URI bar and a document (image, etc)
in the window and they assume rightly they can use that
URI to refer to that image.

The bookmarking system works like this.
Emailing a friend a URI of something you are looking at works like this.
Making a link to something you think it cool works like this.
Putting a image in your page someone else has in their page works like this.
The web works like this.

We can't make the semantic web work in a way that actually
leaves the web not working.

We can't leave the WWW working one way and the LOD web working another, as they are inextricably interconnected.

Now ....  Someone in the the thread somewhere at one point suggested a friendly
amendment to the original proposal, where a new status code
is sent for semantic web data being returned *about* the
object identified by the request URI, rather than information *in* it.
I think 208 was suggested, I.e, the next unused one.

With that modification, I can't see a snag.

- It is only used for data so old web browsers are not going to be seeing it
- The data world is young enough for us to slide it in, maybe, without too much
  harm to existing clients, which would all have to be recoded, but it might be worth it to 
relieve this tension.
- the rest of the web continue to use 200


Tim




------------------------------------------------------------------------------------
Some headers fro URIs above:

$ curl -I  http://www.w3.org/2008/site/images/logo-w3c-mobile-lg
HTTP/1.1 200 OK
Date: Sat, 27 Nov 2010 19:21:50 GMT
Server: Apache/2
Content-Location: logo-w3c-mobile-lg.png
Vary: negotiate,accept
TCN: choice
Last-Modified: Sun, 25 Apr 2010 15:27:07 GMT
ETag: "11a9-485114b0e28c0;4876eed0c4800"
Accept-Ranges: bytes
Content-Length: 4521
Cache-Control: max-age=2592000
Expires: Mon, 27 Dec 2010 19:21:50 GMT
P3P: policyref="http://www.w3.org/2001/05/P3P/p3p.xml"
Connection: close
Content-Type: image/png; qs=0.7


This is odd -- doesn't support HEAD?

$ curl -I http://bnb.bibliographica.org/entry/GB8102507
HTTP/1.0 406 Not Acceptable
Date: Sat, 27 Nov 2010 19:29:24 GMT
Server: Apache/2.2.14 (Ubuntu)
Pragma: no-cache
Cache-Control: no-cache
Access-Control-Allow-Origin: *
Vary: Accept-Encoding
Content-Type: text/html; charset=UTF-8
X-Cache: MISS from localhost
X-Cache-Lookup: MISS from localhost:80
Via: 1.0 localhost (squid/3.0.STABLE19)
Connection: close

$ curl -I -H Accept:application/rdf+xml http://bnb.bibliographica.org/entry/GB8102507
HTTP/1.0 406 Not Acceptable

$ cwm http://bnb.bibliographica.org/entry/GB8102507 --no
          Warning: <ddc:Notation> is not a fragment! 
          Warning: <dc:ISO639-2> is not a fragment! 
          Warning: <ddc:Notation> is not a fragment! 
$ 

$ curl -v -H Accept:application/rdf+xml http://bnb.bibliographica.org/entry/GB8102507 > /dev/null
[...]
< HTTP/1.0 200 OK
< Date: Sat, 27 Nov 2010 19:36:26 GMT
< Server: Apache/2.2.14 (Ubuntu)
< Pragma: no-cache
< Cache-Control: no-cache
< Content-Location: GB8102507.rdf
< Content-Length: 5294
< Access-Control-Allow-Origin: *
< Content-Type: application/rdf+xml; charset=utf-8
< X-Cache: MISS from localhost
< X-Cache-Lookup: MISS from localhost:80
< Via: 1.0 localhost (squid/3.0.STABLE19)
< Connection: close
[..]