This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-12-10
Channels
- # adventofcode (54)
- # announcements (30)
- # asami (13)
- # aws (10)
- # babashka (16)
- # babashka-sci-dev (44)
- # beginners (95)
- # calva (63)
- # clara (10)
- # clj-kondo (3)
- # cljfx (6)
- # cljs-dev (7)
- # cljsrn (1)
- # clojure (68)
- # clojure-europe (59)
- # clojure-nl (7)
- # clojure-norway (12)
- # clojure-spec (6)
- # clojure-uk (6)
- # clojurescript (4)
- # component (4)
- # conjure (5)
- # datomic (3)
- # deps-new (1)
- # events (4)
- # exercism (1)
- # figwheel-main (1)
- # fulcro (33)
- # gratitude (1)
- # improve-getting-started (3)
- # jobs (3)
- # lsp (5)
- # malli (10)
- # membrane (5)
- # music (3)
- # nextjournal (6)
- # off-topic (42)
- # pedestal (2)
- # polylith (14)
- # portal (11)
- # re-frame (42)
- # releases (3)
- # reveal (4)
- # shadow-cljs (62)
- # tools-build (1)
- # tools-deps (3)
- # web-security (1)
- # xtdb (3)
I'm trying to understand Asami's data model a bit better while also thinking about how to model metadata about assertions in Asami (things like the source of a fact). Given that every triple needs to have a specific node identifier, is it possible to make datoms/triples the subjects/entities of other facts (as https://blog.liu.se/olafhartig/2019/01/10/position-statement-rdf-star-and-sparql-star/)?
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.
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.