June 14, 2004DIP Meeting, Lausanne Service Discovery Using Transaction Logic Reasoning Michael Kifer

June 14, 2004DIP Meeting, Lausanne2 A Service Discovery Framework Background theory (ontology) Service –Precondition –Precondition: a formula that states what must true of the input (possibly other things too, but not in WSMO) –Postcondition –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 –Input: a formula representing an object or an object template –Intent –Intent: a formula that states what the user wants to happen after the service is done

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

June 14, 2004DIP Meeting, Lausanne4 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 (

June 14, 2004DIP Meeting, Lausanne5 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 (

June 14, 2004DIP Meeting, Lausanne6 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.

June 14, 2004DIP Meeting, Lausanne7 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

June 14, 2004DIP Meeting, Lausanne8 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.

June 14, 2004DIP Meeting, Lausanne9 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) } ].

June 14, 2004DIP Meeting, Lausanne10 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.

June 14, 2004DIP Meeting, Lausanne11 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(' % Remove the hypothetically added facts and rules deleterule{PostCond}, if Goal[desireAxioms->DesireRules] then deleterule{DesireRules}.

June 14, 2004DIP Meeting, Lausanne12 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