- From: <Patrick.Stickler@nokia.com>
- Date: Thu, 26 Feb 2004 15:03:01 +0200
- To: <BRYAN.B.THOMPSON@saic.com>, <BRYAN.B.THOMPSON@saic.com>, <www-tag-request@w3.org>, <jon@hackcraft.net>
- Cc: <danny666@virgilio.it>, <joe@bitworking.org>, <www-tag@w3.org>
I'm not sure we're completely on the same page here. You refer to "service descriptions". I'm talking about descriptions about any arbitrary resource whatsoever. Consider an agent that is harvesting knowledge from the SW, crawling from description to description. For each URI encountered, having to go through the gymnastics of negotations with each server just to work out how to ask for, much less get the description of each resource is not my idea of a good design. How do you think current web users would react if, for the next version of HTTP, it would be necessary to first submit a HEAD or OPTIONS request to get some crucial bit of information *before* a GET or POST or PUT, etc. request could be submitted? I hardly think that would go over very well. So why do folks think that those of us interested in deploying the semantic web would be perfectly happy and content to have to incur such overhead to simply interact with authoritative servers regarding resource descriptions? Regards, Patrick -----Original Message----- From: www-tag-request@w3.org on behalf of ext Thompson, Bryan B. Sent: Thu 2004-02-26 13:13 To: Stickler Patrick (Nokia-TP-MSW/Tampere); 'BRYAN.B.THOMPSON@saic.com '; 'www-tag-request@w3.org '; 'jon@hackcraft.net ' Cc: 'danny666@virgilio.it '; 'joe@bitworking.org '; 'www-tag@w3.org ' Subject: RE: HTTP Methods Ah. Got it. I don't see that as a shortcoming. If an agent is gathering service descriptions prior, e.g., to planning how to assemble some adaptive choreography, then there would naturally be a phase of gathering information, planning behavior, and the using that information to execute the behavior. -bryan -----Original Message----- From: Patrick.Stickler@nokia.com To: BRYAN.B.THOMPSON@saic.com; www-tag-request@w3.org; jon@hackcraft.net Cc: danny666@virgilio.it; joe@bitworking.org; www-tag@w3.org Sent: 2/25/2004 10:32 PM Subject: RE: HTTP Methods Having to make two requests to get back (typically) the same amount of information that a HEAD request would return is inefficient. It makes SW agents "second class citizens" of the web because they have to do twice as much work to get the information they need to function. Furthermore, while there are some approaches that can work to accomplish the equivalent behavior of MGET (albeit requiring multiple requests) such approaches break down when considering the behavior of MPUT, and MDELETE. Regards, Patrick -----Original Message----- From: www-tag-request@w3.org on behalf of ext Thompson, Bryan B. Sent: Wed 2004-02-25 17:52 To: Stickler Patrick (Nokia-TP-MSW/Tampere); 'www-tag-request@w3.org '; 'ext Jon Hanna ' Cc: 'Danny Ayers '; 'Joe Gregorio '; 'www-tag@w3.org ' Subject: RE: HTTP Methods I do see an opportunity for a "well-known" HTTP method for descriptions. However, what I like better is to use HEAD to recover a header, e.g., Service-Description-Uri, whose value is the URL of the service description. You can then negotiation the description content type separately. -bryan -----Original Message----- From: www-tag-request@w3.org To: ext Jon Hanna Cc: Danny Ayers; Joe Gregorio; www-tag@w3.org Sent: 2/25/2004 8:45 AM Subject: Re: HTTP Methods On Feb 25, 2004, at 15:28, ext Jon Hanna wrote: > > Quoting Patrick Stickler <patrick.stickler@nokia.com>: > >> >> >> On Feb 25, 2004, at 12:40, ext Jon Hanna wrote: >> >>> >>> ... I remain unconvinced of the case >>> for MGET. >> >> Can you demonstrate how the equivalent behavior can be >> implemented using the existing methods without resulting >> in either (a) multiple requests for each single logical >> operation or (b) unintended side effects in the case of >> misunderstanding between client and server, or (c) efficient >> and explicit failure if the request is not understood? > > I'll qualify "unconvinced" as meaning "I've only looked at this a tiny > bit, and > it didn't convince me" as opposed to "I've looked at this a lot and I > think > it's wrong". It's an uninformed instinct thing. > > That said, and given that URIQA is on my list of stuff I want to look > at in the > near future (but I've been putting it off until after my current paying > project) why not GET application/rdf+xml rather than MGETting? What if the resource denoted by the URI has an RDF/XML representation yet you don't want the representation of the resource, you want its description. Content negotation is about selecting between representations. While it might be possible to make it work for differentiating between representations and descriptions, it precludes the ability to select between different encodings of a description and also (even if a special MIME type is used for descriptions) does not make it possible to ask for descriptions of descriptions as opposed to a representation of the description itself. Patrick > Granted an attempt to do so will result in most servers sending you > text/html or > whatever and hoping for the best, but you can stop listening after the > headers, > it seems an explicit enough failure. > > -- > Jon Hanna > <http://www.hackcraft.net/> > "…it has been truly said that hackers have even more words for > equipment failures than Yiddish has for obnoxious people." - jargon.txt > > -- Patrick Stickler Nokia, Finland patrick.stickler@nokia.com
Received on Thursday, 26 February 2004 08:10:16 UTC