if you aren't familiar with the literature, then good on you for getting the right insight. provenance and support are staples of the datalog world.
the other really handy thing here is that it very straightforward to differentiate datalog rule sets. so if you change a fact, you can run a smaller solution that tells you which consequences are affected by the change. under the assumption that the evaluator is pure, we don't need to keep the support graph as you suggest, we can just generate the deltas from evolution of the differentiated form.
detailed provenance can be of real application utility, but if you just care about the accounting, keeping track of the number of supports for each fact is sufficient.
another model which is fun is to make the version of the database (monotonic time) an explicit field in your base facts, assuming you can afford to keep the whole history. a deletion then is just a negative-support, and you can ask questions about the state of the world at any time.
Comments
if you aren't familiar with the literature, then good on you for getting the right insight. provenance and support are staples of the datalog world.
the other really handy thing here is that it very straightforward to differentiate datalog rule sets. so if you change a fact, you can run a smaller solution that tells you which consequences are affected by the change. under the assumption that the evaluator is pure, we don't need to keep the support graph as you suggest, we can just generate the deltas from evolution of the differentiated form.
detailed provenance can be of real application utility, but if you just care about the accounting, keeping track of the number of supports for each fact is sufficient.
another model which is fun is to make the version of the database (monotonic time) an explicit field in your base facts, assuming you can afford to keep the whole history. a deletion then is just a negative-support, and you can ask questions about the state of the world at any time.