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

 

-----Original Message-----
From: Joachim Peer
To: public-sws-ig@w3.org
Cc: Shi, Xuan
Sent: 11/26/05 7:51 PM
Subject: 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



We may have certain agreement on our discussion if you would read our paper
"Rebuilding the Semantic Web Service Architecture" at the Web site:
http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS//Vol-140/ item
#3. The examples discussed in this paper demonstrated that machines have the
ability to correctly intepret services WITHOUT human (programmer)
intervention, i.e. automatic service discovery, matchmaking, composition,
and invocation. By adding or removing the Web services in the listbox in
that example, computer can "understand" whether it can perform certain tasks
and/or dynamically invoke the required service (if exists) for certain
purpose.

However, remember Uschold implied that what and how machine can process
depends on what and how human designs the procedures. To enable such
automation in semantic Web services, we need agreements or standards for
implementation.

The idea of separating service description from any technology for service
development originated from the concept of knowledge engineering in the
domain of AI. I cannot understand why people with AI background cannot see
its root. Maybe I used an old book "Artificial Intelligence - A Modern
Approach" published by Prentice Hall in 1995 ISBN # 0-13-103805-2. On page
219, it describes the difference between knowledge engineering and
programming.

Here it's the same analogy in semantic Web services. Service description is
a process of knowledge engineering while service development is a
programming process while WSDL contains the coding details as the result. I
hope Dr. Parsia could calm down and see the difference and let us know if
such an analogy is correct or not, and if such separation will enable the
service description document being implemented by multiple ways besides
WSDL/SOAP.

Received on Sunday, 27 November 2005 18:38:49 UTC