Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dpv:Process as a superclass of dpv:PersonalDataHandling to describe any data processing #121

Closed
coolharsh55 opened this issue Oct 28, 2023 · 1 comment
Milestone

Comments

@coolharsh55
Copy link
Collaborator

coolharsh55 commented Oct 28, 2023

The intention of introducing this term was to describe a collection of triples related to a specific context regarding processing of personal data, e.g. combination of purposes, processing, personal data, legal basis. In law (EU), the term is synonymous with phrases such as processing of personal data, but because we defined Processing as a separate distinct concept - we needed another concept to reduce the ambiguity between processing as a collective concept from the operation. In retrospect, ProcessingOperation or even just Operation could have been a replacement with Processing then becoming the top concept. But here we are.

As DPV moves towards broader utilisation and expands the scope to non-personal data (while DPVCG's scope remains within the bounds of privacy / personal data) - we also need to describe a top concept that provides a combination or collection for personal as well as non-personal data. Candidates for this are:

  1. DataHandling and NonPersonalDataHandling based on the current PersonalDataHandling
  2. Process with no distinction of personal or non-personal data (as they can be derived e.g. from hasPersonalData use)
  3. Process with PersonalDataHandling and NonPersonalDataHandling as a subclass to keep backwards compatibility.
  4. (edit 2023-12-10) Process with PersonalDataProcess and NonPersonalDataProcess as a subclass. PersonalDataHandling to be deprecated in the future. Justification: handling is a unique term that only we use, whereas process is a common and widely used term.

I prefer pt#3 above for reasons:

  1. PersonalDataHandling is a non-normative term (e.g. doesn't occur in law) and is not commonly understood (e.g. doesn't occur in any dictionary).
  2. PersonalDataHandling is only scoped to PersonalData, so we need to have something for non-personal data and something neutral.
  3. In the documents I typically work with, terms such as Business Process come up which have no analogous term in DPV. PersonalDataHandling is relevant where personal data is being used, but doesn't make sense when something is to be described that doesn't have personal data.
  4. Process (and hasProcess) are well understood (legally, linguistically), and intuitive.
  5. Process may provide a better way to connect with other vocabularies, e.g. prov:Activity and odrl:Action without requiring all the other DPV concepts to be exact mappings e.g. Processing doesn't need to be mapped to prov:Activity.
  6. To keep compatibility, PersonalDataHandling rdfs:subClassOf Process is easy to provide.
  7. AFAIK, Chuck who works with the Jamaican DPA already uses Process in this way instead of PersonalDataHandling. Any existing use is a strong motivator.
@besteves4
Copy link
Collaborator

I like option 3 better too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants