1 / 35

Towards a Practical Rule Language

Towards a Practical Rule Language. Michael Kifer State University of New York at Stony Brook USA. Motivation. Existential Question about Logic Languages. Why didn’t Prolog succeed? Ullman’s conjecture Prolog’s execution strategy is to blame

Download Presentation

Towards a Practical Rule Language

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

More Related