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

RE: Comments on WSDL-S abstract

From: Shi, Xuan <xshi@GEO.WVU.edu>
Date: Tue, 22 Nov 2005 14:47:54 -0500
Message-ID: <D81F456794C18B4DA3E2ABC47DBBEEF2094E45@onyx.geo.wvu.edu>
To: "'Kunal Verma '" <verma@cs.uga.edu>, "'public-sws-ig@w3.org '" <public-sws-ig@w3.org>
Cc: "'martin@AI.SRI.COM '" <martin@AI.SRI.COM>

Since WSDL-S is calling for use cases, I'd like to provide the following
classical WSDL files for your kind attention and testing. I look forward to
seeing what kind of semantic annotations can be added into such WSDL
documents to describe the meaning of such services. Thanks very much in


By the way, I'd like to offer such information for your reference:

Web service http://arcweb.esri.com/services/v2/AddressFinder.wsdl has one
embedded Web service which should be invoked first.

Both of the Web services:

perform exactly the same functions via different interface. Thus they should
have the same service semantics.

As for WebService1-9 in the list above, at least one of them can geocode an
input place name and return the lat/lon of that place, and at least one of
them can convert lat/lon into UTM meters. These are the service semantics
for such Web services.

-----Original Message-----
From: Kunal Verma
To: public-sws-ig@w3.org
Cc: martin@AI.SRI.COM
Sent: 11/22/05 2:09 PM
Subject: Re: Comments on WSDL-S abstract

Dear David,

Thank you for your comments and valuable feedback. In principle, we
with many of your comments and understand the viewpoints you have
expressed. Detailed responses to your comments are given below. 

>> Hi Rama, Joel, John, Meenakshi, Marc-Thomas, Amit, and Kunal - >
>> Congratulations on the acknowledgement of the WSDL-S submission.
>> Since the submission abstract mentions some points of comparison with

>> OWL-S, I would like to offer some clarification and response
>> these points.  I have copied the abstract below (quoted) and I
>> inline.  My primary objective here is to avoid any misperceptions
>> might create unnecessary barriers to collaboration and synthesis of
>> WSDL-S with OWL-S.
>>> > Abstract:
>>> > The current WSDL standard operates at the syntactic level and
>>> > the semantic expressivity needed to represent the requirements and
>>> > capabilities of Web Services. Semantics can improve software reuse
>>> > discovery, significantly facilitate composition of Web services
>>> > enable integration of legacy applications as part of business
>>> > integration. The Web Service Semantics document defines a
mechanism to
>>> > associate semantic annotations with Web services that are
>>> > using Web Service Description Language (WSDL). It is conceptually
>>> > based
>>> > on, but a significant refinement in details of, the original
>>> > proposal [WSDL-S] from the LSDIS laboratory at the University of 
>>> > Georgia. In this proposal, we assume that formal semantic models
>>> > relevant to the services already exist. In our approach, these
>>> > are maintained outside of WSDL documents and are referenced from
>>> > WSDL document via WSDL extensibility elements. The type of
>>> > information that would be useful in describing a Web Service
>>> > the concepts defined by the semantic Web community in OWL-S and 
>>> > other efforts [METEOR-S, WSMO]. The semantic information specified
>>> > this document includes definitions of the precondition, input,
>>> > and effects of Web service operations. This approach offers
>>> > advantages over OWL-S.
>> First, the wording just above seems to imply (or could imply to some
>> readers) that WSDL-S is a competing approach with OWL-S, in the sense

>> that it could replace OWL-S.  Since WSDL-S does not define a semantic
>> model, it is potentially confusing to suggest this.  I suggest that
>> might say something like "offers advantages over the exclusive use of

>> OWL-S", but also further emphasize that OWL-S offers one particular
>> semantic model that could be referenced using WSDL-S elements.
 (Below I
>> suggest some specific, straightforward examples of how this could

>> Second, it seems odd to single out OWL-S in this regard.  As I
>> understand your points below, to the extent they are valid, they
>> equally to WSMO and other approaches that propose a particular
>> model.  Thus, I suggest it would be more helpful to the reader to say
>> something like "offers advantages over the exclusive use of OWL-S,
>> or other single-semantic-model approaches". 

You have a fair point here. Our intention was not to disparage or single
out OWL-S, a proposal from which some concepts like semantic
representation of preconditions and effects have influenced WSDL-S. Many

of the members of our team have used OWL-S in our research projects over
the past couple of years and that has helped us refine our thinking
WSDL-S and therefore this familiarity is inadvertently reflected in the

Your point is well taken. When we get an opportunity to revise,
we will revise the text to ensure OWL-S is not something that
is singled out (this email can be said to attest to that
intention). More to the substance, the key point here was that 
WSDL-S has a different center of gravity.  It looks at the issue of
semantics in Web services using existing approach as its base - WSDL and
XML Schema, and seeks to move the approach forward in a simple way.

>>> > First, users can describe, in an upwardly compatible way, both the
>>> > semantics and operation level details in WSDL-
>>> > a language that the developer community is familiar with. 

>> As expressed above, this claim (that semantics can be described "in
>> WSDL") is misleading.  As your abstract states above, the "formal
>> semantic models ... already exist ... and are maintained outside of
>> documents."  As the first sentence of your abstract states, WSDL
>> the semantic expressivity needed to represent the requirements and
>> capabilities of Web Services".  Just below, you claim that 
>> "externalizing the semantic domain models" is an advantage.  Claiming
>> that semantics can be described "in WSDL" is clearly inconsistent
>> these other claims.  I suggest that you shouldn't (and needn't) claim
>> have it both ways.

You are partially right here. The wording should be changed to say, we
capture the semantics using the extensiblity elements and not within

The point here simply was that by using the extensibility elements
WSDL' framework', we are able to support semantic annotation of WSDL

>>> > Second, by externalizing the semantic domain models, we take an
>>> > agnostic approach to ontology representation languages. This
>>> > Web service developers to annotate their Web services with their
>>> > choice of ontology language (such as UML or OWL) unlike in OWL-S.
>> There is indeed a substantive point here, and I agree it can be an 
>> advantage, for some purposes, to have the flexibility to refer to a
>> variety of semantic specifications.  For other purposes, however,
>> could be viewed as a distinct *disadvantage*.  For example, for Web 
>> service tool vendors who need to know what semantic models they need
>> support, it is distinctly unhelpful to stipulate that "anything
>> However, there is much to be said on both sides of that particular
>> and I won't dwell on it here.
>> Again, it's a bit puzzling as to why OWL-S is singled out in this
>> regard.  In fact, it is somewhat misleading to suggest that OWL-S
>> somehow precludes the use of other semantic models.  If you disregard

>> the WSDL extension tags proposed by OWL-S (which I discuss at the end
>> this message, and which can be regarded as optional), there is
>> in OWL-S that precludes the use of other semantic models.  That is,
>> OWL-S service description exists externally of WSDL, and is grounded
>> a particular WSDL service by specifying a mapping of certain OWL-S
>> constructs to certain WSDL constructs.  There's no reason in
>> why the same WSDL service, or other WSDL services used with it,
>> be described using other semantic models.
>> In any case, I suggest that it would be beneficial to the community
>> emphasize that OWL-S (or, more likely, some derivative "lite" version
>> OWL-S) and WSDL-S can potentially be used together.  For example, a
>> WSDL-S modelReference element attached to a WSDL operation could
>> to an OWL-S atomic process (and this would be perfectly consistent
>> existing practice in OWL-S, where the grounding ontology also
>> such mappings).  A WSDL-S modelReference attached to a WSDL input or 
>> output element could refer to an input or output of an OWL-S atomic
>> process.  A WSDL-S category element could reference a subclass of
>> Profile in a class hierarchy of OWL-S profiles.

We would be delighted to work with any member of the OWL-S team
to explore these connections-- just as we have (and continue to)
explore synergy with WSMO.

>>A WSDL-S schemaMapping 
>> element could refer to an XSLT script that OWL-S already uses to
>> a mapping between OWL-S input/output and WSDL I/O types defined in
>> schema.

We would like to point out that WSDL-S uses schemaMapping not just for 
upcast and downcast from XML to OWL and vice versa, but also to resolve
schema level heterogeneties between different different inputs
and outputs of services, which may be semantically homogeneous (refer to
same ontological concepts or concepts that are mapped to each other). In
our view, this is one of the most significant contributions of WSDL-S,
resolving such heterogeneties is the key for interoperability. For more 
details, please see Table 1 in Appendix D in the submission:

>>> > This is significant
>>> > because the ability to reuse existing domain models expressed in
>>> > modeling languages like UML can greatly alleviate the need to
>>> > separately model semantics. Finally, it is relatively easy to
>>> > the existing tooling around the WSDL specification to accommodate
>>> > incremental approach.
>> This final claim also is misleading.  For one thing, as I explain
>> OWL-S actually requires *less* change to tools that handle WSDL
>> specifications, because we have proposed only a few WSDL extensions
>> may be considered optional.  For another thing, it's pretty much a
>> point.  What you are suggesting, I think, is that a WSDL tool can
>> be updated not to choke on any of the proposed WSDL-S extension 
>> elements.  This is certainly true of WSDL-S proposed extension
>> as it is of OWL-S extension elements.  But of course it must be noted
>> that just by accepting the syntax of a proposed extension element,
>> aren't getting any new functionality.  To update a tool to actually
>> something useful* with the external semantic models, of course,
>> involves very substantial changes to the tool. 

We beleive that extension to WSDL tools will be minor. We already have
prototype for converting WSDL to WSDL-S : Radiant. Use cases are also
being posted. http://lsdis.cs.uga.edu/projects/meteor-s/downloads/

>> I grant, however, that a WSDL vendor could say, for example, "in our
>> next version we will support the use of the WSDL-S modelReference 
>> element attached to operations and referring to a UML diagram", and
>> that could be very nice for WSDL vendors.  But note that, by the same
>> token, the vendor could offer to support the use of modelReference 
>> referring to an OWL-S atomic process, or, for that matter, they could
>> offer to support the use of "owl-s-process" (an extension element
>> proposed by OWL-S) referring to an atomic process. 

Our point was that existing WSDL tools can be enhanced to support
annotations without creating a new way to view and create the Web
description.  As long as the domain ontology exists and can be viewed in
tool, the annotations can be created directly by referencing the
in the ontology. Your point that separate tools are required to create
domain models anyway is a valid one although, we think, people in the 
development community already accept this (eg: Many people use UML
modeling tools).

>> Finally, I would like to point out that OWL-S introduced the idea of
>> WSDL extension elements to refer to external semantic models with our

>> 0.7 release in Oct. 2002.  This is a public release and these
>> extension elements are also discussed in at least one conference
>> publication.  To my knowledge, this fact has never been mentioned in
>> publications associated with WSDL-S.  Granted, they are not
>> very much in OWL-S work, and are not developed very extensively, but,
>> nevertheless, they are there.  See, for example Section 6.2 in the
>> Technical Overview at
http://www.daml.org/services/daml-s/0.7/daml-s.html .

>> In summary, my main point here is that by and large WSDL-S and OWL-S
>> compatible, and most aspects of WSDL-S are already consistent with
>> approach supported by the OWL-S grounding.  No doubt some details
>> to be worked out, but I think we can benefit the community of
>> by working together on these details, and hopefully there will be
>> opportunities to do so  :-) .

Thanks again for your comments. We will integrate these exchanges into
next version. We look forward to the opportunity to work together.

The WSDL-S Team
Received on Tuesday, 22 November 2005 19:50:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:54:15 UTC