Datomic versus RDF

Rich Hickey deliberately avoided RDF

Rich Hickey has said that he appreciated many of the ideas behind the Semantic Web, but he deliberately chose not to adopt the RDF stack. In particular, he wanted to avoid:

URIs for everything.

OWL inference.

The complexity of the RDF ecosystem.

Instead, he kept what he considered the most valuable ideas:

Entities

Attributes

Values

Identity

Immutable facts

Then he added what he believed was missing:

Time

History

Transactions

Why do people often say Datomic stores "triples"?

Because conceptually, the data model is very similar.

RDF

Subject
Predicate
Object

Datomic

Entity
Attribute
Value

However, Datomic extends this model with a temporal dimension.

Instead of storing only an entity, attribute, and value, every fact also records when it became true and whether it was asserted or retracted.

Entity
Attribute
Value
Transaction
Operation

In other words, a datom is closer to a quad (or even a quint) than to a triple.

Anatomy of a datom

A datom consists of five components:

(Entity, Attribute, Value, Transaction, Added)

or, more commonly,

E A V Tx Op

where:

E = Entity

A = Attribute

V = Value

Tx = The transaction that introduced the fact

Added = A boolean (true = assertion, false = retraction)

For example:

[17592186045420 :person/name "Alice" 13194139534312 true]

This means:

In transaction 13194139534312, the fact that this entity's name is "Alice" was asserted.

Later, if the name changes:

[:db/retract 17592186045420 :person/name "Alice"]
[:db/add     17592186045420 :person/name "Alicia"]

Datomic records two new datoms:

E A V Tx false
E A V Tx true

Nothing is ever overwritten.

The original assertion remains part of the immutable history, while the current database value is derived by replaying all assertions and retractions in transaction order.

Attributes linking entities

Attributes don't link to other attributes. Attributes link entities to values, and those values can themselves be entities.

For example, suppose we have two people.

Entity 1
---------
:name "Alice"

Entity 2
---------
:name "Bob"

The datoms are:

[E1 :person/name "Alice"]
[E2 :person/name "Bob"]

Now suppose Alice knows Bob.

Instead of storing a string like "Bob", the value is Bob's entity ID:

[E1 :person/friend E2]

where E2 is another entity.

Visually:

Alice (E1)
   |
   | :person/friend
   v
Bob (E2)

The attribute :person/friend doesn't point to another attribute. It points to another entity.

Attributes have types

In Datomic, every attribute declares its value type.

For example:

:person/name
:valueType :db.type/string

while

:person/friend
:valueType :db.type/ref

The important one is :db.type/ref.

It tells Datomic:

"The value of this attribute is another entity."

Once an attribute is a reference, you've created a graph.

Queries follow references

Imagine:

[E1 :person/friend E2]
[E2 :person/name "Bob"]

A Datalog query can simply say:

[:find ?name
 :where
 [?alice :person/friend ?friend]
 [?friend :person/name ?name]]

The variable ?friend is just another entity ID.

Attributes themselves are entities

Here's where Datomic becomes even more interesting.

Attributes like

:person/name

are themselves stored as entities in the database.

For example (simplified):

Entity 100
----------
:db/ident :person/name
:db/valueType :db.type/string
:db/cardinality :db.cardinality/one

So even attributes have attributes.

You can ask:

"Show me all attributes whose value type is :db.type/ref."

because the schema is just more data.

Do you like what you are reading? Subscribe to receive updates.

Unsubscribe anytime