OPDA Knowledge base
pattern accepted

Transactions & Lifecycle

Context

The PDTF v3 schema carries the transaction envelope as a flat bundle of leaves with no relational object: transactionId/externalIds identify it, participants[] lists the parties (ODR-0006), milestones records listed/started/completed and legalForms progress, chain holds chain linkage, and a scatter of date leaves (listedDate, soldDate, expected, started, completed, official-copy retrievedOn) records when things happened. The transaction is the verb half of the model — the thing that binds seller, buyer, property and legal estate into a homebuying episode — yet the schema gives it no class and no founding semantics.

Two defects compound. Role-founding: ODR-0006 models opda:Seller/opda:Buyer as RoleMixins (anti-rigid, externally founded), but a RoleMixin is incoherent without the relation that founds it — nothing in participants[] + role names the transaction-as-relation. Temporal: the schema records instants (soldDate, listedDate) but has no vocabulary for the intervals that dominate the lifecycle — marketing-to-completion windows, lease terms (startYearOfLease/lengthOfLeaseInYears), lastDemandPeriod {from, to}, proprietorship duration. milestones and participantStatus (Proposed | Invited | Active | Removed) further conflate an anti-rigid status phase with a plain datatype value.

This is the Transactions & Lifecycle module under Council Session 001’s partition-by-ontological-concern resolution (Q3). It is Phase-1 and gated by the identity crux (ODR-0005): the Transaction relator relates Property/Title endurants whose identity criteria are settled in the crux.

Decision

Model the transaction envelope as Transaction-as-Relator + Phases + OWL-Time Conditional intervals: opda:Transaction is a UFO Relator founding the ODR-0006 Seller/Buyer RoleMixins, milestones and participantStatus are anti-rigid Phases backed by SKOS schemes (ODR-0011), and lifecycle/tenure intervals use OWL-Time while prov:atTime is retained for genuine instants in the provenance layer (ODR-0009). This is the only option that founds the participant roles in an explicit relation, models status with the correct anti-rigid category, and resolves the instant-vs-interval incoherence (Q2) — while reusing standard vocabularies rather than re-minting machinery.

Rules

  • opda:Transaction is a UFO Relator — a relational endurant mediating the parties, carrying transactionId (dct:identifier, sourced from the schema transactionId UUID leaf) and externalIds. It founds the opda:Seller/opda:Buyer RoleMixins of ODR-0006. Role-founding is asserted in this module’s prose and Turtle, not as a frontmatter depends-on from ODR-0006, to keep the dependency graph acyclic. Other founding Relators surfaced in ODR-0006 (opda:Proprietorship founding opda:Proprietor; conveyance/transfer relator founding transfer roles) sit at this relational layer alongside the Transaction.
  • opda:Chain as a relation between Transactions — sourced from chain, otherPropertyInChain and propertyDependencyType (Sale | Purchase | Remortgage). A dependent purchase or onward sale is a related Transaction relator, not a property of a single transaction.
  • Milestones and status as anti-rigid Phasesmilestones (listed, started, completed, legalForms) and participantStatus (Proposed | Invited | Active | Removed) are modelled as Phases of the Transaction (or of a participant’s role-play), backed by SKOS status/milestone concept schemes delegated to ODR-0011. A transaction is “in marketing”, “under offer”, “exchanged”, “completed” the way a phase is entered and left, not the way a Kind is instantiated. legalForms (TA6/TA7/TA10 completion) is a sub-phase scheme under the same treatment.
  • OWL-Time intervals for interval-valued facts — lifecycle and tenure facts use OWL-Time: the marketing-to-completion window (listed/started/completed as time:Instant bounds of a time:Interval); lease terms (startYearOfLease + lengthOfLeaseInYears → a time:Interval / time:DurationDescription); lastDemandPeriod {from, to}; moveRestrictionDates; proprietorship duration. Use time:hasBeginning/time:hasEnd/time:hasDuration. Reserve Allen-interval relations (time:intervalDuring, time:intervalBefore) for where temporal ordering is genuinely asserted, not as decoration.
  • prov:atTime retained for instants — genuine instants in the verification/claims layer (ODR-0009) keep prov:atTime; OWL-Time supplies the interval vocabulary PROV-O lacks. The two are complementary.
  • SHACL well-formedness (delegated to ODR-0013) — shapes constrain a time:Interval to carry a beginning and (where the schema supplies one) an end, and constrain lease-term intervals derived from startYearOfLease/lengthOfLeaseInYears to be well-formed.
  • Lifecycle/provenance seam — a milestone transition is represented once as a lifecycle Phase change here and referenced (not re-modelled) as a prov:Activity in ODR-0009.
  • Term sourcing — derived concepts carry dct:source to their canonical schema leaf path per ODR-0004; SKOS concepts (ODR-0011) carry skos:prefLabel/skos:definition from the business glossary and the schema’s milestones/legalForms/participantStatus definitions.
  • Single-scheme-vs-per-role status (RESOLVED — Council session-032, 2026-05-31; Q1/Q2/Q3 each 5–0–0; DA Kendall WITHDRAWN on all three). A single status state-machine, not per-role: one opda:ParticipantStatusScheme + one opda:MilestoneScheme (ODR-0011), with role-specific views expressed as skos:Collection within the one scheme — never per-role schemes (the ODR-0011 §1a one-primary-scheme integrity constraint forbids the duplicate-concept lattice that would require). Two distinct Phase-bearers (refinement adopted): the milestone-Phase bears on opda:Transaction (the Relator); the participantStatus-Phase bears on the participant’s role-play (qua-individual within the Relator), per ODR-0011 §8a “Kind-in-phase (Participant)” — do not flatten both onto the Transaction. Decided empirically: the PDTF corpus carries only the four envelope states Proposed|Invited|Active|Removed as one un-role-discriminated field, with no role-specific operational lifecycle data. Re-open trigger (SET-test — a future-evidence watch, not a held-as-live dissent; the DA fully withdrew): re-open the single-scheme commitment only on genuine definitional divergence — a role for which a status value’s definition differs (absent in schema and emitted TTL today). Lesser future variation routes elsewhere, not to a scheme split: a role-specific subset of states → skos:Collection + overlay sh:in; role-specific transitions → a role-keyed SHACL-AF rule (ODR-0013/0017).
  • Freeze gate — CLEARED (2026-05-31). Both conditions are now met: (a) ODR-0005 cleared its identity-criterion gate (the Transaction relator relates Property/Title endurants); and (b) the single-scheme-vs-per-role question resolved in Council session-032. The Transactions & Lifecycle TBox is unfrozen.
  • Exemplar validation — the module is validated against the lifecycle facets of the ODR-0005 diagnostic exemplars: a property mid-marketing (open-ended interval), a completed sale (closed interval), and a leasehold whose lease term is an interval with a computed end.

Transaction Lifecycle Phases

The participant-status and milestone phases form a directed state machine: a participant moves through Proposed → Invited → Active → Removed while the transaction itself progresses through marketing, under-offer, exchanged and completed milestone phases.

stateDiagram-v2 accTitle: Transaction lifecycle phases accDescr: Participant-status state machine and transaction milestone phase progression from marketing through to completed. state "Participant Status" as PS { [*] --> Proposed Proposed --> Invited Invited --> Active Active --> Removed Proposed --> Removed Invited --> Removed } state "Transaction Milestone Phases" as TM { [*] --> Marketing : listed date recorded Marketing --> UnderOffer : started UnderOffer --> Exchanged : legalForms complete Exchanged --> Completed : completed date recorded } state "UnderOffer" as UnderOffer state "Exchanged" as Exchanged state "Completed" as Completed { [*] --> [*] }

Transaction Relator and Entity Model

opda:Transaction is a UFO Relator mediating Property/Title endurants and founding the Seller/Buyer RoleMixins; each milestone or participant status is a Phase, and chain linkage is a relation between Transaction instances.

classDiagram accTitle: Transaction relator and entity model accDescr: Class diagram showing Transaction as a UFO Relator relating Property and Title endurants, founding Seller and Buyer RoleMixins, and associating with Phase and Chain. class Transaction { +dct_identifier transactionId +externalIds [] +time_Interval marketingWindow +time_Interval moveRestrictionDates } class Seller { <> founded by Transaction } class Buyer { <> founded by Transaction } class Phase { <> SKOS concept (ODR-0011) } class Chain { propertyDependencyType } class Property { <> } class Title { <> } Transaction "1" --> "1..*" Seller : founds Transaction "1" --> "1..*" Buyer : founds Transaction "1" --> "1..*" Phase : hasPhase Transaction "1" --> "0..*" Chain : chain Chain "1" --> "1..*" Transaction : otherPropertyInChain Transaction --> Property : relates Transaction --> Title : relates

Alternatives Considered and Chosen Outcome

Three candidate designs were evaluated against the two key drivers — role-founding coherence and interval-vs-instant accuracy — with Transaction-as-Relator + Phases + OWL-Time the only option satisfying both.

flowchart LR accTitle: Alternatives considered and chosen outcome accDescr: Three candidate designs mapped against role-founding and interval-modelling drivers, showing why only the chosen option passes both tests. A1["Keep schema shape
status as datatype,
instants only"]:::process --> D1{"Roles founded?"}:::warning D1 -->|"no"| R1["REJECTED
RoleMixins unfounded"]:::error A2["Relator + Phases
+ instants only
(no OWL-Time)"]:::process --> D2{"Roles founded?"}:::warning D2 -->|"yes"| D2b{"Intervals
modelled?"}:::warning D2b -->|"no"| R2["REJECTED
Q2 incoherence reproduced"]:::error A3["Relator + Phases
+ OWL-Time intervals"]:::process --> D3{"Roles founded?"}:::warning D3 -->|"yes"| D3b{"Intervals
modelled?"}:::warning D3b -->|"yes"| C["CHOSEN
Adopted Conditional
on interval consumers"]:::success

ODR Dependency Graph

ODR-0007 depends on the foundation, identity-crux, and agents ODRs, implements the programme and partitioning ODRs, and has no predecessors to supersede.

flowchart LR accTitle: ODR-0007 dependency graph accDescr: Directed graph of depends-on and implements relationships declared in the ODR-0007 frontmatter. ODR0004["ODR-0004
Foundation"]:::process ODR0005["ODR-0005
Identity Crux"]:::process ODR0006["ODR-0006
Agents & Roles"]:::process ODR0011["ODR-0011
Enumerations"]:::process ODR0003["ODR-0003
Programme"]:::success ODR0017["ODR-0017
Partitioning"]:::success ODR0007["ODR-0007
Transactions & Lifecycle"]:::infra ODR0004 -->|"depends-on"| ODR0007 ODR0005 -->|"depends-on (gate)"| ODR0007 ODR0006 -->|"depends-on"| ODR0007 ODR0011 -->|"depends-on"| ODR0007 ODR0007 -->|"implements"| ODR0003 ODR0007 -->|"implements"| ODR0017

Alternatives

  • Keep the schema shape — one opda:Transaction class with status/milestone datatype properties and prov:atTime instants only. Fatal flaw: leaves the ODR-0006 RoleMixins unfounded and cannot express the interval-valued lifecycle facts the date-pair leaves clearly imply.
  • Transaction-as-Relator + Phases + instants-only (no OWL-Time) — founds the roles correctly and treats status as anti-rigid Phases, but defers interval modelling. Fatal flaw: reproduces the Q2 incoherence the Council reversed (≈6-3) — using prov:atTime instants while proprietorship and lease intervals go unmodelled.

Consequences

  • Downstream modules must consume the founding-Relator pattern: ODR-0006 RoleMixins resolve their founding citation against opda:Transaction (and the sibling Relators) defined here.
  • ODR-0011 must publish SKOS concept schemes for milestones, legalForms and participantStatus, with skos:prefLabel/skos:definition/dct:source populated per the term-sourcing convention.
  • ODR-0009 must model milestone transitions as prov:Activity instances that reference (do not re-model) the Phase changes defined here.
  • ODR-0013 must publish SHACL shapes for time:Interval well-formedness and lease-term derivation.
  • OWL-Time is adopted Conditional over a recorded Allemang/Davis “defer until a concrete consumer” dissent; if lifecycle interval consumers fail to materialise, the temporal layer carries cost without a proven user.
  • The status SKOS scheme(s) cannot be frozen until the single-scheme-vs-per-role question is resolved in a follow-up council session.
  • Capacity cross-link: sellersCapacity and the asserted-vs-evidenced split remain owned by ODR-0006; the Transaction relator is the relation within which a capacity is asserted, so the ODR-0009 evidence attachment point reaches the transaction through the founded role.
  • Target versions: this module targets RDF 1.2 and SHACL 1.2 per the Core-tier pin in ODR-0002.
  • Deliverables (when fleshed out): transactions-lifecycle.ttl; status/milestone/legal-forms SKOS schemes (→ ODR-0011); an OWL-Time usage-pattern note covering interval construction from the schema’s date-pair and lease-term leaves; SHACL interval-well-formedness shapes (→ ODR-0013).

References

  • Anchor: ODR-0003
  • Foundation: ODR-0004
  • Gating crux: ODR-0005
  • Agents & roles whose RoleMixins this module’s Relator founds: ODR-0006
  • Provenance & claims: ODR-0009
  • Enumerations: ODR-0011
  • Validation: ODR-0013
  • Vocabulary catalogue: ODR-0014
  • Ontology-language adoption (target versions): ODR-0002
  • Council deliberation: session-001 — Q2 (OWL-Time adopted Conditional, ≈6-3, Allemang/Davis dissent), Q3 (partition by concern)
  • Schema inputs: milestones, listed, legalForms, chain, participants/participantStatus, startYearOfLease, lengthOfLeaseInYears, lastDemandPeriod {from, to}, moveRestrictionDates, listedDate, soldDate, started, completed, expected
  • Vocabularies: OWL-Time (intervals/instants — Conditional, catalogued in ODR-0014); SKOS (→ ODR-0011); PROV-O (prov:atTime instants, → ODR-0009); DCAT Conditional where the transaction references published datasets (→ ODR-0014)

Comments

Loading comments…