w3c / dpv Goto Github PK

| Migrated ISSUE-19: Do we need a generic mechanism to describe conditions, constraints and restrcitions to a specific processing or data category or can we re-use odrl's mechanism?

State: RAISED
Opened on: 2019-05-07

The DPV-LEGAL extension contains properties associated with ISO country labels which are not present in the HTML documentation. The use of these properties, e.g. to indicate ISO label for a specific country, is also not present in the tables for that concept. Both of these should be added in. This needs to be done within the template, e.g. https://github.com/w3c/dpv/blob/master/documentation-generator/jinja2_resources/template_dpv_legal.jinja2

| Migrated ISSUE-41: Remove language as sub-class of ethnicity

State: RAISED
Raised by: Harshvardhan J. Pandit
Opened on: 2021-02-03
Description: See https://lists.w3.org/Archives/Public/public-dpvcg/2019Dec/0012.html
Suggestion: declare language a subclass of external at the same level as ethnicity

Currently the DPV release mechanism is based on GitHub taking the entire repo and putting it in a zip file. Anyone downloading this will find the entire catalogue of DPV related resources, including different 'flavours' and the documentation generator also bundled into it. Instead, only the relevant files should be provided as clearly separated as is feasible. For example, each release could provide separate zips for:

1. DPV + Extensions (SKOS semantics)
2. DPV + Extensions (CSV)
3. DPV + Extensions (OWL2)
4. DPV + Extensions (RDFS+SKOS)
5. Everything (all of above)

| Migrated ISSUE-33: The categorisation of Pseudoanonymisation and Encryption is not (semantically) correct

State: RAISED
Raised by: Harshvardhan J. Pandit
Opened on: 2019-11-26
Description: (from presentation to Kantara CISWG) Anonymisation is a subclass of Pseudoanonymisation which is conflicting in semantics as it specifies anonymisation is a type of pseudoanonymisation, which might not be intended. Also, Pseudoanonymisation and Encryption should not be grouping together (as a concept).
Reporter: Harsh
Notes: suggested to start a discussion on this issue.

This issue is a placeholder, and collective single representation of the feedback, discussions, and actions related to DPV v0.8.1 and its role as a release candidate for DPV 1.0.

(pinned edit) As per the last meeting on 19 OCT, the release date is set to (approx.) 15 NOV. The below are the list of tasks/issues to be addressed by then:

• DPV-Legal - remove duplicate concepts, move to EU vocabs, add pending concepts ;
  • #61 - not fixed in v1
  • #48 - not fixed in v1
  • #46 - note added to this effect
• OWL - correctness of syntax ;
  • #59
  • #42
• Concepts
  • Technical Measures #23
  • Purpose #22
  • Consent #21
  • Rules #18
  • Data Collection Method #16
  • Personal Data and PII #14
  • Sensitivity of Data #11 - not fixed in v1
  • Data Subject category #5
• Minor fixes
  • #58
  • #15 Anonymisation methods
  • #72
  • #70
• Release prep/docs
  • #40
  • #39
  • #38
  • #24 - not completed in v1
  • #12
  • #65
  • #66 - can be done after v1 publication
  • #67 - can be done after v1 publication
  • #68 - can be done after v1 publication
  • #71 - to detect errors in concepts
• Notes on Future Work
  • #4 Rights Exercise - will be integrated in v1
  • #64 Data Breach - not fixed in v1

Hi,

in many properties this is mentioned but not defined/nor resolveable.

kr,

Bert

| Migrated ISSUE-10: Are there mappings to gics from other coding systems naics/nace/isic

State: RAISED
Opened on: 2019-02-12

Related Emails:

1. +[minutes] 2019-10-15 dpvcg (from [email protected] on 2019-10-15)
2. +ISSUE-10: Are there mappings to gics from other coding systems naics/nace/isic ... (from [email protected] on 2019-02-12)

Related Notes:

1. [axelpolleres]: related to ACTION-87 and ACTION-91 - 5 Apr 2019, 13:26:36
2. RESOLVED: to close ACTION-87 and also postpone ISSUE-10 with the following rationale: at the moment the spec only defines a schemafor business sector codes in NACE, we leave the definition of (mappings to) other business sector code standards such as eg. GICS to future extensions. - Axel Polleres, 15 Oct 2019, 15:02:43

| Migrated ISSUE-5: Shall we extend the scope of the group to machinge-readable requests to execute rights accroding to eva’s classification of rights

State: RAISED
Opened on: 2018-12-04

Related Emails:

1. +ISSUE-5: Shall we extend the scope of the group to machinge-readable requests to execute rights accroding to eva’s classification of rights (from [email protected] on 2018-12-04)

Related notes:
https://lists.w3.org/Archives/Public/public-dpvcg/2018Nov/att-0030/Data_subjects_rights_V1.png
Axel Polleres, 4 Dec 2018, 09:58:06

The concepts from DPV-LEGAL regarding locations (e.g. nations), memberships, their corresponding ISO 3166 codes are already provided with multi-language labels by the Getty Thesaurus of Geographic Names (TGN) under a Open Data Commons Attribution License. This is more comprehensive than the one in DPV-LEGAL, and contains other information regarding the locations. However, it is not up to date, as evidenced by UK still being depicted as a member of EU.

Suggestion: declare relation between DPV-LEGAL and TGN, e.g. skos:exactMatch, and provide information about TGN on the DPV-LEGAL page.

User wants to check whether the storage's policies are compatible with their own preferred policies. If there are any discrepancies, the user should be warned and given a chance to make a decision about available options.

Does DPV provide a solution that meets the requirements of this use case?

See also: w3c/odrl#21 which raises the question for ODRL for the case mentioned in solid/specification#355 (comment) .

Thinking along the lines of preferred rights, processing rules, purpose, and so forth.

Propose a specific concept to be added/modified within the purpose hierarchy in DPV, or a reference from where to extract purposes and align them within DPV's existing structure.

| Migrated ISSUE-16: Do we need to further structure consent notice?

State: OPEN
Opened on: 2019-04-05
Description: For instance the following aspects might need refinement: right to data portability,right to recitffy, right to erasure, right to restrict processing, right to object, rights regarding automated decision making or profiling, processors, third parties, sub-processors, outside-EEA transfers, automated decision-making, or other necessary details of the privacy-policy.

Related notes:

1. [axelpolleres]: should be mentioned in the section about CONSENT (which as such will be a subsection of legal basis. - 5 Apr 2019, 13:33:59
2. Possibly take items from Bud's presentation on "what is a Consent Receipt?":
   https://lists.w3.org/Archives/Public/public-dpvcg/2019Oct/att-0016/ConsentReceipt-uld-bpb-3.pdf (From Bud's email: https://lists.w3.org/Archives/Public/public-dpvcg/2019Oct/0016.html) - Bert Bos, 29 Oct 2019, 16:06:14

I'd like to suggest to adopt the best practice of using rdfs:isDefinedBy to indicate an RDF vocabulary in which a resource is described (https://www.w3.org/TR/rdf-schema/#ch_isdefinedby) and rdfs:seeAlso to provide the article context.

Currently the older versions (e.g. DPV, extensions, documentation) can only be accessed through git commits or by using older releases. This means they are not accessible through IRIs or online.

To remedy this, older versions can be provided through the iris /v/X.x where X.x refers to a specific version, e.g. 0.7.1. To implement this: the folder path /v needs to be created, then each version copied inside a directory named for that version's number. This is easier to do using scripts similar to those used for releases. The older releases would then be accessible through the existing IRI scheme as https://w3id.dpv/v/0.5 for DPV or https://w3id.dpv/v/0.5/dpv-gdpr for DPV-GDPR, and so on. The folders will contain their HTML documentation, and the rest of non-DPV resources (e.g. documentation generator, primer) will not be versioned in the same manner to avoid replicating the entire repo.

A caveat here is the increased space taken up by older requirements. On average, a DPV release may be approx. ~40MB in size. So as versions build up, the space taken can quickly cross 1GB. As a strategy, only the last iterations for each major version would be supported in this manner. For example, if DPV had releases 1.1.1 and 1.1.2 before moving to 1.2, then only 1.1.2 would be made available. (note that here semantic versioning refers to MAJOR.Minor.fixes where MAJOR refers to significant changes across all of DPV, Minor refers to addition or changes in some parts.

| Migrated ISSUE-15: Personal data cateories collected might be collected in an approximate manner (e.g. age vs. age range), should we provide a mechanism in the vocabulary to distinguish this?

State: OPEN
Opened on: 2019-04-04

Related Emails:

• +ISSUE-15: Personal data cateories collected might be collected in an approximate manner (e.g. age vs. age range), should we provide a mechanism in the vocabulary to distinguish this? (from [email protected] on 2019-04-04)

Related notes:
[axelpolleres]: should be mentioned in section on PErsonal data categories. - 5 Apr 2019, 13:33:12

This issue is for the discussion of what concepts, documentation, or other resources are necessary or needed or ideal for DPV to be provided as a v1.0.0 stable and feature complete resource. The list and descriptions itself are maintained in the community wiki as DPV future

| Migrated ISSUE-9: Where are categories of data controllers used, where are they useful? (cf. recital 98, 99, 100)

State: RAISED
Opened on: 2019-01-22

Related Emails:

1. +[minutes] 2019-10-15 dpvcg (from [email protected] on 2019-10-15)
2. +[minutes] 2019-01-22 dpvcg (from [email protected] on 2019-01-24)
3. +ISSUE-9: Where are categories of data controllers used, where are they useful? (cf. recital 98, 99, 100) (from [email protected] on 2019-01-22)

Related Notes:

1. [axelpolleres]: relates to ACTION-93 - 5 Apr 2019, 13:24:00
2. RESOLVED: With the same rationale as not defining any particular subclasses or categories of dataSubjects, we leave the concrete definition of particular subcategories of dpv:DataController as an extension point. With this rationale we postpone ISSUE-9 - Axel Polleres, 15 Oct 2019, 14:52:04

"Legal Obligation" is presented as a top-level purpose on the DPV's purposes diagram and the specification only has "Legal Compliance" as purpose.

It seems to me that the class PersonalDataCategory is wrongly named and should be renamed, probably to PersonalData. The rationale is that, from this name, one may infer that instances of the class are "categories", while my understanding is that the categories are actually the subclasses of this class (like "Financial" or "Historical").

What confirms this hint is the fact that one of the subclass is "SpecialCategoryPersonalData" (rather than "PersonalDataSpecialCategory").

Also, I believe that the immediate subclasses of PersonalDataCategory should be named more explicitly FinancialData, HistoricalData and so on... In general, naming a class with an adjective is odd...

Intense bikeshedding, I know...

How and where to model Safeguard as a concept within the DPV.

There should be a documentation style guide (e.g. as a Markdown file in documentation-generator folder) that provides information about the styling conventions for documentation, such as how concept labels should be named, descriptions should be written, different conventions followed, diagrams being generated, and so on.

link on page is https://www.w3id.org/dpv/dpv-primer - actual primer is at https://w3c.github.io/dpv/primer/

While the focus of this vocabulary is Data the concept of consent is equally applicable to actions. And the consent for an action may be closely tied to consent for the use/transfer of data related to that action.

For instance consent for your child to go on a field trip is not a fundamentally different than consent for pictures of your child from that field trip to be shared with the rest of the class. The concept of consent is the same in both cases. And it would be advantageous to ask for/store/show the two consents together, perhaps even as two parts/purposes of the same consent.

Similarly, consent for treatment in a hospital is related to consent for data about said treatment to be shared with other parties such as a primary care physician. It will be less burdensome for both patient and staff to handle both in the same process flow. Also the consents for treatment without consent for data sharing should not be handled different than consents for treatment with consent for data sharing.

The current description of consent as "Consent of the Data Subject for specified processing" makes that difficult, as consent for actions such as field trips or medical treatment hardly can be described as 'specified processing' and the subject of the consent may or may no be a data subject as well.

Therefore I suggest broadening the description of consent, for instance to "formal permission for a specified action", which would include 'specified processing'. I do not include '(Data) Subject' because sometimes, e.g. the case of minors, the person(s) giving the consent is not the (data) subject themselves.

| Migrated ISSUE-20: How to express sensitivity of data?

State: OPEN
Opened on: 2019-05-07

Related Emails:

1. +Re: dpv:HouseOwned (from [email protected] on 2019-07-03)
2. +Re: dpv:HouseOwned (from [email protected] on 2019-07-02)
3. +dpv:HouseOwned (from [email protected] on 2019-06-25)
4. +ISSUE-20: How to express sensity of data? (from [email protected] on 2019-05-07)

| Migrated ISSUE-14: We may want to add a non-normative comment in the spec that/how the taxonomy can be used as SKOS

State: OPEN
Opened on: 2019-04-04

Related Emails:

1. +ISSUE-14: We may want to add a non-normative comment in the spec that/how the taxonomy can be used as skos. (from [email protected] on 2019-04-04)

Related Notes:
[axelpolleres]: we may refer to this link https://www.w3.org/2006/07/SWD/SKOS/skos-and-owl/master.html - 5 Apr 2019, 13:32:27

The semantics of a domain or range that is unspecified is unclear.
Either use rdf:Resource, or owl:Thing, or ANY or leave it blank. (Such technical broad ranges can be useful, e.g. if it is object property an xsd:date is probably not an acceptable value).

Unspecified feels like the working group did not reach an agreement. In W3C DCAT it is just left blank. no statement at all. Indicating that anybody can make any assumption of it.

If you want to use the term, please add the semantics in the document.

kr,

Bert

| Migrated ISSUE-3: Do we want to revisit a definition of "gdpr rights" in our definitions and taxonomies?

State: PENDING REVIEW
Opened on: 2018-09-18
Related Actions Items:
ACTION-132 on Bud P. Bruegger to Bud and Eva will try to come up with partial state-transition diagrams to illustrate the interdependencies of data subject rights by the end of november. - due 2019-11-30, closed

Related Emails:

1. +[minutes] 2019-10-15 dpvcg (from [email protected] on 2019-10-15)
2. +[minutes] 2018-09-18 dpvcg (from [email protected] on 2018-09-19)
3. +ISSUE-3: Do we want to revisit a definition of "gdpr rights" in our definitions and taxonomies? (from [email protected] on 2018-09-18)

Related Notes:

1. related to ISSUE-16 - Axel Polleres, 5 Apr 2019, 13:17:38
2. [axelpolleres]: we assume this is about data subject rights in the current discussion.
   15 Oct 2019, 14:28:48

| Migrated ISSUE-27: Discuss accompanying primer document

State: OPEN
Opened on: 2019-06-18

DPV currently provides GDPR legal bases and GDPR rights in the DPV-GDPR extension https://w3id.org/dpv/dpv-gdpr. The way GDPR is interpreted, specific rights are applicable only for certain legal bases. DPV-GDPR should provide this information in a machine-readable format.

This can be done by taking the information (provided in the table below), and constructing the following tripes:

<legal-basis> dpv:hasRight <right> .

This only include rights applicable, and there should be no triples that express a relation that suggests "right is NOT applicable" i.e. something of the form hasRightNotApplicable. This is because there may always be additional obligations or legal requirements that require such additional rights to be available. An example of this is A.14 when combined with A.6-1c legal obligation where a notice may be required to be provided as per the law that is being implemented.

Whether to provide the inverse relation, i.e. something of the form isExercisableFor to indicate its scope need to be discussed to ensure it does not lead to misinterpretation, incorrectness, or modelling issues.

Sources:

• IE DPC Guidance on Legal Bases for Processing Personal Data https://www.dataprotection.ie/en/dpc-guidance/guidance-legal-bases-processing-personal-data
• UK ICO Lawful basis for processing https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/lawful-basis-for-processing/
• EDPB endorsed A29WP Guidelines on Automated individual decision-making and Profiling for the purposes of Regulation 2016/679 (wp251rev.01) https://ec.europa.eu/newsroom/article29/items/612053/en

Updates

• updated A.22
• A.22 can be specified as applicable to all legal bases (except 6-1c legal obligation) OR it can be split as A.22-1 applicable for 6-1d to f with A.22-3 applicable for 6-1a to b
• A77 right to complaint added

| Migrated ISSUE-2 Do we need to formulate a notion of compliance in scope of the cg?

State: RAISED
Opened on: 2018-09-18
Related emails:

1. +[minutes] 2019-10-15 dpvcg (from [email protected] on 2019-10-15)
2. +ACTION-97 (was: ACTION-89) (from [email protected] on 2019-04-22)
3. +[minutes] 2018-09-18 dpvcg (from [email protected] on 2018-09-19)
4. +ISSUE-2: Do we need to formulate a notion of compliance in scope of the cg? (from [email protected] on 2018-09-18)

Notes:

RESOLVED: move issue-2 to postponed issues under the following text: "The group did not concsider defining any notion of (legal) compliance with respect to a particular legislation in scope of the current specification. While we assume that certain violations of compliance could be recorded with the current vocabulary, compliance guarantees or compliance checking algorithms are not part of this specification."
Axel Polleres, 15 Oct 2019, 14:26:54

During discussions, we avoided defining the term 'cloud'. However, the term is important as increasingly standards, laws, guidelines, etc. have started to directly refer to 'cloud computing' and 'cloud technology' without themselves defining what exactly they mean, and relying on the common use of the term. Reflecting this, DPV-TECH should provide 'cloud' as a means of specifying the infrastructure of the service.

This can be done by creating the concept TechnologyInfrastructure and specifying OnPremiseInfrastructure and CloudInfrastructure as two types. This is distinct from TechnologyUsageLocation since a cloud technology can also be utilised locally, e.g. accessing a service deployed on cloud from local machines. The separation of Infrastructure as a concept from Location of Use as a concept reflects this.

| Migrated ISSUE-39: How to represent collection method of personal data?

State: RAISED
Opened on: 2020-07-08

Dear all, the reasoners for compliance checking expect the ontologies in owl format, which is related to Turtle and RDF but different. It would be helpful to add the OWL serialization to the others already present in the repository.

Functionally, all supported syntax would do (Manchester, functional, XML), but Manchester is the closest to RDF and Turtle, so it may be a preferred choice, as it may look more familiar to RDF and Turtle users.

Content negotiation
Attempting to dereference https://w3id.org/dpv# (using Postman, or CURL) and explicitly setting the HTTP Accept: header to be text/turtle returns HTML, and not Turtle.
But dereferencing http://www.w3.org/ns/dpv# does indeed return Turtle for DPV.

Triples describing DPV as an ontology are missing
The returned turtle file here only has triples describing DPV-GDPR and not DPV:

<https://w3id.org/dpv/dpv-gdpr> a owl:Ontology ;
    dct:abstract "The GDPR extension to Data Privacy Vocabulary provides terms (classes and properties) related to EU General Data Protection Regulation."@en ;
    dct:contributor ...

| Migrated ACTION-140: Share missing concepts in dpv for privacy policy generation

State: open
Person: Georg Philip Krog
Due on: June 3, 2020
Created on: May 27, 2020

Related Emails:

1. +Re: DPV Semantics (from [email protected] on 2020-07-02)
2. +RE: DPV Semantics (from [email protected] on 2020-06-30)
3. +Re: DPV Semantics (from [email protected] on 2020-06-30)
4. +RE: DPV Semantics (from [email protected] on 2020-06-30)
5. +Re: DPV Semantics (from [email protected] on 2020-06-30)
6. +Re: DPV Semantics (from [email protected] on 2020-06-30)
7. +Re: DPV Semantics (from [email protected] on 2020-06-30)
8. +Re: DPV Semantics (from [email protected] on 2020-06-30)
9. +dpvcg-ACTION-140: Share missing concepts in dpv for privacy policy generation (from [email protected] on 2020-05-27)

Related Note:
Missing concepts in dpv from GDPR Art 13 and 14, Treaty 108 and ISO/IEC 29184 have been shared on the public mailing list. - Georg Philip Krog, 24 Jun 2020, 12:44:31

Currently the concepts within DPV-OWL are structured semantically in the same manner as other forms (i.e. RDFS, SKOS). OWL permits declaration of additional axioms such as that for disjointness, class-based relations, and composition (e.g. subclasses). This issue is intended to discuss what these axioms are, and how to provide them as code. Suggestions include adding them directly to relevant files during code generation, or providing them in a separate file but under the same namespace to enable optional inclusion.

Edit: also provide inverse relations between properties.

| Migrated ISSUE-26: Describe use-cases and examples showing how the vocabulary should be or can be used

State: OPEN
Opened on: 2019-06-18

In the interest of not restricting how properties can be used, their domains and ranges have not been explicitly provided in the RDF or listed in the HTML. However, having these either separately in a file or in HTML as applicable or suggested would be useful.

Hi,

I have troubles to understand the Personal data categories as classes
For example:

https://w3c.github.io/dpv/dpv-pd/#CarOwned: Information about cars ownership and ownership history.

How should this be used?

_:agent1 dpv-pd:CarOwned  [
     ex:licenceplate "231321-31213-31231"; 
     ex:model "ferrari"
].

But that conflicts with the statement it is a class, because it is used as a property.

Or is this intented to be used as RDFstar?

<< _:agent1 ex:buys  [
     ex:licenceplate "231321-31213-31231"; 
     ex:model "ferrari"
]. >> a dpv-db:CarOwned

This is all very fuzzy to me.

Secondly I wonder why this list even exists at all. Any agent property is valid isn't it? This looks like an attempt to model the world. For instance this repository contains many personal data information data models: https://github.com/SEMICeu/SDG-sandbox/tree/master/evidences
How can they be integrated in the approach?
Or some further away datamodels like https://smartdatamodels.org/?

How is this envisioned?

kr,

Bert

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

Current documentation (HTML) has some concepts showing association with relevant terms, but this is inconsistent. E.g. https://w3id.org/dpv/dpv-legal#DPA-AT shows link to relevant jurisdiction and laws, but the jurisdiction https://w3id.org/dpv/dpv-legal#AT does not show either the law or the authority. To fix,

1. Make changes in spreadsheet to have this information present there
2. Make changes in 002*.py to serialise this in RDF
3. Make changes in 003*.py to provide these relations in the HTML tables.

NOTE: It would be better in the long term to refactor the entire term extraction process to handle arbitrary relations, as otherwise this would mean custom code for each and every sheet that has a non-uniform structure.

| Migrated ISSUE-6: Should our taxonomy include a distinction/modeling of data subjects to whom gdpr applies (eu citizens and/or located in eu)

State: RAISED
Opened on: 2018-12-04

Related Emails:

1. +[minutes] 2019-10-15 dpvcg (from [email protected] on 2019-10-15)
2. +ISSUE-6: Should our taxonomy include a distinction/modeling of data subjects to whom gdpr applies (eu citizens and/or locatedin eu) (from [email protected] on 2018-12-04)

Related notes:

1. in the context of ISSUE-6 is “non-applicable citizens only” a “legal ground”? - Axel Polleres, 4 Dec 2018, 10:07:55
2. related to ACTION-93 - Axel Polleres, 5 Apr 2019, 13:21:00
3. RESOLVED: We leave the further specification of specific subclasses of DataSubjects out of scope of the current CG, the spec provides just one example, dpv:Child that could serve as an illustration for other subclasses affecting certain groups of DataSubjects (e.g. Citizens of certain states to which a particular legislation applies, etc.) with this rationale we postpone ISSUE-6. - Axel Polleres, 15 Oct 2019, 14:47:37

Example: DPV-GDPR has IRI https://w3id.org/dpv/gdpr whereas the path is /dpv/dpv-gdpr. Either the rule (w3id Apache) should redirect to correct path, or the path should be same as IRI.

| Migrated [ACTION-148]https://www.w3.org/community/dpvcg/track/actions/148): Add DOB as a concept

State: open
Person: Harshvardhan J. Pandit
Due on: February 10, 2021
Created on: February 3, 2021

Related notes:
https://lists.w3.org/Archives/Public/public-dpvcg/2019Dec/0018.html - Harshvardhan J. Pandit, 3 Feb 2021, 16:00:51

The DPV terminology is based on that used by the GDPR (reflection of its conception). In order to make it easier to use the DPV for specific jurisdictions, tables for alignments or mappings can be provided that specify how concepts correlate between different jurisdictions. These mappings can be semantic based (e.g. subclass, SKOS matching) or simply alternate labels (where equivalent, provide labels for specific jurisdiction or notation). Extensions (e.g. DPV-GDPR) would be where the respective assertions are housed. e.g. (showing various possibilities)

# dpv.ttl
dpv:DataController a rdfs:Class ;
    rdfs:label "Data Controller"@en .

# dpv-gdpr.ttl
dpv:DataController :hasLabelForGDPR "Data Controller"@en .
:DataController skos:exactMatch dpv:DataController .
:DataController owl:equivalentClass dpv:DataController .

# dpv-iso.ttl
dpv:DataController :hasLabelForISO "PII Controller"@en .
:PIIController skos:exactMatch dpv:DataController .
:PIIController owl:equivalentClass dpv:DataController .

Adding diagrams to present/explain:

1. Taxonomy for each module, e.g. hierarchy of concepts under 'Purpose'
2. Properties available under each module and their use e.g. 'Purpose'
3. Properties possible for use for each concept, e.g. 'Store' as a processing category can use hasLocation, hasStorage, hasDuration (tbd)

Diagrams depend on concepts, which may change over time. Their generation, therefore, should be preferably programmatic. It should not add a burden to the development and should not be 'difficult' to modify or understand in case changes need to be made. Some available opportunities to explore for this:

• WebVOWL
• Graphviz
• Custom JS diagramming libraries such as mxGraph

| Migrated ISSUE-28: Include a way to indicate PII (Personally Identifiable Information)

State: OPEN
Raised by: Harshvardhan J. Pandit
Opened on: 2019-11-26
Description: Description: "This was an input from people at Dativa (Jan Lindquist and Paul Knowles) when Harsh presented the DPV on a recurring hyperledger indy meeting call. "
Reporter: Jan Lindquist & Paul Knowledge (Dativa; via Harsh)
Link: https://lists.w3.org/Archives/Public/public-dpvcg/2019Sep/0001.html
Notes: "we could resolve those as a flag/subclass. Harsh will provide a proposal on how to address this issue"

| Migrated ISSUE-18: Do we need further temporal annotations for the personal data handling class?

State: OPEN
Opened on: 2019-04-05

Related Emails:

• +ISSUE-18: Do we need further temporal annotations for the personal data handling class? (from [email protected] on 2019-04-05)

Related notes:
[axelpolleres]: Do we need terms to document the time instant of specific personal data handling? the validity time of a certain policy? i.e. the temporal extent of a certain personal data handling instance. - 5 Apr 2019, 13:43:44