Re: DPV Framework: Necessity, Consequences, and Mechanics

Hi Georg.
Thank you for the proposal. My replies are inline.

tldr; I see how the Statutory and Contractual necessity concepts are 
helpful because of GDPR Art.13-2e. For the 'defaults' - I think they are 
specific to your use-case and hence shouldn't be in DPV. We can discuss 
whether it is in scope of this group to provide such 'hints' - and if 
yes then whether to create a new extension to house them separately from 
other concepts.

I am critical of the overall proposal because it makes it difficult to 
review as there are lots of details/concepts which are hallucinated by 
GenAI. It would be helpful if proposals like this - which use Generative 
AI - are succint and to the point, and have clear information on which 
are the new concepts and which are being proposed to avoid confusion and 
help with having a clearer discussion.

 From my personal experience in using ChatGPT, it is not possible to 
limit the output of GenAI to only those concepts which are present in 
DPV. Even when using RAG and uploading a list of concepts (e.g. CSV file 
with all DPV concepts) - there is still substantial hallucination. If 
someone has a solution to this - please share it via a separate email to 
the mailing list.

On 29/09/2024 18:51, Georg Philip Krog wrote:

> 
>   Here is the proposed DPV Framework for Necessity, Consequences, and
>   Mechanics
> 
> 
>     1. Necessity Types
> 
>  1. dpv:StatutoryNecessity
>  2. dpv:ContractualNecessity
>  3. dpv:EntryIntoContractNecessity
>  4. dpv:VitalInterestNecessity
>  5. dpv:PublicInterestNecessity
>  6. dpv:OfficialAuthorityNecessity
>  7. dpv:LegitimateInterestNecessity
>  8. dpv:EmploymentLawNecessity
>  9. dpv:SocialSecurityLawNecessity
> 10. dpv:LegalClaimsNecessity
> 11. dpv:PreventiveMedicineNecessity
> 12. dpv:PublicHealthNecessity
> 13. dpv:ArchivingResearchStatisticsNecessity
> 14. dpv:SubstantialPublicInterestNecessity

 From our earlier discussion, the necessity concepts are necessary to 
model GDPR Art.13-2e "whether the provision of personal data is a 
**statutory or contractual requirement**, or a **requirement necessary 
to enter into a contract**". So I agree with `StatutoryNecessity`, 
`ContractualNecessity`, `EnterIntoContractNecessity` - but we should 
discuss whether this is better off in the GDPR extension or in the DPV 
extension. The answer depends on whether these necessity are global i.e. 
useful everywhere or are specifically tied to GDPR. I think contract and 
statutes are present everywhere - so having this in DPV makes sense.

Apart from these, I wonder whether the other necessity concepts 
mentioned here are needed as they relate directly to specific legal 
basis e.g. can the process not use legal basis = vital interest and 
necessity = necessary to say the same thing? Otherwise we will have an 
abundance of necessity concepts which would be duplicating the existing 
purpose x legal basis concepts.

I think from a pragmatic point of view what we want to distinguish is 
_where_ the necessity originates from. ContractualNecessity refers to a 
contract/agreement that is the source of necessity, StatutoryNecessity 
refers to a necessity originating in law. So Official Authority, 
Employment Law, Social Security Law, and Legal Claims are already 
covered. For Vital Interest and Public Interest - there is an exact 
corresponding legal basis, so I don't think these should be duplicated. 
For Preventive Medicine - I think it is the same as vital interest or 
public interest depending on whether it is about an individual or a 
group. Archiving Necessity sounds dubious - it must be covered by Public 
Interest or Legal Obligation as the legal basis and thus the source of 
necessity. Therefore I don't think we should model these concepts as 
necessity to avoid duplication.

> 
> 
>     2. Legal Bases
> 
>  1. dpv:Consent
>  2. dpv:Contract
>  3. dpv:LegalObligation
>  4. dpv:VitalInterest
>  5. dpv:PublicInterest
>  6. dpv:LegitimateInterest
>  7. dpv:ExplicitConsent
>  8. dpv:EmploymentSocialSecurityLaw
>  9. dpv:ProtectVitalInterests
> 10. dpv:LegitimateActivitiesOfFoundation
> 11. dpv:ManifestlyPublicInformation
> 12. dpv:LegalClaims
> 13. dpv:SubstantialPublicInterest
> 14. dpv:PreventiveOccupationalMedicine
> 15. dpv:PublicHealthInterest
> 16. dpv:ArchivingResearchStatistics

We have some of these already as legal basis, and the others are forms 
of laws and aren't legal bases e.g. EmploymentLaw, SocialSecurityLaw. 
Rather than modelling these are legal bases we can model them as 
categories of laws through which a legal obligation can be clearly 
described. Others such as legal claims and manifestly public information 
are NOT legal bases IMO. So please revise the concepts for discussion.

> 
> 
>     3. Consequences of Failure to Provide Data
> 
>  1. dpv:ServiceProvided
>  2. dpv:ServiceNotProvided
>  3. dpv:ServiceProvidedWithLimitedFunctionality
>  4. dpv:DelayedServiceProvision
>  5. dpv:AlternativeServiceOffered
>  6. dpv:ReducedServiceQuality
>  7. dpv:InabilityToFulfillLegalObligations
>  8. dpv:TerminationOfExistingService
>  9. dpv:InabilityToEnterIntoContract
> 10. dpv:PartialServiceProvision
> 11. dpv:IncreasedServiceCost
> 12. dpv:LossOfPersonalization
> 13. dpv:ExclusionFromSpecificFeatures
> 14. dpv:DelayedApplicationProcessing
> 15. dpv:InabilityToVerifyIdentity
> 16. dpv:ReductionInServiceSecurity
> 17. dpv:LimitedCustomerSupport
> 18. dpv:ExclusionFromLoyaltyPrograms
> 19. dpv:InabilityToComplyWithRegulations
> 20. dpv:LimitedAccountFunctionality
> 21. dpv:InabilityToProcessPayments
> 22. dpv:ExclusionFromCommunityFeatures
> 23. dpv:InabilityToProtectVitalInterests
> 24. dpv:InabilityToEstablishLegalClaims
> 25. dpv:LimitedLegalSupport
> 26. dpv:InabilityToProvideHealthCare
> 27. dpv:ExclusionFromResearch
> 28. dpv:LimitedDataAnalysis
> 29. dpv:ExclusionFromPublicServices

These look fine to me but they need good descriptions/definitions. Also 
we should add them to the RISK extension and not DPV.

> 
> 
>     4. Properties
> 
>  1. dpv:hasNecessityType

Why is this needed? We have dpv:hasNecessity which can be used to 
describe a necessity instance. The 'type' of Necessity can be described 
using rdf:type or skos:broader as appropriate.

>  2. dpv:hasLegalBasis
>  3. dpv:hasConsequence

Both these are already present.

> 
> 
>     5. Automatic Mechanics


We don't have 'defaults' in DPV - I think you are asking that these be 
provided as 'suggestions' or 'hardcoded' behavious. However, these are 
arbitrary and we should not add these to DPV e.g. not all consequences 
of failing to fulfil a statutory necessity can lead to specified 
consequences. In Signatu's use-case, these may be suggestions to provide 
as 'default' options e.g. when filling a form.

Whether to provide these as 'suggestions' in DPV depends on 1) the 
source of such suggestions e.g. in RISK extensions the suggestions for 
which concepts can take on which roles have a basis in established 
literature - whereas these 'patterns' do not have a source; and 2) the 
implied behaviour or interpretation must be clear i.e. it must be 
explicitly stated that these are 'possible first choices' and not the 
default interpretations.

As such we should discuss whether 1) we should model this; and if yes 
then 2) where to put these as they should not be in DPV itself to avoid 
misleading interpretations.

> 
> # If dpv:hasNecessityType is dpv:StatutoryNecessity:
> 
>   * Default dpv:hasConsequence to
>     dpv:InabilityToFulfillLegalObligations,
>     dpv:InabilityToComplyWithRegulations
>   * If dpv:hasLegalBasis is dpv:LegalObligation, also add
>     dpv:ServiceNotProvided

> 
> # If dpv:hasNecessityType is dpv:ContractualNecessity:
> 
>   * Default dpv:hasConsequence to dpv:ServiceNotProvided,
>     dpv:TerminationOfExistingService
>   * If dpv:hasPersonalDataCategory includes dpv:FinancialData, also add
>     dpv:InabilityToProcessPayments
> 
> # If dpv:hasNecessityType is dpv:EntryIntoContractNecessity:
> 
>   * Default dpv:hasConsequence to dpv:InabilityToEnterIntoContract,
>     dpv:ServiceNotProvided
> 
> # If dpv:hasNecessityType is dpv:VitalInterestNecessity:
> 
>   * Default dpv:hasConsequence to dpv:InabilityToProtectVitalInterests,
>     dpv:ServiceNotProvided
> 
> # If dpv:hasNecessityType is dpv:PublicInterestNecessity or 
> dpv:OfficialAuthorityNecessity:
> 
>   * Default dpv:hasConsequence to dpv:LimitedServiceProvision,
>     dpv:ExclusionFromSpecificFeatures
> 
> # If dpv:hasNecessityType is dpv:LegitimateInterestNecessity:
> 
>   * Default dpv:hasConsequence to
>     dpv:ServiceProvidedWithLimitedFunctionality, dpv:LossOfPersonalization
> 
> # If dpv:hasNecessityType is dpv:EmploymentLawNecessity or 
> dpv:SocialSecurityLawNecessity:
> 
>   * Default dpv:hasConsequence to dpv:DelayedApplicationProcessing,
>     dpv:InabilityToFulfillLegalObligations
> 
> # If dpv:hasNecessityType is dpv:LegalClaimsNecessity:
> 
>   * Default dpv:hasConsequence to dpv:InabilityToEstablishLegalClaims,
>     dpv:LimitedLegalSupport
> 
> # If dpv:hasNecessityType is dpv:PreventiveMedicineNecessity or 
> dpv:PublicHealthNecessity:
> 
>   * Default dpv:hasConsequence to dpv:LimitedServiceProvision,
>     dpv:InabilityToProvideHealthCare
> 
> # If dpv:hasNecessityType is dpv:ArchivingResearchStatisticsNecessity:
> 
>   * Default dpv:hasConsequence to dpv:ExclusionFromResearch,
>     dpv:LimitedDataAnalysis
> 
> # If dpv:hasNecessityType is dpv:SubstantialPublicInterestNecessity:
> 
>   * Default dpv:hasConsequence to dpv:LimitedServiceProvision,
>     dpv:ExclusionFromPublicServices
> 
> # If dpv:hasLegalBasis is dpv:Consent or dpv:ExplicitConsent:
> 
>   * Allow all consequence types
>   * Default to dpv:ServiceProvidedWithLimitedFunctionality,
>     dpv:LossOfPersonalization
> 
> # For all necessity types:
> 
>   * If dpv:hasPersonalDataCategory includes dpv:IdentificationData, add
>     dpv:InabilityToVerifyIdentity
>   * If processing involves online services, add
>     dpv:LimitedAccountFunctionality, dpv:ExclusionFromCommunityFeatures
> 
> # Industry-specific rules: a. For financial services:
> 
>   * Add dpv:IncreasedServiceCost, dpv:ExclusionFromLoyaltyPrograms b.
>     For e-commerce:
>   * Add dpv:LossOfPersonalization, dpv:ExclusionFromLoyaltyPrograms c.
>     For social media platforms:
>   * Add dpv:ExclusionFromCommunityFeatures, dpv:LimitedAccountFunctionality
> 
> # Data sensitivity rules:
> 
>   * If dpv:hasPersonalDataCategory includes any special category data
>     (e.g., dpv:HealthData, dpv:BiometricData):
>       o Add dpv:IncreasedServiceCost, dpv:ReductionInServiceSecurity
> 
> # Default fallback:
> 
>   * If no specific rules apply, default to
>     dpv:ServiceProvidedWithLimitedFunctionality, dpv:PartialServiceProvision
> 
> 6. Usage Guidelines
> 
>  1. Each Processing Activity should be associated with at least one
>     Necessity Type and one Legal Basis.

This is an implementation detail and not a universal rule. Hence it 
should not be in DPV. This can be modelled using SHACL 
https://www.w3.org/TR/shacl/ for the use-case in a separate external 
extension.

>  2. Multiple Consequences can be associated with a single Processing
>     Activity.

This is already possible as we do not declare cardinality for properties.

>  3. The Automatic Mechanics provide intelligent defaults but should not
>     be considered exhaustive or inflexible.

Also an implementation detail - see earlier comment.

>  4. Human oversight is crucial for ensuring the appropriateness of the
>     assigned Consequences.

Unclear comment - seems like typical GenAI output.

> 
> 
>     7. Example Usage (in Turtle format)
> 
> turtle
> Copy
> |@prefix dpv: <http://w3id.org/dpv# <http://w3id.org/dpv#>> . @prefix 
> ex: <http://example.com/ <http://example.com/>> . 
> ex:MarketingDataProcessing a dpv:ProcessingActivity ; 
> dpv:hasPersonalDataCategory dpv:ContactData, dpv:BehavioralData ; 
> dpv:hasNecessityType dpv:LegitimateInterestNecessity ; dpv:hasLegalBasis 
> dpv:LegitimateInterest ; dpv:hasConsequence 
> dpv:ServiceProvidedWithLimitedFunctionality, dpv:LossOfPersonalization, 
> dpv:ExclusionFromLoyaltyPrograms .|
> 
> This example demonstrates how a marketing-related data processing 
> activity might be described using this framework, including multiple 
> data categories, a specific necessity type, legal basis, and several 
> potential consequences of failure to provide data.

This example actually shows how GenAI produces arbitrary nonsense that 
'looks correct' - over half the concepts in the example are NOT in DPV.

> 
> 
>     Key Automation Features
> 
>  1. Necessity Type Inference:
>       * Automatically suggest the most appropriate necessity type based
>         on the purpose of processing and intended legal basis.

Implementation detail - see earlier comments.

>  2. Consequence Prediction:
>       * Apply the automatic mechanics to predict likely consequences of
>         failure to provide data.
Same as above.

>       * Consider industry-specific rules and data sensitivity in
>         predictions.

No idea what this means.

> 
> 
>     Implementation Example
> 
> python
> |class DPVProcessor: def __init__(self): self.necessity_types = 
> load_necessity_types() self.legal_bases = load_legal_bases() 
> self.consequences = load_consequences() self.automatic_mechanics = 
> load_automatic_mechanics() def process_activity(self, activity_data): 
> necessity_type = self.infer_necessity_type(activity_data) legal_basis = 
> activity_data['legal_basis'] consequences = 
> self.predict_consequences(necessity_type, legal_basis, activity_data) 
> return { 'necessity_type': necessity_type, 'legal_basis': legal_basis, 
> 'consequences': consequences, 'ropa_entry': 
> self.generate_ropa_entry(activity_data, necessity_type, consequences), 
> 'privacy_notice_section': self.generate_privacy_notice(activity_data, 
> consequences), 'risk_score': self.calculate_risk_score(necessity_type, 
> consequences) } def infer_necessity_type(self, activity_data): # Logic 
> to infer necessity type based on purpose and legal basis pass def 
> predict_consequences(self, necessity_type, legal_basis, activity_data): 
> # Apply automatic mechanics rules to predict consequences pass def 
> generate_ropa_entry(self, activity_data, necessity_type, consequences): 
> # Generate RoPA entry in required format pass def 
> generate_privacy_notice(self, activity_data, consequences): # Generate 
> relevant section for privacy notice pass def calculate_risk_score(self, 
> necessity_type, consequences): # Calculate initial risk score for the 
> processing activity pass # Usage processor = DPVProcessor() result = 
> processor.process_activity({ 'purpose': 'Marketing', 'legal_basis': 
> 'LegitimateInterest', 'data_categories': ['ContactData', 
> 'BehavioralData'], 'industry': 'E-commerce' })|

I have no idea what this is doing. Seems some output tied to the use-case.

Regards,
-- 
---
Harshvardhan J. Pandit, Ph.D
Assistant Professor
ADAPT Centre, Dublin City University
https://harshp.com/

Received on Sunday, 29 September 2024 20:15:00 UTC