Re: Representative sample of industry protocols

I agree with Dominique that (paraphrasing) use JSON and then add semantics
via JSON-LD describing that JSON. However, EVRYTHNG's proposed semantic
extensions are (currently) at the "product level" rather than the actuator
/ sensor level.

https://www.w3.org/Submission/2015/SUBM-wot-model-20150824/#
semantic-extensions

{
    "name": "Beaglebone Black",
    "description": "A Beaglebone Black embedded device",
    "productID" : "asin:B00CO3MZCW",
    "manufacturer" : "Beagleboard", ...
}

What one really needs for interoperability is JSON-LD to describe the data
e.g. here

https://www.w3.org/Submission/2015/SUBM-wot-model-20150824/#
update-a-specific-property

[
  {
    "temp":24
  }
]

What does "temp" mean - is it celsius, fahrenheit, is it ranged, what is
its precision and so forth?

The beautiful thing about JSON-LD is that we can keep ad-hoc JSON as the
payload (that is, we don't have to standardize the word "temp") but still
have an exact model of how this works.

This slideshare outlines a way this could be done:

http://www.slideshare.net/dpjanes/semantic-and-the-internet-of-things

Or if something like this in JSON-LD (which if you squint a little could
probably drop on top of EVRYTHNG's proposed semantic extensions)

https://github.com/dpjanes/homestar-smartthings/blob/master/models/smart-things-temperature/model.json

Regards,
David



Regards, etc...


On Wed, Oct 26, 2016 at 6:19 AM, Dominique Guinard <dom@evrythng.com> wrote:

> Hi,
>
> I think one way would indeed be to prioritize the work on HTTP and
> Websockets as we were suggesting in the Web Thing model (
> http://model.webofthings.io): HTTP because it is simply the ubiquitous
> protocol of the Web, Websocket because it represents a way to deal with the
> event-driven real-world supported by a very large number of clients (and
> servers). We use Websocket to that aim for years now, we also use MQTT over
> Websocket which is pretty easy to achieve and can happen all in the browser
> (as both protocols use TCP). In terms of understanding the content of WS
> frames there is a standard way of doing so using the Websocket subprotocol
> field (see https://www.iana.org/assignments/websocket/websocket.xml).
>
> Then of course JSON is the interop data format on the Web with the ability
> through content-negotiation to use a binary protocol (e.g., messagepack,
> etc.) and the open door to the Semantic Web via  JSON-LD extensions (
> https://www.w3.org/Submission/2015/SUBM-wot-model-20150824/#semantic-
> extensions) but I would not make it mandatory: there is a lot of
> interoperability value in supporting plain old JSON with a basic agreed
> upon model.
>
> I think this a trend you can observe in many places. Back 10 years ago not
> that many Things protocols were considering the Internet, let alone the
> Web. Today however things have changed. Weave is building on HTTP and JSON,
> homekit likewise, EnOcean support HTTP at the gateway level, Bluetooth has
> a GATT REST API and even Bacnet apparently will support RESTful services:
> the IoT is finally getting on the Internet and Web protocols seems to be
> the place where the convergence happens defacto, creating a uniform
> application layer. However, the semantics of interactions, resources and
> payloads structure is not uniform yet. This to me is the Web of Things and
> where this group should contribute.
>
> As a side note: the role of HTTP/2 in the IoT for me is also important to
> call out: and HTTP/2 will be much more suitable for embedded devices
> brining some of the goodness of protocols like CoAP and MQTT to a larger
> Web: header compression, binary protocol, serverpush, multiplexing (see
> e.g., http://webofthings.org/2015/10/25/http2-for-internet-of-things-1/).
>
> Dom
>
>
> On Wed, Oct 26, 2016 at 9:50 AM Dave Raggett <dsr@w3.org> wrote:
>
>> Hi Ben,
>>
>>
>>
>> I am hearing strong agreement about the value of HTTP as a very popular
>> Internet protocol, but not so much about the impact of different
>> application domain requirements on the communication patterns. HTTP itself
>> can be used in many different ways, and this can lead to interoperability
>> challenges. It thus makes sense to identify design patterns for common sets
>> of requirements based upon an agreed set of use cases. We can then define
>> the metadata vocabulary for declaring how a particular platform is using
>> the protocol, as a means to enable interoperability. The Interest Group has
>> already done quite a bit of work on this, albeit on a restricted set of use
>> cases.
>>
>> Whilst we can prioritize work on HTTP, we shouldn’t preclude work on
>> other protocols, as according to the level of interest amongst the group
>> participants. The Interest Group, for instance, has worked on CoAP.
>>
>> In respect to WebSockets, people tend to roll their own (proprietary)
>> protocol using JSON messages. Interoperability would require work on
>> standards for these messages. This seems like something that needs further
>> incubation to ensure the appropriate level of critical review.
>>
>> p.s. this is of course just my personal opinion.
>>
>> —
>>    Dave Raggett <dsr@w3.org>
>>
>>
>>
>> --
> --
> Dominique Guinard, Ph.D. ////
> co-founder & chief technology officer
> +44 79 5153 2987 // w evrythng.com
> t @domguinard // w guinard.org
> b webofthings.org
>
> About EVRYTHNG: http://bit.ly/smarterIoT
> Book: Building the Web of Things: http://bit.ly/wotbook
> Bloomberg Innovation Leader 2016: http://bit.ly/1OHR7k7
> RedHerring Top 100 2016: http://bit.ly/1WbIF4t
> 10-billion Products Born Digital: http://bit.ly/1SUHiSN
>