RE: Internet/Distributed Computing using HTTP/POST: Bridge semantic W eb and Web services under the same Internet protocol

Xuan,
OK, I agree with the staging; that SOAP web-services resolve interop
problems syntactically (no mean feat by the way if you remember CORBA),
and WSDL (once you drop out of RPC mode) doesn't make it easy to figure
out the inputs and outputs in a big lump of schema.

>From here on in, my comments are going to be largely critical, but
hopefully constructive.

You say that, "OWL-S, WSMO, and others emphasize the process model for
service aggregation". I don't think so. This comes down to a confusion
of terminology. OWL-S cannot compose services, only processes that
ultimately break down into atomic processes that correspond to WSDL
operations. In other words, OWL-S only addresses compositions of actions
that can be performed at a _single_ service interface. It can't
describe, for example, how you can buy a book on Amazon then sell it on
eBay because these are two different services. WSMO is slightly
different in that addresses B2B relationships between peers with
web-service interfaces and whatever mediation you might need between
them as semantic glue - it's not really consumer facing in this regard.

You say that, "WSDL document can only reflect the content of OOP other
than the meaning of the data and services." However, you state at the
beginning that, "a service semantics is about the service tasks that
constitute the service" and "should be identified in a service
description" . WSDL is after all a web service description language and
therefore a suitable vehicle for semantic annotation that enhance the
current WSDL model.

You say that, "the service aggregation process does not provide the
semantic meaning of the services and such aggregations should not be
exposed to the service requesters who are waiting for an answer to their
request". I think you've misunderstood the subtlety of OWL-S process
modelling. An OWL-S process does not expose anything going on behind the
service interface, rather "it is a specification of the ways a client
may interact with a service" see
<http://www.daml.org/services/owl-s/1.1/overview/#5>. In other words,
every step of a composite process has to be performed by the client.
Certainly, you can consider not having a process model (as WSDL-S does)
on the understanding that you wouldn't be modelling the semantics of
dependencies between successive operations, nor the dataflows between
them.

This last objection undermines your case for your Semantic Request and
Response (SRR) approach which transforms composite processes into an
atomic one. Where this can be done, one may as well use BPEL because
you're talking about the service implementation rather than the
interface. Indeed, "the requester has no need to understand how the
provider processes the request" so this is uninteresting from the
perspective of modelling a shared semantics.

Steve.
 

> -----Original Message-----
> From: public-sws-ig-request@w3.org 
> [mailto:public-sws-ig-request@w3.org] On Behalf Of Shi, Xuan
> Sent: 20 January 2006 06:30
> To: 'public-sws-ig@w3.org '
> Cc: Shi, Xuan
> Subject: Internet/Distributed Computing using HTTP/POST: 
> Bridge semantic W eb and Web services under the same Internet protocol
> Importance: High
> 
> 
> My article "Internet/Distributed Computing using HTTP/POST: 
> Bridge semantic Web and Web services under the same Internet 
> protocol" is published by IBM DeveloperWorks and can be accessed at:
> 
> http://www-128.ibm.com/developerworks/library/ws-intdist/ 
> 
> Actually this paper discussed about two main issues: 
> 
> 1. Service aggregation processes should not be a part of the 
> service semantics. Please pay attention to the explanation to 
> the case of using www.expedia.com to buy ticket, reserve 
> hotel and rental car. Anyone who tried to use such online 
> services can be easily understand that the requester is 
> waiting for an answer other than a complex framework or 
> process model or mediator for service aggregation, etc. In 
> conclusion, service requesters do NOT care how service 
> providers process their request but only want to get an answer.
> 
> 2. Since all functions, offered by the so-called "Web 
> services", can be implemented directly by using HTTP protocol 
> without the need of any other extra frameworks like WSDL, 
> SOAP, etc., we can bridge semantic Web and Web services under 
> the same Internet protocol and unite both REST and WSDL Web 
> services within the same semantic service description 
> framework. WSDL can eventually be deprecated sooner or later 
> since at least it is not a must in developing semantic Web 
> services, if we now can find an easy and simple way to do the 
> exactly same thing.
> 
> While McCool talked about "Rethinking the Semantic Web" in 
> 2005 IEEE Internet Computing Issue Nov./Dec., I suggest that 
> we rethink about semantic Web services. Semantic Web 
> technology is designed for information search on the 
> Internet. SW targets at the static content inside the HTML document.
> However, as I said before, Web services are about functions 
> and actions. How can we use such a static technique to deal 
> with the dynamics in Web service, especially now, considering 
> I already demonstrated that service aggregation processes 
> should not be a part of the service semantics? Was it because 
> that we have to use logic to do something because logic 
> inference and ontology are the bases of semantic Web? Now 
> that we do NOT need to include any process of service 
> aggregation into service semantics description, whatelse can 
> be the role of logic or OWL in describing the meaning of the 
> functions and actions in Web services - remeber that 
> functions are not part of any existing ontology languages?
> 
> Any critical comments and advice will be greatly appreciated. 
> 
>

Received on Friday, 20 January 2006 13:16:33 UTC