Web Machine Learning Community Group Charter (original) (raw)

• This Charter: https://webmachinelearning.github.io/charter/
• Previous Charter: n/a
• Start Date: 2018-10-11
• Last Modified: commits/master

Goals

Machine learning (ML), and especially its subset deep learning, are being successfully used in native platforms in advanced computationally-heavy areas such as image recognition, speech recognition, and natural language processing. Currently, the Web is unable to support advanced machine learning use cases in a performant manner due in part to lack of optimized low-level APIs for machine learning. This Community Group will develop Web APIs to enable the creation of machine learning web experiences that are embeddable in the Web of today, and enable progressive enhancement of existing web applications and frameworks. With these Web APIs, web developers can make interoperable content on all hardware platforms.

The mission of the Web Machine Learning Community Group (WebML CG) is to make Machine Learning a first-class web citizen by incubating and developing a dedicated low-level Web API for machine learning inference in the browser and in products using modern web engines. Following the precepts of the Extensible Web Manifesto, by exposing these low-level capabilities, high-level capabilities that are task-specific—such as vision and natural language processing using built-in models—could be explained and implemented in terms of the low-level capabilities that use custom models pre-trained and deployed by web developers. In other words, the low-level Web API allows high-level feature experimentation and iteration by web developers.

Currently, machine learning inference in the browser uses the WebGL graphics API with limited or no access to platform capabilities beneficial for ML such as CPU parallelism, general-purpose GPU, or dedicated ML hardware accelerators.

The proposed Web API aims to expose generic capabilities to the Web required to provide close-to-native machine learning performance in the browser. In addition to the performance benefits, inference in the browser as opposed to in the cloud enhances privacy, since input data such as locally sourced images or video streams stay within the browser's sandbox. Local processing also enables machine learning use cases that require low latency, such as object detection in immersive web experiences.

Scope of Work

Neural network inference

A Web API for neural network inference hardware acceleration that:

• Allow to construct a neural network computational graph by common building blocks, including constant values and base operations such as convolution, pooling, softmax, normalization, fully connected, activation, recurrent neural network (RNN) and long short-term memory (LSTM);
• Allow to compile the neural network to native optimized format for hardware execution;
• Allow to setup input from various sources on the Web, e.g. array buffers, media streams, schedule the asynchronous hardware execution, and retrieve the output when hardware execution completes.

The APIs in scope of this group will not be tied to any particular platform and will be implementable on top of existing major platform APIs, such as Android Neural Networks API, Windows DirectML, and macOS/iOS Metal Performance Shaders and Basic Neural Network Subroutines.

Each specification should detail all known security and privacy implications for implementers, Web authors, and end users.

Out of Scope

The scope is limited to development of interfaces that expose inference capabilities of the modern platforms beneficial or purpose-built for ML. Training capabilities are out of scope due to limited availability of respective platform APIs.

This Community Group will not define any hardware features or algorithms.

To avoid overlap with existing work, generic primitives used by traditional machine learning algorithms such as base linear algebra operations are out of scope. The WebGL and WebGPU shaders and WebAssembly SIMD are expected to address these requirements, see the Coordination section for details.

This Community Group does not attempt to mandate a specific neural network or Machine Learning model schema or format. Other groups are expected to address these requirements of this evolving area.

Deliverables

Specifications

Web Neural Network API

A dedicated API for neural network inference hardware acceleration

Non-Normative Reports

The group may produce other Community Group Reports within the scope of this charter but that are not Specifications, for instance use cases, requirements, or white papers.

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.

Coordination

Technical coordination with the following Groups is expected:

Web Machine Learning Working Group

The Web Machine Learning Working Group adopted for standardization the Web Neural Network API incubated in this Community Group. The work in this Community Group will happen in collaboration with this Working Group.

GPU for the Web Community Group

The GPU for the Web Community Group defines a Shading Language that may be used to implement traditional machine learning algorithms efficiently. The WebML Community Group should coordinate with this group to avoid overlap.

WebAssembly Community Group

The WebAssembly Community Group incubates a proposal for a 128-bit SIMD support in WebAssembly that can be used to implement traditional machine learning algorithms efficiently. The WebML Community Group should coordinate with this group to avoid overlap.

WebGL Community Group

The WebGL Working Group defines a WebGL API that supports the OpenGL ES Shading Language (GLSL). The GLSL can be used to implement traditional machine learning algorithms efficiently. Furthermore, this group incubates a proposal for a WebGL 2.0 Compute specification that aims to provide an efficient way to run general-purpose GPU (GPGPU) computing workloads such as machine learning algorithms in the WebGL context.

Web Real-Time Communications Working Group

The Web Real-Time Communications Working Group defines the MediaStream API that is one possible inference input data source. The WebML Community Group should coordinate with this group to ensure its future work considers Machine Learning use cases.

Audio Working Group

The Audio Working Group defines the Web Audio API that is one possible inference input data source. The WebML Community Group should coordinate with this group to ensure its future work considers Machine Learning use cases.

Devices and Sensors Working Group

The Devices and Sensors Working Group defines Sensor APIs that are possible inference input data sources. The WebML Community Group should coordinate with this group to ensure its future work considers Machine Learning use cases.

Immersive Web Working Group and Community Group

The Immersive Web Working Group and Community Group aim to bring high-performance Virtual Reality (VR) and Augmented Reality (AR) (collectively known as XR) to the open Web via APIs to interact with XR devices and sensors in browsers. Some of these use cases involve machine learning (e.g., object recognition), and so the WebML Community Group should coordinate with these groups to ensure its work considers XR use cases.

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.

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.

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

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 the 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. Participants announce their candidacies. Participants have 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.
2. Participants vote. Participants have 21 days to vote for a single candidate, but this period ends as soon as all participants have voted. The individual 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.

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.

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.