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