What do you mean by that?

I think conceptually thats handled by the same structure as transactions

for entity E1 you learn fact F1 has a value of V1

for entity E1 you learn fact F2 has a value of V2

and you learn that in transaction T1

By “nested Datom” I mean that one datom can be the entity (“E” position) of another datom.

What use case are you thinking of? As Ethan said, transactions are meant to cover most of these. Datomic doesn’t support arbitrary reification for any entity value (i.e. like RDF does), but transactions are a reification mechanism over groups of datoms (the transaction data)

For example, to represent this information: “Rich is employed by Cognitect as the chief architect.”

(trying ideas..)

I’m not sure how that would apply?

I guess a Datom essentially can connect two “things” (Entity and Value). When you need to connect more than two things - as in my example: “Rich”, “Cognitect” and ” Chief Architect” are three “things” - it seems to make sense to use nesting.

This nesting is something that the “Associative Model of Data” supports (see my above thread). Also, it seems it is a proposed addition to the RDF standard called “RDF-star”.

I think what you want isn't "nested datoms" - datoms can represent this relationship

xtdb afaik decomposes documents with nested structures into datoms internally

it might be just a way to turn

{:thing {:wow 1}}

into a set of datoms which represent the nesting

What is the advantage over either an entity to represent the relationship or a compound value with two references?

Ie the usual ERD modeling

I’m in the process of trying to find out. How would you express “Rich is employed by Cognitect as the Chief Architect.” as Datoms?

Assuming the point is multiple employers at once: [rich :employment e][e :employer cognitect][e :role chief-architect]. Or even reverse direction of :employment

Same thing I would do in a relational db or a doc db

Which datom states that Rich is the Chief Architect?

[e :role chief-architect], where e is the identity of the employment

I guess using nested datoms, it could be like this (where “xxxx” in the second datom represents the first datom):

[rich :employment cognitect]
[xxxx :role chief-architect]

It’s unclear to me that this is what it would mean. If this were reification, xxx would mean the fact itself is a chief architect, not rich-at-cognitect

It would be interesting to hear what you think of this: https://enterprise-knowledge.com/rdf-what-is-it-and-why-do-i-need-it/

This looks like just another way to encode the same thing, and the predicate now has to carry the nuance of what part of the triple is its true object (i.e. is it “adverbial” modifying the fact or is a “meta statement” about the statement itself) . Maybe it’s more compelling in an open system like RDF where you can’t control how people encode things, so you may get stuck needing to annotate a fact instead of an entity. In a closed schema I think I’d rather just not deal with this nuance.

Many systems (even in RDF) do add a special-purpose handle (often an extra component to the triple, like ?tx in datomic) to make “higher order” facts expressible. This is a generalization of that, so maybe it will be fine.

One more example (in you don’t mind) - how would you express this sentence in datoms?: “Flight BA1234 arrived at Heathrow Airport on 12-Aug-1998 at 10:25am.”

It would depend on what this was for, but a first cut would be three datoms joined by an entity that represents an arrival. In pseudocode, [e :arrival/flight BA1234][e :arrival/airport heathrow][e :arrival/time 12-Aug-1998 10:25am]

That makes sense and really helps me in the quest of trying to understand! In “The Associative Model of Data” (https://web.archive.org/web/20181219134621/http://sentences.com/docs/amd.pdf) - which seem to a precursor to Datomic that like RDF-star can nest facts - it would be represented like this:

I’m not sure how related they are. Datomic is inspired by rdf’s basic idea of a “triple” expressing a fact, but I think the influence kind of ends there. I think the datom is in the service of finer-grained truth model, and what you call the “nesting” (the transaction-entity annotation) is in service of the epochal time model, not supplying a new way to express domain-model concepts (in fact, over-using datomic datom history for domain-accessible features is a common datomic pitfall https://vvvvalvalval.github.io/posts/2017-07-08-Datomic-this-is-not-the-history-youre-looking-for.html). In other respects it’s pretty traditional. The world is still closed, multi-valued relationships are still reified, normal entity-relationship modeling process pretty much still applies.

The “Associative Model of Data” (where my screenshot is from) even had immutability 10 years before Datomic - the two seems very similar to me. Would you say the “nesting” wouldn’t help you build Datoms? I don’t quite understand the connection between the transaction and the so called nesting… Thanks for the blog link - are there any more Datomic blogs you would recommend?

> I don’t quite understand the connection between the transaction and the so called nesting… A datom is [E A V TX OP], where TX is the transaction entity the fact is from, and OP is whether this is an addition or retraction of the fact in that TX. So you can treat a datom as a thing “nested” in a transaction because you can join the TX entity to the whole fact. Conceptually [TX :db/add [E A V]], [TX :db/retract [E A V2]]. vs [E A V TX :db/add][E A V2 TX :db/retract] It’s just encoded into the fact itself instead of being a general mechanism.

Which is you can write the datom code as fact additions/retractions nested inside the transaction datom(s)? The effect is still that one or more datoms are connected through a single transaction datom, right?

The datoms are objects not subjects of facts about the transaction. So they’re connected via a transaction entity not transaction datom.

Right.

What does “self-unification within a single clause” mean?

Hi @U083D6HK9! We had a report from a customer that in a very specific use case where they had a self-referencing entity (`:foo/ref`) that the single clause [?e :foo/ref ?e] would return all entities instead of a subset of the entities which matched the clause. This was undefined behavior and so we decided to add a feature that would unify on a single clause. Here is a gist of the previous behavior:

(d/q '[:find (count ?e)
       :in $
       :where
       [?e :some/attr ?e]]
     (d/db conn))
;=> [[3]] ;; returns a count of entities where the left ?e is subset of the right ?e (note there are 4 total entities and 1 self referential)

Now this same query should return the single self referential entity and unify on ?e.

Thank you for the thorough explanation. Makes total sense. Interesting use case.

It's definitely an edge case. Adding a second clause for instance gets the desired behaivor... i.e.

(d/q '[:find (count ?e1)
       :in $
       :where
       [?e1 :some/attr ?e2]
       [(= ?e1 ?e2)]]
     (d/db conn))