View source for Proposals for WoT WG work items

== Difference between Interest Groups and Working Groups ==

According to the [http://www.w3.org/Consortium/Process/ W3C Process]  the primary goal of an Interest Group is to bring together people who wish to evaluate potential Web technologies and policies. An Interest Group is a forum for the exchange of ideas. Working Groups typically produce deliverables (e.g., Recommendation Track technical reports, software, test suites, and reviews of the deliverables of other groups).  Interest Groups thus serve to prepare the ground for standardization of specifications in Working Groups by collecting use cases and requirements, building a shared vision and identifying when work is ready to move into the W3C Recommendation track. There are no IPR commitments for joining an Interest Group, but there are for joining a Working Group, due to W3C's desire to ensure that W3C Recommendations can be implemented on a royalty free basis.  For more details see the [http://www.w3.org/Consortium/Process/ W3C Process] and the [http://www.w3.org/Consortium/Patent-Policy/ W3C Patent Policy].

The Web of Things Interest Group is expected to spin off one or more Working Groups, and to provide suggestions for work items for rechartering existing Working Groups.  This is an enduring role for the Interest Group  as a forum for discussion, and for study of areas that are not yet mature enough to initiate standardization.

== Proposal Structure ==
In this page we collect proposals for work items of a potential upcoming Web of Things Working Group. The work items should be based on currently ongoing WoT technical landscape evaluation conducted in the WoT IG and answer the following questions:

* Objective / WoT Building Block
* Why is this needed?
* Why is this in scope of W3C?
* What are the risks of the proposal and what are mitigations?

As we achieve a rough consensus on each proposal, the aim is to move it into the [https://github.com/w3c/wot/blob/master/WG/charter.md draft Working Group charter] in Github. We can then refine that and decide when the draft charter is mature enough to propose to the W3C Management committee as a basis for W3C Advisory Committee Review.

== Proposals ==

'''See also [https://github.com/w3c/wot/blob/master/WG/wot-wg-items-ap.md Scoping and deliverables on Github]'''


Here are the current proposals. Please add your name if you support a particular work item

===[[Linked Data Vocabulary For Describing Data Models]]===

* '''Supporters''': Dave Raggett (W3C Staff), Louay Bassbouss (Fraunhofer), Soumya Kanti Datta (Institut Telecom), Danh Le Phuoc (Insight Centre for Data Analytics), Darko Anicic (Siemens), Sebastian Käbisch (Siemens), Victor Charpenay (?), Katsuyoshi Naka (Panasonic), Kazuo Kajimoto (Panasonic), Takuki Kamiya (Fujitsu), Ryuichi Matsukura (Fujitsu), Antoine Zimmermann (Université de Lyon), Maxime Lefrançois (?), Frank Reusch (RWE), Jasper Roes (TNO)

* '''Comments''':
** Siemens/Panasonic: Scoping should be clearly focused on horizontal vocabulary and should not go into vertical, domain-specific topics. Further, optimization in terms of serialization formats should be addressed resp. selecting existing efficient representation formats, furthermost to be feasible to implement for constrained devices.
** Dave Raggett: I agree with the restriction to horizontal metadata. The choice of schema language will impact serialization, especially for resource constrained devices. Serialization formats could be dealt with as a separate work item (see content types).


Objective / WoT Building Block
* A standard RDF vocabulary of terms for describing data models for use in generating scriptable objects for IoT services.
Why is this needed?
* Currently, there is no existing standard covering the full set of terms needed to define such models, which can be used to create scriptable objects on servers from microcontrollers to cloud-based server farms.
* When dealing with the physical world, we need better means to express relations in time (e.g. command time vs. execution time)
Why is this in scope of W3C?
* W3C has a long tradition of work on RDF and linked data vocabularies. 
What are the risks of the proposal and what are mitigations?
* Risk: The vocabulary would have limited value in the absence of bindings to protocols and IoT platforms
* Mitigation: Provide specifications and implementations of bindings to common protocols and IoT platforms

===[[Linked Data Vocabulary For Server Metadata]]===

* '''Supporters''': Dave Raggett (W3C Staff), Danh Le Phuoc (Insight Centre for Data Analytics), Yingwei Wang (Invited Expert), Sebastian Käbisch (Siemens), Darko Anicic (Siemens), Victor Charpenay (?), Antoine Zimmermann (Université de Lyon), Maxime Lefrançois (?)
* '''Comments''':
** Siemens + Panasonic: Scoping should be on communication information, i.e. how to establish connectivity with a thing as opposed to point 1, which focuses on how to interact with a thing. Again, efficient representation should be handled here
** Dave Raggett: I think we will need to cover communication and security metadata. The choice of schema language will impact serialization, especially for resource constrained devices. Serialization formats could be dealt with as a separate work item (see content types).

Objective / WoT Building Block
* A standard RDF vocabulary of terms for server metadata.
Why is this needed?
* Currently there is no standard vocabulary for this. It is needed to allow servers to interoperate given that different protocols are appropriate in different circumstances. 
What is this in scope of W3C?
* W3C has a long tradition of work on RDF and linked data vocabularies.
What are the risks of the proposal and what are mitigations?
* Risk: The proposal won't be useful if servers vary too much in which protocols they support, so that it is impractical to find compatible protocols for communicating between a given pair of servers.
* Risk: The proposal will have limited value if it can't be used on constrained devices, e.g. low cost IoT devices.
* Mitigation: Encourage adoption of common protocols for given circumstances, e.g. for constrained devices, and for the public Internet.  A fallback is to find a third server that can act as a go between. Another solution would be pluggable support for protocols as a means to upgrade servers, e.g. home hubs or cloud-based servers.

===[[Content Types for Serialisation of Thing Descriptions and Server Metadata as JSON-LD]]===

* '''Supporters''': Dave Raggett (W3C Staff), Louay Bassbouss (Fraunhofer), Soumya Kanti Datta (Institut Telecom), Danh Le Phuoc (Insight Centre for Data Analytics), Takuki Kamiya (Fujitsu), Antoine Zimmermann (Université de Lyon), Maxime Lefrançois (?)
* '''Comments''': 
** Siemens + Panasonic: To avoid the n+1-problem, we should rely on existing serialization forms to stay extensible while relying on established base of tools and developers. Therefore, the optimization for efficiency should be done in those groups and appear as recommended selection in the first two topics.
** Dave Raggett: The challenge is not only to reduce message size, but also to reduce the memory and processing requirements for handling messages. A further criterion is to pick formats that will be accepted by the broadest range of stake holders, including Web Developers. I assume we agree that further work is needed. For instance, when using JSON-LD on a low end device, it would be desirable to avoid having to make network requests to dereference the @context links. Moreover, it would be desirable to operate on the JSON structure rather than having to first translate to RDF triples and operate on those.  On more powerful devices like hubs or cloud based devices, operating on RDF triples is attractive as it enables tasks such as semantic discovery, service composition, causal reasoning and so forth.  When it comes to efficient encodings, we want to take advantage of the shared knowledge between the sender and receiver of messages. This for example allows us to encode names as short numbers, and avoid the need to include a symbol dictionary as part of the encoded message. The way the shared knowledge is represented will have a significant effect on the processing involved. The more complex the schema language, the more memory and CPU cycles will be needed. To enable the Web of Things to scale to resource constrained microcontrollers, we need to keep this simple. We should avoid assumptions that prevent efficient processing of message encodings.

Objective / WoT Building Block
* Whilst RDF provides a solid formal basis for data models and semantics, it hasn't been very popular amongst the web developer community. We need a lightweight syntax that web developers are comfortable with, has a simple mapping to RDF and is convenient for processing on resource constrained devices, i.e. the microcontrollers that power IoT devices. JSON-LD is promising, and enables the use of JSON which is widely used in the Web. The key value of JSON-LD is the means to  enable the use of short terms in place of RDF's URI's. A standard set of short names would enable compact implementations of servers for constrained devices. Note that the charter should avoid constraining the Working Group to use JSON-LD in case better alternatives are found.
Why is this needed?
* Currently there is no comparable standard, and IoT projects have tended to define their own serialisations.
Why is this in scope of W3C?
* Traditionally W3C standardises document formats as building blocks for Web applications
What are the risks of the proposal and what are mitigations?
* Risk: If the vocabulary defined for this content type expands, it may be difficult to support effectively on constrained devices.
* Risk: If a Link header is used in place of a distinct content type, such that implementations are required to down the linked resource, then this would make it difficult to support effectively on constrained devices.
* Mitigation: Demonstrate operation on constrained devices and justify why they are important to support

===[[Web of Things scripting API]]===

* '''Supporters''': Johannes Hund (Siemens), Daniel Lux (RWE), Louay Bassbouss (Fraunhofer), Soumya Kanti Datta (Institut Telecom), Claes Nilsson (Sony), Toru Kawaguchi (Panasonic), Kazuo Kajimoto, Takuki Kamiya (Panasonic), Ryuichi Matsukura (Fujitsu), Kazuaki Nimura (Fujitsu), Frank Reusch (RWE)
* '''Comments''':
** Siemens + Panasonic: API definitions are clearly an asset of W3C. A recommendation for an API has the potential to avoid situations that harm innovation such as the "browser wars" or the current situation on mobile devices.
The scope should cover an API spec independent of the programming language that is suitable for the major cases and extensible by vendors rather than aiming to support all possible cases (ref. "the extensible web manifesto").



Objective / WoT Building Block
* Abstract WoT API, which can be mapped to static and dynamic programming languages
* Provides means to expose things and to access things
* Based on a model that allows binding to protocols 
Why is this needed?
* Currently no protocol independent API for WoT interactions exists
* The API as abstraction layer is a keystone in preventing further fragmentation especially on the application side
* Allows commoditisation of servients
Why is this in scope of W3C?
* Traditionally W3C standardises APIs e.g. web socket API
What are the risks of the proposal and what are mitigations?
* Risk: Variations in detailed requirements across IoT platforms that make a cross platform API less attractive
* Risk: Acceptance of API without concrete mapping and implementations
* Mitigation: Provide specifications and sample code for concrete mappings into different scripting languages

===[[Bindings To Common Protocols]]===

* '''Supporters''': Dave Raggett (W3C Staff), Louay Bassbouss (Fraunhofer), Soumya Kanti Datta (Institut Telecom), Yingwei Wang (Invited Expert), Claes Nilsson (Sony), Antoine Zimmermann (Université de Lyon), Maxime Lefrançois (?)
* '''Comments''': 
** Siemens + Panasonic: W3C excels in defining models, payloads and APIs. The actual protocols are mainly driven by the respective consortia and standardization bodies. Therefore, a possible deliverable should be rather a model and a guideline on how to create a protocol binding rather than the binding itself, which might better be provided in the scope of the actual protocol definition. The inputs for this should be drawn from both the APIs and the thing description.
** Dave Raggett:  I think it is appropriate for W3C to defining protocol bindings, possible as a joint work item with the corresponding SDO responsible for that protocol. Essentially, we would be defining a messaging layer above the protocol, and that is definitely in scope for W3C work.

Objective / WoT Building Block
* Define a set of standard interactions based on a RESTful Architecture resp. messages for protocol bindings of the Web of Things data models
** (e.g. messages for registering and unregistering proxies, event notifications, property and metadata updates, action invocations and responses.)
* Map these messages to common protocols. The protocols should include commonly used protocols for constrained devices and Internet servers
** (e.g. HTTP, Web Sockets, CoAP, MQTT and XMPP)
Why is this needed?
* There are no current standards for this purpose. 
Why is this in scope of W3C?
* Web technology standards are what enables W3C to fulfil its mission to lead the Web to its full potential. In this case, the new standards would layer on top of existing transport protocols, and will be tightly coupled to the standards W3C that needs to develop for describing the data models for IoT services.
What are the risks of the proposal and what are mitigations?
* Risk: Limited deployment of bindings for particular protocols
* Mitigation: Provide open source implementations for common servers

===[[Uniform and Technology Independent Discovery]]===

* '''Supporters''': Louay Bassbouss (Fraunhofer), Soumya Kanti Datta (Institut Telecom), Claes Nilsson (Sony)
* '''Comments''': 
** Siemens + Panasonic: The discovery of things is a process that effects and is based on the description and the interaction resp. the API. So rather than having a separate track, this topic should be integrated in the respective topics.


* Objective / WoT Building Block
** Design and development of a technology independent discovery for Web of Things.
** Provide guidelines for binding to APIs and protocols for efficient interaction with things.
** Utilize an uniform catalog of descriptions (as defined in things description) for discovery of things and their metadata.
** Provide means of ranking the discovery results (when presented to end users or other M2M applications).

* Why is this needed?
** To realize the global vision of Web of Things, there must be mechanisms to discover resources, their capabilities and properties. Thus resource discovery becomes a fundamental requirement of any IoT platform. A gap analysis of current research directions and standardization efforts reveal:
*** There is no common catalogue to describe the resources, units and domains. Synonyms are also often not recognized. Therefore, searching for a resource using a synonym might not discover the resource.
*** The content of discovery result metadata, ranking of the discovered resources are not standardized.
*** There is a lack of uniform mechanism for resource discovery. As a result, interoperability among WoT/IoT platforms are not maintained.
*** There are no uniform guidelines about how to integrate adequate security mechanisms and access control functions into a discovery framework.
*** The semantic based discovery is not studied in depth yet.
There is no uniform and technology & protocol independent discovery mechanism available.

* Why is this in scope of W3C?
** W3C has a long tradition of creating standards related to web and others which can leverage existing web standards. In this particular case, W3C could take a lead in creating a discovery standard to be used in future WoT platforms, devices and services.

* What are the risks of the proposal and what are mitigations?
** Risk – Creation of a competing standard from another Standard Development Organization.
** Mitigation – Liaise with other SDOs to avoid creating competing standards. Instead provide interoperability methods.
** Risk – Developers might not be attracted to use it if the standard guideline are seemingly complex. This could be a potential risk for semantic based discovery as WoT/IoT developers find it difficult to grasp the concepts of ontology, domain rules, datasets and other related semantic web technologies.
** Mitigation – Provide sample source codes and tutorials highlighting the benefits and guiding the developers in using the proposed discovery standard.

===[[WoT Security and Security-Enabling APIs]]===

* '''Supporters''': Oliver Pfaff (Siemens), James Lynn (HP), Daniel Lux (RWE), Soumya Kanti Datta (Institut Telecom), Claes Nilsson (Sony), Frank Reusch (RWE)
* '''Comments''':
** Siemens + Panasonic: Also for this topic, it can hardly be separated from the API definition without risking to have fragmentation. A senseful approach should therefore be to have security as a cross-cutting topic and integrated into the respective topics.

Meant to be a portion of the Web of Things scripting API initiative

* Objective / WoT Building Block
** Client-side APIs that supports the integration/utilization of security and security-enabling functionality by utilizing a common client-side stack. Note that "client-side" refers to the client-side of the security resp. security-enabling functionality i.e. callers (WoT components) and callee (WoT components again) would benefit 

* Why is this needed?
** A appearant whitespot, see the SP landscape conclusion: developers have to either create code by themselves or re-use provider-proprietary libraries (the latter is further troubled by the fact that there are not yet widely accepted standards for doing authn and authz in WoT => this practice leads to silos) 

* Why is this in scope of W3C?
** Avoid silo'ed WoT solutions, facilitate (secured) interactions between WoT components of different vendors 

* What are the risks of the proposal and what are mitigations?
** Other consortia aiming at the same goal - communicate openly, double/triple-check for prior art, have a clean scope
** Lack of adaptation (paper->codebase) - communicate and demonstrate early on, invite/encourage contributions from developer communities such as Eclipse IoT

===[[Authorization for Things Discovery]]===

* '''Supporters''': Oliver Pfaff (Siemens), James Lynn (HP), Daniel Lux (RWE), Louay Bassbouss (Fraunhofer), Soumya Kanti Datta (Institut Telecom), Claes Nilsson (Sony)
* '''Comments''':
** Siemens + Panasonic: As mentioned, the discovery of things and especially the security aspects such as authorization needs to be integrated into the topics of thing description, communication metadata and the APIs. Proposal here would again be to rather have the topic integrated rather than an own track.


Meant to be a portion of/addendum to the Uniform and Technology Independent Discovery Mechanism initiative

* Objective / WoT Building Block
** Create (conceptual) blueprints displaying how the authorization trick for things discovery can be done-based on using/profiling primitives supplied by others e.g. IETF ACE
** Work with others e.g. IETF ACE in case extensions/adaptations of their deliverables are needed in order to do this trick in a sound way

* Why is this needed?
** Current discovery mechanisms (not meant to be limited to WoT) often reveal information at public endpoints => things information may get exposed to unwanted parties
** Current authorization mechanisms often assume a priori knowledge about callers => no straight-forward solution when no a priori knowledge can be assumed

* Why is this in scope of W3C?
** Avoid potential security/privacy breaches (Things Discovery information at/via public endpoints)
** Avoid silo'ed WoT solutions (vendor/domain-specific recipes of protecting that information)

* What are the risks of the proposal and what are mitigations?
** Other consortia aiming at the same goal - communicate openly, double/triple-check for prior art, have a clean scope
** Lack of underpinnings (primitives supplied by others e.g. IETF ACE do not match provide what is needed for this trick) - transparency, test-drive and communicate early on

===[[Things Metadata for Security and Security-Enabling]]===

* '''Supporters''': Oliver Pfaff (Siemens), James Lynn (HP), Daniel Lux (RWE), Soumya Kanti Datta (Institut Telecom)
* '''Comments''': 
** Siemens + Panasonic: As mentioned above, the topic on thing description should be very closely aligned with this topic, which is not a stand-alone topic but heavily intermingled with the thing description. It could again be better addressed in an cross-cutting way or in side of the thing description topic.

Meant to be a portion of/addendum to the metadata initiatives above

* Objective / WoT Building Block
** Define the security and security-enabling relevant subsections (as above) by which a thing describes itself (e.g. registration)
** Define the security and security-enabling relevant subsections (identifiers, attributes, affiliations, credentials) which are needed by others to interact with a thing

* Why is this needed?
** To augment the planned things metadata work items by the underpinnings needs to facilitate security and privacy
** Common standards do exist to describe the metadata (identifiers, attributes, affiliations, credentials) of human users e.g. the LDAP object classes inetOrgPerson, eduPerson etc. A widely accepted standard to do the same (=describe identifiers, attributes, affiliations, credentials of things in order to facilitate protected interactions) appears missing (some work exists that describes things as passive objects lacking coverage for the dimension of things as actors)

* Why is this in scope of W3C?
** Facilitate standards-based and protected interactions with things
** Avoid silo'ed WoT solutions (vendor/domain-specific recipes of protecting that information)

* What are the risks of the proposal and what are mitigations?
** Other consortia aiming at the same goal - communicate openly, double/triple-check for prior art, have a clean scope
** Lack of adaptation (paper->codebase) - communicate and demonstrate early on, invite/encourage contributions from developer communities such as Eclipse IoT 

----

Questions:

* The content types for serialization were addressed in the github doc. what is the objective and how would they be included here?
* How to address the topics on security and privacy? (WoT-specific topics and generic)