Relation to REST APIs and W3C Web of Things activities

[ClaesNilsson]

There are ongoing activities in the W3C Web of Things Interest Group. A starting point for an architecture is described in Dave Raggett's An introduction to
Web of Things Framework and a proposal for abstract interactions for APIs and Protocol bindings is here.

It is proposed that the DAP work on a generic sensor APi is made in cooperation with the work in the W3C Web of Things Interest Group on architecture, REST APIs/scripting mappings , protocol bindings, discovery, security, etc.

Actions:

• update the WoT IG about the first publication of the Generic Sensor
  API ED through their mailing list.
• rewrite some of the example sketches found on the WoT's GitHub
  repository using the Generic Sensor API and send them through GitHub
  pull requests.
• have follow-up conversations on the topic, probably through the WoT
  IG's mailing list or on this issue tracker.

[tobie]

Thanks a lot for bringing that up, @ClaesNilsson. Looking in particular at the primitives of the proposal you link to and the related JS examples, it's obvious that there is a lot in common. I'd even venture to say that the this proposal could be re-written as a subclass of the Generic Sensor API (by simply subclassing the Sensor constructor).

I'm however curious as to what kind of connections to the server you're planning to support? Can you let me know more (or point me in the right direction)? Thanks!

[ClaesNilsson]

Thanks Tobie. Regarding your question on kind of connections to the server I am not sure on how to answer that. The examples in Example Scriting API Mappings include server side examples. In addition, a WoT entity could have both the roles of a server and a client and the term "servient" is used.
I will send an email on the WoT IG mailing list with a pointer to discussion here to give other WoT IG particpants chance to comment as well.

[h0ru5]

@tobie Not sure I understood the question, but the overall plan is to have language and protocol agnostic primitives and map them into concrete APIs and protocol bindings, thus enabling a familiar developer experience for cross-platform and cross-domain applications. Since this is web technology, the first examples are of course Javascript, HTTP and JSON. But for example by mapping he very same primitives onto C/C++, CoAP and EXI, we also want to support for example embedded devices/sensors.

[tobie]

Thanks, @ClaesNilsson and @h0ru5.

Are my right in assuming that the intersection of both of the WoT work and the Generic Sensor proposal are how remote sensors/things would be exposed in a Web page?

[h0ru5]

Yes, exposure of a remote thing or sensor e.g. for a browser (same should be used for Thing2Thing), will be an intersection. But IMO we also should consider reusing resp. taking input from the proposal for the APIs for scripts on a WoT device, e.g. to access the device's sensors.

[tobie]

But IMO we also should consider reusing resp. taking input from the proposal for the APIs for scripts on a WoT device, e.g. to access the device's sensors.

The purpose of the Generic Sensor API we're working on here is to devise a superclass and blueprint for concrete sensors to derive from. It seems that sensors accessed through HTTP are a perfect example of such a concrete sensor, or at least of a subclass of an abstract sensor constructor.

Now, there's a bunch of things I'm not sure I understand in your proposal yet. A few questions come to mind:

• Why expose both RPC (doAction) and REST-like (get, set) models (especially given the examples used for RPC seem to only do state changes)?
• Are "things" much more than sensors?
• If so, are they much less than servers?
• Is a native JS API worth building, or is it just sugar for a combination of WebSockets and fetch?
• How much of the actual capacities of the "thing" is know beforehand vs. shared as part of the initial handshake that still needs to be defined by the task force?

[mwichmann]

From my perspective (coming from working on IoT stuff elsewhere), things are more than sensors, sometimes much more (a "thing" is abstract, it may be dedicated like a sensor, switch, or lightbulb, or it may be a software stack on something quite general purpose); they are conceptually servers although they may be quite limited in capability; and we should not ever have to know capabilities of things beforehand, there should be a resource discovery process to find out about them. Nothing in the Raggett notes seems to require differently, afaict.

[rwaldron]

Generic Sensor API and Web of Things specs are completely orthogonal. A Sensor.* instance only emits events containing values that correspond to the most recent reading of that instance, for that sensor. Once the sensor instance's value is reported, whatever is done with that value is irrelevant to the sensor instance.

[draggett]

rwaldron's claim that "Generic Sensor API and Web of Things specs are completely orthogonal" suggests a bunch of unstated assumptions that I would like to hear, especially in relation to the use cases that motivate them. For instance, is there an assumption that the generic sensor API isn't intended for continuous data, e.g. from a heart ECG monitor? What assumptions are there in relation to sensor metadata, e.g. the location and owner of a sensor? The Web of Things needs to allow for a wide range of devices and contexts, and as such, is likely to be more flexible than a sensor API designed for a narrower set of assumptions. This is why clarifying the target use cases and assumptions is critical.

[rwaldron]

For instance, is there an assumption that the generic sensor API isn't intended for continuous data, e.g. from a heart ECG monitor?

No, it's intended precisely for continuous data. The problem with this example is that a generic sensor api that ships in a browser can't possibly know about all heart ECG monitors, and furthermore can't possibly know how to handle the data that comes from them.

The primary goal of the first version of the Sensor API is to cleanup access to built-in sensors, eg.

• Accelerometer
• Ambient Light
• Battery
• Compass
• GPS/Geolocation
• Gyro
• Proximity
• Temperature

These are sensors that currently have disparate APIs, this is the problem we are trying to solve. Simultaneously, we're designing towards the future: @tobie and I want to make it such that non-built-in sensors, eg. data via WebSocket (and other various transport protocols), Stream, Serial, BLE, etc. can be "plugged in" to new Sensor({ ... }) (or whatever it's eventually called).

[draggett]

Thanks for the list of built-in sensors. I can understand the idea of creating an API that scales to the needs of these particular sensors, but beyond that a more flexible approach would be appropriate.

For sensors delivering continuous data, it is likely that the history of that data is what the app will want to process (e.g. an ECG waveform), and the latest value won't be particularly important. The way that continuous data is delivered will vary from one sensor to another. For example, values at fixed intervals, or at timestamped points in time? You might get parameters describing a piecewise approximation to time changing values.

This makes it important to get access to metadata describing a particular sensor, or a set of sensors when data is streamed from multiple sensors. This calls for a flexible approach to representing metadata, and I am curious as to how you intend to support that.

The Web of Things starts with the discovery of a URI for a thing as a basis for accessing its metadata. The platform (e.g. server or browser library) can then use this to create a proxy object in the script's local execution environment, decoupling scripts from the underlying bindings to protocols and device drivers.

[rwaldron]

For sensors delivering continuous data, it is likely that the history of that data is what the app will want to process (e.g. an ECG waveform), and the latest value won't be particularly important.

Yes, we agree :)

The Generic Sensor API design does not preclude obtaining, storing and retransmitting the history of values read from a sensor.

[draggett]

But how do you intend to deal with the metadata? Do you intend to place the burden of buffering recent data all on the apps?

[rwaldron]

But how do you intend to deal with the metadata?

Can you be more specific? What metadata are you referring to? Can you give a concrete example?

Do you intend to place the burden of buffering recent data all on the apps?

We had considered batch value set reporting, but have deferred the feature until we see how the Sensor APIs are used in the wild.

[tobie]

Do you intend to place the burden of buffering recent data all on the apps?

We had considered batch value set reporting, but have deferred the feature until we see how the Sensor APIs are used in the wild.

More precisely, we're deferring how to handle this until we have a better understanding of the performance constraints, see #13.

But I'm not sure whether that's what @draggett was asking about.

[tobie]

Thinking about this more, I feel like remote sensors are good candidates for using the Generic Sensor API, but that not all "things" are. For example, I don't see how a lightbulb fits that category.

If IoT APIs were to rely on the Generic Sensor API it would need to devise similar primitives for other "things," (e.g. for actuators) which would mirror the Generic Sensor API.

With that model in mind, the initial metadata-carrying handshake serves to asynchronously determine what kind of "thing" we're communicating with and instantiate the appropriate object. Is it a remote thermometer? We'd instantiate a Sensor.Temperature instance and pass it the the URL or WebSocket connection it must rely on to stream data events. It's a lock? We create instead a new instance of Actuator.Lock. It's a new kind of pressure sensor the platform knows nothing about? That's OK too, the metadata tells us which library to load so as to manage the raw data and massage it into something more palatable, etc.

In summary, the Sensor object would be a low level object (inheriting from EventTarget) that reflects the change in value(s) of a sensor at regular time intervals. It could reflect the values of a sensor supported by the platform or of an unsupported one (in which case connection means and a process to make sense of the sensor's output would need to be provided e.g. a JS library of some sort). Sensors could be local or remote. In the latter case, a mean of connection would again need be passed to the sensor object.

Would such a low-level primitive fit your use cases and requirements?

[anssiko]

Adding @zolkis in the loop, who may be able to review and give feedback from the Web of Things point of view.

[tobie]

WoT IG invited me to come and present the Generic Sensor API work during their weekly call.

You can find the minutes online.

Very productive call which confirms the need to focus on primitives thinking in terms of the Extensible Web Manifesto.

This pushes us to consider the Sensor constructor as a very basic building block: an EventTarget which takes an input, or--paving the path for sensor fusion--multiple inputs, a processor (probably just a JS function) and some basic options (frequency, etc.).

In turn, this lets us move the spec forward whatever the results of the performance constraint research AND allows for future extensions of the spec in currently out of scope areas (sensor fusion, WoT, and low-level, raw sensors).

Next steps are:

1. advise the WoT IG about the first publication of the Generic Sensor
   API ED through their mailing list,
2. rewrite some of the example sketches found on the WoT's GitHub
   repository using the Generic Sensor API and send them through GitHub
   pull requests,
3. have follow-up conversations on the topic, probably through the WoT
   IG's mailing list or on this issue tracker.

[anssiko]

There seems to be an issue with the WoT IG minutes link above, so here it is: http://www.w3.org/2015/05/27-wot-ap-minutes.html#item02

[tobie]

Fixed. Thanks, @anssiko.

[tobie]

Updated the WoT IG on FPWD publication.

[tobie]

Closing this as I think it's best addressed F2F at TPAC.