Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]

On 6/15/11 4:27 PM, Danny Ayers wrote:
> On 13 June 2011 07:52, Pat Hayes<phayes@ihmc.us>  wrote:
>> OK, I am now completely and utterly lost. I have no idea what you are saying or how any of it is relevant to the http-range-14 issue. Want to try running it past me again? Bear in mind that I do not accept your claim that a description of something is in any useful sense isomorphic to the thing it describes. As in, some RDF describing, say, the Eiffel tower is not in any way isomorphic to the actual tower. (I also do not understand why you think this claim matters, by the way.)
>> Perhaps we are understanding the meaning of http-range-14 differently. My understanding of it is as follows: if an HTTP GET applied to a bare URI http:x returns a 200 response, then http:x is understood to refer to (to be a name for, to denote) the resource that emitted the response. Hence, it follows that if a URI is intended to refer to something else, it has to emit a different response, and a 303 redirect is appropriate. It also follows that in the 200 case, the thing denoted has to be the kind of thing that can possibly emit an HTTP response, thereby excluding a whole lot of things, such as dogs, from being the referent in such cases.
> Even with information resources there's a lot of flexibility in what
> HTTP can legitimately respond with, there needn't be bitwise identity
> across representations of an identified resource. Given this, I'm
> proposing a description can be considered a good-enough substitute for
> an identified thing. Bearing in mind it's entirely up to the publisher
> if they wish to conflate things, and up to the consumer to try and
> make sense of it.
>
> As a last attempt - this is a tar pit! - doing my best to take on
> board your (and other's) comments, I've wrapped up my claims in a blog
> post: http://dannyayers.com/2011/06/15/httpRange-14-Reflux
>
> Cheers,
> Danny.
>
Danny,

This is part of the problem:

TBL's argument: the HTTP URIs (without "#") should be understood as 
referring to documents, not cars.

It assumes that the audience doesn't have a clue, so the description has 
to be so condescending albeit inadvertent.

How about:
TBL's argument: the HTTP URIs (without "#") should be understood as 
referring to an Address. A Data Source Name. What data publisher 
provides to user agents for accessing specific data in a given format, 
courtesy of content negotiation or lack thereof etc..

The confusion is a self inflicted one courtesy of narrative style and 
tone, methinks.

URIs abstract Names and Addresses. This whole thing isn't unlike DNS. 
Points of presence on TCP/IP networks have NIC addresses and cnames, 
courtesy of DNS. Spreadsheets have offered cell addresses and cell names 
since forever. Programmers have worked with de-reference (indirection) 
and address-of operators forever. Most of the time when they encounter 
the: "... is a document, not cars ... " style narrative, its throws them 
for a loop!

As you know, a Document == Data Container that's projected to users via 
user agents (typically browsers) using a specific presentation oriented 
metaphor.

Using 303 to deliver indirection is an accurate reflection of the 
required heuristic for implementing de-reference (indirection) via HTTP 
URI based Names. Otherwise, use a # terminated URI and get similar (but 
ultimately limited) effects without an actual 303.

Web users started off using Addresses as Names for Resources (Web Docs). 
Now we're introducing a new abstraction where Name and Address are 
Distinct (i.e., we have Named Objects and Object Representation 
Addresses, interwoven), thus we need to find a variety of ways to 
explain and demonstrate this new abstraction generally known as Linked 
Data. One size never fits all, and http-range-14 is certainly not going 
to be the narrative that breaks that age-old mold :-)

-- 

Regards,

Kingsley Idehen 
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen

Received on Wednesday, 15 June 2011 21:47:05 UTC