[tf-td] WoT metadata

Hi Louay,

Many thanks for sharing your ideas on WoT metadata and APIs.  I think it would be valuable to discuss some of the design premises and how these have led me to a somewhat different outcome. 

The Web of Things is distributed and as such synchronisation can’t happen instantly, and if a server asks for a fresh reading of a remote sensor, by the time it gets that reading, it may well be out of date.
Creating accurate timestamps for sensor readings is likewise challenging due to the difficulties and costs involved in synchronising clocks, moreover many IoT devices lack real-time clocks.
We want to decouple the application scripts from the transfer and transport layer to reduce the burden on application developers and give system developers greater freedom for how they select protocols and messaging schemes to match the context.
The simpler the scripting model, the easier will be to get widespread adoption of the Web of Things. Web developers tend to be scathing of what they see as unnecessary complexity.
Scaling the Web of Things to low end devices will open up many business opportunities, so we need to reduce the memory and processing requirements to the minimum.

For dynamic scripting languages, the server can define setters and getters on the software objects it creates for things.  The application script can then use simple assignment and comparison operators on object properties. The server can use the communications metadata to implement the most appropriate way to handle property updates. There is no need to expose Promises or call backs at the application scripting level when it comes to thing properties. To do so would introduce a coupling between app scripts and the transfer layer and communications metadata, something that we want to avoid.

Another point is the need to separate thing data models from the communications metadata. Including the URIs for each thing for each protocol the server supports as part of the same metadata resource as the thing data model is going to create problems, e.g. if you update which protocols a server supports, it could become painful to then have to also update all of the metadata files for each thing hosted by the server. An alternative is for servers to expose metadata that can be accessed independently of the thing data models. This metadata can provide base URIs for each protocol and be used in combination with a thing specific name declared in the data model that is accessed via the URI for the thing’s description. I’ve partially implemented this approach in my NodeJS-based server.

When it comes to how to represent thing data models, it is no longer clear to me that JSON-LD is a particularly good fit, as a result I am now looking at alternatives. Some stakeholders are committed to XML, whilst Web developers will prefer very lean JSON based representations.  RDF as the formal underpinning is important for scalability, but this shouldn’t be a burden on application developers, especially Web developers. I think we need to consider a range of different approaches and evaluate them with a broad range of developers from a mix of backgrounds. This will minimise the risk of a W3C standard that in practice is largely ignored by stakeholders who don’t share the premises held by the Working Group that developed it.

—
   Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>