RE: Comments on WSDL-S abstract

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
advance!


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


http://157.182.136.51/agswsprojs/geoWebService/Service1.asmx?WSDL 
http://157.182.136.51/agswsprojs/geoWebService/Service2.asmx?WSDL 
http://157.182.136.51/agswsprojs/geoWebService/Service3.asmx?WSDL 
http://157.182.136.51/agswsprojs/geoWebService/Service4.asmx?WSDL 
http://157.182.136.51/agswsprojs/geoWebService/Service5.asmx?WSDL


http://157.182.136.76/AItest/ws/WebService1/Service1.asmx?WSDL 
http://157.182.136.76/AItest/ws/WebService2/Service1.asmx?WSDL 
http://157.182.136.76/AItest/ws/WebService3/Service1.asmx?WSDL 
http://157.182.136.76/AItest/ws/WebService4/Service1.asmx?WSDL 
http://157.182.136.76/AItest/ws/WebService5/Service1.asmx?WSDL 
http://157.182.136.76/AItest/ws/WebService6/Service1.asmx?WSDL 
http://157.182.136.76/AItest/ws/WebService7/Service1.asmx?WSDL 
http://157.182.136.76/AItest/ws/WebService8/Service1.asmx?WSDL 
http://157.182.136.76/AItest/ws/WebService9/Service1.asmx?WSDL



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:

http://157.182.136.51/agswsprojs/geoWebService/Service4.asmx?WSDL 
http://157.182.136.51/agswsprojs/geoWebService/Service5.asmx?WSDL

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
agree
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
regarding
>> these points.  I have copied the abstract below (quoted) and I
respond
>> inline.  My primary objective here is to avoid any misperceptions
that 
>> 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
lacks 
>>> > the semantic expressivity needed to represent the requirements and
>>> > capabilities of Web Services. Semantics can improve software reuse
and
>>> > discovery, significantly facilitate composition of Web services
and 
>>> > enable integration of legacy applications as part of business
process
>>> > integration. The Web Service Semantics document defines a
mechanism to
>>> > associate semantic annotations with Web services that are
described 
>>> > using Web Service Description Language (WSDL). It is conceptually
>>> > based
>>> > on, but a significant refinement in details of, the original
WSDL-S
>>> > 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
models
>>> > are maintained outside of WSDL documents and are referenced from
the 
>>> > WSDL document via WSDL extensibility elements. The type of
semantic
>>> > information that would be useful in describing a Web Service
encompass
>>> > the concepts defined by the semantic Web community in OWL-S and 
>>> > other efforts [METEOR-S, WSMO]. The semantic information specified
in
>>> > this document includes definitions of the precondition, input,
output
>>> > and effects of Web service operations. This approach offers
multiple 
>>> > 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
you
>> 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
work.) 
>
>

>> 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
apply
>> equally to WSMO and other approaches that propose a particular
semantic 
>> 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,
WSMO,
>> 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
around
WSDL-S and therefore this familiarity is inadvertently reflected in the
writeup. 

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
WSDL 
>> documents."  As the first sentence of your abstract states, WSDL
"lacks
>> 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
with
>> these other claims.  I suggest that you shouldn't (and needn't) claim
to 
>> 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
WSDL.

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


>>> > Second, by externalizing the semantic domain models, we take an
>>> > agnostic approach to ontology representation languages. This
allows 
>>> > 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,
this
>> could be viewed as a distinct *disadvantage*.  For example, for Web 
>> service tool vendors who need to know what semantic models they need
to
>> support, it is distinctly unhelpful to stipulate that "anything
goes".
>> However, there is much to be said on both sides of that particular
issue 
>> 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
of
>> this message, and which can be regarded as optional), there is
nothing
>> in OWL-S that precludes the use of other semantic models.  That is,
an 
>> OWL-S service description exists externally of WSDL, and is grounded
to
>> a particular WSDL service by specifying a mapping of certain OWL-S
>> constructs to certain WSDL constructs.  There's no reason in
principle 
>> why the same WSDL service, or other WSDL services used with it,
cannot
>> be described using other semantic models.
>>
>> In any case, I suggest that it would be beneficial to the community
to 
>> emphasize that OWL-S (or, more likely, some derivative "lite" version
of
>> OWL-S) and WSDL-S can potentially be used together.  For example, a
>> WSDL-S modelReference element attached to a WSDL operation could
refer 
>> to an OWL-S atomic process (and this would be perfectly consistent
with
>> existing practice in OWL-S, where the grounding ontology also
specifies
>> 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
define
>> a mapping between OWL-S input/output and WSDL I/O types defined in
XML
>> 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,
since
resolving such heterogeneties is the key for interoperability. For more 
details, please see Table 1 in Appendix D in the submission:
http://www.w3.org/Submission/WSDL-S/ 

>>> > 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
update
>>> > the existing tooling around the WSDL specification to accommodate
our
>>> > incremental approach.
>>
>>
>>
>> This final claim also is misleading.  For one thing, as I explain
above,
>> OWL-S actually requires *less* change to tools that handle WSDL
>> specifications, because we have proposed only a few WSDL extensions
that 
>> may be considered optional.  For another thing, it's pretty much a
moot
>> point.  What you are suggesting, I think, is that a WSDL tool can
easily
>> be updated not to choke on any of the proposed WSDL-S extension 
>> elements.  This is certainly true of WSDL-S proposed extension
elements,
>> 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,
you 
>> aren't getting any new functionality.  To update a tool to actually
*do
>> something useful* with the external semantic models, of course,
likely
>> 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
yes,
>> 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
services
description.  As long as the domain ontology exists and can be viewed in
a 
tool, the annotations can be created directly by referencing the
concepts
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
proposed
>> extension elements are also discussed in at least one conference
>> publication.  To my knowledge, this fact has never been mentioned in
any 
>> publications associated with WSDL-S.  Granted, they are not
emphasized
>> 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
are
>> compatible, and most aspects of WSDL-S are already consistent with
the
>> approach supported by the OWL-S grounding.  No doubt some details
need 
>> to be worked out, but I think we can benefit the community of
interest
>> 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
our
next version. We look forward to the opportunity to work together.

Thanks,
The WSDL-S Team

Received on Tuesday, 22 November 2005 19:50:53 UTC