W3C home > Mailing lists > Public > public-sws-ig@w3.org > September 2005

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

From: Cutler, Roger (RogerCutler) <RogerCutler@chevron.com>
Date: Thu, 1 Sep 2005 08:44:57 -0500
Message-ID: <0C237C50B244FD44BE47B8DCE23A305277A0E8@HOU150NTXC2MC.hou150.chevrontexaco.net>
To: public-sws-ig@w3.org

>From a business perspective I would like to encourage you not to forego
incremental improvements in order to try for some "big solution".  In
practical terms the usefulness of eBusiness solutions is limited by the
cost of establishing the business relationships and by the cost of
"fixing" transactions that have gone awry in some way.  Anything that
involves people getting on the phone and hassling things out is
expensive, and anything that automates even small parts of that process
can have a big impact.

-----Original Message-----
From: public-sws-ig-request@w3.org [mailto:public-sws-ig-request@w3.org]
On Behalf Of Shi, Xuan
Sent: Thursday, September 01, 2005 7:56 AM
To: 'Carine Bournez '; 'Battle, Steven Andrew '
Cc: 'public-sws-ig@w3.org '
Subject: RE: FWD [Work in Progress on Semantics for Web Services (
Advance Notice)]
Importance: High

Dear Dr. Bournez:

I joined this working group and mailing list but cannot add my comments
into the archive. Maybe my opinion is not welcome but I hope more and
more people can understand what' wrong for those research approaches on
semantic Web services research when they are used in real world
development. I think I contacted you and many other W3C staffs,
directors and writers of OWL-S, WSMO, WSDL-S. I hope people in this
working group will not keep silence on those known problems.

In my opinion, the mechanism of OWL-S looks like a backward-engineering
process. Since WSDL is the outcome of OOP, then what OWL-S can do is
only restore the object hierarchy and relationship in the development
process of OOP. In this way, every object used in the Web services can
be associated with others under such framework but OWL-S cannot describe
the meaning of the objects used in the OOP. 

WSDL-S makes things worse since it only "adds" semantics onto certain
objects while remains the others undefined, that is to say, given the
example of Address Finder Web Service (URL can be accessed at:
http://arcweb.esri.com/services/v2/AddressFinder.wsdl ), WSDL-S would
only add semantics onto such WSDL elements like street, intersection,
city, state_prov, zone, country, user name, password, but ignore the
other elements such LocationInfo, ArrayOfLocation, Location[],
description1, description2, addressFinderOptions, token, matchType, etc.
just because they are not meaningful. Thus the whole WSDL file will be a
mess for requesters to understand and use. 

WSMO creates a conceptual model to describe the meaning of the service
and probably can be a useful approach to develop semantic Web services.
Unfortunately, WSMO by now has to "ground" to WSDL to connect both
systems together and to derive the service semantics. If WSDL is NOT the
appropriate source from which to derive data and service semantics, WSMO
just associates with a wrong object and thus cannot get the correct
result. Thus if there is no way to "ground" to WSDL, WSMO is useless as
a stand-alone framework.

In conclusion, the source of the problem in their research on semantic
Web services is that researchers just used some simple business
transaction models and then the whole process is simplified. That is to
say, all WSDL elements used in such simple models are intuitive and
self-understandable. However, given the example in Address Finder Web
Service, most of WSDL elements are meaningless, redundant, and
irrelevant to the users to set up a direct relation between the input
variables and output results. When we try to use such real-life cases to
test those mechanisms, then we can find the true problems. I tried to
CMU's WSDL2OWLS tool to convert the WSDL file of Address Finder Web
Service into OWL-S, the result is almost meaningless and users still
cannot understand the meaning of the service. Unfortunately, CMU's Web
site for testing their tool is down and maybe they just knew OWL-S
approach cannot solve the problem.

What's the semantics for Address Finder Web Service? The direct and
explicit meaning of this Web service is: if the user can provide user
name, password, and address information on street, city, state (or
province), zip/post code, then the service will return the location of
the input address.

I suggest that researchers should give up dealing with those simple
business transaction models. I know SWS now is a big "business" but
please test your approaches and see if your approach can describe the
meaning of "Address Finder Web Service". If it fails, you have to
consider what's wrong and reformat your approach. Don't tell people that
your approach can work find with credit card transaction, buy book,
ticket, purchase order, etc. etc.... They are just meaningless in the
real world.

Any comments and suggestions will be greatly appreciated. I hope W3C and
SWS committee members will not keep silence any more to this challenge
since many of them already knew the content of this message for a rather
long time. I look forward to hearing from you.

Best wishes,


-----Original Message-----
From: Carine Bournez
To: Battle, Steven Andrew
Cc: public-sws-ig@w3.org
Sent: 9/1/05 6:11 AM
Subject: Re: FWD [Work in Progress on Semantics for Web Services
(Advance Notice)]

On Thu, Sep 01, 2005 at 10:50:47AM +0100, Battle, Steven Andrew wrote:
> Carine,
> Can you shed any light on the decision here to establish a charter for
> new working group rather than - or perhaps in addition to - a lighter 
> weight incubator activity. The attendee poll at the FSWS workshop
> little enthusiasm for such a working group. What caused this shift in 
> opinion at the W3C? Steve.

Steve, all,

This "Advance Notice" is precisely aiming at gathering feedback about
the way to go. W3C Members are aware of lightweight process and should
react on member-ws@w3.org about this process. Thank you for raising this
Received on Thursday, 1 September 2005 13:45:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:32:48 UTC