Re: Project Things by Mozilla and the Web Thing API

On 15 July 2017 at 12:06, Dave Raggett <dsr@w3.org> wrote:

> JSON-LD isn’t essential for mapping JSON to Linked Data. A simple
> algorithm borrows the context mechanism from JSON-LD, and maps the names in
> the JSON name/value pairs either to predicates or to labels for blank nodes
> according to whether the depth of nested JSON objects is odd or even. The
> default context provides the mapping of common names to Linked Data URIs.
> An explicit @context should be used for uncommon names.  The default
> context could be referenced as part of a media type definition for thing
> descriptions.
>
> I’ve implemented this algorithm in JavaScript and described it in detail
> at:
>
>     https://github.com/w3c/wot/blob/master/proposals/dsr-td/
> json-to-ld-dsr.md
>

This all sounds good. If I understand correctly this achieves the goal of
having a core vocabulary in plain JSON with a default context, which can
then be extended with a simple mechanism using a @context property like
JSON-LD. A new MIME type could be used to indicate this core description is
being used, similar to the use of the application/manifest+json MIME type
<https://w3c.github.io/manifest/#media-type-registration> by the Web App
Manifest specification.

Rather than formally mixing JSON and JSON-LD, it would be better to use a
> regular algorithm that maps the example in its entirety to Linked Data.
>

I can certainly see the value in formally defining this mapping. From the
specification writing point of view it would be nice to just introduce the
simple core description first and show how that can be used, before going
into the complexities of how this can be algorithmically mapped onto a
linked data ontology.


> The idea of Web Thing Type schemas is something we’re discussing. Darko
> has some work on recipes and ingredients, where an ingredient describes a
> given capability that you can combine with others as a recipe. The question
> we need to answer is what is the minimum requirements for enabling that.
> My guess is that the @type (rdf:type) link to a semantic model is
> sufficient, as this allows for validation that the thing’s properties etc.
> are consistent with the recipe.  It may however be desirable to support
> some kind of @import statement for referencing external definitions when
> standardising a suite of devices using shared definitions for properties
> etc.  OCF and oneM2M both use this kind of modularity in their definitions
> of interfaces that make up particular classes of devices.
>

This sounds good, I agree with you that @type may be enough to get started.

That is a misunderstanding.  It would be natural to have different
> implementations of drivers for different operating systems and IoT
> platforms. The metadata allows a given platform to find and install the
> correct driver for that platform. A regular web developer doesn’t see any
> of this, as it is the platform’s responsibility to manage the drivers.
>
> An example might help. A web developer designs an application that runs on
> a home hub and makes use of a thing provided by home appliance that co
> application/manifest+jsonnforms to the OCF definition and is accessed via
> CoAP. The thing description for that appliance includes an identifier for
> the OCF standards suite. The context maps this identifier to a URI that the
> home hub can dereference to get metadata describing the available drivers
> for different platforms. The home hub can then install the appropriate
> driver, taking care to check the security credentials to ensure that the
> driver is from a trusted source.
>
> The metadata needed to describe the available drivers would be
> standardised later, as it is sufficient initially to just define a
> predicate that identifies the target protocol/standards suite.
>

Yes I did misunderstand that a little, I see that what you're proposing
allows for different driver implementations for different IoT platforms.
This is still straying into defining a software packaging system, or at
least a common metadata standard across multiple software packaging systems
responsible for identifying and validating software packages to install.
I'm still sceptical of this working in practice.

I guess there are also different types of adapters (drivers). Most of the
adapters we have implemented so far (e.g. for Zigbee, Z-Wave and GPIO) also
have hardware requirements so are not things that could just be downloaded
and installed as software packages. We do have an experimental adapter for
Philips Hue which is a purely software based adapter which maps Web Thing
API calls onto the Hue hub's proprietary REST API - but my hope is that
over time these web-like APIs (also potentially including the OCF/CoAP
example you give above) can converge towards a common standard so that
these types of web to web adapters are less necessary.

When it comes to WoT hubs/gateways there's clearly going to be a need to be
able to add or update adapters for new device types or protocols over time
though and I don't think we yet have a good answer for how that could work
at scale, or whether it can or should reasonably be standardised at the
W3C. Happy to continue that discussion.



> I agree. We should avoid embedding the communications metadata directly in
> the thing description. For example, when a home appliance registers with a
> gateway, the registration process could record the communications metadata
> in association with the thing description. When an application wants to use
> the thing provided by the home appliance, the application platform uses the
> URI for the thing description as an index for the associated communications
> metadata.
>
> As an example, if the device is accessed via HTTPS, the application
> platform would need the corresponding URL, and any associated security
> credentials needed for accessing that URL. The metadata describing this can
> be provided as part of the thing registration process. A given thing might
> be provided by a home appliance for use with applications on a home hub
> within the firewall, and for applications running in the cloud on the
> Internet. The registration process for the home hub and for the cloud hub
> will provide different communications metadata, but the thing description
> will be unchanged apart from having a different URI.
>

I see a distinction here between the URLs of web resources which represent
a Web Thing and metadata about non-web communications protocols which may
be used in implementation layers below the web layer. I do think the Web
Thing Description should include links to the Web Thing's resources (e.g.
using http:// ws:// and coap:// URLs), but I don't think the Web Thing
Description should include metadata about the protocols used in the
implementation layer beneath the web layer (e.g. WiFi, Bluetooth, ZigBee or
Z-Wave).

The fact that the Web Thing Description includes URLs to web resources is
what makes it a description of a "web thing" as opposed to just a
description of a "thing", which is pretty useless without the metadata
needed to actually interact with it.


> Note a complication is that the IP address obtained by DHCP may change
> from time to time. The lack of a stable IP address and the Domain Name
> System for local area networks is a challenge for embedding URIs for local
> devices as part of applications. Likewise for thing descriptions that
> reference other thing descriptions. This calls for further discussion of
> device identifiers. This is also related to privacy concerns where you want
> to avoid persistent identifiers that could be used to track people. How
> does a light switch identify a given light if the identifiers are not
> persistent?  What are the implications of the EU’s GDPR regulations?
>

Yes, I think we have to solve the problem of DNS or a DNS equivalent on
local networks so that secure persistent URLs for Things can exist - and
define best practices to address privacy issues.


> To allow for a dynamic set of applications, there will be a need to
> install and uninstall applications, but the precise means to manage this
> may be platform dependent.  At this stage we just need to demonstrate that
> the core standard doesn’t conflict with implementing such management
> services.  We need to be careful to distinguish the experimental APIs we’re
> exploring in the plugfests from what we’re proposing as a standards track
> deliverable.
>

I'm not so worried about this being a problem. Web applications and native
applications commonly consume web services. As far as applications are
concerned, web things are just web resources like any other.

I do think there's a danger of scope creep here, in trying to standardise a
whole application runtime. IMO we should focus on the core issues addressed
by the Thing Description and let applications interact with things as they
do any other web service.


> The Internet is a good analogy. It provides an abstraction layer in terms
> of IP addresses and packets, and avoids developers from needing to know
> about the details of particular networking technologies and the networks
> that use them.  Over time the network technologies have continued to evolve
> and the same is true for IoT technologies. W3C needs to complement the
> choice of IoT technologies and not to mandate which ones to use.
>
We do need standards for the communication metadata used to identify
> protocol bindings. This needs to be done in collaboration with the
> corresponding standards development organisations, e.g. IETF, OCF, oneM2M,
> ...
>

The way I see this is that W3C needs to standardise the web layer and be
agnostic of the implementation stack underneath. Ideally the OCF, OGC and
W3C would converge on a single thing description format and the IETF would
address whether HTTP is appropriate for IoT use cases or whether something
more like CoaP or even an HTTP/3 is needed.

I agree. I think it can be helpful to distinguish the protocols and
> technologies needed to access devices from the protocols commonly used on
> the Internet. The Web of Things abstracts away from this, allowing
> developers to use say HTTP to access a gateway, and for the gateway to use
> say Bluetooth to access an IoT device.  Developers can thus choose the
> integration pattern to match their requirements.
>
> For me a key principle is to decouple applications from the communication
> patterns. In some cases, there is a need for buffering of sensor readings
> and multiplexing of data from multiple sensors and so forth. Battery
> operated devices may spend most of the time asleep. Gateways and cloud hubs
> can host proxies that provide access to caches of sensor data.
>

Exactly.

It is likely that only a few protocols will be widely used on the Internet,
> but we can expect will continue to see greater variety for the device
> technologies. I agree that it would be nice if there were to be
> convergence, e.g. on scripting APIs and application scripting languages.
> JavaScript is certainly attractive given its support by Web browsers and
> the extensive community around NodeJS. However, this is perhaps analogous
> to image formats for web pages. HTML doesn’t specify which image formats
> browser must support, but in practice, there is strong convergence around
> GIF, PNG and JPEG.
>

Yes technically speaking the client side of the web can support multiple
scripting languages in the same way that it can support multiple image
formats, but in practice all web browsers use JavaScript. My expectation is
that the client side of the web will continue to use JavaScript and the
server side of the web will continue to use multiple languages. If the
interface to Web Things is their URLs (via REST & WebSockets) then I see no
need to standardise a new scripting API. On the client side of the web we
already have XMLHttpRequest, fetch and WebSocket. The server side of the
Web of Things can expose a standard web API via URLs and compete on the
underlying implementations in different programming languages.


>
> Note that I am writing this on a personal basis and not on behalf of the
> WoT IG/WG or W3C.
>

You don't need to state this for my benefit. I imagine it is quite rare
that everyone at the W3C agrees on anything! ;)

Ben