RE: Semantics of WSDL vs. semantics of service

Harry,

Thanks very much for your kind attention and information to the debate. I
was impressed by your paper "The Semantic Web: The Origins of Artificial
Intelligence Redux" in which you said:

"The scale of the Semantic Web may aggravate instead of solve the problem.
With a decentralized method of creating knowledge representations, it
becomes increasingly difficult to guess what features of the world people
might formalize into an ontology. This will lead to many ontologies that are
about the same things, yet it will be unable to tell if the elements of two
ontologies are equivalent. Even if there was unambiguous
human-understandable documentation that showed two ontology elements to be
equivalent, the task of mapping between many small ontologies manually is
immense."

And that's the same concern about SWS. WS are decentralized systems. Since
we can develop the same services and functions in different ways, without a
standardized service semantic description document, everyone can describe
the same service in different ways. Especially adding semantic annotations
into WSDL document, I think it may be a trouble other than a solution, given
the examples of geocoding services offerred by ESRI, geocode.us, google
maps, etc. in different versions, approaches (SOAP and REST), etc. The
meaning of such services are the same while they can be deployed by
different interfaces. So your concerns about SW can be the same regarding to
SWS.

That's why I think we should standardize the way for semantic description
about the service and such standard can be deployed by either SOAP or REST
services if they are both in the definition of "Web services". For this
reason, the service semantics are neutral and independent from the service
development and can be shared by all service providers who,  then, do not
need to concern about the ontology or semantics issues individually. In
conclusion, I think we need a centralized coordination mechanism for such
decentralized Web services.

Best wishes,

Xuan

 

-----Original Message-----
From: Harry Halpin
To: '''public-sws-ig@w3.org ' ' '
Sent: 3/16/06 2:03 PM
Subject: 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:50:20 UTC