% presentation and discussion from SWSI F2F, SWSL breakout 10/19/03 % 1. proposal by Benjamin Grosof on direction for SWSL to % avoid procedural process model followed by % 2. partial notes from the committee's discussion spurred by it % notes by Benjamin Grosof 10/19/03 Preface: Only part of the discussion was captured in Part 2 of these notes. See the F2F meeting minutes prepared by Terry Payne for additional notes from the discussion. (Terry: please integrate this message in with your minutes, appropriately.) %%%%%%%%%%%%%%%%%%%%%%%%%%% Part 1: The Proposal Benjamin: I have a "radical" proposal on direction for SWSL, intended as provocation to help focus our thinking and efforts in part by reacting or qualifying it. Here goes... "NO Procedural Process Model" goals/criteria: academe: hard, intellectually interesting industry and standards: easy, valuable for social/business what can we actually do soon -- incl. tools, training let's intro semantics using as KR approaches what we basically already pretty much know how to do: - ontologies - rules -- including procedural attachments - maybe FOL plus let's use some basic ontologies about - profile, incl. from OWL-S as point of departure - tiny bit about time - add some quite generic/upper ontologies about service properties/classes wrt process model: "don't have one" (well, actually, that was for shock effect... but be very minimal) semantics via: - KR-y assertions about input and output messages or objects - KR-y assertions about preconditions and postconditions of a "black-box" service very minimal wrt process model: - Austin has some suggestions about this: - maybe ability to state a process/activity has parts - maybe sequence or conditional branch - maybe most simply a process is just an opaque URI can represent quite a bit using our KRs can do lots of ADM use for Contracts can do some Enactment - including via action/effector procedural attachments can do lots of reasoning including hypothetical reasoning, thus some analysis and verification can do lots of exception handling - e.g., in Contracts view can do lots of security, e.g. authorization, role-based access, digital rights can do some Composition - including via pure reasoning - including via rule chaining (maybe DL property chaining too) - including via procedural attachments for sensing/querying - including via procedural attachments for effecting/actions add semantics to approaches and application scenarios of - UDDI - WSDL(+SOAP) - ?BPEL - ?WS Choreography - ?what else overall: - go for some relatively quick wins - ... in our area of core/unique competence, with comparative advantage - establish SWS presence within the WS space - ... including injecting our stuff into the WS mainstream - build interest and investment for next major phase - don't worry, be happy... :-) In major phase 2 of SWSL efforts: grow the richness of the procedural process model hopefully we'll have more of a starting point "handed to us" from mainstream WS / basic research the usual suspects are available: - PSL (Michael G and Austin) - OWL-S' current process model - Transaction Logic and extensions (Michael K) - non-Semantic WS approaches, e.g., BPEL, Xlang, ... - pi-calculus - petri nets - finite state automata, Mealy machines, etc. - workflow algebras - Golog %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Part 2: partial notes from the committee's discussion: katia: could call this "OWL-S Lite" michael k: what we really need to try out this dirn is USE CASES!!!! michael k: other aspects to consider: DB interaction, msg interactions (also transactional recovery kind of stuff, but maybe defer that) bijan: all work to date on composn at MINDSWAP and w/ Fujitsu has been with just Sequence and usually single input output austin: need an extensible common core process model, can use NIST PSL or something similar benj: can view this in terms of factoring out process model austin: we also need cf. OWL-S: profile, grounding benj: want to use this to focus our efforts on use cases benj: what are areas where there are relatively mature tools - rules is one - e.g., suppose SAP wanted to deliver something based on our stuff within 3 yrs rick: FSA's is another: - Rose-RT bought by Rational Rose then they by IBM (discussion on how would rules with effectors relate to notions of sequencing and composition and plan operators) benj: trying to be provocative, where are specific situations in which we do need, and how much, a procedural process model to what extent can we get away without a (new) procedural process model? i.e., where could we get value from that? is there a way to define our use of KR-y descriptions as decoupled, and maybe make various procedural process modeling approaches be pluggable with it (or vice versa, which is dog vs. tail we can determine later...)? austin: candidate proposal: we could operationalize the general thrust here by 1. simplifying current OWL-S to make process model be basically gone -- just atomic processes with groundings; 2. then add NIST PSL (or maybe another approach) as an elaborated process model - benj: add rules too, for it there's only a placeholder currently in OWL-S (plus work item due Feb.) stefan: what would it take for the committee to agree on a process model? michael k: use cases! benj: we could put it in different terms: suppose you had to personally bet with serious stakes, e.g., $50,000 how long it would take to 1. agree 2. write up 3. create tools benj: one way to structure our efforts is to have more commitment as group (i.e., as "requirements") to version with very simple ("black-box") process model but relatively rich KR-y/profile-y, then have in parallel an effort (e.g., as "objectives") on how to add richer process model, which will also help meet the requirement of extensibility and pluggability of process model (discussion about plugging in PSL as process model, Michael K's process approach and use cases, some other stuff ...) rick hull: after some explorations on process model stuff, we can come back in say Jan. to deciding whether to plan to include it in the V1 of SWSL. %%%%%%%%%%%%%%%%%%