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