Core Chase Derivations and Branches #
Similar to RegularChaseDerivations and RegularChaseBranches, we define CoreChaseDerivations and CoreChaseBranches.
The main result of this file is that the result of a CoreChaseBranch models the underlying KnowledgeBase.
Equations
- CoreChaseDerivation rules = ChaseDerivation (CoreChaseNode rules) (RestrictedObsolescence sig) rules
Instances For
Finiteness of FactSets in the Core Chase #
If we start a CoreChaseDerivation 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 CoreChaseDerivation.
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 ChaseDerivation, 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 next fact set. (This trivially holds for the regular chase 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 head into every node.
The head's core cannot occur again in the tail. 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 ChaseDerivations but the argument is easier for them.
The head cannot occur in the tail. 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 ChaseDerivations but the argument is easier for them.
By head_not_mem_tail_of_finite, if we have a suffix but our head occurs in the suffix, then our suffix is equal to us.
And now by eq_of_suffix_of_head_mem_of_finite, if we have two suffixes $C$ and $D$, and the head of $D$ occurs in $C$, then $D$ is a suffix of $C$. This also holds for regular chase derivations but for different reasons (see the differences of head_not_mem_tail_of_finite and ChaseDerivation.head_not_mem_tail.)
Predecessor Relation #
We port the predecessor results from the ChaseDerivation that are there only shown for derivations with RegularChaseNodes. But since we have suffix_of_suffix_of_suffix_of_head_mem_of_finite, we can also show these for CoreChaseDerivations given that the cores are finite.
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 ChaseDerivation.facts_not_subset_of_strict_predecessor.
The predecessor relation is antisymmetric.
The predecessor relation is transitive.
We can express fairness in terms of the predecessor relation: For each trigger, there is a node such that the trigger is not active for each of the node's successors.
For each node, there exists a homomorphism to each of its successors.
The strict predecessor relation is asymmetric.
The strict predecessor relation is transitive.
The strict predecessor relation is transitive with respect to the regular predecessor relation.
The strict predecessor relation is transitive with respect to the regular predecessor relation.
The ChaseDerivationSkeleton.head is a strict predecessor of ChaseDerivationSkeleton.next.
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 chase derivations, the result of a core chase derivation is only defined if the derivation terminates. Then it is simply the last element. Just like for RegularChaseDerivations however, the result also models all rules.
Instances For
The result is a model of all rules. This is true because otherwise, there would be an active trigger on the result. But we already know that no trigger can be active on the last node of a terminating chase derivation.
Equations
- CoreChaseBranch kb = ChaseBranch (CoreChaseNode kb.rules) (RestrictedObsolescence sig) kb
Instances For
Finiteness of FactSets in the Core Chase #
Just as in a regular ChaseBranch, every fact set (and every core) that occurs in the CoreChaseBranch 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. This result is essential for showing that the core chase result is a model, which we also show here.
The database is a subset of each node since the database only contains constants which can never be remapped by homomorphisms.
The result of a CoreChaseBranch models the whole KnowledgeBase.
Predecessor Relation #
Compared to the CoreChaseDerivation, we can now drop the explicit finiteness conditions.
The predecessor relation is antisymmetric.
The predecessor relation is transitive.
We can express fairness in terms of the predecessor relation: For each trigger, there is a node such that the trigger is not active for each of the node's successors.
The strict predecessor relation is asymmetric.
The strict predecessor relation is transitive.
The strict predecessor relation is transitive with respect to the regular predecessor relation.
The strict predecessor relation is transitive with respect to the regular predecessor relation.
The ChaseDerivationSkeleton.head is a strict predecessor of ChaseDerivationSkeleton.next.
The core of a strict successor cannot be a subset of our core. Otherwise, our current core would not be a core.
The strict_predecessor relation is WellFounded.
Equations
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.
Minimal Nodes with given Properties #
If a property hold for a given node in the chase, then there must be a "first" node for which this property holds. That means that this node is minimal with respect to the ≺ relation.
The result follows by the well foundedness of the ≺ relation.
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 derivations this is trivial because of fact monotonicity but here it is not quite obvious (even though it's intuitive).