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:32:44 UTC