On 3/25/12 12:35 PM, Tim Berners-Lee wrote:
On 2012-03 -25, at 11:38, Norman Gray wrote:Michael and all, greetings. On 2012 Mar 25, at 14:19, Michael Brunnbauer wrote:Perhaps the default IR assumption be saved by saying that a 200 URI<X> is a IR as long as we don't find some triple at X that suggests otherwise. Why not a NIR class ? If the concept of IRs/NIRs is sufficiently unambiguous to talk about it in natural language (I think it is), we can talk about it in RDF.I confess I haven't kept fully up with the details of this suddenly rampant thread, but this suggestion is the one I associate with Ian Davis back in the 'Is 303 really necessary?' thread of November 2010 (that long ago!?). One can characterise this as 'httpRange-14 is defeasible', or, as a procedure: vvvv After a client has extracted all of the 'authoritative' statements about a resource X, which is retrieved with a 200 status, it rfc2119-should add the triple 'X a eg:InformationResource', unless this would create a contradiction. ^^^^ Why would this create a contradiction? The resource X might explicitly say that it is a eg:NonInformationResource; it might be declared to be a eg:Book, which is here or elsewhere declared to be subClassOf eg:NonInformationResource; or X might be in the domain or range of a property which indicates that it is a non-IR, such as for example :describedBy.This doesn't work as the Books are Information Resources. For example, <http://www.gutenberg.org/catalog/world/readfile?fk_files=2372108&pageno=11> is a book, and <http://www.amazon.com/Moby-Dick-whale-ebook/dp/B002RKRU9A/ref=sr_1_2?ie=UTF8&qid=1332692284&sr=8-2> is a page about a book, <http://www.amazon.com/Why-Read-Moby-Dick-ebook/dp/B0052RERYQ/ref=sr_1_10?s=digital-text&ie=UTF8&qid=1332692336&sr=1-10> is a page about a book "Why Read Moby-Dick?" about a book "Moby Dick". They are all IRs. (Not useful to talk about NIRs. The web architecture does not. Now does Jonathan's baseline, not HTTP Range-14. Never assume that what an IR is about is not itself a IR.) ____________________ HOWEVER, the basic idea of giving a way of the server making it explicit that the URI identifies not the document but is subject, without the internet round-trip time of 303, is a useful path to go down. If Ian Davis and co would be happy with it, how about a header 200 OK Document: foo123476;doc=yes which means "Actually the URI you gave is not the URI of a this document, but the URI of this document is foo123476.html (a relative URI). - This is the same as doing a 301 to foo123476.html and returning the same content. - Non-data clients will ignore it, and just show users the page anyway. - Saves the round trip time of 301 - Avoids having the same URI for the document and its subject. This will dismantle HTTP range-14 a bit more, but still never give the same URI to two things. It would mean code changes to my client code and just a reconfig change to Ian's server. Tim
Tim,Alternatively, why not use the existing "Link:" header? Then we end up with the ability to express the same :describedby relation in three places thereby providing wide coverage to user agents and their preferred name/address disambiguation algorithms via:
1. RDF descriptor document graphs2. HTTP response graph via an existing header (Link:) that semantically deals with relations
3. <link/> for (X)HTML .As stated above, user agents can opt to leverage one or all of the above re. URI based name/address disambiguation algorithms.
Basically, you end up with: HTTP/1.1 200 OK ..Link: < foo123476>; rel="describedby"; type="{appropriate-mime-type}"; title="Descriptor Document"
Re. the above, here's what DBpedia has always returned, but via use of "rev" relations in HTTP responses, since we are exposing a description subject URI via its descriptor document (in this case: http://dbpedia.org/page/Linked_Data) :
http://linkeddata.informatik.hu-berlin.de/uridbg/index.php?url=http%3A%2F%2Fdbpedia.org%2Fpage%2FLinked_Data&useragentheader=&acceptheader= .
-- Regards, Kingsley Idehen Founder& CEO OpenLink Software Company Web:http://www.openlinksw.com Personal Weblog:http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile:https://plus.google.com/112399767740508618350/about LinkedIn Profile:http://www.linkedin.com/in/kidehen
smime.p7s
Description: S/MIME Cryptographic Signature
