Re: Change Proposal for HttpRange-14

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 graphs
2. 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