1. July 1, 2004SWSL Rules SWSL Rules Sketch of the proposed language BG & MK

2. July 1, 2004SWSL Rules2 Main Features Rule based with non-mon negation Literals: –Predicates –Frames, class hierarchy, instances of classes, classes as instances (some OWL-Full features for cheap) –Based on F-logic Higher-order syntax, first-order semantics –Variables can be anywhere (predicate, function positions) which allows introspection of structure –Reification: rules, rule bodies, rule heads –Based on HiLog

3. July 1, 2004SWSL Rules3 Main Features (Contd) Rule priorities, constraints, negation in the rule head –Does not add expressive power, but lets the programmer specify complex cases of negation much more succinctly and clearly –Based on courteous LP approach by BG –Useful for specifying complex policies etc.

4. July 1, 2004SWSL Rules4 Main Features (Contd) Considering –Procedural attachment –State changing operators (a la SQL bulk updates) –Triggers –Based on Transaction Logic (and possibly some non-logical)

5. July 1, 2004SWSL Rules5 Relationship to OWL Includes OWL Lite - –See the paper by de Bruijn, Polleres, Fensel http://www.wsmo.org/2004/d20/v0.2/20040630/ http://www.wsmo.org/2004/d20/v0.2/20040630/ –OWL Lite - includes the most significant features of OWL Lite Includes some of the features of OWL Full –Classes as instances The exact intersection of SWSL Rules and OWL is not known at this time

6. July 1, 2004SWSL Rules6 Example: Travel Reservation Services can sell tickets from city A to city B or sell citipasses for a city. Features shown: –input as a reified object –complex goals (Boolean combos) –rules in postconditions and goals –service effects can depend on input –services/goals can include time ranges –goals/services can contain universal quantifiers

7. July 1, 2004SWSL Rules7 Example: Taxonomy germany, france, europe, etc. – classes of cities paris, bonn, etc. – cities germany sub europe. austria sub europe. france sub europe. tyrol sub austria. Innsbruck in tyrol. lienz in tyrol. vienna in austria. bonn in germany. frankfurt in germany. paris in france. nancy in france.

8. July 1, 2004SWSL Rules8 Example: A Service Description Serv1 sells tickets & citipasses serv1[ precondition(?Input) -> ${ ?Input like ?Req[from->?From and to->?To] and ?Req in request and ?From in germany and ?To in austria or ?Input like ?Req[citipass-> ?City] and ?Req in request and ?City in tyrol } and effect(?Input) -> ${ (ticket(?Req)[start->?From and destination->?To and timerange->[12,18]] :- ?Input like ?Req[from->?From and to->?To] and ?Req in request) and (pass(?Req)[location->?City] :- ?Input like ?Req[citipass->?City], ?City in tyrol, ?Req in request) } ].

9. July 1, 2004SWSL Rules9 Example: A Goal Find services that can sell a pass for some city in Tyrol and for every city in France goal123[ input -> ${_#1[citipass-> ?_]} and intent-> ${?Pass[location->?X in france or location->?X in tyrol] and forall ?City (if ?City in france then exists ?Pass1 (?Pass1[location->?City]) ) ] and _#1 in request. Auto-generated new object Id Issue: Is adding quantifiers a good idea?

10. July 1, 2004SWSL Rules10 A Service Discovery Rule #doFindService(?Goal) :- ?Goal[input -> ?Input] and ?Serv[precondition(?Input) -> ?Precond] and ?Precond and ?Goal[input -> ?FreshInput] and ?Serv[postcondition(?FreshInput) -> ?PostCond] and insertrule{?PostCond} and // hypothetically assume postcondition // Check if our goal is satisfied by the service ?Goal[intent -> ?Intent] and if ?Intent then (write('Service ') and write(?Serv) and writeln(' matches!')) and // Remove the hypothetically added facts and rules deleterule{?PostCond}.

11. July 1, 2004SWSL Rules11 Thoughts on a Bridge to SWSL Process serv1[ precondition(?Input) -> … and effect(?Input) -> … and processModel -> ${ (sand seq paint) par heat } ] Process model reified as a term Process model could be a PSL statement or expressed in some other language. We assume it is some kind of a first-order statement.

12. July 1, 2004SWSL Rules12 Thoughts on a Bridge (contd) goal123[ input -> … and intent -> … and processQuery -> ${ sand seq paint} ] Process query reified as a term Matching of process query against process model can be done using a first order theorem prover, which can be treated as a procedural attachment that takes 2 reified formulas and tells whether one implies the other.