RE: FWD [Work in Progress on Semantics for Web Services (Advance Notice)]

Hi, David,

Thanks very much for your kind attention and advice. I hope my
straightforward comments will not make people in this group unhappy but
rather will promote more discussion about the semantic Web service research
and development. Even the saying like semantic Web services = semantic Web +
Web services is questionable.

In the paper "Potential Modeling And Simulation Applications Of The Web
Ontology Language - OWL" which can be found at:

http://www.informs-sim.org/wsc04papers/031.pdf 

the author discussed that " ... 

OWL was developed to support the Semantic Web. 

OWL provides web-ready object-oriented information representations with an
open vendor-neutral language. 

OWL is best used for representing object oriented descriptions of items in a
well-defined domain. 

The information representation constructs in OWL supports object-oriented
descriptions. 

OWL supports the definition of classes, individual instances, and property
relationships between classes, individuals, and properties.

..." 

It seems that such statements demonstrated that the current technologies
(OWL, etc.) can only define the "nouns" other than the "verbs". Thus OWL is
good at defining the object relatioship used in OOP in class-subclass
definition, but how can we define the meaning, behavior, and action of the
functions and services? Thus we need to consider how to expand such
methodology to define "verbs" (actions, behaviors, etc., i.e. the meaning of
services and funtions). 

Given the following example, how can we define the semantics (the meaning)
of such a Web service and function: 

select geospatial features from feature layer 1 that contain, or are 
contained by, the features in feature layer 2. 

The function interface can be described as: 

Function functionName (String polygonLayer1, String polygonLayer2) : 
String selectedPolygonFeatures 

This can be a typical interface to process geospatial data or perform 
spatial query. Moreover, the exactly same function: 

Function intersect (String polygon1, String polygon2): String polygon3 

can perform different tasks (spatial query vs. geoprocessing) and get 
different results. Then how can we use OWL to define such different purpose
and bahavior of such functions with the same name and interface?

Thanks to Naveen's kind attention and assistance, I can use CMU's WSDL2OWLS
tool now for testing again on the WSDL file - 

http://arcweb.esri.com/services/v2/AddressFinder.wsdl

The problem, I am not sure if anyone tried this sample, is that the users
need to first invoke another Web service to get a dynamically generated
authentication token and then they can use the AddressFinder Web services.
The problem is here again, how OWL-S and WSMO can describe such requirement
or meaning inside the Web services? That's to say, user name and password
are used to invoke another Web service which is the precondition to invoke
AddressFinder Web services?

Actually the user can have a global account then they can use such user name
and password to invoke any paid Web services. Such design complies with OOP
requirement but leaves the problem for creating semantic Web services. In
this example, "token" has the same meaning to the user but when we use
WSDL2OWLS tool to get the OWL file, we can find "token" is defined three
times because it is used in three functions.

Any suggestions to such examples?


-----Original Message-----
From: David Martin
To: Shi, Xuan
Cc: 'Carine Bournez '; 'Battle, Steven Andrew '; 'public-sws-ig@w3.org '
Sent: 9/1/05 2:44 PM
Subject: Re: FWD [Work in Progress on Semantics for Web Services (Advance
Notice)]

Hi Xuan -

Thanks for your comments.  You make some good points about OWL-S and 
other SWS approaches such as WSMO.  But it appears to me that you are 
giving an inaccurate picture of what OWL-S is about, so I would like to 
provide a clarification.  Your comments seem to be based on the 
assumption that OWL-S is only meant to be used in a 
"backward-engineering" style; that is, only meant to be used to annotate

pre-existing WSDL services, which were designed independently from 
Semantic Web approaches.

Here I only want to point out that OWL-S was not primarily conceived for

use in that "backward-engineering" style.  As Alois Reitbauer has also 
pointed out in a previous message, it is possible to employ Semantic Web

approaches in a forward-engineering methodology; that is, incorporating 
ontology-based semantics from the beginning in the design process.  A 
number of researchers have been working on this way of doing things, and

tying it in with widely used methods such as those based on UML. 
Furthermore, please note that WSDL-specified Web services are not 
mandated to use XML Schema to describe their inputs and outputs.  WSDL 
has extensibility mechnisms that allow for other "typing" mechanisms. 
Thus it is possible to imagine Web services that are "native speakers" 
of OWL (their inputs and outputs are exchanged using one of OWL's 
serialization syntaxes), which would largely address the gap that you 
describe between a WSDL and an OWL-S specification.

I hasten to add that no such services exist today, and furthermore there

are some unresolved difficulties.  (These have to do with the fact that 
OWL instances can be serialized in so many different ways, and there can

be ambiguity regarding how much content needs to be carried to 
adequately characterize an OWL instance.)  However, there has been a 
good deal of discussion about these difficulties, and I believe they can

be addressed.  Presumably this might be a topic of concern if any SWS 
standardization or pre-standardization activities materialize at W3C.

Finally I would like to add that there is no basis for your 
characterization that SWS is "big business".  There is a great deal of 
research interest in these technologies because the promise is so great,

but that's not at all the same as saying that it is "big business". 
(For instance, I do not know of any companies that are trying to ensure 
profits by trying to control the direction of SWS standardization 
activities.)  I am certain that Carine is only trying to make progress 
possible by considering some activities that would promote greater 
collaboration between those who are working on WS and those who are 
working on SWS, so that (among other things) we can make further 
progress towards addressing issues such as those that you raise.

Regards,
David Martin

Received on Friday, 2 September 2005 02:42:49 UTC