[DRAFT] W3C Data Privacy Vocabularies and Controls Community Group (DPVCG) Charter This Charter is work in progress. To submit feedback, please use: https://github.com/w3c/dpv/issues/399 * This Charter: https://w3id.org/dpv/charter * Previous Charter: https://www.w3.org/community/dpvcg/2020/09/22/data-privacy-vocabularies-and-controls-community-group-dpvcg/ (not formally adopted) * Start Date: Estimated 2025-12-01 * Last Modified: N/A Examples (not endorsement) of other charters: * Solid CG https://www.w3.org/community/solid/charter/ * Privacy CG https://privacycg.github.io/charter.html * Privacy Interest Group https://www.w3.org/2019/09/privacy-ig-charter.html Mission The mission of the W3C Data Privacy Vocabularies and Controls Community Group (DPVCG) is to develop ontologies and taxonomies that support the implementation of regulations, standards, and approaches relevant to privacy and data protection. Scope of Work The scope of the DPVCG is defined in terms of providing ontologies and taxonomies that represent information from normative sources (e.g. laws, standards) and their practical implementation considerations (e.g. use-cases, sectorial). The term 'ontologies' refers to modelling concepts and relationships between them, for example 'Personal Data' concept and its associative relation 'has personal data'. The term 'taxonomies' refers to providing enumeration of ontological concepts based on real-world use and requirements, for example defining 'email', 'name', 'likes/dislikes' as kinds of personal data. The DPVCG refers to both ontologies and taxonomies collectively as "vocabularies" (in its name). The 'core vocabulary' for defining the scope of the DPVCG is as follows: 1. Personal Data and its categorisation as sensitive, special, and transformation into forms such as anonymisation and pseudonymisation 2. Operations (processing of personal data) such as collect, use, store, share, erase , including locations, durations, and other contextual information 3. Purpose or end-goals for why data is being processed or something is being done 4. Entities and their roles such as controller, human or data subject, service provider that assist in specifying responsibilities and ensuring accountability 5. Technologies involved and their provision and deployment 6. Measures including technical, organisational, legal, and physical measures, such as to ensure security or safeguard safety or to provide transparency through notices 7. Risks and impacts associated with their processes and how they can be mitigated 8. Contextual information such as controls, necessity, statuses, reuse, involvement 9. Jurisdictional (i.e. legally defined) information such as applicable laws, defined legal bases, compliance requirements and outcomes, and defined rights and their exercise 10. Logical grouping of concepts into units or processes and indication of whether they are permitted, prohibited, obligated and other relevant rules The work of the DPVCG is inspired by and arose out of a project associated with the EU and its GDPR requirements. However, the scope of the DPVCG is inclusive of all jurisdictions and their specific laws and topics associated with privacy and data protection. To accommodate this, the DPVCG has developed a modular structure that separates the 'main' and 'jurisdictional' aspects into separate namespaces. To assist with the adoption of the DPVCG's outputs and to facilitate engagement and participation, the DPVCG provides materials such as guides, examples, and primers. These resources can be generic or address a specific need or requirement, for example to assist with compliance with specific standards or legal measures. The DPVCG can provide mappings and schemas to assist with the use of its outputs with other existing approaches and norms. For example, a mapping from the DPV to W3C ODRL standard, or to represent consent records as per ISO/IEC TS 27560:2023. The DPVCG's work consists of analysis of sources, modelling information concepts and requirements, and representing these as artefacts, primarily in RDF which is a W3C standard for interoperable and machine-readable data. To express the semantics of concepts and relationships, the DPVCG makes use of the following additional W3C standards: RDFS, SKOS, OWL. All other forms and outputs are derived from these in a consistent manner. The Turtle RDF serialisation format is used as the canonical representation with other output forms being derived from this while ensuring compatibility and consistency. Out of Scope 1. Determination of legal compliance, conformity, or any other measure is out of scope. The DPVCG provides solely the means to represent information involved in determining these and to assist in the process through information modelling. 2. Developing software or other algorithmic methods as a specific implementation are out of scope. The DPVCG provides schema and specifications that can be used to develop such approaches. 3. Modelling of topics, laws, or other concerns that do not relate to privacy and data protection are out of scope. Topics that are not primarily about privacy or data protection can be within the scope if they relate to the core concepts and provide meaningful representation of information (e.g. considering AI technologies as involving personal data is within scope, and by extension the AI Act is in scope) 4. Topics such as IP, copyright, trademarks, and trade secrets are out of scope beyond their acknowledgement as relevant measures (e.g. to protect personal data) 5. Implementation of the DPVCG's outputs for specific use-cases (e.g. solely within an organisation or a project) are out of scope. The DPVCG members can be approached to provide advice and to participate in such matters. Using an organisation's use-cases to improve the DPVCG's outputs, for example through additional concepts, are within scope. 6. Proprietary use-cases, information, or other non-public information is out of scope. The participation and work of the DPVCG will be in accordance with the W3C's policies for community groups. 7. Conformity assessments or certifications for guides, mappings, and schemas provided by the DPVCG are out of scope. Deliverables Vocabularies 1. The Data Privacy Vocabulary (DPV), referred to by its canonical IRI https://w3id.org/dpv, is the primary output of the DPVCG. The DPVCG may provide additional extensions through consensus. The following broad category of extensions is provided as deliverables: 1. Personal Data (PD) 2. Risk Management (RISK) 3. Technology (TECH), including (AI) 4. Locations and Jurisdictions (LOC) 5. Justifications (JUST) 6. Legal extensions representing specific jurisdictions (e.g. EU, Ireland, USA) 7. Legal extensions representing specific laws (e.g. EU GDPR) 8. Extensions representing Standards (e.g. IEEE P7012) 9. Extensions representing specific sectors (e.g. Education, Health) 2. Documentation: The DPVCG also provides a Primer to assist with understanding the DPV, and several Guides for assisting with specific objectives or topics. These documentation can contain recommendations that are suggested for consistent and interoperable use of the DPV. 3. Mappings: The DPVCG aims to provide mappings with other well-established vocabularies i.e. correspondences that specify how the DPV's concepts fit with the concepts provided in other vocabularies. The goal of this is to assist in the use of the DPV with other existing vocabularies. For example, DPV can be used within ODRL policies, which are a W3C standard through the mappings. 4. Schemas: The use of DPV in a well-defined and constrained manner for a specific topic or objective. For example, for indicating consent records as defined by ISO/IEC TS 27560:2023 and EU GDPR. Non-Normative Reports 1. Examples that illustrate the use of DPV are non-normative 2. Use-cases that describe scenarios and requirements are non-normative and represent information that assists in the development of the DPV Dependencies or Liaisons 1. W3C: 1. Liaison with the W3C ODRL CG as there is an overlap in scope, outputs (e.g. DPV and ODRL both model policies and concepts). There are overlapping members between the DPVCG and ODRL CG who conduct the liaison. 2. PING WG and Privacy CG are relevant regarding privacy, where their work may provide additional requirements, concepts, and guidance for the development of technical measures in DPV. Similarly, the outputs of the DPV may be of use to these stakeholders to understand and represent information. 2. Other Standards Development Organisations where the DPVCG members may utilise the outputs of the DPVCG directly (i.e. referenced in the document) or indirectly (e.g. by using DPV's concepts to understand information requirements) 1. ISO/IEC: JTC1/SC27 regarding cybersecurity and privacy, and JTC1/SC42 regarding artificial intelligence. There are overlapping members between the DPVCG and these groups. There is no formal liaison. 2. CEN/CENELEC: JTC13 regarding cybersecurity and privacy, and JTC21 regarding artificial intelligence.There are overlapping members between the DPVCG and these groups. There is no formal liaison. 3. IEEE: There are overlapping members between the DPVCG and efforts such as IEEE P7012. There is no formal liaison. 4. Interoperable Europe and SEMIC program: These represent similar initiatives for creating vocabularies and associated topics (e.g. legal compliance).There are overlapping members between the DPVCG and these groups. There is no formal liaison. Community and Business Group Process[a] The group operates under the Community and Business Group Process. Terms in this Charter that conflict with those of the Community and Business Group Process are void. As with other Community Groups, W3C seeks organizational licensing commitments under the W3C Community Contributor License Agreement (CLA). When people request to participate without representing their organization's legal interests, W3C will in general approve those requests for this group with the following understanding: W3C will seek and expect an organizational commitment under the CLA starting with the individual's first request to make a contribution to a group Deliverable. The section on Contribution Mechanics describes how W3C expects to monitor these contribution requests. The W3C Code of Ethics and Professional Conduct applies to participation in this group. Work Limited to Charter Scope The group will not publish Specifications on topics other than those listed under Specifications above. See below for how to modify the charter. Contribution Mechanics Substantive Contributions to Specifications can only be made by Community Group Participants who have agreed to the W3C Community Contributor License Agreement (CLA). Specifications created in the Community Group must use the W3C Software and Document License. All other documents produced by the group should use that License where possible. {TBD: if CG doesn't use GitHub replace the remaining paragraphs in this section with: "All Contributions are made on the groups public mail list or public contrib list"} Community Group participants agree to make all contributions in the GitHub repo the group is using for the particular document. This may be in the form of a pull request (preferred), by raising an issue, or by adding a comment to an existing issue. All GitHub repositories attached to the Community Group must contain a copy of the CONTRIBUTING and LICENSE files. Transparency The group will conduct all of its technical work in public. If the group uses GitHub, all technical work will occur in its GitHub repositories (and not in mailing list discussions). This is to ensure contributions can be tracked through a software tool. Meetings may be restricted to Community Group participants, but a public summary or minutes must be posted to the group's public mailing list, or to a GitHub issue if the group uses GitHub. Decision Process If the decision policy is documented somewhere, update this section accordingly to link to it. This group will seek to make decisions where there is consensus. Groups are free to decide how to make decisions (e.g. Participants who have earned Committer status for a history of useful contributions assess consensus, or the Chair assesses consensus, or where consensus isn't clear there is a Call for Consensus [CfC] to allow multi-day online feedback for a proposed course of action). It is expected that participants can earn Committer status through a history of valuable contributions as is common in open source projects. After discussion and due consideration of different opinions, a decision should be publicly recorded (where GitHub is used as the resolution of an Issue). If substantial disagreement remains (e.g. the group is divided) and the group needs to decide an Issue in order to continue to make progress, the Committers will choose an alternative that had substantial support (with a vote of Committers if necessary). Individuals who disagree with the choice are strongly encouraged to take ownership of their objection by taking ownership of an alternative fork. This is explicitly allowed (and preferred to blocking progress) with a goal of letting implementation experience inform which spec is ultimately chosen by the group to move ahead with. Any decisions reached at any meeting are tentative and should be recorded in a GitHub Issue for groups that use GitHub and otherwise on the group's public mail list. Any group participant may object to a decision reached at an online or in-person meeting within 7 days of publication of the decision provided that they include clear technical reasons for their objection. The Chairs will facilitate discussion to try to resolve the objection according to this decision process. It is the Chairs' responsibility to ensure that the decision process is fair, respects the consensus of the CG, and does not unreasonably favour or discriminate against any group participant or their employer. Chair Selection Participants in this group choose their Chair(s) and can replace their Chair(s) at any time using whatever means they prefer. However, if 5 participants, no two from the same organisation, call for an election, the group must use the following process to replace any current Chair(s) with a new Chair, consulting the Community Development Lead on election operations (e.g., voting infrastructure and using RFC 2777). 1. The call for an election should be made on the public mailing list and by current member(s) of the DPVCG. If such a call is made within a meeting, the minutes should be posted to the mailing list with the call. 2. Participants that are DPVCG members announce their candidacies. Participants have at least 14 days to announce their candidacies, but this period ends as soon as all participants have announced their intentions. If there is only one candidate, that person becomes the Chair. If there are two or more candidates, there is a vote. Otherwise, nothing changes. If the chair fails to inform the group about the election within 2 weeks of accumulating 5 votes, the process can be assumed to have automatically started and members can announce their candidacy. 3. Participants that are DPVCG members vote. Participants have at least 21 days to vote for a single candidate or for multiple positions (if applicable), but this period ends as soon as all participants have voted. The individual(s) who receives the most votes, no two from the same organisation, is elected chair. In case of a tie, RFC2777 is used to break the tie. An elected Chair may appoint co-Chairs directly if there are no objections, or may use the election process for the same. Participants dissatisfied with the outcome of an election may ask the Community Development Lead to intervene. The Community Development Lead, after evaluating the election, may take any action including no action. For information, see https://www.w3.org/community/about/process/ Amendments to this Charter The group can decide to work on a proposed amended charter, editing the text using the Decision Process described above. The decision on whether to adopt the amended charter is made by conducting a 30-day vote on the proposed new charter. The new charter, if approved, takes effect on either the proposed date in the charter itself, or 7 days after the result of the election is announced, whichever is later. A new charter must receive 2/3 of the votes cast in the approval vote to pass. The group may make simple corrections to the charter such as deliverable dates by the simpler group decision process rather than this charter amendment process. The group will use the amendment process for any substantive changes to the goals, scope, deliverables, decision process or rules for amending the charter. [a]from this point on the text below is standard boilerplat w3c suggested stuff; I have only corrected where we publish minutes, rephrased the election process, etc.