W3C home > Mailing lists > Public > public-ws-chor@w3.org > May 2003

Re: service type and the Semantic Web

From: Drew McDermott <drew.mcdermott@yale.edu>
Date: Wed, 14 May 2003 11:21:15 -0400 (EDT)
Message-Id: <200305141521.h4EFLFv04184@pantheon-po01.its.yale.edu>
To: public-ws-chor@w3.org

   Subject: service type and the Semantic Web
   Resent-Date: Tue, 6 May 2003 13:25:50 -0400 (EDT)
   Resent-From: public-ws-chor@w3.org
   Date: Tue, 6 May 2003 19:18:22 +0200 (MET DST)
   From: Stanislaw Ambroszkiewicz <sambrosz@IPIPAN.Waw.PL>
   To: public-ws-chor@w3.org
   CC: Stanislaw Ambroszkiewicz <sambrosz@IPIPAN.Waw.PL>

    >> Jon Dart wrote:
   > >> So service type is just a more generic term and a WSDL interface is
   > >> just part of the definition of that type.

   Consider two services; each of them performs one operation.
   Suppose that input data types of the two services are the same as
   well as the output data types.  Is it possible that these services
   perform different operations?

   If the answer is NO, then service type is hard-coded in the input
   and output data types.  It means that the pair of input and output
   data types determines the type of service.  It is a solution to the
   problem of service type.  The solution is of particular interest
   for procedural (imperative) approach to service composition, like
   BPEL.  Then, the type of composite service as well as the interface
   can be created automatically from BPEL code.  Please note that if
   the service type (proposed by Sanjiva Weerawarna) had been included
   in WSDL 1.2, then it would be hard or even impossible to create the
   interface of composite service automatically.  If I am not right,
   please let me know it.

   If the answer is YES, then it is clear that the service type is
   necessary, and there must be another means to express the type of
   service. The solution proposed by Sanjiva Weerawarna seems to be
   insufficient, i.e., something more is needed than just giving a
   name to a service type.  IMO the concept of service type is related
   to the more fundamental concept of meaning on the Web.  However, it
   seems that DAML-S did not succeed in achieving its ambitious goal;
   it was reduced more or less to WSDL + UDDI + BPEL.  Perhaps it is
   the high time to come back to the roots of the Semantic Web.

   Best regards,
   Stanislaw Ambroszkiewicz
   Polish Academy of Sciences          http://www.ipipan.waw.pl/mas/

The answer is clearly YES.  However, I doubt that the concept of
service type has much to do with "meaning on the Web," except for very
loose concepts of "meaning."  Expressing the type of service requires
that service providers and service requesters use the same language,
and that it can be shown that P->R, where P is the description
published by the provider, and R is the description posted by the
requester.  That is, the "broker" that brings the provider and
requester together should be able to verify that if the provider
provides a service satisfying P, it will satisfy R, this requester's
particular requirement.

This is a purely inferential task, and has nothing to do with
"meaning."  Of course, to prove that P->R, it may be necessary to make
use of background information (i.e., axioms) relating the terms of P
and R, but those axioms don't get us any closer to "meaning."

I think you're being too hard on DAML-S.  Its notion of _profile_ is
supposed to be an independent characterization of a service in a
formal language, namely, RDF + OWL (or its predecessors).  Because OWL
is a description logic, P->R becomes "class P subsumes class R."

Of course, the "roots of the Semantic Web" are always of interest, and
perhaps not grown as deeply as we'd like them to be, but one can
pursue service descriptions independently of the pursuit of better
foundations for the SW.

                                             -- Drew McDermott
					     Professor of Computer Science
                                             Yale University
Received on Wednesday, 14 May 2003 11:21:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:04 UTC