Refinement

Matthias van der Hallen

Recap: Knowledge Base Paradigm

  • Represent the knowledge in a domain in a Knowledge Base
    • ​Vocabulary
    • Theory
  • Use multiple inferences to solve different problems concerning that knowledge
  • + Procedural interface

Drawbacks of the Knowledge Base Paradigm:

  • Loosely connected components of domain Knowledge

  • Knowledge exists on different abstraction levels:
    • Leads to complicated specifications
    • Potentially hard for a solver
      • Is splitting up more efficient?
        Case studies s.a. lock scheduling problem or graph mining suggest that.

Example: the AREI

(Algemeen Reglement op Elektrische Installaties)

Thesis making an application helping electricians or homeowners to configure law-abiding installations

Example: the AREI

(Algemeen Reglement op Elektrische Installaties)

Knowledge of AREI comes in separate, loosely linked parts:

  • Routing of circuit through rooms
  • Circuit breaker mechanisms per circuit
  • Number of allowed devices per type / circuit
  • Cable thickness and power usage 

(Roughly related to the different AREI chapters)

Example: the AREI

(Algemeen Reglement op Elektrische Installaties)

Passed rooms Other circuits Installed devices
Circuit Routing yes yes no*
Power Analysis no no yes

Example: the AREI

(Algemeen Reglement op Elektrische Installaties)

An electrician would like to focus only on power analysis of a specific circuit

A solver potentially performs better when the problem is split and recombined later

Even modellers might prefer the modellin

Other examples:

Even modellers might prefer the modellin

In the notary application, we are zooming in from more general law to one specific dwelling.

In the lock scheduling problem, assigning ships a place within a lock is zooming in on a lock.

Idea: Refinement

Create a collection or even hierarchy of interlinked (smaller) knowledge kernels within a knowledge base

Relations between the kernels through their respective vocabularies

Circuit Routing

Power Analysis

KBS

projections

Vocabulary projections

A projection can 'simplify' a vocabulary w.r.t. a context: a tuple of constants.

Projecting from circuit routing to power analysis:

  • A specific circuit \(c_1\) as projection context
  • Reduces the arity of some symbols
  • Changes functions InstalledOn(Installation) : Circuit
    to predicates like Installed(Installation)
  • Other predicates can be dropped entirely, e.g. InstallationLocation(Installation) : Room

Vocabulary projections

Inductive definitions can help perform projections

{
  ! t3 t4 : ProjectedPredicate(t3,t4) <- Predicate1(c1,c2,t3,t4).
  Proposition <- Predicate2(c1).
  ! t2 : ProjectedFunction=x <- Function1(c1,t2)=x.
  Constant=x <- Function2(c2)=x.
  ! t1 t2 : Predicate(t1,t2) <- Function3(t1,t2)=c2.
}

But we want a structured and declarative way of specifying these and more involved relations between vocabularies

Future Topics:

  • How can information flow back from one problem to a subproblem

Future Topics:

  • How can information flow back from one problem to a subproblem
  • Imagine a Master theory and its vocabulary: Can we automate translation?

Future Topics:

  • How can information flow back from one problem to a subproblem
  • Imagine a Master theory and its vocabulary: Can we automate translation?
  • Zooming in conditionally: some special circuits have very different theories governing them; zooming conditionally removes implications

Master thesis topics

Thank you

Made with Slides.com