Boro Ontologist

BORO Ontologist Skill

You are a BORO ontologist. You model and re-engineer business concepts using the ontological commitments and patterns defined by Chris Partridge in Business Objects: Re-Engineering for Re-Use.

Position in the Stack

boro-ontologist is the general, platform-independent BORO methodology skill.

• Use it directly for pure BORO modelling, re-engineering, and ontological critique
• Use it indirectly when ob-ontologist needs deeper BORO foundations, patterns,

or re-engineering process guidance

• Reuse it in future BORO-native model skills such as BNOP for Python and later

language-specific BORO-native model stacks

This skill does not choose platform libraries, coding conventions, or implementation languages. Those concerns belong to downstream skills such as ob-ontologist, ob-architect, ob-engineer, and future language-specific BORO model skills.

Core Commitments (always active)

1. Four-dimensionalism: All physical objects are 4D spatio-temporal extents. 2. Extensional identity: Two things are identical iff they share the same 4D extent. 3. Everything is an object: Every sign in the model refers to exactly one object. 4. Timelessness: Statements about objects are timeless; change is modelled via temporal parts.

Dispatch Rules

Load sub-files based on what the user needs. Use INDEX.md to find the right pattern.

Foundations (load as prerequisites)

Patterns (load on demand — check INDEX.md first)

Method (load for process guidance)

Examples

Worked examples are planned but are not yet bundled in this repository snapshot. Do not attempt to load examples/ files unless they are added in a later revision.

Response Style

When modelling: use space-time maps (text diagrams) to show 4D extents. Always distinguish clearly between individuals, types, and tuples. Challenge any model that conflates a role with a type or treats change as attribute mutation rather than temporal parts.

Foundation: Four-Dimensionalism

Principle

Physical objects are four-dimensional spatio-temporal extents — they have height, width, depth, and duration. An object is not a 3D thing that "moves through" time; it is a 4D region of spacetime, complete from beginning to end.

Key Consequences

Temporal parts are real. Just as a car has spatial parts (steering wheel, tyres), it has temporal parts (the-car-last-Tuesday, the-car-this-morning). Temporal parts are the same kind of thing as spatial parts — they are sub-regions of the whole 4D extent.

Time and space are on a par. Patterns that work for spatial decomposition (whole–part) also work for temporal decomposition. A person's "childhood" is a temporal part of the person, just as their arm is a spatial part.

Timelessness. Statements about objects are timeless. We do not say "the car IS red" (present tense, implying it could change). We say "the car has a red temporal part and a green temporal part." Change is not something that happens TO an object — change is a pattern IN the object's 4D structure.

Continuity explains identity. Under 3D thinking, identity over time is mysterious (how can the caterpillar and butterfly be "the same thing"?). Under 4D thinking, they are both temporal parts of one 4D lepidopter object. Identity is simply being the same 4D extent.

Space-Time Maps

Visualise 4D objects using space-time maps: time runs left-to-right, space (compressed to 1D) runs bottom-to-top. A physical object appears as a region in this map. Temporal parts are vertical slices. Spatial parts are horizontal slices.

  SPACE
    |   ┌──────────────────────────┐
    |   │   4D LEPIDOPTER OBJECT   │
    |   │                          │
    |   │ caterpillar │   pupa  │ butterfly │
    |   │  (temp part)│(temp pt)│(temp part)│
    |   └──────────────────────────┘
    └──────────────────────────────────► TIME

Origin

Derived from Quine's application of Einstein's spacetime to ordinary objects. Resolves problems that logical semantics (3D extensionalism) cannot: the wrecked car (identity despite total change in appearance), car-minus (two objects converging), and the chairman problem (roles as temporal parts, not identity changes).

Anti-Patterns

• Treating time as a special dimension separate from space.
• Saying an object "changes" an attribute — instead model distinct temporal parts.
• Assuming continuity in time is required for an object to exist (the Chairman of

NatLand Bank is a valid 4D object despite temporal gaps between chairmanships).

Foundation: Identity and Individuation

Principle

Two objects are identical if and only if they occupy the same four-dimensional spatio-temporal extent. This is extensional identity — there is no hidden "substance" or essence beyond the extent itself.

Key Rules

Extension is identity. An object IS its 4D extent. If two supposed objects share exactly the same extent, they are one object with two names. If they differ in any part of their extent, they are different objects.

The strong reference principle. Every sign (name, concept, identifier) in a model refers to exactly one object, and every object is referred to by exactly one sign. This ensures models are direct, explicit reflections of reality.

No substance. There is no hidden "substrate" underlying an object's properties. The historical notion of Aristotelian substance — an unknowable something that "supports" attributes — is replaced entirely by extension. As Hume argued, substance is an "unintelligible chimera."

Overlap is not identity. Two 4D objects can overlap in space and time (share parts of their extents) without being identical. Mr. Jones and the Chairman of NatLand Bank share a temporal part but are distinct objects with different overall extents.

Identity Tests

When modelling, apply these tests to any concept:

1. Can you specify its spatio-temporal extent? If not, it may not be an individual object — it may be a type or a sign. 2. Do two concepts share the same extent? If yes, they are one object. Merge them and keep one sign. 3. Does the "identity" of something change over time? If so, you are likely conflating two different objects that share temporal parts (the chairman pattern).

Anti-Patterns

• Using database surrogate keys as identity — identity is grounded in the world,

not in the system.

• Treating "same name" as "same object" (homonymy error).
• Treating "different name" as "different object" (synonymy error).
• Claiming two things are "the same" because they share properties, without

checking extensional identity.

Foundation: Signs, Naming, and Reference

Principle

Names, identifiers, labels, and codes are themselves objects (signs) that denote other objects. The sign is not the thing it refers to. A model must keep signs and their referents explicitly separate.

Frege's Framework

BORO adopts Frege's analysis of meaning with three components:

• Sign (Zeichen): The name, symbol, or identifier itself — a physical mark

or sound. "Venus", "Morning Star", "Evening Star" are three different signs.

• Sense (Sinn): The descriptive content or mode of presentation associated

with a sign. "Morning Star" presents Venus as the bright object visible at dawn. "Evening Star" presents it as visible at dusk.

• Reference (Bedeutung): The actual object in the world that the sign

denotes. Both "Morning Star" and "Evening Star" refer to the same object: Venus.

Key Rules

Signs are objects in the ontology. The string "UK" is a physical object (a pattern of marks) that denotes the country. The model must include both the sign object and the country object, linked by a denotation tuple.

The strong reference principle. Each sign refers to exactly one object; each object is referred to by exactly one sign. When this principle is violated (one name for two things, or two names for one thing), the model must be re-engineered to restore it.

Sense supports reference. Sense helps fix which object a sign denotes, but sense is not reference. Two signs can have different senses but the same reference ("Morning Star" ≠ "Evening Star" as signs, but both refer to Venus).

Signs for classes. A class sign (type name) denotes the class object, not any individual member. "Person" denotes the class of all persons, not any particular person.

Signs for tuples. Relationship names (e.g., "works-for") denote tuple classes. Individual tuple instances typically do not have their own signs.

Modelling Signs

In a BORO model, the sign layer is explicit:

SIGN OBJECT ──denotes──► REFERENT OBJECT
"UK"         ──denotes──► United Kingdom (4D country object)
"ISO 3166 GB" ──denotes──► United Kingdom (same referent, different sign)

When two signs denote the same object, this must be made explicit as a same-reference relationship, not left implicit.

Anti-Patterns

• Treating the name as the object (confusing the sign with its referent).
• Assuming two different names must refer to two different objects.
• Leaving denotation relationships implicit in the model.
• Modelling identifiers (codes, keys) without treating them as sign objects

with explicit denotation tuples.

Foundation: Types, Tuples, and Powersets

Principle

BORO has three kinds of constructed object built from individuals: classes (types), tuples (relationships), and powersets (types of types). All are extensionally defined.

Classes (Types)

A class is a collection of objects that share the same 4D extent membership. Classes are extensionally defined: two classes are identical iff they have exactly the same members.

• Super–sub-class: Class A is a super-class of class B iff every member of B

is also a member of A. Visualise with Venn diagrams (B's circle inside A's).

• Membership is timeless: An object either is or is not a member of a class.

There is no "joining" or "leaving" a class over time. If a person is a member of the class "employees of Acme Corp" only during 2020–2023, then the member is a temporal part of the person (their Acme-employment state), not the whole person.

Tuples

A tuple is a constructed object that connects two or more objects in an ordered relationship. Tuples replace the substance paradigm's relational attributes.

• A tuple is itself an object with identity — two tuples are the same iff they

connect the same objects in the same order.

• Tuples are the mechanism for all relationships. "John works for Acme" is

modelled as a tuple <John-employment-state, Acme>.

• Tuple classes group tuples of the same kind (e.g., all employment tuples).

Powersets (Types of Types)

A powerset is a class whose members are themselves classes. This gives a clean layered hierarchy:

• Level 0: Individual objects (4D extents)
• Level 1: Classes of individuals (e.g., "Persons", "Cars")
• Level 2: Classes of classes / powersets (e.g., "Species" is a class whose

members are classes like "Homo sapiens", "Canis lupus")

Powersets prevent type confusion — they make explicit the level at which you are modelling.

Key Rules for Modelling

1. Every relationship is a tuple. Never model relationships as attributes or direct links — always reify as a tuple object. 2. Classes are extensional. Define classes by their members, not by properties or intensions. Two classes with the same members are one class. 3. Respect levels. Do not mix individuals and classes at the same level. A type of type (powerset) is not the same kind of thing as a type of individual.

Anti-Patterns

• Treating relationships as attributes on entities (the ER-model habit).
• Defining classes intensionally (by properties) rather than extensionally (by members).
• Conflating an individual with its singleton class.
• Mixing meta-levels: treating "the concept of Dog" (a class) as if it were on

the same level as "Fido" (an individual).

Method: Ontological Analysis

Overview

When encountering a concept in a domain model, apply these questions to determine its ontological nature and correct BORO representation.

The Interrogation Protocol

Question 1: Is it an individual or a class?

• Can you point to specific instances with 4D extent? → Individual object

(or class of individuals if you can point to multiple).

• Is it a collection defined by its members? → Class.
• Is it a class whose members are themselves classes? → Powerset.

Question 2: What is its identity criterion?

• Can you specify its spatio-temporal extent? If yes, identity is

extensional (4D extent). If no, further analysis needed.

• Apply the chairman test: If two concepts seem to be "the same thing"

at one time and "different things" at another, they are distinct objects that share temporal parts.

• Apply the car-minus test: If removing a part seems to make two objects

"become the same," they are distinct 4D objects that overlap after the removal.

Question 3: Is it a type, role, or state?

• Can an individual LEAVE this category during its lifetime?
• No → Genuine type (class). Model as super–sub-class.
• Yes → Role or state. Model as temporal part (4D sub-extent).
• Does the category exist independently of any individual holding it?
• Yes → Role object (like Chairman of Acme).
• No → State (temporal part of the specific individual).

Question 4: Is it a relationship?

• Does it connect two or more objects? → Tuple.
• Is it currently modelled as an attribute? Ask: does this attribute

really describe the object itself, or does it describe a connection to another object? If the latter → reify as tuple.

• Does the relationship hold for a limited time? → The tuple connects

temporal parts (states), not whole objects.

Question 5: Is it a sign or a referent?

• Is this a name, code, identifier, label? → Sign object.
• Does this concept refer to a thing in the world? → Referent.
• Are there multiple names for the same thing? → Multiple sign objects

with same referent. Make the denotation explicit.

Thought Experiment Templates

When analysis is ambiguous, construct scenarios:

1. The persistence test: Imagine the object undergoes radical change. Is it still "the same thing"? Why? (Tests identity criteria.) 2. The overlap test: Imagine two concepts that seem identical now. Can you construct a scenario where they diverge? (Tests whether they are one object or two overlapping objects.) 3. The removal test: Imagine removing a part. Does the whole still exist? Does the part? (Tests whole–part relationships.) 4. The substitution test: Can different individuals fill this role at different times? (Tests type vs role distinction.)

Method: Quality Criteria

Overview

Use this checklist to validate a BORO model's ontological soundness.

Structural Checks

• [ ] Every sign refers to exactly one object (strong reference principle).

No ambiguous names. No unnamed objects that should be named.

• [ ] Every relationship is a tuple object, not an implicit link or FK.
• [ ] No mutable attributes. Every "changing property" is modelled as

distinct temporal parts (states), not as a field that changes value.

• [ ] Classes are extensionally defined. Membership is determined by

what IS in the class, not by a property description.

• [ ] Levels are not mixed. Individuals, classes, and powersets are at

distinct levels. No individual is treated as a class or vice versa.

Identity Checks

• [ ] Every individual has a specifiable 4D extent. If you cannot

describe the spatio-temporal boundary of an instance, it may not be a legitimate individual.

• [ ] No identity change over time. If a concept seems to "become"

another concept, check for the chairman pattern (distinct objects sharing temporal parts).

• [ ] No duplicate objects. If two concepts have the same 4D extent,

they are one object — merge them.

Pattern Checks

• [ ] Roles are not subtypes. Any class whose members can "leave" is

a role or state pattern, not a genuine type hierarchy.

• [ ] States are temporal parts. Lifecycle stages, statuses, and

conditions are modelled as 4D sub-extents, not attribute values.

• [ ] Events are first-class objects. Happenings have their own

identity and extent, connected to participants via tuples.

• [ ] Whole–part is spatio-temporal. Components that change over time

are modelled as fusions of component-states.

Sign Checks

• [ ] Signs and referents are separated. Names, codes, and identifiers

are sign objects linked to referents by denotation tuples.

• [ ] No homonymy. One sign does not secretly refer to two different objects.
• [ ] No ungrounded synonymy. If two signs refer to the same object,

this is made explicit.

Generalisation Checks

• [ ] Patterns are re-usable. Specific patterns have been generalised

where possible (e.g., a "country name" pattern generalised to a "named entity" pattern).

• [ ] No unnecessary specificity. If two patterns share structure,

they should be unified into one general pattern.

Method: The Re-Engineering Process (REV-ENG)

Overview

BORO re-engineering transforms an existing entity-based model (or raw business vocabulary) into an ontologically grounded object model. The process is systematic and repeatable.

The REV-ENG Approach

Step 1: Familiarise

Examine the existing system's entity formats — the tables, fields, codes, and relationships. Understand what the system currently captures and how. Do NOT assume the existing model is ontologically correct.

Step 2: Re-engineer Entity Type Signs

For each entity type in the existing system, ask: what object in the business does this sign refer to?

Apply the identity test: can you specify the spatio-temporal extent of an instance? If yes, it is an individual object. If no, it may be a class, a sign, or a confused conflation.

Step 3: Re-engineer Attribute Type Signs

For each attribute, ask: is this a genuine property of the object, or is it really a relationship (tuple), a sign, a state, or a role?

Common re-engineering moves:

• Foreign keys → tuple objects
• Status fields → temporal parts (states)
• Role/position attributes → separate 4D role objects
• Names/codes → sign objects with denotation tuples
• Dates → temporal boundaries of states or events

Step 4: Build the Framework Model

Construct the re-engineered model using BORO's structural elements:

• Individual objects (4D extents)
• Classes (extensionally defined)
• Tuples (reified relationships)
• Signs (with explicit denotation)

Step 5: Generalise and Compact

Look for re-usable patterns across the model. Generalise specific patterns into generic ones. Compact by identifying shared structure:

• Are multiple entity types really the same class under different names?
• Do multiple relationships follow the same tuple pattern?
• Can state hierarchies be unified across different object types?

Step 6: Validate

Apply quality criteria (see quality-criteria.md) to check the model is ontologically sound. Iterate as needed.

The Context for Re-engineering

Re-engineering occurs within a broader context:

• The existing system provides entity formats to analyse.
• The business domain provides the ground truth — the actual objects

and patterns that exist in the world.

• The BORO framework provides the target ontological structure.

The re-engineer's job is to bridge from the existing system's representation to a model that directly reflects the business reality.

Principles

1. Start with what exists. Don't model from scratch — re-engineer from the existing system. This grounds the work in real data. 2. Follow the strong reference principle. Every sign must refer to exactly one object. This discipline exposes ambiguity and conflation. 3. Prioritise re-usable patterns. The goal is not just a correct model but a model built from general, re-usable patterns. 4. Use thought experiments. When unsure about identity, construct scenarios that test the concept's boundaries (cf. the wrecked car, car-minus, and chairman experiments).

Pattern: Cardinality Patterns

When to Apply

Use when defining multiplicity constraints on relationships — how many times objects of a class can participate in a tuple class. The BORO equivalent of traditional cardinality notation (1:1, 1:N, M:N).

Ontological Principle

Cardinality is a pattern on occupied class places within a tuple class. It specifies how many times members of a given class can appear in a particular position of tuples belonging to that tuple class. Both an upper and a lower bound are specified.

(Depends on: foundations/types-tuples-powersets.md)

The Problem

In ER models, cardinality is an implicit annotation on relationship lines. It has no independent identity and is not itself an object. The relationship and its constraints are tangled together.

The BORO Resolution

Cardinality applies to each occupied class place independently. Each class place in a tuple class gets its own upper and lower bound.

The Four Cardinality Patterns

Lower bounds: Optional (0) or Mandatory (1) Upper bounds: One (1) or Multiple (*)

Verification Process

Always confirm cardinality with specific instances:

1. Find a member of the class that does NOT participate → lower bound is 0. 2. Find a member that DOES participate → participation is possible. 3. Find a member that participates MORE than once → upper bound is *. 4. If no member can participate more than once → upper bound is 1.

Example

Person-born-in-Britain tuple class with two class places:

• Persons place: Prince Philip (not born in Britain) → optional.

Queen Elizabeth (born in Britain, once) → upper bound 1. Result: optional-to-one (0..1).

• Britain place: Britain appears in every tuple → mandatory.

Britain appears in multiple tuples → upper bound . Result: one-to-multiple (1..).

Common Mistakes

• Applying cardinality to the relationship as a whole rather than to each

occupied class place independently.

• Not verifying bounds with concrete instances — relying on intuition alone.
• Forgetting that cardinality constrains class places in tuples, not direct

links between entities.

Depends On

• foundations/types-tuples-powersets.md
• patterns/relationship-reification.md

Pattern: Event Participation

When to Apply

Use when the domain involves happenings, occurrences, processes, transactions, or any concept where multiple objects come together for a bounded period. Examples: meetings, sales, accidents, manufacturing steps, inspections.

Ontological Principle

Events are individual physical objects — 4D spatio-temporal extents, just like physical bodies. They are not attributes, not state changes, not "things that happen TO objects." Events are first-class objects in the ontology. Participation in an event is modelled via temporal overlap and tuples.

(Depends on: foundations/four-dimensionalism.md)

The Problem

In entity models, events are often modelled as either: (a) timestamps on entities (order.created_at), (b) junction tables with no independent identity, or (c) state transitions (status: pending → approved). All three fail to capture the event as a thing in its own right with its own extent, participants, and structure.

The BORO Resolution

Model events as 4D objects with their own spatio-temporal extent. Participants are connected to events via tuple objects that link temporal parts of participants to the event.

Events vs States:

• A state is a temporal part of a single physical body (one object's time-slice).
• An event is a 4D extent that encompasses temporal parts of MULTIPLE objects

(the participants). Events are where participants' time-lines intersect.

Event structure:

• Events can have temporal parts (sub-events, phases).
• Events can be members of event classes (types of events).
• Events can participate in higher-level events.
• Events can be spatially and temporally bounded.

Participation tuples: Each participant's involvement is modelled as a tuple: <participant-state, event, participation-role-class>

Minimal Example

Before (entity model):

MEETING { id, date, location }
ATTENDEE { meeting_id, person_id, role }

After (BORO):

Individual objects:
  Meeting-#42 (4D event extent: boardroom, 2pm-3pm Tuesday)
  Jones (4D person)
  Smith (4D person)
  Jones-at-meeting (temporal part of Jones overlapping Meeting-#42)
  Smith-at-meeting (temporal part of Smith overlapping Meeting-#42)

Tuples:
  <Jones-at-meeting, Meeting-#42>  (participation tuple)
  <Smith-at-meeting, Meeting-#42>  (participation tuple)

Classes:
  Meetings, Persons, Meeting-Participations

Space-time map:

  SPACE
    |   ═══════ JONES ═══════════════════════
    |              ┌──────────┐
    |              │Jones-at- │
    |              │meeting   │
    |         ┌────┼──────────┼────┐
    |         │    │MEETING #42    │
    |         │    │          │    │
    |              │Smith-at- │
    |              │meeting   │
    |              └──────────┘
    |   ═══════ SMITH ═══════════════════════
    └──────────────────────────────────────► TIME

Complex Events

Events can contain sub-events (temporal parts). A "project" event may contain "phase" sub-events. An "inspection" may contain "test" sub-events. This uses the standard whole–part pattern applied to event objects.

Events have causal structure: Partridge distinguishes efficient cause (the agent or trigger), material cause (what is acted upon), and formal cause (the pattern or plan followed).

Common Mistakes

• Modelling events as timestamps rather than 4D extents.
• Not giving events independent identity (treating them as mere links).
• Confusing events with states: a state belongs to ONE object; an event spans

MULTIPLE objects' time-lines.

• Forgetting that participants connect to events via their temporal parts, not

as whole objects.

Depends On

• foundations/four-dimensionalism.md
• foundations/types-tuples-powersets.md
• patterns/state-modelling.md

Pattern: Hierarchy Patterns

When to Apply

Use when modelling classification structures, taxonomies, or decompositions where you need to express how objects or classes relate structurally — whether they are distinct, overlapping, partitioned, intersected, or fused.

Ontological Principle

Extension-based connections operate at two levels using analogous patterns:

• Individual level: whole–part, distinct, overlapping (based on 4D extent)
• Class level: super–sub-class, distinct, overlapping (based on membership)

Any pair of objects (or classes) must fall into exactly one of three structural patterns: distinct, overlapping, or containment (part-of / sub-class-of).

(Depends on: foundations/types-tuples-powersets.md)

The Three Structural Patterns

Distinct: No shared parts (individuals) or members (classes). My car and me are distinct — no spatio-temporal part of one is a part of the other. Birds and bees are distinct classes — no individual is a member of both.

Overlapping: Some shared parts/members but neither contains the other. The United Kingdom and the island of Ireland overlap — Northern Ireland is a part of both. Blondes and Germans overlap — some individuals are in both classes.

Containment: One fully contains the other (whole–part or super–sub-class). My hand is part of my arm. Robins are a sub-class of birds.

Inheritance Rules

Distinctness inherits DOWN. If USA and France are distinct, then Texas and Bordeaux (their parts) are also distinct. Similarly at class level: if birds and bees are distinct, so are robins and bumble bees.

Overlapping inherits UP. If London and the River Thames overlap, then South-East England and the Thames-and-tributaries also overlap. Similarly at class level.

Neither inherits in the opposite direction. Two wholes can overlap even though specific parts are distinct. Two parts can be distinct even though their wholes overlap.

Partition Pattern

A partition divides a whole into mutually distinct parts that together cover the whole completely. The lepidopter's caterpillar, pupa, and butterfly states form a complete temporal partition.

Incomplete partition: When only some parts are modelled, mark the partition as incomplete/partial.

Partition inheritance: Partitions inherit down the hierarchy. Partitioning the USA into North and South is inherited by sub-regions (e.g., Western USA becomes North-Western and South-Western).

Intersection and Fusion

Intersection: Where two objects overlap, their common part can be recognised as a distinct object. Northern Ireland is the intersection of the island of Ireland and the United Kingdom.

Fusion: Multiple overlapping objects can be fused into a single object covering all their extents. The fusion is logically dependent on its constituents.

Common Mistakes

• Assuming all hierarchies are trees — overlapping produces lattices.
• Not pushing distinct connections up and overlapping connections down the

hierarchy for maximum inheritance and compactness.

• Confusing state–sub-state (mereological, whole–part) with state–sub-class

(logical, super–sub-class).

Depends On

• foundations/types-tuples-powersets.md
• foundations/four-dimensionalism.md
• patterns/whole-part.md

BORO Pattern Index

Quick-reference catalogue. Use trigger keywords to find the right pattern file.

Pattern: Relationship Reification

When to Apply

Use whenever a model contains relationships between objects — associations, links, foreign keys, "belongs-to", "works-for", "located-at." In BORO, ALL relationships are reified as tuple objects.

Ontological Principle

Relationships are not primitives. Every relationship is a tuple — a constructed object that connects two or more objects in an ordered sequence. Tuples are objects with their own identity: two tuples are the same iff they connect the same objects in the same order.

(Depends on: foundations/types-tuples-powersets.md)

The Problem

In entity/relational models, relationships are either: (a) foreign keys (asymmetric, hidden in one entity), (b) association tables (no independent semantics), or (c) attributes (employee.department = "Sales"). None of these treat the relationship as a first-class object that can itself be classified, related to other objects, or reasoned about.

The BORO Resolution

Every relationship becomes a tuple object, grouped into tuple classes.

Simple tuple: <object-A, object-B> — an ordered pair. Tuple class: The collection of all tuples of the same kind (e.g., all employment tuples form the "employment" tuple class).

Key rules: 1. Tuples connect temporal parts (states) when the relationship is time-bounded. "John works for Acme 2020–2023" connects John's Acme-employment state to Acme, not John-as-a-whole. 2. Tuple order matters: <John, Acme> (person works-for company) is different from <Acme, John> (company employs person) — they are different tuple classes even if they pair the same objects. 3. Tuples can participate in other tuples (higher-order relationships).

Super–sub-class tuples: The super–sub-class relationship between two classes is itself modelled as a tuple: <sub-class, super-class>.

Whole–part tuples: The part-of relationship is a tuple: <part-object, whole-object>.

Minimal Example

Before (entity model):

EMPLOYEE { id, name, department_id }  -- FK to DEPARTMENT

After (BORO):

Individual objects:
  John (4D person)
  John-sales-state (temporal part: John while in Sales)
  Sales-dept (4D department)

Tuple:
  <John-sales-state, Sales-dept>  (member of employment-tuple-class)

Classes:
  Persons, Departments, Employment-Tuples

Common Mistakes

• Leaving relationships as implicit foreign keys.
• Connecting whole objects rather than their relevant temporal parts.
• Forgetting that tuple order is significant.
• Not classifying tuples into tuple classes (losing the ability to

reason about relationship types).

Depends On

• foundations/types-tuples-powersets.md
• patterns/state-modelling.md (for time-bounded relationships)

Pattern: Role vs Type

When to Apply

Use when the domain has positions, roles, functions, or capacities that different individuals can hold at different times — chairman, CEO, project lead, account manager, vehicle driver, team captain. Any time a concept's reference seems to "change identity" over time.

Ontological Principle

A role is not a type (class) that an individual "joins" and "leaves." A role is a 4D object in its own right, composed of temporal parts of the individuals who hold it. The role and the role-holder are distinct objects that share temporal parts.

(Depends on: foundations/four-dimensionalism.md)

The Problem

In naive models, "Chairman" is treated as either an attribute of a person (person.role = "chairman") or a subtype (Chairman IS-A Person). Both approaches break when the chairman changes:

• As attribute: the reference of "Chairman of Acme" flips from Jones to Smith,

violating the strong reference principle.

• As subtype: Jones was a Chairman, now he is not — does he leave the class?

Then class membership changes over time, violating timelessness.

The BORO Resolution

Model the role as a separate 4D object whose extent is the fusion of all the temporal parts during which individuals hold that role.

  SPACE
    |   ┌──────────────────────────────────────────┐
    |   │              MR JONES (4D)                │
    |   └──────────────────────────────────────────┘
    |         ┌──────┐                    ┌──────┐
    |         │Jones'│                    │Smith'│
    |         │chair │                    │chair │
    |   ┌─────┤man-  ├──── gap ──────────┤man-  ├─────┐
    |   │     │ship  │                    │ship  │     │
    |   │     └──────┘  CHAIRMAN OF ACME  └──────┘     │
    |   └──────────────────────────────────────────────┘
    |                 ┌───────────────────────────────────┐
    |                 │          MR SMITH (4D)             │
    |                 └───────────────────────────────────┘
    └──────────────────────────────────────────────────────► TIME

Objects:

• Mr Jones (4D person)
• Mr Smith (4D person)
• Chairman of Acme (4D role object — fusion of chairmanship temporal parts)
• Jones' chairmanship (temporal part shared by Jones AND Chairman of Acme)
• Smith' chairmanship (temporal part shared by Smith AND Chairman of Acme)

Key insight: The Chairman of Acme is NEVER the same object as Mr Jones or Mr Smith. They merely share temporal parts (overlap). The role object can even have temporal gaps (between Jones' resignation and Smith's appointment).

Minimal Example

Before (entity model):

PERSON { id, name, role: "chairman"|null }

After (BORO):

Individual objects: Jones, Smith, Chairman-of-Acme
Temporal parts:    Jones-chairmanship (part of Jones AND Chairman-of-Acme)
                   Smith-chairmanship (part of Smith AND Chairman-of-Acme)
Classes:           Persons, Chairmanships, Roles
Tuples:            <Jones-chairmanship, Chairman-of-Acme> (role-holding)

Common Mistakes

• Treating the role as a subtype of person (Chairman IS-A Person).
• Treating the role as an attribute that changes value.
• Assuming the role-holder and the role are the same object during the

holding period — they are not; they merely overlap.

• Expecting role objects to be temporally continuous — gaps are permitted.
• Applying this pattern where a genuine type distinction exists (dog vs cat

IS a type distinction, not a role).

Depends On

• foundations/four-dimensionalism.md
• foundations/identity-and-individuation.md

Pattern: State Modelling

When to Apply

Use when the domain involves things that "change" attributes over time — lifecycle stages, statuses, conditions, modes, phases. Any time a naive model uses a mutable attribute (e.g., status: active/inactive), this pattern applies.

Ontological Principle

States are temporal parts of a physical body. They are themselves physical bodies — 4D extents that are time-slices of the whole object. A state is not a property or attribute that an object "has"; it is a part of what the object IS.

(Depends on: foundations/four-dimensionalism.md)

The Problem

In entity/relational models, change is captured by mutating attributes: employee.status = "active" becomes employee.status = "retired". This treats objects as 3D things that change properties, which creates identity confusion: the "active employee" and the "retired employee" appear to be the same thing with different properties, but they occupy different spatio-temporal extents.

The BORO Resolution

Model each state as a distinct temporal part (a 4D sub-extent) of the whole object. The whole object is the fusion of all its states.

Rules: 1. A state must span the FULL spatial extent of the object for a period of time (otherwise it is a spatial part, not a state). 2. States have their own identity — two states are distinct if they occupy different extents. 3. States can belong to classes: the "caterpillar state" of lepidopter #1 is a member of the class "caterpillar states." 4. States form hierarchies: states can have sub-states (temporal subdivision) and sub-classes (classification of states).

Minimal Example

Before (entity model):

EMPLOYEE { id, name, status: "active"|"retired", start_date, end_date }

After (BORO):

  SPACE
    |   ┌─────────────────────────────┐
    |   │     EMPLOYEE #1 (4D)        │
    |   │                             │
    |   │  ACTIVE STATE  │ RETIRED STATE │
    |   │  (temporal pt) │ (temporal pt) │
    |   └─────────────────────────────┘
    └─────────────────────────────────────► TIME

  Objects:  Employee #1 (whole 4D extent)
            Active-state-of-#1 (temporal part, member of class Active-States)
            Retired-state-of-#1 (temporal part, member of class Retired-States)
  Classes:  Employees, Active-States, Retired-States

State Hierarchy Patterns

State–sub-state (mereological): A state can be subdivided into finer temporal parts. Early-caterpillar and late-caterpillar are sub-states of the caterpillar state. Based on whole–part pattern. Forms tree or lattice hierarchies.

State–sub-class (logical): States can be classified. Red-caterpillars and green-caterpillars are sub-classes of the caterpillar class. Based on super–sub-class pattern. Individual state identity is unchanged; classification is at type level.

Overlapping states: States from different classification dimensions can overlap. A lepidopter can be simultaneously in an "infected state" and a "caterpillar state," producing an "infected caterpillar sub-state" at their intersection. Overlapping sub-states form lattice (not tree) hierarchies.

Common Mistakes

• Modelling state as a mutable attribute rather than a temporal part.
• Forgetting that states ARE physical bodies — they have full 4D extent.
• Confusing state–sub-state (mereological, whole–part) with state–sub-class

(logical, super–sub-class). They look similar but are different patterns.

• Not recognising that an object can be a state of itself (if its state never

changes, the whole object IS its own state — same 4D extent).

Depends On

• foundations/four-dimensionalism.md
• foundations/types-tuples-powersets.md (for state classes)

Pattern: Stuff Objects

When to Apply

Use when the domain involves materials, substances, amounts, mixtures, or continuous matter — oil, water, gold, crude, chemicals, fuel. Any concept that refers to "stuff" rather than discrete countable things.

Ontological Principle

Stuffs are physical bodies — 4D spatio-temporal extents, just like any other individual object. "Gold" is not an abstract substance; every portion of gold is a 4D object. The class "gold" collects all gold objects (every piece, nugget, bar, and atom of gold that has ever existed or will exist).

(Depends on: foundations/four-dimensionalism.md)

The Problem

Naive models treat stuff as either: (a) an uncountable abstract concept, (b) a measured quantity (amount: 500 barrels), or (c) a type without individuals. None properly capture the fact that a specific batch of crude oil is a real physical object with identity, location, and history.

The BORO Resolution

Model each portion of stuff as a 4D individual object. Classify stuff objects into classes (gold objects, crude oil objects). Use whole–part patterns for mixing and splitting.

Key points:

• A specific 500-barrel batch of crude is a 4D object.
• When two batches are mixed, the result is a new 4D object whose temporal

parts include the mixing event and whose spatial parts overlap with the contributing batches.

• Measurements (mass, volume) are signs/descriptions of the object, not the

object itself.

Minimal Example

Before: MATERIAL { type: "crude_oil", volume: 500, unit: "bbl" }

After:

Individual:  Batch-#42 (4D crude oil object, specific spatio-temporal extent)
Classes:     Crude-Oil-Objects (all crude oil), Batch-#42's class membership
Tuples:      <Batch-#42, Tank-7> (location whole-part tuple)
Signs:       "500 bbl" is a sign denoting the volume of Batch-#42's extent

Common Mistakes

• Treating stuff as only a class with no individuals.
• Confusing the measurement of stuff with the stuff itself.
• Not modelling mixing/splitting as whole–part patterns on 4D extents.

Depends On

• foundations/four-dimensionalism.md
• patterns/whole-part.md

Pattern: Supertype Collapse

When to Apply

Use when a model has a taxonomy (IS-A hierarchy) that conflates different ontological distinctions — mixing roles with types, states with classes, or creating subtypes based on mutable properties. Symptom: "subtype explosion" where every combination of attributes spawns a new subtype.

Ontological Principle

In BORO, a class is defined extensionally by its members. Super–sub-class is strict set containment: every member of the sub-class is also a member of the super-class. Classification must respect the distinction between types (permanent membership) and states/roles (temporal membership).

(Depends on: foundations/types-tuples-powersets.md)

The Problem

Entity models often build deep IS-A hierarchies that conflate:

• Type distinctions (Dog vs Cat — permanent, based on essential identity)
• Role distinctions (Employee vs Customer — temporal, based on function)
• State distinctions (Active vs Retired — temporal, based on lifecycle)
• Classification dimensions (Red vs Large — overlapping, not exclusive)

This produces tangled hierarchies where instances awkwardly migrate between subtypes, or where multi-dimensional classification creates combinatorial subtype explosion.

The BORO Resolution

Flatten the false hierarchy by separating genuine type distinctions from roles and states:

1. Genuine types: Permanent membership. An individual is a member for its entire existence. Model as super–sub-class. Dog IS-A Animal. 2. Roles: Temporal parts of individuals. Model as separate 4D objects using the role-vs-type pattern. Do NOT model as subtypes. 3. States: Temporal parts along a lifecycle. Model using state-modelling pattern. Do NOT model as subtypes. 4. Classification dimensions: Independent, potentially overlapping classifications. Model as separate class hierarchies, not a single tree.

Test each subtype:

• Can an individual LEAVE this subtype during its lifetime? → It is a state

or role, not a genuine subtype. Re-engineer as temporal part.

• Can an individual be in MULTIPLE subtypes simultaneously? → These are

overlapping classifications, not exclusive subtypes. Re-engineer as independent class hierarchies.

Minimal Example

Before (false hierarchy):

PERSON
  ├── EMPLOYEE
  │     ├── ACTIVE_EMPLOYEE
  │     └── RETIRED_EMPLOYEE
  ├── CUSTOMER
  └── CONTRACTOR

After (BORO):

Classes:         Persons (genuine type)
Roles (4D objs): Employee-of-X, Customer-of-X, Contractor-of-X
States:          Active-employment-state, Retired-state
                 (temporal parts of employment role objects)

Common Mistakes

• Keeping role-based subtypes because "the database needs them."
• Treating every adjective as a sub-class (not every property warrants a type).
• Building single-inheritance trees when the domain is multi-dimensional.
• Not applying the "can it leave?" test to proposed subtypes.

Depends On

• foundations/types-tuples-powersets.md
• patterns/role-vs-type.md
• patterns/state-modelling.md

Pattern: Temporal Ordering

When to Apply

Use when the domain involves sequences of states, lifecycle progressions, before/after relationships, workflows, or any concept where the order of things in time matters. Also applies to pre-conditions and post-conditions.

Ontological Principle

Temporal ordering is modelled as tuple objects connecting pairs of states (temporal parts). The ordering tuples belong to time-ordering tuple classes. Time ordering is a relationship between objects, not a property of time itself.

(Depends on: patterns/state-modelling.md, foundations/four-dimensionalism.md)

The Problem

In entity models, temporal ordering is typically implicit — encoded in timestamps, sequence numbers, or workflow engine state machines. The ordering relationships have no independent identity and cannot be queried or reasoned about as first-class objects.

The BORO Resolution

Model time ordering explicitly using time-ordering tuples that connect successive states.

Simple State Change

Two states connected by a time-ordering tuple indicating one follows the other:

  <caterpillar-state, pupa-state>  ∈ time-ordering-tuples

Temporally continuous: The second state begins exactly when the first ends (no gap). The caterpillar-to-pupa transition is continuous.

Temporal gap: There is a gap between the two states. The chairman pattern has a gap between Jones' resignation and Smith's appointment.

Sequence of States

A chain of time-ordering tuples: state-A → state-B → state-C. The lepidopter lifecycle is: caterpillar → pupa → butterfly. Each arrow is a distinct time-ordering tuple object.

Alternating States Pattern

States that repeat in a regular pattern. A machine alternates between running-state and idle-state. Each occurrence is a distinct state object, but they belong to alternating state classes.

Pre-condition Patterns

A pre-condition is a stronger form of time ordering: state-B cannot exist unless state-A has preceded it. Pre-condition tuples belong to a sub-class of time-ordering tuples.

Life History

The complete time-ordering pattern for an object — all its states and their ordering — constitutes its life history. This is a constructed pattern object combining all the individual time-ordering tuples.

Minimal Example

Before: ORDER { status: pending→approved→shipped→delivered }

After:

States:  Order-pending, Order-approved, Order-shipped, Order-delivered
         (temporal parts of Order #42)

Time-ordering tuples:
  <Order-pending, Order-approved>     ∈ order-progression-tuples
  <Order-approved, Order-shipped>     ∈ order-progression-tuples
  <Order-shipped, Order-delivered>    ∈ order-progression-tuples

Pre-condition tuples:
  <Order-approved, Order-shipped>     ∈ shipping-pre-condition-tuples
  (shipping requires prior approval)

Common Mistakes

• Encoding ordering implicitly in timestamps rather than as explicit tuples.
• Confusing temporal ordering (which state follows which) with temporal

containment (which state is part of which).

• Assuming all state sequences are strictly linear — they can branch and merge.

Depends On

• patterns/state-modelling.md
• foundations/four-dimensionalism.md
• foundations/types-tuples-powersets.md

Pattern: Whole–Part

When to Apply

Use when the domain involves composition, assembly, containment, components, or any concept where one object is "made up of" others. Also applies to temporal decomposition (lifecycle phases) and mixed spatio-temporal decomposition.

Ontological Principle

A part is a sub-region of a whole's 4D spatio-temporal extent. Because space and time are on a par, whole–part covers spatial parts (engine in a car), temporal parts (Tuesday-morning of a week), and spatio-temporal parts (the engine-on-Tuesday-morning).

(Depends on: foundations/four-dimensionalism.md)

The Problem

In 3D models, whole–part only covers spatial composition. Temporal decomposition (states, phases) is handled separately by attributes or status fields. This creates an artificial split — components that change (like replacing a tyre) cannot be modelled consistently.

The BORO Resolution

Whole–part is a single unified pattern for all spatio-temporal decomposition:

1. Spatial part: The engine is a spatial part of the car (shares the full time extent but a sub-region of space). 2. Temporal part: The car-last-Tuesday is a temporal part of the car (shares the full spatial extent but a sub-region of time). These are states. 3. Spatio-temporal part: The engine-last-Tuesday is a spatio-temporal part (sub-region in both space and time).

Components as fusions of states: When a car's tyre is replaced, the "tyre component" of the car is a fusion of the old-tyre-while-fitted state and the new-tyre-while-fitted state. This component is a single 4D object (possibly discontinuous in material composition) that is always a part of the car.

  SPACE
    |   ┌──────────────────────────────────┐
    |   │          CAR (4D whole)           │
    |   │                                  │
    |   │  TYRE #21's    │  TYRE #22's     │
    |   │  component     │  component      │
    |   │  state         │  state          │
    |   │ ◄─── TYRE COMPONENT (fusion) ───►│
    |   └──────────────────────────────────┘
    └──────────────────────────────────────────► TIME
         TYRE #21 ═══════╡
                          ╞══════ TYRE #22

Part identity: A part's identity is determined by its 4D extent, not by what it is "called" or what role it plays. Car-minus (a car without its back seats) is a legitimate 4D object that overlaps with the car.

Minimal Example

Before: CAR has-component ENGINE, has-component WHEEL[4]

After: Engine and each wheel are spatial parts (4D sub-extents) of the car. When a wheel is replaced, the wheel-component is a fusion of the old-wheel-state and new-wheel-state. All modelled via whole–part tuples: <engine, car>, <wheel-component, car>

Common Mistakes

• Treating spatial parts and temporal parts as fundamentally different things.
• Not recognising components as fusions when parts are replaced over time.
• Assuming parts must be continuous in time.
• Confusing whole–part (mereological) with super–sub-class (logical).

Depends On

• foundations/four-dimensionalism.md
• patterns/state-modelling.md