HO Support in Logic Specification Languages 

for Data Mining

Matthias van der Hallen - ICLP DC (31/08/15)

FO(·)

A grounder and solver that supports certain FO(·) extensions

Family of Languages extending FO with:

  • Type System
  • Arithmetic
  • Inductive Definitions
  • (Partial) Functions
  • Aggregates
  • ...

Data Mining

Challenges:

Large, or even infinite, domains: costly enumeration

Potentially backed by a traditional database

Same concepts reoccur often.

E.g. Homomorphism, isomorphism

Not much support for this in KR languages

Modularity

We write the transitive closure of binary relations very often:

∀a, b : ClosureOfP ( a, b ) ← P( a, b ).
∀a, b : ClosureOfP ( a, b ) ← ∃c : P( a, c ) ∧ P( c, b ).

 

  • Structured Recursive & Generic Types: ADTs
  • Relations as First Class Citizens
  • Library Building Constructs

FO(·) misses:

∀a, b : ClosureOfP ( a, b ) ← P( a, b ).
∀a, b : ClosureOfP ( a, b ) ← ∃c : P( a, c ) ∧ P( c, b ).

Modularity

We write the transitive closure of binary relations very often:

∀a, b : ClosureOfP ( a, b ) ← P( a, b ).
∀a, b : ClosureOfP ( a, b ) ← ∃c : P( a, c ) ∧ P( c, b ).

Modularity

∀a, b : ClosureOfP ( a, b ) ← P( a, b ).
∀a, b : ClosureOfP ( a, b ) ← ∃c : P( a, c ) ∧ P( c, b ).

 

  • Structured Recursive & Generic Types: ADTs
  • Relations as First Class Citizens
  • Library Building Constructs

FO(·) misses:

∀a, b : ClosureOfP ( a, b ) ← P( a, b ).
∀a, b : ClosureOfP ( a, b ) ← ∃c : P( a, c ) ∧ P( c, b ).

Modularity

  • Library Building Constructs: Templates

Higher Order Support is an important step towards Modularity:

Templates are Second Order definitions

{
   Closure(P,Q) ← {
                    Q(x,y) ← P(x,y) ∨ (∃ z: Q(x,z)∧Q(z,y)).
                   }.
}

Modularity

  • Library Building Constructs: Templates

Higher Order Support is an important step towards Modularity:

Templates are Second Order definitions

{
   Closure(P,Q) ← {
                    Q(x,y) ← P(x,y) ∨ (∃ z: Q(x,z)∧Q(z,y)).
                   }.
}

Problem:

Many solving systems, such as IDP, depend on a grounding phase.

Grounding translates FO(·) constraints to a propositional level

but when domain enumeration is costly or impossible, we can't ground naively.

∀a : P(a) ⇒ ∀b : Q(a,b).
¬P(a1) ∨ Q(a1,b1).
¬P(a1) ∨ Q(a1,b2).
¬P(a2) ∨ Q(a2,b1).
¬P(a2) ∨ Q(a2,b2).

Smart Techniques

  • Lazy Grounding & Relevance
  • Quantifier Elimination & Rewriting
  • Oracles

We need smarter techniques to handle large domains and higher order constraints:

Lazy Grounding & Relevance

∀a : P(a) ⇒ ∀b : Q(a,b).
  • Grounds only when necessary
  • Only partially if formula is complex
  • Only relevant literals, i.e. the program's truth value depends on that of the literal

For large domains, this is grounded when:

  • P(a) is made True for some a

  • Q(a, b) is made False for some (a, b)

Quantifier Elimination

Reducing the number of quantifiers makes for smaller groundings

Skolemization: Replace existential quantifiers by (Skolem) variables:

  • Unnested ∃: introduce skolem variable
  • Nested ∃: introduce functions
∃a : P(a).
∀a : ∃b : Q(a,b).
P(S).
∀a : Q(a,S(a)).

Requires support for functions

Extensions & other techniques exist:

  • Rewrite ∀ quantifiers to ​∃
  • Rewritings such as in Presburger Arithmetic (Cooper1972)

Oracles

Technique to allow quantification over predicates:

  • Ensure quantifications are existential
  • Encapsulate quantification body as theory
  • Solve this Existential SO theory using
    subsolver as oracle
  • Require it to pass/fail

Questions?

Matthias van der Hallen

matthias.vanderhallen@cs.kuleuven.be

Celestijnenlaan 200A, Leuven

+32 16 37 39 84

Made with Slides.com