Re: Change Proposal for HttpRange-14

Tim,

(CCing www-tag)

On 25 Mar 2012, at 15:34, Tim Berners-Lee wrote:
> On 2012-03 -25, at 07:31, Jeni Tennison wrote:
>> Yes, as I argued here [3] I strongly believe that casting the separation of IR and the thing it describes as a best practice rather than a vital necessity is the right way to go.
>> 
> 
> To actually confused those things in a system is to me is absolutely unacceptable.
> When I build rule file or systems some of them deal with documents and
> some with things that those documents describe, and in general they do both.

To be clear, what I said above is *not* part of the change proposal. I know it is not acceptable to you, so putting it in a change proposal would be pointless.

> If you want to define a new proposal then it had better be one where for
> a given URL I know which it identifiers.  

You mean, for some set of URLs you know that it identifies an IR, right? Even you couldn't know for *all* URLs *exactly* what they identify, just by looking at them or just from a HTTP status code.

> 	Pre - HR14, I could do that by looking at the URL.

You mean, that you knew for the subset of URLs that didn't have hashes, you could tell that they were IRs. I don't think you could tell anything about the URLs that did have hashes what they identified, just by looking at the URL.

> 	Post-HR14, I had to do a network operation to find out, but I can put up with that if it REALLY helps people.

Right, with HR14, the set of URLs for which you could tell whether they were a IR was limited to just those that returned a 2XX response, leaving a larger set of URLs for which you couldn't tell whether they were a IR or not (eg those that gave a 303 or a 4XX response).

> With your change proposal, there are times when you don't know at all!

Yes, just as there were before HR14 and after HR14.

I hear that you would like there to be a larger set of URLs that you *know* are IRs. I don't currently understand how it alters what the applications that you care about do.

What do your applications add into the set of RDF that you manipulate with your rules when you know something is an IR? Do you add a type assertion or something to the RDF you get when you get a 2XX response? How do you use those statements in your application? What do your applications do when the RDF that you get from the URL asserts something that is in conflict with the idea that the URL identifies a document, such as <U> a foaf:Person?

I'd be happy with an approach that had more things in the IR bracket, so long as it's recognised that there are some URLs that provide a 2XX response that you cannot tell are IRs. For example, an assumption that if U gives a 2XX response then it identifies an IR *unless* the statements about U include a rdf:type statement that states U has a type that is *not* a IR type (where the IR types are listed explicitly in a registry). Would that feel more reasonable or would that be unacceptable to you as well?

> For example, under your change proposal does 
> "http://www.gutenberg.org/catalog/world/readfile?fk_files=2372108&pageno=11"
> identifify? 
> 
> If
> card:i  :likes <http://www.gutenberg.org/catalog/world/readfile?fk_files=2372108&pageno=11>.
> Do I like a book or a whale?
> 
> To not know is unacceptable to me. 


Currently, I believe that it means you like the Project Gutenberg web page that contains page 11 of that particular edition of Moby Dick. Do you think it says that you like the book? If you do, I'm seriously confused and fear that I must have misunderstood the entirety of the httpRange-14 decision.

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Sunday, 25 March 2012 17:57:16 UTC