Context: WoT assumptions
○ Part of the Web of Things Architecture
○ Represents a Thing on the Web
○ Component-based architecture that addresses different concerns
○ Defined in the French ASAWoO project
○ One possible implementation of a servient
○ Defines a vocabulary that distinguishes
● Embedded WoT server
○ Standard compliant
○ Partly implement servient / avatar architecture
○ Expose RESTful capabilities 3
● Be based on Web standards
○ Protocols: HTTP, CoAP
○ Communication scheme: REST
● Ensure application-level Interoperability and Discoverability
○ Provide Semantic resource descriptions
○ RDF, RDF-S, OWL
● Fit in constrained devices
○ Ease of Deployment and Scalability
1. Computing power: CPU, Memory, Storage
3. Energy Efficiency 4
Embedding minimum technologies for constrained devices to integrate the
Semantic Web of Things, without undermining their original functionalities.
Constrained Device software components
● Thing Configuration: A non-volatile memory space where the state of the
device’s services is stored.
● Semantic Server Repository: A space where the device can store and
read its Semantic descriptions.
● Service Model: In memory representation of the services currently
provided by the sensors and actuators.
● Processing buffers: Handle requests and generate responses
○ CoAP headers
○ JSON payloads
CoAP(Constrained Application Protocol)
- Analogous to HTTP request semantics (GET/POST/PUT…)
- Binary Headers
➔ Support for REST implementations
- On top of UDP (but also 6LoWPAN)
- Blockwise transfer: fixed size packet exchange
➔ Suitable for constrained devices
Constrained Device processing workflow
Mode 1: Startup
Mode 2: Requesting
Sem. Server Repo.
Request Buffer AnalyserService URI
. . .
A Thing exposes a list of Capabilities.
● Capability Properties
○ Enabled Status
Each device describes its API through a complete Hydra API documentation
➔ Resource Expensive
➔ Use Linked Data to reference common parts of the API → ASAWoO
Hosted @ http://liris.cnrs.fr/asawoo/ontology/asawoo-hydra.jsonld
Semantic API documentation
Hydra-based documentation example
"@type" : ["hydra:Resource","asawoo:Capability"],
"description": "Retrieves a temperature.",
"hydra:supportedOperation" : [
"description": "The value returned for a Temperature reading, as specified in SAREF."
Hosted @ https://github.com/ucbl/arduinoRdfServer/blob/master/example/arduino.jsonld
Feasibility is achieved on a Constrained Device using the CoAP standard with a
● Several services can be instantiated at once.
● Embedded RDF graphs are used by both client and server to describe an
● Configuration persists through power cuts 19
RAM Footprint Cumulative Available RAM
Algorithm & Class Instantiation 968B 1080B (52%)
Service Template (x3) 279B 725B (35.4%)
Static JSON Buffers 200B 525B (25.63%)
Package-processing variables 24B 501B (24.46%)
● POC about semantic interoperability in the WoT on constrained devices
● Next step: intelligent clients that can discover and use such WoT servers
● A step toward decentralized semantic WoT?
○ Aggregating such servers can result in complex applications by pushing hypermedia
This work is supported by the French Agence Nationale pour la Recherche (ANR) under the grant