Re: Semantics of WSDL vs. semantics of service

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 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.

   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? As Bijan notes, this seems to require 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?

   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 as its done
done it's a semantic web service.

So yes, that's *a lot* of work. Therefore, I highly doubt anyone has the
*one right answer.* But, doing as Xuan Shi's doing and 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

Shi, Xuan wrote:
> Bijan,
>
> Thanks for your comments. I'd be happy to show you the nakedness of OSRR so
> you can examine it at anywhere by any approach. At least I am glad to see
> you agree now OSRR is not just an assertion or lier but can be implemented
> by either SOAP or REST services without confusion and obscurity.
>
> Best wishes,
>
> Xuan
>
> --
>
> Actually, what I hate is lies, distortion, confusion, obscurity, and 
> bogus reasoning.  Look to your own nakedness.
>
> Cheers,
> Bijan.
>
>
>

Received on Thursday, 16 March 2006 19:03:14 UTC