This is the list of current Community and Business Groups. Anyone may join; W3C Membership is not required. However, you must have a W3C account.
Use the Activity Dashboard to find out which groups are active.
Community Groups are proposed and run by the community. Although W3C hosts these conversations, the groups do not necessarily represent the views of the W3C Membership or staff.
138
Groups found
The group aims to agree extensions to the XSLT 3.0 Recommendation published on 8 June 2017, along with supporting changes to the other specifications (XPath, Functions and Operators) on which it depends.
A preliminary proposal describing requirements for such extensions can be found in Michael Kay's Proposal for XSLT 4.0 published in the Proceedings of XML Prague 2020
It is intended that the group will operate primarily by use of email and forums but may hold a face-to-face meeting to resolve issues prior to final publication of a specification.
The group may publish specifications.
The Spec Editors Community Group aims to be an inclusive space where spec editors, and those wanting to become spec editors, can learn from each other.
The Spec Ed CG focuses on the practice (the art?) of writing technical specifications across the Web ecosystem (W3C, WHATWG, ECMA, IETF, etc.). By looking across the ecosystem, we hope to improve our specification development practices at the W3C.
As part of this CG, we hope to run hands-on virtual tutorial sessions that will cover:
The Maps in HTML Community Group seeks to establish at least one hypermedia type which can be considered to be consumed by a (new) "map" element for HTML. Follow-on from Bar Camp at #lgd14. The objective will be to define a hypermedia type which can be linked to from a hypothetical (but prototyped in Web Components) "map" or (geo-map for Web Components) element which will provide simple mashup capabilities and user interface.
This group will publish specifications.
The aims of the Solid project are in line with those of the Web itself: empowerment towards an equitable, informed and interconnected society. Solid adds to existing Web standards to realise a space where individuals can maintain their autonomy, control their data and privacy, and choose applications and services to fulfil their needs.
The mission of the Solid Community Group is to describe the interoperability between different classes of products by using Web communication protocols, global identifiers, authentication and authorization mechanisms, data formats and shapes, notifications, and query interfaces.
To contribute towards a net positive social benefit, we use the Ethical Web Principles to orient ourselves. The consensus on the technical designs are informed by common use cases, implementation experience, and use.
Solid Technical Reports lists Work Items, information on how to Participate, and the Solid of Code of Conduct (in addition to the Positive Work Environment at W3C: Code of Ethics and Professional Conduct.)
The ODRL Community Group supports the promotion and future development of the W3C ODRL recommendations:
Specifically, the ODRL CG will:
The overall goal/mission of this community group is to explore the requirements, best practices and implementation options for the conceptualization and specification of domain knowledge in AI.
We plan to place particular emphasis on the identification and the representation of AI facets and various aspects (technology, legislation, ethics etc) with the purpose to facilitate knowledge exchange and reuse.
Therefore the proposed outcomes could be instrumental to research and advancement of science and inquiry, as well as to increase the level of public awareness in general to enable learning and participation.
Proposed outcomes:
WHO SHOULD JOIN: researchers and practitioners with an interest in developing AI KR artifacts (ontology, machine learning, markup languages)
The Music Notation Community Group develops and maintains format and language specifications for notated music used by web, desktop, and mobile applications. The group aims to serve a broad range of users engaging in music-related activities involving notation, and will document these use cases.
The Community Group documents, maintains and updates the MusicXML and SMuFL (Standard Music Font Layout) specifications. The goals are to evolve the specifications to handle a broader set of use cases and technologies, including use of music notation on the web, while maximizing the existing investment in implementations of the existing MusicXML and SMuFL specifications.
The group is developing a new specification to embody this broader set of use cases and technologies, under the working title of MNX. The group is proposing the development of an additional new specification to provide a standard, machine-readable source of musical instrument data.
The mission of the W3C Data Privacy Vocabularies and Controls CG (DPVCG) is to develop a taxonomy of privacy and data protection related terms, which include in particular terms from the new European General Data Protection Regulation (GDPR), such as a taxonomy of personal data as well as a classification of purposes (i.e., purposes for data collection), and events of disclosures, consent, and processing such personal data.
The DPVCG was created as an outcome of the W3C Workshop on Data Privacy Controls and Vocabularies in Vienna in 2017, and started on 25th May 2018 – the date of the enforcement of GDPR. Since then, the DPVCG has worked to fulfil its aims and objectives, and produced the Data Privacy Vocabulary (DPV) as a deliverable.
Membership to the group is open to all interested individuals and organisations. To join the group, you need a valid W3C account – which is free to get and can be requested here. The group meets usually through online meeting calls, details of which, including past minutes, can be found here. The group also interacts through a mailing list regarding topics, discussions, sharing of agendas, actions, and other relevant items. The resources and work relevant to the group is hosted on the GitHub platform under the DPVCG name.
The group is currently chaired by:
Previously, it was chaired by:
The working of the group is fairly open and transparent in its process, with most of the information present on the wiki. For past work, actions, issues, and records – please refer to the wiki and threads on the mailing list. Anyone can use the mailing list to ask questions, suggest topics, raise issues, and offer solutions. Non-members might receive an automated reply asking them to authenticate their email or email address for posting.
Similarly, calls are usually open to attend, with the agenda shared on the public mailing list. Call details may be shared on the internal mailing lists accessible to only members for security purposes – so it may be best to ask the chair(s) or a member for attending a call.
General questions regarding what the group considers in scope can be determined from the aims and objectives. Specific queries or propositions should be conveyed to the mailing list. For issues regarding the DPV, including addition of concepts or a query or other relevant topics – you can use the mailing list or the issues feature in a GitHub repo.
The DPV is a vocabulary (terms) and an ontology (relationships) serialised using semantic-web standards to represent concepts associated with privacy and data protection, primarily derived from GDPR. It enables representation of which personal data categories are undergoing a what kind of processing by a specific data controller and/or transferred to some recipient for a particular purpose, based on a specific legal basis (e.g., consent, or other legal grounds such as legitimate interest, etc.), with specified technical and organisational measures and restrictions (e.g., storage locations and storage durations) in place.
The DPV is useful as a machine-readable representation of personal data processing and can be adopted in relevant use-cases such as legal compliance documentation and evaluation, policy specification, consent representation and requests, taxonomy of legal terms, and annotation of text and data.
The DPV is an evolving vocabulary – as the DPVCG continues to work on updating it with broader concepts as well as enriching its hierarchy of concepts. For this, we invite contributions of concepts, use-cases, requirements, and applications.
The mission of the RUM Community Group is to improve and expand the capabilities of developers and businesses who are using Real User Monitoring (RUM) to measure user experience on the web.
We are focused on the measurement of performance, errors, logs, tracing, activity, and any other facet that indicates user experience.
Our deliverables would include: Collaborative research projects (sharing the experimental results and any findings), and generating documents for external consumption (principles, opinions, positions, recommendations to Working Groups and others).
This community group is part of the OpenActive initiative. Our goal is to develop technical specifications and best practices that will support the use of open and shared data relating to sports and physical activities.
Our primary focus is on standardising how to publish data about opportunities to be physically activity, defining best practices and APIs to enable booking of events and facilities, and improving interoperability of data across the sector.
To ensure that our specifications will support a variety of use cases, we welcome contributions from a range of organisations, including existing platforms and new startups.
While our work is technical, you don’t have to be a developer to contribute to our standards group. We are looking for input from product and service managers whose domain knowledge can help us to create better outputs.
Conflict-Free Replicated Data Types and the local-first approach they enable are evolving very rapidly. This community group will focus on coordinating efforts to specify CRDT for RDF. There are various existing efforts already working on CRDT for RDF or some aspects of it such as:
As well as broader CRDT and local-first community https://localfirstweb.dev/
This CG would offer a neutral space to help coordinate those efforts.
This group will publish Specifications. Outcomes from this group could be submitted to a future RDF-focused WG. The work of this group could be beneficial to other groups at W3C such as the Linked Web Storage Working Group.
Bluetooth is a standard for short-range wireless communication between devices. This group is developing a specification for Bluetooth APIs to allow websites to communicate with devices in a secure and privacy-preserving way. In particular the web Bluetooth API focuses on minimizing the device attack surface exposed to malicious websites, possibly by removing access to some existing Bluetooth features that are hard to implement securely. Further, the API takes the approach of a user interface to select and approve access to devices as opposed to using certification and installation.
Most of our activity happens in our GitHub repository, with supporting code in adjacent repositories in the WebBluetoothCG GitHub organization.
The group will incubate specifications for decentralized web applications, with a goal of enhancing security, privacy, and efficiency through the use of blockchain technologies. Our first deliverable will comprise a list of value-adds and benefits that blockchain technology may be able to provide for the World Wide Web community. Subsequently, based on our findings, we aim to agree on a set of general, high-level requirements and capabilities that blockchain-based application architectures would need to fulfill in order to deliver value. Finally, we aim to explore the potential impacts of these architectures on the privacy, resiliency, incentives, and accessibility of the web, and to establish relationships with other groups to ensure alignment as these solutions are developed.
Media web application developers want to deploy their content on a wide and heterogeneous range of devices and platforms, e.g. televisions, set-top boxes, and mobile devices. To ensure a smooth user experience across devices, these user agents need to support a minimum set of Web technologies that developers can rely on being supported. This Community Group plans to specify such a set of Web technologies and additionally plans to provide guidance for developers and implementers e.g. on performance constraints and portability issues.
See the CG charter for more information.
The Publishing Business Group fosters ongoing participation by members of the publishing industry and overall publishing ecosystem in the development of the Web for publishing, and serves as a conduit for feedback between the publishing ecosystem and W3C. See the Publishing Business Group Charter for details.
The Business Group maintains a separate “Working” Web site, which includes documents, like information on meetings, index for meeting minutes, and other working documents. There is also a separate wiki for BG members. Finally, if necessary or convenient, Google Documents can also be used; these are collected in a separate Google Drive folder.
(The Working Web site’s content is actually served from a dedicated Github repository.)
This group is for collaboration between people working on web components libraries, tools, documentation and standards.
We will work together on projects of shared interest in order to enhance interoperability, solve common problems, build shared community resources, and ultimately continue to grow a cooperative, productive, and happy web components ecosystem.
Areas we expect to work on include gap analysis, design principles, common protocols, discoverability and quality, documentation, tooling, and more.
This is the community group for individuals interested in contributing to the development and maintenance of the Accessibility Roles and Responsibilities Mapping (ARRM) framework.
The purpose of the ARRM is to guide web teams (designers, developers and content creators) and subject matter experts in successfully distributing accessibility responsibilities by roles in a web development lifecycle, so that every stakeholder understands the role that they have to play in embedding accessibility requirements and best practices in their workflow in order to make digital content more usable to - and inclusive of - people with various types of disabilities.
This group will not publish Specifications.
Mission
The mission of the COGA Community Group is to work with and support the Cognitive and Learning Disabilities Accessibility (COGA) Task Force to improve web accessibility for people with cognitive and learning disabilities.
This group supports the COGA Task Force by supplying user needs and feedback.
Scope
The COGA Community Group’s work will include:
- Sharing challenges when using the web and other digital displays
- Suggesting user needs
- Helping with research
- Suggesting ways to improve accessibility for the community
- Reviewing COGA’s drafts
- Outreach and collecting feedback from the community
- Helping with policy and the business cases for COGA guidance
- Having open meetings to discuss these points
Open meetings may be live video conferences or in other discussion formats
Participation
You do not need to be an expert in all topics related to cognitive accessibility to join the community group. The COGA Community Group will work in smaller groups for specific subjects, giving you the opportunity to participate on the topics you choose.
The COGA Community Group will also work together on some topics, brainstorming and building a community dedicated to improved access for all.
Anyone can join this group as long as they follow the community guidelines.
However, the community group will specifically benefit from including:
- people with learning and cognitive disabilities,
people with mental health challenges,
- caregivers, therapists and people who work with people with learning, cognitive challenges and in mental health,
- researchers,
developers, quality assurance professionals, and user interface experts,
industry, looking to share and support ideas, and
policy makers.
Additional details of participation
- Joining the COGA Community Group does not involve joining the COGA Task Force.
- If you would prefer to join this group anonymously, please send an email to ran@w3.org.
- The community group will not publish specifications, but may make suggestions to the COGA taskforce.
- For more information about community groups, please visit Community and Business Groups Frequently Asked Questions.
- Short link to this document: bit.ly/coga-community
The mission of this group is to discuss accessibility adapted for children (age appropriate, literacy relevant).
The Community Group welcomes meeting accommodation sponsorship through funding or complimentary services. Many thanks to Patricia Lessard, Things Entertainment, LLC and Deaf Services of Palo Alto for your donations.
The real world is frustratingly uncertain, incomplete and inconsistent. This is challenging for traditional approaches to information systems, and a new paradigm is needed that combines symbolic and statistical techniques, building upon decades of work in the cognitive sciences, and over 500 million years of natural selection. This will allow us to create cognitive agents that learn and reason based upon prior knowledge and past experience, and which can satisfy the need for, transparency in decision making, and continuous learning for adapting to ever changing needs. This community group will address opportunities for cognitive agents using graphs, statistics, rules and graph algorithms, starting with an amalgam of RDF and Property Graphs, together with Web architecture for cognitive databases.
More specifically, the Cognitive AI Community Group will work on use cases and requirements, demo's, open source, and scaling experiments. For more details, see:
• Cognitive AI CG GitHub Repository
• Chunks and Rules Specification
• Keynote on Cognitive AI for the 2020 Summer School on AI in Industry 4.0
• An older talk on Cognitive AI and the Sentient Web
The Web NFC Community Group will create a Near Field Communication API that is browser-friendly and adheres to the Web's security model. We believe that means the API will not expose full, low level NFC functionality, but rather a higher level subset that is safe for Web pages, protects user privacy, and does not annoy users with unnecessary or complex permission requests. See the Web NFC Community Group Charter and the Web NFC specification for more information.
The mission of the W3C Credible Web Community Group is to help shift the Web toward more trustworthy content without increasing censorship or social division. We want users to be able to tell when content is reliable, accurate, and shared in good faith, and to help them steer away from deceptive content. At the same time, we affirm the need for users to find the content they want and to interact freely in the communities they choose. To balance any conflict between these goals, we are committed to providing technologies which keep end-users in control of their Web experience.
The group's primary strategy involves data sharing on the Web, in the style of schema.org, using existing W3C data standards like JSON-LD. We believe significant progress toward our goals can be reached by properly specifying "credibility indicators", a vocabulary/schema for data about content and the surrounding ecosystem, which can help a person and/or machine decide whether a content item should be trusted.
Please see the group wiki for more details.
1. Goals The mission of this group is to explore mechanisms and interfaces between Cloud, Edge, and Client for computing workload offloading and orchestration. The typical use cases include AI acceleration, cloud gaming, and streaming acceleration. The goal is to explore the feasibility of defining a set of new APIs and mechanisms that enable computing workload offloading and orchestration between Cloud, Edge, and Client. It should leverage existing mechanisms as much as possible and should coordinate with related W3C working groups and other SDOs and open-source communities if necessary.
2. Scope of Work This group aims to discuss proposals for Cloud-Edge-Client coordination, including: - Use cases and requirements for Cloud-Edge-Client coordination - Proposals for APIs and mechanisms (including protocols) that enable computing workload offloading and orchestration between Cloud, Edge, and Client - Secure networking and trust model requirements in the context of edge computing and offload to edge.
3. Out of Scope The following are out of scope: Actual development of standards.
4. Success Criteria The Group will have succeeded if it can achieve the following:
- Participation from various stakeholder communities, especially from startups and innovators in the space of distributed computing; - Consensus on a standard solution architecture for workload offloading.
5. Deliverables Work items can be documents, such as specifications, technical reports, best practices and guidelines, use cases and requirements, white papers, etc. Work items can also be software, for instance test suites, samples, proof of concept work, etc. In general, all work items in scope of the group are welcome. If there are individuals who will commit to being editors for a document, the group should record agreement to accept it as a work item even if it conflicts with previous work adopted by the community. Newly-accepted work items that extend beyond the scope of this Community Group Charter will lead to a reconsideration of the Charter. The Community Group may vote to revise the Charter in order to include new work, or to determine that the proposed work is unrelated.
6. Specifications The group may produce Specifications that are not on the W3C Standards track. Development of W3C Standards should be done in appropriate Working Groups.
7. Non-Normative Reports The group may produce other Community Group Reports within the scope of this charter that are not Specifications, for instance Techinal Reports, Use Cases, Requirements, Primers, White Papers, etc.
8. Test Suites and Other Software The group MAY produce test suites to support the Specifications. Please see the GitHub LICENSE file for test suite contribution licensing information.
9. Dependencies or Liaisons The group may collaborate with other relevant groups within W3C.
10. Community and Business Group Process 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.
11. 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.
12. 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.
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.
13. 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.
14. 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.
15. 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.
The aim of the Rights Automation for Market Data Community Group is to develop and publish a market-data profile for ODRL.
Market data is mostly the pricing and trading data for financial instruments (and their associated indices) generated by trading venues. The licenses controlling its use are frequently complex, and tightly segment the underlying data.
We will model these licenses using ODRL and extend the language with a profile that defines the new terms required. This group will publish Specifications.
With a standard, machine-readable way of describing market data licenses, we can look towards automating rights-management along the market data supply chain and drive efficiencies in financial markets.
The group welcomes the involvement of domain experts in licensing (especially market data) and those skilled in modeling licenses (especially using ODRL).
If you are not a group participant you can still subscribe to our list.
The goal of the Games Community Group is to improve the quality of open web standards that games developers rely on to create games. To achieve its goal, the Games community group will:
The Games community group will not develop any normative specification. As such, there will not be any Essential Claims under the W3C Contributor License Agreement or Final Specification Agreement.
Please see the adopted charter for details.
This community effort aims to provide medical,healthcare and life-science specialized web schemas and vocabulary through improving and extending the existing schemas, concepts, terms and definitions in schema.org vocabulary. Ultimate goal is to enable the use of schema.org not only by webmasters but also in indexing health records, healthcare documents, and as a pillar open source of medical and healthcare and life science ontology/vocabulary for formalization of healthcare information.
This will make healthcare and medical data on web easy to describe correctly (with their correct meaning and context), easy to expose /index so ready to be accessible and will highly improve to re-usability and exchanging in semantic way, with their correct meaning and context.
The intention is not to replace existing ontologies, nor making upper level ontology nor creating yet another clinical information model/standards. The aim is mainly to provide most useful and frequently used (so, demand driven) classes and properties related to the medical and healthcare domain. Within this scope all concepts are mapped as far as it's feasible to the existing terminology like SNOMED CT, ICD, LOINC, ATC, RxNorm, HL7 FHIR, etc.
Much is said about the mismatch between the needs of employers for qualified employee candidates and a pool of available candidates. One major factor contributing to this mismatch is the signaling between the demand-side (i.e., employers) and supply-side (i.e., education, training and credentialing providers, students and workers) of the talent pipeline. This mismatch frequently results in neither party coming into view of the other. The goal of the Talent Marketplace Signaling (TalentSignal) Community Group is to assist Schema.org in improving workforce signaling by refining existing schema.org types serving the talent pipeline and suggesting new types and properties where improved signaling cannot otherwise be achieved. Currently, workforce signaling sits at the intersection of a number of existing schema.org types: Course, JobPosting, Occupation, Organization, Person and the proposed EducationalOccupationalCredential.
The TalentSignal Community Group will focus initially on refinement of the JobPosting Schema and related types as it survey's specifications from domain entities such as HR Open Standards and PESC as well as the US Chamber of Commerce Foundation's Job Data Exchange (JDX) and T3 Innovation Network initiatives for better means to strong, more effective supply- and demand-side signaling.
Discussion forum between CSS experts, Color Management experts, and TV/Movie/Broadcast experts to explore use cases and inform W3C specification work (such as CSS Color 4 and subsequent levels). Both SDR and HDR are in scope. Wide gamut displays and the Web is in scope. Web use of ICC (v.4 and ICCMax) is in scope.
