1

Towards a Practical Rule Language

Michael Kifer

State University of New Yorkat Stony BrookUSA

2

Motivation

3

Existential Question about Logic Languages

• Why didn’t Prolog succeed?• Ullman’s conjecture

– Prolog’s execution strategy is to blame– He thought that deductive databases is the answer

• Why didn’t deductive databases conquer the world then?• My conjectures

– Predicate-based languages are too low-level, hard to use for large applications

– No killer application (especially in the DB area)– Deductive “databases” is a misnomer – knowledge programming is the

right application domain– Query answering is not the only thing – need methods with side

effects, procedural knowledge A practical rule language should be able to address the above issues

4

The FLORA Project

• FLORA-1 – ca. 1999– Attempt to implement a high-level knowledge

programming language

– Based on F-logic and XSB: F-logic was the high-level declarative specification language; XSB provided the programming component

• Lessons– F-logic is not enough for sophisticated applications

– XSB’s programming component is too low-level

– Need a lot more pragmatics, such as a flexible module system, user-controlled skolemization, introspection, etc.

5

The FLORA Project (cont’d)

• FLORA-2 – ca. 2001 – now– A new start based on lessons learned

– Based on F-logic, HiLog, and Transaction Logic– A lot more pragmatics:

• A new module system

• User-controlled skolemization

• Introspection (ability to examine own knowledge base)

• Debugging support

• Exception handling

• FLORA-2 (next release)– Simplified syntax

– Rich primitive data types

6

What is F(rame)-Logic?• An object-oriented first-order logic• Extends predicate logic with

– Objects with complex internal structure– Class hierarchies and inheritance– Typing

• A basis for object-oriented knowledge representation and programming

• See– Basic theory: [Kifer & Lausen SIGMOD-89], [Kifer,Lausen,Wu JACM-95]– Extensions:

• Path expression syntax: [Frohn, Lausen, Uphoff VLDB-94] • Meta-programming, other extensions: [Yang & Kifer, J. on Data Semantics 2003]• Semantics for inheritance: [Yang & Kifer, J. on Data Semantics 2006]

7

What is HiLog?

• A higher-order extension of predicate logic with

tractable first-order semantics

• Also partly exists in XSB and Common Logic

• See [Chen,Kifer,Warren, HiLog: A Foundation for Higher-Order Logic Programming, J. of Logic Programming, 1993]

8

What is Transaction Logic?

• A logic for programming change

• Designed both for programming and reasoning

• Applications:

– Workflow modeling

– Web service discovery

– Web service choreography

– Planning

– Database view maintenance

Bonner&Kifer, An Overview of Transaction Logic, in Theoretical Computer Science, 1995.Bonner&Kifer, A Logic for Programming Database Transactions, in Logics for Databases and

Information Systems, Chomicki&Saake (eds), Kluwer, 1998.Bonner&Kifer, Results on Reasoning about Action in Transaction Logic, in Transactions and

Change in Logic Databases, LNCS 1472, 1998.

9

Overview of FLORA-2

10

F-logic: Simple Examples

Object description:

John[name ‘John Doe’, phones -> {6313214567, 6313214566}, children -> {Bob, Mary}]

Mary[name’Mary Doe’, phones -> {2121234567, 5129297945}, children -> {Anne, Alice}]

Structure can be nested:

Sally[spouse -> John[address -> ‘123 Main St.’] ]

attributesObject Id attributes

11

Original F-logic: Too Much Syntax

• F-logic has much more syntax compared to traditional deductive databases (high-level languages usually do)

• But the original logic had too much syntax– ok for a theoretical device

– bad for a practical language

• The original F-logic distinguished between functional attributes (spouse -> mary) and set-valued attributes (children -> {bob,kathy})

• Proved error-prone in practice

• Simplified syntax treats functional attributes as cardinality constraints (later)

12

F-logic: Class Hierarchies

ISA hierarchy:

John : Person // class membership Mary : Person Alice : Student

Student :: Person // subclass relationship

Student : EntityType

Person : EntityType

Class & instance in different contexts

13

F-logic: Methods

Methods: like attributes, but take arguments

?S[professor(?Course) Prof] :-

?S:Student[took(?Semester) ?Course[taught(?Semester) ?Prof]].

• professor, took, taught – 1-argument methods• object attributes can be viewed as 0-ary methods

Queries:

?– Alice[professor(?Course) ?P] and ?Course : ComputerScience.

Alice’s CS professors.

14

Reflection in F-logicBrowsing the IsA hierarchy: ?- John : ?X. // all superclasses of the object john

?- Student :: ?Y. // all superclasses of class student

Defining virtual classes:

?X : redcar :- ?X : car andand ?X[color -> red].

Querying the schema:

?O[attributesOf(?Class) -> ?Attr] :- ?O[?Attr ->?Value] and ?Value : ?Class.

• Attributes that have a value in ?Class

A method that returns attribute names

A virtual class of red cars

16

Type Signatures

• Type info is specified using statements like this (called signatures):Person[name {1:1}*=> string, spouse {0:1}*=> Person, children *=> Person].

*=> means inheritable instance attribute (like instance variable in Java)

• Signatures are formulas in F-logic; can be queried, etc.

• The notion of well-typed models relates signatures to data

17

HiLog

• Allows certain forms of logically clean, yet tractable, meta-programming

• Syntactically higher-order, but semantically first-order and tractable

18

Examples of HiLogVariables over predicates and function symbols: p(?X,?Y) :- ?X(a,?Z), ?Y(?Z(b)).

Variables over atomic formulas (reification): p(q(a)). r(?X) :- p(?X) and ?X.

A use of HiLog in FLORA-2 (even more involved queries about the schema):

?Obj[unaryMethods(?Class) ?Method] :- ?Obj[?Method(?Arg) -> ?Val] and ?Val : ?Class.

Variable that ranges over unary method names

19

HiLog Simplified F-logic Syntax

• Original F-logic didn’t use HiLog, but still allowed variables over methods

• This required special syntax:?Obj[unaryMethods(?Class) -> ?Method] :-

?Obj[?Method @ (?Arg) -> ?Val] and ?Val : ?Class.

• This proved to be error prone:Obj[foo(Arg) -> Value]

vs.

Obj[foo @ (Arg) -> Value]

21

Transaction Logic

• A logic of change

• Unlike temporal/dynamic/process logics, it is also a logic for programming

• In the context of objects:– A logic-based language for specifying the

behavior of objects

22

Transaction Logic (cont’d)

• Designed for programming and reasoning– Other logics, e.g., situation calculus, temporal, dynamic, and

process logics are designed for reasoning only

– They typically lack such basic facility as subroutines

23

Problems with State Dynamicsin Logic Programming

• assert/retract have no logical semantics• Non-backtrackable, e.g.,

?- assert(p), fail.

leaves p around– Prolog actions are not atomicnot atomic in the database sense

• Prolog programs with updates are the hardest to write, debug, and understand

24

Example: Stacking a Pyramid (Prolog)

Program: stack(0,X). stack(N,X) :- N>0, move(Y,X), stack(N-1,Y).

move(X,Y) :- pickup(X), putdown(X,Y). pickup(X) :- clear(X), on(X,Y), retract(on(X,Y)), assert(clear(Y)). putdown(X,Y) :- wider(Y,X), clear(Y), assert(on(X,Y)), retract(clear(Y)).

Action: ?– stack(18,block32). % stack 18-block pyramid on top of block 32

Note: Prolog won’t execute this intuitively correct program correctly!

25

Example (cont’d): Stacking Pyramids (FLORA-2)

Program: stack(0,?X). stack(?N,?X) :- ?N>0, move(?Y,?X), stack(?N-1,?Y).

move(?X,?Y) :- pickup(?X), putdown(?X,?Y). pickup(?X) :- clear(?X), on(?X,?Y), btdelete{on(?X,?Y)}, btinsert{clear(?Y)}. putdown(?X,?Y) :- wider(?Y,?X), clear(?Y), btinsert{on(?X,?Y)}, btdelete{clear(?Y)}.

Action: ?– stack(18,block32). // stack 18-block pyramid on top of block 32

FLORA-2 will execute this program correctly, because all actionshave the property of being atomicatomic in the sense of database theory of transactions

26

Transaction Logic - Basics

• Introduces serial conjunction, (in FLORA-2 denoted with “,”)

• a b – do a then do b

• Uses the usual /\, \/, ¬, , (but with an extended semantics)• Example: a \/ (b c) /\ (d \/ ¬e)

• Rules:• a :- b a \/ ¬b

Means: to execute a one must execute b (i.e., a is the name of a subroutine)

• Also has hypothetical operators, ◊ and □ (not implemented in FLORA-2)

27

Semantics & Proof Theory

• Model-theoretic, like in F-logic and HiLog– Cleanly integrates with these logics

• Proof theory also executes actions according to their definitions– Will correctly execute the pyramid stacking problem

• Can be also used to– Reason about actions

– Plan robot actions

28

Pragmatics of Knowledge Programming

29

User-controlled Skolemization

• Needed to represent objects whose IDs are immaterial (e.g., parts of the same kind – nuts, bolts)

• Needed to approximate existential information– KR based on the logic programming paradigm provides no

direct support for existential variables in rule heads– Skolemization is the next-best thing– Example: every person has a parent

?P[parent -> _#(?P)] :- ?P:Person.

– Example: student database_#1[name->’John Doe’, advisor->_#[professor->MaryDoe, advisee->_#1] ].

Same Skolem constant

Skolem function

30

Scoped Inference

• Semantic Web requires scoped inference because– Normally the knowledge base is known

– But this doesn’t hold, if the KB is the entire Web

– Hence, a realistic KR language for the Semantic Web should have an explicit construct for specifying the scope – the KB with respect to which inference is to be made

• Scoped inference is mandatory for realizing default negation on the Web– To apply any form of the CWA, one needs to know the entire KB first

– The KB is unbounded in case of the Web

– Hence, again, scoped inference is needed

• Basic pragmatics – fundamental to knowledge programming, not just the Web

31

Scoped Inference in FLORA-2

• Has a flexible, dynamic module system• Each module is treated as a distinct knowledge base• Rules belonging to one module can reference

knowledge defined in other modules• Every literal in a query is explicitly or implicitly

relativized to a particular module– Hence the scope of every inference is known

32

FLORA-2 Modules

• Rules and facts are loaded into modules at run time. A module is an abstraction for a piece of executing code.

?- [myProgram >> foobar].• myProgram.flr is loaded into module foobar.

?- [anotherProgram >> foobar]. • anotherProgram.flr replaces myProgram in the module foobar.

?- [+yetAnotherProgram >> foobar].• Knowledge from yetAnotherProgram.flr is added to foobar

• Rules can be constructed at run time by modules and inserted into other modules– New agents can be constructed and spawned at run time as new modules

33

Referring to Knowledge Defined in Other Modules

• Referring to things defined in another module:head :- p(?X) and p(?X,f(a))@foo and ?O[abc(123) -> ?Result]@bar.

• The module to query can be decided at runtime:head :- ?M=foobar and p(?X,f(a))@?M and ?O[abc(123) -> ?Result]@?

M.

• Modules can be discovered by queries: Which module has a definition for p(…,f(a)) ?

?- p(?, f(a))@?M.

34

Module Encapsulation

Modules can be encapsulated to block unintended interactions

• Export to all modules::- export p(?,?) and ?[foo -> ?].

• Export to specific modules::- export (p(?,?) >>>> (abc, cde)) and ?[foofoo -> ?] >> efg.p/2 is exported only to modules abc and cde. Attribute foofoo is exported to efg. Predicate q/1 is exported to all modules.

• Updatable export::- export p(?,?) and updatable ?[foofoo -> ?] >>(abc,cde). p/2 can be only queried by other modules, but modules abc and cde can

also insert or delete data for the attribute foofoo

35

Semantics of Modules

• Modular programs can be given direct model-theoretic semantics

• But the easiest way to explain their semantics is – to assume that each module is given a unique prefix, eg.,

module foobar will have a prefix like _$_$foobar’– Each predicate or attribute/method name defined in a given

module would implicitly include that prefix. For instance: p(…)@foobar becomes _$_$foobar’p(…)

a[attr v]@foobar becomes a[_$_$foobar’attr v]

– This separates the namespaces of different modules

36

Other Pragmatics

• Non-logical updates (a la assert/retract)• Prolog-style cuts (nonlogical optimization)• Interfaces to Web, Java, C• Data types (future)• Aggregation/comprehension operators• Introspection (can examine its own rules, add, delete

rules)• Constraint solver• Exception handling• Debugging support

37

Lessons Learned

• Possible to design (at least some) logic primitives at the right level of abstraction

• Usability: delicate balance between features and simplicity

• Pragmatics is important: need to balance declarative and procedural worlds

• Some “dirty” tricks (like Prolog cuts) can be useful. Are there declarative substitutes?

• Using logic for programming is still very hard!• Query optimization is still a huge problem