The FO() Knowledge Base System project - VUBThe fundamental KRR research question I Humans experts possess (declarative) knowledge. I They use it I to accomplish tasks I to solve problems

The FO(·) Knowledge Base System project

Marc DeneckerKnowledge Representation & Reasoning (KRR)

Katholieke Universiteit Leuven

February 26, 2016

1 / 113

Introduction: the FO(·) KBS project

FO(·)

Inference of the KBS: progress reportModel expansion and visualisationImperative + Declarative Programming (IDP)

Conclusions

2 / 113


FO(·)


Conclusions

3 / 113

The fundamental KRR research question

I Humans experts possess (declarative) knowledge.I They use it

I to accomplish tasksI to solve problemsI or to build programs that do this for us

(computer science)

I How does this work?

I Inherently a KRR research question.I (KRR: Knowledge Representation and Reasoning)

I If we ever want to be able to build software systems in aprincipled way, we will NEED to understand this.

I This places KRR at the foundations of computer science.

4 / 113

The fundamental KRR research question

I Humans experts possess (declarative) knowledge.I They use it

I to accomplish tasksI to solve problemsI or to build programs that do this for us

(computer science)

I How does this work?

I Inherently a KRR research question.I (KRR: Knowledge Representation and Reasoning)

I If we ever want to be able to build software systems in aprincipled way, we will NEED to understand this.

I This places KRR at the foundations of computer science.

5 / 113

State of the art

I About every area in Computational logic is involved in aspectsof this question.

I Scientific understanding is partial and scattered over the manyfields of computational logic and declarative problem solving.

I One issue that fragments computational logic more thananything else:

the reasoning/inference task

6 / 113

State of the art

I About every area in Computational logic is involved in aspectsof this question.

I Scientific understanding is partial and scattered over the manyfields of computational logic and declarative problem solving.

I One issue that fragments computational logic more thananything else:

the reasoning/inference task

7 / 113

State of the art

I For every type of reasoning task, a new logic (or more thanone):

I Classical first order logic (FO):deduction

I Deductive Databases (SQL, Datalog):query answering & other database operations

I Answer set Programming (ASP):answer set computation

I Abductive Logic Programming:abduction

I Constraint Programming (CP):constraint solving

I Description logics:subsumption ⊆ deduction

I Planning languages PDDL :planning

I Temporal logics :model checking

I . . .8 / 113

State of the art

A declarative proposition:

Each lecturer teaches at least one course in the first bachelor

What is its purpose? What task is it to be used for?

I It could be a query to a database.

I It could be a constraint in a course assignment problem.

I It could be a desired property, to be proven from a formalspecification of the course assignment domain.

I . . .

In the current state of the art, depending on the task to be solved,we need a different system and a different logic to represent thisproposition.

9 / 113

State of the art







I . . .


10 / 113

State of the art







I . . .


11 / 113

State of the art







I . . .


12 / 113

State of the art







I . . .


13 / 113

Is declarative knowledge not independent of the task (and hence,of a specific form of inference) ?

14 / 113

An illustration

Question: How to solve a graph coloring problem in a declarativeway?

I Step 1: What is the knowledge? What is the centralproposition of a correct graph coloring?

I No two adjacent vertices have the same color.I In FO (classical first order logic):

∀x∀y(G (x , y)⇒ Col(x) 6= Col(y))

I Step 2: Input/Output:I Input: a pair of a graph G (Vertex ,Vertex) and a set Color of

colours; in FO, this is called a structureI Output: a function Col(Vertex) : Color satisfying the

proposition

I Step 3: What kind of inference do we need to solve theproblem?

I model generation

15 / 113

An illustration




∀x∀y(G (x , y)⇒ Col(x) 6= Col(y))



proposition


I model generation

16 / 113

An illustration




∀x∀y(G (x , y)⇒ Col(x) 6= Col(y))



proposition


I model generation

17 / 113

An illustration




∀x∀y(G (x , y)⇒ Col(x) 6= Col(y))



proposition


I model generation

18 / 113

An illustration




∀x∀y(G (x , y)⇒ Col(x) 6= Col(y))



proposition


I model generation

19 / 113

“What kind of inference do we need to solve this problem?”

I A question that until recently, for FO, was not even asked letalone addressed.

I FO was seen exclusively as the logic of deductive reasoning.I In some fields, this is still the dominating view.

I Deduction is utterly useless for solving the graph coloringproblem.

I Instead, people developed new logics to handle problems likethis:

I Constraint Programming LanguagesI Ilog, Zinc, Constraint Logic Programming, . . .

I Answer Set Programming (ASP)

20 / 113








21 / 113








22 / 113








23 / 113

Why do we need all these syntaxes for expressing the sameinformation?

Isn’t it possible to solve multiple types of tasks using the samelanguage?

24 / 113

Spread out over all disciplines of computational logic, there is anenormous expertise about KR and inference.

If only we could bundle what is known about KR and inference in acoherent scientific framework!?

25 / 113

The FO(·)-KBS project: an integration project

On the logical level: FO(·)Knowledge exists, it can be studied through the

methods of formal empirical science

Study “knowledge” by principled development of expressive KRlanguages

I Clear informal semantics

I Expressive languages, rich enough so that the information,relevant to solve a problem CAN be represented.

I Classical first-order logic (FO) as foundation, extended wherenecessary.

(FO(·)= family of extensions of FO)

26 / 113


On the logical level: FO(·)Knowledge exists, it can be studied through the

methods of formal empirical science

Study “knowledge” by principled development of expressive KRlanguages

I Clear informal semantics

I Expressive languages, rich enough so that the information,relevant to solve a problem CAN be represented.

I Classical first-order logic (FO) as foundation, extended wherenecessary.

(FO(·)= family of extensions of FO)

27 / 113


I On the inference level:

I Building solvers for various forms of inference for FO(·)I Integrating various solving techniques from various declarative

programming paradigms in one Knowledge Base System.

28 / 113

What do I mean with “inference”?

An Inference is a computational task:

I Input: a tuple of objects including a logic theory

I Output: a set of computed objects such that the output isinvariant under replacing the input theory by a logicallyequivalent theory.

I E.g., Deduction inferenceI Input theory T , sentence ϕI Output : true if T |= ϕ

I E.g., Query inference:I Input structure A, set expression {x : ϕ}I Output {x : ϕ}A

29 / 113


I On the application level:

I Towards a typology of tasks and computational problems interms of (the same) logic and inference.

I Eagerly searching for novel ways of using declarativespecifications to solve problems.

30 / 113

The FO(·)-KBS project is the long-term research goal of the KULeuven KRR research group.

31 / 113


FO(·)


Conclusions

32 / 113

Why FO as a foundation ?

FO: the language that failed in the seventies?I Too expressive for building “practical” systems?

I UndecidabilityI Expressivity/Efficiency trade-off

I FO is not suitable for describing common sense knowledge?I Nonmonotonic reasoning

I FO as a language is too difficult for practical use?I E.g., quantifiers

33 / 113


I FO, the outcome of 18’s and 19’s century’s research in

“laws of thought”

I E.g., Leibniz, De Morgan, Boole, Frege, Peirce

I FO is about a small set of connectives:

∧,∨,¬,∀,∃,⇔,⇒I Essential for KR, the right semantics in FO

I Crystal clear informal semantics

∀x(Human(x)⇒ Man(x) ∨Woman(x))means

All humans are men or women

I Model semantics as a way to formalize meaning.

34 / 113






∧,∨,¬, ∀,∃,⇔,⇒I Essential for KR, the right semantics in FO





35 / 113











36 / 113










I Model semantics as a way to formalize meaning.37 / 113

Claims

(1) Every expressive declarative modelling language has asubstantial overlap with FO, in one form or the other.

I For some languages, the syntax, conceptuology, terminologymay severely obscure the relationship.

I SQLI ALLOYI Zinc (a constraint programming language)I Answer Set Programming

(2) But FO is not enough for practical KR.

38 / 113

Claims





39 / 113

Claims





40 / 113

I But FO is undecidable?

I To be precise:I Deductive inference in FO is UndecidableI Other forms of inference are tractable (P) or almost (NP)I Other forms of inference have far more applications.I Many/most practical software problems are not deductive ones.

I Much richer “logics” are in use in industry (SQL, ILOG, Zinc)

I In the FO(·)-KBS project, we focus on expressivity with theaim to develop expressive natural KR languages suitable toexpress domain knowledge in REAL problems.

I We ignore the expressivity/tractability trade-off!

41 / 113

I But FO is undecidable?I To be precise:

I Deductive inference in FO is UndecidableI Other forms of inference are tractable (P) or almost (NP)I Other forms of inference have far more applications.I Many/most practical software problems are not deductive ones.




42 / 113






43 / 113






44 / 113






45 / 113

FO(·): turning FO into a practical KR language

I FO does not suffice for knowledge representation, modelling,specification

⇒ FO(

Types,ID,Agg,Arit,FD,Mod,HO,. . .

)

I TypesI (Inductive) DefinitionsI AggregatesI ArithmeticI Coinductive DefinitionsI Modal operatorsI Higher Order logicI . . .

The FO(·) language framework

46 / 113



⇒ FO(

Types,ID,Agg,Arit,FD,Mod,HO,. . .

)



47 / 113



⇒ FO(Types

,ID,Agg,Arit,FD,Mod,HO,. . .

)

I Types

I (Inductive) DefinitionsI AggregatesI ArithmeticI Coinductive DefinitionsI Modal operatorsI Higher Order logicI . . .


48 / 113



⇒ FO(Types,ID

,Agg,Arit,FD,Mod,HO,. . .

)

I TypesI (Inductive) Definitions

I AggregatesI ArithmeticI Coinductive DefinitionsI Modal operatorsI Higher Order logicI . . .


49 / 113



⇒ FO(Types,ID,Agg

,Arit,FD,Mod,HO,. . .

)

I TypesI (Inductive) DefinitionsI Aggregates

I ArithmeticI Coinductive DefinitionsI Modal operatorsI Higher Order logicI . . .


50 / 113



⇒ FO(Types,ID,Agg,Arit

,FD,Mod,HO,. . .

)

I TypesI (Inductive) DefinitionsI AggregatesI Arithmetic

I Coinductive DefinitionsI Modal operatorsI Higher Order logicI . . .


51 / 113



⇒ FO(Types,ID,Agg,Arit,FD

,Mod,HO,. . .

)

I TypesI (Inductive) DefinitionsI AggregatesI ArithmeticI Coinductive Definitions

I Modal operatorsI Higher Order logicI . . .


52 / 113



⇒ FO(Types,ID,Agg,Arit,FD,Mod

,HO,. . .

)

I TypesI (Inductive) DefinitionsI AggregatesI ArithmeticI Coinductive DefinitionsI Modal operators

I Higher Order logicI . . .


53 / 113



⇒ FO(Types,ID,Agg,Arit,FD,Mod,HO,. . . )



54 / 113

About adding Inductive Definitions to FO.

55 / 113

Some prototypical Inductive Definitions.

The two most common forms of ID’s.

The transitive closure TG of a graphG is defined inductively:- (x , y) ∈ TG if (x , y) ∈ G ;- (x , y) ∈ TG if for some vertex z,

(x , z), (z, y) ∈ TG .

Monotone inductive

We define A |= ϕ by induction onstructure of ϕ :- A |= q if q ∈ A;- A |= α ∧ β if A |= α and A |= β;- A |= ¬α if A 6|= α

(i.e., if not A |= α);

Induction over well-foundedorder

56 / 113

Properties of informal ID’s

I Linguistically, a set of informal rules (with negation)

I Semantically, two principles:I Non-constructively, the least set closed under rule applicationI Constructively, the set obtained by iterated rule application.

I These two principles coincide – Tarski!

I Only for monotone definitions!

57 / 113

Properties of informal ID’s

I Linguistically, a set of informal rules (with negation)

I Semantically, two principles:I Non-constructively, the least set closed under rule applicationI Constructively, the set obtained by iterated rule application.

I These two principles coincide – Tarski!

I Only for monotone definitions!

58 / 113

Informal (inductive) definitions (ID’s)

I Definitions in mathematics:I a special sort of knowledge:

I of mathematical precisionI broadly usedI intuitively well understoodI but not scientifically well-understood

I An ideal topic for formal empirical exact scientific study.

59 / 113

Adding ID’s to FO

I Inductive definitions frequently occur in KR and formalspecifications

I ID’s cannot be expressed in FO in general.I Compactness theorem

⇒ It is necessary to extend FO with them.

60 / 113

FO(ID) (Denecker 2000, Denecker& Ternovska 2008)

An FO(ID) theory:I FO sentencesI Definitions: sets of rules

Example: {∀x∀y(R(x , y)← G (x , y))∀x∀y(R(x , y)← ∃z(G (x , z) ∧ R(z , y)))

}∀x∀yR(x , y)

expresses that . . .R is the reachability graph of graph G and G is aconnected graph

Claim (KR 2014)

Rules under well-founded semantics provide a uniformformalism for expressing the most common forms of

definitions.

61 / 113




}∀x∀yR(x , y)

expresses that . . .

R is the reachability graph of graph G and G is aconnected graph

Claim (KR 2014)


definitions.

62 / 113




}∀x∀yR(x , y)


Claim (KR 2014)


definitions.

63 / 113




}∀x∀yR(x , y)


Claim (KR 2014)


definitions. 64 / 113

Another useful extension of FO are aggregates.

65 / 113

An example inductive definition with aggregate

A company A controls company B if the total sum ofthe shares in company B owned by A or by

companies controlled by A is more than 50%.

An inductive definition over aggregates.

The vocabulary

I Cont(x , y): company x controls company y .

I OwnsSh(x , y , s): company x owns s shares in company y .

{∀a∀b(Cont(a, b)← Sum

{(s, c) :

(c = a ∨ Cont(a, c))∧OwnsSh(c, b, s)

: s

}> 50)

}

66 / 113

An example inductive definition with aggregate

A company A controls company B if the total sum ofthe shares in company B owned by A or by

companies controlled by A is more than 50%.

An inductive definition over aggregates.

The vocabulary

I Cont(x , y): company x controls company y .

I OwnsSh(x , y , s): company x owns s shares in company y .{∀a∀b(Cont(a, b)← Sum

{(s, c) :

(c = a ∨ Cont(a, c))∧OwnsSh(c, b, s)

: s

}> 50)

}

67 / 113

FO(ID) as a rule formalism

I Many rule-based formalismsI Logic ProgrammingI DatalogI Answer Set ProgrammingI Description logics with rulesI Abductive Logic ProgrammingI Business rule systems

I Unclear semantical status of rules.I FO(ID) overlaps with many of them and provides two precise,

well-understood declarative sorts of rulesI Material implications, definitional rules

68 / 113

Future work

Adding

I Causal statements (ICLP 2014, ECAI 2014, NMR 2014)

I Modal operators

I Higher Order

69 / 113


FO(·)


Conclusions

70 / 113

How to use Logic for problem solving

I A logic theory is a bag of (descriptive) information

I A logic theory cannot be executedI A logic theory is not a programI A logic theory is not a representation of a problem

I So how can we use a logic theory to solve problems?

71 / 113

A Knowledge Base System (KBS)

Knowledge Base

Inference 2 Inference 3

Inference 4Inference 1

Checking consistency of schedule

University course scheduling

Computing a schedule

. . .

Updating a schedule

I Manages a declarative Knowledge Base (KB): a theoryI Equiped with different forms of inference:

I Model generation: Computing a scheduleI Model checking: Verifying consistency of a scheduleI Update and Revision: Updating a given scheduleI Deduction for verification of the KB

Querying of defined predicates, . . .

72 / 113


Knowledge Base


Inference 4Inference 1




. . .

Updating a schedule




73 / 113


Knowledge Base


Inference 4Model Generation




. . .

Updating a schedule


I Model generation: Computing a schedule

I Model checking: Verifying consistency of a scheduleI Update and Revision: Updating a given scheduleI Deduction for verification of the KB


74 / 113


Knowledge Base

Model checking Inference 3





. . .

Updating a schedule


I Model generation: Computing a scheduleI Model checking: Verifying consistency of a schedule

I Update and Revision: Updating a given scheduleI Deduction for verification of the KB


75 / 113


Knowledge Base

Model checking Revision Inference





. . .

Updating a schedule


I Model generation: Computing a scheduleI Model checking: Verifying consistency of a scheduleI Update and Revision: Updating a given schedule

I Deduction for verification of the KBQuerying of defined predicates, . . .

76 / 113


Knowledge Base

Model checking Revision Inference

Deduction, QueryingModel Generation



Computing a schedule. . .

Updating a schedule



Querying of defined predicates, . . . 77 / 113

A KBS demo

The course selection demo: interactive configurationhttp://krr.bitbucket.org/courses/

5 Used forms of inference:

I Model Checking (P)

I Propagation (P)

I Model Generation (NP)

I Model Generation+Optimization (NPNP)

I Explanation (P)

78 / 113

http://krr.bitbucket.org/courses/

A KBS demo

Demonstrating a principle that procedural programming languagescan’t do:

Reusing the same specification/theory/knowledgebase to solve different types of problems.

79 / 113

Implementation of KBS

IDP3:

I A KBS systemI Programming environment

I Programming with theories, structures, inference methodsI In an extension of procedural language Lua:

Built by KRR-members Broes De Cat, Bart Bogaerts, JoachimJansen, Pieter Van Hertum, Jo Devriendt, Ingmar Dasseville (andex-members Johan Wittocx, Maarten Marien, Stef De Pooter)

80 / 113

Implementation of KBS

I Forms of inference currently under development:I (Finite) Model expansion (the core component of IDP3)I OptimisationI PropagationI Querying structuresI ∆-model generation and revision:

I ∼view materialisation and update in databasesI computing & updating defined predicates

I Progression of temporal FO(.) theories.I Model revisionI Debugging, Explanation.

81 / 113

Model generation/expansion

Model Expansion

I Input:I An FO(.) theory TI An (finite) structure Ai for a subvocabulary of

T , expressing domain and data.

I Output: a model A of T expanding Ai

Special case: Herbrand Model Generation

82 / 113

The grounder

Grounding = Eliminating quantification

Term Rewrite

Type derivation

Symmetry

breaking

Lifted unit

propagation

Grounding with

bounds

Evaluate known

definitions

FO(.) theory

CNF – ECNF – SMT (- FlatZinc )

83 / 113

MinisatID: SMT solver

Solving = computing a model

MinisatID

Model

CNF – ECNF – OPB – ASP - QBF

PC solver

SAT-solver

ID-module0..*

Agg-module Minisat++

CP-module Gecode

84 / 113

Technology

Technologies from different computational logic areas integrated:

I Constraint Programming technology

I Sat Modulo Theory (SMT)

I Logic Programming

I Answer Set Programming

I MIP: Mixed Integer Programming

85 / 113

Solver AST (sec.) PSI (%)

minisatid 950.91 51.62g12cpx 1126.98 41.68fzn2smt 1143.47 38.13ortools 1316.25 30.65g12lazyfd 1306.10 30.31gecode 1354.65 29.51izplus 1350.42 28.05bprolog 1423.45 24.73jacop 1435.123 24.67g12fd 1424.80 23.57mistral 1525.83 16.91g12mip 1597.54 12.58

Table : Experimental evaluation of MiniZinc solvers on the CSPs inBenchmark Set B AmadiniGM13.

86 / 113

Benchmark # solved IDP # solved Gringo-Clasp

Perm. P. Matching 10 10Valves Location * 7 4Still-Life * 2 3Graceful Graphs 3 9Bottle Filling 10 10NoMystery 9 6Sokoban 7 5Ricochet Robots 7 10Crossing Minim. * 0 9Solitaire 8 9Weighted Sequence 10 10Stable Marriage 10 10Incremental Sched. 6 5Visit All core 6 7Knight’s Tour core 1 0Maximal Clique *core 0 1Graph Colouring core 7 4

Table : Experimental results for benchmarks of the 2013 ASPcompetition.

87 / 113

Other demos

I Model expansion with logic-based visualisation

I Programming with logical inference

I Temporal Reasoning: planning

I Temporal reasoning: execution and optimisation

Demos and examples can be accessed fromhttps://dtai.cs.kuleuven.be/software/idp/

88 / 113

https://dtai.cs.kuleuven.be/software/idp/

IDPd3: logic based visualisation

dtai.cs.kuleuven.be/krr/idp-ide/?present=

SudokuVisualisatie

I This application serves to solve sudoku puzzles and tovisualise the outcome. The theory T expresses the 3 laws ofsudokus: one occurrence of each number in each row, columnand block. Model expansion inference solves a puzzle specifiedin the input structure by returning a model A. De solution issudokuA. The user theory T D3 (see next slide) is mainly adefinition of IDPd3 graphical predicate and function symbolsdefined in terms of symbols interpreted in A. ∆-modelexpansion on T D3 and input structure A computes a valuefor these predicates which is then transferred to the graphicalprogram d3.

I This is a simple illustration of logic to transform one sort ofdatastructure in another.

89 / 113

dtai.cs.kuleuven.be/krr/idp-ide/?present=SudokuVisualisatie

dtai.cs.kuleuven.be/krr/idp-ide/?present=SudokuVisualisatie

theory T D3 : V out {{

d3 type(1, Cell(r,k)) = rect <-.

d3 rect width(1, Cell(r,k)) = 4 <-.

d3 rect height(1, Cell(r,k)) = 4 <-.

d3 color(1, Cell(r,k)) = "white" <-.

d3 x(1, Cell(r,k)) = 5*k <-.

d3 y(1, Cell(r,k)) = 5*r <-.

d3 type(1, Text(r, k)) = text <-.

d3 x(1, Text(r, k)) = 5*k <-.

d3 y(1, Text(r, k)) = 5*r + 1 <-.

d3 text size(1, Text(r, k)) = 3 <-.

d3 text label(1, Text(r, k)) = t <-

sudoku(r, k) = c & toString(c) = t.

d3 color(1, Text(r, k)) = "black" <-.

d3 order(1, Cell(r, k)) = 0 <-.

d3 order(1, Text(r,k)) = 1 <-.

}}

This definition defines slide 1(argument 1) with:

I for each cell (r , c) arectangular objectdenoted Cell(r,c), and atext object Text(r,k).

I It defines type, width,height, color, x and yposition of therectangular object.

I It defines type, text sizeand label, color, x and yposition of the text object

I The sudoku number atcell (r , c) is the label ofthe text object..

I that text objects are infront of rectangularobjects

∆-model expansion expands astructure interpreting sudokuinto a structure interpreting allthese graphical symbols. This isfed into d3. 90 / 113

IDPd3: an example

Input structure

sudoku = {1, 1→ 1; . . . ; 9, 9→ 4}. . .

↓ ∆-model generation

d3 type = {1,Cell(1, 1)→ rect; 1,Text(1, 1)→ text; . . . }d3 color = {1,Cell(1, 1)→ white; 1,Text(1, 1)→ black; . . . }d3 x = {1,Cell(1, 1)→ 5; 1,Cell(1, 2)→ 10; . . . }. . .

↓ translation to d3 input + d3

91 / 113

A prototype of a knowledge-based programming environment

I IDP3: A programming environment

I High level objects: vocabularies, theories, structures

I Functionalities for manipulation and inference

I Implemented in the language Lua

I A new way of mixing Declarative and Procedural knowledge

92 / 113

A demo: generating Sudoku-puzzles

Sudoku-puzzle requirements’

I (consistency) It should allow one unique solution

I (minimality) If we delete any value of the puzzle, it has atleast two solutions.

93 / 113

Background knowledge base in IDP

Vocabulary

vocabulary sudokuVoc {

extern vocabulary grid:: simpleGridVoc

type Num isa nat

type Block isa nat

Sudoku(Row ,Col) : Num

InBlock(Block ,Row ,Col)

}

Theory

theory sudokuTheory : sudokuVoc {

! r n : ?1 c : Sudoku(r,c) = n.

! c n : ?1 r : Sudoku(r,c) = n.

! b n : ?1 r c : InBlock(b,r,c) & Sudoku(r,c) = n.

! b r c : InBlock(b,r,c)

<=> b = ((r -1)/3)*3 + ((c -1)/3) + 1.

}

94 / 113

A demo: generating Sudoku-puzzles

Puzzle := emptyGenerate at most 2 solutions for PuzzleWhile 2 solutions were found do{

Select a random position where the two solutions differExtend Puzzle with the value of the first solution at this positionGenerate at most 2 solutions for Puzzle}

For each position of Puzzle that contains a value do {Delete the value at this positionGenerate at most 2 solutions for PuzzleIf there are two solutions, undo the deletion of the value.}

Visualize the puzzle and its unique solution

95 / 113

Procedures

procedure createSudoku () {

math.randomseed(os.time ())

local puzzle = grid:: makeEmptyGrid (9)

stdoptions.nrmodels = 2

local currsols = modelExpand(sudokuTheory ,puzzle)

while #currsols > 1 do

repeat

col = math.random (1,9)

row = math.random (1,9)

num = currsols [1][ sudokuVoc :: Sudoku ](row ,col)

until num ~= currsols [2][ sudokuVoc :: Sudoku ](row ,col)

makeTrue(puzzle[sudokuVoc :: Sudoku ].graph ,{row ,col ,num})

currsols = modelExpand(sudokuTheory ,puzzle)

end

printSudoku(puzzle)

}96 / 113

Discussion

Two sorts of inferences:

I generating solutions to puzzles: model expansionI Visualizing through ∆-model expansion

I computing a model of a definition ∆I A special case of model expansionI No searchI Can be implemented very differentlyI = View materialisation in deductive databases.

Acces and manipulation of structures.

I Structures are objects in the environment

I Puzzle and its solutions are structures

I Checking and updating values at positions of puzzle

97 / 113

Reasoning on Temporal theories

I Temporal theory T : Linear Time Calculus

I Use Model expansion for planning with optimisationI Use Progression for interactive execution.

I Input: T , structure A representing state at time iI Output: structure A′ representing possible state at time i + 1.

I Illustration: pacman.

IDP is the only system that we know of that can use the sameformal specification to solve both tasks.

98 / 113

Reasoning on Temporal theories

I Temporal theory T : Linear Time Calculus

I Use Model expansion for planning with optimisationI Use Progression for interactive execution.

I Input: T , structure A representing state at time iI Output: structure A′ representing possible state at time i + 1.

I Illustration: pacman.

IDP is the only system that we know of that can use the sameformal specification to solve both tasks.

99 / 113

A company running standard software systems on this principle:

I LogicBlox - Datalog :http://www.logicblox.com/

100 / 113

http://www.logicblox.com/

101 / 113

102 / 113

Future

Knowledge-based software engineeringI Important gains to be made:

I development timeI compactnessI correctnessI reuseI maintainability

I Great scientific and practical challenges

We are in the process of searching niches with industry where ourtechnology could already make a difference

103 / 113

A KRR-team with Ingmar Dasseville, Jo Devriendt and Matthiasvan der Hallen won the International Logic Programming andConstraint Programming competition with IDP.

104 / 113


FO(·)


Conclusions

105 / 113

Conclusion

I Computational logic is getting too complexI Too many logicsI FO(·): reuse and integrationI We need a M3C :-)

I Economies to be made:I Reusing specifications/modellingsI Reusing LanguagesI Reusing inference technologiesI Integration raises challenging new research questionsI Integration produces multiplication effects

I New insights in a fundamental KRR research questionI How do we use declarative K for problem solving?I What is the role of logic in computer science?I How to build better SE-systems using logic inference

106 / 113

Conclusion




107 / 113

Conclusion




108 / 113

Main Publications

I The logic FO(ID)

Denecker, Marc; Ternovska, Eugenia. A logic of nonmonotoneinductive definitions, ACM Transactions on Computational

Logic, volume 9, issue 2, 2008.

I The KBS-paradigm:

Denecker, Marc; Vennekens, Joost. Building a knowledge basesystem for an integration of logic programming and classical

logic, ICLP 2008

I Theory of course selection demo

Vlaeminck, Hanne; Vennekens, Joost; Denecker, Marc. Alogical framework for configuration software, PPDP 2009

109 / 113

The IDP system:Wittocx, Johan; Marien, Maarten; Denecker, Marc. The IDPsystem: A model expansion system for an extension of classicallogic, Denecker, Marc (ed.), Logic and Search, LaSh 2008Wittocx, Johan; Marien, Maarten; Denecker, Marc. Grounding FOand FO(ID) with bounds, JAIR, volume 38, 2010Wittocx, Johan; Marien, Maarten; Denecker, Marc. GidL: Agrounder for FO+, Thielscher, Michael; Pagnucco, Maurice (eds.),NMR 2008Marien, Maarten; Wittocx, Johan; Denecker, Marc; Bruynooghe,Maurice. SAT(ID): Satisfiability of propositional logic extendedwith inductive definitions, SAT 2008 - Theory and Applications ofSatisfiability Testing, 2008Marien, Maarten; Wittocx, Johan; Denecker, Marc. Integratinginductive definitions in SAT, Logic for Programming, ArtificialIntelligence, and Reasoning, Yerevan, Armenia, 2007.

110 / 113

The IDP programming environment:De Pooter, Stef; Wittocx, Johan; Denecker, Marc. A prototype ofa knowledge-based programming environment, INAP 2011

111 / 113

IDP, IDP3 and the demos’s are available via our webpagehttp://krr.bitbucket.org


Publications are on line via my webpagehttp://people.cs.kuleuven.be/~marc.denecker/

112 / 113

http://krr.bitbucket.org


http://people.cs.kuleuven.be/~marc.denecker/

Documents

The FO() Knowledge Base System project - VUBThe fundamental KRR research question I Humans experts possess (declarative) knowledge. I They use it I to accomplish tasks I to solve problems