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

FW: questions about applying DAML-S

From: Kogut, Paul A <paul.a.kogut@lmco.com>
Date: Thu, 14 Mar 2002 15:46:24 -0500
To: "'www-ws@w3.org'" <www-ws@w3.org>
Message-id: <079B626B05A0D3118B1000508B0EA5E90B0890F6@emss04m05.ems.lmco.com>

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


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.

I would also think that instances of inputs, outputs, preconditions and
in the DAML-S profile would reference classes and properties in upper
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.


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


 > 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 15:46:37 UTC

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