Identity, Change and Time: 3D vs 4D Worldviews
Your asset register says pump P-101 was installed in 2019. Maintenance replaced its impeller in 2022, its motor in 2023 and its casing in 2025. The register still says P-101, installed 2019. Is that true? This is not a philosopher’s parlour game. It determines warranty claims, safety cases, depreciation schedules and whether your digital twin tells the truth. How an ontology answers it depends on a choice most modellers never realise they are making: the choice between a 3D and a 4D worldview. This lesson makes the choice explicit, because it is the deepest structural decision in any ontology, and because an entire national modelling tradition, the one behind UK defence and government data standards, made the unfashionable choice and got measurable benefits from it.
The Ship of Theseus is an asset management problem
Plutarch’s ancient puzzle asks: if every plank of a ship is replaced one by one, is it still the same ship? And if someone reassembles the discarded planks into a second ship, which one is the original? Substitute “pump” for “ship” and you have a live dispute in every asset-intensive industry. The regulator wants the maintenance history of the physical object that sits on the plant floor today. Finance wants the depreciation history of the asset line item, which survived every physical replacement. The manufacturer’s warranty attaches to specific serialised components, several of which are now in a spares bin. Three legitimate identities, one tag number. Data models that give you a single Pump record with mutable attributes force these identities into one row, and the conflicts surface as data quality incidents that are actually metaphysics quality incidents.
The philosophical machinery for handling this is the theory of identity conditions: for any class you model, what makes an instance the same instance over time? Ask this of every class in your ontology and vague classes crack open. Is a Customer the legal person, the account, or the relationship? Is a Flight the scheduled service BA117, or the specific departure of BA117 on 30 July 2026? Lesson 22 turns identity conditions into a practical design tool via OntoClean; here we need the two big rival answers.
Endurantism: the 3D worldview
The common-sense position, and the default of nearly every database schema ever drawn, is endurantism, usually called the 3D view. Objects are three-dimensional things that are wholly present at every moment of their existence, and they persist through time by enduring: the whole pump exists now, existed yesterday, and change means the very same object having different properties at different times. In a 3D model, P-101 is one continuant object, and “impeller replaced in 2022” is an event that happened to it. Upper ontologies in the realist tradition, notably BFO (ISO/IEC 21838-2), formalise this by splitting reality into continuants (objects, wholly present at a time) and occurrents (processes and events, which unfold over time). It is intuitive, matches how people talk, and works cleanly while your questions are about the present.
The trouble starts with history. If the same object simply has different properties at different times, then “P-101 has power rating 15 kW” is true now and false after the 2023 motor swap, and a plain triple stating it is dangerously incomplete. 3D systems patch this with timestamps on rows, audit tables, slowly changing dimensions, bitemporal columns, or reified “state” records bolted onto the side. Each patch works locally; collectively they are ad hoc, and every integration between two 3D systems must reconcile two different patching conventions. Anyone who has merged two bitemporal warehouses knows the pain has a shape. The 4D claim is that the pain comes from the worldview, not the implementations.
Perdurantism: the 4D worldview
Perdurantism, the 4D view, says objects are four-dimensional: extended in time exactly as they are extended in space. The pump is a spacetime worm stretching from installation to decommissioning, and what exists at any moment is a temporal part (a state) of that whole. Change is not one thing mysteriously altering; it is the simple fact that different temporal parts have different properties. “P-101 had a 15 kW motor until March 2023 and an 18.5 kW motor after” becomes two states of P-101, each with unchanging properties and definite temporal extent. Nothing is ever updated; history is never overwritten; the past is just more of the object.
Three practical consequences follow. First, temporal queries become ordinary queries: “what was the configuration on 12 May 2022?” selects the states whose extents contain that date, with no special temporal machinery. Second, identity questions become explicit modelling decisions rather than accidents: the physical pump, the functional slot “the pump serving line 4”, and the asset-register entry are three different 4D individuals related by states of participation and installation, and the Ship of Theseus dissolves into choosing which worm you are asking about. Third, extensional identity becomes available as a criterion: in the BORO method, two things are identical exactly when they have the same spatiotemporal extent, which gives modellers a brutal, decidable test for whether two systems’ records refer to the same thing. That test is the engine of BORO-style legacy re-engineering: instead of debating what a source system’s “customer” concept means, you ask what actual extents its records map to.
| Dimension of comparison | 3D (endurantist) | 4D (perdurantist) |
|---|---|---|
| What persists | Whole object, wholly present at each moment | Spacetime extent with temporal parts (states) |
| How change is modelled | Same object, properties change; needs timestamps or audit structures | Different temporal parts bear different properties; nothing changes in place |
| History | Bolt-on (audit tables, bitemporal columns, versioning) | Native; every assertion is about some temporally extended part |
| Identity test | Per-class, often implicit and disputed | Extensional: same spatiotemporal extent, same thing (BORO) |
| Intuitiveness for stakeholders | High; matches everyday speech | Lower at first; training required |
| Representative frameworks | BFO (ISO/IEC 21838-2), most ER models | BORO, HQDM, IDEAS, IES4 |
| Sweet spot | Current-state views, biomedical classification, lighter apps | Asset-heavy domains, audit and provenance, long-lived integration |
Worked example · the Aberdeen-2 asset register
Where we left it: the register will be a knowledge graph governed by an ontology, with a SKOS layer for the source vocabularies.
Work order WO-2022-114, April 2022: contractor swaps P-101’s original impeller (IMP-12) for a new one (IMP-77). Finance insists P-101 is the same asset, because depreciation continues on one line item. The reliability engineer insists the vibration history before and after the swap must never be merged, because it describes two different machines. Both are right, and the two worldviews let the register say so:
# 3D reading: one continuant whose property changed
ex:P101 ex:hasImpeller ex:IMP77 . # true today; was ex:IMP12, now overwritten
# 4D reading: one individual, two temporal parts
ex:P101_st1 ex:temporalPartOf ex:P101 ;
ex:hasImpeller ex:IMP12 ; ex:stateEnd "2022-04-12"^^xsd:date .
ex:P101_st2 ex:temporalPartOf ex:P101 ;
ex:hasImpeller ex:IMP77 ; ex:stateStart "2022-04-12"^^xsd:date .In the 4D reading, finance’s asset is the whole spacetime worm ex:P101, and the reliability engineer’s “two different machines” are its states st1 and st2. Nobody has to lose the argument: the dispute was never about facts, it was about which individual each team meant. “What was P-101’s configuration on 1 June 2021?” becomes an ordinary query: select the state whose extent contains the date.
State of the register: the register must record states with temporal extents, not just current values. Next question: what does it mean when a value is simply missing.
What breaks · staying 3D and overwriting in place
The pragmatic objection is that the 4D machinery looks like overkill: keep one P-101 record, update it when maintenance happens. Here is the register before and after doing exactly that:
# March 2022 load # May 2022 load (overwrites)
ex:P101 ex:hasImpeller ex:IMP12 . ex:P101 ex:hasImpeller ex:IMP77 .
ex:P101 ex:vibrationRMS 4.1 . ex:P101 ex:vibrationRMS 2.3 .Two things break, one loudly and one silently. Loudly: the swap itself has vanished. No triple records that WO-2022-114 happened, so “which contractor last opened P-101, and how long was it offline?” returns nothing. Silently, and worse: the reliability team’s trend job averages vibrationRMS over 2022 and attributes the whole series to “P-101”, blending readings from two different mechanical configurations into one curve. The anomaly model trained on that curve learns a machine that never existed. Nobody gets an error message at any point; the graph is syntactically perfect and historically false.
Why UK defence went 4D
The most consequential industrial commitment to 4D modelling happened in the UK. Matthew West’s work on data quality in process industries produced HQDM, the High Quality Data Model, a pattern catalogue built on 4D foundations, and the BORO method supplied the extensional re-engineering discipline. Through the IDEAS defence lineage this culminated in IES4, the Information Exchange Standard published openly by Dstl, a 4D ontology designed so that security and intelligence organisations with radically different internal systems can exchange information without semantic loss. The reasoning was exactly the pain points above: defence data is long-lived, provenance-critical, and integrated across dozens of suppliers and decades of systems, which is the worst possible terrain for ad hoc temporal patches. Today IES is the common ontology of the National Digital Twin Programme’s integration architecture, meaning the 4D approach now underpins the UK’s cross-sector digital twin ambitions. GCHQ has separately published MagmaCore, a Java implementation of HQDM over RDF. Lesson 26 walks through BORO, HQDM and IES in detail, using the instructor team’s own published IES-HQDM crosswalk as the worked example of how two 4D ontologies align in practice.
Choosing, honestly
Do not read this lesson as 4D triumphalism. The 3D tradition powers the most successful ontology ecosystem in existence (the OBO Foundry’s biomedical ontologies, lesson 34) and the BFO standard that the US Department of Defense and Intelligence Community adopted as their baseline in 2024. Choose based on your questions. If your competency questions are overwhelmingly about current state and classification (“what kind of thing is this, and what are its properties now?”), 3D with disciplined event modelling is cheaper and your stakeholders will thank you. If they are about history, configuration at a time, custody, provenance and audit (“what was true, when, and how do we know?”), 4D repays its learning curve quickly, because the alternative is reinventing temporal parts badly, one audit table at a time. Mixed estates are normal: a 4D core for assets and agreements with 3D-style views projected out for applications is a pattern you will meet again in the standards modules.
Whichever worldview you pick, pick it consciously, write it down, and apply it uniformly. The worst outcome is the accidental hybrid, where half the team timestamps rows and the other half models states, and the graph silently contains both. Your take-away test for any class: ask “what are its identity conditions, and how does it persist through change?” If the team cannot answer in two sentences, the modelling is not done. Next, we arm you with the logic that makes all of these assertions machine-checkable: open worlds, closed worlds, and what a reasoner can actually conclude.
Check yourself
The audit team needs the register to answer “what was P-101’s configuration on 1 June 2021?” for any past date, reliably. Which modelling actually delivers that?
- Keep current-value triples and add ex:lastUpdated “2022-04-12” to each one.
- Model temporal parts of P-101, each carrying its configuration and a temporal extent, and select the part whose extent contains the date.
- Mint one IRI per year (ex:P101_2021, ex:P101_2022) and attach that year’s configuration to each.
- Snapshot the whole graph into a dated named graph every night and query the snapshot for the date requested.
Show the answer, and why each wrong option is wrong
B is correct. This is the 4D pattern: states with explicit extents make “configuration at time t” an ordinary query for any t, the swap is the boundary between states, and the identity of the whole P-101 survives for finance.
A is audit metadata masquerading as history. A timestamp on the current value tells you when the row last changed; it cannot recover the configuration two changes ago, and for 1 June 2021 it offers nothing but “the current value arrived later”. C shatters one pump into arbitrary yearly individuals: the April 2022 swap is invisible inside ex:P101_2022, finance’s single asset now needs a chain of sameAs-like glue, and the year boundary is a modelling artefact no question ever asked for. D can only answer for dates a snapshot happens to exist, at enormous storage cost, and “what changed, when, between which configurations?” still requires diffing snapshots outside the model. Named graphs are the right tool for provenance and administration, which is their job in lesson 5, not a substitute for a temporal model.
