Re: Review of new HTTPbis text for 303 See Other

Oops!  That was intended to be off list, of course.  I guess I should
have trimmed the CC list before composing.  :)

On Wed, 2009-07-15 at 10:54 -0400, David Booth wrote:
> [Off list]
> 
> FWIW, I wasn't able to follow Pat's point either, but I'd like to
> understand it, so if you and Pat don't mind copying me on your
> correspondence I would be interested.
> 
> Thanks,
> David Booth
> 
> On Wed, 2009-07-15 at 03:11 +0200, 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.)
> > 
> > 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. 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
> > > mailto:phayes@ihmc.us 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
> > > -- 
> > > http://larry.masinter.net
> > >
> > >
> > >
> > 
> > 
> > 
> > 
-- 
David Booth, Ph.D.
Cleveland Clinic (contractor)

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.

Received on Thursday, 16 July 2009 13:40:07 UTC