Re: [WoT IG] to converge on WoT architecture

Hi Vlad,

Thanks for the quick response. I am in my hotel room in Berlin and will shortly leave for dinner. Tomorrow I get to present on the web of things at the Media Web Symposium, organised by Fraunhofer FOKUS. My comments are inlined below:

> On 19 May 2015, at 18:32, Vlad Trifa <vlad@evrythng.com> wrote:
> 
>> The Web of Things goes well with the Internet of Things (one is built on the other) and both terms are well established.
> 
> Well, indeed...
> 
> that's why I proposed to call a Web Thing any "thing" (physical or virtual) that is part of the Web of Things. In other words, as long as I can access data/service of a Thing over the Web (from my browser, an app on my phone, or more generally any HTTP client I'm writing) - then it is a Web Thing. 
> 
> My personal website isn't a Web Thing. But if I extend the server it's hosted on so it can proxy other "Things" (and expose the payloads/models/formats we're trying to define), then it becomes a Web Thing, do you agree? 

Kind of.  I see web servers as hosting many “things”.  A web of things server, simply put, provides access to things.

> 
> HTTP first is because of the layered architecture of the Web. Where the "Web-enablement" happens (the HTTP server my Javascript app needs to send a request to in order to unlock my garage door) is transparent from a Web Thing Client perspective, so you could embedded an HTTP server directly on the device if you *really* want to, or simply on an intermediate server in the cloud which "hides the fact that it's actually talking with something else to device, like MQTT" - it just doesn't matter! I'll still be writing my app using high-level "Web" concepts (the WoT language we're trying to define)!
> 
> The point we're trying to make is that we propose HTTP, because it's what most "Web of Things developers" will use to build WoT apps. If I had to learn MQTT, CoAP, XMPP, plus a few more, to build IoT client apps (which is the case today), then we wouldn't need this working group in the first place. This is the major problem we're trying to solve I believe, no? 
> 
> More importantly, there's no point arguing whether we need CoAP, MQTT, and co: it's clear that we need them!!! But if I'm a front-end developer and can write a simple app only using HTTP, to control a bunch of physical devices (that might be connected using MQTT, COAP, or anything else) then that'd be sweet! And I don't even need to know which device speaks what because these are "encapsulated" behind Web Things (proxies that map them) and all I need to learn is the Web Things "standard"! And if that's the outcome of this work group, then I'll proudly say we've been successful!
> 
> 
> So, in short, I believe we're talking about the same thing and share the same vision, so we simply need to agree on a set of basic concepts that we can all take for granted and build upon. 
> 
> Does this all make sense? Anyone sharing these thoughts? Or disagreeing?

The essence we should agree on is:

  a.  web addresses (aka URIs or IRIs) identify things
  b.  these addresses can be used to access descriptions of things
  c.  these descriptions are in a standard yet extensible format that servers
       can use to create local proxies for things that scripts can interact with
  d.  we should simplify scripts by decoupling the underlying protocols,
       this also allows for highly scalable cloud based servers
  e.  these descriptions support discovery just like HTML and the LINK header
  f.  we need to cleanly model things, security and communications

The metadata needs to be flexible and extensible so that we can cover existing and future devices.  We get this by building on W3C’s Linked Data framework.  JSON-LD is attractive for this as it combines the simplicity of JSON with the expressive power of Linked Data. The Web of Things must work well with existing technologies like Bluetooth and IEEE 802.15.4. There are many approaches to discovery, e.g. mDNS, UPnP, bar codes, NFC, Bluetooth, registration with the cloud, descriptions of the relationships between things, and personal relationships as part of social networks.

I think we should approach communications metadata from the work that has already been done e.g. for Bluetooth and sensor networks, where devices spend most of their time powered down to prolong battery life.  There is a huge amount of work on security and resilience so we should build on that rather than re-inventing the wheel.

Best regards,

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