Re: questions about applying DAML-S

I would also add, to what Massimo and Sheila have said, that DAML-S
profiles also lend themselves to the construction of a class hierarchy,
reflecting service types.  At various places in the hierarchy,
additional properties can be introduced, which are specific for that
type of service.  For example, a RetailSale profile class might
introduce a formOfPayment property, and a RetailBookSale subclass (of
RetailSale) might introduce a bookTitle property.  These additional
properties can also be used by matchmakers.

Unfortunately, we don't yet have an example of a hierarchy of profiles,
but that's high up on our agenda...

-- David Martin
-- SRI International

Massimo Paolucci wrote:
> 
> 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 Friday, 8 March 2002 02:19:18 UTC