New IG Charter Deliverable Topics

[mmccool]

Include some or all of the following topics as potential deliverables for the new IG charter (from the Bundang F2F):

IG: Incubation of existing concepts, Exploration of new Concepts
IG: Communication patterns
Protocol Bindings
SubProtocols (long-poll, streaming, multi-part, SSE, Webhooks)
Default protocol binding for convergence
IG: WebSocket Subprotocol for WoT (maybe IETF collaboration)
Mozilla proposal
Panasonic proposal for Events
IG: System Things
Local hardware API based on Thing abstraction
Discovery („local“ filter)
Driver model for servients
Vocabulary
Payments
Marketing
Optional ontologies
Accessibility
New Interaction Types?
Thing Directory
Lifecycle Management & Servient I/Fs
Schemas for binary payload formats
Security Guidelines?
Maintenance
Binding Templates
Security vocabulary

Grow W3C WoT ecosystem
Multi-stakeholder demo
Semantic capabilities
Other services (calendars etc.)
Vertical focus (interop, openness, …)
Smart Buildings
Smart Cities
Collaborations
iot.schema.org
Linked Building Data Community Group
BRICK
Haystack
Echonet Consortium
ETSI CIM
IIC
Eclipse IoT (Smarthome, Vorto)

See https://www.w3.org/WoT/IG/wiki/images/8/86/W3C_WoT_Bundang2018_Rechartering.pptx

[mkovatsc]

I updated the draft rendered at https://w3c.github.io/wot/charters/wot-ig-2019.html

There was a lot of outdated text, so I made a number of editorial changes (taking into account there now exists a working group and WG Editors' Drafts.

Scope

Considering the scope I included the following items besides the general support WG and explore scope, which is actually unchanged (see summary box):

Initial items

• exploring use cases and requirements for concrete consumer, industrial, and smart cities application scenarios
• simplified APIs for application developers
• hypermedia concepts for complex Actions and Events that have a lifecycle on their own

Mid term

• evaluate (relatively) new semantic technology features (e.g., JSON-LD 1.1 framing, graph data workshop outcome)
• WoT infrastructure services (such as Thing Directory and proxies)
• overall secure Thing lifecycle management including management interfaces for systems hosting Things

Long term

• TD Profiles for enhanced interoperability
• same (transfer to the W3C Recommendation Track)

Deliverables

• WoT Use Cases and Requirements
• WoT API Considerations (better title?)
• WoT Hypermedia-driven Interactions

[mlagally]

Oracle reviewed the proposed charter and suggests the following modifications:

Modifications:

• adding "environmental" and "energy management" to the scenarios
• moving profiles to the mid terms objectives
• adding a profile specification to the normative deliverables
• 2 additional external organisations:
  -- OMA SpecWorks
  -- ETSI

I created a PR with the these changes for the IG charter at:
#615

[benfrancis]

From the re-chartering discussion at TPAC it was my understanding that both the Interest Group and Working Group would be seeking a six month extension to their existing charters, so this new 2.5 year charter proposal for the Interest Group has come as a bit of a surprise. Sorry if I misunderstood.

I'd like to understand more about the "WoT Simple API" and "WoT Hypermedia-driven Interactions" deliverables.

Two areas that have already been identified as critical by the WoT WG are simplified APIs for application developers,

By "API", does this mean a JavaScript API, or a "concrete protocol binding" (e.g. a standard REST API and/or a WebSocket sub-protocol)? I'm hoping it's the latter, which is something Mozilla would like to contribute to. Should this be more explicit?

hypermedia concepts for complex Actions and Events that have a lifecycle on their own (e.g., Properties about the progress of a running Action or an Action to cancel a running or queued Action).

I wouldn't describe these as "Properties of an Action" or use an "Action to cancel an Action" as in the example given, but I agree that if a Thing Description provides declarative protocol bindings then it needs to be able to describe more complex API concepts like creating and deleting new resources (e.g. to describe an action request queue).

Is it possible that the "WoT Simple API" and "WoT Hypermedia-driven Interactions" could be exploring two different approaches for achieving the same thing? One using concrete protocol bindings, the other using declarative protocol bindings.

One topic will be the creation of Thing Description Profiles, constraining the set of TD features and extensions, to enhance interoperability within a certain application domain, for instance, a vendor-neutral Web platform for apps that are installed on home gateways, or usage as technology-neutral asset administration shell for Industry 4.0.

This all seems a bit nebulous. "vendor-neutral Web platform for apps that are installed on home gateways" sounds suspiciously like standardising an application runtime, which I would advise against. And FWIW I'm not sure if the term "Industry 4.0" means much to anyone outside Germany.

One other minor point. From the Introduction:

The Internet of Things (IoT) suffers from a lack of interoperability across platforms. As a result developers are faced with data silos, high integration and maintenance costs, and limited market potential. This can be likened to the situation before the Internet, when there were competing non-interoperable networking technologies. The Internet makes it easy to develop networked applications independently of those technologies. The W3C is seeking to do the same for the Internet of Things with the Web of Things.

The Internet of Things already exists. A better analogy here would be that the current Internet of Things is like the Internet before the World Wide Web, with competing incompatible hypertext systems. The W3C is applying lessons learned from the World Wide Web to the Internet of Things to create the Web of Things.

[draggett]

@benfrancis wrote:

I'd like to understand more about the "WoT Simple API" and "WoT Hypermedia-driven Interactions" deliverables.

The Simple API refers to the idea of a simple JavaScript API in which thing properties and actions are exposed as JavaScript object properties and methods. This is only applicable for programming languages with direct support for getters and setters, and entails the use of events to signal asynchronous updates, errors and loss of connectivity. Read and writes are synchronous and quick as is the case for regular JavaScript properties. The local platform could synchronously detect when an assigned value conflicts with the declarations in the thing description, and raise an exception. A client-side script could assign a value to a thing's property and later get an event that this update was rejected by the server for some reason.

We had a discussion on this during TPAC and I proposed that this could be layered on top of the existing API and agreed to take this on as part of the incubation work in the WoT IG. This falls under the mantra that it is easy to make something complicated and much harder to make it simple.

[mmccool]

Note that these are IG topics, and so are meant to be experimental, and may or may not lead to RECs in the long run, and then only if they are promoted to WG deliverables. IG charter deliverables will be generally published as W3C Notes.

We need to finalize this, in particular, need to decide whether or not to merge Oracle's PR. As mentioned under that PR, I am willing to merge unless someone comments otherwise. The merge is overdue though, and since there have not been any further comments on Oracle's PR, I am going to merge it and submit the updated version to W3M.

[mmccool]

@benfrancis Note the WG extension (no new charter...) is for 6mos (to finish the current deliverables), this IG rechartering is for 30mos, to align with an expected later WG rechartering of 24mos (with a new charter and new deliverables, but those are still to be discussed and agreed upon).

[mmccool]

I talked with Kaz about this just now and we are basically out of time. However, there is a still a month's long process before the new IG charter is confirmed, during which there is an opportunity for comments and edits. So we are going to go ahead and submit what we have to W3M and use the formal process for further comments and edits.

[ashimura]

@benfrancis to be clear, I'd like to continue some more detailed discussion with you offline, e.g., on the WoT IG Chairs list. Is that OK?

[mkovatsc]

Please see #761 for the updated IG charter

[egekorkan]

Latest charter here: http://w3c.github.io/wot/charters/wot-ig-2019.html