RE: [OWL-S] Who does what?

Other candidates such as BPEL, SCSL, may address such problems, and the
following efforts tried to emerge them with WSDL/OWL-S(DAML-S) if not
complete solutions.


1. From DAML-S to BPEL, at
http://europa.nvc.cs.vt.edu/ride04/RIDE04_Accepted_Papers.htm

2. Service components for managing the life-cycle of service compositions J.
Yang, M.P. Papazoglou pp 97-125 Full text via ScienceDirect :
http://www.sciencedirect.com/science?_ob=GatewayURL&_origin=CONTENTS&_method
=citationSearch&_piikey=S0306437903000516&_version=1&md5=e59150cac247b074ed5
5ae2fd5844601

3. BPEL2DAML-S, http://www.it.swin.edu.au/centres/cicec/bpel2damls.htm

Cheers

Jun Shen

Swinburne

-----Original Message-----
From: public-sws-ig-request@w3.org [mailto:public-sws-ig-request@w3.org] On
Behalf Of David Martin
Sent: Wednesday, 17 December 2003 4:47 PM
To: public-sws-ig@w3.org
Subject: [OWL-S] Who does what?




Here's the "summary/position statement" I promised / threatened to write 
up, at the end of our telecon last week.

(This is the statement to which Bijan said, to wit: "I completely agree 
with that statement".  After I picked myself up off the floor, he noted 
that he was kidding.  Nevertheless, I do not believe this statement to 
be particularly controversial.)

------

Some critical requirements for a process model are:

(a)    It should be possible to specify (composite) processes involving 
multiple roles (not just the usual two - provider/requester - that we 
talk about the most).

(b)    It should be possible to specify all possible* combinations of 
"who does what"; that is, which roles perform which steps (including 
evaluating conditions).
     *under some reasonable analysis of what's possible, which I won't 
address here

(c)    It should be possible to unambiguously express 
"fully-fleshed-out" processes -- that is, processes that are executable 
by some set of enactment engines -- where "unambiguously" means, I 
think, that one can easily make an assignment of roles to enactment 
engines, and, once such an assignment has been made, the behavior of 
each enactment engine is then clearly spelled out.

OWL-S currently doesn't meet these requirements.  We have a property 
called "participant", but we haven't been using it.  We've always relied 
on various simplifying assumptions to determine "who does what", but 
we've not been nearly clear enough about these assumptions.

It seems to me there are three paths towards getting OWL-S to meet these 
requirements.  These aren't necessarily exclusive; that is, the solution 
might be some combination of elements from these paths.  Also, there 
might be other paths that I'm not including here.

(1) Make "who does what" more explicit in OWL-S process models, by 
relying on "participant", and adding additional, related, constructs as 
needed to spell it out.

(2) Convince ourselves that OWL-S groundings can provide the missing 
information, and extend them if needed, and document how this works.

Note that these first 2 paths allow for the specification of all the 
roles within a single process model, which is what most of our 
discussions seem to assume.  The 3rd path, however, relies on separate 
process models for the different roles.

(3) Adopt a convention of specifying a separate process model for each 
role (so that a role gets associated with an entire process model rather 
than with individual process steps within the more complex process 
models of (1) and (2)).  And make sure we have an appropriate set of 
constructs to support this convention.

Cheers,
David

Received on Wednesday, 17 December 2003 00:56:20 UTC