W3C home > Mailing lists > Public > public-wot-ig@w3.org > May 2015

AW: [WoT IG] to converge on WoT architecture

From: Hund, Johannes <johannes.hund@siemens.com>
Date: Tue, 26 May 2015 09:03:23 +0000
To: "vlad@evrythng.com" <vlad@evrythng.com>
CC: "james.lynn@hp.com" <james.lynn@hp.com>, "dsr@w3.org" <dsr@w3.org>, "Heuer, Joerg" <Joerg.Heuer@siemens.com>, "public-wot-ig@w3.org" <public-wot-ig@w3.org>
Message-ID: <C271054E16F8474D9104E1146C767BF144F3F2@DEFTHW99EK1MSX.ww902.siemens.net>
Hi Vlad,

this is a very valuable discussion.

I do agree that the basic message should be in the lines of: “if you there is no compelling reason to use something else, you should use HTTP. If you have to use something else, then use these primitives to ensure it works semantically the same way.”

Finding a structure like the one you describe was exactly my intention for setting up the doc on github: https://github.com/w3c/wot/blob/master/TF-AP/Example_sketch.md

The baseline there is also that we’ll have a set of abstract descriptions for data structures resp. resources and their interactions as you point out below. Then we can have “primary” mappings – HTTP and JSON – and other mappings (e.g. XML/EXI for the data structures and e.g. CoAP for the protocols).

I was just aiming shorter with my sketch, only covering the TF-AP topics. However, I see it makes sense to have the TF-TD topics around data structures and semantics in the same document as you proposed.

An additional point I would like to add is to give a guideline on scripting APIs to expose (server-side) or interact (client-side) with a thing e.g. in webIDL. It’s is a pretty low-hanging fruit with the interactions and data structures defined, and will help to avoid the fragmentation we have on HTTP-serverside scripting nowadays as opposed to the client-side in a browser, where we have a very good developer experience (after several browser-wars).

So this could result to:

1. General model introduction ("concepts/terminology")

2. Describing the entities (sensors, actuators, actions, events) - models/schemas with what each field means (IETF term would be “media types”)

3. Describe the "interactions" (how to subscribe to an event, read a sensor, turn on a light, unlock a garage door) – message-level definition  of the dynamic payload sent over (“interface”)

4. Describe the semantic extensions: JSON-LD models etc.

5. Describe other extensions (extra security, privacy models, etc.)

6. Describe exactly how all this models (1-5) are mapped in HTTP/JSON

7. Methodology for how to map 1-5 to new, other data serializations and protocols (XML/EXI, CoAP, MQTT, etc.)

8. Guidelines on API definition: webIDL, Javascript examples etc.

@all: would such a structure be a common view?

How should we proceed here?

Would it make sense that Vlad and me would merge our inputs  and provide an IG-wide document based on the structure discussed here?

Best regards,


Von: Vlad Trifa [mailto:vlad@evrythng.com]
Gesendet: Samstag, 23. Mai 2015 10:28
An: Hund, Johannes
Cc: james.lynn@hp.com; Dave Raggett; Heuer, Joerg; public-wot-ig@w3.org
Betreff: Re: [WoT IG] to converge on WoT architecture

Hi Johannes,

I fully understand and agree with you, especially when it comes to device to device comms - no need to speak http to each other if they both speak something more optimized. And I also believe that a common data structure (easily mappable across several protocols) is definitely the cornerstone of this IG.

However, I'm strongly in favour for the HTTP/JSON encoding of that data structure to be the first/main/recommended one (when possible) because it sends the message: "Ideally, use this http/json model natively on your device if you can (e.g. a wifi-connected alarm clock), but if that doesn't make sense (e.g. battery-powered sensor), then here's the COAP equivalent which works exactly the same way and its great too."

So, the overall structure on the outcome here we should all agree, looks like this to me:

1. General model introduction ("concepts/terminology")

2. Describing the entities (sensors, actuators, actions, events) - json models/schemas with what each field means

3. Describe the "interactions" (how to subscribe to an event, read a sensor, turn on a light, unlock a garage door) - the dynamic payload sent over

4. Describe the semantic extensions: JSON-LD models etc.

5. Describe other extensions (extra security, privacy models, etc.)

6. Describe exactly how all this models (1-5) are mapped in CoAP

7. General methodology for how to map 1-5 to new, other protocols (MQTT, etc.)

Would you all agree with such a structure?

   On 22 May 2015, at 11:14, Hund, Johannes <johannes.hund@siemens.com<mailto:johannes.hund@siemens.com>> wrote:

   Hi Vlad,

   I do agree that it is a valid point to demand: everything (or rather every “Thing”) has to have a URI and follow a well-defined resource architecture including the media types and interfaces.

   But I do think the value point is not that this has to be HTTP/JSON only. The true value is that everything that is adhering to this agreed resource model and is connected on OSI layer 4+ is then interoperable.

   Following your example from the PDF: it’s nice and valid that you can connect them on the “Cream layer”, i.e. have some application somewhere on the web that gets notified from the cloud API of my light-switch vendor so that it can send a request to the cloud of my lamp vendor to switch it on.

   But I think it is aiming too short. What if the startup that runs the service gets out of business? Or changes TOS?

   We need Thing-to-Thing. I want my lightswitch to talk with my lamp. And it’s a fact that you cannot run HTTP on a low-footprint device. Running e.g. CoAP should not exclude it from adhering to the same model.

   Even if one of them speaks natively HTTP and the other  a non-HTTP protocol (let’s call it “Foo”), I know that it is adhering to the resource model (or the URI points to an entity representing the physical thing that does) and all I need is a dumb adapter Foo-to-HTTP (which needs to to nothing more than protocol translation) and  I can interoperate them. Same adaptor can enable my browser/smartphone/… to talk with it.

   So no problem with defining/designing for HTTP/JSON, but I would not restrict it to just that.

   IMO the key value is, as you mentioned, to have a consistent developer experience. This is not based in using HTTP, but in having a commonly used resource model. For that we have to show this essential model and how to map this very same resource model including media types (=data structures) and interactions also to other protocols.


   Von: Vlad Trifa [mailto:vlad@evrythng.com]
   Gesendet: Donnerstag, 21. Mai 2015 23:45
   An: Lynn, James (Fortify on Demand)
   Cc: Dave Raggett; Heuer, Joerg; public-wot-ig@w3.org<mailto:public-wot-ig@w3.org>
   Betreff: Re: [WoT IG] to converge on WoT architecture

   [tl;dr] I guess my previous mail could be summarised as follows ;)

      On 21 May 2015, at 22:28, Vlad Trifa <vlad@evrythng.com<mailto:vlad@evrythng.com>> wrote:

      Fair point Jim.

      I think the idea of "making them part of the Web of Things" is that somewhere between an app I write and the thing itself, there's a server that exposes data/services about that product in HTTP and thus makes it part of the Web of Things. It Web-enables that thing. A bottle of wine on its own isn't part of the Web of Things, unless it has an identifier on it, which you can use to query a Web server and read/write data about that bottle. But this server needs to do more than "just expose an HTML page about that thing"!!! Otherwise I could argue that Amazon is the biggest Web of Things server ever made! Indeed, there are pages about every thing there, from golf clubs to cars, and more - real things!! That obviously has nothing to do with the Web of Things, it's just the Web.

      Using this analogy, a Web cam with an IP address and a very limited HTML user interface (but no API I can use programmatically) isn't part of the Web of Things to me, it's just part of the Web. So the question really is this: do we consider the Web of Things as nothing more than the Web? Or is the WoT a little layer of cream on top of the Web that makes it more programmer friendly, or at least more physical-object-friendly??

      If I have an IP camera in my LAN so it has an IP address, but I need to install a vintage application that runs only on Windows to access that camera (because it speaks a horrible protocol from the 80's), can we really consider it part of the Web of Things? Definitely not to me. But if it does have a socket open on port 80 though... and a server listening there? Still not. And if it has a horrible HTTP API that I need 3 days to understand because it's everything but restful? Maybe... ?

      Putting an HTTP API server on the camera, on the router of my LAN, somewhere in the cloud, or even as a plugin in my chrome browser that translates my HTTP request my app is sending to "whatever the device speaks" is all we need to make it part of the Web of Things. That is what I meant by a "layer of cream", something that other machines could easily read, and something that a developer could easily use, which HTTP alone won't do.

      It feels that this definition is broad enough so that any thing can be part of the Web as long as there's something somewhere I can send HTTP requests to. But if I need to write an app that uses non-Web requests to it, and I - as a developer - need to learn and write that specific protocol in the app I'm writing for a particular device (e.g. bluetooth), then it feels that we're missing the point of the Web of Things. Without this line in the sand, I feel we're back to the place where I need to learn several non-web protocols to talk to several devices (and that place is the Internet of Things, ie. the world of today).

      My definition of the WoT is that as long as there's a Web URL somewhere I can send a JSON/HTTP request from a javascript app I'm writing (regardless of where that URL is hosted - all I need to know is that its a URL and I can talk HTTP to it), is a necessary (but not sufficient!) condition to be part of the Web of Things. And I believe without this strong requirement in place, then we're simply patching the status quo in the IoT world and "try to pull" various protocols in the same direction, as opposed to create a simple, universal, and truly Web-based ecosystem and do a great work to integrate other protocols into it (as we'll always need them).

      Would love to hear how you all think think/feel about these ideas! Agree, or definitely not?

         On 21 May 2015, at 19:58, Lynn, James (Fortify on Demand) <james.lynn@hp.com<mailto:james.lynn@hp.com>> wrote:


         I think there a lot of things that will not be servers but will be considered part of the WoT. I think many of these fall into the category of sensors or other data feeds that will be clients to a server. I believe some webcams may be an example a thing which is not a server and certain components of a home automation system may be client-only and yet have a presence on the web including an IP address and/or a URI.



         From: Vlad Trifa [mailto:vlad@evrythng.com]
         Sent: Tuesday, May 19, 2015 8:44 AM
         To: Dave Raggett
         Cc: Heuer, Joerg; public-wot-ig@w3.org<mailto:public-wot-ig@w3.org>
         Subject: Re: [WoT IG] to converge on WoT architecture


         How about simply "Web Thing"? Because the Web of Things is made of Things - Web Things. It seems simple enough to be useful & reusable.

         A Web Thing should automatically imply that it's a server, otherwise it's not accessible over the Web.

         What might be a useful term though is "Web Thing Client" or "Web of Things Client", which means it can access, read, and control other Web Things, but doesn't expose its services on the Web.

         This is what we've proposed in our proposal here: bit.ly/wot-label<http://bit.ly/wot-label> --> feedback very welcome!




         vlad trifa, phd ////

         co-founder, head of r&d + innovation

         m +44 750 888 2051 // w evrythng.com<http://evrythng.net/>

         t @vladounet /////// w vladtrifa.com<http://vladtrifa.com/>

            On 19 May 2015, at 11:52, Dave Raggett <dsr@w3.org<mailto:dsr@w3.org>> wrote:

               On 18 May 2015, at 19:42, Heuer, Joerg <Joerg.Heuer@siemens.com<mailto:Joerg.Heuer@siemens.com>> wrote:

               So I did the exercise to draft some architecture aspects from my view point and share

               a)      the attached slides showing those aspects (I assume they are not self explanatory yet, but for sure you have some associations ;-) and

               b)      the plantUML source code, so you can edit or augment the figures e.g. with an online editor e.g. [PlantText]

               In the webconf tomorrow I can give a brief introduction to the slides, but even more important we need to discuss if we can agree to take plantUML for joint editing of these views and understanding. It is my understanding that in parallel Johannes is conducting some experiments to integrate plantUML figure generation into github so we not have to share two documents as done for illustration above but can work on a single one.

               So please share your ideas on this.

            Thanks for sharing this with us.  Any particular reason why the term “wot servient” has been introduced here? For me, Web of Things Server is clearer — it is a web server that hosts things.

            My implementation work, and my look at microcontrollers suggests that a critical part of the architecture will be the metadata and the need to cleanly separate descriptions of things, security and communications related aspects.  One example is to cover the possibility that some servers will batch data and even multiplex data from different sensors.

            Best regards,


               Dave Raggett <dsr@w3.org<mailto:dsr@w3.org>>

Received on Tuesday, 26 May 2015 09:03:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:26:33 UTC