Rules

concepts in Data Privacy Vocabulary (DPV)

Final Community Group Report

This version:
https://www.w3.org/community/reports/dpvcg/CG-FINAL-dpv-20250316/
Latest published version:
https://w3id.org/dpv/dpv/modules/rules
Latest editor's draft:
https://dev.dpvcg.org/dpv/modules/rules
Editor:
Harshvardhan J. Pandit (ADAPT Centre, Dublin City University)
Feedback:
GitHub w3c/dpv (pull requests, new issue, open issues)
This Release
https://w3id.org/dpv/2.1/modules/rules
Previous Release
https://w3id.org/dpv/2.0/modules/rules
Changelog
Changelog for v2.1
Key Publications
Data Privacy Vocabulary (DPV) -- Version 2.0 (2024)
Creating a Vocabulary for Data Privacy (2019)

Contributors: (ordered alphabetically) Arthit Suriyawongkul (ADAPT Centre, Trinity College Dublin), Axel Polleres (Vienna University of Economics and Business), Beatriz Esteves (IDLab, IMEC, Ghent University), Bud Bruegger (Unabhängige Landeszentrum für Datenschutz Schleswig-Holstein), Damien Desfontaines (No affiliation provided), David Hickey (Dublin City University), Delaram Golpayegani (ADAPT Centre, Trinity College Dublin), Elmar Kiesling (Vienna University of Technology), Fajar Ekaputra (Vienna University of Technology), Georg P. Krog (Signatu AS), Harshvardhan J. Pandit (ADAPT Centre, Dublin City University), Iain Henderson (JLINC Labs), Javier Fernández (Vienna University of Economics and Business), Julian Flake (University of Koblenz), Mark Lizar (OpenConsent/Kantara Initiative), Maya Borges (Danish Agency for Digitisation), Paul Ryan (Uniphar PLC), Piero Bonatti (Università di Napoli Federico II), Rana Saniei (Universidad Politécnica de Madrid), Rob Brennan (University College Dublin), Rudy Jacob (Proximus), Simon Steyskal (Siemens), Steve Hickman (Epistimis LLC). NOTE: The affiliations are informative, do not represent formal endorsements, and may be outdated as this list is generated automatically from existing data.

Abstract

This document provides additional details and examples for rules concepts for permission, prohibition, and obligation used in the Data Privacy Vocabulary [DPV], and is a companion to the [DPV] specification.

DPV Specifications: The [DPV] is the core specification within the DPV family, with the following extensions: Personal Data [PD], Locations [LOC], Risk Management [RISK], Technology [TECH] and [AI], [JUSTIFICATIONS], [SECTOR] specific extensions, and [LEGAL] extensions modelling specific jurisdictions and regulations. A [PRIMER] introduces the concepts and modelling of DPV specifications, and [GUIDES] describe application of DPV for specific applications and use-cases. The Search Index page provides a searchable hierarchy of all concepts. The Data Privacy Vocabularies and Controls Community Group (DPVCG) develops and manages these specifications through GitHub. For meetings, see the DPVCG calendar.

To cite and understand the structure of DPV, the article "Data Privacy Vocabulary (DPV) - Version 2.0" (2024) describes the current state of DPV and extensions from version 2.0 onwards (open access version here). The earlier article "Creating A Vocabulary for Data Privacy" (2019) describes how the DPV was developed (open access versions here, here, and here).

Contributing: The DPVCG welcomes participation to improve the DPV and associated resources, including expansion or refinement of concepts, requesting information and applications, and addressing open issues. See contributing guide for further information.

Status of This Document

This specification was published by the Data Privacy Vocabularies and Controls Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Final Specification Agreement (FSA) other conditions apply. Learn more about W3C Community and Business Groups.

GitHub Issues are preferred for discussion of this specification.

1. Introduction

Figure 1

DPV provides the concept Rule to specify requirements, constraints, and other forms of 'rules' that are associated with specific contexts (e.g., processing activities) using the relation hasRule. DPV provides three forms of Rules to represent Permission, Prohibition and Obligation, and their corresponding relations hasPermission, hasProhibition and hasObligation, to indicate a Rule that specifies whether something is permitted, prohibited or an obligation, respectively.

Permission refers to the indicated context being allowed or approved to be carried out. Permissions are only a 'permissive signal' i.e. it is not necessary to carry out an activity just because it is permitted (see obligation for this). Permissions can be used to record what has been permitted or to distinguish the 'permissive' parts from other 'non-permissive' or prohibitive parts, such as in use-cases for policies, agreements, consent records, and risk assessments.

Prohibition represents the indicated context is not allowed or it is not approved to be carried out. If something is expressed as a prohibition - it explicitly indicates that it must not occur. Unlike permission, prohibition is a 'strong' rule i.e. if something is prohibited, then it is necessary that it not be carried out.

Obligation is the antipodal rule for prohibitions, which means if something is an obligation then it is necessary for it to be carried. It differs from permissions - which are a 'soft' rule i.e. a permitted activity is not necessary to be carried out.

DPV does not define additional semantics for rules and limits its scope and focus to provide a simple way to specify permissions, prohibitions, and obligations as common rules associated with activities. For a more extensive and richer set of semantics and concepts to represent rules, DPVCG suggests looking towards other languages, such as [ODRL], [SHACL], and [RuleML] that have been developed with the specific goal of representing and applying rules. We welcome contributions for aligning DPV with these, and for providing guidance on how to complement DPV's rule-based concepts with external languages.

2. Rule Fulfilment Status

The DPVCG is exploring representing the state of rule fulfilment through concepts, for example to represent a prohibition has been violated, or an obligation has been fulfilled, or a permission has been utilised. The currently provided concepts for these, represented by the concept RuleFulfilmentStatus and its taxonomy, which are associated using the relation dpv:hasStatus, indicate the intent and scope of this work.

The DPVCG is working with ongoing efforts regarding similar modelling of concepts for ODRL implementations, in particular to ensure the concepts in DPV are in sync and compatible with those developed for ODRL. The below issue shows the progress for this.

Issue 189: [Concept]: Rules fulfilment and applicability statuses WIPdpv

In meeting SEP-10 the group agreed to include statuses for RuleFulfilmentStatus fulfilment and applicability. These are aimed to provide an overview of whether the rule applies (e.g. permission utilised) and whether it has been successful (e.g. obligation fulfilled). We aim to align this work with external efforts related to ODRL rules for Solid. Proposed future work involves describing rules in relation to:

3. Interpreting Rules

3.1 Default Interpretation

Though DPV provides concepts representing deontic logic, it does not specify what should be the 'default' interpretation in relation to rules, i.e. it does not provide an interpretation of whether some rules apply automatically unless otherwise declared. For example, in declaring an instance of Process, the assumption is that the activities are modelled for what is happening or what is intended/planned to happen. The explicit annotation using a Permission rule adds information about whether some activity is permitted (and its associated information). Instead, if the use-case is using DPV to only document activities that are permitted, there is no need to explicitly specify the permissions. Similarly, just because something is happening or planned to happen, it cannot be assumed to be permitted (e.g. pending evaluation of legal requirements).

This lack of default interpretation enables modularity in the use of DPV concepts. For example, an instance of dpv:Process which does not have a dpv:hasRule declared within it, can be made part of a rule to specify permissions, prohibitions, or obligations regarding the process. If instead the process had a default interpretation (e.g. permission), then it would require creating a separate instance with the same information - leading to duplicated efforts. While an apparent solution is to create a mechanism whereby the rule in the process is overridden with the intended 'outer' rule or context e.g. to specify the prohibition in one process overrules permission in another process, this prevents the combination of rules to describe situations such as a permission for a larger context within which specific parts are prohibited or obligated.

3.2 Mixing/Nesting Rules

In representing Rules, DPV only provides the concept and does not express any inherent semantics on what those rules mean in relation to each other. For example, DPV does not express Permission to be non-compatible or disjoint from Prohibition. This is to separate the interpretation and application of rules based on the necessities of a use-case. For example, in a legal investigation it may be prudent to specify permission and prohibition can never occur together, but this may not be true if there are different legal requirements that allow a prohibition to be resolved or deferred, such as through another permission that overrides the prohibition.

Further, as described earlier in the section on default interpretations, it is possible to mix or nest rules such as through processes. For example, if ProcessA is a permitted process and contains ProcessB which is a prohibited process, DPV does not dictate what should be default interpretation for this arrangement. The role of DPV concepts regarding rules, as of now, is to provide a simplified indication of whether something is permitted, prohibited, or obligated. Further interpretations require creation of a formal specification that dictates how rules should function together. For example, depending on the use-case, several interpretations are possible for the example described here:

  1. Prohibitive interpretation: Both ProcessA and ProcessB are prohibited because through ProcessA is permitted, ProcessB is within it and is prohibited - thereby prohibiting both processes. Such interpretations prevent modularity - everything is prohibited because something is prohibited, or it is permitted because there are no prohibitions.
  2. Permissive interpretation: ProcessA and ProcessB are both permitted since ProcessA gives permission for the entire process and overrides the prohibition in ProcessB. Such interpretations also prevent modularity - everything is permitted because the higher/broader processes are permitted even though there are specific prohibitions at a granular level.
  3. Contextually Prohibitive interpretation: ProcessB is prohibited as declared, and the rest of ProcessA without ProcessB is permitted. If there was a further ProcessC that is permitted, and is present within ProcessB, then ProcessC would still be prohibited as the broader prohibition from ProcessB overrides it. Such interpretations permit modularity with permission granted for parts as long as there is no prohibition overriding it from a broader context. In this, a prohibition within a permission still allows the permitted parts to be carried out, whereas a permission within a prohibition would still be prohibited.
  4. Contextually Permissive interpretation: This is the same as the contextually prohibitive interpretation, except permissions occurring within prohibitions are not overridden. This means, ProcessA is allowed through its permission, with ProcessB within it being prohibited, except for ProcessC within ProcessB - which is permitted.

The above example interpretations only concerned permissions and prohibitions, and did not include obligations - or other concepts such as duties, dispensations, exceptions, and defeasibility. From this, it should be clear how the specification and interpretation of rules can be quite complex and has a large impact on the intended activities and information being documented.

Note: DPVCG is exploring providing rule interpretation concepts in future versions

4. Triggering Rules

DPV does not define how rules are 'triggered' i.e. how to specify under what conditions a rule should become applicable or is exempted from being applied. Some common triggers for rules to be applied are provided here as examples:

  1. Ex-ante: the rule is applied before the specified activity is carried out.
  2. Ex-post: the rule is applied after the specified activity is carried out.
  3. Real-time: the rule is applied during the specified activity being carried out.
Note: DPVCG is exploring providing rule trigger concepts in future versions

5. Alignment with ODRL

[ODRL] provides a W3C standardised representation for expressing policies containing rules such as for permissions, prohibitions, obligations over 'assets' and the involved 'parties'. While ODRL focuses on providing a general structure for policies without jurisdictional concepts or modelling, it complements DPV by enabling declaration of policies, agreements, and other similar documents in a structured, interoperable, and standardised manner. The DPV concepts enable specifying the exact information within the structure provided by ODRL - which can be useful for two entities to exchange information. For example, in a controller-processor agreement, ODRL can be used to define the agreement in terms of involved parties, their roles, and which entity is responsible for performing which actions, as well as the expected ex-post consequences of those actions - such as for reporting from processor to controller, or to indicate what should be done should a particular requirement is violated.

The DPVCG is interested in formally authorising a shared specification with the ODRL Community Group that outlines the use of DPV concepts for/with ODRL. The current proposal for this is to create an ODRL profile that declares DPV concepts in context of ODRL's conceptual model and through which DPV concepts can be correctly declared and used in ODRL. The current draft guidance document for use of DPV and ODRL is available at Guide for using DPV with ODRL, and the mapping of concepts between DPV and ODRL is available at Mapping DPV concepts to ODRL.

Issue 31: Mappings from DPV to other vocabularies todohelp-wanted

This issue is intended to create a list identifying the vocabularies whose mappings should be provided by the DPVCG.

Given that DPV takes a singularly domain-specific approach to defining terms (i.e. it does not consider semantics from other vocabularies), its use alongside or with other vocabularies is undefined. For example, dpv:hasName is semantically similar to foaf:name or rdfs:label. When an use-case or adopter requires use of other vocabularies, it is desirable to have an alignment between DPV and other vocabularies so as to have a data model/graph utilising both.

The proposal is to provide such mappings in a directory e.g. /mappings/dpv-foaf containing an RDF file representing the mapping which is expressed using SKOS (i.e. exact, close, related) and a HTML document explaining the rationale and implications.

Below are vocabularies proposed for producing mappings (section below is edited to keep the list updated)

  1. RDFS (labels, comments) and SKOS (labels, notes) - note: DPV prefers use of SKOS annotations
  2. foaf - annotations for agents / entities
  3. vCard - annotations for agents / entities
  4. DCMI Metadata Terms - relations for commonly utilised information e.g. timestamps, publication provenance, identifiers
  5. ODRL - legal/deontic terms e.g. parties (entities in DPV) and rules regarding permissions - aligned with DPV's taxonomy e.g. personal data, purpose, legal basis
  6. SEMIC - EU SEMIC vocabularies such as DCAT-AP, Core, ADMS used for open data
  7. PROV - activities, aretefacts, agents/entities, and expressing plans/provenance
  8. gist - upper ontology for business processes and concepts
  9. schema.org - broad coverage of terms representing entities, processes, for communications (e.g. emails), kinds of personal data
  10. DCAT - resources, provenance of resources, representing data and catalogues
Issue 130: Alignment with ODRL scopeWIPhelp-wanted

In this issue, we will track the work being done on aligning DPV with the ODRL information model (being maintained by the ODRL CG) towards the publication of a joint report.

This issue is also being tracked in the ODRL CG repo and mappings from DPV to other vocabs are tracked here #31.

6. Vocabulary Index

6.1 Classes

6.1.1 Obligation

Term Obligation Prefix dpv
Label Obligation
IRI https://w3id.org/dpv#Obligation
Type rdfs:Class, skos:Concept, dpv:Rule
Broader/Parent types dpv:Rule
Object of relation dpv:hasFulfillmentsStatus, dpv:hasObligation, dpv:hasRule
Definition A rule describing an obligation for performing an activity
Date Created 2022-10-19
Contributors Beatriz Esteves, Georg P. Krog, Harshvardhan J. Pandit, Paul Ryan
See More: section RULES in DPV

6.1.2 Obligation Fulfilled

Term ObligationFulfilled Prefix dpv
Label Obligation Fulfilled
IRI https://w3id.org/dpv#ObligationFulfilled
Type rdfs:Class, skos:Concept, dpv:RuleFulfilmentStatus
Broader/Parent types dpv:RuleFulfilleddpv:RuleFulfilmentStatusdpv:Statusdpv:Context
Object of relation dpv:hasContext, dpv:hasStatus
Definition Status indicating an obligation has been fulfilled i.e. the activity stated as being required to be carried out has been successfully completed
Date Created 2024-09-10
Contributors Harshvardhan J. Pandit
See More: section RULES in DPV

6.1.3 Obligation Unfulfilled

Term ObligationUnfulfilled Prefix dpv
Label Obligation Unfulfilled
IRI https://w3id.org/dpv#ObligationUnfulfilled
Type rdfs:Class, skos:Concept, dpv:RuleFulfilmentStatus
Broader/Parent types dpv:RuleUnfulfilleddpv:RuleFulfilmentStatusdpv:Statusdpv:Context
Object of relation dpv:hasContext, dpv:hasStatus
Definition Status indicating an obligation has not been fulfilled i.e. the activity stated as being required to be carried out has not been carried out but this is not considered as a violation e.g. there is still time to conduct the activity
Date Created 2024-09-10
Contributors Harshvardhan J. Pandit
See More: section RULES in DPV

6.1.4 Obligation Violated

Term ObligationViolated Prefix dpv
Label Obligation Violated
IRI https://w3id.org/dpv#ObligationViolated
Type rdfs:Class, skos:Concept, dpv:RuleFulfilmentStatus
Broader/Parent types dpv:RuleViolateddpv:RuleFulfilmentStatusdpv:Statusdpv:Context
Object of relation dpv:hasContext, dpv:hasStatus
Definition Status indicating an obligation has been violated i.e. the activity stated as being required to be carried out has not been carried out and this is considered as a violation i.e. the activity can no longer be carried out to fulfil the obligation
Date Created 2024-09-10
Contributors Harshvardhan J. Pandit
See More: section RULES in DPV

6.1.5 Permission

Term Permission Prefix dpv
Label Permission
IRI https://w3id.org/dpv#Permission
Type rdfs:Class, skos:Concept, dpv:Rule
Broader/Parent types dpv:Rule
Object of relation dpv:hasFulfillmentsStatus, dpv:hasPermission, dpv:hasRule
Definition A rule describing a permission to perform an activity
Examples dex:E0028 :: Rule specifying permission
dex:E0066 :: Specifying permissions and prohibitions
Date Created 2022-10-19
Contributors Beatriz Esteves, Georg P. Krog, Harshvardhan J. Pandit, Paul Ryan
See More: section RULES in DEX

6.1.6 Permission Not Utilised

Term PermissionNotUtilised Prefix dpv
Label Permission Not Utilised
IRI https://w3id.org/dpv#PermissionNotUtilised
Type rdfs:Class, skos:Concept, dpv:RuleFulfilmentStatus
Broader/Parent types dpv:RuleFulfilleddpv:RuleFulfilmentStatusdpv:Statusdpv:Context
Object of relation dpv:hasContext, dpv:hasStatus
Definition Status indicating a permission has not been utilised i.e. the activity stated as being permitted has not been carried out
Date Created 2024-09-10
Contributors Harshvardhan J. Pandit
See More: section RULES in DPV

6.1.7 Permission Utilised

Term PermissionUtilised Prefix dpv
Label Permission Utilised
IRI https://w3id.org/dpv#PermissionUtilised
Type rdfs:Class, skos:Concept, dpv:RuleFulfilmentStatus
Broader/Parent types dpv:RuleFulfilleddpv:RuleFulfilmentStatusdpv:Statusdpv:Context
Object of relation dpv:hasContext, dpv:hasStatus
Definition Status indicating a permission has been utilised i.e. the activity stated as being permitted has been carried out
Date Created 2024-09-10
Contributors Harshvardhan J. Pandit
See More: section RULES in DPV

6.1.8 Prohibition

Term Prohibition Prefix dpv
Label Prohibition
IRI https://w3id.org/dpv#Prohibition
Type rdfs:Class, skos:Concept, dpv:Rule
Broader/Parent types dpv:Rule
Object of relation dpv:hasFulfillmentsStatus, dpv:hasProhibition, dpv:hasRule
Definition A rule describing a prohibition to perform an activity
Examples dex:E0029 :: Rule specifying prohibition
dex:E0066 :: Specifying permissions and prohibitions
Date Created 2022-10-19
Contributors Beatriz Esteves, Georg P. Krog, Harshvardhan J. Pandit, Paul Ryan
See More: section RULES in DEX

6.1.9 Prohibition Fulfilled

Term ProhibitionFulfilled Prefix dpv
Label Prohibition Fulfilled
IRI https://w3id.org/dpv#ProhibitionFulfilled
Type rdfs:Class, skos:Concept, dpv:RuleFulfilmentStatus
Broader/Parent types dpv:RuleFulfilleddpv:RuleFulfilmentStatusdpv:Statusdpv:Context
Object of relation dpv:hasContext, dpv:hasStatus
Definition Status indicating a prohibition has been fulfilled i.e. the activity stated as being prohibited has not been carried out
Date Created 2024-09-10
Contributors Harshvardhan J. Pandit
See More: section RULES in DPV

6.1.10 Prohibition Violated

Term ProhibitionViolated Prefix dpv
Label Prohibition Violated
IRI https://w3id.org/dpv#ProhibitionViolated
Type rdfs:Class, skos:Concept, dpv:RuleFulfilmentStatus
Broader/Parent types dpv:RuleViolateddpv:RuleFulfilmentStatusdpv:Statusdpv:Context
Object of relation dpv:hasContext, dpv:hasStatus
Definition Status indicating a prohibition has been violated i.e. the activity stated as being prohibited has been carried out
Date Created 2024-09-10
Contributors Harshvardhan J. Pandit
See More: section RULES in DPV

6.1.11 Rule

Term Rule Prefix dpv
Label Rule
IRI https://w3id.org/dpv#Rule
Type rdfs:Class, skos:Concept
Object of relation dpv:hasFulfillmentsStatus, dpv:hasRule
Definition A rule describing a process or control that directs or determines if and how an activity should be conducted
Examples dex:E0030 :: Rule combining DPV with ODRL
Date Created 2022-10-19
Contributors Beatriz Esteves, Georg P. Krog, Harshvardhan J. Pandit, Paul Ryan
See More: section RULES in DEX

6.1.12 Rule Fulfilled

Term RuleFulfilled Prefix dpv
Label Rule Fulfilled
IRI https://w3id.org/dpv#RuleFulfilled
Type rdfs:Class, skos:Concept, dpv:RuleFulfilmentStatus
Broader/Parent types dpv:RuleFulfilmentStatusdpv:Statusdpv:Context
Object of relation dpv:hasContext, dpv:hasStatus
Definition Status indicating a rule has been fulfilled, completed, or satisfied
Date Created 2024-09-10
Contributors Harshvardhan J. Pandit
See More: section RULES in DPV

6.1.13 Rule Fulfilment Status

Term RuleFulfilmentStatus Prefix dpv
Label Rule Fulfilment Status
IRI https://w3id.org/dpv#RuleFulfilmentStatus
Type rdfs:Class, skos:Concept
Broader/Parent types dpv:Statusdpv:Context
Object of relation dpv:hasContext, dpv:hasStatus
Definition Status associated with a rule for indicating whether it is applicable, or has been utilised, and whether the requirements of the rule have been fulfilled or violated
Examples dex:E0084 :: Stating status of Rule fulfilment
Date Created 2024-09-10
Contributors Harshvardhan J. Pandit
See More: section RULES in DEX

6.1.14 Rule Unfulfilled

Term RuleUnfulfilled Prefix dpv
Label Rule Unfulfilled
IRI https://w3id.org/dpv#RuleUnfulfilled
Type rdfs:Class, skos:Concept, dpv:RuleFulfilmentStatus
Broader/Parent types dpv:RuleFulfilmentStatusdpv:Statusdpv:Context
Object of relation dpv:hasContext, dpv:hasStatus
Definition Status indicating a rule has not been fulfilled nor violated
Date Created 2024-09-10
Contributors Harshvardhan J. Pandit
See More: section RULES in DPV

6.1.15 Rule Violated

Term RuleViolated Prefix dpv
Label Rule Violated
IRI https://w3id.org/dpv#RuleViolated
Type rdfs:Class, skos:Concept, dpv:RuleFulfilmentStatus
Broader/Parent types dpv:RuleFulfilmentStatusdpv:Statusdpv:Context
Object of relation dpv:hasContext, dpv:hasStatus
Definition Status indicating a rule has been violated, breached, broken, or infracted
Date Created 2024-09-10
Contributors Harshvardhan J. Pandit
See More: section RULES in DPV

6.2 Properties

6.2.1 has fulfillment status

Term hasFulfillmentsStatus Prefix dpv
Label has fulfillment status
IRI https://w3id.org/dpv#hasFulfillmentsStatus
Type rdf:Property, skos:Concept
Broader/Parent types dpv:hasStatus
Sub-property of dpv:hasStatus
Domain includes dpv:Context
Range includes dpv:Rule
Definition Specifying the fulfillment status associated with a rule
Date Created 2024-09-10
Contributors Harshvardhan J. Pandit
See More: section RULES in DPV

6.2.2 has obligation

Term hasObligation Prefix dpv
Label has obligation
IRI https://w3id.org/dpv#hasObligation
Type rdf:Property, skos:Concept
Broader/Parent types dpv:hasRule
Sub-property of dpv:hasRule
Domain includes dpv:Context
Range includes dpv:Obligation
Definition Specifying applicability or inclusion of an obligation rule within specified context
Date Created 2022-10-19
Contributors Beatriz Esteves, Georg P. Krog, Harshvardhan J. Pandit, Paul Ryan
See More: section RULES in DPV

6.2.3 has permission

Term hasPermission Prefix dpv
Label has permission
IRI https://w3id.org/dpv#hasPermission
Type rdf:Property, skos:Concept
Broader/Parent types dpv:hasRule
Sub-property of dpv:hasRule
Domain includes dpv:Context
Range includes dpv:Permission
Definition Specifying applicability or inclusion of a permission rule within specified context
Examples dex:E0066 :: Specifying permissions and prohibitions
Date Created 2022-10-19
Contributors Beatriz Esteves, Georg P. Krog, Harshvardhan J. Pandit, Paul Ryan
See More: section RULES in DEX

6.2.4 has prohibition

Term hasProhibition Prefix dpv
Label has prohibition
IRI https://w3id.org/dpv#hasProhibition
Type rdf:Property, skos:Concept
Broader/Parent types dpv:hasRule
Sub-property of dpv:hasRule
Domain includes dpv:Context
Range includes dpv:Prohibition
Definition Specifying applicability or inclusion of a prohibition rule within specified context
Examples dex:E0066 :: Specifying permissions and prohibitions
Date Created 2022-10-19
Contributors Beatriz Esteves, Georg P. Krog, Harshvardhan J. Pandit, Paul Ryan
See More: section RULES in DEX

6.2.5 has rule

Term hasRule Prefix dpv
Label has rule
IRI https://w3id.org/dpv#hasRule
Type rdf:Property, skos:Concept
Domain includes dpv:Context
Range includes dpv:Rule
Definition Specifying applicability or inclusion of a rule within specified context
Date Created 2022-10-19
Contributors Beatriz Esteves, Georg P. Krog, Harshvardhan J. Pandit, Paul Ryan
See More: section RULES in DPV

6.3 External

DPV uses the following terms from [RDF] and [RDFS] with their defined meanings:

The following external concepts are re-used within DPV:

Funding Acknowledgements

Funding Sponsors

The DPVCG was established as part of the SPECIAL H2020 Project, which received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No. 731601 from 2017 to 2019.

Harshvardhan J. Pandit was funded to work on DPV from 2020 to 2022 by the Irish Research Council's Government of Ireland Postdoctoral Fellowship Grant#GOIPD/2020/790.

The ADAPT SFI Centre for Digital Media Technology is funded by Science Foundation Ireland through the SFI Research Centres Programme and is co-funded under the European Regional Development Fund (ERDF) through Grant#13/RC/2106 (2018 to 2020) and Grant#13/RC/2106_P2 (2021 onwards).

Funding Acknowledgements for Contributors

The contributions of Harshvardhan J. Pandit have been made with the financial support of Science Foundation Ireland under Grant Agreement No. 13/RC/2106_P2 at the ADAPT SFI Research Centre.

A. References

A.1 Informative references

[AI]
AI Technology concepts for DPV. URL: https://w3id.org/dpv/ai
[DPV]
Data Privacy Vocabulary (DPV) Specification. URL: https://w3id.org/dpv
[GUIDE-ODRL]
Guide for using DPV with ODRL. URL: https://w3id.org/dpv/guides/dpv-odrl
[GUIDES]
Guides for DPV. URL: https://w3id.org/dpv/guides
[JUSTIFICATIONS]
Concepts representing Justifications for DPV. URL: https://w3id.org/dpv/justifications
Legal Jurisdiction-relevant concepts for DPV. URL: https://w3id.org/dpv/legal
[LOC]
Location and Geo-Political Membership concepts for DPV. URL: https://w3id.org/dpv/loc
[MAPPING-ODRL]
Mapping DPV concepts to ODRL. URL: https://w3id.org/dpv/mapping/odrl
[ODRL]
Open Digital Rights Language (ODRL) Model. URL: https://www.w3.org/TR/odrl-model/
[PD]
Personal Data categories for DPV. URL: https://w3id.org/dpv/pd
[PRIMER]
Primer for Data Privacy Vocabulary. URL: https://w3id.org/dpv/primer
[RDF]
RDF 1.1 Concepts and Abstract Syntax. URL: https://www.w3.org/TR/rdf11-concepts/
[RDFS]
RDF Schema 1.1. URL: https://www.w3.org/TR/rdf-schema/
[RISK]
Risk Assessment and Management concepts for DPV. URL: https://w3id.org/dpv/risk
[RuleML]
RuleML: Rule Markup Language. URL: https://en.wikipedia.org/wiki/RuleML
[SECTOR]
Sector-specific Extensions for DPV. URL: https://w3id.org/dpv/sector
[SHACL]
Shape and Constraint Language (SHACL). URL: https://www.w3.org/TR/shacl
[TECH]
Technology concepts for DPV. URL: https://w3id.org/dpv/tech