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
Introduction: the FO(·) KBS project
FO(·)
Inference of the KBS: progress reportModel expansion and visualisationImperative + Declarative Programming (IDP)
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
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.
10 / 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.
11 / 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.
12 / 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.
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
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
16 / 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
17 / 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
18 / 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
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
“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)
21 / 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)
22 / 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)
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
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)
27 / 113
The FO(·)-KBS project: an integration project
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
The FO(·)-KBS project: an integration project
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
Introduction: the FO(·) KBS project
FO(·)
Inference of the KBS: progress reportModel expansion and visualisationImperative + Declarative Programming (IDP)
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
Why FO as a foundation ?
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
Why FO as a foundation ?
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.
35 / 113
Why FO as a foundation ?
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.
36 / 113
Why FO as a foundation ?
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.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
(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.
39 / 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.
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.
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!
42 / 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!
43 / 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!
44 / 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!
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(·): 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
47 / 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 Types
I (Inductive) DefinitionsI AggregatesI ArithmeticI Coinductive DefinitionsI Modal operatorsI Higher Order logicI . . .
The FO(·) language framework
48 / 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) Definitions
I AggregatesI ArithmeticI Coinductive DefinitionsI Modal operatorsI Higher Order logicI . . .
The FO(·) language framework
49 / 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 Aggregates
I ArithmeticI Coinductive DefinitionsI Modal operatorsI Higher Order logicI . . .
The FO(·) language framework
50 / 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 Arithmetic
I Coinductive DefinitionsI Modal operatorsI Higher Order logicI . . .
The FO(·) language framework
51 / 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 Definitions
I Modal operatorsI Higher Order logicI . . .
The FO(·) language framework
52 / 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 operators
I Higher Order logicI . . .
The FO(·) language framework
53 / 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
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
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.
62 / 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.
63 / 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. 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
Introduction: the FO(·) KBS project
FO(·)
Inference of the KBS: progress reportModel expansion and visualisationImperative + Declarative Programming (IDP)
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
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, . . .
73 / 113
A Knowledge Base System (KBS)
Knowledge Base
Inference 2 Inference 3
Inference 4Model Generation
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 schedule
I Model checking: Verifying consistency of a scheduleI Update and Revision: Updating a given scheduleI Deduction for verification of the KB
Querying of defined predicates, . . .
74 / 113
A Knowledge Base System (KBS)
Knowledge Base
Model checking Inference 3
Inference 4Model Generation
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 schedule
I Update and Revision: Updating a given scheduleI Deduction for verification of the KB
Querying of defined predicates, . . .
75 / 113
A Knowledge Base System (KBS)
Knowledge Base
Model checking Revision Inference
Inference 4Model Generation
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 schedule
I Deduction for verification of the KBQuerying of defined predicates, . . .
76 / 113
A Knowledge Base System (KBS)
Knowledge Base
Model checking Revision Inference
Deduction, QueryingModel Generation
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, . . . 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
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
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
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
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
Introduction: the FO(·) KBS project
FO(·)
Inference of the KBS: progress reportModel expansion and visualisationImperative + Declarative Programming (IDP)
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
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
107 / 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
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
https://dtai.cs.kuleuven.be/software/idp/
Publications are on line via my webpagehttp://people.cs.kuleuven.be/~marc.denecker/
112 / 113