Re: Representative sample of industry protocols

Hi Robert,

Note that my comment was specifically related to interoperability using
plain-old JSON, as per Dominique's email I was responding to.

Know that there's some thing called "temp", or "t", or "temperature", or
"blargle", or whatever that can be set _is_ useful, but doesn't do a whole
lot for interoperability _unless_:

   - those specific terms are standardized (here be dragons), or
   - there's a semantic description available

My deeper point I guess is that this is actually fairly straightforward to
do. Transport the data in JSON (or whatever, depending on the
circumstances); and describe the data elsewhere to make it interoperable.

Regards,
David



On Wed, Oct 26, 2016 at 7:18 AM, Robert Gallas <gallas.robert@gmail.com>
wrote:

> [
>   {
>     "temp":24
>   }
> ]
>
>
> has meaning only if used together with protocol binding.
>
> [
>
>   {
>
>      "context" : "json-ld-uri",
>
>      "interaction": "set-property",
>
>      {
>         "temp":24
>      }
>
>    }
> ]
>
> has meaning as selfcontained message modeled using TD JSON-LD which can be
> sent via email as well.
>
> On Wed, Oct 26, 2016 at 1:00 PM, Dominique Guinard <dom@evrythng.com>
> wrote:
>
>> Just to clarfiy: absolutely with you David, we never meant to propose the
>> extension at the product level only, the product schema.org format was
>> just picked as an example. We meant to support *any* extension via JSON-LD.
>>
>> Dom
>>
>> On Wed, Oct 26, 2016 at 11:58 AM David Janes <davidjanes@davidjanes.com>
>> wrote:
>>
>>> 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
>>>
>>>
>>> --
>> --
>> 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
>>
>
>