Concept taxonomy (SKOS)

Terminology layer for PDTF. Three families of SKOS concept scheme: one cross-cutting Core, one per bounded context (six in total), and a growing set of small code-list (enumeration) schemes for controlled vocabularies. Concepts that mean the same thing across contexts are defined once and tagged with multiple skos:inScheme memberships — not duplicated, not collapsed into one tree.

What already exists

• Initial SKOS seed — source/00-deliverables/semantic-models/business-glossary.ttl (554 concepts in one flat scheme: 54 OPDA glossary terms + 500 schema-derived).
• 1,557 unique leaf property names from the schemas (see Data dictionary & glossary).
• No cross-scheme mapping triples yet — the seed flattens everything into one container, which is what this work corrects.

The schemes

Core vocabulary scheme

The spanning vocabulary — concepts that transcend any single context. These are the nouns the OWL ontology mints as classes (pdtf:Property, pdtf:Participant, pdtf:Transaction, pdtf:Document) plus the cross-context property concepts the data dictionary already identifies (address, name, email, dateOfBirth, …).

Source: the 389 cross-context concepts already counted in the data dictionary (appear in 3+ schemas).

One scheme per bounded context

Six schemes, mirroring the six primary industry contexts in 12-bounded-contexts and the overlay grouping already used by the data dictionary:

Code-list schemes (enumerations)

Small controlled vocabularies for things that are values rather than nouns — used wherever an instance needs to be tagged with one of a fixed set of categories. Each is its own scheme, kept short and self-contained. The bounded-context schemes refer to these as tag values; they do not duplicate the concepts.

Natural neighbours likely to grow into their own enum schemes: tenure types (Freehold, Leasehold, Commonhold), EPC ratings (A–G), Council tax bands (A–H), verification levels for the trust framework.

What lives outside SKOS

The earlier nine-branch proposal mixed terminology with structure and state. SKOS keeps the terminology; the rest moves to its natural home:

• Structural classes — pdtf:Property, pdtf:Participant, pdtf:Document, pdtf:Transaction, pdtf:Form, pdtf:Search are OWL classes. The SKOS schemes hold the terms; OWL holds what those terms are. Form and Search appear in both layers — class-of-thing in OWL, value-of-tag in the code-list schemes above.
• Transaction lifecycle — the machine — the ordering of states (Listed → OfferAccepted → Exchanged → Completed) is a state machine modelled in PROV-O activities. The state labels are in pdtf-states:Scheme above; the transitions are not.
• Claim & Evidence — the W3C VC wrapper. PDTF reuses vc:Credential, vc:Issuer, vc:Holder, vc:Verifier — we do not mint our own.
• Financial / Legal — subject-matter facets, not concepts. Apply as dcterms:subject tags on individual concepts where useful, not as schemes.

Worked example: address

"Address" appears in 10 overlays. In most contexts it is exactly the same concept; in Estate Agency it is subtly different (a marketing label, not a registered identifier). The taxonomy makes that distinction explicit — and avoids minting redundant URIs.

Rule of thumb

• Same meaning across N contexts → define the concept once (in scheme:Core) and list every context it lives in via skos:inScheme. SKOS permits a concept to belong to many schemes.
• Meaning genuinely differs → this historical design proposed a context-specific concept and skos:closeMatch; any current relationship must be reassessed under the Category 8 method.
• Never mint context-specific concepts that skos:exactMatch back to the core — that is just two URIs for one concept, which the unique-name principle forbids.

@prefix skos:      <http://www.w3.org/2004/02/skos/core#> .
@prefix opda:      <https://opda.org.uk/pdtf/> .              # OWL classes + properties (flat)
@prefix scheme:    <https://opda.org.uk/pdtf/scheme/> .       # SKOS concept schemes
@prefix s-core:    <https://opda.org.uk/pdtf/scheme/core/> .          # core-scheme members
@prefix s-ea:      <https://opda.org.uk/pdtf/scheme/estateAgency/> .  # estate-agency members

# Define address ONCE — list every scheme it belongs to
s-core:address  a skos:Concept ;
    skos:prefLabel "Address"@en ;
    skos:definition "A postal address identifying a building or land parcel."@en ;
    skos:inScheme  scheme:Core ;
    skos:inScheme  scheme:Conveyancing ;
    skos:inScheme  scheme:PropertyDataServices ;
    skos:inScheme  scheme:MortgageLending ;
    skos:inScheme  scheme:Surveying .

# Mint a separate concept ONLY when the meaning genuinely differs
s-ea:marketingAddress  a skos:Concept ;
    skos:prefLabel  "Marketing address"@en ;
    skos:inScheme   scheme:EstateAgency ;
    skos:closeMatch s-core:address ;
    skos:scopeNote  "Approximate — may exclude flat numbers; not the registered title address."@en .

The result: one URI for the shared concept, one extra URI only where the semantics actually diverge. A SPARQL query asking "what address concepts apply in Conveyancing?" returns the single pdtf:address. The same query against Estate Agency returns pdtf-ea:marketingAddress — and a follow-up closeMatch hop discovers it's a near-synonym of the core address concept.

URI strategy

The kind-split (ADR-0006) keeps each kind in its own namespace: OWL classes and properties in the flat term namespace (https://opda.org.uk/pdtf/), SKOS schemes and their concepts under /pdtf/scheme/, SHACL shapes under /pdtf/shape/. So the same label can serve both roles without URI collision — opda:Property (the class) is a different resource from the property concept under its scheme.

Why multiple schemes, not one

A bounded context is, by Eric Evans's definition, a linguistic boundary: a term means what it means inside the context, and reconciling it with another context is an explicit modelling step. skos:ConceptScheme formalises exactly that — it is the right SKOS construct for "this is where this term is at home." When the same concept genuinely does mean the same thing in multiple contexts, SKOS lets it sit in multiple schemes (skos:inScheme is many-to-many); when meaning diverges, the mapping relations (closeMatch, broader, narrower) carry the reconciliation that context-map patterns describe at the DDD layer.

A single flat scheme cannot express that "address" is the same concept in Conveyancing and Property Data Services but a near-synonym ("marketing address") in Estate Agency — it either collapses them (losing context fidelity) or duplicates them with no link (losing the reconciliation). Multiple schemes with multi-membership and explicit mappings is the SKOS-native way to model what we already say in the bounded-contexts page.

Next work

1. Mint the scheme URIs — Core, 6 contexts, and the initial 4 enum schemes (11 schemes to start) — and update business-glossary.ttl so each concept declares its skos:inScheme — multi-valued for shared concepts.
2. For each of the 389 cross-context concepts, decide: shared (one URI, multiple skos:inScheme), genuinely-variant (separate URI + skos:closeMatch), or hierarchical (skos:broader / narrower). Start with address, name, email, dateOfBirth.
3. Draft the first enumeration schemes: form types, search types, transaction states, participant roles. Each is small (≤20 concepts) and self-contained.
4. Hand the structural classes (Property, Participant, Document, Transaction, Form, Search) over to the OWL ontology, and the state-machine transitions over to PROV-O activities.
5. Land the cross-scheme mapping file at source/00-deliverables/semantic-models/mappings/cross-scheme.ttl (the empty folder is already there).
6. Wire the existing data browser on Business glossary to filter by scheme and by scheme family.