Towards a Practical Rule Language

1. Towards a Practical Rule Language Michael Kifer State University of New York at Stony Brook USA

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 Id attributes attributes 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.’] ]

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-logic • Browsing 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 and ?X[color -> red]. • Querying the schema: • ?O[attributesOf(?Class) -> ?Attr] :- • ?O[?Attr->?Value] and ?Value : ?Class. • Attributes that have a value in ?Class A virtual class of red cars A method that returns attribute names

15. 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

16. HiLog • Allows certain forms of logically clean, yet tractable, meta-programming • Syntactically higher-order, but semantically first-order and tractable

17. Examples of HiLog Variables 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 ofHiLoginFLORA-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

18. 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]

19. 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

20. 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

21. Problems with State Dynamicsin Logic Programming • assert/retract have nological semantics • Non-backtrackable, e.g., ?- assert(p), fail. leaves p around • Prolog actions are not atomic in the database sense • Prolog programs with updates are the hardest to write, debug, and understand

22. 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!

23. 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-2will execute this program correctly, because all actions have the property of being atomic in the sense of database theory of transactions

24. 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 inFLORA-2)

25. 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

26. Pragmatics of Knowledge Programming

27. 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] ]. Skolem function Same Skolem constant

28. 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

29. 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

30. 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.flrreplaces 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

31. 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.

32. Module Encapsulation Modules can be encapsulated to block unintended interactions • Export to all modules: :-exportp(?,?) and ?[foo-> ?]. • Export to specific modules: :- export (p(?,?) >> (abc, cde)) and ?[foo-> ?] >> efg. p/2 is exported only to modules abc and cde. Attribute foo is exported to efg. Predicate q/1 is exported to all modules. • Updatable export: :- export p(?,?) and updatable ?[foo-> ?] >>(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 foo

33. 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

34. 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

35. 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