A reminder that we will have a virtual meeting next Tuesday, 17 March 2026 at 4pm UTC to which all Community Group members are invited. This meeting is a chance for the co-chairs to provide an update on each of the CG’s specifications – SMuFL, MusicXML, and MNX – and for the new MusicXML specification editor and co-chair, Karim Ratib, to introduce himself to the community.
Adrian has completed the specification for which characters are allowed in IDs (issue #503): up to 256 ASCII characters, and no spaces or non-printable characters can be used. This ID system is designed to make it possible to use the internal IDs used by other applications (for example, MuseScore) in MNX documents.
We spent a bit of time discussing the default file extension for MNX documents, and whether we would need an OCF-style container for MNX, per discussion #416. Our current thinking is that we probably do not need a container, so we propose that MNX documents should have the file extension .mnx.json. Consuming applications can check the file extension, that the document parses as JSON successfully, and that it has a top-level mnx key.
The next meeting is the Community Group virtual meeting on Tuesday 17 March 2026. The next co-chairs’ meeting is scheduled for Tuesday 24 March 2026.
]]>Here is the meeting in local times for the meeting on March 5th, 2026 15:00 UTC. Both meetings go over the same agenda. Please attend whichever meeting works best for you. Here is a UTC to timezone converter if needed.
Subscribe with this link: https://www.w3.org/groups/cg/coga-community/calendar/export/ (opens in a new tab)
Meeting Agenda
Async Reminders and channels:
As time zones can change (e.g. daylight savings), please feel free to use one of these calendar holds

This calendar hold should automatically adjust to the correct time for your timezone. The zoom link is in the calendar invite.
Direct link to join the discord channel: https://discord.gg/8EtqXgEsTv. The zoom link is posted in the discord channel.
]]>Register for Zoom: https://us06web.zoom.us/meeting/register/wA0fFkgfTzOPmICdy7bl2w
]]>Karim has some ideas for changing the metadata and tools for working with them, so Daniel encouraged him to open issues for those things
The schema now has an official version number, and the version number is incremented with each revision; it started at 1 and is now at 4 already; issue #497 is thus addressed.
There has been some good discussion about measure indexes, measure numbers, and how you point at measures from other places within an MNX document (issue #447). The indexing part has now been nicely addressed: we previously used a 1-based index for referring to bar numbers. We discussed changing it to being 0-based, but instead we decided to use the measure ID. Multi-measure rests, the measure rhythmic position object, and system (part of the layout infrastructure) now all use IDs.
One remaining thing for measure numbers is the label (issue #501). There has been a spirited discussion about how to encode the label. We don’t yet have a really clear definition of what we’re trying to achieve: it could be more than simple numbers. A couple of suggestions have been made for how this should be encoded. Myke proposes that this is good enough for now, and that we punt issues concerning bar numbering for Broadway and other similar niche cases for the future, or encourage that community to make a proposal that we can include later on.
The next issue to consider is what constitutes a valid ID. We don’t currently provide any info beyond that it should be a string. Our original idea was a simple alphanumeric value, but Robert Patterson pointed out that it would be nice to save MuseScore’s internal ID, which contains other characters. Adrian will make a proposal for issue #503 for this. We briefly discussed whether the string should use only printable ASCII characters, and agreed this is probably sufficient.
The next co-chairs’ meeting is scheduled for Tuesday 10 March 2026.
]]>The mission of the Semantic 3D Content Accessibility Community Group is to enable accessibility for people with disabilities of 3D content (like: virtual worlds, XR/VR/AR/MR, video games, videos, animations, images, TV, Generative AI content, real-life and other 3D experiences) using an approach of a common semantic 3D data model and a related ecosystem.
We aim to research and define the format for a common semantic 3D data model with focus on accessibility. In addition, we plan to provide guidelines around its generation and usage for making different types of 3D content accessible. This group may publish Reports and this group may publish Specifications.
To give a very simple example, the semantic 3D content data model could include (among many other fields) names and locations of objects. If the data of names and locations is externalized then accessibility solutions would be able to access this data in different ways (like using spatial audio or accessing it as lists via a screen reader using different sorting and filtering criteria, etc.). By having these options, users with disabilities would have the agency to choose when, where and how they want to experience 3D scenes in a variety of highly personalized ways. Names and locations data is common to all 3D content so accessibility solutions could make all types of 3D content accessible in a decoupled way from the experience or even the media type they originate from. As a result, this decoupling could enable reuse of the same accessibility solutions across experiences and media types after their thorough testing with people with disabilities.
The group invites people with disabilities, assistive technology and accessibility solutions developers and researchers, 3D and XR content creators, 3D engines and tools developers, browsers developers, media players developers, technical writers, accessibility subject matter experts, Human Computer Interaction practitioners, media specialists, Artificial Intelligence specialists, software developers and solutions architects and anyone else wishing to collaborate and contribute towards realizing the mission of this Community Group.
For one example of a semantic 3D content data model with specific and special focus on accessibility that could be considered and developed along with other contributed alternatives see Semantic-XR (which is a follow up work to a presentation given at the 2019 W3C Workshop on Inclusive Design for Immersive Web Standards and part of a presentation planned for the 2026 W3C Workshop on Smart Voice Agents.
In order to join the group, you will need a W3C account. Please note, however, that W3C Membership is not required to join a Community Group.
This is a community initiative. This group was originally proposed on 2026-02-18 by Zohar Gan. The following people supported its creation: Kurt Cagle, Adam Sobieski, Borislav Iordanov, Zohar Gan, Peter Hulst, Haklae Kim, Marc Printz and Priyanka Dank. W3C’s hosting of this group does not imply endorsement of the activities.
The group must now choose a chair. Read more about how to get started in a new group and good practice for running a group.
We invite you to share news of this new group on social media and other channels.
If you believe that there is an issue with this group that requires the attention of the W3C staff, please email us at [email protected]
Thank you,
W3C Community Development Team
As AI systems increasingly determine what web content people see, there is no shared vocabulary, framework, or measurement approach for understanding how content becomes visible — or invisible — within AI discovery and response systems. Publishers, website developers, platform operators, agencies, AI system developers, and researchers lack common reference points for evaluating how content is discovered, understood, trusted, and surfaced by AI systems. The AI Visibility Lifecycle Community Group will provide a collaborative forum to explore these challenges, with the aim of developing shared vocabulary, measurement approaches, and best practices for understanding content visibility within AI discovery and response systems. The 11-Stage AI Visibility Lifecycle framework (DOI: 10.5281/zenodo.18460710) is intended to serve as a starting point for discussion within the group, but is not intended to constrain the group’s discussions or decisions about future deliverables.
In order to join the group, you will need a W3C account. Please note, however, that W3C Membership is not required to join a Community Group.
This is a community initiative. This group was originally proposed on 2026-02-10 by Bernard Lynch. The following people supported its creation: Kurt Cagle, Doğu Abaris, Bernard Lynch, Peter Hulst and Michael Caskey. W3C’s hosting of this group does not imply endorsement of the activities.
The group must now choose a chair. Read more about how to get started in a new group and good practice for running a group.
We invite you to share news of this new group on social media and other channels.
If you believe that there is an issue with this group that requires the attention of the W3C staff, please email us at [email protected]
Thank you,
W3C Community Development Team
The mission of the Context Graph Community Group is to develop specifications, vocabularies, and best practices for representing and resolving contextual misalignment between global knowledge representations (e.g., organizational knowledge bases, ontologies, policies, and shared data models) and local interpretation contexts (e.g., user intent, operational setting, execution constraints, or domain-specific framing) in decision systems and human–AI workflows.
Many decision and information systems implicitly assume that the shared knowledge model and the local context at the point of interaction are aligned. In practice, this alignment frequently fails: terms carry different meanings across organizational, temporal, or operational boundaries; assumptions embedded in global models do not hold locally; and key context required to interpret state, policy, or meaning is absent, unavailable, or ambiguous at the point of use. These failures are distinct from data quality or optimization problems—they represent a structural interoperability gap in how context is communicated, validated, and resolved across systems.
A Context Graph treats this gap as a first-class, interoperable artifact: a structured representation of the contextual prerequisites required for valid interpretation, their dependencies, and their resolution status. The Community Group will formalize (1) a core data model for expressing contextual prerequisites and resolution state, (2) a minimal vocabulary for describing common categories of contextual mismatch, and (3) optional protocol guidance for structured clarification and safe stopping conditions when required context cannot be resolved. The goal is to enable independent systems to detect contextual misalignment, request missing prerequisites, and converge on a locally valid interpretation before downstream computation or decision-making proceeds.
Primary activities: This group will develop one or more specifications for representing Context Graphs, including: (1) a core data model for contextual prerequisites and their dependencies, (2) vocabularies for expressing resolution status and common categories of global–local contextual mismatch, and (3) optional protocol guidance for structured clarification and safe stopping conditions when required context cannot be resolved. The group will also produce use cases, requirements, test vectors, and best-practice guidance for implementers in knowledge management, enterprise decision workflows, and human–machine / human–AI systems.
Who should participate: Practitioners and researchers in knowledge representation, semantic web technologies, ontology engineering, decision science, AI/ML systems integration, enterprise knowledge management, and human–computer interaction. Developers building systems where shared knowledge models must be interpreted across diverse operational contexts are especially encouraged to join.
Publication intent: This group intends to publish Community Group Reports, including specification-style documents and supporting notes (e.g., use cases, requirements, and implementation guidance).
In order to join the group, you will need a W3C account. Please note, however, that W3C Membership is not required to join a Community Group.
This is a community initiative. This group was originally proposed on 2026-02-23 by Ron Itelman. The following people supported its creation: Kurt Cagle, Holger Knublauch, Jason Koh, Ron Itelman, Connor Cantrell Connor Cantrell and Michael Caskey. W3C’s hosting of this group does not imply endorsement of the activities.
The group must now choose a chair. Read more about how to get started in a new group and good practice for running a group.
We invite you to share news of this new group on social media and other channels.
If you believe that there is an issue with this group that requires the attention of the W3C staff, please email us at [email protected]
Thank you,
W3C Community Development Team
The mission of the Universal Object & Resource Attestation (UORA) Community Group is to develop a vendor-neutral, decentralized protocol for the identity, state verification, and lifecycle tracking of physical assets. By bridging the gap between physical objects and digital identifiers, UORA enables every resource to function as a first-class citizen of the internet, fostering global trust, transparency, and interoperability across supply chains and industries.
Scope The group will focus on the technical specifications required to bind physical objects to the digital world using the W3C’s foundational standards for Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs).
Deliverables
Success Criteria
The Community Group will be considered successful when its core specifications are used by at least two independent, interoperable implementations to track physical assets across a multi-party supply chain.
Out of Scope
In order to join the group, you will need a W3C account. Please note, however, that W3C Membership is not required to join a Community Group.
This is a community initiative. This group was originally proposed on 2026-02-03 by Amir Hameed Mir. The following people supported its creation: Kurt Cagle, Amir Hameed Mir, Muezza Wani, Irtiqa Latif and Maimoona Bhat. W3C’s hosting of this group does not imply endorsement of the activities.
The group must now choose a chair. Read more about how to get started in a new group and good practice for running a group.
We invite you to share news of this new group on social media and other channels.
If you believe that there is an issue with this group that requires the attention of the W3C staff, please email us at [email protected]
Thank you,
W3C Community Development Team
The mission of the Context Graph Community Group is to develop specifications, vocabularies, and best practices for representing and resolving contextual misalignment between global knowledge representations (e.g., organizational knowledge bases, ontologies, policies, and shared data models) and local interpretation contexts (e.g., user intent, operational setting, execution constraints, or domain-specific framing) in decision systems and human–AI workflows.
Many decision and information systems implicitly assume that the shared knowledge model and the local context at the point of interaction are aligned. In practice, this alignment frequently fails: terms carry different meanings across organizational, temporal, or operational boundaries; assumptions embedded in global models do not hold locally; and key context required to interpret state, policy, or meaning is absent, unavailable, or ambiguous at the point of use. These failures are distinct from data quality or optimization problems—they represent a structural interoperability gap in how context is communicated, validated, and resolved across systems.
A Context Graph treats this gap as a first-class, interoperable artifact: a structured representation of the contextual prerequisites required for valid interpretation, their dependencies, and their resolution status. The Community Group will formalize (1) a core data model for expressing contextual prerequisites and resolution state, (2) a minimal vocabulary for describing common categories of contextual mismatch, and (3) optional protocol guidance for structured clarification and safe stopping conditions when required context cannot be resolved. The goal is to enable independent systems to detect contextual misalignment, request missing prerequisites, and converge on a locally valid interpretation before downstream computation or decision-making proceeds.
Primary activities: This group will develop one or more specifications for representing Context Graphs, including: (1) a core data model for contextual prerequisites and their dependencies, (2) vocabularies for expressing resolution status and common categories of global–local contextual mismatch, and (3) optional protocol guidance for structured clarification and safe stopping conditions when required context cannot be resolved. The group will also produce use cases, requirements, test vectors, and best-practice guidance for implementers in knowledge management, enterprise decision workflows, and human–machine / human–AI systems.
Who should participate: Practitioners and researchers in knowledge representation, semantic web technologies, ontology engineering, decision science, AI/ML systems integration, enterprise knowledge management, and human–computer interaction. Developers building systems where shared knowledge models must be interpreted across diverse operational contexts are especially encouraged to join.
Publication intent: This group intends to publish Community Group Reports, including specification-style documents and supporting notes (e.g., use cases, requirements, and implementation guidance).
You are invited to support the creation of this group. Once the group has a total of 5 supporters, it will be launched and people can join to begin work. In order to support the group, you will need a W3C account.
Once launched, the group will no longer be listed as “proposed”; it will be in the list of current groups.
If you believe that there is an issue with this group that requires the attention of the W3C staff, please send us email on [email protected]
Thank you,
W3C Community Development Team
Current knowledge representation systems suffer from massive duplication and fragmentation: the same knowledge (e.g., a Unicode character, mathematical symbol, or spatial concept) is duplicated across fonts, embeddings, accessibility metadata, and visual renderings. Redundant representations can create maintenance, performance, security, and licensing issues.
The PM-KR Community Group will develop a knowledge representation paradigm where knowledge is stored once as executable procedures (like font programs or mathematical formula definitions) and referenced via symlink-style composition, enabling both humans and AI systems to consume the same procedural source.
The group will study data models, execution semantics, conformance levels, and relationships with other W3C technologies (e.g., RDF, OWL, JSON-LD).
Note: This group is motivated by prior work on Knowledge3D, and that work may inform the group’s discussions. That work does not constrain the group’s discussions, nor will it be a deliverable of this group.
In order to join the group, you will need a W3C account. Please note, however, that W3C Membership is not required to join a Community Group.
This is a community initiative. This group was originally proposed on 2026-02-20 by Daniel Ramos. The following people supported its creation: Adam Sobieski, Milton Ponson, Nitin Pasumarthy, Jonathan DeRouchie, Hanna Abi Akl and Daniel Ramos. W3C’s hosting of this group does not imply endorsement of the activities.
The group must now choose a chair. Read more about how to get started in a new group and good practice for running a group.
We invite you to share news of this new group on social media and other channels.
If you believe that there is an issue with this group that requires the attention of the W3C staff, please email us at [email protected]
Thank you,
W3C Community Development Team