W3C home > Mailing lists > Public > public-sws-ig@w3.org > July 2006

Re: agents

From: Xuan Shi <Xuan.Shi@mail.wvu.edu>
Date: Tue, 25 Jul 2006 09:42:38 -0400
Message-Id: <s4c5e7af.086@WVUGW01.wvu.edu>
To: <trp@ecs.soton.ac.uk>
Cc: <burstein@bbn.com>, <jpsequeira@netvisao.pt>, <public-sws-ig@w3.org>

Terry,

Thanks for your comments. But I still have to ask you some questions.

You wrote:

"There are few, if any assumptions you can make about the requesters who
will consider, and consequently consume your service. ....."

My questions:

Do you mean that OWL-S is all based on assumptions? If I "should assume
that a service is an encapsulated entity, that can be  used in
isolation, as well as composed / aggregated by some third party", as you
said, do you mean we also need to use statisitcs to assume the
propability for different client-side use cases before we prescribe a
process.owl? How can you imagine which use case is permmisible and which
one are not? If OWL-S is based on such prescribed assumptions, then the
intelligence within your agent is limited and cannot handle any unknown
use cases beyond your assumption.

You wrote:

"But OWL-S was also designed (and originally motivated) to support 
automated utilization of services by intelligent Agents; i.e. where
there is no programmer at all in the loop".

My questions:

Dr. Mark Burstein has an interesting paper "Dynamic Invocation of
Semantic Web Services that Use Unfamiliar Ontologies" published by IEEE
Intelligent Systems. July/August, 2004. In his article, he said the
dynamic invocation of Web services is characterized as "without any
reprogramming, a software system could have the flexibility to use
various services that do the same kind of job but have different APIs".
I think "automated utilization" can be referred to his concept of
"dynamic invocation". Here, the key is "without any reprogramming".

Do you believe OWL-S enables dynamic invocation or automated utilization
of Web services without ANY reprogramming? I don't believe it as you can
find in my previous posts:

http://lists.w3.org/Archives/Public/public-sws-ig/2006Apr/0042.html
http://lists.w3.org/Archives/Public/public-sws-ig/2006Apr/0048.html

What OWL-S can achieve may just terminate at a composition stage. As I
said in those two emails, assuming we can identify those 4 Web services
that perform the same function based on OWL-S composition, then how can
anyone dynamically invoke these services without ANY reprogramming? For
example, two of those 4 address geocoding Web services have exactly the
same function and interface structure but different interface names
while the other two have completely different interfaces, perfectly
matches Dr. Burstein's description - do the same kind of job but have
different APIs.

How can you invoke those two ESRI service to retrieve tow different
objects (GeocodeInfo vs. LocationInfo) without ANY reprogramming? Is
such conclusion also based on assumptions?


You wrote:

"Process models can be used for a number of reasons.  For example, a
service provider may model *many* processes, and through planning, or
perhaps a tool used by the providers human owner to configure the
offered services, to assemble a set of legitemate processes that can
then be published." ......

My questions:

I think you change or transform the terminologies again in your
assumption. Obviously the "service provider" in your case is an
application developer, and thus in Web service terminology, you are
talking about a service requester, not provider. Then it goes back to
the beginning of my questions to Dr. Burstein. I hope OWL-S people can
clearly clarify the two different concepts: service provider and service
requester, otherwise we have to make corrections to enable others
understand when you are talking about a "Web" service provider, when you
are talking about an application developer (also a service provider in
your term) but actually you refer to a service requestier.

Regards,

Xuan







>>> Terry Payne <trp@ecs.soton.ac.uk> 07/25/06 4:09 AM >>>

On 24 Jul 2006, at 20:11, Xuan Shi wrote:

>
> Once a service provider publishes a service, how can the provider know
> which, whether, and how service requester will consume this  
> service? ...

It doesn't know.  It can't!

> ... A
> service provider does NOT know whether the requester will only consume
> this single service or will consume this service with many other
> services. So how can you prescribe a process.owl file for your service
> requesters when you develop a service?

There are few, if any assumptions you can make about the requesters who
will consider, and consequently consume your service.  All you can do is
represent the service such that a requester then has sufficient  
detail to be
able to utilize the service, without a priori information about the  
specific
service instance in question (by a priori, I mean that the  
implementation of
the requester does not assume any knowledge of the providers service,  
and
the only knowledge available is that in the OWL-S declarations).

> Just as you said, "The OWL-S files are intended to be consumed by  
> OWL-S
> client", how can service providers determine and control whether this
> specific service can be used in whatever process model on the
> client-side? For example, how can a rental car service provider know
> whether or nor this service will be consumed by a service requester  
> who
> will just want to find a rental car, or who will also want to book an
> airline ticket, or more want to reserve a hotel, and more want to  
> get a
> ticket packet for Disney World?

Some of these are good questions that need to be addressed.  However,  
you
should assume that a service is an encapsulated entity, that can be  
used in
isolation, as well as composed / aggregated by some third party.


> The process.owl tries to describe or mimic the client-side activity  
> for
> a specific service requester. How a service provider can model or
> imagine all possible client-side behaviors? Service
> integration/aggregation is not the business of service provider.

It can't model all client-side behaviors per sey, but model a set of
permissible client-side behaviors that a client could use to access
the service.

>
> As for service requesters (i.e. application developers who integrate 1
> or many services together to serve the end-users), is it necessary to
> have such a process model? Then please see the following question:


Yes.  Look, don't make the mistake of thinking that the OWL-S model  
is simply
provided to some back-room programmer who is writing code to aggregate
services.  Sure, SWS, along with appropriate tools can greatly  
facilitate the
development of applications constructed from composed services, or via
higher level workbenches (such as the myGrid Taverna workbench used
by bioinformatitcans) for users who need simple tools for workflow  
construction.
But OWL-S was also designed (and originally motivated) to support  
automated
utilization of services by intelligent Agents; i.e. where there is no  
programmer
at all in the loop.  In this case, one needs a detailed, knowledge- 
rich model...

>
> Whom do you want to present such a "process model"?
>
> --1. To the service provider? The provider does not care about and
> control how requesters integrate the service for whatever purpose. As
> for provider in this case, if the preconditions are satisfied, it will
> invoke the service and return the result to you otherwise fail.
> --2. Or do you want to present the process model to yourself - service
> requester? It's strange as you know what you are doing (You may be
> wondering why you show it to yourself).
> --3. Or do you want to show the model to your client - the end-user?
> It's ridiculous as I said before - the end-users (they may not be CS
> professionals) are waiting for a result, not the process details of  
> how
> you hire subcontractors and how your subconstractors accomplish the  
> task
> for you.

Process models can be used for a number of reasons.  For example, a
service provider may model *many* processes, and through planning,
or perhaps a tool used by the providers human owner to configure
the offered services, to assemble a set of legitemate processes that can
then be published.

A more important issue is the one raised in point 3 - it might be  
essential for
a client to know whether or not the provider delegates part of the  
process to
a third party.  For example, my agent may be prepared to trust your  
service,
but not the third party you use to validate my credit card details.   
By being able
to inspect the process model, my agent can determine if it should use  
your service!

The bottom line is that if you're looking at sws purely from a  
programmer perspective,
then it can come over as heavy weight.  But if you consider wider  
issues of distributed
computing, and especially those issues that have been addressed by  
the Distributed AI
and Multi-Agent system community for the last twenty years, then many  
of the motivations
behind OWL-S make much more sense!

	Terry

>
> So, why they must be available on the web?
>
>>>> Mark Burstein <burstein@bbn.com> 07/24/06 11:21 AM >>>
> ......
>
> The process model must provide precise
> semantic correlates for all inputs and outputs that are possible in
> the WSDL messages that they correspond to, and must link these data
> to the corresponding preconditions and effects so that a service
> requester can mechanically determine whether and how it will provide
> the correct inputs and interpret the resulting outputs.
>
> ......
> The OWL-S files are intended to be consumed by OWL-S client agents
> that are then able to call the described services. So they must be
> available on the web.
>


_______________________________________________________________________
Terry R. Payne, PhD.        | http://www.ecs.soton.ac.uk/~trp/index.html
AgentLink III Co-coordinator    | AgentLink III - http:// 
www.agentlink.org
University of Southampton    | Voice: +44(0)23 8059 8343 [Fax: 8059  
2865]
Southampton, SO17 1BJ, UK | Email: terry@acm.org / trp@ecs.soton.ac.uk
Received on Tuesday, 25 July 2006 13:43:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 16 March 2008 00:11:05 GMT