Re: Representative sample of industry protocols

[
  {
    "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
>