When you say “data model”, what are you referring to? How Asami stores data, or how it models edges in a graph? The latter is really what the API tells you, though I hope to expand that soon. The former is fixed, and I explain it in a couple of talks

The latter. The concrete implementation isn't as important to me as what types of relations between facts I can model using it. I'm also wondering if, even though Asami is a schemaless DB, attributes can have attributes https://docs.datomic.com/on-prem/schema/schema.html#attributes.

Datomic schemas are more about data types on attributes. This is really only relevant to Asami when executing transactions, since single/multi-cardinality attributes change what adding a value means, and ownership indicates which other things get deleted when an entity it taken away. Sure, I can store this in a graph, read it, and use this to moderate how transactions are executed. I’m thinking about that. Meanwhile, I’m looking at allowing transactions to take a :schema parameter when loading data, and this schema will be used during that transaction.

That’s happening much sooner

Things are a bit slow right now. This is entirely on my own time now. I’ve had a couple of big talks to complete, I just wrapped up on a side project, I’m dealing with a health issue this week (nearly resolved), and am about to travel for Christmas. I’m hoping to pick up my pace in the new year.

If I were interested in the details of how this might be possible, which namespace should I read through?

Well, it happens in 2 places. The first is in asami.index. Functions like index-add accept 3 elements labeled “a”, “b”, and “c” (Depending on the index, this will be some combination of “entity”, “attribute” and “value”), an id, and a value called t. This stores a statement in an index as {:a {:b {:c {:t t, :id id}}}}. It’s yet to be committed, but there will also be a vector added to the graph that has the statement conj’ed on. The other place is asami.durable.graph. The BlockGraph implementation has 5 indexes: 4 of them (`spot`, post, ospt, tspo) hold statements, and the 5th (`pool`) maps internal ids to data. You’re looking for the tspo index. This is a flat file that holds data of [transaction, subject, predicate, object] (where subject=entity, predicate=attribute, object=value). The statement ID is the offset into this file. The other 3 indexes (whose names end with t) hold the statement ID in the 4th position. (it’s t instead of i, because it was originally going to be a transaction ID, but then I pivoted to giving every statement its own ID instead).

Exposing this isn’t too hard, but there are lots of bits. I need to extend the API so that resolve-triple can also take statement IDs. More importantly, I need to extend the query language to access them.

I plan on doing this via patterns that look like this: [e a v t :as ?id]

where the pattern can be truncated, so that the t can be skipped, or the v t, or the a v t.

It’s just a little messy to get it all out and dispatch it appropriately 🙂