Re: Project Things by Mozilla and the Web Thing API

On 15 July 2017 at 14:32, Kovatsch, Matthias <matthias.kovatsch@siemens.com>
wrote:

> Thanks for keeping up the conversion so lively and helping us evaluating
> the current status.


Thank you for your patience with my potentially disruptive emails!


> I saw a few key discussion points on which I would like to comment to
> better understand our approach.
>
>
> > Is it not possible to have a core plain JSON vocabulary which can be
> extended
> > with semantic markup in JSON-LD? Rather than two separate encodings.
>
> JSON-LD puts a number of constraints onto the JSON structure to result in
> valid triples. To be able to make use of the existing tooling around Linked
> Data, triple stores, reasoning, etc., we must stick to valid JSON-LD in the
> way we do.
>
> Once the formal model is standardized -- the JSON-LD serialization comes
> basically for free here -- we are happy to look into a more human-friendly
> serializations in pure JSON. It simply entails more work on standardizing a
> new representation format, converters to Linked Data, test suite, IANA
> registration, etc. Yet, Dave has been working on this individually already,
> the IG now bumped up the priority on this, and your format could actually
> be a way forward here.
>
> I think we agree on the overall goal that the Thing Description is on the
> one hand machine-understandable, but on the other hand developer-friendly
> in the sense they are not confronted with any Semantic Web complexity.
>

In my view it is worth the effort and in fact more valuable to come up with
a plain JSON core description format that developers can use directly,
rather than spend a long time defining an abstract semantic model which can
be serialized in multiple formats. In our experience web developers care
much more about having a concrete tool they can directly apply to solving
problems than an abstract semantic ontology. It sounds like a core JSON
format with a simple extension mechanism via a "@context" tag is a possible
path forward here.


>
> In the Web, the browser with its standardized APIs plays a central role in
> realizing applications. The browser APIs, however, focus on interfacing
> with the user through a graphical UI / the DOM.
>
> Thing companies, e.g., device manufacturers and vendors, identified the
> need for a similar standardized runtime environment for IoT application,
> which is not focusing on UIs, but on device and automation logic. Our
> approach is also fundamentally different to the System Applications Working
> Group, as we define a very narrow Thing API more comparable to the
> XMLHttpRequest Object. So, at first it will be Thing companies implementing
> this on their devices; at some point, browser vendors might want join in to
> close the link between devices and UIs. Maybe you can relate to the
> struggle of releasing apps for the different smartphone ecosystems -- which
> is also solved through (UI-centric) Web technology.
>
> Overall, nobody is forced to use it. So why not simply accept that there
> are more than enough W3C Member organizations -- which are not limited to
> browser vendors anymore -- that agreed that they need this standard? Others
> can simply ignore it, no?
>

First of all, I think it's important that the W3C membership is not limited
to browser vendors. I see much of the innovation in the WoT being on the
server side rather than the client side of the web stack and device
manufacturers and vendors obviously bring invaluable expertise to the IoT
discussion.

But here is the challenge we have at Mozilla. We would like to be able to
point the web developer community towards the Web of Things Working Group
at the W3C and say "Here is how we can build a decentralized IoT by giving
things URLs on the web. Here is a (draft) standard Web Thing Description
format and a standard Web Thing REST + WebSockets API that you can conform
with in order to achieve interoperability".

Currently when someone looks at the deliverables of the working group the
first thing they probably see is the WoT Architecture Specification
<https://w3c.github.io/wot-architecture/>. This is hugely overcomplicated
and difficult to read, it talks about "servients", "protocol bindings" and
programming language agnostic "scripting APIs" and has lots of complicated
looking diagrams.

Next they see the Thing Description
<https://w3c.github.io/wot-thing-description> specification which describes
an abstract semantic model using RDF triples without any indication of how
you would actually interact with that Thing over the web.

Then they see the WoT Scripting API
<https://w3c.github.io/wot-scripting-api/> which seems to be trying to
define a standardised application runtime and a language-agnostic scripting
API which really has nothing to do with the web at all.

Giving Things URLs on the web need not be this complicated!

As I understand it Mozilla and Google both made formal objections to the
working group charter, saying that many of the deliverables lacked
sufficient incubation and that the focus should be on defining the core web
thing description format. In choosing to ignore this feedback and going
ahead with all of the above deliverables the working group has put us (and
others) in a difficult position.

I am trying to figure out whether it's possible for Mozilla to continue to
contribute towards the effort of defining the core Thing Description
format, without all of those other nascent and abstract deliverables being
a distraction. So far I see some hope of alignment on the description
format, but I see lots of examples of where the broader goals of an
encoding-agnostic semantic model, a protocol-agnostic interface and a
programming language-agnostic scripting API are putting unnecessary
constraints on that core effort which cause it to be overcomplicated and
risk delaying its delivery indefinitely.

We are left with the dilemma of whether to try to contribute to the working
group in its current form and try to demonstrate to web developers that the
Web of Things need not be as complicated as it may appear from the W3C, or
to start a separate effort under another standards body (or more likely an
informal community group at the W3C) with like-minded organisations who
would like to work on a more concrete and pragmatic specification with a
much narrower scope.

My main suggestion is that the Working Group make a better distinction
between its core deliverables (which in my mind should be a very concrete
Web Thing Description format and Web Thing API) and the more nascent and
abstract activities around the semantic web and application runtimes which
might be better suited to the Interest Group at this stage.

Best Wishes

Ben