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.
- Is splitting up more efficient?
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
Refinement
By krr
Refinement
- 1,066