Re: Is there any logical conflict between the semantics in SW and that in SWS ?

hi Xuan,

i've sum'd up my view on Web Services and Semantic Web Services below. I
hope it helps you answering your own questions (regaring the meaning of the
word "semantics" in context of SWS)


THE RATIONALE BEHIND SEMANTIC WEB SERVICE MARKUP
---------------------------------------------------

A basic requirement for any (Web Service-) client to make use of Web
services is an understanding of the purpose and meaning of the operations a
Web service offers. Traditionally, this knowledge is directly injected into
Web service client programs by their *programmers* who read the syntactic
interface description and the text-based comments in the description
documents or in related documents in order to assess the semantics of the
various service operations.


The problem:
Inflexibility of Applications Hard-Wired to a Web service
-----------------------------------------------------------------

The downside of this approach is, however, that client applications
programmed  against a specific Web service interface can only solve a very
restricted set of problems using a very restricted set of problem solving
methods. This is not a problem if the services to be used by the
application rarely change, but it appears inadequate for many types of
applications that have to deal with dynamically changing service
environments. For instance, consider so called "Personal Information
Agents" or "Intelligent Agents" that have to aid the user  to solve certain
problems (e.g. to print out a document at the next printer available, or to
book a hotel room) that perhaps can not even know a priori what type of
service to use for what kind of task. Clearly, any application that is
programmed directly against a Web service in the fashion described above
will fail.


A first step towards a solution:
"Monolithic" Agreements on Service Semantics
-----------------------------------------------

Now, a first step towards more flexibility and the dynamic selection and
use of Web services is the definition of *standardized* service interfaces:
Parties with a common interest can jointly reach agreements on the
semantics of a set of syntactic descriptions. This is supported by the WSDL
standard, which allows for the decoupling of abstract service interfaces
(called "port types" in version 1.1) from concrete service *instances*; a
single port type description can be used as a basis for multiple service
instances, and if there is consensus about the semantics of the abstract
port type description, then consensus on the semantics of all of its
instances may be assumed.

Based on such agreements, client applications may be crafted that use those
Web services, and processes involving several services may be composed, for
instance using the BPEL4WS process description language.

*However*, a limitation of this approach becomes immanent when services
diverge from the initial agreements. For instance, when a service changes
its implementation (e.g. to refine its service offerings) its semantics and
probably its syntactic interface will change. Since there is no formal
machine interpretable connection defined between the semantics of a service
and its syntactic interface (given by WSDL), human intervention is needed
to decide whether the service is still compatible with the agreed semantics
or not!


More flexible:
Standarization based on Semantic Building blocks
----------------------------------------------------

A way of addressing this limitation is to write down a sufficiently large
part of the intended semantics of a service in a *formal machine
interpretable* fashion using some kind of semantically well defined
*building blocks* that can be assembled using some form of *semantic glue*
to capture service semantics. This idea was put forward by research
initiatives that developed semantic markup languages like OWL-S & co.:

In that approach, an agent only needs to understand
(i) the semantics of the various building blocks (which may or may not be
reusable across several services and domains)
(ii) the laws of the "semantic glue" which may be given by some action
theory,

The category (i) refers to terms like "credit card", "book", "restaurant",
"flight ticket", "buy", "sell", "pay", "user account", etc.

The category (ii), i.e. the "semantic glue", refers to things like
"precondition", "effect", "know-ledge effect" or "post-condition" etc. as
well as "and", "or", "not", "forall" and other logical operators.

Once you have an agreement on items in category (i) and (ii), you can
combine all those building blocks to describe AS MUCH SERVICES as you like
and a machine that is programmed to interpret those items correclty can
then AUTOMATICALLY deal with services described by such a concept.

As one can see, the building block-based concept gives machines the ability
to correctly intepret services WITHOUT human (programmer) intervention  -
*because* of the explcitely & formally written (and therefore
machine-interpretable) description of the service semantics using shared
conceptualizations and shared vocabulary.

hope this helps!

cheers
-- Joachim