Datalog seems like a way to "spell" knowledge graph (KG).
The article touches on Datalog statements changing over time. One ingredient I think would be good to add to the system is to make every statement carry "providence" metadata. The providence should be sufficient to enable later confirmation that a statement is still valid or if the statement needs to be reformed without the need to remake the entire graph from scratch.
I would make at least some forms of providence follow a strict schema that is defined for the subject matter that is being captured. For example, statements about a code base should refer to the source files and their version (file modification date, content hash) from which the statements were concluded. When a source file is modified we may then find all statements made from them and reevaluate just those statements.
The next level would be to keep statements even if reevaluation breaks them and add a method to derive a subgraph for a given state of the subject. For example, over many releases of a code base, a lot of statements would not change, some would. Having a graph that spans all conclusions about all releases of a code base and a way to form the subgraph for a specific release would allow the system to efficiently target queries for a particular release.
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.
The OP rediscovered that frontier models prefer to reason over logical scaffolding for complex tasks. They excel at technical work with many constraints as they can perfectly maintain the references, flow graph, and evidence states while they works through your conformance gates.
Many people here might disagree; but they're holding it wrong. Those folks should ask:
1. Am I using free tier tokens?
2. Am I working on trivial software?
3. Am I expecting models to adapt to my ways of thinking?
Anyone affect by any of these three mistakes will maintain an impenetrable filter of perpetual ignorance about model capabilities. Since the OP came with receipts, I'm reproducing an example graph below.
Comments
Datalog seems like a way to "spell" knowledge graph (KG).
The article touches on Datalog statements changing over time. One ingredient I think would be good to add to the system is to make every statement carry "providence" metadata. The providence should be sufficient to enable later confirmation that a statement is still valid or if the statement needs to be reformed without the need to remake the entire graph from scratch.
I would make at least some forms of providence follow a strict schema that is defined for the subject matter that is being captured. For example, statements about a code base should refer to the source files and their version (file modification date, content hash) from which the statements were concluded. When a source file is modified we may then find all statements made from them and reevaluate just those statements.
The next level would be to keep statements even if reevaluation breaks them and add a method to derive a subgraph for a given state of the subject. For example, over many releases of a code base, a lot of statements would not change, some would. Having a graph that spans all conclusions about all releases of a code base and a way to form the subgraph for a specific release would allow the system to efficiently target queries for a particular release.
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.
I think you mean provenance, not providence
*provenance
The OP rediscovered that frontier models prefer to reason over logical scaffolding for complex tasks. They excel at technical work with many constraints as they can perfectly maintain the references, flow graph, and evidence states while they works through your conformance gates.
Many people here might disagree; but they're holding it wrong. Those folks should ask:
1. Am I using free tier tokens? 2. Am I working on trivial software? 3. Am I expecting models to adapt to my ways of thinking?
Anyone affect by any of these three mistakes will maintain an impenetrable filter of perpetual ignorance about model capabilities. Since the OP came with receipts, I'm reproducing an example graph below.
From a plan in my active research project: