RE: HTTP Methods

-----Original Message-----

From: www-tag-request@w3.org
To: www-tag@w3.org
Sent: 2/26/2004 5:08 PM
Subject: Re: HTTP Methods


I think URIQA has already been discussed a dozen times on this list.
I have no interest in it for several reasons

   1) the M* names have already been proposed for batch methods,
      and soundly rejected because doubling method space is evil.

                 ???  Firstly, if the present methods cannot be employed efficiently
                  and without introducing ambiguity, then I hardly see new methods
                  as "evil". They may not be your preference, but I think your choice
                  of vocabulary is much too strong. Secondly, whatever the earlier
                  proposals regarding batch processing were concerned, just because
                  those were rejected (even if soundly) that doesn't mean that all other
                  proposals for new methods are by default unacceptable.

                  I think it would be fair to expect you to clearly point out the faults
                  of the URIQA proposal more specifically than simply finding it
                  "guilty by association".


   2) the fragment is not and never will be allowed in the request-uri
      of HTTP because of the effect that has on caches and 
intermediaries.

                  Fair enough. I'd be happy seeing folks not using fragids at all. So
                  as far as I'm concerned, this simply strengthens my arguments
                  elsewhere about not using URIrefs with fragids to denote key resources
                  (such as vocabulary terms).

                  Thus, while RDF can be used to say things about resources denoted
                  by URIrefs with fragids, the use of such URIrefs limits the utility of those
                  URIs in the broader web context and thus, for practical considerations,
                  as a "best practice" folks should use URIs without fragids. Fine. Great.

   3) metadata is a resource too, leading to the desire to use all
      of the normal resource methods, access control, authoring, and
      metadata on that resource..

                  I agree. And you can. GET/PUT/DELETE work in harmony with
                  MGET/MPUT/MDELETE -- the key distinction being that the former
                  interact with representations and the latter with descriptions of the
                  resource denoted.

                  If you want to PUT a representation of a resource description,
                  you can do so. And you do so via the URI denoting the description.
                  The URI denoting the description  should be specified in the header
                  of an MGET request. Or it may be defined/obtainable elsewhere.
                  In any case, a description is a resource and GET/PUT/DELETE are
                  fully and intentionally applicable.
 
                  If you want to MPUT knowledge describing a resource, you can do
                  so as well. And you do so via the URI denoting the resource. But
                  MPUT'ting knowledge is not the same operation as PUT'ting a description.
                  The semantics/behavior of these two methods are *not* identical. Nor
                  are MDELETE and DELETE identical. MPUT and MDELETE modify
                  (not replace/remove) a description. They are not as absolute as PUT
                  or DELETE.

   4) doubling the number of methods and access control mechanisms
      is a bad trade-off when compared to using a link.

                  I disagree. Firstly, I don't see how URIQA doubles the number
                  of access control mechanisms. Secondly, the investment in
                  adding support for the URIQA methods results in huge run-time
                  savings by SW agents, reducing by at least half the number of
                  server requests that must be made simply to find out what some
                  particular URI means without having to dig into the (otherwise
                  irrelevant details) of how a particular server manages resource
                  descriptions.

   5) the cost of an additional request to find out the metadata link
      is only necessary if you don't already have that link.

                  I expect that in nearly all cases, you won't have that link.

   6) RDF is the resource description framework -- it can refer to
      metadata about a resource just as easily as it refers to
resources.

                   True. But if all you have is a single URI, what do you do?!  How
                   do you begin bootstrapping your knowledge of whatever is denoted
                   by that URI if you've never encountered it? If you already had the RDF,
                   you wouldn't need to ask.

   7) The only way to make the semantic web a second-class citizen is
      to remove its resources from the Web, which is exactly what URIQA
      proposes.

                     Firstly, my remarks about "second class resources" was specifically
                     limited to URIrefs with fragids.

                     Secondly, URIQA does *not* remove any resources from the web,
                     but provides more optimal, efficient, and robust interaction between
                     a client and server with a particular focus on precisely defined concise
                     bounded resource descriptions rather than arbitrary representations.

                      Your comments above leave me wondering if you have ever seriously
                      reviewed the URIQA spec and considered its merits or whether you have
                      simply dismissed as a matter of course because you are simply opposed
                      to new methods, of any kind....


It is a dead parrot.

                     You are entitled to your opinon, surely. I happen to disagree.

                      If interested, I would be happy to chat with you face-to-face in Cannes
                      about URIQA. Perhaps you will convince me it is a dead parrot. Perhaps
                      I'll convince you it's alive and well. Perhaps we'll jointly agree it's a potted
                      plant. Whatever.

                      Regards,

                      Patrick Stickler
                      patrick.stickler@nokia.com

Received on Saturday, 28 February 2004 14:05:53 UTC