Sensitivity and policy: model privacy, roles and scope

A public model does not make its instance data public

A definition of a person’s contact-detail property can be openly readable without exposing anyone’s contact details. A model may explain how an inspection report relates to a transaction without making every report available to every visitor. Vocabulary publication, data disclosure and access enforcement are different decisions.

In the fictional Harbour Court dossier, the report version, a participant's contact details and the transaction have different identities. Start with a modelling question: “Can we identify which contact-detail property is classified as personal data, and the particular transaction and report version to which a stated role or authority relates?” This question earns explicit relationships and qualifications; it does not invent a permission or legal conclusion.

This chapter teaches ontology meaning, not a Trust-governance or security-operations course. The broader programme context belongs in DBT identity, roles and Trust, stewardship and privacy and the standard/operator distinction. These fictional examples are not legal advice, adopted privacy values or claims that an OPDA system enforces access.

Use the retained concern that owns the meaning

ADR-0063's Trust clarification and ADR-0067's resource-home rule retain privacy, access, provenance and time within ontology modelling. Each OPDA resource still has one semantic home in the established contexts; an externally governed resource retains its external owner. Reuse and mapping do not copy scheme authority into every property-domain model.

New concepts and mappings need a competency question, a semantic owner and an adopted profile. These connections do not import Category 6 as a governance ontology or authorise a general role-based access-policy engine.

Keep sensitivity independent from subject classification

A classification such as “transactional data” says something about the role of information in a model or information landscape. A sensitivity value says something different about handling expectations. Being master data does not make information public; being transaction data does not by itself make it restricted. Category 5 classification metadata and category 11 sensitivity therefore remain separate concerns.

Likewise, an access role is not the same as a person’s domain role. A seller participates in a transaction; a permitted reader is a role within an access policy. One may inform the other under a declared rule, but a Seller classification must not automatically grant access to every report at an address.

Sensitivity may depend on the actual content and context. A class-level annotation is a modelling signal, not a complete decision for every instance. Neither inheritance nor a shared property name silently supplies a blanket access decision.

Use the privacy vocabulary for the concern it describes

The selected method uses DPV as a reference vocabulary for personal-data categories, purposes, processing and related policy concepts. It uses governed local annotation properties to describe classes and properties, with vocabulary alignments where meanings fit. That is not the same pattern as asserting that an ontology class is itself an individual processing activity.

The adopted category distinguishes sensitivity levels, personal-data flags and categories, applicable-regulation concepts, processing purpose, lawful-basis concepts, residency information and access levels. These are related dimensions, not one boolean “compliant” flag. Their values and scope need review; an identifier containing the word “consent” does not demonstrate that valid consent was obtained.

The adopted annotation-first pattern precedes more detailed qualified policy records. Later phases must not be presented as current operational capabilities simply because their classes or future patterns appear in a decision record. A referenced vocabulary is also not automatically an owl:imports dependency.

Keep sensitivity, personal-data categories, regulations, lawful bases, retention actions, residency/transfer and access levels in their separately governed schemes. Review mappings to the applicable canonical DPV, DPV-PD or legal concept; there is no blanket skos:exactMatch. A generic SKOS concept type cannot establish membership in the particular scheme the binding requires.

This chapter follows ODR-0054's adopted pin and scoped applicability/binding corrections. It does not promote a newer upstream predicate declaration: that requires a separate OPDA adoption decision. No new policy predicates or processing-purpose vocabulary are adopted by the examples.

Add ODRL only for the selected policy gaps

OPDA ODR-0057 conditionally adds ODRL through the DPV profile. DPV supplies classification and context; ODRL expresses permissions, prohibitions, duties and constraints. This is a division of jobs, not a competition to place every privacy statement in whichever vocabulary has the shortest term.

The selected ODRL 2.2 Common Vocabulary scope has exactly three conditional uses: retention policies with deadlines or elapsed-time conditions; permissions conditioned on dynamic state; and cross-border transfer policies composing reviewed conditions. Other profiles and uses need an amendment. This is not a general substitute for the programme's governance arrangements.

Within the selected DPV Profile of ODRL, a policy must have a target resolving to an appropriately DPV-typed resource. Merely finding odrl:target is insufficient. A constraint has a left operand, operator and right operand; a DPV classification must not be substituted for an ODRL left operand merely because it names the topic. Appropriate DPV terms may supply operand values. The target's type and the vocabulary boundary are distinct structural checks.

The OPDA restriction on automatic policy generation is particularly important: scoped ODRL policies are human-curated, not inferred from source-code structure, field names or extraction confidence. A model can reveal that a decision is needed. It cannot invent the regulatory intent or permission needed to make that decision.

Work through the Harbour Court contact-detail model

The fictional inspection occurred on 12 August 2026. Report v1 was issued on 14 August and corrected by v2 on 20 August; the correction did not create a new inspection. The proposed ontology also has an inspection-contact property and a person participating in a particular transaction. All identifiers below are illustrative example.org resources; no contact value, credential or actual person's information is published.

An annotation describes the model element

A transaction role is not an access role

Suppose the person plays Seller in the transaction concerning Harbour Court. The domain relationship must identify its bearer and transaction. If a separate scheme rule refers to an authorised reader, any connection needs an explicit role, data scope, action and contextual justification. It might concern reading one report version for a stated purpose; it cannot be inferred as access to all records sharing an address.

Map to the separately owned scheme meaning through the mapping discipline, preserving its exact context-map applicability. Do not mint another copy of a scheme role inside Surveying and Valuation, equate Seller with an access role, or treat scheme permission, legal basis and consent as synonyms.

A report's evidence and an authority's validity answer different questions

A claim about the inspection can refer to report v2 and its supplier under the selected evidence and time patterns. If an authority claim has its own evidence and validity interval, identify those separately. The inspection date, report issue date, time a statement was recorded and authority expiry must not collapse into one timestamp.

The model-authoring history may say who drafted the contact property's definition. It does not say who supplied a particular person's details, prove that the inspection occurred or establish accreditation. Likewise, a recorded authority that applied in August cannot establish permission in September without the relevant current evidence. The model exposes that unanswered question; this lesson does not design an access evaluator.

Review the exact subject and scheme in a qualified classification

Under ODR-0054, a qualified sensitivity classification has exactly one subject IRI and exactly one level from the sensitivity scheme, with the scoped classification-time and actor/provenance requirements. A personal-data binding has exactly one property IRI and one boolean flag. True requires a category; every supplied category must belong to the personal-data scheme.

An annotation's applicability to classes or properties must follow the selected exclusive property-side mechanisms. Do not turn alternative targets into conjunctive RDFS domains. Required definitions and ontology ownership also need declaration checks that select annotation properties even when their ownership link is missing.

Keep the adopted and deferred boundaries visible

Start with classification metadata. Qualified use can introduce retention schedules, access policies and purpose declarations under their governed profile; machine-executable policy remains conditional under ODR-0057. Neither an annotation nor a populated policy graph proves an operating capability.

ODR-0054's selected surface covers the two qualified assertion profiles above, the DPV/ODRL boundary validator, scheme completeness and explicit annotation-property documentation/ownership targeting. Preserve structural Violation and advisory provenance/documentation severity. This is a required method surface, not evidence that five OPDA validators have been delivered.

Regulation-to-lawful-basis conditionals, retention and access-policy completeness, and sensitivity-escalation checks remain staged pending a scoped decision. Do not resurrect historical shape lists or adopt a newer upstream change through a teaching example. The separate adoption gate remains separate from explaining the currently adopted method.

What validation can establish—and what it cannot

Shapes can check whether a qualified sensitivity classification identifies its subject and level, whether a personal-data flag has the required category, whether values come from the chosen schemes, and whether a policy uses the prescribed vocabulary boundary. Such checks establish structural conformance to the selected representation.

They do not prove the classification is substantively correct, that a legal basis applies, that a recipient’s identity has been authenticated or that a service has refused an unauthorised request. Those require the relevant authority, evidence and enforcement mechanisms. Describe the check that actually ran instead of compressing all of these questions into “policy validated”.

Named-graph placement does not confer authorisation or transfer semantic ownership. Enforcement is a downstream responsibility. Keep that boundary explicit without making deployment, registry operation or policy evaluation part of this ontology lesson.

Failure case: a domain role becomes blanket permission

An author sees “Seller” and a valid personal-data binding, then asserts that the person may read every report at Harbour Court. Neither premise supplies that conclusion. The role is scoped to a transaction; the annotation describes a model property. No particular access action, data scope, purpose or current authority has been established.

The repair is to remove the unsupported access conclusion from the proposal, preserve the two legitimate statements and record the missing semantic question for the responsible owner. If an access relationship is later justified, model its actual scope and evidence through an adopted profile. Do not add a generic “trusted” flag to make the unresolved question disappear. SHACL can test the representation; annotations and JSON-LD do not authenticate actors, grant rights, establish legal compliance or enforce access.

Source contract

Required method: OPDA ODR-0054 R2–R6, including its amended shape/profile boundaries and 28 August applicability correction; ODR-0057 R3–R9, especially the three scoped policy uses and R7’s human-curation limitation. Category 11 is retained; importing category 6 as a governance ontology is outside the selected OPDA scope.

Adoption provenance: upstream revision 67174057e6384b79d0b28b7736fe70a66e112895, 5 September 2026. See standards and decisions for register and adoption scope. OPDA method adoption, fictional policy questions and current operational enforcement are separate claims; this chapter establishes no legal or enforcement result.