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 [..]