Consistency in class naming about dpv HOT 4 CLOSED

In principle, I agree with both points. However, two 'burdens':

1. Changing one of the core concepts i.e. PersonalDataCategory -> PersonalData is a big change in terms of backwards compatibility (difficult)
2. Real world usage doesn't include suffixing all subsequence categories with "Data" (which is why they're named as such). But again, I agree in that in principle 'Internal' and 'External' are not good labels for terms.

Some form of a guide for concept naming and description texts needs to be established (doable). Solution for 1 could be to keep the IRI the same PersonalDataCategory and only change the label to PersonalData. Same for subclasses.

P.S. Pierre-Antoine (thank you) was kind enough to replicate the issue from dpvcg/dpv#12 where I had lapsed to close the earlier DPVCG repos. My comment has been copied over as well.

from dpv.

Relevant mail with stylistic options and alternatives for resolving this: https://lists.w3.org/Archives/Public/public-dpvcg/2021Nov/0001.html Gist of it is:

Some stylistic options discussed:

1. pd_Location
2. Location_pd
3. LocationPD
4. PDLocation
5. PD_Location
6. LocationData (from GitHub Issue #27 [3])
7. LocationPersonalData

Personally, I still prefer providing personal data categories as a separate taxonomy that can grow on its own, but if the group consensus is to choose from this list, I'd pick #1 and #4 (in that order).

from dpv.

Discussion on renaming PersonalDataCategory to PersonalData with group agreement in today's meeting: thread in mailing list and minutes of meeting.

from dpv.

DPV v0.4 makes this change: PersonalDataCategory has been replaced with PersonalData (same for relevant properties and other concepts). The personal data categories have been moved to extension dpv-pd to separate personal data and other concepts e.g. Location as personal data and Location as data storage location. I believe this concludes this issue, and if there are no further discussions, will close it next week.

from dpv.