I have thoughts about knowledge graphs, I wonder if someone is willing to sanity check this:
- A delta-CRDT based hypergraph where the canonical units represent change, not state. A "delta" here establishes a relationship with specific semantics as of a point in time.
{
id: 1,
timestamp: ...,
creator: user_1,
relations: {
employer: { reference: acme_inc, backpointer: employees },
employee: { reference: joe_smith, backpointer: employer }
}
}- This is more complex than a basic triple, but not by much. The idea is that you are encoding a full bi- (or poly-)directional relation rather than mutating values on different objects. You just accumulate (and contextually replicate) deltas. Want to negate a given relationship? Don't delete it, append a new delta with the 'negates' relation targeting the old one, etc.
- State, then, becomes a question of filtering down to the deltas you care about and then reducing them into a representation that applies to your use case.
- I call this a
rhizomatic datastore, because the flat append-only list of deltas can be filtered and materialized into any number of representations. The rhizome is the set of all deltas - but then you can maintain stateful views of the rhizome separately and trivially patch them with applicable deltas as they come in.
- In an agent model, I'm thinking I'd use a vector store to normalize relation and backpointer names. For instance, if I say 'joe smith is employed by acme' or 'joe smith works for acme' or 'joe smith's job is over at acme' those should all resolve to the same delta, which either reuses existing relation and backpointer names from the vector store or creates new ones.
- Querying this whole thing requires a root node and a schema to apply. I'm actually thinking graphql would probably be the simplest way to go.
Putting it all together, if I'm talking to my AI agent about Joe Smith and his job, it doesn't need to pull in everything it knows about Joe Smith. We can create a schema that represents an EmployedPerson, which filters down to a limited set of relations. Those relations are then used to select applicable deltas, which get grouped together and injected into the prompt in a concise way.
I feel like this approach gives us a lot more flexibility than simply using 'name' attributes on 'entity' and 'relationship' objects, you know? It also encodes temporality and provenance for every piece of information we have access to.
I'm in a position to potentially implement a proof of concept, and I'm working on a writeup to justify it. I'm posting here to ask y'all for your thoughts.
