Modeling Time in a Graph

Modeling Time in a Graph

Effective-from / valid-to properties vs temporal relationship nodes — pick per query pattern.

Why it matters

If queries always need 'what was true at T?', materialise time as a node so you can MATCH on it. Otherwise store from/to as properties and filter in WHERE.

Going deeper

Two idioms, chosen by query pattern:

The validity-property pattern needs an open-ended guard so current facts (no to yet) survive the filter:

MATCH (p:Person)-[r:WORKED_AT]->(c:Company)
WHERE r.from <= date($asOf)
  AND coalesce(r.to, date('9999-12-31')) >= date($asOf)
RETURN p.name, c.name;

Promote to :Date/:Month nodes only when calendar traversal itself becomes the query (e.g. 'show the timeline', 'co-occurrence on the same day') — otherwise you pay node-creation and join cost for filtering you could do in WHERE.

Modeling time is choosing between a photo album and a live CCTV feed. Storing from/to on a relationship is the album: each fact carries its own date stamp, and you flip to the right page with a WHERE filter. Promoting time to :Date nodes is the CCTV control room: you walk up to '2024-01-01' and see everything true at that instant. The album is cheaper; the control room pays off only when you constantly ask 'what was true at exactly time T?'

• Forgetting open-ended validity. r.to >= $asOf silently drops ongoing facts whose to is null. Fix: coalesce(r.to, far_future).
• Time-as-nodes by default. Adds join cost for one-off filters. Fix: start with properties; promote only when calendar traversal is the query.
• Storing a JSON timeline string. Unqueryable. Fix: model intervals explicitly.