RE: Difficulty with DAML-S

Charlie,

>As regards the IOPEs,
> When a requester agent queries a matchmaker then as a result the latter
would
> return information regarding a matched web service. This information would
> include the IOPEs which come from the service Profile and which the
> provider would have advertised with the matchmaker earlier. Correct?

That is correct.  In fact, typically, the matchmaker would return the
matching profile,
so the requester would not only have details about the IOPEs but also other
information
such as service parameters, ownership information etc.  That way, if there
are several
matches, then the service requester can use this information to refine its
choice of
service to use.

>As regards a service requester:
> So in practice the requester would already know about these IOPEs, what it
> doesn't know is the type of process, be it atomic or composite. If it is
> atomic then no intermediary steps are needed, and presented with the
> input the provider agent should present the output, but if it is composite
> then there has to be a continuous "consultation" with the process model
> to identify the workflow from the input to the output (with the
> possibility that the intermediary output of one atomic service is
> used as an output to the next atomic process in the sequence)
> until all the processes involved are executed.  Is this correct?

Yes, this is correct.

> So the process model would be a guide for the requester agent that
indicates
> to it which inputs it (requester) has to present and which outputs to
> pretend from an atomic process (from the provider). So in practice the
> requester must avail itself of an interpreter and a parser, so that with
> one it parses the process ontology and with the other it understands
> what to make out of this parsed structure. Correct?

This is correct.  In fact, the physical interaction (i.e. message formats
etc)
would be provided by the grounding (under development) which would be linked
to the process model.  So for a requester agent to be able to communicate
with
a service provider, it would need to be able to parse the process ontology
and
the grounding.

> Any suggestions of already available interpreters to use?
> Is it sensible to think of an interpreter as for example
> a group of java classes specializing in giving meaning to DAML constructs?

I don't believe that any interpreters have yet been released to the general
community
though I understand that such interpreters are being developed.

> So the parser/interpreter would be able to lead an agent to discover that
> the input for a certain service is a string and is referred to for example
> bookName. But how is the autonomous agent going to understand that the
> required output is the books name and not its ISBN? Also such a
> description in the requesters KB would not be described as bookName but
> as for example: bookTitle. How is this mapping handled? Or is this not
> in the scope of the DAML-S ontologies? Is there a solution for this
> problem? Or is this a million dollar question?

This is not the scope of DAML-S, per say, but the scope of DAML itself.  One
would mark up ones service using concepts within existing ontologies, i.e.
the
"bookname" you refer to would be a reference to the resource 'BookName'
within
some ontology.  This would be a different concept to the ISBN concept.
There
might be some relationships between the concept 'BookName' and the concept
'bookTitle' in different ontologies (i.e. sameClassAs or subClassOf, etc.)
which
would be used to map the concepts to each other.  Such logical relations are
used by the Matchmaker to identify semantic matches.

> As regards the service provider:
> the work of the provider is to advertise the service profile with a
> matchmaker, pass the required inputs into the web service's methods
> and pass the computed outputs to the requester. Is it not? Have I
> left something out?

Yes, you are right.  Although this assumes the middle agent you are using is
a matchmaker, i.e.
a yellow-pages styled registry.  There are other types of middle agent you
may use, such as a
broker middle agent, or wanted-ad's middle agents, where such behavior
differs.  For example, in
the wanted ad's middle agent, requesters would advertise their desire of
service, and providers would
then query the middle agent to locate matching requesters.


Terry
  -----Original Message-----
  From: www-ws-request@w3.org [mailto:www-ws-request@w3.org]On Behalf Of
Charlie Abela
  Sent: Thursday, January 10, 2002 12:26 PM
  To: www-ws@w3.org
  Subject: Difficulty with DAML-S


Hi All

I am trying to understand some fundamental issues associated with DAML-S and
am hoping that someone out there can help me clarify them.

As regards the IOPEs,
When a requester agent queries a matchmaker then as a result the latter
would return information regarding a matched web service. This information
would include the IOPEs which come from the service Profile and which the
provider would have advertised with the matchmaker earlier. Correct?

As regards a service requester:
So in practice the requester would already know about these IOPEs, what it
doesn't know is the type of process, be it atomic or composite. If it is
atomic then no intermediary steps are needed, and presented with the input
he provider agent should present the output, but if it is composite then
there has to be a continuous "consultation" with the process model to
identify the workflow from the input to the output (with the possibility
that the intermediary output of one atomic service is used as an output to
the next atomic process in the sequence) until all the processes involved
are executed.
Is this correct?

So the process model would be a guide for the requester agent that indicates
to it which inputs it (requester) has to present and which outputs to
pretend from an atomic process (from the provider). So in practice the
requester must avail itself of an interpreter and a parser, so that with one
it parses the process ontology and with the other it understands what to
make out of this parsed structure. Correct?
Any suggestions of already available interpreters to use?
Is it sensible to think of an interpreter as for example a group of java
classes specializing in giving meaning to DAML constructs?

So the parser/interpreter would be able to lead an agent to discover that
the input for a certain service is a string and is referred to for example
bookName. But how is the autonomous agent going to understand that the
required output is the books name and not its ISBN? Also such a
description in the requesters KB would not be described as bookName but as
for example: bookTitle. How is this mapping handled? Or is this not in the
scope of the DAML-S ontologies? Is there a solution for this problem? Or is
this a million dollar question?

As regards the service provider:
the work of the provider is to advertise the service profile with a
matchmaker, pass the required inputs into the web service's methods and pass
the computed outputs to the requester. Is it not? Have I left something out?

Regards



  Charlie