Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations

Presentation on theme: "1 Towards a Practical Rule Language Michael Kifer State University of New York at Stony Brook USA."— Presentation transcript:

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

2 2 Motivation

3 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 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 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 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 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 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 9 Overview of FLORA-2

10 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 Idattributes

11 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 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 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 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: and ?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 method that returns attribute names A virtual class of red cars

15 15 ?O[attributesOf(?Class) -> ?Attr] :- ?O[?Attr => ?Type] and ?Type :: ?Class.

16 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 17 HiLog Allows certain forms of logically clean, yet tractable, meta-programming Syntactically higher-order, but semantically first-order and tractable

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

20 20 Reification Blending HiLog with F-logic allows making objects out of statements about objects: john[believes -> ${mary[likes -> bob ]} ] Introduced in [Yang & Kifer, ODBASE 2002] Rules can also be reified useful in semantic Web services Object made out of the formula mary[likes -> bob]

21 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 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 23 Problems with State Dynamics in Logic Programming assert/retract have no logical semantics Non-backtrackable, e.g., ?- assert(p), fail. leaves p around not atomic –Prolog actions are not atomic in the database sense Prolog programs with updates are the hardest to write, debug, and understand

24 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 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 actions atomic have the property of being atomic in the sense of database theory of transactions

26 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 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 28 Pragmatics of Knowledge Programming

29 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 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 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 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 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 34 Module Encapsulation Modules can be encapsulated to block unintended interactions Export to all modules: :- export p(?,?) and ?[foo -> ?]. Export to specific modules: >>foo :- export (p(?,?) >> (abc, cde)) and ?[foo -> ?] >> efg. p/2 is exported only to modules abc and cde. foo Attribute foo is exported to efg. Predicate q/1 is exported to all modules. Updatable export: foo :- export p(?,?) and updatable ?[foo -> ?] >>(abc,cde). foo p/2 can be only queried by other modules, but modules abc and cde can also insert or delete data for the attribute foo

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

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

Similar presentations

Ads by Google