Re: Semantics of WSDL vs. semantics of service

(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