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.

 > 
 > 2. Are there any conventions for naming DAML-S profile and process files?
 > The Congo and Bravo examples do not follow consistent conventions.

We did not develop any naming conventions for DAML-S profiles.  We
just follow the DAML conventions.  But any suggestions are welcome.

 > 
 > 3. We are having trouble deciding whether a "failure" is an output or an
 > effect.
 > The DAML-S tech overview says
 > "Effects are events that are caused by the successful execution of a
 > service."
 > The walkthrough says 
 > "Note that not all services have physical side-effects.  
 > In particular, services that are strictly information providing do not."
 > So if AeroDAML fails to return a markup file is this an effect?
 > Or is some form of error message an output?
 > What about if you get no error message and something just hangs?

I am still unsure about the role of failures in the service profile
and I expect that it will depend on how it will be used.  One of the
purposes of the service profile is service location, from that point
of view you want to search on the bases of what the service does, not
how the service fails.  Still, the service profile can also be used in
other ways (such as decide which service to use when there are ties
being one) and there the failures may become important.  We did not
address this problem in the service profile yet.  The process model of
DAML-S does contain the information on how to detect failures, so
services can look at what kind of failures may occur while interacting
with the service.

Thanks for your interest, and sorry for the delayed answer.

--- Massimo

Received on Thursday, 7 March 2002 10:52:09 UTC