RE: questions about applying DAML-S

Paul,

sorry for the delay of my answer, and thanks for your comments, they
are extremley welcome.

Kogut, Paul A writes:
 > 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.

This is a good question that I suspect will emerge more and more in
the future. The profile of DAML_S has a field called serviceCategory
which is used for this purpose.  

I think that the use of service category is very appealing during
matching, but the problem is that if the categories allowed in the
ontology are too broad, the use of service categories may result to be
almost meaningless.  On the other side, to make it meaningful you need
to specify many different classes one for each service type (Somebody
at a conference objected once that you need also to represent
combinations of services, but I am still not sure about that.)  The
use of inputs and outputs tries to circumvent that by allowing an
implicit definition of services.  With this I mean, instead
of describing a service as a ski-equipment-vendor, it is defined as a
service that takes money as input and returns skies as output.

The whole issue seems to me like another instance of the trade-off
between space and computation.  By allowing an implicit representation
we require less precise ontologies of services, but require more
careful description of the service and more complex matching.  As
David pointed out in his message, we are trying to support both ways
of matching since some fairly large ontologies and classifications of
services are emerging.  Also,  it is still far from clear which
trade-off will be better at the end, and which one actual users will
find more useful.

 > 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, indeed inputs, outputs, preconditions and effects do require a
class and not an instance.  This is to allow users to look for which
service sells skies (or to be precise instances of the class Sky), and
not for one specific pair of green skies.

What we are doing with UDDI is to map the DAML-S Service Profile into
UDDI so that it preserves the meaning of DAML-S.  This is something
like the WSDL mapping in UDDI records. 


Thanks for your comments,

--- Massimo

Received on Friday, 22 March 2002 18:16:51 UTC