W3C home > Mailing lists > Public > public-dpvcg@w3.org > May 2019

Re: DPVCG: vocab questions

From: Ekaputra, Fajar Juang <fajar.ekaputra@tuwien.ac.at>
Date: Mon, 13 May 2019 08:26:43 +0000
To: "Harshvardhan J. Pandit" <me@harshp.com>
CC: "Kiesling, Elmar" <elmar.kiesling@tuwien.ac.at>, "Data Privacy Vocabularies and Controls Community Group" <public-dpvcg@w3.org>
Message-ID: <77C63B60-A094-4469-9C13-19251E0A3285@tuwien.ac.at>
Hi Harsh,

(1a): As you suspect, we don’t have these descriptions elsewhere, so we need to define them anew - would be happy to work together with you/elmar/others on these descriptions.

(1b): If I remember it correctly, the creation of this class is the result of the discussion last Tuesday.
However, I agree with your argumentation line that probably it’s better to remove it or even make it into a property (as originally proposed).

Best regards,
—
Fajar J. Ekaputra
194/1 Information & Software Engineering Group,
Technische Universität Wien (TUWien).
W: http://juang.id Skype: fajar.juang

On 10.05.2019, at 13:42, Harshvardhan J. Pandit <me@harshp.com<mailto:me@harshp.com>> wrote:

Hi Elmar, Fajar.
I'm cleaning the spreadsheet, and need to resolve a few pending issues to get it to v1.
I wasn't sure who is leading which category (Personal Data / Purpose), so I've included both.

1) Personal Data

a) Missing descriptions
There are missing descriptions for classes, presumably because the EnterPrivacy spreadsheet did not have them (I think?). If so, we would need to define them, similar to what we did with the processing tab.
Do we have these descriptions elsewhere in another spreadsheet by change or do we need to define them anew?

b) Remove DerivedData as a Parent Class
DerivedData is defined as a parent class for a few classes - I think primarily because those classes represent data not possible to obtain by observation (?). However, since a person can always explicitly provide that data, I think the use of DerivedData is not semantically correct.
For example, Internal is defined as a subclass of DerivedData. However, I can always explicitly provide this information, in which it should not be classified as derived.
Therefore, I think DerivedData should be removed as a parent class from the other classes

2) Purpose

a) Remove NACE from purposes
Since we define NACE in an external namespace (dpv-nace), we don't need the example NACE classes in the purposes vocab, and should remove them

b) Beneficiary is accepted or proposed?
The class beneficiary (and property) in purposes is grayed out and does not have descriptions or provenance. Do you know if it is accepted, or is supposed to be removed?

Thanks,
--
---
Harshvardhan Pandit
PhD Researcher
ADAPT Centre
Trinity College Dublin


Received on Monday, 13 May 2019 08:27:40 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:27:57 UTC