W3C home > Mailing lists > Public > www-ws@w3.org > March 2002

Re: FW: questions about applying DAML-S

From: David Martin <martin@AI.SRI.COM>
Date: Thu, 14 Mar 2002 13:04:39 -0800
Message-ID: <3C911067.AA65D62C@ai.sri.com>
To: "Kogut, Paul A" <paul.a.kogut@lmco.com>
CC: "'www-ws@w3.org'" <www-ws@w3.org>

"Kogut, Paul A" wrote:

> -----Original Message-----
> From: Kogut, Paul A
> Sent: Thursday, March 14, 2002 3:25 PM
> To: 'paolucci+@cs.cmu.edu'; www-ws-request@w3.org
> Subject: RE: questions about applying DAML-S
> Massimo,
> I would think that a much more scalable approach to matchmaking
> would be to look up a service by topic and then choose a specific
> service based on inputs, outputs, preconditions and effects.
> For example, when you are buying a ski helmet on the web you would
> first look for ski equipment, choose a vendor, then find out
> how to specify your size. You wouldn't search for a service
> whose input is size first. Maybe I am missing something.

Yes, that's also the view we are pursuing in DAML-S.  I tried to hint at that
in a recent message, but may not have been very clear.

> I would also think that instances of inputs, outputs, preconditions and
> effects
> in the DAML-S profile would reference classes and properties in upper
> ontologies
> or domain specific ontologies. For example, if you were buying a
> PC the processor speed input would be a property of computer with
> a value restricted to MHz. Maybe this is what you are doing with UDDI.

Yes, that's also consistent with our view.  Admittedly, however, our existing
examples do not make all of this as clear as it should be made.  (We're
working on this :-)

-- David

> Thanks,
> Paul
> -----Original Message-----
> From: Massimo Paolucci [mailto:paolucci@icarus.cimds.ri.cmu.edu]
> Sent: Thursday, March 07, 2002 9:37 AM
> To: www-ws-request@w3.org; paul.a.kogut@lmco.com; daml-process@bbn.com
> Subject: Re: questions about applying DAML-S
> Paul,
>  > All,
>  >
>  > We are trying to markup AeroDAML with DAML-S.
>  > Here are some questions:
>  >
>  > 1. I am wondering how you do semantic matchmaking when the
>  > profile only has a textDescription of the service.
>  > I was expecting to see an additional field like "semanticDescription"
>  > with words and relationships marked up based on
>  > upper ontologies or domain specific ontologies (e.g., the daml.org tool
>  > categories).
> The Service Profile part of DAML-S describes the semantics of a
> service.  The main idea is to describe a service on the bases of the
> function it computes. Specifically, a service is described by its
> input, output, preconditions and effects.  Where the idea is that a
> service transforms the inputs from users or other services into
> outputs, but also, it may require some preconditions to be satisfied
> and it may result in some effects that change the state of the service
> or of the people/services that interact with it.  A simple example of
> that of a service that reports stock quotes for a fee.  Such a service
> may take a ticker symbol and credit card number as input, and deliver
> a quote as output.  A precondition for the service is that the credit
> card be a valid one, and the effect is that the card is charged at the
> end of the service.
> At CMU we are developing a matching algorithm between profiles that
> uses DAML and matches between inputs and outputs (we intend to extend
> on preconditions and effects, but that requires a rule language that
> DAML do not support yet).  When you look for a service, you compile a
> profile of the service you desire, and submit it to a DAML-enabled
> registry.  The registry browses its DB of service advertisements and
> extracts only those services whose inputs match the inputs of your
> request, and whose outputs match the outputs of your request (I'll be
> happy to talk with you about the details of the algorithm, but I will
> skip them for now.)  As far a DAML-enabled registries, we are
> considering services like UDDI but with some semantic capabilities.
> We are currently experimenting with adding such a semantic matching
> capabilities to the UDDI registry by compiling DAML-S advertisements
> in UDDI records and then matching between them.  This is still work in
> progress, but we have some encouraging preliminary results.
> In addition to inputs, outputs, preconditions and effects, the DAML-S
> profile supports additional fields that allow requesters to constrain
> their search. Such fields allow requesters to specify the service
> category (B2B, B2C etc), resources that it may require, degrees of
> quality etc.  We allow for an extensible set of "service parameters"
> (much like the UDDI TModels).  These service parameters constrain the
> search, to prevent that the services returned satisfy your needs.
Received on Thursday, 14 March 2002 16:01:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:37:07 UTC