Core Chase Trees #
Next to the CoreChaseBranch definition, we also define a tree version in line with what is done for our generic and regular chase structures.
Equations
- CoreTreeDerivation rules = TreeDerivation (CoreChaseNode rules) (RestrictedObsolescence sig) rules
Instances For
Finiteness of FactSets in the Core Chase #
If we start a CoreTreeDerivation on a finite fact set, all other fact sets (and cores) also remain finite.
For regular chase derivations, we only show this for ChaseBranches that start on a database. However, here we also require such a result on auxiliary results that we show for the CoreTreeDerivation.
If the initial facts are finite, then the facts of every node are finite.
If the initial core is finite, then the cores of every node are finite.
Homomorphisms along the Chase #
In the regular TreeDerivation, each steps can only add facts, which makes consecutive nodes subsets of each other.
This is not true for the core chase. But at least, we can always find a homomorphism into the following fact sets. (This trivially holds for the regular tree derivation as well since with the subset relation the id mapping always forms such a homomorphism.)
For each derivation, there is a homomorphism from its root into every node.
The root's core cannot occur again in the child trees. If this was the case and since we always find homomorphism from to successor cores, we can argue that then the triggers would have already been satisfied. The same theorem exists for regular TreeDerivations but the argument is easier for them.
The root cannot occur in the childTrees. Otherwise, the same fact set would occur twice in the chase. But since we always find homomorphism from to successor fact sets, we can argue that then the triggers would have already been satisfied. The same theorem exists for regular TreeDerivations but the argument is easier for them.
By root_not_mem_childTrees_of_finite, if we have a subtree but our root occurs in the subtree, then our subtree is equal to us.
Predecessor Relation #
We port the predecessor results from the TreeDerivation that are there only shown for derivations with RegularChaseNodes.
We also add a few results on top that are specific to the core chase such as exists_homomorphism_of_prec or core_not_subset_of_strict_predecessor (where the latter is a variant of RegularTreeDerivation.facts_not_subset_of_strict_predecessor.
For each node, there exists a homomorphism to each of its successors.
The node is a strict predecessor of each of its childNodes.
The core of a strict successor cannot be a subset of our core. Otherwise, our current core would not be a core.
Terms in the Chase #
We make some general observations about certain terms that might occur in the chase.
- Constants can only originate directly from rules or from the initial fact set. No other constants can be introduced.
- Functional terms can either also originate from the initial fact set or they are introduced as fresh terms by a trigger.
The second observation entails that the precense of a functional term that does not occur in the initial fact set implies
that the trigger that introduces this term must have been applied in some ChaseNode.
Constants in the chase can only come from the initial fact set or from a constant in a rule.
Each functional term in the chase originates as a fresh term from a trigger if it was not already part of the initial fact set.
If a functional term occurs in the chase, then the trigger that introduces this term must have been used in the chase, unless the term already occurs in the initial fact set.
Core Chase Result #
Oppossed to regular tree derivations, the result of a core tree derivation is only defined if the derivation terminates. Then it is simply the last element. Just like for RegularTreeDerivations however, the result also models all rules.
Equations
Instances For
Since the result is only defined for terminating trees, it must be finite
(which does not mean that each individual fact set is finite as well, this would only hold for proper CoreChaseTrees).
Each element of the result models the rules.
Equations
- CoreChaseTree kb = ChaseTree (CoreChaseNode kb.rules) (RestrictedObsolescence sig) kb
Instances For
Finiteness of FactSets in the Core Chase #
Just as in a regular ChaseTree, every fact set (and every core) that occurs in the CoreChaseTree is finite simply since the (initial) database is finite and since each step only adds finitely many facts.
Database Containment #
Even though we do not have fact set monotonicity in the core chase, it is still true that the database occurs in every fact set and core in the chase.
This is because the database only features constants and these can never be remapped by any homomorphism.
We also have a result here stating that every member of the CoreChaseTree result is a model.
The database is a subset of each node since the database only contains constants which can never be remapped by homomorphisms.
Each result member of a CoreChaseTree models the whole KnowledgeBase.
Predecessor Relation #
Compared to the CoreChaseDerivation, we can now drop the explicit finiteness conditions.
The node is a strict predecessor of each of its childNodes.
The core of a strict successor cannot be a subset of our core. Otherwise, our current core would not be a core.
Terms in the Chase #
We make some general observations about certain terms that might occur in the chase.
- Constants can only originate directly from rules or from the initial fact set. No other constants can be introduced.
- Functional terms can either also originate from the initial fact set or they are introduced as fresh terms by a trigger.
The second observation entails that the precense of a functional term that does not occur in the initial fact set implies
that the trigger that introduces this term must have been applied in some ChaseNode.
Constants in the chase must be in the database or in some rule.
Each functional term in the chase originates as a fresh term from a trigger.
If a functional term occurs in the chase, then the trigger that introduces this term must have been used in the chase.
Used triggers remain inactive #
Here we prove that triggers used in the core chase remain inactive from this point. Not only that but also every equivalent trigger (producing the same result) is inactive from this point on. For regular chase trees this is trivial because of fact monotonicity but here it is not quite obvious (even though it's intuitive).