1 / 12

Service Discovery Using Transaction Logic Reasoning

Service Discovery Using Transaction Logic Reasoning. Michael Kifer. A Service Discovery Framework. Background theory (ontology) Service Precondition : a formula that states what must true of the input (possibly other things too, but not in WSMO)

lillian-lancaster
Download Presentation

Service Discovery Using Transaction Logic Reasoning

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. Service Discovery Using Transaction Logic Reasoning Michael Kifer DIP Meeting, Lausanne

  2. A Service Discovery Framework • Background theory (ontology) • Service • Precondition: a formula that states what must true of the input (possibly other things too, but not in WSMO) • Postcondition (usually called “effect” in other terminologies): a formula that states what is guaranteed to hold after the service executes • Goal – what the client wants • Input: a formula representing an object or an object template • Intent: a formula that states what the user wants to happen after the service is done DIP Meeting, Lausanne

  3. Logical Formulation Ontology |= Precond(Input\ActualInput) /\ (Postcond(Input\ActualInput) -> Intent) Requires query containment reasoning • Can such reasoning be done in a rule-based • language? DIP Meeting, Lausanne

  4. Logical Formulation (cont’d) 1. Ontology |= Postcond(Input\ActualInput) -> Intent Iff 2. Ontology/\ Postcond(Input\ActualInput) |=Intent • (1) can’t be done in a rule-based language, but (2) can • Postcond is not part of the background theory – must be assumed hypothetically • Not possible in standard first-order logic, especially not in a rule-based language • But possible in Transaction Logic (http://flora.sourceforge.net/aboutTR.php) DIP Meeting, Lausanne

  5. Discovery in Transaction Logic Ontology |= Postcond(Input\ActualInput) -> Intent Iff Ontology |=  (insert{Postcond(Input\ActualInput)} /\ Intent) • This can be accomplished in the rule-based subset of Transaction Logic • And easily implemented in the FLORA-2 system (http://flora.sourceforge/net/) DIP Meeting, Lausanne

  6. Limitations of Transaction Logic Based Discovery • Obviously: rule-based, so no disjunctions in the rule heads • Some things might be harder to do than in DL (eg, universals), but not significantly so • Supports: • Preconditions: Boolean combos of atomic formulas, which may in turn be defined by rules. • Postconditions: Facts and rules. No Boolean combos (e.g., negation or disjunction) • Goals: Like preconditions: Boolean combos of atomic formulas, which may in turn be defined by rules. DIP Meeting, Lausanne

  7. 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 DIP Meeting, Lausanne

  8. Example: Taxonomy • germany, france, europe, etc. – classes of cities • paris, bonn, etc. – cities germany :: europe. austria :: europe. france :: europe. tyrol :: austria. Innsbruck : tyrol. lienz : tyrol. vienna : austria. bonn : germany. frankfurt : germany. paris : france. nancy : france. DIP Meeting, Lausanne

  9. Example: A Service Description • Serv1 sells tickets & citipasses serv1[ precondition(Input) -> ${ Input ~ Req[from->From, to->To], Req : request, From : germany, To : austria ; Input ~ Req[citipass-> City], Req : request, City : tyrol }, postcondition(Input)-> ${ (ticket(Req)[start->From, destination->To, timerange->[12,18]] :- Input ~ Req[from->From, to->To], Req : request), (pass(Req)[location->City] :- Input ~ Req[citipass->City], City : tyrol, Req : request) } ]. DIP Meeting, Lausanne

  10. 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->_]}, intent-> ${Pass[location->X:france; location->X:tyrol], Pass[not doesnotServiceAllFrance]}, %% NOTE: With Lloyd-Topor this can be expressed more naturally: %%FORALL City if City:france then Pass[location->City] intentAxioms -> ${Pass[doesnotServiceAllFrance] :- City : france, Pass[not location-> City]} ], _#1:request. DIP Meeting, Lausanne

  11. A Service Discovery Rule #doFindService(Goal) :- Goal[input->Input], Serv[precondition(Input)->Precond], Precond, Goal[input->FreshInput], Serv[postcondition(FreshInput) -> PostCond], insertrule{PostCond}, % hypothetically assume postcondition %% Hypothetically assume the definitions of the Desire if Goal[intentAxioms->DesireRules] then insertrule{DesireRules}, %% Check if our goal is satisfied by the service Goal[intent->Desire], if Desire then (write('Service '), write(Serv), writeln(' matches!'))@prolog(), %% Remove the hypothetically added facts and rules deleterule{PostCond}, if Goal[desireAxioms->DesireRules] then deleterule{DesireRules}. DIP Meeting, Lausanne

  12. Conclusions • Service discovery can be conveniently done in a rule-based language + Transaction Logic • Representing pre/post conditions heavily relies on the ability to reify complex formulas, including rules – RDF’s reification of triples is insufficient (need a real logic, not an Ersatz-logic) • Frame-based representation gives a nice syntax for describing services DIP Meeting, Lausanne

More Related