(no subject)

Charlie,

You ask me why, then I have to say, this SWS-IG is about research for
semantic Web services (SWS), not just for OWL-S as you said there are
many other alternatives. As we understand, Web services have three
roles, service provider, service requester, and service registry. The
problem here is, I am concerned MORE about service providers, OWL-S/WSMO
(and maybe yourself also) focus on service requester. In your message
below, if there is no mistake, you just discussed the role of
requesters. How about you can tell me and the others the role of service
provider in this case? 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?

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?

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

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

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

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?

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

So why I indulge in arguments over the list? Because this is a place for
discussing semantic Web services (not a group for OWL-S, etc.). I just
want to do something as you suggest - building over ideas, extending
ideas, identifying innovative ideas, accepting healthy critism and also
backtracking and identifing where an argument has become faulty, for
example, at least I think process.owl is just a faulty for service
providers - untill now, nobody would like to answer the question
mentioned above. Since OWL-S is submitted to W3C, it has to be examined
comprehensively and it response to any query and criticism, not just
keep silence and ignorance to its problems or faulties. Do you think
they want to accept criticism and backtrack/identify their faulty? The
problem and question have been here for a long time but do you think
they want to remove process.owl from its framework? If not, just keep
silence and ignorance but I will ask the question again, why service
provider need it?

I like healthy and rational discussion but unfortunately, as some people
told me off-the-list, someone(s) just talk in this group without manner.
So you should suggest to set up a moral commitee in this group to
supervise such issues.

Regards,

Xuan

>>> Charlie Abela <charl_abela@yahoo.co.uk> 07/26/06 12:12 PM >>>

Hi,

I just want to express MHO on some arguments being treated in this list.
I don't consider myself an expert in neither of the areas of Web
services and Semantic Web, but my impression was that a mailing list
such as the Semantic Web Services-interest group is all about
associating the work related with the Semantic Web to that of Web
Services...thus trying to enrich a Web service description so that an
agent can be lead to discover and execute the service with as little
human intervention as possible.

It is my understanding that a service requester could be:
1. a person A who instructs his agent (somehow) to find a particular
service: e.g. a hotel reservation service, this person I label as a
common web user
2. a person B who again instructs his agent to find a service, e.g.
hotel reservation, which can be aggregated with another service, eg.
city_tour reservation, thus providing a more useful function, this
person I label as a service developer apart from also being a service
requester.

In the first instance person A may not know exactly the best way in
which to find such a hotel service, thus his request is only partially
defined, and as such his agent has to perform much work. Most probably
in the initial results list, there are services which only patially
satisfy his needs. But with some refinement (this being as little as
possible, so that the service browsing experience is not a bore) a list
of the most suitable services is retrieved and presented to person A.

In the second instance person B has a finer grained knowledge about the
service he requires and the way in which this service has to interact
with the other already available service. Actually B is not interested
in how the city_tour service is implemented, but has some already
clearly defined plan about the way in which it has to interact with the
hotel_reservation service. He wants to create a workflow which is
flexible enough for the service requester agent. B's idea is to create
the following scenario: 
hotel_reservation OR (hotel_reservation AND city_tour)

To cut the story short, after finding a suitable service B aggregates
these functions together and does not only provide a human readable
interface but also an enriched version of what the service is capable of
doing. He eventually selects a service repository where he advertises
this new service. At which point he now turns also into a service
provider.

Now given that a requester agent has an enriched definition of what the
service can do and in which order it can perform these functions, the
intelligent agent can identify whether such a service is suitable for
him or not. Given that logic is involved, an agent can reason about
certain aspects of the service, which would not be possible if the
service description is purely WSDL.

Someone might say, what has this to do with the arguments brought
forward....
I wanted to mearly provide a simple scenario which people can use to
base their arguments, so that others, new to the list and to Semantic
Web Services, could understand better, possibly.

Some other things that people seem to be forgetting; OWL-S is one of the
first languages which came out of a collective effort, but it is not the
only one, just to name a few others, there are WSDL-S, WSMO and possibly
others. So one could also look at these efforts and identify
commonalities, discrepancies, pit faults, advantages etc.

Fianlly I must say that over the years this list has helped a lot to
clarify/challenge some ideas about the area, but I think that research
is not just shooting down arguments ( I think that is the job of a
lawyer), it is building over ideas, extending ideas, identifying
innovative ideas, accepting healthy critism and also backtracking and
identifing where an argument has become faulty. It would really make
sense to see these principals reflected in this list and in the way that
people put forward arguments. 

Xuan, I would like to read how by applying Semantic Web
technologies/languages, u can improve the way in which your developed
services are more efficiently discovered and combined together. Cause
after all, if one is not pro Semantic Web or at least thinks that it can
improve things, why indulge in arguments over the list. If  what I read
is not interesting to me, why read it in the first place, and why go
into length to argument about it?

regards to all

Received on Thursday, 27 July 2006 14:51:38 UTC