Our presentation of the paper at the 7th international Workshop on the Web of Things http://webofthings.org/wp-content/uploads/2016/07/WoT_2016_Paper_6_ConstrainedSemanticWoT.pdf
3. Context: WoT assumptions
● Servient
○ Part of the Web of Things Architecture
○ Represents a Thing on the Web
○ Component-based architecture that addresses different concerns
● Avatar
○ Defined in the French ASAWoO project
○ One possible implementation of a servient
○ Defines a vocabulary that distinguishes
■ Capabilities
■ Functionalities
● Embedded WoT server
○ Standard compliant
○ Partly implement servient / avatar architecture
○ Expose RESTful capabilities 3
4. Requirements
● 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
○ Constraints:
1. Computing power: CPU, Memory, Storage
2. Network
3. Energy Efficiency 4
9. 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
9
Constrained Thing
Thing
Configuration
Semantic
Server
Repository
RAM
e
Service
Model
Processing
buffers
10. Application Protocol
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
10
11. Constrained Device processing workflow
Mode 1: Startup
Mode 2: Requesting
Boot
Device
Configuration
Reader
Thing Config.
List of
Enabled
Services
Service
Parser
Sem. Server Repo.
Service
TemplateService
TemplateService
Model
CoAP
Request Buffer AnalyserService URI
. . .
Completeness
Detection
Sensor/Act.
Sensor/Act.
CoAP
Response
Results
Buffer
Serializing CoAP
Buffer
Blockwise
Transfer
11
13. A Thing exposes a list of Capabilities.
● Capability Properties
○ Enabled Status
○ Command
○ Value
Each device describes its API through a complete Hydra API documentation
➔ Resource Expensive
➔ Use Linked Data to reference common parts of the API → ASAWoO
ontology
Hosted @ http://liris.cnrs.fr/asawoo/ontology/asawoo-hydra.jsonld
Semantic API documentation
13
14. Hydra-based documentation example
{
"@id":"vocab:temperatureSensor",
"@type" : ["hydra:Resource","asawoo:Capability"],
"description": "Retrieves a temperature.",
"hydra:supportedOperation" : [
{
"@id": "_:senseTemp",
"@type": "asawoo:capability_retrieve",
"returns": "vocab:Temperature"
},[...]
]
},[...]
{
"@id": "vocab:Temperature",
"@type": ["http://ontology.tno.nl/saref/#Temperature","asawoo:Value"],
"description": "The value returned for a Temperature reading, as specified in SAREF."
},[...]
14
Hosted @ https://github.com/ucbl/arduinoRdfServer/blob/master/example/arduino.jsonld
19. Results
Feasibility is achieved on a Constrained Device using the CoAP standard with a
REST architecture:
● Several services can be instantiated at once.
● Embedded RDF graphs are used by both client and server to describe an
API
● 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%)
21. Conclusion
● 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
possibilities further
21
