June 14, 2004 DIP Meeting, Lausanne

Service Discovery Using Transaction Logic Reasoning

Michael Kifer

June 14, 2004 DIP Meeting, Lausanne 2

A Service Discovery Framework• Background theory (ontology)• Service

– PreconditionPrecondition: a formula that states what must true of the input (possibly other things too, but not in WSMO)

– PostconditionPostcondition (usually called “effect” in other terminologies): a formula that states what is guaranteed to hold after the service executes

• Goal – what the client wants– InputInput: a formula representing an object or an object

template– IntentIntent: a formula that states what the user wants to

happen after the service is done

June 14, 2004 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?

June 14, 2004 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)

June 14, 2004 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/)

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

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

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

June 14, 2004 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)

}].

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

June 14, 2004 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 Desireif Goal[intentAxioms->DesireRules]

then insertrule{DesireRules},

%% Check if our goal is satisfied by the serviceGoal[intent->Desire],if Desire

then (write('Service '), write(Serv), writeln(' matches!'))@prolog(),

%% Remove the hypothetically added facts and rulesdeleterule{PostCond},if Goal[desireAxioms->DesireRules]then deleterule{DesireRules}.

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