W3C

– DRAFT –
DPVCG Meeting Call

15 SEP 2021

Attendees

Present
:, AxelPolleres, Georg, harsh, Paul, Piero
Regrets
-
Chair
harsh
Scribe
harsh

Meeting minutes

Presentation by Piero Bonatti on using DPVCG's outcomes in TRAPEZE

https://trapeze-project.eu/ TRAPEZE is a H2020 project, a sprititual successor to SPECIAL project which was the progenitor of DPVCG

In TRAPEZE, automating compliance checking (specifically about consent) is the focus and the architecture and use of DPV is focused on these

Stakeholders have dashboards for viewing and interacting with their respective roles and data

Use cases related to compliance: policy compliance with GDPR, with consent, and re-use of consent

User agents help with checking compatibility of preferences in policies and understanding consequences of consent (what-if queries)

Missing in DPV is Disjoint Classes e.g. purpose with processing, recipient

Piero: some terms can be describe in more / with more details (to follow up later)

Example of CommercialInterest for granularity i.e. subclasses of CommercialInterest fulfil any consent given to CommercialInterest (to follow up later)

(will ask to share slides for reference)

Q&A Session

harsh: CommercialInterest was used in the examples, but in DPV we have decided to deprecate the term as it is too vague and difficult to apply in practice. How is its use involved in TRAPEZE?

Piero: This was just an ad-hoc example. If term is vague and not suitable, DPV should deprecate it.

Georg: (discussing on Architecture and feature set and use of DPV)

Collection of questions follows below.

The specification used by TRAPEZE borrows @context from JSON-LD, but is not the same or compatible with JSON-LD. This is because in JSON-LD the values of properties are taken to be instances (some info may have been lost in notes here).

In addition, lists are different in JSON-LD where they could imply intersection whereas in TRAPEZE the requirement is to have union of concepts e.g. purposes.

Discussion on whether DPV should model deontic concepts (e.g. permission, prohibition) to restrict or specify constraints on data. Opinion is that this is difficult to do while ensuring the generality of DPV as a vocabulary.

Experiments can take place under a separate extension to figure out how this might work, but for now DPV can remain agnostic for such terms.

Suggestion taken from Piero's presentation to consider inclusion of concepts such as Anonymised Data and its use e.g. Blurred Location Data.

Minutes manually created (not a transcript), formatted by scribe.perl version 136 (Thu May 27 13:50:24 2021 UTC).