Re: agents

Terry,

Thanks very much for your advice. I did not claim something as you
imagined but got such impression from your previous discussion and
statement (you used such words - assume, assumption, etc. - too many
times). 

If *application developer* is not a clear definition, we may wish to use
the concept of *agent* if you agree. Then to my understanding, your
agent consumes the other services (or more specifically, WSDL services),
not generate new (WSDL) services. If this is correct, your agent (or
application developer) is a (WSDL) service requester, not provider.
Could you please clearly tell us whether your agent is a (WSDL) service
provider or just a (WSDL) service requester? Your claim is still not
clear yet (as you said - When I talk about a service provider, I am
talking about the entity that provides the service - WSDL service or
Web-based service).

If your agent is a (WSDL) service provider, I just wonder why does
service provider need to do planning stuff, as well as service
aggregation/integration? A (WSDL) service provider just publishes
service (as an agent), and then (this agent just) waits for service
request and send back service response. For example, you publish a hotel
reservation service. Why do you need to consider how your service will
be consumed by different service requesters? If process.owl is not based
on assumption, then you may wish to tell us where is the design from? In
case if any service requester that is not listed in your process.owl but
sends you a request, will your agent (service provider) response to the
request or not? If your answer is yes, this process.owl file seems
useless. If your answer is no, then you have to modify this process.owl
file to add more use cases in your planning. 

Again, service aggregation/integration is not the business of (WSDL)
service provider but something for (WSDL) service requesters (consume
the WSDL service other than generate new WSDL service). If you think
(WSDL) service providers should be responsible for service
aggregation/integration issues, then you have to tell us why service
providers should handle service requesters actions? If you agree that
service aggregation/integration is not the business of (WSDL) service
provider, then what's wrong with my statement that OWL-S is a mixture of
*service-related* issues other than service semantic definition -
actually I was wondering why OWL-S people ignored a message in this
mailing list if they were capable to answer the question - what are the
*semantics* of OWL-S process? See -

http://lists.w3.org/Archives/Public/public-sws-ig/2006Jun/0039.html

Regards,

Xuan




>>> Terry Payne <trp@ecs.soton.ac.uk> 07/25/06 10:51 AM >>>
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 16:10:09 UTC