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

Re: agents

From: Xuan Shi <Xuan.Shi@mail.wvu.edu>
Date: Sun, 23 Jul 2006 14:29:34 -0400
Message-Id: <s4c387f1.033@WVUGW01.wvu.edu>
To: <jpsequeira@netvisao.pt>
Cc: <bparsia@isr.umd.edu>, <public-sws-ig@w3.org>

OWL-S is a mixture of *service-related* issues. As Bijan said, if you
are a service provider, normally "there won't be a lot of process to
describe". This means, once a service provider describes IOPEs for the
service, that's enough (service.owl, profile.owl).

Then why do we need to describe varied "processes" for service
composition? Actually this (process.owl) is something described for
service requesters, who want to show us how they consume multiple
services to accomplish a series of tasks (if a service requester only
consumes an atomic process, then there is no composite services). Such
activity is strange also as in real life, NO service providers will tell
their customer how many subcontractors they hired and how subcontractors
will accomplish the tasks in whatever kind of order and processes.  

OWL-S is really a strange approach for service providers. The myth
underneath the background is that OWL-S people believe that SWS = SW +
WS and logic modeling should be a component in its framework. 

Unfortunately SW deals with *data* and *concepts*. There is NO function
definition in SW ontologies. So we see the first fundamental problem in
OWL-S (SW is not good for SWS).

Secondly, logic modeling is NOT a necessary component for SWS. For
example, when we define a single service (or atomic process), such as
"a" hotel reservation service, or "a" airline ticket reservation
service, etc. What's the role for logic modeling in this case?

Then how can we play logic modeling in SWS if there is no place for
logic modeling in describing "a" single service? A good invention is to
deal with service-related issues, which are the activities for service
requesters - they *probably* need to deal with different kinds of
services that are not well defined. It is in such situation that we find
a place for OWL-S.

For service providers, OWL-S is redundant and strangeous as it describes
lots of service-related issues that are not relevant to service
providers (in my opinion, it's almost useless to service requesters
also, if we consider the algorithm, speed, bandwidth issues in Internet
computing to handle online logic inference when dealing with many
unknown services).



>>> Bijan Parsia <bparsia@isr.umd.edu> 07/20/06 5:54 PM >>>

On Jul 20, 2006, at 3:48 PM, Jorge Paulo Sequeira wrote:
> I'm new to owl-s and I've got a basic question:
> I want to semantically document a web service of mine.
Why? What's your goal?
> Let's say I build all the files that I need, with all the  
> information with input output preconditions and effects. Let's also  
> assume that I have already a service.owl, a profile.owl, a  
> process.owl and a growding.owl for my service.
Er...you mean the standard background ontology that you've imported?  
Or is it just that you've covered all these areas? (There's no  
requirement for separate files. If your service is atomic, there  
won't be a lot of process to describe).

> What now?
if you have no other goals, then you are done!
> What am I supposed to do with these files?
This is a really strange question. What did you *want* to do with  
them? Why did you mark them up?

Typically, one will publish them so others (or you) can use them.
> Do I have to build my own agent to query them?
Er...usually one wants to use enriched descriptions to assist in  
enhancing or automating certain tasks such as service discovery,  
matching, composition, or execution. Well, you know what the service  
is, so no discovery. You've only mentioned one, so not a lot of  
matching or composition. Is this a general question?
> Are there API's available on the community?
Yep. I recommend, as I would :) the Maryland OWL-S api:
> What's the typical use for these files? How do I integrate this  
> information on my web server so agents can locate and "understand"  
> the service?
Just publish like normal web documents.

Received on Sunday, 23 July 2006 18:30:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:32:56 UTC