(no subject)

Please see my comments inline below.

----- Original Message ----
From: Xuan Shi <Xuan.Shi@mail.wvu.edu>
To: public-sws-ig@w3.org; charl_abela@yahoo.co.uk
Sent: Thursday, 27 July, 2006 4:50:53 PM
Subject: Re:

 How about you can tell me and the others the role of service
provider in this case? 

Answer: in the scenario I depicted, person A is the pure requester, but person B starts as being a requester (i.e. wants to discover some service) and then uses this for his own needs (i.e. creates a new service description which includes both the hotel and the city-tour services) after which he advertises this new service with a service registry, thus he now becomes a service provider.

More specifically, please tell us:

Why WS developer for Hilton (hotel) can handle WS development of
American Airline? and why Hilton needs a composite service process.owl
for American Airline, and vice versa?

Answer: Looking at the scenario again: person B who is a developer, was commissioned to create a service for Fast_Travelling_Agency which required a way in which web agents (roaming for travelling services) could make hotel reservations and also choose to reserve a city tour over the web, i.e. without the clients coming over to the Fast_Travelling_Agency offices (it could also be the case that this agency does not actually have any offices where clients could go over and discuss travelling plans).

With an emphasis on service requester, we lose the focus on defining the
*semantics* of Web services. As McCool said in his paper published by
IEEE Internet Computing in the last issue of 2005 that until now, there
is no real service and there is no service semantics. Or you want to
tell me what's the *semantics* of a hotel reservation service in this
SEMANTIC Web services interest group?

Answer: I might not be understanding you completely here, as I said I am not an expert in the field, but am working on discovering and using new technologies to possibly make things easier for a software agent to identify some web functionality. Sorry I did not read that paper, but I think that when we say service semantics (someone can correct me if I'm wrong), we refer to some definition, in some language such as OWL-S or WSMO, which are machine readable. If we consider the hotel_reservation service, the inputs and outputs together with URI's to concepts in some ontology may help the agent to reason about the type of inputs that this service requires and thus whether the agent could supply them or not. In this manner the agent may or may not present this service to person A or B. For example if, for the sake of this argument, the person A does not have a visa-card which is one information that the hotel_reservation requires, then it is useless for  A's agent to present
 this service to him. 

If you read W3C documentation about OWL-S and WSMO, you may find that
only 1/4 of them is about service (provider) while the other 3/4 is
about service integration/aggregation/mediation. That's why I said it's
a mixture with a focus or stress on requester-side activities. But I am
interested in the *semantics* of service more than requester-side
modeling. So why I cannot indulge in this group because I have some
different ideas that challenge the faulties in the existing frameworks -
do you mean this SWS-IG is not for research on service *semantics*? 

Answer:Well, as I depicted the role of person B, he is both a requester and a provider (or else works for a provider: Fast_Travelling_Agency). And as I see it, a service provider, or the developer who is creating the service on his behalf is more interested in defining how his service will function. Now if the Fast_travelling_Agency, does not want to make the service machine readable (as in semantically enabled) then WSDL would suffice, but if the target of this agancy is to make it available for agents then it commissions person B to enrich the service with OWL-S or WSMO or the like.
I still don't understand which ideas you are making reference to. Can u perhaps use the scenario or else create one and make your ideas clearer?

Such existing frameworks look like that these people are developing
saddles (handling service semantics) before they have a horse (service
semantics). That's why I keep asking them questions and debating with
them for a long time, especially, why service provider can imagine and
handle service requesters' activities? For service providers, they just
have the following roles:

1. develop service
2. define service and share the service semantics
3. wait for service request
4. response for service request

Answer: I would say that develop and define are step 1. In which case the developer (who could or could not be the provider) has the option to create from scratch a service or to reuse one after submitting a request to some service registry.
Step 2 is advertise and share semantics.
I agree with 3 and 4.

Where is the place for integration/aggregation/mediation to the service
provider, i.e. varied modelings in OWL-S/WSMO? 

Answer: I think (again pls, someone correct me if I'm wrong) that aggregation/mediation are important when it comes to automating the discovery, composition and execution of services.

You and many others said that SWS are "all about associating the work
related with the Semantic Web to that of Web Services", I just wonder
when SW people develop the framework (RDF/OWL) to define the *semantics*
of the *concepts*, is there anything in this framework that describes
how to handle the processing of such *concept*? Can you and anyone tell
me how RDF/OWL defines a model to process the
integration/aggregation/mediation issues for people (requesters) who
process the concepts defined on the semantic Web?

I don't think that the requesters in this case are people but as I said earlier, these are mainly tools for agents. 

If RDF/OWL in SW is just a framework to *_define_* the semantics of the
concepts, why SWS framework like OWL-S/WSMO includes client-side
integration/aggregation/mediation modelings that are NOT for service
providers? As I asked Terry yesterday, if they are not based on
assumption, then where is the design from?

As for myself, I already proposed a new approach and framework for SWS
and it first emphasizes on the *semantics* of the service, 

what is your idea of the service semantics?

NOT about
client-side service integration - as a service provider, this is NOT my
business. As a service provider, I need to consider HOW to enable my
requesters to understand the service - this should be the focus of SWS
research as I think, and this has been the reason why I keep debating
with people in this group: the focus of SWS research - service semantics
(provider-side) vs. modeling integration process (requester-side). 

can you clarify your idea of provider and requester?

And obviously, we should have a horse first before we build saddles. It is
such a simple lesson but I just wonder why people just ignore it.

Unfortunately, my proposed approach is not good to too many people and
parties in this world. By the new approach, even there is no need for
WSDL but we can do the exactly same thing in a much easy and simple way
- WSDL people are unhappy as Dr. Haas told me even WSDL is still under
development. Also by the new approach, service provider communicates
with service requester through semantic interface or document, other
than programming interface (APIs) - then you know how many people are
unhappy about it (all existing approaches deal with the semantics of
APIs, other than the semantics of service). In the new approach, there
is no composite service - service providers have to encapsulate and
transform all kinds of composite services into atomic one. 

In this way,it enables dynamic invocation as defined by Dr. Burstein, which means,
if a service requester can indentify multiple services that performs
exactly the same service (through service discovery, matchmaking and
composition), the service requester can send exactly the same request to
ANY of these providers without considering the APIs differentiations on
the server-side. But unfortunately, you can understand how many people
are unhappy again to such a new approach, at least for OWL-S, there
won't be more space for modeling.

Answer: I cannot actually understand this argument, again can you supply a practical example of how your approach can make away with the complexity (cause defining services with OWL-S and WSMO is rather complex unless suitable tools are used) of the proposals submitted to W3C?



Regards

Charlie