Скачать презентацию Towards a Practical Rule Language Michael Kifer State Скачать презентацию Towards a Practical Rule Language Michael Kifer State

576865d65ccc54f19c9d59e8c6b42a75.ppt

  • Количество слайдов: 35

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

Motivation 2 Motivation 2

Existential Question about Logic Languages • Why didn’t Prolog succeed? • Ullman’s conjecture – 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 3

The FLORA Project • FLORA-1 – ca. 1999 – Attempt to implement a high-level 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. 4

The FLORA Project (cont’d) • FLORA-2 – ca. 2001 – now – A new The FLORA Project (cont’d) • FLORA-2 – ca. 2001 – now – A new start based on lessons learned – Based on F-logic, Hi. Log, 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 5

What is F(rame)-Logic? • An object-oriented first-order logic • Extends predicate logic with – 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] 6

What is Hi. Log? • A higher-order extension of predicate logic with tractable first-order What is Hi. Log? • A higher-order extension of predicate logic with tractable first-order semantics • Also partly exists in XSB and Common Logic • See [Chen, Kifer, Warren, Hi. Log: A Foundation for Higher-Order Logic Programming, J. of Logic Programming, 1993] 7

What is Transaction Logic? • A logic for programming change • Designed both for 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. 8

Overview of FLORA-2 9 Overview of FLORA-2 9

F-logic: Simple Examples Object Id attributes Object description: John[name -> ‘John Doe’, phones -> F-logic: Simple Examples Object Id 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. ’] ] 10

Original F-logic: Too Much Syntax • F-logic has much more syntax compared to traditional 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) 11

F-logic: Class Hierarchies ISA hierarchy: John : Person Mary : Person Alice : Student F-logic: Class Hierarchies ISA hierarchy: John : Person Mary : Person Alice : Student // class membership Student : : Person // subclass relationship Class & instance in different contexts Student : Entity. Type Person : Entity. Type 12

F-logic: Methods: like attributes, but take arguments ? S[professor(? Course) -> ? Prof] : F-logic: 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 : Computer. Science. Alice’s CS professors. 13

Reflection in F-logic Browsing the Is. A hierarchy: ? - John : ? X. Reflection in F-logic Browsing the Is. A hierarchy: ? - John : ? X. // all superclasses of the object john ? - Student : : ? Y. // all superclasses of class student A virtual class of red cars Defining virtual classes: ? X : redcar : - ? X : car and ? X[color -> red]. A method that returns attribute names Querying the schema: ? O[attributes. Of(? Class) -> ? Attr] : ? O[? Attr ->? Value] and ? Value : ? Class. • Attributes that have a value in ? Class 14

Type Signatures • Type info is specified using statements like this (called signatures): Person[name 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

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

Examples of Hi. Log Variables over predicates and function symbols: p(? X, ? Y) Examples of Hi. Log 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 Hi. Log in FLORA-2 (even more involved queries about the schema): ? Obj[unary. Methods(? Class) -> ? Method] : ? Obj[? Method(? Arg) -> ? Val] and ? Val : ? Class. Variable that ranges over unary method names 18

Hi. Log Simplified F-logic Syntax • Original F-logic didn’t use Hi. Log, but still Hi. Log Simplified F-logic Syntax • Original F-logic didn’t use Hi. Log, but still allowed variables over methods • This required special syntax: ? Obj[unary. Methods(? 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 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 21

Transaction Logic (cont’d) • Designed for programming and reasoning – Other logics, e. g. 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 22

Problems with State Dynamics in Logic Programming • assert/retract have no logical semantics • Problems with State Dynamics in Logic Programming • assert/retract have no logical 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 23

Example: Stacking a Pyramid (Prolog) Program: stack(0, X). stack(N, X) : - N>0, move(Y, 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, block 32). % stack 18 -block pyramid on top of block 32 Note: Prolog won’t execute this intuitively correct program correctly! 24

Example (cont’d): Stacking Pyramids (FLORA-2) Program: stack(0, ? X). stack(? N, ? X) : 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, block 32). // stack 18 -block pyramid on top of block 32 FLORA-2 will execute this program correctly, because all actions have the property of being atomic in the sense of database theory of transactions 25

Transaction Logic - Basics • Introduces serial conjunction, (in FLORA-2 denoted with “, ”) 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) 26

Semantics & Proof Theory • Model-theoretic, like in F-logic and Hi. Log – Cleanly Semantics & Proof Theory • Model-theoretic, like in F-logic and Hi. Log – 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 27

Pragmatics of Knowledge Programming 28 Pragmatics of Knowledge Programming 28

User-controlled Skolemization • Needed to represent objects whose IDs are immaterial (e. g. , 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->Mary. Doe, advisee->_#1] ]. Skolem function Same Skolem constant 29

Scoped Inference • Semantic Web requires scoped inference because – Normally the knowledge base 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 30

Scoped Inference in FLORA-2 • Has a flexible, dynamic module system • Each module 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 31

FLORA-2 Modules • Rules and facts are loaded into modules at run time. A FLORA-2 Modules • Rules and facts are loaded into modules at run time. A module is an abstraction for a piece of executing code. ? - [my. Program >> foobar]. • my. Program. flr is loaded into module foobar. ? - [another. Program >> foobar]. • another. Program. flr replaces my. Program in the module foobar. ? - [+yet. Another. Program >> foobar]. • Knowledge from yet. Another. Program. 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 32

Referring to Knowledge Defined in Other Modules • Referring to things defined in another 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. 33

Module Encapsulation Modules can be encapsulated to block unintended interactions • Export to all 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 ? [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 34

Semantics of Modules • Modular programs can be given direct modeltheoretic semantics • But Semantics of Modules • Modular programs can be given direct modeltheoretic 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 a[attr ->v]@foobar becomes _$_$foobar’p(…) becomes a[_$_$foobar’attr -> v] – This separates the namespaces of different modules 35

Other Pragmatics • • • Non-logical updates (a la assert/retract) Prolog-style cuts (nonlogical optimization) 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 36

Lessons Learned • Possible to design (at least some) logic primitives at the right 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 37