This is a very interesting discussion that I’m going to have to digest. I’m going to ponder whether what you’re doing with ECAI and what I’m doing with tapestry theory are complementary. Our Brainstorm product has two parts: the Grapevine, the prototype of which is what we’re currently building with you Mleku, and the knowledge graph (or sometimes I call it concept graph). The knowledge graph encodes not just mundane content, facts and information, but also ontologies, semantics, etc that we can in principle build individually but prefer to build collaboratively — which is what the grapevine is for. The knowledge graph supports queries like: give me the list of all widgets in my local graph database with characteristics A, B, and C. These are well defined, generalizable and extensible path queries that can be written using cypher. It requires the uuid for the node that represents the concept of widgets; if we don’t have that uuid, we can find it using the same cypher query. Mleku are those the kinds of queries you’re talking about when you say you can optimize for them?

Replies (1)

yes, of course, you think i wouldn't be confident i can do it while i talk about tackling this? https://git.mleku.dev/mleku/algebraic-decomposition/src/branch/dev/ALGEBRAIC_DECOMPOSITION.md i understand the general concepts well enough that i think i can actually build according to the steps laid out in the later part of that document. i actually didn't refer to any specs or papers when i designed the vertex tables that orly now uses to accelerate some of the nip-01 queries that touch graph relations. i independently invented it. not even sure if anyone else has done it that way, but i think so, because claude seemed to indicate that this technique of bidirectional references in tables are used for graph traversal without the cost of table intersection (aka, adjacency free thingy). see , i don't remember exact nomenclature, i only remember concepts, and usually, visually.