accepted 2026-08-19

Treat the Property Pack ontology as an accelerated SPDTF component

Update 2026-09-03 — ADR-0074’s route amendment moves the canonical Property Pack reader family from /spdtf/property-pack/** to /development/property-pack/**. This changes its web address, not its scope, authority, evidence, lifecycle or relationship to SPDTF.

Update 2026-08-20: the semantic-documentation portion is implemented as two linked audience paths. Understand ontologies teaches the concepts and how to read the model; How we model SPDTF documents the evidence-up method, semantic package, contexts, modelling rules, standards, evidence, validation and coverage. This partial implementation does not change this ADR’s Accepted status or make Proposed ADR-0065/0068 lifecycle policy operative.

Update 2026-08-21: the two-part PDTF schema hierarchy is implemented. The canonical /ontology branch now uses linked task-category pages, nested model tiers and a context index to organise every existing technical route without moving it or changing page-level status. Expandable labels remain links; separate controls disclose their children.

Update 2026-08-21 — hierarchy-reflecting PDTF schema routes: ADR-0076 retains this two-part model but moves its reader documentation beneath /spdtf/inputs/pdtf-schema/schema-and-supporting-material/** and /spdtf/inputs/pdtf-schema/schema-derived-ontology/**. The earlier no-move statement above remains historical implementation provenance; it no longer governs routing. Old documentation routes are removed without redirects, while the canonical /pdtf/** RDF identifier paths and representation contract remain exact.

Context and Problem Statement

The existing technical input has two distinct but related bodies:

the PDTF schema and supporting material: JSON Schemas and overlays, the data dictionary and the business glossary; and
the schema-derived ontology extracted from those artefacts, together with its model views, qualified mappings and provenance.

The PDTF schema contains the Property Pack definition. The schema-derived ontology should therefore contain corresponding Property Pack coverage, although it may not expose that coverage as one explicit, governed module or profile. The current repository proves that every one of the 451 required Property Pack paths occurs in the local v3.5 schema. It does not yet prove complete semantic equivalence between those paths and the extracted ontology: only 34 complete required paths have exact entries in the current ontology provenance index. Consolidation, one-to-many modelling and provenance gaps mean that this is not a semantic coverage percentage. It establishes the need for a proper crosswalk.

The former /v2/** corpus is the Property Pack ontology generated from the Property Pack definition. Its old route label is historical implementation provenance, not a standards version. The corpus belongs to SPDTF development. It is not an external input sitting beside SPDTF and it is not the whole future SPDTF ontology. It is a priority component that the wider ontology will identify as its Property Pack part or profile.

The Property Pack is the standardised bundle of property data that accompanies a transaction. In ontology terms it is an exchange or delivery profile spanning several semantic contexts, not one universal bounded context. Its 451 required source items define the initial coverage boundary; they do not prescribe 451 ontology properties or the structure of the legacy JSON tree.

The Property Pack ontology follows an accelerated governance sequence. The Technical Working Group must review the current candidate and make a determination by the end of September 2026 so that it can support other government-scheme work and OPDA’s case to be recognised as the authoritative steward. There is not enough time to require prior feedback from every domain working group. After the technical determination, the wider working groups may review the relevant parts and propose controlled changes.

ADR-0074 is already implemented in code, but its “development input” placement and authority text no longer describe this programme model. ADR-0067 also assumes affected domain-working-group review before promotion and therefore needs this explicit, scoped governance amendment.

Decision Drivers

Make the September Technical Working Group milestone visible and actionable.
Present the Property Pack ontology as part of SPDTF without implying that it is the whole SPDTF ontology.
Show the actual lineage through the PDTF schema and schema-derived ontology.
Preserve the current candidate and its citations while allowing later governed revisions.
Separate technical determination from later domain review, publication, adoption and external recognition.
Prevent “Property Pack”, its source definition, its ontology and an approved exchange contract from becoming interchangeable labels.
Keep DBT policy, OPDA’s Smart Data modelling group and the candidate DBT semantic context distinct.

Considered Options

Keep Property Pack under a generic Development input branch. Rejected because it misstates ownership, hides the priority workstream and flattens unrelated page types.
Wait for every domain working group before making a determination. Rejected because it cannot meet the September milestone.
Repair the schema-derived ontology in place. Rejected as the sole method because inherited schema topology would obscure which SPDTF meanings were deliberately reconsidered.
Use an accelerated Technical Working Group determination followed by controlled wider review (chosen). This preserves the deadline while making later semantic improvement explicit rather than pretending broader consensus already exists.

Decision Outcome

The Property Pack ontology is a first-class workstream within SPDTF development. The reader-facing hierarchy becomes:

SPDTF
├── Overview and programme status
├── Property Pack ontology
│   ├── What a Property Pack is
│   ├── Purpose, government use and September milestone
│   ├── Definition and 451-item scope
│   ├── PDTF schema lineage and semantic crosswalk
│   ├── Current ontology model
│   ├── Technical Working Group determination
│   ├── Versions, validation and artefacts
│   └── Later domain-working-group review
├── Ontologies and semantic modelling
│   ├── Understand ontologies
│   │   └── How to read the model
│   └── How we model SPDTF
│       ├── Evidence-up modelling
│       ├── Semantic package and context boundaries
│       ├── Modelling rules and upper-ontology lenses
│       ├── Standards, evidence and qualified mappings
│       └── Coverage, validation and projections
└── Wider SPDTF ontology development
    ├── Domain and scheme working groups
    ├── Interoperability Working Group
    └── Candidate, question and change registers

The PDTF schema area exposes its two-part structure:

PDTF schema
├── Schema and supporting material
│   ├── JSON Schemas and overlays
│   ├── Data dictionary
│   ├── Business glossary
│   ├── Implementation guidance
│   └── Usage and implementation evidence
└── Schema-derived ontology
    ├── Lineage, provenance and verification
    │   ├── Historical modelling record
    │   └── Independent schema-to-ontology verification
    ├── Model views by audience and nested implementation tiers
    ├── Concepts and architecture, including ontology contexts
    ├── Terms and model resources
    ├── Validation and examples
    ├── Trust, governance and limitations
    └── Use and tooling

Property Pack route and version contract

/spdtf/property-pack/** is the single canonical Property Pack ontology family.
The 690-page technical corpus moves there as one atomic family: old /v2 maps to /spdtf/property-pack, old /v2/comparison maps to /spdtf/property-pack/pdtf-schema-lineage, and every other old /v2/{suffix} maps to /spdtf/property-pack/{suffix}.
The complete /modelling/property-pack source catalogue moves to /spdtf/property-pack/definition-and-scope; it is not a competing landing page.
/v2/** and /modelling/property-pack are removed without redirects. The operator explicitly accepted that URL break on 2026-08-19; this is not a compatibility promise.
A later determination or revision receives an explicit version and immutable change record. It must not silently rewrite the evidence for the September determination.
The migration receipt maps every old page and fragment to its exact canonical replacement and proves that neither retired family is emitted.

PDTF schema to Property Pack crosswalk

The maintained crosswalk must account for all 451 source items and support many-to-one and one-to-many semantic treatment:

Property Pack source item
→ PDTF schema path
→ schema-derived ontology construct(s) or recorded gap
→ SPDTF Property Pack construct(s)
→ retained, revised, consolidated, split or missing disposition

Lexical equality and exact source-path matches may assist the audit but cannot establish semantic equivalence by themselves.

Accelerated determination and later review

The governance sequence is:

preserve the current Property Pack ontology candidate and its evidence;
present it as-is to the Technical Working Group with explicit review questions;
record the group’s determination and every qualification or required change;
version the determined Property Pack ontology and its validation evidence;
allow its use in wider government-scheme work to the extent actually authorised;
invite the domain, scheme and Interoperability working groups to review relevant meanings later; and
process later proposals through controlled change, impact assessment and a new version rather than silently changing the determined baseline.

The Technical Working Group is not the Property Technology bounded-context group. Before the September determination is represented as authoritative, Governance must record the Technical Working Group’s canonical identity, delegated remit, decision owner, quorum or decision rule, evidence set, allowed outcomes and escalation path.

Independent status dimensions

Every Property Pack page must distinguish:

source-definition status;
ontology candidate and version status;
Technical Working Group determination status;
later domain-working-group review status;
implementation or release status; and
external government-use or authority-recognition status.

Technical validation does not by itself prove semantic agreement. A Technical Working Group determination does not imply that every domain group has reviewed the result. Government use supports OPDA’s authority case but does not, by itself, prove that OPDA has received a defined statutory or externally delegated authority role.

DBT Smart Data boundary

External DBT Smart Data policy and official evidence remain under Programme.
The OPDA-internal Smart Data scheme-design group remains under Working groups and makes no claim to be a DBT or statutory body.
The machine-proposed DBT Smart Data semantic context remains inside the Property Pack ontology’s context map and must be labelled as a model component.

These three records cross-link; they do not share an unqualified navigation label or authority status. Wider government use of the Property Pack must not automatically be described as DBT use.

Consequences

Good, because the site reflects the actual September delivery and decision path.
Good, because the Property Pack is visibly part of SPDTF while remaining a bounded profile rather than the entire ontology.
Good, because the schema-derived ontology’s expected Property Pack coverage becomes an auditable claim rather than an assumption.
Good, because later working-group review can improve the model without erasing the technical determination used by government consumers.
Bad, because the current implemented navigation and status registry now require a coherent follow-up change.
Bad, because a complete 451-item semantic crosswalk is additional work.
Bad, because circulated /v2/** and /modelling/property-pack URLs intentionally stop resolving; the cleaner information architecture is preferred over compatibility.

Confirmation

This decision remains Accepted while its full governance and lineage contract is completed. The operator additionally authorised the no-redirect route consolidation on 2026-08-19. The route slice is independently complete only when the atomic move, information-retention receipts, navigation, status and browser gates all pass.

Implementation requires all of the following:

one canonical Property Pack hub and one unambiguous nested navigation branch;
the implemented two-part PDTF schema navigation;
a machine-readable 451-row lineage crosswalk;
a recorded Technical Working Group governance contract and September deadline;
independent status fields for determination, later review, release and external authority;
distinct DBT policy, internal-group and model-context labels;
removal of generic modelling guidance from the SPDTF root in favour of the ontology-method branch;
preservation of every current Property Pack information block and fragment at its declared canonical replacement, with the old route families absent; and
unit and browser tests for hierarchy, ownership, search facets, breadcrumbs, status wording, route preservation, accessibility and responsive behaviour.

No publication or deployment is authorised by this ADR.

More Information

Amendments

2026-08-22 — Chair-authority terminology correction. Maria Harris, OPDA Chair, clarified that the inherited version-numbered draft technical scheme was not created collaboratively and was not endorsed by OPDA. The existing source is the PDTF schema and supporting material; the extracted model is a separate schema-derived ontology. SPDTF is the first collaboratively authored scheme draft. The Property Pack remains an accelerated SPDTF component, and its crosswalk now records schema path → schema-derived construct or gap → SPDTF construct. Reader routes use /spdtf/** and /spdtf/inputs/pdtf-schema/**; historical /v2/** source-route evidence and stable /pdtf/** identifiers remain unchanged.