Re: Review of new HTTPbis text for 303 See Other

On Jul 14, 2009, at 8:11 PM, Richard Cyganiak wrote:

> Thanks Larry. I wish I could talk with such clarity.
> I want to take the discussion with Pat a bit further, but will do so  
> off-list. (Tomorrow, Pat -- I need to mull it over a bit.

OK, but see quick remark below.

> )
> I initially joined the thread to say this: The HTTP spec, with Roy's  
> proposed new 303 text, accommodates all Semantic Web use cases I can  
> think of. Including using HTTP URIs to denote people.

And my entire beef with it is that there is a case it misses, which is  
a URI denoting a person but which resolves to an http endpoint which  
has access to a 200-codable representation of itself (not of the  
person, but of it, the resource on the other side of the http  
interface.) And that IS a possibility, and I can even imagine some  
very nice uses for it.

> It's good to see httpRange-14 slowly "trickle down" into the specs.



> Cheers,
> Richard
> On 14 Jul 2009, at 21:46, Larry Masinter wrote:
>> This conversation is filling my mailbox. Some general
>> observations:
>> (Pat, your arguments are laced with ad hominem, which makes reading
>> the dialog unpleasant. I don't think Richard is being
>> silly, intellectually dishonest, bloody arrogant, or any of the
>> other terms you've used, please refrain.)
>> It's the nature of standards discussions that people speak
>> their point of view; doing so isn't arrogant.
>> It is the nature of technical specifications that it is frequently
>> necessary to take normal English words in particular technical
>> way; it is not intellectually dishonest to do so.
>> It is good practice for technical specifications in standards
>> groups to say as little as possible in order to meet the
>> needs of interoperability and the purpose for which the
>> specification is being written.
>> It is not necessary or even possible for a technical specification
>> to answer questions that may be fundamental for applications
>> that are outside of its scope. It is common, reasonable,
>> and traditional for standards specifications to "not answer"
>> questions because answering the question isn't necessary
>> for the purpose for which the standard was written.
>> It isn't necessary for the proper functioning of the web and
>> to accomplish interoperability of web clients and servers
>> to agree on how to use HTTP URIs and the HTTP protocol --
>> for that purpose, it isn't necessary to answer the question
>> of whether a HTTP URI can identify a person.
>> It may be necessary to answer the question in a technical
>> specification for the semantic web and in the RDF
>> specification  -- but the answer more likely
>> belong in those specifications and not in the
>> IETF HTTP specification.
>> It may be necessary for the IETF HTTP specification
>> be edited in a way that made it clear that it didn't
>> contain the answer to this question, but I'm not
>> sure where to draw the line of describing things
>> it doesn't answer.
>> It's easy to imagine a system in which a URI is used
>> to identify a person for the purpose of that system.
>> But I can't see how IETF, W3C, or continued discussion
>> on any of our mailing lists are going to converge
>> any time soon on answers to the philosophical questions
>> that have been with us for millennia. What is it
>> that "Pat Hayes" identifies, anyway? Can I use
>> as a URI to identify you?
>> Well, that's a question outside of the "mailto:"
>> URI spec, I think.
>> Perhaps  there needs to be a better way of distinguishing
>> the statements "this specification does not limit the scope
>> of applicability" and "this specification applies in all
>> circumstances".
>> If you had some better way of phrasing it so that it would
>> be clear the former was meant rather than the latter, I
>> think that would be helpful.
>> The fact that something "does matter" -- to you, to the
>> RDF community, to the W3C, to the world at large --
>> does not mean that it is appropriate to "matter" in
>> the context of the HTTP spec.
>> It is an important design principle for developing
>> specifications to keep specifications orthogonal: for the purposes
>> of the HTTP protocol, it does not matter what resources
>> are exactly. For the purpose of resource identification, it should
>> not matter what the protocol is; tying semantic web
>> interpretation to a particular error code in the HTTP
>> protocol seems like bad design to me.
>> The idea that the HTTP working group should care about the
>> semantic web and change its specification to meet some
>> semantic web requirement for use of HTTP URIs in semantic
>> web applications  -- well, that raises several red flags
>> for me, that we're building specifications that are not
>> sufficiently orthogonal that things that *shouldn't* matter
>> are taken as important questions that *must* be answered.
>> The HTTP specification is *not* about what a "resource" is.
>> It *is* about how to use and implement the HTTP protocol.	
>> There continues to be some confusion in the discussion between
>> "URI" and "HTTP URI" that I find disturbing and confusing, because
>> I think sometimes statements about one are attributed to the
>> other. Not all URIs are HTTP URIs. Please try to be more careful.
>> Regards,
>> Larry
>> -- 

IHMC                                     (850)434 8903 or (650)494 3973
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile

Received on Wednesday, 15 July 2009 15:58:10 UTC