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

Re: agents

From: Terry Payne <trp@ecs.soton.ac.uk>
Date: Tue, 25 Jul 2006 16:51:17 +0200
Message-Id: <38019609-4447-4D35-B26E-F166B130639E@ecs.soton.ac.uk>
Cc: Terry Payne <trp@ecs.soton.ac.uk>, <burstein@bbn.com>, <jpsequeira@netvisao.pt>, <public-sws-ig@w3.org>
To: "Xuan Shi" <Xuan.Shi@mail.wvu.edu>

Xuan,
	
On 25 Jul 2006, at 15:42, Xuan Shi wrote:

> 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?...

That is one huge leap of faith there.  My statement you quote above  
refers
to the idea that a provider doesn't know at development time who the  
requesters
will be at run time.  I'm sorry, but I fail to see how from this  
idea, one can then claim
that therefore OWL-S is completely 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:

Steady on.  Again, I made no statement about what OWL-S currently  
does; it
is a research effort that is continually evolving, that can achieve  
some things,
but that will need further research to achieve others.  All I meant  
was that
when we started developing OWL-S, *some* (not all) of the motivations  
behind
its design came from the idea of dynamically discovering and utilising
services by agents at runtime (yes, without having to get a human  
developer
in to modify code).


>
> 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...

Forgive me, but I find it interesting that you claim to have a better  
understanding
of what I meant than I do.  When I talk about a service provider, I  
am talking
about the entity that provides the service; for example, in the  
examples available
from the OWL-S pages, I would be talking about "Congo" who provides  
the "Congo-buy"
service.

Also, please clarify - by "application developer", did you mean a  
human programmer?  Because
the example I gave was (again) at run-time, where the *provider*  
might re-assess what
services it can present to requesters, for example, based on  
available resources.


> ...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.

I think the problem is that you're getting very confused; and making  
some overly
strong claims here.  Before you throw out any more questions, you  
should reassess
the claims you are making, as I suspect these might in part be  
responsible for you
confusion.

	Terry

>
> 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
>
>


_______________________________________________________________________
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 14:51:36 GMT

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