1 / 12

SWSL Rules Sketch of the proposed language

SWSL Rules Sketch of the proposed language. BG & MK. 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

sandro
Download Presentation

SWSL Rules Sketch of the proposed language

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SWSL RulesSketch of the proposed language BG & MK SWSL Rules

  2. 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 SWSL Rules

  3. Main Features (Cont’d) • 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. SWSL Rules

  4. Main Features (Cont’d) • Considering • Procedural attachment • State changing operators (a la SQL bulk updates) • Triggers • Based on Transaction Logic (and possibly some non-logical) SWSL Rules

  5. Relationship to OWL • Includes OWL Lite- • See the paper by de Bruijn, Polleres, Fensel 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 SWSL Rules

  6. 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 SWSL Rules

  7. 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. SWSL Rules

  8. 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) } ]. SWSL Rules

  9. 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? SWSL Rules

  10. 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}. SWSL Rules

  11. 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. SWSL Rules

  12. Thoughts on a Bridge (cont’d) 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. SWSL Rules

More Related