some thoughts on SWSL service profile concept and approach

(sorry -- forgot to post this initially to www-ws@w3.org, but it's a 
technical issue, so I'm doing so with this msg.  -- Benjamin)

>Date: Tue, 06 May 2003 15:03:09 -0400
>To: swsl-committee@daml.org
>From: Benjamin Grosof <bgrosof@MIT.EDU>
>Subject: some thoughts on SWSL service profile concept and approach
>Sender: owner-swsl-committee@wrath.daml.org
>X-Spam-Score: 2.4
>X-Spam-Level: ** (2.4)
>X-Spam-Flag: NO
>X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
>
>Hi folks,
>Following up the action item I had:
>
>Here are some thoughts on the concept of a SWSL service profile, and what 
>our approach to representing a profile should be (inline'd below and also 
>attached as a file for convenience).  The first part is a summary of some 
>suggestions -- please read that first.
>
>Then there's a less coherent but possibly fertile set of material:  I've 
>appended some notes from the f2f that I took, mostly transcribing discussion.
>
>Benjamin
>
>% outline on modifying SWSI profiles from DAML-S's
>% in light of rules and contracts
>% by Benjamin Grosof
>% created 4/11/03
>% modified 5/6/03
>% this version:  5/6/03
>
>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>Comments by Benjamin Grosof on suggestions for SWSL Service Profiles
>relative to DAML-S Service Profiles as a point of departure.
>
>A key background point is  DAML-S design approach already says:
>there may be many profiles, used for different purposes
>
>
>Benjamin's suggestions:
>
>We should support partial-ness of a description in a general way,
>including to reuse/overlap the profile info for/with the process model.
>Then any particular profile becomes some partial description, e.g.,
>a subset of a more complete but still partial description which includes
>an executable process model.
>
>Suggest we think about there being
>(beyond the grounding)
>a knowledge-based service description,
>some subset of which is executable and thus constitutes a process model,
>but which may include parts that are not executable,
>and any coherent subset of which can be used as a profile.
>
>What kind of knowledge may a service description contain?
>It should be at least:
>- DL ontologies cf. OWL
>- LP rules cf. RuleML
>- process model in the above sense
>What else is TBD (To Be Determined/designed)...
>
>A profile may include its own ontologies stuff,
>e.g., as when define product names or levels or customer kinds.
>
>Wrt predefined properties of a service:
>suggest Pricing be one of them.
>
>An important kind of profile is a partial or complete contract proposal.
>
>An important kind of profile is a service discovery/advertisement entry.
>
>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>APPENDICES:  some additional notes follow -- material from
>the f2f meeting on 4/11/03
>
>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>% especially relevant notes from the SWSI f2f SWSL sessions:
>(just cut and pasted from Benjamin's notes)
>
>3. cf. Benjamin's suggestion:  add CONTRACTS and things like that to
>the PROFILE -- needs crisping up -- but seems reasonable [Michael K]
>
>consider light workflow via rules [Benjamin's point]
>
>cf. Benjamin's issue with rules:
>OVERLAP AND STRUCTURING of same info being used in both
>the PROFILE and the process model
>
>Michael and Benjamin:  propose as req:
>to allow/enable:  that could have RULES (e.g., partial profile) as a
>VIEW on, or a partial spec of, the PROCESS MODEL, and as a full spec
>for a simple process model
>
>Benjamin:
>- not sure how critical it is to get profile out quickly as a draft
>- post-conditions guaranteed    is very close to   contract descr,
>
>
>Benjamin:
>**implic's of a partially executable contract ruleset use case
>at paradigm level -- for
>possibly modifying the DAML-S paradigm of division between service profile
>vs. service process model
>- at least would want to be able to point from profile to rulebase,
>   and from process model to rulebase
>- they overlap
>
>Benjamin:
>exception handling can be viewed as part of a rule-based spec
>at profile level, not just at process model level
>
>Benjamin:
>contracts can be viewed as service descriptions
>
>Benjamin:
>user/customer conceptual view of business processes / services today
>is often cf. light workflow
>
>Benjamin:
>light workflow also used in pub-sub, or info flow type applications
>(news, workflow, info dissemination)
>
>Benjamin:
>rule-b descr's/services as early low-hanging approach to
>distinctively semantic WS; same rulebase descr useful for several SWS tasks
>incl discovery, selection, negotiation, monitoring, exception handling
>
>
>Dieter:  can use rules for "evolving algebras"  for state-transition oriented
>process descriptions - i.e., represent the states and time explicitly,
>can have sequences of actions
>
>Benjamin:  yes for quite a bit, but rules lack some perspicuity for
>representing some of that, compared to workflow languages
>
>Dieter:  error recovery w/ compensation is tough
>- Michael K:  should do in WS level not SWS
>
>Karl:  can view:  a requirement for our SWS service description: is that
>service descriptions are partial
>
>Benjamin:
>also want executable for at least some simpler expressive cases
>
>Benjamin:  as consider different tasks for SWS, the aspects of
>overall service descr that help with each task may overlap properly,
>e.g., rule-based service descr's for e-contracts,
>thus may want to define even more aspects of service descriptions
>than just "profile" vs. "process model"
>
>
>Benjamin:  for adoption by developers, it's critical that our service descr's
>are part of the main spec that generates executable, otherwise dev'ers
>won't invest the effort to gen the spec's and maintain them in the life cycle,
>because they'll be viewed as extra
>
>Benjamin:  let's think in terms of
>- our mission is to provide a KNOWLEDGE-BASED service descriptions,
>as extension and enrichment of usual service descriptions;
>this is intrinsically plumbing in a direct sense;
>- focus on who will AUTHOR the knowledge-based descriptions,
>e.g., developers in the beginning, then later end users
>- get more req's and attention/investment by pilot brag applications
>     being done
>
>
>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>% overview slide from Benjamin's presentation in SWSL session of f2f:
>%   [NB:  formatting got a bit messed up in pasting from powerpoint]
>
>Overview:  {SW rules+ontologies} and the procedural aspect of SWS
>
>Quickly review:  rule-based SWS cf. the 3/20 SWSL telecon presentation
>and 4/9 DAML PI Mtg Services Breakout
>Describing post-conditions and pre-conditions, esp. contingent behavior
>Let's do more use cases and application scenarios
>Situated logic programs (SLP)  [the largest emphasis of this presentation]
>very simple workflow, viewable as timeless and stateless
>abstraction of event-condition-action rules and OPS5 production rules
>supported in RuleML and (basically too in) Jess.
>actions (invoke external procedures) triggered by inferring of conclusions
>queries (invoke external procedures) during testing of rule antecedent c
>onditions
>Built-ins used in rules and ontologies, e.g.,
>  arithmetic and comparison operators/functions
>Exception handling in workflows and service agreements/contracts
>Representing service post-conditions and state transitions, incl. contracts,
>persistence defaults  [-- next presentation could usefully have more on this]
>
>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>% some other thoughts and notes from 4/11/03, by Benjamin:
>
>in the process model:  there are:
>
>precondns
>input
>output
>effects
>
>and can all be CONDITIONAL!  -->> think about how rules related
>
>%%%
>
>one critique point:
>
>quality vs. category vs. non-functional parameters
>vs.  functional parameters
>
>is not a good division
>
>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
>
>
>________________________________________________________________________________________________
>Prof. Benjamin Grosof
>Web Technologies for E-Commerce, Business Policies, E-Contracting, Rules, 
>XML, Agents, Semantic Web Services
>MIT Sloan School of Management, Information Technology group
>http://ebusiness.mit.edu/bgrosof or http://www.mit.edu/~bgrosof
>
>

________________________________________________________________________________________________
Prof. Benjamin Grosof
Web Technologies for E-Commerce, Business Policies, E-Contracting, Rules, 
XML, Agents, Semantic Web Services
MIT Sloan School of Management, Information Technology group
http://ebusiness.mit.edu/bgrosof or http://www.mit.edu/~bgrosof