Meeting minutes
Repository: w3c/dpv
Meeting minutes: https://
purl for this meeting: https://
DPV 2.0 released
https://
DPV 2.0 is released - congratulations to everyone 🎉
Consent Guide finalisation
harsh: We have a 'draft' message on the consent 27560 guide - https://
no changes, okay to remove the message, and publish this through the w3c process
Legal Extensions for EU/EEA Members
harsh: added legal extensions i.e. under /legal for all EU/EEA member states - except IE and DE which we already had
harsh: for now, only the DPAs have been added for each member state, though it is quite trivial to add in the laws as well as it is only an entry in the spreadsheet. Would be good for new members to contribute here.
harsh: see https://
ISO 3166-2 subdivisions
harsh: added subdivisions (cities, regions) from ISO 3166-2 standard. The source for this information is Wikidata. There was no other suitable resource, as there were subtle errors or discrepencies in most sources.
harsh: see https://
harsh: As the number of subdivisions is approx. 5000 entries, the entire page became quite big in size (10-20 MB) and there was a noticeable delay in opening the page. To avoid usability being reduced, I have removed the table definitions and instead put in simple paragraphs containing the concepts e.g. loc:IE-D - County Dublin (rdfs:Class, skos:Concept, dpv:Region)
Legal Basis
harsh: I discussed contract vocabulary with members from smashHit project which had a contract vocabulary, see the terms adapted for DPV by them here: https://
harsh: However, I am not satisfied with the outcome as there are several terms which do not align with DPV and have no relevant definition or enumeration that we can use
harsh: So based on this, a proposed contract vocabulary is https://
harsh: new proposed concepts are StandardFormContract for when contract is not negotiated, and NegotiatedContract for when it is negotiated. There is SLA and EULA as commonly used terms, and there are concepts to represent B2B and B2C contracts. Other specific terms that come up are employment contract, distribution license, and license agreement. These are not necessarily legal basis for personal data, so we should think how to provide them. We already have dpv:Licence as contract term or legal agreement under legal measure.
harsh: for B2B2C - I don't know whether this is a combination of B2B and B2C i.e. we don't need to model it
beatrizEsteves: for B2B and B2C, we should also add B2B2C as it is used by Athumi here in Flanders
added B2B2C with a note to check its parent concepts later
harsh: To model the status of contract, added statuses to keep track of when it is drafted, offered, negotiated, refused, ended or terminated or invalidated
harsh: added metadata for contract using DCT e.g. title, created, and so on. For duration we should use dpv:hasDuration. For indicating parts of a contract, use dct:hasPart
harsh: to model clauses, dpv:ContractualClause is proposed. Different parts exist such as terms and conditions, preamble, and so on.
harsh: To keep track of contract fulfilment - added concepts for fulfilled, breached, and unfulfilled (i.e. not fulfilled and not breached). For contractual clause, added similar clauses for fulfilment etc.
harsh: For other legal basis, fewer concepts are required. For legal obligation and official authority of controller, a relevant law is associated using dpv:hasApplicableLaw. For legitimate interest, vital interest, and public interest a purpose is needed using dpv:hasPurpose. The necessity of legal obligation, official authority, vital interest is assumed to be required, and for the others it is assumed to be optional unless otherwise noted.
harsh: for Legitimate interest, the statuses are associated with whether the legal basis was declared to the data subject or not, and only after that whether it was objected to or not.
harsh: For legitimate interest objection - we already have opt-out and opt-in somewhere as concepts - so we need to think carefully how to fit all this together - personal preference is that we do it for each legal basis so it doesn't get conflated with consent as opt-in
to be discussed later with Georg present for legal clarity
Sector
harsh: we have sectors in extensions like AI Act, but the list is incomplete. So proposal is that we define only the necessary ones we need in main DPV spec so we can structure or group our concepts e.g. law enforcement purposes under law enforcement sector; for regulation specific sectors there are authoritative lists like NACE.
delaramGolpayegani: would this include other sectors as well that occur in the act as there can be any number of sectors?
harsh: no, the idea is that we only define those that we need in DPV i.e. we have purposes or other concepts specific to that sector so we can use the concept to group things together
paulRyan: like the idea of using something authoritative like NACE
Notice 29184
harsh: working on machine-readable notices https://
Next Meeting
next meeting will be in 1 week on TUESDAY 13 August at 13:30 WEST / 14:40 CEST. Agenda will be continuation of today's topics with any updates on github/mailing list and AOB.