% 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 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%