- From: Harry Halpin <hhalpin@ibiblio.org>
- Date: Thu, 16 Mar 2006 11:56:04 -1000
- To: public-sws-ig@w3.org
(posting again due to my inability to format on my archaic Zaurus! - apologies!) Oh dear, Perhaps we could clarify the issues on a point by point basis, and also agree on things that are really not up for being argued? Assumptions: 1) Semantics as encoded by OWL/RDF is potentially a *good thing* for Web Services. (As to avoid the whole "let's keep in all in vanilla XML" argument we had a while back...) 2) WSDL and SOAP are necessary for many kinds of Web Services, particularly those that define things more complex that HTTP PUT a document and HTTP GET a document back in REST-style. So "deprecating" them or ignoring WSDL/SOAP is out of the question. Now, the questions I *think* Shi Xuan is trying ask: 1) Should we restrict ourselves to WSDL? - I'd guess we have no choice to *at least* provide semantics for people that use WSDL, if we want to describe composition of processes/services that you just can't do in a simple REST architecture. 2) Is there an abstraction that fits on top of both SOAP and REST? Could we add semantics to that? - Again, I throw off the rather vague "typed functions" idea, which I am working on making less vague. But, there's no reason *not* to start with the more complex case, SOAP first. The least complex case of just throwing documents around using HTTP seems like you could almost get away with just a good-old-fashioned hack: you can always put RDF direct in the XML via GRDDL,and one could imagine putting a simple RDF vocabulary for inputs and output of services as the output of a GRDDL process. 3) Should we describe the semantics of the process/service composition/orchestration or just the input and output types, or both? - Why not both? this would obviously be useful. As Bijan notes, this requires WSDL, SOAP, etc in complex cases, and so mapping these things to RDF among other things. Re: Battle's post, it seems we have to at least describe the service composition, which OWL-S does. But where do we draw the line at the most we want to describe? Just constraints, and then solve over those constraints? Or to actually, as Battle pointed out, BPEL-style, actually execute the darn things? Then to what level should we distinguish the types of things we're adding semantics to? Could we develop a "Semantic Web Services" cake diagram? 4) Should we put the mappings in the document or out the document? - Again, why not both? I think what will be easier depends on the users,and when it's done regardless of the technique it's a semantic web service. The crux of the question would be good use cases for either *putting annotations in the WSDL ala WSDL-S* and uses cases for keeping it outside ala *OWL-S.* So yes, that's *a lot* of work. Therefore, I highly doubt anyone has the *one right answer.* But, Xuan Shi's decrying SOAP and WSDL or using RDF/SemWeb is generally not up for grabs and not productive. However, his other question, about how we can simplify and make this useable over non-SOAP services, is interesting, and would be useful. I suspect that's where he's trying to go with his OSRR talk...but maybe not. I'll read the documents first :) (hand-waving,trying to steer conversation away from flame-war...) -harry
Received on Thursday, 16 March 2006 22:01:24 UTC