Re: Comments on WSDL-S abstract

Hi Kunal -

Thanks (a bit belatedly) for these comments and clarifications.  This is 
very helpful and I think we have a common perspective on these issues.

Regards,
David

Kunal Verma wrote:
> 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/ <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 
> <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, 29 November 2005 06:59:05 UTC