W3C home > Mailing lists > Public > www-ws-arch@w3.org > October 2002

Re: WSDL, RDF and REST

From: Mark Baker <distobj@acm.org>
Date: Fri, 11 Oct 2002 14:03:00 -0400
To: "Cutler, Roger (RogerCutler)" <RogerCutler@ChevronTexaco.com>
Cc: "'www-ws-arch@w3.org'" <www-ws-arch@w3.org>
Message-ID: <20021011140300.J8458@www.markbaker.ca>

Hi Roger,

On Thu, Oct 10, 2002 at 06:47:12PM -0700, Cutler, Roger (RogerCutler) wrote:
> Mark --
> 
> One of your responses to my posted question about objects in web services
> has gotten me thinking about something else.  I am by no means confident
> that this makes any sense, but let me give it a shot anyway:
> 
> It seems to me that one of the major points of difference between the REST
> folks and others that are less easy to characterize with one word has to do
> with verbs.  The web services folk are putting them into XML as data and the
> REST folk would prefer to have a limited set of verbs on which there is more
> or less universal consensus.
> 
> Would it be helpful if the Web Services architecture specified in some way
> that the list of verbs that are understood by a web service can be, or
> should be, semantically described via RDF in metadata that enhances the WSDL
> decription of the service?

You could certainly try.  And what you'd find by doing so would be quite
interesting.  But IMO, I don't think it would be helpful for deploying
Web services.

RDF is only good at relating things, for example describing tennis shoes
in terms of regular shoes, or baseballs in terms of balls.  For methods,
it works the same way; you need some other methods to compare them to.
Now, in order to keep these methods manageable (because they need to be
deployed a priori), what you would find yourself doing is generalizing
them as I previously described[1].  So for example, if the method was
"getStockQuote", you could use RDF to compare it to the meaning of
"getQuote".  But since deploying the meaning of any new method on the
Internet is expensive, it's more economical to just compare
"getStockQuote" to "GET", since it's more general and therefore the
advantages of deployment are spread out over more services (greater
network effects).

Now, once you've gone through the generalization exercise, you realize
that you don't need more specific methods than the base methods you've
identified, because you can use these base methods in HTTP to construct
messages that can accomplish the same tasks that the finer grained
methods were.

Thanks for trying to find a middle ground here, Roger, I appreciate it.
But unfortunately, there really isn't one (well, outside of using Web
services in a RESTful manner).

 [1] http://lists.w3.org/Archives/Public/www-ws-arch/2002Jun/0085

MB
-- 
Mark Baker, CTO, Idokorro Mobile.  Ottawa, Ontario, CANADA.
http://www.markbaker.ca             http://www.idokorro.com
Received on Friday, 11 October 2002 14:01:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:09 GMT