The charter can be revised with the consensus of the Community Group, and more details on this and the decision process for selecting Chairs, etc. are given below. Key considerations are:
- Overall goals
- Scope of work
- Deliverables and roadmap
- Dependencies and liaisons
The tools available to the group include a wiki, a blog, a mailing list and an IRC channel for chat. We may want to use GitHub for a repository of documents and for issue tracking.
The aim of the Web of Things Community Group (CG) is to accelerate the adoption of Web technologies as a basis for enabling services for the Internet of Things. In order to achieve this mission, the group will bring representatives of key stakeholders together to:
- Collect use cases as a basis for identifying requirements
- Develop materials describing an architecture for the Web of Things
- Review existing standards and their applicability
- Identify gaps where new standards would be appropriate
- Develop proposals for new standards as needed
- Identify opportunities for creating broader awareness of the Web of Things
- Engage with the developer community to gather implementation experience
- Initial analysis by the end of October 2013
- Draft proposals for new standards by the end of October 2014
- Revised proposals and charters for their standardization by end October 2015
Standardization should follow implementation experience and a consensus on core use cases. In some cases, proposals could be submitted to existing W3C Working Groups, and in others, new Working Groups could be proposed. The Community Group may find it appropriate to recommend work in other standards development organizations such as the IETF. Any work that is intended for use in W3C standards specifications will be subject to the Contributor License Agreement (CLA).
Scope of Work
This section sets out a brief overview of the areas of interest.
Physical Objects and Devices
These are sensors, actuators and physical objects with identifiers, e.g. bar codes or RFID. Devices may be battery operated and form part of low power sensor networks. There may be a variety of communication technologies involved, e.g. WiFi, power line networking, Bluetooth, ZigBee, NFC,and so forth. Devices may be behind IP Firewalls and Network Address Translation interfaces. Devices may be public, or private, e.g. personal health sensors.
These provide a virtual interface to physical objects and devices, hiding the details of how they are addressed and communicated with. This simplifies application development, and allows for optimization of power and communication.
These add logic to service objects as well as allowing for compositions of services.
These make use of services. A terminological question is whether services just provide data, or whether they can also provide a user interface as a pluggable component for building applications. We may want to come up with a name for such components.
Provide a basis for connecting providers and consumers of services and applications.
Given the very broad scope of the work, it will be important to agree on core use cases as a basis to focus attention on a manageable number of work items. Some considerations include:
- Push, pull, or streaming models for data
- Static vs rapidly changing data
- Geographically tagged data
- Metadata including identity, service descriptions, provenance, privacy policies and preferences, access control and licensing
- Security – understanding threats and how to counter them
- Scalability – allowing for large numbers of services, and for hotspots that can rapidly arise, and later fade away
- Requirements for open marketplaces, e.g. registration, payments, reviews, search and recommendations
- Requirements for management, accounting and performance monitoring
- Emerging practices for interface design, e.g. JSON-LD and DOM Futures
Licensing terms are important when it comes to consuming and composing services. This may include the use of sticky policies that are attached to data. It will be important to acknowledge and reference where possible existing, well proven technologies. Distributed, federated approaches are likely to be needed, placing computation where it best provides for scalability and performance. Some services will run in the cloud, whilst others run locally as part of applications on a user’s device (e.g. a Web browser on a smart phone).
Dependencies or Liaisons
The following is an initial list of projects with an interest in the Web of Things:
- Compose project — Enabling open markets of services based upon the Internet of Things
- Webinos project — open source extension to the web platform to enable apps and services to be used and shared consistently and securely over a broad spectrum of converged and connected devices, including mobile, PC, home media (TV) and in-car units. The main innovation is the role of Personal Zones for securing personal devices and services. This has been applied to heart monitors, and to services based around arduino and raspberryPi.
- iCore — Core initiative addresses two key issues in the context of the Internet of Things (IoT), namely how to abstract the technological heterogeneity that derives from the vast amounts of heterogeneous objects, while enhancing reliability and how to consider the views of different users/stakeholders (owners of objects & communication means) for ensuring proper application provision, business integrity and, therefore, maximize exploitation opportunities. The iCore proposed solution is a cognitive framework comprising three levels of functionality,reusable for various and diverse applications. The levels under consideration are virtual objects(VOs), composite virtual objects (CVOs) and functional blocks for representing the user/stakeholder perspectives.
- IoTest Project — Focusing on composition/orchestration of services, self-managing components for auto-configuration and testing, abstraction of underlying technologies. IoTest will develop a test-driven service creation environment (SCE) for Internet of Things enabled business services.
- Semantic Sensor Networks Community Group — Continues the work of the Semantic Sensor Networks Incubator Group (the SSN-XG) in defining and using ontologies and mappings for querying, managing and understanding sensors, sensor networks and observations. This community group will also serve as a community and access point for ontologies (such as the group’s SSN ontology) and technologies developed for semantic sensor networks. See SSN-XG Final Report.
As work proceeds, we expect to identify additional groups, including existing Standards Working Groups with deliverables relevant to the goals of this charter.
Community and Business Group Process
Anything in this charter that conflicts with requirements of the Community and Business Group Process is void.
Choosing a Chair
This group chooses their Chair(s) and can replace the Chair(s) at any time using whatever means they prefer. However, if 5 participants – no two from the same organization – 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 organization – 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.
This group will seek to make decisions when there is consensus. When the group discusses an issue on the mailing list and there is a call from the group for assessing consensus, after due consideration of different opinions, the Chair should record a decision and any objections.
Participants may call for an online vote if they feel the Chair has not accurately determined the consensus of the group or if the Chair refuses to assess consensus. The call for a vote must specify the duration of the vote which must be at least 7 days and should be no more than 14 days. The Chair must start the vote within 7 days of the request. The decision will be based on the majority of the ballots cast.
It is the Chair’s responsibility to ensure that the decision process is fair, respects the consensus of the CG, and does not unreasonably favor or discriminate against any group participant or their employer.
The group will conduct all of its technical work on its public mailing list.. Any decisions reached at any meeting are tentative and must be confirmed on the mail list.
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.