Content Types for Serialisation of Thing Descriptions and Server Metadata as JSON-LD

Simple metadata descriptions are essential for widespread adoption by Web developers and cheap IoT devices.

By choosing to formally base the description of IoT services on the resource description framework (RDF), W3C will provide a solid foundation for web scale markets of services. However, existing serialisations of RDF are relatively expensive to process and unpopular with Web developers. We need a lightweight syntax that web developers are comfortable with, has a simple mapping to RDF, and which can be processed conveniently on resource constrained devices, so that we can run web of things servers on IoT devices powered by microcontrollers. One possibility is JSON-LD which builds upon the popularity of JSON as a data format that has surpassed XML as a common format for data transfer on the Web. The key value of JSON-LD is the means to enable the use of short terms in place of RDF's URI's. A standard set of short names would enable compact implementations of servers for constrained devices. Note that thing descriptions could be serialised in a number of formats, and there is no implication that this be limited to JSON-LD.

One suggestion has been to use the existing JSON-LD content type along with a Link header to reference the default context. This has three drawbacks. The first is that not all protocols that could be used to access thing descriptions support the Link header or its equivalent. We shouldn't make the assumption that the Link header is always available. The second drawback is that it will be impractical for constrained devices to download and process the linked context. The third drawback is that the Link header increases memory demands, which could be a problem for low end devices with very limited memory.

The Working Group should be free to choose the data format that best suits the needs of web developers. JSON-LD was not developed with expressing object data models in mind, and it is possible that an alternative JSON based syntax may prove a better fit. Other possibilities could include the Link format used with HTTP and CoAP, which was developed to support HATEOAS (Hypermedia as the Engine of Application State). Ideally, a number of different approaches would be provided for review by web developers based upon practical implementation experience with experimental web of things servers.

See Also