Data Privacy Vocabulary (DPV)

DPV is built on W3C Semantic Web standards (RDF, OWL), providing a rigorous ontological structure rather than a flat list of terms. This allows machines to infer logical relationships between concepts.

• RDF Triples: All statements are structured as subject-predicate-object, enabling graph-based querying.
• OWL Axioms: Formal constraints define class hierarchies, property domains, and cardinality restrictions.
• Inference: A system can deduce that if data is 'Anonymized', it is no longer 'PersonalData' without explicit programming.

DPV organizes privacy concepts into a strict, extensible class hierarchy rooted in Purpose, Processing, PersonalData, LegalBasis, and TechnicalOrganisationalMeasure.

• Purpose: Defines why data is processed (e.g., dpv:Marketing, dpv:ServiceProvision).
• PersonalData: Categorizes what data is involved (e.g., dpv:SpecialCategoryPersonalData, dpv:Financial).
• LegalBasis: Specifies the legal justification (e.g., dpv:Consent, dpv:LegitimateInterest).
• Processing: Describes how data is handled (e.g., dpv:Collect, dpv:Store, dpv:AutomatedDecisionMaking).

DPV is designed as a modular base ontology that can be extended with domain-specific profiles without breaking core interoperability. This prevents vendor lock-in while allowing for regulatory specificity.

• DPV-GDPR: Extends DPV with specific EU GDPR concepts like dpv-gdpr:RightToErasure and dpv-gdpr:DPIA.
• DPV-PD: A detailed taxonomy of personal data categories (e.g., dpv-pd:Biometric, dpv-pd:EthnicOrigin).
• DPV-LEGAL: Jurisdiction-specific legal statuses and compliance records.
• Custom Extensions: Organizations can create proprietary subclasses while remaining compatible with the core DPV standard.

DPV enables the creation of serialized privacy policies in formats like JSON-LD and Turtle that software agents can parse, compare, and validate automatically.

• Consent Receipts: A DPV-based record proving a specific user granted consent for a specific purpose at a specific time.
• Policy Matching: An agent can compare a user's expressed privacy preferences against a service's DPV-encoded policy to detect conflicts.
• Automated Compliance: A processor can check if a requested processing operation is permitted under the controller's declared DPV purposes.

DPV includes constructs for modeling the context and risk of processing activities, moving beyond simple binary permissions to nuanced impact assessments.

• Context: Defines the processing environment, including dpv:StorageLocation, dpv:Recipient, and dpv:Scale.
• Risk: Links processing to potential dpv:Consequence and dpv:Impact (e.g., dpv:Discrimination, dpv:FinancialLoss).
• Mitigation: Associates dpv:TechnicalOrganisationalMeasure (like dpv:Encryption or dpv:Pseudonymisation) to specific risks.
• This structure directly supports automated generation of Data Protection Impact Assessments (DPIAs).

DPV is designed to map to and align with other major privacy and data governance frameworks, acting as a semantic bridge between regulatory silos.

• ISO/IEC 29184: Maps to ISO's privacy notice requirements.
• GDPR & CCPA: Provides explicit legal basis and right taxonomies for these regulations.
• W3C Data Privacy Controls: Aligns with the W3C's technical privacy architecture for the web platform.
• Solid Protocol: Used within Tim Berners-Lee's decentralized web project to manage data access permissions in personal online datastores (Pods).