OPDA Knowledge base
Business Data Knowledge Generated 2026-05-15 DAMA · Metadata Management · Data Modeling & Design

Data dictionary

Deduplicated and enriched from PDTF Schemas v3 (base transaction + 16 canonical overlays) and the OPDA Glossary spreadsheets. Each entry carries a suggested RDF URI for use in the ontology workstream.

See also: Ontology manual — Logical tier

This page surfaces 1,538 PDTF schema-derived data elements (broad, schema-level). The Logical tier of the Ontology manual documents 41 ontology entities with typed attribute tables, cardinality, identity keys, and ER diagrams (deep, ontology-level). The two are complementary: this dictionary is the raw material; the manual's logical tier is the refined, generator-emitted ontology reference.

Headline numbers
  • 16 canonical schemas (5 redundant ones excluded)
  • 1,538 unique data elements — one entry per unique concept name, deduplicated across all schemas
  • 699 entities — objects and arrays (things that exist in the model)
  • 840 properties — scalar fields (attributes of entities)
  • 54 business terms from the merged OPDA Glossary
  • 554 concepts in the generated SKOS scheme
Loading data elements…

Deliverables

All files generated to source/00-deliverables/semantic-models/.

FileSizeWhat it isAudience
data-dictionary-canonical.json ≈ 1.8 MB Machine-readable: 8,458 property-path entries across the 16 canonical schemas (one row per schema×path occurrence, not deduplicated). The browser above shows the 1,538 deduplicated concepts. Engineers, code generators
data-dictionary.json 3.0 MB Original extraction including derived/superseded schemas (14,287 entries). Kept for transparency — do not use for counts. Audit only
data-dictionary.md ≈ 110 KB Human-readable: per-schema tables, deduplicated to unique leaf names, organised by bounded context. Engineers, BAs, reviewers
audit.json ≈ 2 KB What the inflation was, why, and the corrected figures. Anyone reviewing numbers
glossary-merged.json 20 KB Merged of the two OPDA Glossary.xlsx files (PoC + Technical WG), deduplicated to 54 unique terms. Engineers, modelling
business-glossary.md 23 KB Three-section human glossary: OPDA Glossary terms A–Z, top-level PDTF concepts from schema annotations, external vocabulary (W3C VC, DID, ToIP). Stakeholders, working groups, new joiners
business-glossary.ttl 164 KB SKOS Concept Scheme — 554 concepts. Loads directly into Protégé / GraphDB / TopBraid for the ontology work. Ontology engineers

Canonical schema inventory

SchemaFileBounded contextUnique leaves
Base Transactionpdtf-transaction.jsonBase — spans all contexts1,557
BASPI v5baspi5.jsonEstate Agency318
Residential Data Schemards.jsonProperty Data Services196
Property Info Questionnairepiq.jsonSurveying184
Property Information Formta6.jsonConveyancing178
NTS Sales v2nts2.jsonEstate Agency160
Leasehold Property Enquirylpe1.jsonConveyancing136
Local Authority Searchcon29R.jsonProperty Data Services125
NTS Lettings v2ntsl2.jsonEstate Agency124
Leasehold Information Formta7.jsonConveyancing98
Fittings & Contentsta10.jsonConveyancing90
Mortgage Enquiriesfme1.jsonMortgage Lending78
Office Copyoc1.jsonProperty Data Services68
Drainage & Watercon29DW.jsonProperty Data Services34
SR24sr24.jsonProperty Data Services7
Local Land Chargesllc1.jsonProperty Data Services3

How it was built

flowchart LR S1["`v3 base schema pdtf-transaction.json`"]:::external S2["`16 canonical v3 overlays BASPI · TA6/7/10 · NTS CON29R/DW · PIQ · OC1 · LLC1 LPE1 · FME1 · RDS · SR24`"]:::external G1["`Glossary.xlsx Trust Framework PoC`"]:::external G2["`Glossary.xlsx Technical Working Group`"]:::external EXT["`W3C VCDM 2.0 W3C DID 1.0 ToIP Foundation`"]:::external PROC["`Schema walker + deduplication + title enrichment + RDF URI generator + glossary merger + SKOS generator`"]:::process D1["`properties.js 1,538 unique concepts entity + property kinds + RDF URI per entry`"]:::data D2["`entities.js 54 glossary terms + 470 schema entities`"]:::data D3["`glossary-merged.json 54 terms deduplicated`"]:::data D4["`business-glossary.md tri-source glossary`"]:::data D5["`business-glossary.ttl SKOS · 554 concepts`"]:::data S1 --> PROC S2 --> PROC G1 --> PROC G2 --> PROC EXT --> PROC PROC --> D1 PROC --> D2 PROC --> D3 PROC --> D4 PROC --> D5
Build pipeline. Deterministic — re-runnable any time the schemas or glossaries change.

Suggested RDF URIs

Every data element carries a suggested RDF URI using the https://w3id.org/opda/pdtf/ base namespace — not yet registered or dereferenced, but stable enough to use in draft ontology work.

  • Entities (objects / classes): https://w3id.org/opda/pdtf/class/ClassName
  • Properties (scalar attributes): https://w3id.org/opda/pdtf/vocab/propertyName

These will be refined when the upper ontology is defined (see step 2 under What to do with these deliverables). Cross-context concepts (e.g., address, name) share a single URI — disambiguation into context-specific sub-properties is deferred to that step.

Source citations

Every entry in the browser carries a source field (primary schema) and a sources array listing all schemas that define that path. Use the Sources facet to explore which overlays contribute a given element.

The primary sources, with paths:

Cross-context concepts

Many paths appear in three or more overlays — these are the cross-context vocabulary that needs explicit reconciliation in the ontology. Top examples (sorted by spread):

address, name, date, amount, type, description, reference, status, provider, title, property, id, required, code, category

Full list with which overlays contain each: see the "Cross-context concepts" section of source/00-deliverables/semantic-models/business-glossary.md.

What to do with these deliverables

  1. Have an editorial pass over business-glossary.md with the Technical Working Group — reconcile the OPDA Glossary terms with the property-data terms extracted from the schemas.
  2. Define the upper ontology — pick the core classes (Transaction, Property, Participant, Claim, Document, Form, Search) and align with W3C VC. Register the https://w3id.org/opda/pdtf/ namespace and replace the suggested URIs with resolvable ones.
  3. Per-overlay JSON-LD contexts — for each of the 16 canonical overlays, author a @context that maps JSON property names to ontology terms. Start with baspi5.json as the worked example.
  4. Generate SHACL shapes from the JSON Schema validation rules. Most rules (required, enum, pattern, type) translate mechanically.
  5. Disambiguate cross-context names — for each name appearing in multiple overlays, decide whether it refers to the same concept (single URI) or to context-specific concepts (separate URIs with mapping).

Comments

Loading comments…