# Refinement

Matthias van der Hallen

• 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:
• 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

By krr

• 944