Properties on Relationships

Properties on Relationships

Weights, timestamps, confidence — first-class property-graph features that RDF needs reification to express.

Why it matters

Edge properties let you carry context (when, how much, how sure) without inventing intermediate nodes.

Going deeper

A relationship carries its own properties inline:

MERGE (a:Account {id:'A'})-[t:TRANSFERRED_TO {txId:'tx-001'}]->(b:Account {id:'B'})
SET t.amount = 12500, t.currency = 'USD', t.at = datetime(), t.riskScore = 0.82;

This is the property graph's headline advantage over RDF triples, where an edge is just (s, p, o) with no room for context — to attach amount you must reify: create an intermediate node standing for the statement and hang properties off it. That's more nodes, more joins, and a clumsier query.

When to still use an intermediate node in Neo4j: when the 'edge' has its own identity and relationships — a payment that is itself disputed, reversed, or linked to other payments is really a :Transaction node, not just an edge. Rule of thumb: properties for context, a node for a thing that has its own life.

Edge properties are writing the details on the envelope, not in a separate ledger. In a property graph, 'Alice paid Bob $50 on Tuesday with 80% confidence' is written on the arrow between them. In RDF you can't write on the arrow, so you invent a middle-man node (reification) — like keeping a separate ledger entry that points back to both people. The envelope is faster to read and harder to lose.

• Modelling a first-class entity as a bare edge. If the 'relationship' gets disputed/reversed/linked, it needs identity. Fix: promote to a node.
• Stuffing a JSON blob onto the edge. Unqueryable context. Fix: discrete typed properties.
• Over-reifying. Creating a node for every edge kills the property-graph advantage. Fix: properties first, nodes only when justified.