Charter
This is the charter for the W3C Autonomous Agents on the Web (WebAgents) Community Group (CG).
Goals
This CG aims to investigate the design of a new class of Web-based Multi-Agent Systems (MAS) that:
- inherit the beneficial architectural properties of the Web (Internet-scalability,
evolvability, simplicity, etc.), - preserve the beneficial properties of MAS (adaptability, openness, robustness, etc.),
and - are human-centric (support transparency, usability, accountability, etc.).
We are especially interested in the use of Linked Data and Semantic Web standards for weaving a hypermedia fabric that mediates uniform interaction among heterogeneous entities: people, artificial agents, (low-power) devices, digital services, knowledge repositories, etc. — for this reason, we refer to this new class of Web-based MAS as Hypermedia MAS. This community group brings together experts actively contributing to advances in autonomous agents and MAS, the Web Architecture and the Web of Things, Semantic Web and Linked Data, and Web standards in general — as well as any other areas that could contribute to this approach for distributed intelligence on the Web.
In particular, the WebAgents CG aims to:
- Collect relevant background materials to support the transfer of knowledge across the various areas of expertise relevant to Hypermedia MAS.
- Collect use cases for Hypermedia MAS from the broader community.
- Collect references to relevant technologies and implementation experience from the broader community.
- Facilitate experimenting with Hypermedia MAS by collecting relevant tutorials, organizing hackathons and challenges, and promoting playgrounds for developers.
Scope of Work
To achieve its goals, the WebAgents CG pursues the following activities:
- Organizing events such as hackathons, plugfests, workshops, etc.
- Writing Community Group Reports on the findings of the CG.
- Curating online materials to help promote the work of the CG and to support experimenting with Hypermedia MAS.
- Creating liaisons with other groups at the W3C (Community, Interest, and/or Working Groups) that are relevant to the topics explored in this CG.
- Creating liaisons with the research community and the industry.
Out of Scope
Under this initial charter, the work of the WebAgents CG is in an exploratory phase — and the scope of the relevant topics also needs to reflect the interests of CG members.
The WebAgents CG aims to maintain its complementarity with other CGs. For instance, while many of the topics related to the overall objective of this CG draw from (Decentralized) AI research, its main focus is primarily on architectures for and the engineering of Hypermedia MAS. Other W3C groups might be better suited for other AI-related topics (e.g., see the Cognitive AI CG, the AI Knowledge Representation CG, or the Human-Centric AI CG). The WebAgents CG provides a unique forum for everyone interested to integrate these aspects for exploring and designing large-scale, open, long-lived, and decentralized Web-based systems of people and intelligent (artificial) agents.
Deliverables
Specifications
No specifications will be produced under the current charter.
Non-Normative Reports
The group may produce Community Group Reports under this charter that are not specifications — for instance, reports on use cases, requirements, and implementation experience.
Test Suites and Other Software
There are no concrete plans to create software or test suites under this charter. Instead, the current charter aims to collect references to relevant technologies and to facilitate experimenting with Hypermedia MAS.
Other Deliverables
The group may produce deliverables to promote the topics such as videos and podcasts, slide decks and teaching materials, tutorials, etc.
Dependencies or Liaisons
The WebAgents CG aims to coordinate with the Web of Things Working Group (WG) for use cases and applications of agent-based systems in the Web of Things.
Additional dependencies and liaisons are to be decided. Other groups that are relevant to the
topics of the WebAgents CG include the Solid CG, LDP Next CG, WebID CG, Federate Identity CG, Nostr CG, ODRL CG, Cognitive AI CG, AI Knowledge Representation CG, Human-centric AI CG, Web Authentication WG, and Verifiable Credentials WG.
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 repository 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).
- 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.
- 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.
